Ability to model ism_transitions

I’m increasingly of the opinion that modelling of the specific ism_transitions is fraught with danger because it is really hard to model these with a universal use case in mind.
Inevitably, no matter how universal we intend to be, we end up being too specific or not specific enough for any given use case. So perhaps these should be added at the template level, rather than fixed (often unusably) at the archetype level. Or maybe archetype the easily universal ones, and allow the list to be extended where diversity is required.

I’m currently battling the ACTION.medication_management archetype. The FHIR IPS IG requires a Medication Statement which could leverage the ISM_transition groupings but definitely NOT the explicit pathway steps. In this way the ACTION groupings could come closer to the FHIR MedicationStatement.status value set (active/completed/intended/stopped/on hold/not taken) . Ignoring ‘entered in error’ for now.

I don’t think that designing another ‘Medication Statement’ archetype helps, nor adapting the INSTRUCTION. The scope of ACTION is to include planned, current, completed so if we could include the groupings in our modelling I actually think this would be useful. These groupings could be managed at archetype level, maybe leaving the specifics ism-transitions to be added at template level.

Thoughts?

Heather

I’m not sure I understand what the groupings would be. Could you give an example? :smile:

Planned, active, cancelled, postponed, completed, aborted.

Hi Heather, I’m trying to understand your requirement.

Do you want to model your own instruction state machine? https://specifications.openehr.org/releases/RM/latest/ehr.html#_the_standard_instruction_state_machine_ism

Or just define it in the template instead of in the archetype?

I’m expressing a growing concern that it is almost impossible to design detailed ism-transitions at archetype level. And there is value in being able just to say something is planned or completed, without duplicating the ‘grouping’ name in a specific ism_transition step.
What has been set up for the ACTION.medication_management was based on feedback from a domain that had quite a lot of experience and we thought it generic at the time, but in my experience there are other steps that are subtly semantically different and if we add all of those nuances it becomes nigh on unusable.
Is it valid to consider design ism-transitions in the template so that local implementations can share the transitions but we don’t impose on other implementations? Or at least give people a choice eg our current choice data type allowing free text or coded text. Certainly tooling doesn’t allow it now, but do the specs?

It is possible to capture the ism_transition current_status (the generic codes) without capturing any related archetyped careflow_step, which is optional. So we can already do what you are suggesting at run-time, just not specify it in the tooling

I do understand the issue you are hitting though - why when I have modelled ‘MedicationStatement’ I actually used the INSTRUCTION.medicaiton_order, coupled with a status cluster archetype.

The Medication Action does work very well if you are trying to capture the actual individual prescribing cycle events ie, in a real prescribing system, burt Medication statement is a good example of a different pattern where all we re recording (or exposing) is essentially a ‘current_status’ summary of a live or recent medication order. That will include some sort of generic status (current. discontinued etc) but that may well be flattened in a slightly arbitrary way, and also include not just the current datetime for that status but other key dates like Date first prescribed, Date last dispensed, Date last authorised, ‘Date of last 5 issues’ depending on the use-case.

I’m not sure that the represents a real ACTION in medication terms, it is a summary of the order and (some) related actions. That has value as a much easier set of data to understand than a full blown set of prescribing events - one of the reasons that we decided in the UK that GP systems should expose MedicationStatement, even though they all can expose the full cycle via Medication Order, Admin, Dispense resources. Most consumers just want to know ‘what is the patient taking’ without interacting with the prescribing system as such.

Ok, so we do need to be able to reveal it in the tooling. Ping @borut.fabjan and added as an AD feature request :angel:.

I know and understand this, but it’s rather clunky and clearly a compromise/workaround. If we’re going to work alongside FHIR in the long term I think we need a clear strategy or pattern. Many FHIR profiles have their equivalents of planned, active, cancelled, postponed, completed, aborted as a status, and I’m exploring how these inherent attributes in the openEHR RM could be utilised better. It also just makes sense clinically sometimes.

The FHIR Medication Statement is a gnarly modelling challenge - it is not intended to be just what the patient is taking now, but potentially what they took in the past and what they will take in the future. It could be argued that the concept is flawed, but rather than having any hope of bringing FHIR around to my POV, I see more potential in an ACTION supporting that complexity, especially as it morphs through the states, than an INSTRUCTION with a status qualifier. But I’m still exploring, really using this forum for thinking out loud, pondering the tensions, and hoping for brighter minds to provide some insight.

And the issue still remains, the pathway steps that have been published in the Medication Management ACTION have rarely aligned with my recent use cases, and this creates concern. If it doesn’t fit my use cases, then others will have the same experience. So still pondering how to maybe approach this better… :thinking:.

/cc @thomas.beale

I just happened to see this - is the idea here that you would ideally like to have an RM attribute representing something like ‘lifecycle status’ (aka document / authoring status) for prescriptions, and Instructions more generally, and that this should be separate from Actions that actually flow from a confirmed or completed Instruction being performed by others?

This sounds like a sensible addition to me, and would correctly separate ‘actions’ on the prescription itself from actions undertaken to execute the prescription, which is what the Action ISM transition steps and careflow steps are about.

Have I got this right? Would it make sense to add such an attribute to the RM in Release 1.1.0?

I understand the FHIR Medication statement a bit more now, and to me this seems like a completely separate concept from either the Medication order or Medication management. It can be derived from an order, but it’s neither a request to dispense or administer a medication, nor the primary documentation that the medication course is being planned, a dose has been taken, or that the medication has been ceased. I suspect a separate ACTION archetype is warranted for this concept, basically matching the FHIR resource.

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

  1. 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.

  2. 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.

  3. 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

  1. 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.

  2. As above but specialise to make it clear that this is a MedicationStatment not an order - perhaps my preferred approach.

  3. 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.

  4. 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.

