Patient deduplication is a tough problem, and there are many approaches to implementing a deduplication program. We provide this guide and sample code as a resource to teams who want to run a continuous deduplication program that is powered by automation and highly auditable.
There are three elements that we see playing a big role in deduplication:
- New patients evaluated for duplication at time of creation (event driven)
- Disciplined maintenance of identifiers from different systems
- Maintaining your de-duplication policy as code
Here is a 5 minute tutorial video on deduplication that summarizes the content of this post.
Event Driven Deduplication
In Medplum, by hooking a Subscription to the Patient resource, you can subscribe to the creation of new Patient. This is powerful because it allows you to check each new patient against the existing patient base and flag duplicates in real time.
We suggest making a Bot that listens for new patients and every time a new patient is created evaluation whether they can be merged with an existing patient, creating a duplication risk score or flagging for manual review.
A sample (skeleton) deduplication bot can be found in the Medplum Demo Bot repository.
Many systems issue patient identifiers, like payors (e.g. United Healthcare), pharmacy and medication systems (e.g. Surescripts or DoseSpot) and even payment providers like Stripe. FHIR support maintaining multiple identifiers from different systems. If you maintain records with patient identifiers from different systems, this can be the basis for detecting duplicates with high accuracy.
The sample deduplication bot test shows a patient with multiple identifiers for reference.
Policy as Code
The stakes are high for deduplication. A false merge can cause treatment errors, incorrect data disclosure and more. Having an auditable policy as code, test coverage, source control and a system with robust audit history is an excellent tool for having that high fidelity deduplication process that is required for great patient care.