Enterprise Patient Identity Across Acquired Hospitals: How to Reconcile Duplicate and Fragmented Patient Records

Hospital acquisitions bring together EHRs, medical record numbers MRNs, and registration practices that were never designed to operate as one enterprise. The same patient may have disconnected histories, while identical MRN values may identify different people.

Reconciliation must establish who each record belongs to, preserve identifier relationships, and make the correct clinical history accessible.

What Is Enterprise Patient Identity?

Enterprise patient identity associates a person with records across participating hospitals. An enterprise master patient index EMPI maintains these relationships without necessarily replacing local MRNs or consolidating clinical databases.

Classify records before choosing an operation:

Separate records across organizations are not automatically erroneous duplicates. FHIR explicitly supports distributed patient records.

Why Identity Reconciliation Matters

An incorrect link can expose another patient’s information or contaminate clinical decisions. A missed link can leave allergies, results, or prior encounters undiscovered.

An EMPI relationship alone does not restore clinical access. Each linked identifier needs a functioning retrieval route to the relevant EHR, laboratory, imaging archive, or document repository.

Reference Architecture

This recommended logical design separates identity decisions from downstream execution.

Use interfaces supported by participating applications. IHE PIXm supports identifier cross-referencing; PDQm supports demographic queries and matching. PMIR supports master-identity lifecycle management in FHIR-only configurations for that function. These profiles do not replace local matching validation.

6 Technical Steps to Reconcile Patient Identities Across Acquired Hospitals

1. Inventory Identifiers and Assign Decision Ownership

Preserve the complete identifier

Represent an MRN with its assigning domain and value. Hospital A’s 12345 and Hospital B’s 12345 must remain distinct.

Preserve legacy identifiers, leading zeros, and character formats. In FHIR, retain Patient.identifier.system and value; Patient.id identifies a resource within its server context.

Create an application matrix covering EHRs, LIS, RIS/PACS, billing, patient portals, and archives. Record each system’s identity source, supported events, merge restrictions, and correction procedures.

Assign HIM ownership of identity adjudication, application teams ownership of propagation, and clinicians ownership of affected-care review.

2. Normalize Demographics Without Destroying Evidence

Profile missing fields, placeholder birth dates, name truncation, shared contact details, and inconsistent addresses by hospital.

Retain original values and source timestamps alongside normalized comparison values. Preserve historical names and addresses where available; Project US@ provides address-formatting guidance.

Do not link patients solely because they share an address or telephone number. Define exception workflows for twins, newborns, unidentified patients, and conflicting demographics.

For temporary identities, assign a resolution owner, track downstream use, and verify correction across systems and transfers.

3. Validate Matching and Review Uncertain Cases

Measure errors before automating links

Combine validated identifier relationships with demographic matching appropriate to the population. FHIR Patient/$match returns candidates, scores, and match grades; it does not perform chart merges or prescribe an algorithm.

Use an independently adjudicated reference set:

• Precision: correct accepted links divided by all accepted links assessed.
• Recall: true links found divided by all true links in the reference set.

Include difficult nonmatches and known matches missed during candidate generation. Reviewing only proposed matches cannot establish recall.

Set thresholds from local results and risk tolerance. Keep link approval separate from merge authorization. For unmatched patients, investigate first; create an enterprise identity only through the approved registration workflow.

4. Execute Controlled Links and Merges

For confirmed duplicates, document the surviving identifier, demographic survivorship rules, evidence, approver, and affected applications.

In IHE ITI-8, ADT^A40 communicates a merge within an identifier domain: MRG-1 contains the subsumed identifier and PID-3 the survivor.

FHIR Patient. Link can describe identity relationships, but does not automatically rewrite clinical references. PMIR also leaves handling of references to deprecated identities outside its scope.

Maintain a crosswalk and per-application completion ledger. Test repeated messages, out-of-order updates, and late results. Require application-level verification beyond interface acknowledgments.

Document vendor-specific correction procedures: ITI-8 has no UnMerge transaction, and PMIR places unmerge outside its scope.

5. Control Acquisition Cutover and Verify Clinical Access

Use this recommended sequence:

1. Baseline: extract identity data and approve crosswalks.
2. Capture changes: retain registrations, demographic updates, and merges occurring after extraction.
3. Reconcile: apply and validate subsequent changes before activation.
4. Account for downtime: track patients registered during transition and resolve temporary identifiers.
5. Verify: retrieve encounters, results, images, and documents using reconciled identities.

Identity resolution does not resolve conflicting medication or allergy lists. Assign clinical review and assess care affected by overlays.

Pilot a bounded cohort. Expand only after agreed matching criteria pass, critical exceptions are resolved or explicitly contained, and downstream retrieval and recovery procedures are verified.

6. Prevent New Fragmentation

Train registrars to search before creating records. Review exceptions daily and monitor false links, duplicate creation, unresolved temporary IDs, queue age, and propagation failures.

Define metric denominators and observation periods. Restrict merge permissions, authenticate interfaces, encrypt exchanges, and retain audit trails.

Plan Your Reconciliation With CapMinds

CapMinds supports EHR migration and HL7/FHIR integration. Discuss your acquired hospitals’ identifier domains, application dependencies, and cutover constraints to define reconciliation scope and validation requirements.

Discuss Your Patient Identity Integration Requirements