I have been investigating referral workflows using Service request and Service archetypes. Does anyone have any best practice guidance for this type of INSTRUCTION and ACTION workflow? For example:
Should Service request and Service archetypes be in the same template together or separate templates?
Should the shared fields across both archetypes such as Description be copied over from Service request to Service and kept in sync - i.e. with edits and deletions?
Is there a proposed field to link the archetypes together - i.e. a referral identifier
Is there a suggested link between status of Service Request and ism transitions in service - i.e. Composition containing Service request archetype submitted and Service set to ism transition of Service request received
Both ways could work, and I think this is an implementation choice. For the initial order/request, I usually put both the INSTRUCTION and the ACTION together, with the ACTION in an appropriate current_state, usually planned or scheduled. This makes it easier to reuse the information for any later ACTION instances detailing the further process.
This is the way I do it, for the order composition. I havenât seen need for a lot of updating the INSTRUCTION and hence the (initial) ACTION, but that may just be the use cases Iâve worked on.
There are several:
The RM technical method is using the ACTION.instruction_details
Itâs also possible to use archetyped identifier elements which are usually put in the protocol of both INSTRUCTION and ACTION archetypes.
The status of an INSTRUCTION is held in the ism_transitionof its corresponding ACTION. Maybe I misunderstood the question?
Agree @silje that there can definitely be slightly different approaches and also agree with your preferred approach. Put the âfirst instanceâ of the ACTION in the same COMPOSITION of the INSTRUCTION to capture âinitiationâ of the order, then separate ACTIONS in one or more other COMPOSITIONS.
Agree too that the use of ACTION.instruction_details is the correct way for the different ACTIONS to link back to the original INSTRUCTION but in a distributed system where there are different CDRs or e.g a typical non openEHR lab system, that is where the Order Identifiers come in (in line with HL7). Some sort of common shared âexternalâ order number that both parties in the process use and would appear e.g lab messages. @Ian_Bennett - that is your âorder identifierâ
There are 2 flavours:
Requester Order Identifier (HL7 Placer Order number): This is issued by the system/app making the order.
Receiver IOrder Identifier (HL7 Filler Order nyumber): This is issued by the system/app that is receiving the order, and handed back to the requesting app as an initial message.
Often both are carried in HL7 messages, and I would probably record them even if also using the internal openEHR instruction_details ot manage the âlinksâ internally.
The issue about whether to replicate details like âdescriptionâ is really a local one, and is really about local governance, and exactly what might have changed in the ACTION versus the original INSTRUCTION e.g. if a referral is being triaged, it is possible that the service name as well as the description might need to be changed if the referral is re-routed to a more appropriate place - does this mean that the original INSTUCTION is changed or is this essentially a New INSTRUCTION, issued by the triage service. Often however, replicating the description (and indeed the service name) is really just about providing an easy way for the ACTION âproviderâ to have the key aspects of the original order without having to navigate complex queries, or where the original instruction is not actually available.
Thanks @siljelb and @ian.mcnicoll . We were exploring the âhiddenâ RM attributes today in @ian.mcnicoll âs openEHR Fellowship talk which I believe instruction_details falls into.
The example of the laboratory result is interesting as that is an Observation archetype with more explicit identifiers (i.e not derived from RM attributes).
Indeed - these identifiers are the Requester and Receiver Order Identifiers that also appear in the Service Request and Action archetypes, used for external identifiers âassigned by the systemâ not internal RM instruction_details.
It is not unusual to capture the lab results without any supporting INST/ACTION details, since the client is only really interested in the result, not in trackingthe process but in a full Order comms/lab report scenario you would want both, and in the Lab Report composition you might well have both the ACTION.service_request and the Lab OBSERVATION.
Agree many labs requests and results can be handled as a direct INSTRUCTION â OBSERVATION. The main role of an ACTION in this scenario in a clinical system is for the specimen collection and initial handling.
From what part of INSTRUCTION archetype do you typically set to ACTION.instruction_details? Is this a frontend workflow that needs to be implemented whereby you set ACTION.instruction_details from a certain element within INSTRUCTION archetype?
What archetyped identifier elements do these refer to?
Note you need to be careful with that because the path is not really an ID of an instance (single occurrence) of an ACTIVITY in the INSTRUCTION: the INSTRUCTION could have many ACTIVITIES at that path in a single COMPOSITION instance, and what you might want is to have an activity_id that is actually an identifier of a single ACTIVITY instance in the data.
Note I have an update in the description since I was talking about the instruction_id but the problem is in the activity_id definition (see at the bottom of the original description).
âThe issue is the INSTRUCTION_DETAILS.activity_id: String which is in fact an archetype path, because the INSTRUCTION_DETAILS.instruction_id: LOCATABLE_REF has the id field that allows to identify the INSTRUCTION instance without any problems and the LOCATABLE_REF.id is actually mandatory.
But to fully know the exact status we need to be able to reference one exact ACTIVITY within the INSTRUCTION, even if multiple ACTIVITY instances specified by the same C_OBJECT appear in an INSTRUCTION object.â
@ian.mcnicoll consider the case where an INSTRUCTION archetype defines an ACTIVITY at the activities[at0001] path, and ACTIVITY at0001 has occurrences = 0..*
Then your instruction details is ambiguous since the path can refer to either ACTIVITY. We actually need, at least, activity_id to be unique in the context of the INSTRUCTION.
What we currently use is the ACTIVITY data path, which is unique: /activities(0), /activities(1), etc. Though this is not a good solution if the CDR doesnât control the order o the items in a multiple attribute like activities. A more solid solution would be to use the ACTIVITY.uid in the activity_id.
On the other hand, that also requires that different instances of ACTIVITY[at0001] have different names. The spec allows multiple occurrences with the same name at that path in the data instance. If itâs allowed, then the current activity_id doesnât point to a single ACTIVITY instance, thatâs the main issue, currently itâs not an ID.
Also, I donât think the issue is in the AOM/ADL, itâs in the RM.
âactivity_id: Identifier of Activity within Instruction, in the form of its archetype path.â
What I understand as âarchetype pathâ is the path of a node in an archetype, and those donât contain dynamic predicates like dynamic paths used in AQL do. So the archetype path alone is referencing both ACTIVITIES inside the INSTRUCTION instance. (I mentioned that in the JIRA ticket).
