The Interface That Lied
A hospital's ADT interface from a newly acquired outpatient clinic sends demographic and visit data to the enterprise EHR via an HL7 v2 feed. Two weeks after go-live, the data governance team finds that 6% of records have mismatched patient identifiers: the same patient exists under two MRNs, one from the clinic and one from the hospital. The interface uses a local patient ID and maps to the enterprise master patient index (MPI) by exact match on last name, first name, and date of birth. There is no enterprise-wide EMPI; each facility maintains its own MPI. A recent safety event involved a medication ordered on the wrong record because a hyphenated surname was truncated at 20 characters in the sending system. The vendor says the fix is 'a mapping table.' The CMIO asks whether to build a point-to-point mapping or invest in an enterprise EMPI.
1. Evaluate the vendor's 'mapping table' proposal against the enterprise EMPI option. What are the trade-offs and what would you recommend?
Read the worked answer
A mapping table is a point-to-point fix that does not solve the underlying identity problem. It can resolve the known duplicates but will not prevent new ones, and it scales poorly: every new interface or facility adds another table, each with its own drift and maintenance burden.
Trade-offs:
- Mapping table: cheap, fast, low disruption; but brittle (exact-match logic on name/DOB fails for hyphenation, name changes, twins, nicknames), does not address the truncation defect at the source, and creates hidden coupling. It also does not give a single patient view across facilities.
- Enterprise EMPI: higher cost and implementation time, requires probabilistic matching, governance, and stewardship; but provides a durable identity layer, supports cross-facility record linkage, and enables detection of new duplicates rather than only known ones.
Recommendation: Do both, in sequence. (1) Immediate mitigation: fix the truncation at the sending system (a data-quality defect, not a matching problem), and stand up a short-term mapping/reconciliation worklist to resolve the 6% known duplicates with human review. (2) Strategic: fund an enterprise EMPI with probabilistic matching, defined match thresholds, and a stewardship workflow for ambiguous matches. The mapping table buys time; the EMPI solves the class of problem. Frame the business case around the safety event and the cost of manual reconciliation.
2. Design the matching logic and governance for the EMPI. What match thresholds, review rules, and escalation would you specify?
Read the worked answer
Matching logic:
- Use a probabilistic algorithm combining multiple attributes (name, DOB, sex, address, phone, SSN where available) rather than exact match on three fields. Normalize names (handle hyphens, suffixes, nicknames) before comparison.
- Define three bands: auto-link (high confidence, e.g., score above an upper threshold), manual review (ambiguous middle band), and no match (below lower threshold). Thresholds should be calibrated against a labeled sample, not guessed.
- Never auto-link on a single attribute; require corroboration.
Governance:
- A data stewardship team owns ambiguous matches and has authority to merge or reject. Define turnaround SLAs for the review queue.
- Merge is reversible and audited. Over-merges are more dangerous than under-merges; require a second reviewer for merges above a risk tier.
- Track metrics: duplicate rate, false-link rate (sampled audit), review queue volume and aging, and time-to-resolution.
- Escalation: any suspected wrong-patient event triggers immediate investigation, root-cause analysis, and reporting through the safety event system.
- Document the matching rules and thresholds in a controlled policy so changes go through change control.