I’m starting to think that an ADMIN_ENTRY is also a viable alternative, mirroring the FHIR resource exactly, given the nature of it for reporting and exchange rather than use in EHRs. None of the overload of the existing archetypes, nor openEHR CLASSES.

There are quite a few uses of Statements inside the clinical space - reconciliation reports, discharge letters, outpatient clinics, referrals, handover documents

How about specialising medicationorder to MedicationStatement? That makes the use clear, or at least safe.

These examples are already commonly represented as templates and I see them as quite a different use case.

My impression of the the Medication Statement is to be a communication tool, usually as part of a message within the FHIR context, and it could be used within the context of a Discharge summary to represent the discontinued meds etc alongside the Discharge meds intended for future care.

We may also need to consider other similar ‘snapshots’ used to convey current state of care, especially as part of transfer of care, might be valid for the course of a Problem, or state of Immunizations part way through a childhood schedule.

I can’t see how an INSTRUCTION helps here. I’m in agreement that on further consideration, while ACTION has the benefit of the ism_transitions, it is too complicated, especially if we want to mirror the FHIR resource or use it for similar purposes.
With the benefit of time, my thinking is evolving and I’m increasingly leaning towards the ADMIN or even a point in time event in an OBSERVATION to represent a snapshot with the state (active, completed etc) represented simply as a value set in a data element.

Sure - I agree they are templates but inside e.g. a referral letter, a list of current meds is essentially a list of MedicationStatements - some/all of the Instruction and a summation of actions. THe pattern is the same. Similarly for a reconciliation report - this is a set of Medication statements with additional reconciliation ‘markup’. In neither case are these true parts of a ‘live INSTRUCTION/ACTION cycle’.

I agree that the original definition/intent of the FHIR MedicationStatement was much narrower i.e for patient-reported information but when doing the FHIR profiling in the UK, so that is used in discharge letters etc , and we only use MedicationRequest for 'actual prescribing systems.

We could do the same and develop a specific MedicationStatement archetype but it will be structurally identical to Medication Order and that feels like unnecessary duplication.

One other option we have not explored is to have a new ?? ACTION medication_event_summary archetype that just carries the current_status and summative care_flow steps i.e. it is clear that this is a summary of Action events and the status is about the most recent event.

Also allow specific key dates to be modelled ‘eg. Date first prescribed’ , So roughly speaking, what I am doing in my CLUSTER medication_summary but move that to a new ACTION archetype to sit alongside the INSTRUCTION.

I’ve had a go here.

https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDFlMDdiMGRlOTM4YzRmYzJhYzQ3NThjYWI1N2ZkMjBj

I would not suggest OBSERVATION, but I potentially agree with the rest.

Back to my original question: would a lifecycle_status or similar attribute on INSTRUCTION help here? Or if you want to go one better, we could add a class similar to ISM_TRANSITION to INSTRUCTION, called (say) ORDER_STATE. Changes to to the order (as opposed to real Actions executing the order) would then be represented via variant versions of this in an INSTRUCTION archetype.

At runtime, a change on an order would result in a new (version of the original) INSTRUCTION instance, with the changes included, e.g. a different dose or narrative or whatever, plus an ORDER_STATE instance that documents what kind of change (‘adjusted dose’ | ‘validate repeat’ | etc).

This would be a cleaner version of the ADMIN suggestion.

Doing something like this would actually enable the complete separation of Actions that execute the order (i.e. dispensing, administration, suspension etc) from Actions that modify the order itself. Should have thought of this 20y ago…

This is getting more complicated than I can follow in a message thread. If we want to pursue this further, I suggest that we need a call.

Actually OBSERVATION as a point in time snapshot is increasingly what I perceive the medication statement to be. Use it in a message or within a discharge summary etc that is also a snapshot at a specified point in time. I’ve uploaded a proposal - https://ckm.openehr.org/ckm/#archetypeproposals_1013.38.169

We may be overthinking this.

Is a medication statement an Observation made on the patient (or tissue, blood etc)? If I understand it correctly, it is an assessment / list of medications the patient says s/he is currently on. I guess it could be an Observation, although to me it seems more like an attempt to obtain info from the patient to bring the medications list up to date.

In any case, the suggestion I have for the problem of Actions is this:

  • limit Actions to being actions taken by HCPs (or patient or other actor) in the execution of a medication order (i.e. the Instruction) as it is at the time;
  • add something else to the RM that represents changes / updates made to the order itself.

This would have the effect of making the list of Actions clearer and easier to understand - now they are just about delivering the medication, therapy, surgery or whatever, and it would also make the changes to the Rx easier to separate and e.g. display on a screen.

How does this sound? To me it sounds like something I wish we had thought of a long time ago :wink:

I think I need a real-time discussion on this. It isn’t clear to me what you are proposing but I’d like to understand more.

1 Like

Yes, I agree I think we need a bit of a real-time discussion. I think the use-case for the Statement pattern is somewhat wider than the intended FHIR scope, and I am not convinced that we really want to introduce yet another flavour of medication archetype. I certainly agree that we do not need a new RM class.

Should I ask Jill to fire out a Doodle, see if we can find a suitable time?

3 Likes

I’m not sure if this is actually related to a previous discussion we had on the old mailing lists https://www.mail-archive.com/openehr-clinical@lists.openehr.org/msg04586.html

It was some time ago, but we ended up adapting the tooling to reflect Ivar requirements. This methodology change at the very least allowed to create a visualization of all the workflow defined in the archetype

1 Like