We are looking into using attestations to record patient approval and approval by a senior clinician of a care plan.
The patient or senior clinician should be able to approve the care plan themselves. But it should also be possible for another clinician to register the approval of the client/senior clinician.
We are wondering how to record in openEHR both the party that approved the care plan and the party that recorded that approval.
For compositions there is a clear distinction between the committer and the composer. We would like to do something similar.
An idea we had was saving the approving party as the committer of the attestation and saving the recording party as the committer of the linked contribution.
Is this a right solution or do you have any other ideas?
In the current RM, attestations just record the fact of some party having âattestedâ to the content of what is in the Version object (usually a Composition or some part of one). There is no field to record that the identity of the data enterer of the attestation.
I would suggest that âapprovalsâ (patient and clinical approval are different things) could be recorded in Composition.context.participations.
We are actually looking at exactly the same issue as part of the One-London project, which involves migrating an existing Care planning solution which has exactly that type of approval/endorsement process. We are still working through the best approach but I suspect simple attestation is not sufficient, especially if you need to mange the workflow of the process.
Current thinking is to use INSTRUCTION.service and ACTION.service to mage the process and âsignaturesâ. We have done something similar on different project (which also had to include handling someone signing âon behalf ofâ the approver.
Hi @ian.mcnicoll, just discussed with @Jelte. And we want to go the same way. Attestations by proxy/delegation seems too complex for now. For the patients approval I think action.consent is the best fit. But Iâm not sure about the senior clinician. I see you used action.service. The concept is sufficiently broad to allow it âDescription
A general clinical activity carried out for the patient to receive a specified service, advice or care from an expert healthcare provider.â But Iâm hoping we can do better. I think itâs a regular usecase for care plans, so Iâd like to align.
@thomas.beale the context.participation has a function and a performer which are a role and a person. You could record function = approver and person = dr. Beale. But that leaves it ambiguous wether the person actually approves, or is the one who should approve (some day).
Another issue with using composition.context is it has event semantic including a mandatory start_time. While a plan is not about an event perse. see my issue: [SPECRM-106] - openEHR JIRA
The way the main RM should be understood is that if something is recorded in the data, it is something that is true / occurred. So your example would mean that Dr Beale did approve of the xyz and on date/time abc.
Composition.context really is about ⊠context of the main content.
The whole concept of âplansâ is a whole other model (Task Planning). What can be done with the RM is Instructions to represent orders for things to be done, which is a kind of planning, but doesnât have the flexibility of Task Planning. We need to analyse this use case a bit better IMO.
Iâm eager to analyse this use case a bit better. What information would we need? I could provide screenshots of the UI? (Maybe in private)
Re the recorded implies itâs true/occurred and the approved. The way I would understand recording an approved at a given time, is that there exist someone who is the approver, not the status of the approval itself, that could still be many things: âpartially approved, disapproved, not yet approve etcâ. Itâs subtle. Second problem with this is itâs part of the composition not of a version of the composition, so if an approval would be recorded of a composition, that version of the composition would change, (strange initiĂ«le maybe). Moreover if the composition changes and a new version is recorded, the approval should not automatically be extended to the new version. With composition.context it does. (Or there should be special logic somewhere, a bit ugly).
So we intend to record the approval action archetypes in a different composition that refers to a version of the care plan composition.
All true - but the current RM doesnât model at this level. These kinds of things are (as you know) modelled by lifecycle state machines (like the ones for Instructions, and Task Plan tasks). If we thought we needed such stateful and detailed approval and other clinical governance actions, we would need to a) define the state machines and b) add new attributes to the appropriate places to capture the current state of any approval etc, and c) add to current software to implement the various state machines.
This is all doable, and indeed, maybe it is what we should be doing. This kind of clinical governance doesnât really want to be in archetypes (I donât think) - better if you get it for free, and as long as the state machines are flexible, different lifecycles for different locations can be accommodated.
