Stream: patient administration WG
Topic: Patient Merge Connectathon Stream
Grahame Grieve (Jun 22 2019 at 20:29):
I spoke about patient merging at DevDays. At the end, I asked if anyone was interested in a stream around patient merging, and there was quite some interest (50+ hands up). Is anyone interested in planning and running a stream around patient merge?
For me, there's 2 parts of interest:
- how does the API deal with a patient merge that happened internally
- how does the API allow for a patient merge process
I think the 1st is more pressing than the second
Grahame Grieve (Jun 22 2019 at 20:34):
btw, during the presentation, I described 3 options for dealing with a request accessing a patient that has been been merged into another patient (eg. patient A merged into Patient B, and now GET [base]/Patient/A:
- return 200 ok with a patient record stating actice=false + link to B
- return 304 redirect to [base]/Patient/B (handled in HTTP client transparently to client)
- return 404 not found
I asked for a show of hands for which was safest - and got an even spread across options
Grahame Grieve (Jun 22 2019 at 20:35):
note I think the 304 redirect is mist unsafe since it's transparent to the client. btw, I asked how many implementations check that that the patient id in the returned resource matches the patient that was requested, and got only 1 implementation saying that they do that (Pascal)
John Moehrke (Jul 01 2019 at 15:02):
we also have interest in this from IHE perspective related to the PRIM profile. The management of Patient is not as hard as the management of all data (FHIR Resources) that reference the 'old' Patient. especially related to when those historic Resources are signed...
John Moehrke (Jul 02 2019 at 14:55):
it would be good to itemize the use-cases that distinguish Merge from a perfect world where no duplicates ever happen and identity provisioning is perfect the first time.
John Moehrke (Jul 02 2019 at 14:57):
what happens to Patient resource? What happens to other Resources that reference the Patient resource? Queries, Creates, Updates?
Brian Postlethwaite (Jul 02 2019 at 23:07):
Yes, those are all considerations for the connectathon.
Brian Postlethwaite (Jul 02 2019 at 23:08):
Did IHE try and test anything for what they wrote up, or just an initial strawman?
Cooper Thompson (Sep 14 2019 at 13:31):
Here is a webex we can use for screen sharing at the connectathon: https://epic.webex.com/epic/j.php?MTID=mdf6fe02c3cc03a5503d8d8e5a9e70636
Brian Postlethwaite (Sep 14 2019 at 13:32):
Hey all, this is the topic to follow for connectathon related Patient Merge functionality
Brian Postlethwaite (Sep 14 2019 at 13:32):
https://confluence.hl7.org/display/PA/Connectathon+Sept+2019+at+WGM+%28Atlanta%29+Patient+%24Merge
Cooper Thompson (Sep 14 2019 at 13:34):
Here is a webex we can use for the merge connectathon: https://epic.webex.com/epic/j.php?MTID=mdf6fe02c3cc03a5503d8d8e5a9e70636
Brian Postlethwaite (Sep 14 2019 at 20:58):
I have a very draft version up on here:
http://sqlonfhir-r4.azurewebsites.net/fhir/
Currently is only performing the changes to the Patient resources (and validating all the parameters)
next for me will be processing all the referenced content.
Brian Postlethwaite (Sep 15 2019 at 13:57):
@John Moehrke got a tic to talk turkey, I mean provenance for the Patient Merge?
We're trying to decide what is in it.
Jenni Syed (Sep 15 2019 at 15:16):
@Brian Postlethwaite looking at the Merge Operation - how does the server know who to send messages to about the merge? The subscription approach is nice because apps that care (or servers that care) can formally request notification
Jenni Syed (Sep 15 2019 at 15:17):
IE: we have some apps that don't care about merges because they don't store data (actually the majority right now)
Jenni Syed (Sep 15 2019 at 15:17):
But we have a few that do have separate stores and need to get the data updated
John Moehrke (Sep 15 2019 at 15:18):
on that topic... have you seen the subscription for patient updates including merge that are in the IHE PRIM profile?
Brian Postlethwaite (Sep 15 2019 at 15:20):
The operation is the explicit action to kick off the whole thing, how that ripples onto other systems isn't specifically covered at this stage, but have covered a little on what could occur from a messaging standpoint - but really drafty.
https://confluence.hl7.org/pages/viewpage.action?pageId=58657695#MergeOperation-NotificationMechanisms
Jenni Syed (Sep 15 2019 at 15:20):
@John Moehrke No, but we've had some issues with Subscriptions in pre-R5 draft as well (the Topic breakout work is helping resolve some problems). Link?
Jenni Syed (Sep 15 2019 at 15:41):
I get the impression that this is going to be a place where the subscription profile will need to be able to handle many different scenarios, so long as an app or server will get notified
Jenni Syed (Sep 15 2019 at 15:42):
IE: it will point to a topic definition that allows for many scenarios, but the end result is the same
John Moehrke (Sep 15 2019 at 15:56):
unfortunately the work is still open.. and awaiting the merge work here at HL7. It is in this github https://github.com/IHE/IT-Infrastructure/tree/master/PRIM
John Moehrke (Sep 15 2019 at 16:43):
Provenance.activity could be drawn from the EHR lifecycle events where there is a merge activity http://build.fhir.org/valueset-object-lifecycle-events.html
John Moehrke (Sep 15 2019 at 16:44):
I have a CP to fix the existing Provenance.actiity valueset that is not complete
Brian Postlethwaite (Sep 15 2019 at 20:39):
https://1drv.ms/p/s!ApkGK_oT9urNvYVm4A3KnKVlnAnxaA
Brian Postlethwaite (Sep 24 2019 at 04:35):
Question to the group on References to Patient with a version on them, such as those found in AuditEvents.
What do we do with those?
I think they have to remain untouched right?
Can't exactly move them over, as that version number is specific to the old value.
Think might be worth including them in a log though.
@John Moehrke thoughts?
Brian Postlethwaite (Sep 24 2019 at 04:47):
Also, anyone have any comments on what should happen if the reference exists in an extension somewhere? should that be updated too?
(Assuming the answer yes) My server would have no idea what to do with this.
Internally I'm iterating over all the resource types, and search parameters that target the source patient , and then updating them as they are found.
This means that as long as there is a search parameter on Patient for all the usage, then they will be all covered.
@Cooper Thompson @Jenni Syed @Grahame Grieve thoughts?
Grahame Grieve (Sep 24 2019 at 12:20):
Those questions are a challenge for me. I’d search for resources by the search parameters, but I’d scan them by element, not search parameter. But... I don’t have time to scan every resource on file. So search parameters are the thing. But... what about DocumentReference where one of the references shouldn’t be fixed?
John Moehrke (Sep 24 2019 at 13:08):
Good question that I am not sure how much thought has gone into it. These hard questions are the bit I expect to keep popping up. I would expect that the historic versions of any resource would be not-touched, thus historic linkages are still historically correct. It is just the current and future versions that have the identity updated because of the merge operation. Right?
Thus, when a query is done on non-version id; it will get the current and thus correct value. Where as pulling a version specific will get that specific. right?
John Moehrke (Sep 24 2019 at 13:09):
as to extensions that are of type Reference... this might be detectable even if the extension is not understoood? This seems dangerous. Might be best for us to identify that extensions that are (or have within) References are an open issue.
John Moehrke (Sep 24 2019 at 13:13):
Are we looking for general guidance that an element of type Reference that holds a version specific reference would NOT be changed by a merge operation? That seems on the face to be safe, so what are the cases when it is not? If not that kind of a behaviour of the merge, what kind of damage can a more aggressive merge cause? Seems aggressive merge could do quite a bit of unintended damage. I think it is best that we itemize these so that we can come to a conclusion. seems to me that if a version specific reference was used, it was used for good reason; however might there be egregious use of version specific references when unversioned should be used?
John Moehrke (Sep 24 2019 at 15:20):
Those questions are a challenge for me. I’d search for resources by the search parameters, but I’d scan them by element, not search parameter. But... I don’t have time to scan every resource on file. So search parameters are the thing. But... what about DocumentReference where one of the references shouldn’t be fixed?
This is a good example. Even in XDS when merge is done in a XDS Registry, only the active Patient ID is updated in the Registry. Any "sourcePatientInfo" is left exactly as it was initially published. This concept of sourcePatientInfo is specifically intended to be exactly what the patient was at the time of publication. In the binding of XDS to FHIR in MHD; the concept of sourcePatientInfo is mandated as a contained Patient. This is how this behavior is maintained in FHIR.
John Moehrke (Sep 24 2019 at 15:22):
which brings up the question about merge on if it is expected that the merge will update any Patient.id found in contained? I would think it should not expect a merge operation to affect contained Patient. But should it? What about all other resource types that are in contained? might those also be behind the visitiblity of the merge action?
Brian Postlethwaite (Sep 24 2019 at 21:19):
The 2 that really get me are provenance and verificationresult.
I kinda think a new verificationresult would be in order, however all the other provenances that contributed to the patient record are now no longer locatable for the patient. This seems wrong.
My merge provenance resource records a warning for each versioned reference it encounters. And doesn't touch the merge provenance records.
I still need to process the patient resource more carefully to catch other patient resources that link to the source that aren't involved in the merge.
John Moehrke (Sep 25 2019 at 06:33):
The older Provenance would be findable if you noticed the one Provenance indicating the merge... In theory the deprecated Patient no-longer exists, and thus all the old versions of that deprecated Patient would too no-longer exist. Where the definition of no-longer exist is dependent on the policy. If that policy is to truly purge, then both the Patient and Provenance (all versions) would also get purged. So, I am not clear what the problem is. Similar for VerificationResult, why would these matter anymore for the deprecated Patient; they clearly were improper Verification Results... as they were verifying the thing that ultimately was deemed to be duplicate and to be deprecated...
Brian Postlethwaite (Sep 25 2019 at 06:46):
You're right. My new provenance needs to point to it, so concern alleviated (of sorts)
Brian Postlethwaite (Sep 25 2019 at 06:48):
The VerificationResult however I would think that would want to initiate a new verification process on the freshly merged record, as the previous verification is now stale/irrelevant.
Think I'll add it to my info messages.
John Moehrke (Oct 03 2019 at 11:45):
New twist brought up in IHE discussions on Patient Merge and affect in an HIE... Given that the patient can be an author, and other kinds of participants... When merging one must look everywhere the deprecated Patient exists and fix them up too. So the actions of a merge is not limited to .subject and .patient elements.
Grahame Grieve (Oct 03 2019 at 19:41):
no. and any real system will have patient information outside the scope of FHIR too. Even minimally, there's potentially multiple user accounts
Brian Postlethwaite (Oct 03 2019 at 20:48):
Correct. My POC reads every resource and any search parameter to patient it resolves. But this misses any extensions that aren't in search parameters.
Only way around it is to scan everything in the way in and tag a special search parameter patient-for-merge
descendants.ofType(ResourceReference).resolve().ofType(Patient)
I know probably wrong and expensive but that gives the idea.
Brian Postlethwaite (Oct 03 2019 at 20:49):
@John Moehrke I thought we'd already mentioned it. We will be more explicit though.
René Spronk (Oct 13 2019 at 06:05):
So what happened to the idea of support a HTTP redirect? This would at least help if one should fail to update some of the references..
John Moehrke (Oct 13 2019 at 21:33):
Not sure what happened... but there was concern that an http redirect might not be noticed as "you have something wrong that needs to be fixed". But I don't think we forbid it, I think we just thought that it was more dangerous than helpful.
Brian Postlethwaite (Oct 13 2019 at 22:00):
And also consistency in approach, that only works when you are directly requesting that specific resource, so it doesn't work with searching, or includes. I thought we added those notes into the discussion in the page. Will ensure it's documented in there.
Brian Postlethwaite (Oct 16 2019 at 19:04):
Conference call on now for the Merge if folks want join!
Reinhard Egelkraut (Jan 10 2020 at 14:48):
Hi @Brian Postlethwaite ,
Is there going to be a Patient Merge track again at the Connectathon in Sydney?
If yes, I would be interested to participate.
Brian Postlethwaite (Jan 10 2020 at 22:52):
Wasn't planning on doing it, though could present some progress to others might be an idea.
Last updated: Apr 12 2022 at 19:14 UTC
