Duplicate patient records are a common occurrence in healthcare data.
FHIR attempts to address this by providing a detailed spec for how to implement the Patient $merge operation.
If you haven’t looked into this yet, it probably means your FHIR project is still early stage. There is simply no way to avoid duplicate patient records in real world scenarios.
Examples of why duplicate patient records might exist:
- Combining multiple datasets
- Emergency admissions, where patient details might be incomplete
- User error, name changes, misspellings, etc.
Support for advanced FHIR operations across the various FHIR server providers is weak. Users are often left to “roll their own”.
I have yet to find a server provider that supports /Patient/$merge out-of-the-box.
The $merge operation accepts two Patient resources:
- The Source — the old Patient about to be merged.
- The Target — the new or “primary” Patient resource.
The merge process updates the Patient.link element of both resources.
The Source Patient is given a Link.type of “replaced-by” and references the Target.
The Target Patient is given a Link.type of “replaces” and references the Source.
The Source Patient is then set to inactive. In some cases it may be deleted.
A “housekeeping” step is then performed to update all FHIR resources that reference the Source so that they now reference the Target Patient.
This process is asynchronous and may take some time, as years of data might need to be updated. During that time, results can be erratic and incomplete.
What to do after the merge in the event of a GET request involving the Source Patient is very much up to the FHIR server.
- Return the inactive Source Patient
- Return the Target Patient
- Return both
The FHIR documentation in this area is comprehensive, but does raise a lot of questions that need to be addressed during implementation.
A final word of caution. How /Patient/$merge is implemented is as much a business decision as it is a technical decision.
Don’t let your devs have free reign on this one!
---