Patient Matching Software: Solving EMPI and Record Resolution

Black Book Research found that an average of 24% of an organization's patient records were duplicates. The same research found that approximately one in three claim denials result from inaccurate patient matching.

In our new article, we cover what patient matching software and an enterprise master patient index do, how matching works, and which data decides the outcome. We also explain how to measure match quality and where identity belongs in an integration architecture.

Key Takeaways

• Patient matching software decides whether two records describe the same person and keeps that decision consistent across connected systems.
• An enterprise master patient index compares demographic data, scores each pair of records, and uses thresholds to link them, send them to review, or keep them apart.
• Deterministic, probabilistic, and referential matching differ in how they score records, and each fits a different data situation.
• Match quality depends more on clean, normalized registration data than on the matching algorithm.
• Matching performance is measured with consistent metrics such as duplicate rate and overlay rate, because no industry-wide definition of match rate exists yet.
• Identity resolution works best as one central service with a shared crosswalk, reversible links, and a review queue with a named owner.

What Is Patient Matching Software?

Patient matching software is a system that decides whether two records belong to the same person and keeps that decision consistent across other systems.

The Office of the National Coordinator for Health Information Technology (ONC) defines patient matching as "the identification and linking of one patient's data within and across health systems in order to obtain a comprehensive view of that patient's health care record".

The term also appears in clinical trials, where software focuses on matching patients to studies. This article covers patient identification across electronic health records and the systems connected to them.

MPI, EMPI, and the terms vendors use

Vendors use these terms in overlapping ways, so it helps to separate them early:

• Master patient index (MPI) is the list of patients inside one system or facility.
• Enterprise master patient index (EMPI) spans multiple facilities and links each local record to one enterprise identity.
• Patient identity resolution is the process of deciding which records belong to the same person.
• Golden record is the most complete and accurate version of a person's identity, built from all linked records.

MRN vs. enterprise identifier

A medical record number (MRN) is local. Each facility issues its own, so one patient often has a different MRN at every site. An enterprise identifier sits above them, links every MRN for the same person, and gives downstream systems one ID to read.

Where patient matching software sits

Vendors sell this capability as EMPI software, patient identity matching software, or patient record matching software. Whatever the label, the matching logic usually lives in one of these places:

• Inside an EHR, where it covers only patients registered in that EHR.
• Inside an interface engine, where it resolves identity as messages pass through.
• In a separate identity service, which every integration calls through application programming interfaces (APIs).
• In a managed service, where a vendor runs the matching for the organization.

Why Do Duplicate and Mismatched Records Break Integration at Scale?

Duplicate and mismatched records break integration because every connected system inherits the same identity decision. A missing link leaves data incomplete. A wrong link is worse, because every system that copied it now holds the error.

Technical interoperability makes sure a message arrives, and identity decides which chart it lands in. At scale, identity errors cause a predictable chain of problems:

• New feeds create duplicates. A new facility brings its own MRN series, so the same patient arrives twice.
• Overlays mix two people. Physicians see one person's results in another person's chart, which is a direct patient safety risk.
• FHIR references break. Observations, Encounters, and MedicationRequests attach to the wrong Patient resource.
• Analytics lose accuracy. Reports count duplicate records as separate patients.
• Cross-organization queries fail quietly. The record exists under another identity, so the search finds nothing.
• Manual fixes create unmerge debt. Corrections made by hand never reach the source systems.

Eventually, the damage reaches patient care and the revenue cycle, where a claim filed under the wrong identity is denied.

How Does an EMPI Actually Match Records?

An EMPI matches records by comparing demographic fields, scoring how well they agree, and applying thresholds to that score. Every new registration or inbound message raises the same question: has the system seen this person before? At a high level, every patient matching algorithm answers with one of these outcomes: automatic link, manual review, or no match.

The approaches differ in how they produce the score.

Deterministic matching

Deterministic matching links records when chosen fields agree exactly or meet a defined rule, such as the same last name, date of birth, and sex. When a rule fires, it gives a high degree of confidence and is easy to explain to an auditor. Rules fall short with real-world data, though: one typo, a nickname, or a changed surname is enough to miss a match.

Probabilistic matching

Probabilistic matching gives each field a weight and adds the weights into one score. Rare values count for more, so agreement on an uncommon surname says more than agreement on "Smith." This approach handles messy data well, but it needs tuning against a labeled sample of true matches.

Referential matching

