Stream: implementers
Topic: patient merge
Radu Craioveanu (Apr 23 2018 at 16:27):
anyone have examples of implementation for merging Patients and then using the Merged Patient. In our case, we can have the same Patient enrolled under different IDs in the same organization, which need to be merged together once this duplicate patient has been identified. I see FHIR provides the option to use .Link but I am not sure how people are using that in real implementations. Or perhaps, there is just a copy of data from one patient record to the other, rather than just linking.
nicola (RIO/SS) (Apr 23 2018 at 17:53):
I'm very interested in this topic too. This is really tricky problem. We just think how to approach it. From one side - linking is good, but then you have to get all patient data by set of ids. If you copy from one patient to another - then potential unmerge will be nightmare.
Cooper Thompson (Apr 23 2018 at 20:00):
Are you asking about actually performing the merge/unmerge using FHIR? Or just representing the outcome of the merge using FHIR? The FHIR spec currently doesn't support doing a merge (or unmerge). Patient.link is only really the expression of a merge done via non-FHIR means. Selecting surviving vs. non-surviving demographics, identifiers, etc. can't really be done without an event/operation.
Our implementation represents two merged patients in FHIR by just returning an HTTP 301 sending you to the target patient if you try to access the source patient. Our resources that point to patient will all contain references to the target patient, but if any systems have old versions of resources with references to the source patient, that's fine, as they'll just get the 301 once they try to do reference resolution.
Grahame Grieve (Apr 23 2018 at 20:08):
we've never run this into the ground. There's a choice of ways to implement it, which more or less match the choices in v2. I'd like to have a connectathon stream on this, but we've never got enough energy for that
Kurt Ericson (Apr 24 2018 at 04:12):
@Cooper Thompson in your case, how are clients instructing the API to perform the merge/unmerge that generates the redirect? Or, is the merge request handled out-of-band and presented to clients as a 301?
Cooper Thompson (Apr 24 2018 at 11:59):
We are almost always going to be the EMPI for an organization, so we do not accept merge requests from API clients. In the case where there is a 3rd party EMPI, we can accept merge messages via HL7v2. We have not had a reason to implement a FHIR merge API with another EMPI, since HL7v2 serves perfectly well for that function.
Academically, it might be interesting to talk about merges originating from FHIR (non-EMPI) clients, but operational HIM departments are unlikely to be on board with merges coming from anything but the EMPI.
Simone Heckmann (Apr 24 2018 at 15:40):
I'm very interested in this topic too. This is really tricky problem. We just think how to approach it. From one side - linking is good, but then you have to get all patient data by set of ids. If you copy from one patient to another - then potential
unmergewill be nightmare.
Hm... you could create a Provenance Resource pointing to all the Resources you copied from one Patient to the other, to make it traceable/reversable. Though I agree that it's a nightmare considering that in some scenarios, this could be hundreds of Resources...
Grahame Grieve (Apr 24 2018 at 21:48):
@Cooper Thompson that's a short term view; one could well imagine HIM departments wanting their own 3rd party mergers. Clearly not where you are now, of course.
Grahame Grieve (Apr 24 2018 at 21:49):
alternatively, it would be very useful to be able to submit merge proposals from a client
Brian Postlethwaite (Mar 08 2019 at 02:49):
Hey all, The Patient Administration workgroup has on its worklist this year to investigate patient merge functionality and what that means in FHIR.
There is a project page setup for the discussion in confluence and we'd like to get the ball rolling.
https://confluence.hl7.org/display/PA/Patient+Merge+and+Link
While we are at it, this is a call for interest in participating in a potential experimental track at the May WGM in Montreal on the topic.
Click a reaction on this post if you would come and participate.
(and yes I did just like my own post, to say that I'll participate too)
Brian Postlethwaite (Mar 08 2019 at 02:55):
The agreed first stage of this project was to:
- document existing behaviors of existing products
- how this is exposed in the data
- what are the expectations of client applications
So if you have any feedback that you'd like to contribute to any of these 3 topics, please let us know!
Elliot Silver (Mar 08 2019 at 03:11):
@Brian Postlethwaite, IHE is working on a profile this year around some of those issues. The next IHE face-to-face meeting is in Chicago immediately before the Montreal WGM. It would be great if we can converge two efforts. @John Moehrke, @Luke Duncan, @Derek Ritz.
Brian Postlethwaite (Mar 08 2019 at 03:13):
Or at least feed the findings for sure! and expand on them... I'm not going to be able to attend the IHE meeting for pretty obvious reasons... :grinning:
Lloyd McKenzie (Mar 08 2019 at 03:30):
Will this include expected behavior of systems when querying patient data post-merge? And will it deal with the notion of "un-merge"?
Derek Ritz (Mar 08 2019 at 03:38):
@Lloyd McKenzie Hopefully yes to the former and likely not to the latter (or not in this cycle, anyway).
Derek Ritz (Mar 08 2019 at 03:51):
Very much agree it will be helpful to collaborate. @Elliot Silver Can we draw Daniel B into this conversation?
Elliot Silver (Mar 08 2019 at 03:54):
Sure, send him an email asking him to sign up to chat.fhir.org. And remind him that the HL7 WGM will be in his home town.
John Moehrke (Mar 08 2019 at 13:02):
Will this include expected behavior of systems when querying patient data post-merge? And will it deal with the notion of "un-merge"?
This is one critical requirement of the IHE work item. Where we can, we will be defining an actor grouping behavior: Given a data server actor is grouped with a merge notification recipient, when it receives a merge notification from the authority, then it will give post-merge results to future requests for data, so that a client of the data server always gets accurate data query results.
Benjamin Flessner (Mar 08 2019 at 21:10):
Redox is attending in Montreal and we have implemented a FHIR patient merge using a message bundle with code patient-link and two patient resources, as well as handling the ramifications of that merge in our server. Would love to share our experiences before, during, and/or after the Connectathon! We're also participating in v2-to-FHIR mapping which might be somewhat related, at least in comparing a v2 patient merge with a FHIR message bundle.
Grahame Grieve (Mar 13 2019 at 06:59):
I don't know if I have time to be part of this connectathon track in Montreal, but I'm presenting on this subject at DevDays and will be leaning heavily on the track for my content
Michele Mottini (Apr 29 2019 at 13:36):
So our system as an MPI, linking together patient records that are recognized to be the same person - this creates some questions on how best to render these linked patients in FHIR
One option is to render each of them separately, and adding the links in the link element - but this makes getting all the clinical data for that patient somewhat difficult
The other option is to merge them all together into a single FHIR resource - in this case though
1) It might be useful to know that different elements came from different liked patients (corresponding to different data sources)
2) What to do with conflicting data - like different birth dates?
What we tentatively come up with are some extensions, so if a merged patient has two different names coming from different sources we tag them:
"name": [
{
"extension": [
{
"extension": [
{
"url": "source",
"valueString": "RK.CareEvolution.Demo"
},
{
"url": "source",
"valueString": "PACode"
}
],
"url": "http://careevolution.com/fhirextensions#patient-sources"
}
],
"use": "official",
"family": [
"Demoski"
],
"given": [
"Stan"
]
},
{
"extension": [
{
"extension": [
{
"url": "source",
"valueString": "FHIR"
}
],
"url": "http://careevolution.com/fhirextensions#patient-sources"
}
],
"use": "official",
"family": [
"Graziani"
],
"given": [
"Tizio"
]
}
],
(Stan Demoski comes from RK.CareEvolution.Demo and PACode, Tizio Graziani comes from FHIR)
For conflicting data we do generate any values but we put all original values (and their sources) in extensions:
"_birthDate": {
"extension": [
{
"extension": [
{
"extension": [
{
"url": "value",
"valueDate": "2011-03-28"
}
],
"url": "source",
"valueString": "RK.CareEvolution.Demo"
},
{
"extension": [
{
"url": "value",
"valueDate": "2011-03-28"
}
],
"url": "source",
"valueString": "PACode"
},
{
"extension": [
{
"url": "value",
"valueDate": "1958-03-28"
}
],
"url": "source",
"valueString": "FHIR"
}
],
"url": "http://careevolution.com/fhirextensions#patient-sources"
}
]
},
```
Do anyone else have the same issue? How was it solved?
Is it worthwhile to standardize this (or a similar) extension system? Or maybe there is already something along those lines?
Yunwei Wang (Apr 29 2019 at 15:38):
Looks like you need to tag all the elements in Patient if values coming from different source: address, gender, contacts, ....
Then the combined Patient json is hard to read.
Michele Mottini (Apr 29 2019 at 15:41):
Yes,we are tagging everything - tagging element with the source is a 'nice to have' though, not strictly needed. What is (probably) needed is to be able to put the original values in the output when they conflict and the element supports only a single value - like in the case of different birthdates
René Spronk (Apr 30 2019 at 04:56):
A client of the MPI is probably best served by having access to one single consolidated record. A client is unlikely to look or understand these extensions. If you wish to keep track (internally within the MPI) where some bits of data cam from, that'd be Provenance. If the MPI can't be sure as to what the birth date is, then the consolidated Patient resource should indicate there is uncertainty, not list multiple dates. (Just adding the client perspective, these extensions are a bit too focused on the MPI side).
Michele Mottini (Apr 30 2019 at 13:04):
Thanks @René Spronk
If you wish to keep track (internally within the MPI) where some bits of data cam from, that'd be Provenance.
I can see how I could add multiple Provenance resources pointing to the merged Patient to describe where the data came from, but it does not seem possible to indicate which piece of data come from which Provenance ... am I wrong?
then the consolidated Patient resource should indicate there is uncertainty
How would you do that?
Lloyd McKenzie (Apr 30 2019 at 14:31):
@John Moehrke the Provenance resource should be indicating how to point to individual data elements within FHIR.
To flag something as uncertain you can put an extension on the relevant element. (e.g. within the 'birthDate' element if birthDate is uncertain).
Michele Mottini (Apr 30 2019 at 14:45):
To flag something as uncertain you can put an extension on the relevant element
OK - that's what we do now, with a custom extension that actually contains all the original values (ad abundantiam). Is there a 'more standard' way?
John Moehrke (Apr 30 2019 at 14:55):
John Moehrke the Provenance resource should be indicating how to point to individual data elements within FHIR.
To flag something as uncertain you can put an extension on the relevant element. (e.g. within the 'birthDate' element if birthDate is uncertain).
There is a CR asking for Provenance to express how to point at specific data elements. I have passed this to FHIR-I for their guidance on 'how'.
Lloyd McKenzie (Apr 30 2019 at 15:23):
@John Moehrke Can you link to the tracker?
John Moehrke (Apr 30 2019 at 16:27):
Michele Mottini (Apr 30 2019 at 16:32):
Thanks! (for easier navigation: the tracker references back to https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Source.20of.20information)
Gustav Vella (Jul 30 2020 at 11:39):
Hi, I've read through this thread, through the thread linked above and through this https://stackoverflow.com/questions/33450951/fhir-merge-patients .
Our client wants us to document the ADT/ACK - Merge Patient - Patient Identifier List (Event A40). We can chose how to do this.
What is the best practice? - is this a concern of the audit event, provenance or patient resource?
I'm also looking at this document: https://confluence.hl7.org/display/PA/Merge+Operation
- "Question: Provenance/AuditEvent actions - any security issues here?"
- "Answer: After some discussion, the Provenance is the preferred resource to track this content, as will likely remain with the clinical data retention, AuditEvents may be cleansed periodically. AuditEvents are not always available/exposed to all users."
Can I consider this as official guidance?
@Alexander Zautke for your info so we don't double post
John Moehrke (Jul 30 2020 at 12:18):
I am not sure if your whole question is the one on the distinction between Provenance and AuditEvent... but if that is it, then I would answer that is the supported by the definitions in the FHIR core specification for those two resources, and covered on the FHIR core specification security and privacy pages http://build.fhir.org/secpriv-module.html
John Moehrke (Jul 30 2020 at 12:19):
That said... those are statements of intended use, and expected use under expected policy. FHIR does not declare any restrictions to ANY policy or use-case. We simply design to a set of expected use-cases. So you can certainly use FHIR in ways not consistent with intended use or expected policies.
Yannick Börner (Jul 30 2020 at 13:02):
I don't think there is any best practice for documenting patient merges yet. Personally, I think the Provenance resource is best suited for this but one could also imagine a solution utilizing Messaging. I would advice against using AuditEvents as these are not always supposed to be available to normal users whereas the Provenance resource is.
John Moehrke (Jul 30 2020 at 13:15):
The changes one makes to a Patient (s) resource is a different topic than where to record why it was done (Provenance). There is an Implementation Guide from IHE that focuses on a Golden Patient domain. In this domain, which is a cooperative of many, there are one or more agents looking to detect failures that produced two Patient resources for the same single patient, and Merging. The changes done to the two Patient resources are defined. In that model only the deprecated Patient resource is changed. It is updated to point at the surviving Patient by way of its Patient.link with replaced-by; and it is marked as inactive in its Patient.active element. This following the guidance on the FHIR core Patient http://build.fhir.org/patient.html#dup-records.
AND all participants in the cooperative are informed of this merge with the expectation that THEY update their data, changing any data that references the deprecated Patient gets updated to point at the surviving Patient.
Thus it is not just the Patient resource that is engaged, but also all the data holders under the influence of that Patient identity domain (golden).
see https://wiki.ihe.net/index.php/Patient_Master_Identity_Registry_(PMIR)
John Moehrke (Jul 30 2020 at 13:17):
There are other models that would update both the deprecated and the surviving Patient to cross-link them; but this overhead didn't solve any problem, and it presented some synchronization issues. (Note one can always do a lookup given the Patient resource they have for any other Patients that have a link to it. This would find you all deprecated and thus merged former Patients)
Last updated: Apr 12 2022 at 19:14 UTC
