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.
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:
merging two EHRs into one of the two: one EHR with everything the other is deleted or inactivated
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
all EHRs reference the same patient: just reference the same patient from many EHRs
Then there is the technique (mixed with the architectures above):
Physical merging: moving or copying data between EHRs
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!
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
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
@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
@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. 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ā¦
Yes, that was exactly the change that had to be made to the spec. The merge behaviour documented is safe for event compositions but cannot be guaranteed to be safe for persistent compositions.
Exactly, and the is_singleton template property we implemented is a āformalizationā of that claim: the merge fails if you have two such compositions.
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ā¦