Stream: implementers
Topic: When patients are linked
John Moehrke (Nov 14 2018 at 21:47):
What is the expectation upon a query results (e.g. query on Observations) when the query includes a Patient resource, when that Patient is linked to another Patient resource (previously duplicate Patient resources)? There is mention in the compartment definition for Patient, that indicates that a Compartment on Patient that is linked results in the combination of both. http://build.fhir.org/compartmentdefinition-patient.html
Is this same (same as compartment) expected of more normal query parameter 'patient' or 'subject'? Where is this clarified?
Grahame Grieve (Nov 15 2018 at 02:20):
it's not clarified, and would be a good connectathon subject for the patient stream , I think.
John Moehrke (Nov 15 2018 at 16:52):
seems like the FHIR federation is a peek at this.
Michele Mottini (Nov 15 2018 at 17:12):
The way I read the specs is that a Patient Compartment does _not_ combine Patient that are linked :
Michele Mottini (Nov 15 2018 at 17:13):
' all the records associated with the linked patient are in the compartment associated with the target of the link' - i.e. the records associated with the linked patient are in a _different_ compartment
Michele Mottini (Nov 15 2018 at 17:14):
I vaguely remember asking this same question a long time ago (I think as a comment to the spec page), and that the answer was that Compartment is like a normal search: does not combine related Patients
John Moehrke (Nov 15 2018 at 17:41):
I read the text on the compartment for Patient to express that I get the combined results of all linked Patients. Thus one compartment is equivalent to another when the two are linked. So this text must be a confusing text: " When a patient is linked to another patient, all the records associated with the linked patient are in the compartment associated with the target of the link."
John Moehrke (Nov 15 2018 at 17:43):
which I figured was unreasonable magic... but I am happy if this is the understanding of the results a search on a Patient identity that has links to other Patient identity.
John Moehrke (Nov 15 2018 at 17:44):
The alternative, which I figured is more possible, is that EVERYONE doing a query of a Patient, must do equivilant queries on ALL of the links to that Patient in order to get the whole patient record.
Grahame Grieve (Nov 16 2018 at 06:57):
I think that text needs some work - linked how?
John Moehrke (Nov 16 2018 at 18:49):
clearly... magic... Yes, if the text is not intended to imply magic, then it should not be said. Yet, the linked Patient data problem needs signficant work. That is the problem of what happens to the data when there are data recorded against two different Patient resources, after those two Patient resources are found to be the same patient and thus linked... It would be nice to move the work to the server, and not expect every application to recognize a Patient has been linked (as in link/unlink/merge).
John Moehrke (Nov 21 2018 at 18:19):
I have created GF#19687 so that this can be a discussion for R5
Veliyan Georgiev (Nov 27 2018 at 13:10):
Here is my observation: We have Cerner and Epic and an MPI on top of it. I tried few queries in the EMRs with different MRNs for the same patient and I got the same record. From what I can see - both Epic and Cerner listen and handle merges pretty well so in essence they handle the cross linking logic themselves without the client knowing. Now, having said that - I believe in FHIR this would equal to all patient instances having all identifiers in them but it is clear that the expectation is that it “just works” from what I can see.
John Moehrke (Nov 27 2018 at 17:57):
I suspect there will be different behavior when the backend is a FHIR Server vs when the backend is a non-FHIR EHR. In an EHR it is common for linking to be recognized as logically the same thing. There is no problem with 'fixing up' old .patient or .subject elements. However in a FHIR Server this may not be true or possible.
Brian Postlethwaite (Nov 27 2018 at 20:49):
Yes, in the back the servers may be rewiring the subject patient properties. Also what would be expected where the link reference is external to another or old system?
With the strength of audit/provenance could unlink easier than before.
John Moehrke (Nov 27 2018 at 20:53):
yes it is possible to do the fixup in a revision, mark that revision with Provenance as to why, and sign the Provenance proof of before and after to show integrity. complex, but possible.
Brian Postlethwaite (Dec 03 2018 at 09:55):
I thought a single merge audit that version referenced all the stuff that was merged in a single record, that could the do a roll back of all those...
Brian Postlethwaite (Dec 03 2018 at 09:55):
But yes, still not simple.
John Moehrke (Dec 03 2018 at 14:49):
How to indicate a link is less confusing then how a client app needs to behave (actions and expectations) when the patient has links... I suspect reality is that client apps must be very aware of patient links. I am not sure that server side fixup of .patient/subject is sufficient given the proliferation of records with old patient id; especially in a distributed network.
Brian Postlethwaite (Dec 03 2018 at 21:49):
Yes, especially in a distributed network.
John Moehrke (Dec 03 2018 at 22:46):
distributed ledger technology...
Last updated: Apr 12 2022 at 19:14 UTC
