Stream: v2 to FHIR
Topic: Conversion of same patient from multiple systems
Rik Smithies (Apr 01 2019 at 23:16):
What are good patterns for when there are multiple source systems feeding in to FHIR, and they are maintaining two slightly different versions of a patient? Say you are taking two lab feeds, and new records over time from both. There are PID segments in each, and they are judged to be the same patient (same identifier and other match fields) but with some slight differences. You can't keep updating the one FHIR patient as this might cause the demographics to continually flip-flop. For some fields you could do a merge e.g. keep both versions of their address in one FHIR resource. For other fields you cannot do this merge. Do you create two patient resources and make one the (arbitrary) active master and one the inactive one and link the two? This preserves the sources, when you cannot ascertain which one is actually correct (if either). This question lead on from Provenance one - you can at least say where each one came from and update the correct ones each time around.
René Spronk (Apr 02 2019 at 04:04):
REST is client side orchestration, so by default the answer will be the flip flop as described above.
In messaging the server gets to ignore the PID data from what it regards as 'less reliable PID sources' (apart from using the patient identifier for referencing purposes). This calls for server side logic, to allow a server to 'silently ignore' certain PID updates.
A RESTful server can't "silently ignore" an update. So either a RESTful server should reject Patient resources from less reliable sources (but: what would the error message for the rejection be?).
If you don't want to use a FHIR message, then this may require a custom server side operation, e.g. [base]$updatePatient. This would allow server side logic and the silently ignoring of certain updates.
Craig Newman (Apr 02 2019 at 12:06):
I'm not sure there is anything FHIR specific about this problem. I've seen it plenty of places that use v2 as well. Typically, I've seen systems flip-fop. Sometimes they only "trust" certain sources or they try and use PID-33 (last update date/time) to weed out "old" demographics (I don't see an equivalent to a last date/time in the FHIR Patient resource, but it could be tracked with an extension I suppose). PID-33 was part of several Meaningful Use specs in the US. I've also seen systems keep to separate records that are linked and then offer an "enterprise" amalgamated record is created to show end users. However, things like allergies, problems, med, etc that can be on both records are tough to reconcile. None of these solutions are particularly satisfying though.
Brian Postlethwaite (Apr 03 2019 at 11:59):
Meta.lastUpdated
Rik Smithies (Apr 03 2019 at 21:23):
I thought of lastUpdated too, but I think the data item might be "date of the record that this was created from". So if you know the data of some other input, you can determine if it is newer that your original source.
David Hay (Apr 05 2019 at 18:18):
REST is client side orchestration
But this sounds like Rik is still using a messaging paradigm, so the server can do what it wants (eg it could only accept Patient updates from a PAS)...
Last updated: Apr 12 2022 at 19:14 UTC
