CONTEXT:
For the use case medication administration I created a template which includes the archetype ACTION.medication.v1. This archetype includes an instruction state machine with a long list of states. Based on the requirements’ analysis (problem domain) we mapped the given states to available and suitable states in the ACTION archetype. Below you find two diagrams:
From the problem domain we want to map onto openEHR:
Using the Better Platform Sandbox and the REST API, I realized, that these states all have the same code, namely 245. And I already knew, that all these states are considered active states and thus similar. But I did not know, that we could not differentiate between them when persisting data onto the clinical data repository.
QUESTIONs:
Given the state diagram in the solution domain, how can a system persist the specified states, such that the respective state is updated accordingly.
Example scenario:
A medication administration has been created with the state “Medication prepared”.
Then it is updated from “Medication prepared” to “Medication reassessed”.
After adminsitration the data object representing the medication administration is then updated to “Dose administered”.
And how can a system know, which of the given four active states is actually persisted, as I am not able to differentiate between these four “245”.
care_step is mandatory in the RM but not careflow_step but in most circumstances, I would expect a careflow_step to be recorded as well , which I think is what you are after.
There is also an optional ‘transition’ attribute, which can capture the change in current_styate but I have no experience of use.
Thanks for pointing me to this thread, Silje. I understand your concern in this thread, and thanks to both of you, Silje and Ian, I am now able to provide better documentation for the implementers on how to instantiate the states and set guards for the transitions using the states in the ACTION.medication archetype.
As a thank you, I took a lot of effort in writing my response to the given thread, in which I distilled my knowledge from all the use cases I am currently handling. While writing my response in “Medication ACTION archetype - time to reassess,” I felt like I was back in language school in London, where I had to write a ton of essays on topics in philosophy.
Haha. I absolutely recognuse that tip-over point where we seem to have abandoned the safe zone of digital and entered the more esoteric world of philosophy. At least you have somecfirmal education in that world!
This made me think about a very related topic. Is there a preferred way to store the evolution of the ACTION state machine in the Compositions? I mean, there are two options:
To store a new version of the composition, so that the latest version always keeps the current ACTION state.
To store a new and independent composition for each change of the sate (which probably includes changes in the context of the event).
I think #1 is probably easier to manage and facilitates the retrieval of the evolution of the action, but #2 maybe is more formally correct since it keeps separated different events.
I think this depends on which of the different processes currently crammed into the same ACTION.medication archetype you’re using (see this topic for more about this problem):
Store a new version of the composition if you’re representing the ordering->maintenance->ceasing process. It’s super important to always have the latest state of an order.
Store a new and independent composition if you’re representing the administration or dispensing processes. Each step here is a separate action, carried out at separate points in time, and possibly by different people.
In our experience, there are good cases for both and I think you have delineated them pretty well as against the need to understand state vs recording events.
I think Better have increasingly moved to option 2, even for ‘stateful’ cases, as they have some AQL extensions that allow 'current_state/step to be easily retreived/derived, without the complexity normally involved when querying across multiple compositions.
We certainly use both, or at least discuss the strengths / weaknesses of each approach with clients.
@damoca : Context: For the use case medication administration I have finished the use case specification, which requires an active medication order, such that these medication administrations are linked to the respective medication order in the clinical data repository. The use case explicitly excludes the use case, where a medication is administered without any prior authorization - this will be specified in the upcoming weeks.
Implementation: I am now writing the implementation guide, where I specified the evolution of the ACTION state machine using the same object (equal to composition):
A user initializes a new medication administration object, where the default state is set to “Medication prepared”, as it is currently the case in our EHR. The link to the respective medication order is linked in the persisted medication administration object. The GUID of the object is “UID::domain::1”
A second user controls if the prepared medication fulfills the original medication order and if everything is fine, the second user updates the same medication administration object with a new state, namely “Medication reassessed”. The UID of the respective object
remains the same, but the version number is increased by 1, such that the updated object hast the following GUID: “UID::domain::2”.
Users are allowed to update the object back to the state “Medication prepared” in case some errors have been encountered after the human assessment. Or it can be updated to “Dose administration omitted”. This would result to the GUID: “UID::domain::3”
If point 3 is not the case, then the user documents the successful dose administration and the medication administration object is updated with the new state “Dose administered” and the GUID is now “UID::domain::3”.
If point 3 was the case and one reassessment has been performed, then after the documentation of the dose administration, the object will have the GUID “UID::domain::5” - the version number is higher if several reassessment have been performed.
To sum up, our specification follows your first option.
Context:
I am currently trying to update medication administrations using the ism_transition.careflow_step, but I am failing - miserably. For this purpose I am using the RESTful API endpoint specified by openehr:
where {{openEhrApiUrl}} is a placeholder, and the hash-value is simply the ehrID.
When I include the careflow_step in the request body, then I cannot store a composition. Without it, I have no issues. Consequently, I am initializing the careflow_step wrongly and need your assistance.
In the request body I initialize
ism_transition": {
"_type": "ISM_TRANSITION",
"current_state": {
"_type": "DV_CODED_TEXT",
"value": "active",
"defining_code": {
"_type": "CODE_PHRASE",
"terminology_id": {
"_type": "TERMINOLOGY_ID",
"value": "openehr"
},
"code_string": "245"
}
},
"careflow_step": { // when removing this part I can persist data
"_type": "DV_CODED_TEXT",
"value": "Medication prepared"
}
}
Question:
How shall the “careflow_step” be initialized with “Medication prepared”?
