A master patient index in a US healthcare deployment is one of those infrastructure pieces that quietly decides whether the rest of the stack holds together. Get it right and patient data flows cleanly across encounters, departments, and external partners. Get it wrong and duplicate records accumulate, clinical decision support fires against incomplete histories, and reconciliation becomes a never-ending operational tax. The decision in 2026 looks different than it did five years ago: more FHIR-native options, more federation patterns, and a higher bar for matching accuracy.
This guide walks through what a master patient index has to do in a US healthcare context, what the questions worth asking actually are, and how to think about the trade-offs between deployment models. For the digital health FHIR primer, the rest of the series covers the surrounding pieces.
What a Master Patient Index Has to Do
The job description sounds simple. A master patient index assigns a stable enterprise identifier to each unique person, links incoming records from each source system to that identifier, and exposes the linkage so downstream consumers can pull every record on the same person through a single lookup. That is the contract.
In a US healthcare deployment, the contract has to hold across messy data. Names get misspelled or change at marriage. Date of birth gets typo'd. Addresses change as patients move. Social security numbers are inconsistently captured. Identifiers from external systems do not always match the format your MPI expects. The MPI has to handle the noise without producing either false duplicates (the same person getting two enterprise IDs) or false matches (two people getting one ID).
The Questions That Matter at Procurement
A handful of questions tend to reveal more than any feature checklist. The first is how the MPI handles probabilistic matching with the messy data your sources actually produce. Marketing decks show match rates against synthetic test data. The number that matters is the rate against your data, which the vendor has to demonstrate on a sample of your real records.
The second is the operational story for resolving close-but-not-certain matches. A working MPI surfaces a stewardship queue for the cases the matcher cannot resolve automatically, and the queue has to be usable by data stewards who are not data scientists.
The third is the integration surface. A FHIR-native MPI exposes its identifiers through standard Patient resources and `$match` operations. A legacy MPI requires custom integration code per source system. The difference becomes visible as the number of source systems grows.
Deployment Models Worth Knowing
US healthcare MPIs split between three deployment models. The single-tenant enterprise MPI runs inside one health system's perimeter, with all the source systems feeding into it directly. This is the dominant model for large hospital networks.
The federated MPI links identifiers across multiple organizations, each running its own enterprise MPI but sharing matches through a federation layer. This is the pattern for health information exchanges, ACO networks, and statewide patient lookup services.
The cloud-managed MPI runs as a service that ingests records and returns linked identifiers, with the matching engine living outside the customer's perimeter. This pattern is growing for digital health products that want patient identity without owning the platform.
The deployment model shapes which vendors fit and which create friction.
Common Procurement Mistakes
Three patterns recur across organizations that ended up replacing their MPI. The match accuracy was measured against tidy test data and never benchmarked against the real data. The stewardship queue was an afterthought, and data stewards drowned in flagged matches the system could have resolved. The integration surface was custom per source, and adding a new source system became a months-long engineering effort each time.
The fix is to require a benchmark against real data, walk through a stewardship workflow with the actual data stewards who will run it, and verify the integration surface speaks a standard (FHIR Patient and `$match`) rather than a vendor-specific API.
Where to Go From Here
Once the criteria are clear, the comparisons start to matter. The top 6 EMPI platforms for cross-state patient reconciliation covers the federation-heavy options, the best patient-matching tools for high-volume EDs in 2026 goes into the hospital-specific deployment shape, and the top 7 probabilistic patient-matching libraries for FHIR stacks takes the developer-facing view.
A master patient index is mostly a question of operational fit: who owns it, how the stewardship queue runs, how new sources integrate. The features look similar across vendors; the operational story is where the decision lives.