Master Patient Index (MPI) and EMPI: Patient Matching Algorithms, FHIR $match, and IHE Standards

A Master Patient Index (MPI) is an authoritative clinical database that maintains a unique, consistent demographic record and medical record number (MRN) for every patient registered within a healthcare organization. When scaled across multiple hospitals, ambulatory clinics, laboratories, and health information exchanges, an Enterprise Master Patient Index (EMPI) links disparate local facility MRNs under a single cross-system Enterprise Identifier (EID). In both clinical care delivery and longitudinal health services research, the MPI/EMPI prevents fragmented patient charts, medical errors from record overlays, and biased cohort linkage across electronic health records (EHR vs. EMR).

What Is a Master Patient Index (MPI) in Healthcare?

Every clinical encounter generates laboratory results, diagnostic images, medication orders, and clinical notes that must be bound to the correct individual. Without a centralized identity index, a patient admitted to an emergency department under “Rob Smith” and later seen in an outpatient specialty clinic as “Robert J. Smith” risks being assigned two separate medical record numbers. An MPI serves as the identity resolution layer that stores core identifying elements—including legal and alias names, date of birth, administrative sex, current and historical residential addresses, telephone numbers, government or payer identifiers, and facility-specific MRNs.

Health information management (HIM) data stewardship teams monitor two primary identity integrity defects inside an MPI:

• Duplicate Medical Records (False Negatives): A single physical patient is assigned two or more distinct MRNs, splitting clinical history, allergy lists, and longitudinal trial follow-up across fragmented records.
• Overlay / Mingled Records (False Positives): Two different physical patients are erroneously assigned the same MRN or merged into one enterprise profile—a high-severity patient safety hazard that can expose a patient to treatments based on another individual’s lab values or imaging, and can corrupt patient-level outcomes in clinical research registries.

MPI vs. Enterprise Master Patient Index (EMPI)

While the terms are frequently used interchangeably, health informatics architectures distinguish a facility-level MPI from a cross-organizational EMPI:

Architectural Dimension	Single-Facility Master Patient Index (MPI)	Enterprise Master Patient Index (EMPI)
Organizational Scope	Single hospital or standalone clinic using a single EHR instance	Multi-hospital integrated delivery network (IDN), Health Information Exchange (HIE), or multi-site clinical research network
Identifier Hierarchy	Manages a single local Medical Record Number (MRN) namespace	Preserves each facility’s local MRN + Issuing Authority (OID/URI) and links them to a master Enterprise Identifier (EID)
System Integration	Native registration module inside an EHR (such as Epic Systems Identity)	Cross-platform identity hub reconciling records across heterogeneous EHRs, LIMS, PACS, and national frameworks like Carequality
Research Data Linkage Role	Single-center cohort extraction	De-duplicating multi-institutional real-world data (RWD) and linking EHR cohorts with mortality or claims registries

How Deterministic, Probabilistic, and Referential Patient Matching Algorithms Work

Because the United States does not mandate a universal national patient identifier, MPIs and EMPIs rely on algorithmic record linkage to resolve patient identities across demographic variations, typographical errors, name changes, and missing fields:

1. Deterministic Matching

Deterministic patient matching evaluates exact boolean agreement (or rule-based combinations of exact matches after phonetic and string normalization such as Soundex, Metaphone, or US Postal Service address standardization) across a predefined set of attributes—for example, requiring an exact match on Normalized_Last_Name + Normalized_First_Name + Date_of_Birth + Last_4_SSN. Deterministic rules yield very low false-positive (overlay) rates when identifiers are complete and accurate, but suffer from high false-negative (duplicate) rates whenever a birth date digit is transposed, a hyphenated surname is truncated, or a patient changes their address.

2. Probabilistic Matching (Fellegi-Sunter Model)

Probabilistic patient matching—formalized mathematically by Ivan Fellegi and Alan Sunter—calculates a composite statistical weight for each candidate record pair by evaluating two probabilities for every demographic attribute $i$:

• $m_i$ (Match Probability / Sensitivity): The conditional probability that attribute $i$ agrees given that the two records truly belong to the same patient ($1 – text{error/change rate}$).
• $u_i$ (Unmatch Probability / Chance Agreement): The conditional probability that attribute $i$ agrees purely by chance across two unrelated individuals (determined by attribute frequency; for example, matching on a rare surname or exact birth date carries a much smaller $u_i$—and therefore much higher discriminating power—than matching on administrative sex or a common surname like “Smith”).

When attribute $i$ agrees, the algorithm adds a positive agreement weight $w_i^+ = log_2(m_i / u_i)$; when it disagrees, it adds a negative penalty weight $w_i^- = log_2((1 – m_i) / (1 – u_i))$, often combined with Jaro-Winkler string edit-distance scaling for partial typographical matches. The summed composite score $W = sum w_i$ is evaluated against two operational thresholds:

1. Above Upper Threshold ($W ge T_{text{upper}}$): Automatic link (`certain` match).
2. Below Lower Threshold ($W le T_{text{lower}}$): Automatic non-match (`certainly-not`); a new identity record is created if registering.
3. Clerical Review Zone ($T_{text{lower}} < W < T_{text{upper}}$): Routed to an HIM data stewardship queue for manual verification before linking.

3. Referential Matching and Privacy-Preserving Record Linkage (PPRL)

Referential matching augments EMPI demographics against continuously updated population reference data (such as historical address histories, telecommunications records, and name-change records), resolving identity links even when a patient moves across states and changes both surname and phone number. In de-identified clinical research data enclaves, institutions apply Privacy-Preserving Record Linkage (PPRL)—computing keyed cryptographic hashes or Bloom filter encodings over normalized demographic tokens—so an EMPI or honest broker can link longitudinal patient records across sites without exchanging cleartext protected health information (PHI).

Interoperability Standards: IHE PIX/PDQ and HL7 FHIR Patient/$match

Standards organizations define exact messaging and RESTful API contracts for querying and synchronizing an MPI or EMPI:

• IHE Patient Identifier Cross-Referencing (IHE ITI TF-1 Chapter 5: PIX and PIXm): The Integrating the Healthcare Enterprise (IHE) PIX profile enables a clinical system holding a patient’s local identifier in Domain A to query the EMPI Cross-Reference Manager and retrieve the corresponding patient identifiers in Domains B and C. Its modern RESTful counterpart, PIXm, executes this cross-reference over HL7 FHIR.
• IHE Patient Demographics Query (IHE ITI TF-1 Chapter 8: PDQ and PDQm): The PDQ profile allows client systems to query a Patient Demographics Supplier using partial demographic attributes to retrieve matching patient records. The FHIR-based PDQm profile supports mobile and web applications, incorporating transaction ITI-119 for MPI matching.
• HL7 FHIR Patient/$match Operation (FHIR R4 Patient-operation-match): Rather than relying on simple exact-string REST search parameters (GET /Patient?family=...), FHIR defines a dedicated MPI invocation: POST [base]/Patient/$match. The client submits a Parameters payload containing a partial or complete Patient resource, an optional onlyCertainMatches boolean flag, and a maximum count. The EMPI executes its internal deterministic or probabilistic algorithm and returns a searchset Bundle of candidate Patient resources, each annotated with a search.score from 0.0 to 1.0 and an HL7 match-grade extension (certain, probable, possible, or certainly-not).