Merging and unmerging EHR Ids and their compositons

Hi everyone, has anyone any experience in merging and unmerging ehrIds, along with associated compositions, specifically into an EHRBase CDR?

I hope someone might be able to help with a problem we have encountered.

I have a source ehrId and a target ehrId, with the source being merged into the target. The compositions are then copied over, through a contribution, to the target ehrId.

I understand a reference to the source composition uid needs to be maintained, should it be required to unmerge. This reference is placed within the other_input_versions_uids element of the contribution. This is submitted successfully, and a contribution uid returned.

The submitted composition uid is also retrieved.

But when the composition itself is retrieved, there is no other_input_versions_uids element and no reference to the source composition uid.

I hope I’ve explained this adequently but if not please don’t hesitate to come back to me.

Any suggestions/experience/ideas would be very much appreciated.

Steve

I am not sure if this variant of merge-functionality is wide spread across all CDR implementation. It is not wrong, but I don’t know if this is a standard - if I am wrong please correct me with a reference.

We have in any case a different view and implementation: we ‘move’ compositions and contributions to the target EHR, reconstructing containment references. For later reference we use FOLDERs into target to keep track of merging info trails from the source; this way the original compositions and contributions remain as much as possible intact, and no need for new identification uid. We don’t have an ‘unmerge’ feature, but in theory you can merge content back to source.
I’m not saying this is best or better, just that is different then EHRbase.

Back to your questions about other_input_versions_uids, I guess when you retrieve the composition, it is not returning those references because they actually ‘sit’ in the contribution (so in the transaction envelope), not in the (composition-)content itself.

I’m commenting here without having experience with EHRbase though, so to know for sure, you better wait for a more official answer…
Hopefully this might be helpful to you.

Hi @steve.pillar there is no standard way of doing this in openEHR yet, though it’s a very common use case.

Having thinking a little bit about this in the past, there are many approaches, and I don’t think anyone is wrong. In my view there are three architectures:

  1. merging two EHRs into one of the two: one EHR with everything the other is deleted or inactivated
  2. merging two EHRs into a 3rd one: an EHR is created to act as a facade for the other two, no data is moved or copied
  3. all EHRs reference the same patient: just reference the same patient from many EHRs

Then there is the technique (mixed with the architectures above):

  1. Physical merging: moving or copying data between EHRs
  2. Logical merging: creating references instead of actually moving the data

In any case, having references instead of the data, makes querying more complex and less performing, though moving data might need storing extra metadata (for instance if you need to unmerge in the future) and the merge process might be longer.

Any approach is valid, but some might be better for certain use cases. In any case, there should be audit logs in place.

Please let us know how you end up implementing all this!

Hi Pablo,

I think the requirements and possible process is actually pretty well documented largely @thomas.beale , of course!

and AFAIK, Better have largely faithfully implemented that behind Admin merge//unmerge EHR rest API calls. They did encounter an issue with persistent compositions which required a spec change,so they have followed the spec at least in part @matijap ??

@sebastian.iancu - I’m pretty sure we are trying to retrieve the missing attributes at the right level i.e in the VERSIONED Composition wrapper which is committed via a Contribution.

My guess is that this ‘obscure’ part of the RM spec has just not been implemented in Ehrbase (yet) - @vidi42

I do think we should be adding Merge/Demerge as a formal Admin Rest API call

1 Like

Thanks for the reminder @ian.mcnicoll I totally forgot about that part in the specs. My memory is getting worst with the years!

Thanks Pablo,

The way we have approached it so far is:

Deactivate tne source ehr id, ie is_modifiable and is_queryable are both set to false.

The compositions of the source ehr id, if any, are copied over to the target ehr id, and then deleted, ie a logical delete with the composition’s lifecycle set to 523 deleted.

What I would like to have the option of, is to reverse/unmerge the above. That is, with any composition, I can see that it is the result of a merge, and where it had come from, ie the source composition uid, that I would then be able to update the lifecycle of and derive the ehr id etc.

It is maintaining a reference to the source compoisition that I haven’t worked out yet

1 Like

@pablo @ian.mcnicoll, I was also not sure anymore if we have that formally described - in any case I was speaking about the other type of merge=move that we implemented

1 Like

@sebastian.iancu in your implementation, after the move, is it possible to unmerge? If yes, what kind of metadata do you store in order to know how the unmerge should be done?

We don’t support ‘unmerge’, wasn’t required so far. An somehow alternative solution is to merge it again, but thins won’t be always what the end user may want.

From CDR perspective, persistent compositions are no different. We make no effort to prevent you having 2 of them in the same EHR as a result of a merge (or as a result of manual commit), which is suboptimal. :slight_smile: That’s why we introduced a notion of “singleton” templates. To my knowledge it has not been standardised yet, but it’s written in some SEC task, so it might be standardised eventually. If you try to merge 2 EHRs containing one such composition each, the merge will fail and you need to resolve that manually before making a merge…

There have been lengthy discussions in the past decade or even more about automatically merging persistent/singleton composition and I think it has been concluded every time that there is no safe way to do that…

1 Like