we are currently diving a bit deeper into this topic and I got some questions. To my understanding, an Activity inside an Instruction is referenced by an action entry within the instruction_details.
Now, we want to query the latest careflow_step of all activities within a specific archetype (e.g. medication) for a patient and maybe filter using the current state of an action. To my understanding, this will require to execute multiple AQL queries which seems like a rather inefficient way.
We might be able to resolve some of these issues by introducing sub-selects to AQL, but this will likely not do the whole trick. It would be great if others can share their experience how to implement this (e.g. I think it would be useful to additionally âforwardâ reference the actions from an instruction and not only vice versa, but this might be an internal implementation detail).
If the INSTRUCTIONs and their resulting ACTIONs are indexed, as they would be from a Care Plan, and the references are progressively built every time an ACTION is performed on an order in that Care Plan, then you just have to pull up the Care Plan to see what the situation is.
This kind of indexing can be done from any Composition, not just a Care Plan - it could be done in the Medications List for example. Similarly, a global list of âactiveâ (= ISM active and suspended) Instructions could be maintained (one per EHR) to track all active orders.
If just using raw AQL querying to get back the ACTION chain for an order, smart indexing could make use of the ACTION.instruction_details info, but thatâs a kind of special processing that most platform implementers would want to avoid.
We are currently discussing a related topic from an issue/border case I detected some time ago [SPECPR-221] - openEHR JIRA
As Thomas says, some kind of index might be needed (external to the RM data), to query for the statuses or last status for an INSTRUCTION/ACTIVITY combination.
I also think, some kind of extra management is needed internally, for instance, if a ISM_TRANSITION is the last for an INSTRUCTION/ACTIVITY, if could have an âis_lastâ at the database level, then when a new ACTION is committed for the same INSTRUCTION/ACTIVITY, the âis_lastâ flag should be updated to false in the previous ACTION.ism_transition, and set to true in the new one. All that should be transparent to the client/user of the CDR, and might require some batch work since doing all that during the same commit transaction, just to make everything look atomic, might have a huge performance impact.