Metadata in REST resources

Implementation Platform
1

While working with EHR and patient (PERSON/ROLE) merge processes I have found the current resources based on the RM a little restrictive.

While we can have versioning info embedded in the LOCATABLE.uid, there is no native way to add extra metadata to EHRs or PERSONs retrieved by the REST API via GET or via a query.

In FHIR for instance, there is a “meta” element in all resources that allows to provide extra information, about the resource, to the APIs client.

I found that to be useful for giving the client info about merge operations that have been applied to an EHR or a PERSON. For instance, let’s say that EHR A was merged into EHR B, and a client does a GET for EHR A. Depending on the implementation it might return EHR A or EHR B, since B is the resulting “active” record, though in logical merges, EHR A might still be accessible via the API. So to consider all possible cases, it would be useful to have an extra “meta” area to tell the client: “I give you EHR A, though note that was merged into EHR B” (as structured data of course). Without that extra piece of information, the client might not know about the merge at all.

In our Atomik implementation we are still doing that, though it’s our of spec.

I would like to know if others have a similar problem and how did you resolve that.

A second question would be if anyone else feels that kind of thing is actually worth to be formalized and added to the REST spec and ITS schemas.

Thanks!
Pablo.

2

Discussing this with colleagues, I got another idea: we can use/extend the current versioning system to deal with merge-related transactions.

For context: we are working in a completely openEHR Master Patient Index, so we need to deal with patient matching, linking, merging, unmerging, etc.

Those transactions in the MPI have consequences in the EHR: if a patient is merged into another, the EHR of that patient might need to be merged into the other patient’s EHR too.

Now we are doing some things inside spec and some outside spec.

Right now the openEHR demographic records don’t know about the merge, though I’m thinking of including merge information at the VERSION/AUDIT_DETAILS level.

Currently (Support Terminology specification) we have these types:

  • creation
  • amendment
  • modification
  • synthesis
  • deleted
  • attestation
  • restoration
  • format conversion
  • unknown

For merge operations support, I would propose to also add these:

  • merge
  • unmerge (because undoing is also a possibility)

I would like to know what others thing about this before proposing the addition to the specs.