Enterprise Master Patient Index (EMPI) and Patient Matching: MPI vs EMPI, Matching Methods and Match-Rate KPIs

Patient identity matching: why it matters more than it looks

Patient matching is the job of deciding whether two records describe the same person. Inside one hospital it happens every time someone registers; across a health system, an HIE or a data platform it happens millions of times a day, mostly without a person involved. When it goes wrong in one direction, a patient’s history is split across records and clinicians miss allergies, results and prior diagnoses. When it goes wrong in the other direction, two people’s records are combined and someone else’s history appears in the chart.

ECRI ranked patient identification errors second on its 2016 list of top patient safety concerns, and The Joint Commission requires hospitals to use at least two patient identifiers, now under goal NPG.01.01.01 of its 2026 National Performance Goals. Those rules cover the bedside. The EMPI covers the records behind it: if the chart itself belongs to two people, checking two identifiers at the bedside will not catch the error.

The problem is sharper in the United States, which has no national patient identifier, than in countries that issue one. But even with a national ID, newborns, visitors, emergency arrivals and data from systems that never captured the ID still need demographic matching. That is why every serious interoperability program eventually becomes a patient identity program.

What is a master patient index (MPI)?

An MPI predates electronic records: hospitals kept card indexes that pointed from a patient’s name to their paper chart. In a modern EHR, the MPI is the patient table plus the search, duplicate-check and merge functions around it. It answers one question, “Have we seen this person before, in this system?”, and it is only as good as the data captured at registration.

What a master patient index contains

What is an enterprise master patient index (EMPI)?

An EMPI does not replace each system’s MPI. The hospital EHR still issues its MRN, the lab system its accession-linked patient ID and the billing system its account number. The EMPI keeps the map between them, decides which local records belong together, and publishes those decisions so that every connected system, and every downstream consumer such as a FHIR data exchange or an analytics platform, sees one patient instead of three.

Two terms you will meet alongside it:

• Golden record. Some EMPIs build a “best” version of the patient’s demographics from all linked records, using survivorship rules such as “most recent verified address wins”. Others only link and leave each source record as it is.
• UMPI or community MPI. When the scope extends beyond one organization, for example an HIE or a national exchange, the index is sometimes called a universal or community master patient index. The matching techniques are the same; the governance and data-sharing rules are very different.

MPI vs EMPI: key differences and when you need each

The difference is scope. An MPI answers “have we seen this person in this system?” An EMPI answers “which records, across all our systems and facilities, belong to this person?”

When an MPI is enough, and when you need an EMPI

How patient matching works in healthcare systems

Whatever the algorithm, an EMPI runs the same pipeline every time a record is created or changed in a connected system.

1. Capture

   An ADT or FHIR event arrives from a source system.

2. Standardize

   Names, dates, addresses and phones normalized; junk values removed.

3. Block

   Pick a small candidate set, e.g. same birth year and name sound.

4. Compare

   Field by field: exact, fuzzy, phonetic, date-aware.

5. Score

   Rules fire or weights add up to a match score.

6. Decide

   Link, review or create, then publish to connected systems.

Blocking is the step people skip in explanations and the one that decides performance. Comparing every new record with every existing one is impossible at scale, so the engine first selects candidates that share a cheap key, such as a phonetic code of the surname plus birth year. Blocking that is too narrow silently hides true matches; blocking that is too wide makes matching slow. Most engines run several blocking passes with different keys.

Standardization is the other quiet win. Converting addresses to a standard postal format, stripping titles and suffixes, normalizing phone formats and rejecting placeholder values like “BABY BOY” or 01/01/1900 improves every comparison that follows. Federal work on this is concrete: ASTP/ONC’s Project US@ published a unified specification for representing patient addresses consistently across systems in January 2022. Expect gains in finding matches, not miracles: in a 2019 JAMIA study, standardizing addresses to US Postal Service rules raised matching sensitivity by about 0.6% and 4.5% in two datasets, while overall accuracy stayed flat because specificity fell. Combined standardization lifted sensitivity in the HIE dataset from 81.3% to 91.6%.

Deterministic vs probabilistic patient matching

There are two families of patient matching algorithms, and most production EMPIs use both: deterministic rules for the clear cases and guardrails, probabilistic scoring for everything in between.

