Beyond Patient Matching: The path to patient mastering
This is the third in a series of articles examining patient identity in the era of FHIR-enabled interoperability. The first article explores the complexities of patient matching and the second article explains how FHIR tools can partially address them. This final installment introduces governed identity services as a comprehensive solution to the patient matching challenge.
FHIR and FHIR-adjacent technologies go a long way toward solving CMS’ patient-matching challenges, helping healthcare organizations exchange data at scale. But healthcare is moving toward data-dependent action: clinical reasoning at scale, digital quality measurement, value-based care, public health intelligence, and learning health systems that continuously improve based on the data they generate.
"It's one thing to retrieve a record from another organization; it's another to use that record to trigger clinical recommendations, calculate quality measures, determine eligibility for interventions, support risk adjustment, train analytic models, or evaluate outcomes over time. In each case, the system is not merely asking, “Can I access data?” It's asking, “Can I trust that this data belongs to the right person, in the right context, and across the right timeline?”
Those tasks require more than patient matching—they require patient mastery.
Patient matching vs. patient mastering
Matching is the probabilistic linking of records, identities, or personae based on available attributes such as name, date of birth, address, phone number, identifiers, and other demographic data points. Patient matching is necessary, and standards like FHIR’s Patient/$match operation give implementers a common way to ask a FHIR API for candidate matches. But the FHIR specification is explicit that Patient/$match does not define a universal matching algorithm, minimum input set, or common threshold strategy. Master patient identifier implementations may require different inputs and behave differently depending on their underlying logic.
Patient mastering goes further. It creates and maintains a trusted, authoritative identity view by continuously reconciling duplicate records, overlays, splits, merges, demographic changes, identifier crosswalks, and exception workflows. Matching asks whether two records appear to describe the same person. Mastering decides how that determination is governed, persisted, corrected, audited, and reused across an enterprise or network.
The need for patient mastering is well-documented. Although federal health agencies recognize patient matching as a critical component of interoperability and the national health IT infrastructure, research on duplicate records has shown how fragile demographic matching can be in practice. In one multisite analysis of nearly 399,000 confirmed duplicate patient record pairs, middle name and Social Security number were among the most frequent mismatch fields, and many name-field discrepancies were caused by misspellings or swapped name components.
The lesson is not that demographics are useless. Demographics alone are a weak foundation for a healthcare system increasingly dependent on precision, automation, and longitudinal insight.
Identity as a prerequisite for clinical reasoning
The stakes become clearer when we look at clinical reasoning. Clinical decision support (CDS), digital quality measurement, and computable guidelines all rely on one thing: knowing exactly which patient you’re looking at with enough history about that patient to make safe decisions. For example, CDS-Hooks is a technical pattern that triggers clinical guidance inside of a clinician’s workflow at the point of care using FHIR to share patient data and recommendations. Clinical quality language similarly depends on patient-centered data to evaluate logic for measures, decision support, and related computable artifacts.
These tools can be powerful but they are only as reliable as the identity context and source data underneath them. If a patient’s history is split across multiple records, a CDS service may miss a contraindication, prior test, diagnosis, or eligibility criterion. If two patient records are incorrectly overlaid, the system may deliver a recommendation for one patient based on someone else’s health history. In quality measurement, the same identity failures can distort denominators, numerators, exclusions, risk adjustment, and outcome attribution.
This is not a technical problem but rather a reasoning one, and it’s why patient identity should be treated as part of the clinical reasoning infrastructure, not as a separate back-office problem. The more we automate healthcare logic, the more identity becomes embedded in every downstream decision. A learning health system cannot learn from fragments. A CDS service cannot reason safely from the wrong chart. A digital quality measure cannot measure accurately if it cannot reliably assemble the person-level record it is measuring.
Why learning health systems raise the bar
The Agency for Healthcare Research and Quality defines a learning health system as one “in which internal data and experience are systematically integrated with external evidence and put into practice so that patients receive higher-quality, safer, more efficient care and healthcare organizations become better places to work.” AHRQ further emphasizes that learning health systems gather and apply evidence in real time, use health IT to share new evidence with clinicians, analyze data and care experiences, and continually assess outcomes to refine processes and training.
Those feedback loops depend on reliable person-level aggregation over time. A health system cannot accurately evaluate whether an intervention improved outcomes if the pre-intervention and post-intervention data are split across different identities. It cannot evaluate access to care if demographic attributes are inconsistent or unreconciled. It cannot safely generalize research findings if its training data is contaminated by duplicate records, overlays, or unresolved identity conflicts. And it cannot scale evidence-based medicine if the evidence it generates is built on unstable identity foundations.
This becomes even more important as healthcare organizations expand the use of artificial intelligence and machine learning. Models trained on fragmented or misattributed patient histories may learn the wrong patterns, reinforce incomplete views of care, or underperform for populations whose demographic data is less complete, less stable, or less consistently captured. Patient identity is therefore not only an interoperability concern, but a data quality, analytics, safety, and governance concern.
From local matching to governed identity services
To move forward, we should consider FHIR’s tools as building blocks to solve patient identity, but understand that, on their own, they cannot deliver confident patient matches 100% of the time. FHIR’s patient resource, identifiers, links between patient records, and Patient/$match operation are useful, but should align with FHIR-adjacent identity patterns. A learning health system needs these building blocks to sit inside a broader governance framework that addresses how identity is created, matched, mastered, corrected, audited, and shared.
At minimum, that framework should include standardized expectations for matching APIs, required and recommended demographic inputs, identifier strategies, match confidence scoring, exception handling, merge and split workflows, data provenance, and feedback loops for improving source data quality. It should also distinguish between different identity use cases. The threshold for returning a likely match during patient access may not be the same as the threshold for merging records, releasing sensitive information, attributing quality outcomes, or training an analytic model.
This presents CMS with a unique opportunity. CMS programs increasingly depend on digital infrastructure that assumes reliable person-level data (quality measurement, prior authorization, value-based payment, beneficiary access, public reporting, population health analytics, and program integrity). A CMS-led patient identity governance framework could help move the industry beyond isolated matching engines and toward a more consistent identity layer for FHIR-enabled exchange.
Such a framework would not require a single national identifier to create value. It could instead establish expectations for how identity services behave, match quality is measured, demographic data quality is improved, authoritative identity decisions are governed, and FHIR and FHIR-adjacent technologies are deployed to support those workflows.
The goal should be pragmatic: make identity a first-class design concern in every national interoperability initiative. If patient identity remains implicit, every downstream use case will continue to absorb the cost of ambiguity. But when identity is explicit, governed, and measurable, FHIR-based exchange becomes more than data transportation—it becomes the foundation for patient mastering and its benefits: safer automation, more accurate measurement, more trustworthy analytics, and a healthcare system capable of learning from its own experience.