Storing and reading attestations

Specifications RM
1

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.?
2 Likes
2

I think this in not implemented very much. So I’m not surprised. @MattijsK may have some experience from Nedap.

I do feel it’s the right solution for the right problem though. Apparently it’s not been urgent (or much harder to implement than I expect)

1 Like
3

Hey,

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.

1 Like
4

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:

  1. Manage the secret within local users (we have local user management for small deployments like secondary repositories or for analytics/reporting.
  2. 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.

Best,
Pablo.

1 Like