FHIR alone won’t fix patient matching

Interoperability in healthcare has advanced significantly over the past decade, with HL7’s FHIR emerging as the dominant standard for interoperable data exchange. Use cases are proliferating, implementation guides are maturing, and national programs such as the Trusted Exchange Framework and Common Agreement (TEFCA) and Patient Access are accelerating adoption. Despite this progress, it’s still challenging to answer a simple question: Are we even talking about the same patient?

Patient matching and master data management remain some of the most persistent and under-addressed challenges in health IT. As we build increasingly sophisticated FHIR-based ecosystems, the consequences of getting identity wrong are no longer theoretical—they are operational, financial, and clinical.

A recent survey of healthcare providers and Health Information Exchange (HIE) leaders found that 38% of providers have incurred an adverse event in the previous two years because of a patient matching issue. A College of Healthcare Information Management Executives (CHIME) survey of healthcare CIOs found that error rates due to patient mismatching averaged 8% and ranged up to as high as 20%.

It isn’t just providers who are affected; patients are negatively impacted as well. CHIME also noted that approximately 35% of all denied healthcare claims result from inaccurate patient identification or information. This was pointed out in CHIME’s breakdown of the bipartisan MATCH IT Act, which seeks to address the problem of patient misidentification.

The path forward requires acknowledging that FHIR has solved part of the healthcare data management problem, but not all of it. Fixing patient matching demands intentional investment in identity infrastructure, governance, and standards that have long been deferred.

The problem: Why patient matching still fails

In everyday life, we assume identity is stable and consistent. In health IT, it rarely is. Patients receive care from multiple providers, health systems, payers, and public health programs, with each organization assigning its own identifiers and record numbers, collecting its own demographics, and correcting data on its own timeline. The result is a patchwork of “truths” about the same person spread across disparate systems that weren’t built to ensure consistency and integrity amongst themselves.

Because there is no universal, authoritative patient identifier in the United States, patient matching is inherently a probabilistic exercise. Systems look at a set of attributes (e.g., name, date of birth, address, phone), apply weights and thresholds, then decide whether two records are close enough to be treated as the same person.

This works until the inputs are incomplete, outdated, or inconsistent. In healthcare, this unfortunately is the norm rather than the exception. Poor data quality often results in many thousands of staff hours spent comparing patient records and manually reconciling, splitting, or merging patient entities in various systems.

Common data quality issues that make matching difficult include:

• name variation and change (e.g., nicknames, multiple last names, marriage/divorce, cultural naming conventions, typos)
• address instability and formatting differences (e.g., moves, homelessness, rural routes, unit numbers, PO boxes)
• missing or inconsistent contact details (e.g., phone numbers recycled, email changes)
• inconsistent demographic fields (e.g., sex/gender markers, race/ethnicity categories, “unknown” defaults)
• outdated records and delayed reconciliation (e.g., a corrected birthdate in one system doesn’t propagate to others)
• different identifiers for the same person across contexts without a shared crosswalk (e.g., medical record numbers, payer member IDs, program IDs)

Within a single hospital, a Medical Record Number (MRN) may feel good enough, but across a regional or national ecosystem, it doesn’t hold. Without some form of national master patient identifier or equivalent, trusted identity framework, every healthcare data exchange becomes an identity negotiation. Each participant in that exchange must decide how much it trusts the other’s identifiers and demographics and how aggressively they will attempt to reconcile discrepancies.

Most organizations try to compensate with a Master Patient Identifier or electronic Master Patient Identifier (MPI/eMPI), and many vendors provide their own matching engines. But these engines are not standardized: They use different attribute weights, thresholds, and error-handling approaches. Meantime, individual organizations’ configuration options lead to varied results and effectiveness. The consequence is that patient identity may be solved inside one organization while still failing at the seams between organizations, where interoperability is supposed to deliver the most value.

When matching fails, it typically fails in two directions:

• False positives (over-matching): Two different people are mistakenly treated as one. This is a both a privacy risk (e.g., inappropriate disclosure of protected health information) and a safety risk (e.g., clinical decisions influenced by another person’s history).
• False negatives (under-matching): One person is split into multiple records. This fragments the longitudinal record, hides prior history, drives duplicate testing, and creates avoidable burden as clinicians and operations teams reconcile charts manually.

This is a problem that FHIR is not designed to fix, contrary to popular belief. The FHIR standard improves exchange at the technical and semantic layers, but it does not magically create a shared identity layer. Although FHIR’s Patient resource is a container for demographic and identifier data, it was never intended as an identity guarantee.

That said, FHIR does provide some tools that assist in the patient identity resolution process. These include the $match operation and data elements like Patient.identifier and Patient.link for merge/split handling. This is where organizations’ implementation of FHIR and its tools matter.

FHIR is what is a “platform standard,” meaning that it provides all of the data models and tools necessary to facilitate interoperable healthcare data exchange. But the actual implementation of it is mostly left to the organization, which can result in varied experiences across the interoperability landscape. FHIR does not provide the matching algorithm or the weights or thresholds needed for confident patient matching. The same input demographics may produce different candidate matches across different systems because the engine behind the operation is not standardized and there is no universal pattern for thresholds, confidence scoring, or exception management.

In other words: FHIR helps us exchange data and it can help us express identity-relevant information consistently, but we still need intentional strategy, governance, and fit-for-purpose services to resolve identity at scale. In the next installments of this series, we’ll move from the challenges to the practical application—examining how these failure modes show up in CMS-aligned workflows and where FHIR can (and cannot) help close the gap.