The probabilistic approach comes from the Fellegi–Sunter model of record linkage, published in 1969. For each field, m is the probability that it agrees when two records really are the same person, and u is the probability that it agrees by chance between two different people. Agreement on a field with a high m and a tiny u, such as a phone number or a national ID, is strong evidence. Agreement on sex, where u is about one half, is weak evidence. Modern engines add fuzzy comparators such as Jaro–Winkler for names, phonetic codes, nickname tables and date comparators that recognize swapped days and months.

Algorithm sophistication matters. AHIMA’s practice brief on patient identity in health information exchange notes that basic matching algorithms usually identify only 10 to 40 percent of existing duplicates, intermediate ones 50 to 70 percent, and advanced ones up to 98 percent.

See both methods decide the same pairs

Pick a scenario. Record A is already in the EMPI; record B is a new registration. The deterministic rule needs first name, last name, date of birth and sex to agree exactly. The probabilistic score uses illustrative weights, auto-links at 20 or more and sends 8 to 19.9 to review.

Illustrative weights from assumed m and u values, not tuned for any population. Fictitious records.

Other matching approaches you will hear about

Common patient matching attributes and identifiers

Not every field is equally useful. A good attribute is discriminating (few people share it), stable (it does not change), and usually captured. The table shows how the common ones compare in practice.

In the US, the attributes that matter most for matching are now part of the national data standard. The 21st Century Cures Act Final Rule notes that current address, previous address, phone number, phone number type and email address were included in USCDI version 1 “for their usage in accurate patient matching”. That is useful leverage when you ask EHR vendors and exchange partners to send them consistently.

Patient deduplication: duplicates, overlaps and overlays

Health information management teams use three terms for identity errors. They need different fixes and different KPIs, so it pays to keep them apart.

Merge, link and unmerge

Within one system, two records for the same patient are usually merged: one survives, the other is retired, and in HL7 v2 the change goes out as an ADT^A40 “merge patient” message so downstream systems follow. Across systems, records are usually linked under an enterprise ID rather than merged, because each source system keeps its own record; HL7 v2 has ADT^A24 “link patient information” and ADT^A37 “unlink”. Every merge needs a tested unmerge path, because a wrong merge that cannot be reversed turns into a permanent overlay.

Common challenges in patient identity management

Most matching errors start long before the algorithm runs. GAO’s 2019 review of patient matching found that inaccurate, incomplete or inconsistently formatted demographic information was the main obstacle, and that no single effort would solve it. These are the causes we see most often, and what to do about them.

Patient match-rate KPIs: how to measure EMPI performance

“Our match rate is 98%” means little until you know what was counted. A useful KPI set covers three things: the quality of the data in the index, the accuracy of the matching decisions, and the cost of keeping it that way.

False positives, false negatives, precision and recall

Every matching decision lands in one of four boxes. Precision and recall are just ratios of these boxes, and the thresholds decide how pairs are distributed between them.

A worked example

Suppose a data steward reviews a random sample of 1,000 record pairs and labels 300 as true matches. The EMPI linked 285 pairs: 282 of them correct and 3 wrong. It missed 18 true matches.

• Precision = 282 ÷ (282 + 3) = 98.9%. About one link in a hundred is wrong.
• Recall = 282 ÷ (282 + 18) = 94.0%. Six in a hundred true matches were missed and became duplicates.
• F1 = 2 × 0.989 × 0.940 ÷ (0.989 + 0.940) = 96.4%.

The same engine could report a “match rate” of 98.9%, 94.0% or something else entirely, depending on which ratio is chosen. Always ask for both numbers, the size of the labelled sample, and how the sample was drawn. Numbers in this example are illustrative.

Try it: move the thresholds

The chart shows 1,000 synthetic candidate pairs by match score: true matches above the line, non-matches below. Pairs above the auto-link threshold are linked automatically, pairs between the thresholds go to a data steward, and pairs below become new records. Watch what each threshold does to precision, recall and the review queue.

Two lessons carry over to real systems. First, there is no threshold that removes both errors when the distributions overlap; you choose which error to pay for, and in healthcare that usually means tuning the auto-link threshold for precision and accepting a review queue. Second, the review band is a staffing decision as much as a technical one. Size it to the number of data stewards you actually have.

Best practices for implementing an EMPI solution

