Stream: implementers
Topic: Would Patient/{id}/$everything traverse linked patients?
John Silva (Jul 27 2021 at 15:18):
Would the Patient/$everything operation be expected to traverse patients in the link.other.reference? (Assuming link.other type=replaced-by is using in patient merging scenarios). It would seem, e.g. in a case where there is a STAT patient (A) that is later discovered to be patient (B), that this would be used and the patient's "full data" would exist in both FHIR Patients. Or, would it be the responsibility of the FHIR client (user) to perform multiple Patient/{id}/$everything retrievals?
Lloyd McKenzie (Jul 27 2021 at 15:25):
My guess is it would be up to the server. If you think the operation should mandate something (or clarify that behavior might be variable), feel free to submit a change request.
John Silva (Jul 28 2021 at 01:06):
Well, "up to the server" isn't the answer I was expecting but you've essentially answered my question, "it's not currently specified in the FHIR $everything spec page".
I would have thought that it should be more precisely specified. Maybe this is a non-standard use case but it seems like when Patients are merged the FHIR way of. handling this is to use the link.other property with type=replaced. Of course link.other could also be used for linking a mother's record to her children's records, which in that case it wouldn't necessarily make sense to export as part of $everything since those other Patient resources are for 'different Persons'.
[I suppose submitting a change request would allow the Patient Management group to at least discuss this and maybe come up with some recommendations.]
Gino Canessa (Jul 28 2021 at 16:41):
That is certainly a way of handling a patient merge. To my knowledge, there is no 'official' way of handling merge yet - I believe there is a project specifically focused on defining Patient Merge, but I am only vaguely aware of it. It could even be complete? But I don't remember seeing a publication in ballot.
Generally speaking, having more than one ID for a patient is problematic (again, without going into can/should/why/when/etc.). For example, if you authorize a SMART app scoped to patient/1, does the authorization server know that it also needs patient/2? If so, which one is the current context for searches, etc.? Until there is a good standard process for merging, I don't think it's possible/realistic to define what every behavior should be.
In this case, the everything operation is clear about what the intentions are ("provide a patient with access to their entire record"), and a server implementing the operation should be trying to do that. It is also clear on what 'minimum' implementation should be ("the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user").
If I were writing a server that did merges in the way described, I would include linked patients. If I were writing a client that uses this operation, I would check the patient record and make additional requests if needed (e.g., if the patient has a 'replaced' link and does not contain that patient resource, run the operation on that patient).
It's a tough area that, to my knowledge (which is admittedly limited =), isn't yet well-defined. In lieu of that, "leaving it up to the server" means that implementers have the flexibility they need to ensure they can have a correct implementation. The unfortunate tradeoff is that clients have less of a guarantee.
Brian Postlethwaite (Aug 24 2021 at 21:49):
The patient merge functionality is documented here https://confluence.hl7.org/display/PA/Merge+Operation
and will be moved into the R5 spec (as soon as I can get around to it)
Elliot Silver (Aug 24 2021 at 23:05):
@Brian Postlethwaite , on that page, it says that all references to the source patient need to be updated to the target patient. Is this just for patient/subject elements or anywhere a reference to a patient can occur? What about Reference (Any) elements? Patient references embedded in stored Bundles? or in DocumentReference content or Binary? Is the process expected to work if either the source or target Patient reference uses an identifier instead of a url? Is there a requirement that the base url for both source and target patients is the same?
John Silva (Aug 25 2021 at 15:39):
@Brian Postlethwaite -- that Merge page 'spec in progress' looks eerily like the way it was described in HL7v2 (of course though with FHIR and RESTful mechanisms not messaging); which makes sense because it's trying to solve the same problem.
But back to my original question, I guess the responsibility would be on the FHIR Client to perform additional $everything operations if the linked patient data is not returned. I suppose the bigger problem with 2 patient (internal/FHIR) ids is what Gino mentioned. In the 'old days' the MPI I believe tried to mediate these types of issues (with, I'm sure, a bunch of code to effect the desired behavior). Maybe a FHIR Facade that has the MPI "in between" the FHIR (data store) Server could be used to handle some of these issues (subscriptions, patient access, etc.)
Last updated: Apr 12 2022 at 19:14 UTC
