Reconciling a Duplicate Patient Registry Before an HIE Go-Live
A 12-clinic ambulatory network is 30 days from joining a regional health information exchange. The master patient index (MPI) contains 410,000 records. A vendor's probabilistic matching tool flags 9,800 candidate duplicate pairs at a 0.82 threshold. The governance council must decide how to resolve them before go-live. Two clinics use a legacy system that truncates surnames to 12 characters and stores date of birth as MM/YYYY only; the remaining ten clinics capture full names and full DOB. The council has one full-time data steward, no dedicated budget for manual review, and a policy that clinical safety incidents from misidentification must be reported to the board. The HIE contract requires a single enterprise identifier per patient at go-live.
1. The council wants to auto-merge all 9,800 pairs to meet the deadline. As the data steward, what is your recommendation and what evidence supports it?
Read the worked answer
Do not auto-merge at 0.82 across heterogeneous source systems. The two legacy clinics have systematically degraded match fields (truncated surname, partial DOB), so their pairs carry higher false-positive risk than the same score from the ten full-capture clinics. A blanket threshold treats unequal evidence as equal.
Recommendation:
- Stratify the queue by source-system pair. Pairs where both records come from full-capture clinics can be auto-merged above a higher threshold (e.g., 0.95) with audit sampling.
- Route all pairs involving a legacy-clinic record to human review, prioritized by clinical risk (active patients, recent encounters, orders in flight).
- Use a deterministic pre-pass on exact enterprise IDs, MRN plus full DOB plus sex, and exact full names to clear obvious matches cheaply.
- Defer low-risk legacy pairs (inactive patients, no encounters in 24 months) to post-go-live review with a documented exception, since the HIE requirement is one identifier per active patient.
The one steward plus no budget means the plan must be workload-bounded: deterministic pass first, then risk-ranked manual review, then a time-boxed exception list approved by the council and logged. Auto-merging everything converts a deadline problem into a patient-safety problem that the board will see.
2. A clinician reports that two records for the same patient were merged, and one record contained a penicillin allergy. What governance controls failed, and what corrective actions would you put in place?
Read the worked answer
This is a misidentification safety event, which triggers the board-reporting policy. The failure is not just the merge decision; it is the absence of safeguards around it.
Controls that failed:
- Merge criteria were applied uniformly without weighting source-system data quality.
- No pre-merge allergy/medication conflict check. A merge that combines an allergy onto a patient who lacked one should have halted for review.
- No unmerge capability or rollback plan tested before go-live.
- No post-merge audit sampling to catch false positives.
Corrective actions:
- Immediate: execute the documented unmerge, notify the affected clinician and patient per policy, and file the safety report.
- Add a conflict rule: any candidate merge where allergy, blood type, or sex conflicts must go to human review regardless of score.
- Require a reversible merge with full audit trail of field-level provenance.
- Stand up a data governance review board with clinical representation that owns match thresholds and reviews a monthly sample of merges.
- Track a false-positive rate metric and pause auto-merge if it exceeds an agreed tolerance.