I’m currently chewing on a model for procedures, so looking at the Procedure archetype, based on the ACTION class. Under purpose, it is stated that the scope covers “planning, scheduling, performance, suspension, cancellation, documentation and completion”. To support planned procedures, there’s a “planned procedure” pathway step and a “Scheduled date/time” element under defined under description. So far, so good.
However, the definition of the ACTION class states that it is “Used to record a clinical action that has been performed …“. And the INSTRUCTION class states “Used to specify actions in the future …”, while ACTIVITY explicitly models a “timing” element to specify the moment when the activity is to be performed. So from descriptions there seems to be a clear distinction between future and past.
Intuitively, it makes some sense to regard a concretely scheduled procedure as a concrete activity, but I’m confused as to how this aligns with the intended use of the models.
Hope that someone with a better understanding of these models can help me out.
I agree that “Used to record a clinical action that has been performed …“ is it may imply only completed states but ACTIONS have always explicitly been designed to handle non-complete states, so in this case I suspect ‘clinical action’ is intended to include ‘cancelled, ‘scheduled and even ‘proposed’.
I think you will find that the INSTRUCTION.timing attribute is very rarely used. It relies on an older timing syntax called GTS, but in practice, it is overly complex for simple cases and underpowered for e.g complex medication timings. Current practice is generally to use the simple dates/times inside the INSTRUCTION archetype for simple requirements and use the CLUSTER timing archetypes with daily, no daily and therapeutic direction or service direction to handle most complex cases.
You might find this document helpful in understanding how these archetypes work together, at least for medication. For non-medication examples use Service Direction as the parent construct
Hi Ian, thanks for the explanation. If you say the ACTIONS have always been designed to handle non-complete states, does that imply that the scope of INSTRUCTION is meant to be a bit narrower than “all things in the future”?
Adding to what @ian.mcnicoll said, an Instruction should be understood as a formal order, that will be acted upon by appropriate agents. The most common forms are a medication prescription, booking for procedure, e.g. surgery, dialysis etc. The Instruction is what the treating physician has asked to be done / scheduled etc.
Actions are records of real world acts performed by executors of the Instruction. For a medication order: anything to do with dispensing, administering, stopping, suspending, the medication will potentially have an Action to record it (it might not of course - there are generally no such recording for patient-administered home medication like antibiotics); same for any other order - Actions record what was done. E.g. a dialysis session should create at least one Action (for completion) but might generate Actions for all the steps, depending on the clinic software.
Bookings for review, dialysis, physio, surgery etc may (should) be recorded as Actions in the EHR, but of course they will also be in the booking system.
I find INSTRUCTIONs and ACTIONs a complicated but interesting topic, even more so than most other areas of health IT.
For some background you could study the Refermece Model specification: EHR Information Model
Please be aware that openEHR has been developed from a practical, documentation focussed, information State approach. While your background with zibs is more a conceptual model of reality.
Conceptually the procedure could be the same, wether in an order for a procedure or a carrier out procedure. But regarding documentation the meta information is very different.
The split between action and Instruction is extra relevant for keeping the state of that information. To know the ‘State of an INSTRUCTION’, you need to query for the corresponding ACTION. There’s ‘always’ a corresponding pair modelled. Check the paragraph on Instruction state machine.
One complicating factor is the implications of the patient centric EHR documentation model of openEHR RM. This level of detail for instructions quickly touches on semi automated scheduling of those instructions. Where information outside the scope of a single patients EHR is highly relevant, like list of employees with the right quilifications. Availabilty of devices, rooms etc etc. So we should be careful not to do too much with the INSTRUCTION/ACTION model. As Thomas is hinting at.
I think there’s some misunderstanding between you and Ian regarding completion. But I’ll leave it to him to explain more, before I confuse things further.
It would help our advice if you could share a bit more about you goals and challenges regarding procure model.
Thanks @thomas.beale and @joostholslag for the further explanation. Coming from a FHIR background (much more than a zib background Joost ) this explanation actually seems to align with the request/event pattern seen there.
At the moment, I’m mainly trying to understand the modeling approach and how to align this with the class descriptions found in the reference model.
Also bear in mind that some of the current ACTION archetypes in the international CKM are very old and long overdue for an overhaul.
I’m especially thinking of ACTION.medication and the way it tries to combine several different and completely separate pathways into a singe archetype, but also to a certain degree ACTION.procedure with its scars from early tooling and inexperienced modellers.
ACTION.service on the other hand is much more in line with current modelling patterns.
It is always worth reminding people of this. The EHR is a record - a series of items that document some observation, thought, order, action, review, goal, etc. It will always be an imperfect reflection of reality, but it is the record of events that we have. The job of an EHR is to faithfully record what someone chooses to commit to it - it is not a psychic entity that somehow ‘knows’ what really went on (if it was different).
The ‘model of reality’ mentality should be primarily aimed at representing processes, either in the future (how a certain thing, like intubation) should be done, or possibly representing past processes based on data that we can find.
Also worth repeating, since it’s a basic concept in openEHR. The most recent Action performed for an Instruction tells you the current state of the work described in the Instruction - maybe it was suspended, cancelled, completed, still active, whatever. You have to look at the chain of Actions over time to see the evolution of the ‘state’ of the Instruction.
) this explanation actually seems to align with the request/event pattern seen there.