We want healthcare personnel to be able to sign reports, approve prescriptions or acknowledge laboratory results. Attestations seem to us to be a suitable way of recording this signing ( Common Information Model ; Common Information Model ).
However, despite many attempts, we have not been able to save objects of the ORIGINAL_VERSION class with ‘attestations’ properties and then read these attestations (tried against EHRBase and Better EHR).
Our questions:
Are any of you successfully using attestations?
If so, could you post some successful REST request examples?
If not, how do you save the signing of reports, the approval of prescriptions, the acknowledgement of laboratory results, etc.?
Yeah, we did implement openEHR attestations in our CDR at some point. But we are currently not using them. We noticed that the specified attestations were not fully covering all of our use cases. One of them being the option of “approving on behalf of someone else”, so a case where the user is not the approver.
We are now simply using custom archetypes for signing/approving, which are then linked to the compositions that they apply to.
In Atomik (https://atomik.app/) we support attestations. When committing them using the POST /composition service, extra headers are needed to send the information required to build the Attestation object.
With POST /contribution, it can go inside the payload.
This considers the signing process is done on the client side, though we are working on the signing and signature verification services to be able to commit the minimal information and let Atomik server to generate the signature proof. This will have two options, since you need to manage the secrets (private key) somewhere:
Manage the secret within local users (we have local user management for small deployments like secondary repositories or for analytics/reporting.
Manage the secret with an electronic wallet (blockchain, etc) we have an external provider for this.
Note we don’t impose any rules on who should sign the documents, it can be the composer, a participant, or even a party that is neither, though that has to exist in the demographic repository (Atomik supports EHR and demographics in the same repo), so any of those use cases you mention can be implemented.
Though I can provide a request, I can’t assure that will work on EHRBase or Better, I don’t know how they implemented attestations.
Thank you for your reply. Building a custom archetype could really be the (fallback) solution.
Even if attestations do not directly support “approving on behalf of,” this could be provided by the openPGP standard, which is used for the content of “attestation.proof.” I have read (but not yet used) that openPGP provides signature subpackets that could be used for signatures “on behalf of …”. Or – more cumbersome but cryptographically verifiable – that one person delegates their signature to another person via openPGP. “Attestation.proof” could then contain the entire chain of delegation from person A to person B with subsequent signature by person B.
Thank you for your reply. As our customers currently use EHRBase or Better EHR, Atomik is unfortunately not an option for us at the moment. But maybe in the future?
Do you have a conformance overview of Atomik with regard to the openEHR specification (in the sense of the FHIR CapabilityStatement)?
Hi @emmanuel.eschmann , no worries, I mentioned Atomik just to show how one implementation works.
I have worked in openEHR conformance extensively, in fact it started with my work at HiGHmed to make EHRBase compliant with openEHR (before we worked on it there was a gap between its implementation and the openEHR specs).
There I stated very clearly that openEHR needs a formal Conformance Statement document, like the industry standard DICOM CS, and proposed a processable format, which is like a Capability Statement.
Though I want to generate the processable one ASAP, I think that will be done after we deliver some projects to a client. I can give you more details. Feel free to DM me.