Referential matching checks records against an external database of known identities. It can connect records that share almost nothing, such as an old address and a new married name. The trade-off is a third party in the data flow and a privacy review to go with it.

Blocking and candidate generation

Before scoring anything, the engine decides which records are worth comparing. Comparing every record with every other one does not scale, so blocking narrows the search first, for example to records that share a birth year and a phonetic code for the surname. A blocking rule that is too strict hides true matches before scoring even starts.

A worked example of field weighting

Record A reads "Jonathan Smith, 12 March 1984, 14 Elm Street." Record B reads "Jon Smith, 12 March 1984, 14 Elm St." An exact-name rule rejects this pair, while a probabilistic engine with a nickname table and address standardization scores it high, which is the right call.

Now Record C arrives: "John Smith, 12 March 1984, 14 Elm Street." It also scores high, because only one letter separates John from Jon. If Jonathan and John are twins, that score links two different people.

That is why every threshold needs a review band with a person behind it.

Thresholds, review, and survivorship

Most engines use two thresholds to transform a score into a decision. Pairs above the upper threshold link automatically, and pairs below the lower one stay separate. Everything in between goes to a data steward for manual review.

Moving either threshold is a trade-off. A lower bar creates more overlays, and a higher bar leaves more duplicates.

Once records are linked, survivorship rules decide which value wins when they disagree, for example the most recently verified address. The result is the golden record that downstream systems read.

Linking versus merging

The last decision is what happens to linked records. A link connects them and keeps each one intact, so it can be undone. A merge combines them into one record and usually cannot be reversed, which makes it an architectural decision.

The Sequoia Project's white paper, A Framework for Cross-Organizational Patient Identity Management, sets minimum acceptable principles for this work. Among them: no exact character-by-character matching, and no reliance on a single identifier such as a Social Security number.

Which Data Elements Decide Match Quality?

Match quality depends mostly on the data an organization captures and normalizes, and much less on the algorithm. Every matching approach compares the same demographic fields, so a placeholder birth date or a free-text address weakens all of them equally. That is why accurately matching patient records starts at registration.

Reliable patient identity matching depends on how accurately healthcare organizations capture these fields:

National standards help align capture across systems. The United States Core Data for Interoperability (USCDI) includes a Patient Demographics/Information class for data used "for identification, records matching, and other purposes." For addresses, Project US@ defines one consistent way to represent a patient address.

Hard cases every healthtech product meets

Even with clean capture, some records create additional challenges for any engine:

• Twins and families share surnames, addresses, and phone numbers, and twins also share a birth date.
• Newborns in children's health settings often get a temporary name that changes days later.
• Name and gender marker changes break exact rules unless previous values are kept. Capturing these changes well is also a matter of inclusion.

Capture rules for registration workflows

Most duplicates start at record creation, so registration practices matter most. These rules prevent the most common capture errors:

• Reject placeholder dates of birth at entry.
• Keep previous names and addresses instead of overwriting them.
• Standardize addresses before storage.
• Store every source identifier together with the system that issued it.

How Is Patient Matching Performance Measured?

Patient matching performance is measured with a small set of metrics, tracked the same way over time. A single match rate from a vendor says little on its own, because each vendor can define and count it differently. Together, the metrics below show whether identity is improving or degrading:

The lack of a shared definition is a known industry problem. According to TechTarget, the MATCH IT Act would have ONC define patient match rate and adopt a minimum data set supporting the adoption of patient matching at 99.9% accuracy. The bill was introduced in February 2024, reintroduced in March 2025, and a Senate companion bill followed in August 2026.

A maturity model for patient identity management

The Sequoia Project's maturity model helps an organization assess its patient identity management. It rates people, processes, technology, and governance. Level zero means ad hoc work, and level four means continuous improvement with active senior management involvement.

In the framework’s Intermountain Healthcare example, the cross-organizational match rate started at 10%. It reached 62% after workflow fixes, 85% after the team analyzed the remaining errors, and over 95% once data quality, workflows, and governance improved. Matching is an ongoing program with its own budget, and one software purchase does not complete it.

Before the first new feed goes live, measure a baseline: duplicate rate, sampled overlay rate, and review queue volume. This baseline is vital for showing whether the integration made identity better or worse.

Where Does Patient Matching Software Fit in an Integration Architecture?

Identity resolution belongs in one central service that sits in front of every system using patient records. That service keeps an identifier crosswalk, and every integration reads identity from it instead of deciding on its own. The same rule applies to all healthcare interoperability solutions, whether they run on HL7 v2 or FHIR.