Whether you license EMPI software, use your EHR vendor’s enterprise identity module or build matching into your own platform, the projects that succeed follow a similar order.

1. Baseline before you buy

   Profile identity data in every source: completeness of each attribute, placeholder values, formats, and an estimated duplicate rate from a sample. This is the baseline every later KPI is compared with.

   Weeks 1–4

2. Set up governance and stewardship

   Name an owner, usually HIM, define who may merge, unmerge and link, write the policies for twins, newborns, unknown patients and name changes, and staff the review queue.

3. Standardize capture at the source

   Structured address entry, required formats, search-before-create screens and placeholder rules in every registration system. The cheapest match is the one you never have to make.

4. Build a labelled sample, then tune

   Have stewards label a few thousand candidate pairs drawn across score ranges and populations. Use it to set blocking keys, weights and both thresholds, and keep part of it aside to measure precision and recall honestly.

   Data team + HIM

5. Clean up history before go-live

   Run the initial cross-match across all sources, work the high-score pairs first, and agree how legacy duplicates will be merged or linked in each system.

6. Integrate in both directions

   Feed registrations and updates in, and publish links and merges back out to EHRs, ancillary systems and the data platform, so nobody keeps acting on a stale identifier.

   Integration team

7. Monitor and re-tune

   Report the KPI set monthly, re-sample precision and recall at least yearly and after any source change, and investigate every overlay as a safety event.

   Ongoing

EMPI readiness checklist

Tick items as you confirm them (progress is saved in this browser only), or print it for your steering group.

Buy, use the EHR’s, or build?

Most providers license a proven EMPI or use the enterprise identity service of their EHR or integration platform, then invest in configuration, tuning, stewardship and integration. Building your own matching makes sense when identity is part of your product, for example a health data platform, registry, HIE or payer system, and you need control over the logic, scale or where the data lives. Open-source options such as the HAPI FHIR server’s MDM module or OpenEMPI exist, but the engine is the smaller part of the work; governance and integration are the larger part.

How an EMPI supports EHR integration and healthcare interoperability

In an integration architecture the EMPI sits next to the interface engine. Source systems send registrations and updates in, the EMPI decides identity, and every consumer asks it which records belong together.

POST [base]/Patient/$match
{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "resource", "resource": {
        "resourceType": "Patient",
        "name": [{ "family": "Smith", "given": ["Jon"] }],
        "birthDate": "1984-03-07",
        "address": [{ "postalCode": "77030" }]
    }},
    { "name": "onlyCertainMatches", "valueBoolean": false },
    { "name": "count", "valueInteger": 3 }
  ]
}

A server that supports $match returns a Bundle of candidate Patients, each with search.score and, optionally, a match-grade extension. The specification deliberately leaves the algorithm to the server, which is why a FHIR $match endpoint is usually backed by an EMPI. If you are building one, our FHIR integration and HL7 integration teams cover both sides, and the HL7 and FHIR integration guide explains how the message flows fit together.

Identity across exchanges: TEFCA, the UAE and Saudi Arabia

Exchange frameworks increasingly name the EMPI directly. TEFCA’s QHIN Technical Framework (version 2.1, October 2025) requires a QHIN to resolve patient identity through an enterprise master patient index or a record locator service, asks that addresses conform to Project US@, and says matching recommendations or requirements will follow.

In the Gulf, national IDs help but do not remove the need for matching. Dubai’s NABIDH identity management policy makes the Emirates ID the primary identification document for patients, with a passport or residency permit accepted when there is none. Abu Dhabi’s Department of Health requires the Emirates ID to be captured by card reader at every visit, noting that poor demographic capture affects patient matching in the Malaffi HIE. Saudi Arabia’s NPHIES accepts several identifier types, including national ID, Iqama, passport, visitor permit and border number. Each of these still needs an index that links visitors, newborns and legacy records correctly; see our NABIDH, Malaffi and NPHIES integration pages.

How Bonami helps with patient identity and EMPI projects

Our healthcare engineering team builds the identity layer as part of integration and data platforms: matching engines, steward workflows, and the HL7 and FHIR plumbing that carries identity decisions to every system. We have built identity resolution for a state immunization registry and for a national health services payer, so we know where the hard cases hide.

Frequently asked questions about EMPI and patient matching