I’d love some advice that I can pass on to other modellers…
Many times it is clear where an INSTRUCTION or ACTION should be modelled in a template ie an order vs something that has been done.
In the clinical scenario where we want to extract and share a list of medications that a patient is currently taking I’m faced with two options…
Include the list of INSTRUCTIONs that make up the current Medication list, package it up and send to the receiving EHR, with the added benefit that they can include the INSTRUCTIONs and immediately have the potential to use it to populate their new Medication List; OR
Include the medication list as ACTIONs, such that it accurately represents the actual things the patient is taking or has been administered.
So, my assumptions are:
If extracting from an openEHR system natively to another openEHR system, the first option makes most sense.
If a patient is adding meds into their phone app, I’d like model it as an ACTION, representing what they say they are taking but not adding in the extra semantics and apparent authority that this is correct enough to prescribe from, which is somewhat implied in an INSTRUCTION.
Now, my question: If sending from an openEHR system via FHIR, in this context we are likely mapping to a FHIR Medication Statement resource and it is not clear to me whether INSTRUCTION or ACTION class might be better to model in the source template that will be the basis for the extract.
It is described as: “A MedicationStatement may indicate that the patient may be taking the medication now or has taken the medication in the past or will be taking the medication in the future.” So, to me it is a munge of ACTION (past and current) plus INSTRUCTION (future) - but not intended to be as detailed as any of these. It is clearly a technical construct that does potentially facilitate FHIR exchange in the technical sense, but doesn’t make much sense to me as a clinician, especially if it ends up duplicating the record of meds taken, being taken or ordered. We can record the info captured from consumers and carers etc in our existing models using RM for provenance and don’t need a separate model for the purpose.
I also note that we have an EVALUATION for a Medication summary that is intended to provide an overview of drugs that need a helicopter view such as steroid administration over time, cumulative toxic drug intake etc. Quite a different notion, and primarily a clinical purpose.
I’m reluctant to advocate for an equivalent archetype to the FHIR Medication Statement, mainly because of the duplication issues and overheads.
Brief response as I’m on my phone. We definitely need to reflect the idea of medication statement as a snapshot list of current and perhaps recent medication, both for use at exchange and also for some statement type lists within systems. Eg medicines reconciliation. This quite distinct from a full prescribing system where there is an initial instruction order followed by multiple action events.
My own approach is generally not to use actions for pure statements but to roll up the relevant action states a d dates in a medication order summary cluster archetype carried within each order instruction. Look for idcr medication statement template in the Apperta CKM. I’ll update with a link later.
We do also need that separate medication summary evaluation archetype for life long use of a med particularly in registry settings as these often refer to medication groups rather than individual drugs eg anticoagulants. Again we have som examples in apperta ckm. Links to follow.
I think we usually forget about the Integration information model (in this case, GENERIC_ENTRY), and in my opinion this should be the way of doing things in a generic way for models coming from other standards. It’s not that common to find that semantics between different Classes of different RMs align completely. Creating a given GENERIC_ENTRY from a medication resource should be quite straightforward, and the meaning of classes should be the ones from the original class. Easier to define and map.
Then the answer is model both (Instruction and Action medication), which will map to a single Resource (or probably each one to a profile over the resource)
I look at it the same way as @ian.mcnicoll. The use case at hand is to exchange some information about the state of the medication situation for the patient. It’s not about the real Instruction or Action. What’s needed is a summary. The summary might have references to the primary data, but it’s not the primary source.
If the use case was to transfer the patient data you would transfer the primary data. But that’s another story.
I might have misunderstood the use-case @heather.leslie. So correct me if I where wrong in my assumptions.
@bna - I really don’t think we need to introduce a new ‘medication statement’ archetype as opposed to ‘medication order’ - in practice they are virtually identical.
I just add an ‘Order summary cluster’ to the medication order INSTRUCTION
This carries the overall status of the order (including discontinued) and an optional set of ‘key dates’ - these are often ‘derived’ e.f Date First prescribed, Date last dispensed, Date last authorised, Date discontinued.
This can all be done using ACTION archetypes of course but it is really messy to model and does not really provide any additional value in the context of a ‘statement’ use-case.
We are actually working on an interesting project in Wales that will use several ‘Medication statements’, a Medication reconciliation statment, and a ‘Transcribed prescription list’ which more closely resembles a full prescribing system with ‘proper’ use of ACTION archetypes.
@heather.leslie we have an existing FHIR MedicationStatement service that maps to both Medication Order Instruction and Medication Action.
In short, you can’t have a instruction without an action otherwise it has no current state and have only an instruction definition.
When we receive a new medication statement resource (with a status of active) we create an Instruction with the order details and an Action with an Active state. I’ll have to look deeper at our mappings to confirm how we represent the effectiveDateTime and dateAsserted but I suspect that the dateAsserted will be the Action.time and the effectiveDateTime will go in the order timing cluster.
Thanks for all your comments. Exploring the practicality of this further…
This use case is, or will be, common. And as @heath.frankel points out, communication about meds in openEHR requires both the INSTRUCTION & the ACTION, in theory.
But if we’re engaging with non-openEHR systems, this is far too complex.
I am starting to imagine the need for a new archetype, to bridge between our INSTRUCTION/ACTION pair and the FHIR Medication statement. Also maybe consider it in a patient app with data being presented to a clinician who then needs to decide how/if/when to formally import it into the openEHR system (via INSTRUCTION/ACTION pair).
I’m not convinced that we can expect to export an INSTRUCTION/ACTION in an extract and expect it to be mapped adhoc and correctly by every system or vendor to a FHIR profile for exchange. But if we design an archetype that carries the content that needs to be, or currently is, exchanged and is aligned with the FHIR Medication statement, there could be some value - consider a purpose-built ‘Medication exchange’ EVALUATION that could be populated by derived data from an openEHR system and carries the ‘First ever prescribed’, Last prescribed, next due kind of dates, alongside the Drug name and dose amount/frequency (possibly to the level of reusing our Therapeutic direction models if we have to). Think integration archetype, here.
OK - awaiting howls of horror and anguish, now. Go!
The use of a MedicationStatement pattern goes well beyond the original FHIR definition (patient-reported) or messaged summaries.
In the work for Wales we are using it for
Messaged summaries
Outpatient medication records
Admission medication records/ reconciliation statements.
I think we all agree that there is a need for this kind of pattern but I am reluctant to create yet another flavour of Medication, since the contents of a MedicationStatement (based on experience from FHIR curation as well as various openEHR projects) is that they are pretty well identical to the MedicationOrder Instruction, with the addition of some kind of current status and a summary of ‘key dates’.
I’m happy that we can control the semantics of ‘Statement’ vs. ‘active Prescription’ by the enclosing Composition but there is perhaps an argument for adding some kind of marker to the Instruction to indicate that this is a statement, rather than an active order - that would also perhaps let us clearly delineate a statement vs. recommendation vs. an actual order.
If we do create a new Statement Evaluation, we will end up continually having to keep this in lock-step with the Instruction.
I get the messiness. But using an INSTRUCTION as you describe is a fudge and still potentially problematic outside an openEHR system. This is why an EVAL makes some sense to me.
I would like to investigate further, probably only to explore and identify which is the least worst solution, I guess. Maybe we need to consider a family of critical integration archetypes that align with FHIR, esp where INSTRUCTIONs/ACTIONs are hard to transform.
Perhaps we could chat to understand what else in the INSTRUCTION is useful from your experience…
I have found that almost everything in the existing INSTRUCTION is potentially required, depending on the use-case. This type of ‘Statement’ pattern is not just in summaries or exports but in things like Medication reconciliation documents, pharmacist reviews, local 'contextual medication statements e.g in patient app for asthma, where as well as the core INSTRUCTION data-points there might be some local/ contextual extensions like ‘Green inhaler’ .
I understand the unease about this being an INSTRUCTION vs. EVALUATION but there are many other places where INSTRUCTIONS will be used as ‘statements’ without related ACTIONS, and indeed arguably may of the paces that we use ACTION.procedurte this is really a history of procedures summary rather than part of an active workflow process.
My current policy is to ‘control’ the ‘flavour’ (yes- I know!!) of MedicaitonOrder ,by adding the CLUSTER.medication_order_summary , but more importantly to use the COMPOSITION.prescription archetype for a ‘proper’ medication management orde->dispense->admin cycle, and a COMPOSITION.medicaiton_list for other ‘statement’ type scenarios.
@bna - You will see from the list of uses that while Medication statements are generally summaries of an order-dispense-cycle handled somewhere else, they can be derived primary documents of their own e.g the documented results of a reconciliation process or pharmacy review.
In terms of exporting data to to other non-openEHR systems, in FHIR terms these will almost always be MedicatonStatement resources and I’ve already had a go at this here.
I’m rally not keen on having parallel and almost identical EVALUATION.medicitoonStatement and INSTRUCTION.medicaitonOrder archetypes - keeping these aligned will be an ongoing pain and make moving data back and forward between prescribing systems and internal statements another overhead (unless we drop virtually all of the content into a new CLUSTER) - which for me would be preferable but I’m really not sure that the risk of ‘mismatch’ justifies the overhead. Exposing medication data (however we do it) to external service like FHIR is always going to be much more complex than just clearly identifying EVALUATIONS vs. INSTRUCTIONS. An ‘actual’ prescribing system would almost certainly (in FHIR terms) expose both a MedicationStatement for consumption by other systems that just want a list/summary of ‘current medication’ - constructed on-the fly by querying into INSTRUCTIONS/ACTION in a clearly defined set of compositions. In other cases they may also map to FHIR MedicationREquest, Dispense etc if the external systems need to directly participate in the prescribing process.
If there is reluctance to use an INSTRUCTION/ACTION pair to fully represent the medication order and you don’t want a separate medication EVALUATION, to simply specify the current “asserted” state of a medication as per the MedicationStatement you can just use an ACTION in a similar way you represent Immunisations. The only difference is that the state is Active and not completed. This is similar to asserting that a procedure has been done without reference to an order.
There is an existing care_flow_step of ‘Medication reassessed’, which perhaps should be repurposed to ‘Medication assert’, to give you the ‘flavour’ of the active state.
You will just need to carry more medication details in the ACTION, which you would normal provide in the INSTRUCTION.
The downside of this is that you have no means to tie together any subsequent state transitions when the medicine is stopped or suspended, which is the value of the INSTRUCTION. Although, a workflow_id is one option of doing this but I am not sure if this is common practice amongst implementations.