In short, every inbound record follows one path: Receive → Normalize → Score → Decide → Record → Notify

Step by step, the flow looks like this:

1. Receive. An HL7 v2 ADT (admit, discharge, transfer) message or a FHIR Patient resource arrives with a source identifier.
2. Normalize. The service standardizes names, dates, and addresses.
3. Find candidates. Blocking rules pull likely matches from the index.
4. Score. The engine scores each candidate pair against the thresholds.
5. Decide. High scores link automatically, and middle scores go to the review queue.
6. Record. The crosswalk maps the source identifier to an enterprise identifier.
7. Notify. Consuming systems receive an event and update their references.

ADT events that break naive designs

A naive design assumes identity is fixed after the first message, but identity keeps changing. In HL7 integration, ADT A28 and A31 messages add and update patient information, and A40 merges patient identifiers.

Retrospective merges cause the most trouble. A merge can arrive days after orders and results were filed under the old records, so the pipeline has to reprocess them. Every step therefore needs to be idempotent, which means it can safely run twice on the same message without creating new duplicates.

The crosswalk table

The crosswalk is the single record of which local identifiers belong to which person. It needs these columns:

The last two columns make every link auditable. They also give data stewards the ability to find and reverse a bad decision.

Patient identity in a FHIR-native stack

In a FHIR-native stack, identity logic runs next to the FHIR store and uses the same resources as the rest of the platform. Organizations that use Medplum for healthcare systems integrations can implement it as Medplum bots or as an external service in front of the store.

Medplum’s patient deduplication guide maps each step to standard FHIR. A RiskAssessment stores each candidate pair with its match score.

A confirmed merge connects the records through Patient.link, marks the duplicate inactive, and repoints resources such as Encounters to the surviving record. Pairs a reviewer rejects go on a Do Not Match list.

Our Medplum case study notes that “patient matching can be implemented with bots or external logic to avoid duplicates.”

Should a Team Build, Buy, or Extend Patient Matching Software?

The right choice depends on how many source systems a platform carries, how messy its data is, and whether people are available to work a review queue. Each option solves a different problem:

• Build means writing the matching logic in-house.
• Buy means licensing EMPI software and integrating it.
• Extend means adding custom normalization and workflow around an established engine.

Decision criteria

These factors usually decide which option fits:

• Source systems. More sources, and frequent changes to them, favor a dedicated identity service.
• Cross-organization matching. Matching across organizational boundaries calls for probabilistic or referential methods.
• Privacy position. Referential matching sends identities to a third party, so the privacy review has to allow it.
• Data stewardship. Someone has to work the review queue every day.

Cost drivers and when building fits

Most patient matching software that healthcare buyers evaluate looks similar on a feature list.

• Licensing fees for EMPI software.
• Integration work for every source system.
• The review queue, which is an ongoing people cost.
• Historical cleanup of duplicates that already exist.

Building makes sense when sources are few, data is clean, and matching stays inside one organization. In that case, a deterministic core with a review screen can serve the need. A multi-facility platform with cross-organization exchange usually needs an established engine, often extended with custom logic.

Compliance context

Patient matching supports data quality and interoperability, and it is one part of a wider compliance program. A review queue shows two candidate identities side by side, so it needs the same protected health information (PHI) access controls as the patient chart. HIPAA (the Health Insurance Portability and Accountability Act) also expects audit controls, so every link and merge decision should leave an audit trail.

What Goes Wrong in Practice?

Most patient matching problems come from thresholds tuned for the wrong goal, review queues nobody owns, unnormalized data, misplaced trust in EHR matching, and no plan for undoing a merge. These patterns appear in hospitals, clinics, and digital health products alike, and each one has a practical fix.

Tuning for match rate creates overlays

A higher match rate looks like progress, so it is tempting to lower the auto-link threshold. The catch is that the engine then links more pairs that are actually different people. The fix is to track the overlay rate next to the match rate and audit a sample of links after every threshold change.

The review queue becomes a backlog nobody owns

Without a clear owner, the review queue keeps growing until someone bulk-approves it, and overlays slip through. The fix is data governance. Give the queue a named owner, often in health information management (HIM), set a target age for open items, and report queue health to the leadership team.

Matching runs on unnormalized data

When one record says "St." and another says "Street," the engine wastes its accuracy on formatting. Typing errors have the same effect. The fix is to normalize names, dates, and addresses before scoring and to improve data capture at registration.

EHR matching is assumed to cover other organizations

