Why not? Small changes to the RM are easy, and it is now clear to me that tracking changes to orders, as opposed to tracking actions undertaken in the execution of said orders, is not properly modelled in the RM. Doing so I think would make life much easier at the archetype / template / form / visualisation levels.
Anyway, to be discussed.
RM changes, however small are not easy to actually implement- tooling, CDRs training material …
I’m not against RM chanbges per-se I just agree with Heather that this does not need a new archetype class.
The issue of tracking ‘order changes’ is a red-herring - that is not an issue. We manage it perfectly well within the Action.medication archetype right now and noone of these would norm,ally appearin this ‘Statement’ in any case.
The use-case is a need to summarise an INSTRUCTION (actually potentially all of it) and selected ACTION events, including some ‘dervied’ datappoints like Data First prescribed data last issued, along with a simplified idea of ‘status’ which is likely to be simialr to the generic current_staus values but more likely to be clinically nuanced.
I can replicate that right now, either by using a CLUSTER inside the INSTRUCTION, it works well, and is being used in production.
The second alternative is to create some custom summative ACTION archetypes for this purpose - arguably a better approach.
The third is something like an OBSERVATION archetype, as Heather suggests. I’m not bothered about the class. It is pint-in-time snapshot, so Observation fits well enough. My main concern is that it will basically look virtually identical to the original Medicaition order and I don’t think that parallel modelling is necessary. We can meet the requirement of the ‘Statement’ pattern *which goes beyond the FHIr scope) without creating parallel models.
As ever, I would not want ot get too hung up on the’ philosophical/ontological’ fit for current archetype classes - these are convenience data structures not pure ontological commitments.
Ok - so something like a ‘status report’ or ‘snapshot’ of the state of execution of an Instruction by HCPs/patient/whomever? Sounds like some kind of ‘report’ or ‘summary’. We don’t really have a good RM type for this at the moment, but it would be at least partly solved (I think) by the proposed Citation / View Entry intended to also solve the challenge of constructing Problem and other managed lists. ‘VIEW’ probably isn’t a great name, maybe ‘NOTE’ or would be better.
It is an RM change, but, done right, it would address a whole raft of needs. In its current form, it still wouldn’t provide all the data points you need, but an archetype of VIEW_ENTRY could.
Minor point - it’s probably not a great idea to misuse RM classes too much, because archetypes based on those classes will turn up in unexpected / wrong places in tools like CKM… the above-described use case is most definitely not an Observation in the sense of the RM. These classes are not really ‘convenience’ data structures, they are intentionally modelled to address exactly the things they address (which they may not do perfectly of course).
Sorry Tom,
We absolutely do not need a new class. We can do all we need with existing classes.
If we are were to create new class for every ontological subtlety that we encounter we would have another 5 or 6 classes just in medication. If we need those ontological classifications to support grouping /searching in tools like CKM, that can be done but it should not , IMO be hardwired into classes, unless there is a very clear need for a different kind of basic structure that the existing classes do not support. This is not one of those use-cases.
Well we are already going to add something to support Views/citations/reports, which we have needed for a long time. It will potentially cover this new need, so we ought to analyse that. We don’t add classes for every ontological subtlety (not even close), which is why openEHR RM is 1/3 the size of say FHIR, and more generic. But it doesn’t address everything that is needed, so careful changes are needed and are already happening (currently RM Release 1.1.0). I don’t see what the objection here is.
Agree. Changing orders is opening up the proverbial can of worms. Not sure that ACTIONS are the safe place to do it though. Most often, especially with medications, a new order to replace the original is the safest.
Disagree. The commonality is only ID of the medication and dose. This should be common in the INSTRUCTION, ACTION and this proposed OBSERVATION for statement. Otherwise it is a completely different purpose. OBSERVATION does work well to create repeatable, consistent data with a specific point in time effect, recorded once only within an event based COMPOSITION or FHIR message. And I see enormous value in creating something simple that will align with a major FHIR use case without all of the elegant complexity that comes bundled up with an ACTION. Think of it as an integration model, if you like. But I think it has utility in the real world and using the different class helps to differentiate it from the others for those without lots of openEHR experience. There is value in ‘teachability’ and ‘pass-onability’ as well as semantics. Multiple INSTRUCTIONs for medication related stuff will cause confusion.
Disagree that it’s a misuse. We need the semantics of the ‘point in time’ event.
Again, lets organise a chat to fast track and get everyone aligned. We may have been able to find a common way forward in 5 minutes of real-time discussion… Then again, maybe not 
Have a good one 
I’m still not really clear on the requirements then 
- agree on the call - anyone care to organise? I’ll fit in.