Yes - thnks Silje that’s a nice summary and exactly how it is being used in the UK. THe original intent was, I think, really to capture patient-reported data but we saw the need for a similar structure to represent a ‘statement of current/recent medication’ for
-
Where a system exposing the statement does not have a native e-prescribing system, and the data is originally recorded as a Statement in the first place.
-
Other parts of the record e.g. as part of a discharge summary, reconciliation report etc where a simplified compressed form of the full prescribing cycle information is really what is required.
-
As a facade on top of systems which do have a full e-prescribing system e.g UK GP systems - they can expose their data as a set of Instructions and multiple Actions (in our terms) but this becomes really burdensome for third-parties to handle especially as they nearly always just want a ‘list of current/recent medications’ and do not want or need ot work interactively with the prescribing system.
We had already gone down this road pre-FHIR as it became apparent that trying to handle the requirements of something an emergency patient summary with ‘pure’ Instructions and Actions was just way too difficult to manage. As well as there being the complexity of multiple Actions, some of the data points required were essentially ‘derived data’ like ‘Date last prescribed’ - there is no such thing in a pure Instruction/Action cycle it is just the most recent ‘Prescription issued’ event. Even in the UK the 4 country summaries all had slightly different requirements in that regard.
The UK MedicaitionStatment profile has extensions to handle some of these data points.
Essentially I see it as a summative statement comprising most of the original Instruction, usually the status of probably the last Action event and a (variable) selection of other key dates and details from intermediate events but it is really somewhat different from a true ACTION and not really an INSTRUCTION either.
I chose to handle this as an INSTRUCTION with the summary cluster because the core of of the structure is and needs to be identical to that of the Medication order. We could create a new ACTION or even an EVALUATION but that means essentially duplicating (and maintaining) the whole Order structure.
I’m not even sure I would regard this as a real ACTION. It obviously carries some kind of current_status and Heather has found that it fits the generic ism_transition states but I’m not sure I would want to rely on that plus it raises other issues in tooling etc. It also really not part of a true Action cycle - these are just snapshots of the current state of a more detailed set of events.
So I agree that MedicationStatment is ‘ontologically’ something different - a mashup of information from the original INSTRUCTION plus current status plus key information from underlying ACTION events (with quite variable requirements).
I’m not keen on overloading the existing ACTION.medication and I’d really prefer not to have another parallel archetype, 90% of which is identical to Medication Order. That is just a governance burden that we should avoid.
The use of INSTRUCTION plus a Cluster to capture the extra Statement requirements (status, key dates) has worked well for me, even though I agree that this not a true INSTRUCTION but the context if use makes that clear.
Options I can see
-
Use Medication order + ‘Statement extension’ as I have done. Works well practically, keeps Statement aligned with Order, allows flexibility in terms of what Action dates and other event information can be handled simply.
-
As above but specialise to make it clear that this is a MedicationStatment not an order - perhaps my preferred approach.
-
Specialise ACTION.medication to add the simplified care_flow steps that Heather has identified. That still leaves us with having to replicate a whole bunch of parts of Medication Order e.g Dispensing information that may be needed as a part of a Statement but do not really belong in ACTUON.medication. It also exposes developers and clinicians to the complexities of ism_transitions/ careflow steps etc when all they really need is a simpler current_state flag.
-
Create a new MedicationStatement archetype - cleaner but then we have to mirror all of the MedicationOrder and keep it all aligned. Or we could rip up the existing Order and drop stuff into Clusters but there would be really high price to pay for the large number of current implementations that are using what we have already.
So I agree that this kind of Statement is really neither a pure ACTION or INSTRUCTION, and I don’t think it really needs to be an ACTION - it is not part of a workflow process - just a summary of that process.
I suspect here will be other similar requirements e.g summative statements of service delivery - I still honestly think therese are best (mostly) represented as INSTRUCTIONS with additional some summative information, perhaps as specialisations to make that different use clear.
.
.