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.
Hi @birger.haarbrandt did you get around how to query INSTRUCTION/ACTIVITY and their state from ACTIONs?
Iām going back to this topic since I think the modeling part is clear in the specs but not how that should be used in real life workflows, including how to create AQLs for querying state data for INSTRUCTIONs/ACTIVITIEs.
On the RM side, the representation of the references between ACTION and INSTRUCTION/ACTIVITY on instances is also something that should be improved in the specs. For now, what we are doing is explained in my last comment on the JIRA issue mentioned above (we are using instance paths not archetype paths as said in the specs).
I also came up with 3 queries we would like to see in the specs, because are pretty common:
Given an INSTRUCTION X, get itās last state.
Given an INSTRUCTION X, get all states (maybe with timing too).
Given a state Y, get all INSTRUCTIONs in that state.
Note that āstateā there is the careflow_step code, and INSTRUCTION is really the combination INSTRUCTION/ACTIVITY, because the state change might be for a specific ACTIVITY inside the INSTRUCTION.