The advice given in the COMMON spec. with regard to Disjoint Merges of persistent compositions is potentially problematic.
in the context of when a new EHR is created inadvertently, and requires a merge of any compositions created in the 'incorrect' EHR.
It essentially advises that a when merging persistent compositions, the most recent version found across the 2 EHRs should be regarded as the most accurate and that it be applied as an update to the 'correct' EHR .
We have become aware of a scenario where an unconscious patient has a new EHR inadvertently created and, for example, a new allergies list composition created where it is stated that the patient has 'no known allergies', based on the accurate but limited information available from relatives. However the original correct (and older) record in the 'correct' EHR may well have listed for example 'Allergic to penicillin'.
The current specification suggests that this older but actually accurate record should be overwritten by the 'No known allergies' version which is more recent. This could present a clear clinical safety issue and suggest that the specification be revised.
Thomas and I have discussed the problem and we are pretty sure that there is no predictable and safe solution to merging persistent compositions, that can be arrived at computationally but that in each case the merge will have to be performed manually at Entry level resulting in a reconciled composition, or at least a judged view on which version of the merge compositions should be regarded as the most recent, accurate understanding. This seems to equally apply to all kinds of persistent composition whether managed lists or 'single source of truth' documents such as End of Life wishes.
Our suggestion is that the text at https://specifications.openehr.org/releases/RM/latest/common.html#_version_merging Dishjoint merging should change to advise that merges of persisent compositions must be handled manually .
I agree with your analysis and conclusion.
I second Computationally merging compositions, whether or not they’re persistent, have been a thorn on my side in a number of cases and just like you, I always decided that I could not offer a safe algorithmic way to do it. Manual it is.
Manual is needed here. Great analysis.