Don't miss out

Don't miss out

Don't miss out

Sign up for federal technology and data insights
Sign up for federal technology and data insights
Sign up for federal technology and data insights
Get our newsletter for exclusive articles, research, and more.
Get our newsletter for exclusive articles, research, and more.
Get our newsletter for exclusive articles, research, and more.
Subscribe now

What FHIR can—and can’t—do about the identity problem

What FHIR can—and can’t—do about the identity problem
By Benjamin Graham
Senior Fast Healthcare Interoperability Resources (FHIR) Architect
Benjamin Graham's Recent Articles
FHIR alone won’t fix patient matching
Jul 7, 2026
4 MIN. READ

Modern APIs do not solve healthcare’s longest-standing interoperability problem: knowing whether two records belong to the same person. As FHIR adoption expands across use cases like prior authorization, patient access, quality measurement, and public health, that question becomes even more consequential, not less.

FHIR provides tools for representing patients, exchanging identifiers, and invoking patient matching workflows. But it does not create a universal identity layer, standardize matching logic, or fix the governance and data quality problems that drive mismatch. This makes FHIR important to the identity problem, but not sufficient to solve it. FHIR, CMS, and the TEFCA network together underscore the challenges, opportunities, and limits of using interoperable standards to solve the identity problem.

The best way to see the challenge is through real workflows. In each case, FHIR can improve the mechanics of exchange. But if the identity is incorrect, the workflow still fails.

  • Prior authorization is increasingly tied to FHIR-enabled exchange through CMS policy and the Da Vinci Burden Reduction implementation guides. The goals are clear: reduce manual work, accelerate decisions, and improve transparency. But those gains depend on assembling the right clinical and coverage context for the right patient. If records are fragmented or mismatched, documentation can be incomplete and decisions can be delayed. The burden simply shifts rather than disappears. CMS, through rules such as CMS-0057-F and the proposed CMS-0062-P, have pushed the market toward API-enabled prior authorization, but that change does not remove the underlying identity risk.
  • The same pattern appears in digital quality measurement, care coordination, and public health. Measures depend on assembling complete longitudinal data across systems. Care teams depend on a coherent patient story across settings. Public health depends on trustworthy person-level aggregation. In all three settings, the existence of duplicate, split, or incorrectly linked records undermines trust in the outcome. Increased interoperability only helps if the ecosystem can also improve identity resolution. The TEFCA framework and federal public health interoperability efforts point toward broader exchange, but broader exchange also raises the stakes for getting identity right.

Still, FHIR materially improves the technical foundation for patient matching. The Patient resource supports core demographics and multiple identifiers, which reflects the reality that a person is rarely represented by a single token across healthcare. The specification also defines Patient/$match, giving systems a standardized way to submit demographic information to an identity service and receive candidate matches in return. Those are meaningful advances because they create reusable patterns instead of proprietary one-off interfaces. Patient and Patient/$match illustrate that interoperability can support identity workflows more directly than older exchange models did.

FHIR also supports record linkage through mechanisms such as Patient.link and aligns with broader identity and discovery patterns used across the interoperability ecosystem. That makes it more plausible to connect local identity services, enterprise master patient indexes, and network-based exchange approaches over time, even if the matching logic itself remains outside the standard. Patient.link demonstrates how FHIR helps operationalize identity workflows without fully defining them.

FHIR provides these great tools but still doesn't settle the hardest questions. There is no universal matching algorithm, confidence threshold, or stewardship model. Two systems can both support the same FHIR operations and still reach different conclusions about whether records belong to the same person because their rules, data quality, and risk tolerance differ.

Just as importantly, FHIR does not create governance or clean up bad source data. It doesn’t decide which identifiers are authoritative, when records should be merged, who reviews ambiguous matches, or how quality is monitored over time. Nor does a nationwide exchange framework automatically solve this. TEFCA creates a stronger floor for exchange, but patient identity remains probabilistic, operational, and heavily dependent on stewardship.

The practical path forward is to stop expecting FHIR to become something it was never designed to be. The better strategy is to pair FHIR-based exchange with stronger identity services, clearer stewardship, and better data quality practices. In some settings, that will mean centralized Master Patient Index (MPI) platforms, including Enterprise Master Patient Index (EMPI) solutions. In others, it will mean more federated, network-based identity models. Either way, identity must be treated as core infrastructure rather than an afterthought.

This challenge also presents a policy opportunity. As federal efforts continue to accelerate FHIR-based exchange for prior authorization, patient access, quality, and public health, policy should reinforce this foundation through stronger expectations for identifier strategy, match transparency, and operational governance across exchange partners. This doesn't require a single national identifier. The final article in this series will explore how Learning Health Systems can benefit from an improved governance framework for patient identity while incorporating FHIR and adjacent technologies.

Meet the author
  1. Benjamin Graham, Senior Fast Healthcare Interoperability Resources (FHIR) Architect

    Benjamin Graham is a Senior FHIR Architect at ICF with over 17 years of experience in healthcare interoperability, specializing in FHIR and health data standards. He has led major API implementations, earned multiple HL7 certifications, actively contributes to national interoperability initiatives, and advances the field through education, advisory roles, and thought leadership. View bio

Your mission, modernized.

Subscribe for insights, research, and more on topics like AI-powered government, unlocking the full potential of your data, improving core business processes, and accelerating mission impact.