An EHR's internal matching covers only the patients registered in that EHR. Records that arrive from a health information exchange (HIE) or from partner providers fall outside it.

On the preventive care platform we built on Medplum, a bi-directional Health Gorilla integration brings in external medical records through national networks. These records come from outside the organization, so cross-organization matching needs its own design and its own rules.

No plan exists for undoing a bad merge

An EMPI merge does not reach the source systems on its own, so a bad merge lives on in every system that copied it. The fix is to prefer reversible links, store the pre-merge state, and define an unmerge workflow before go-live.

TechMagic's Experience With Healthcare Integration and Patient Identity

TechMagic has delivered 200+ projects since 2014, with 400+ experts. In healthcare, our work covers integration, EHR and EMR platforms, Medplum-based products, FHIR and HL7 v2 pipelines, and data engineering. On integration projects, we design data mapping, permissions, and sync logic to avoid duplication and drift between systems.

Our HealthTech projects include:

• Unified EMR interoperability layer. For a US patient intake and referral platform, we built one interoperability layer that connects 10+ EMRs, including Epic, athenahealth, NextGen, and Medplum. New health systems onboard through configuration instead of a code fork.
• MHC HealthCare. We built a HIPAA-compliant EMR portal for secure storage and exchange of sensitive medical data.
• Tiro.Health. We helped build a FHIR-compliant medical form platform that meets WCAG 2.2 accessibility standards.
• Unumed. Our security engineers penetration-tested a cloud-native hospital management system, including its API integrations.

We treat identity as part of the integration design, so it gets planned before the first feed goes live.

Need Expert Help With Patient Matching?

Matching thresholds, crosswalk design, and ownership of the review queue are much easier to decide before development starts than after go-live. An early architecture review settles these questions while changes are still cheap.

Final Thoughts

Patient matching software works only as well as the process around it: clean data at registration, one central identity service, tracked metrics, and a staffed review queue.

Where is this heading?

• More exchange means more matching decisions. Nearly 500 million health records had moved through the Trusted Exchange Framework and Common Agreement (TEFCA) by February 2026, up from 10 million in January 2025, according to ASTP/ONC data reported by TechTarget.
• Identity checks are moving to check-in. More than 700 organizations have joined the Centers for Medicare & Medicaid Services (CMS) Health Tech Ecosystem, according to TechTarget, and its Kill the Clipboard pledge promotes digital identity verification at intake.
• Policy is still catching up. The MATCH IT Act would define match rate at the federal level. HIPAA originally called for a unique identifier per patient, but the Section 510 rider has barred the Department of Health and Human Services from funding a unique patient identifier since the late 1990s.

FAQ

What is patient matching in healthcare?

Patient matching in healthcare is the process of identifying and linking one patient's records within and across health systems. Accurate matching means treatment, billing, and data exchange all rely on one reliable record for each person.

Why do healthcare organizations use patient matching software?

Healthcare organizations use patient matching software to prevent medical errors and protect patient safety. Patient data often contains inconsistent or outdated demographic information, such as old addresses and changed surnames. Patient matching software links those records to the right person despite the differences.

What are the two main algorithms used to match patient records?

The two main algorithms used to match patient records are deterministic and probabilistic matching. Deterministic matching links records when chosen fields agree exactly or follow a rule, while probabilistic matching weights each field and links records above a score threshold. Referential matching, which checks records against an external identity database, is a third approach.

What is the difference between an MPI and an EMPI?

A master patient index (MPI) lists the patients inside one system or facility, each with a local identifier. An enterprise master patient index (EMPI) spans multiple facilities or systems and links each person's local records to one enterprise identifier.

How can duplicate patient records be reduced?

Duplicate patient records are reduced by capturing complete demographic data at registration, normalizing names, dates, and addresses before matching, and resolving identity in one central service. A staffed review queue and regular duplicate scans keep the duplicate rate from rising again.

What is a good duplicate record rate?

A good duplicate record rate is one that is measured the same way every time and keeps falling. No industry-wide definition of the rate exists yet. The MATCH IT Act would have the Office of the National Coordinator for Health Information Technology (ONC) define patient match rate, including duplicate and overlaid records.

Does FHIR solve patient matching?

Fast Healthcare Interoperability Resources (FHIR) does not solve patient matching on its own. FHIR provides a Patient resource with identifiers and a $match operation that returns scored candidates. Each FHIR server still supplies its own matching logic, so data quality and matching rules remain the organization's responsibility.