FHIR Master Patient Index: A Buyer's Guide for Healthcare CIOs

A master patient index is the identity layer that prevents one patient from showing up as three records across different parts of a healthcare organization. In the FHIR era the MPI is also the connective tissue between FHIR Patient resources and the broader landscape of EHR, lab, and payer systems that still carry their own identifier domains. Selecting one is a CIO-level decision rather than a vendor-side technical choice, because the implications ripple across compliance, clinical safety, and downstream data quality. For more on the patient-matching space, see additional MPI and patient-matching notes.

This guide covers the criteria that matter during procurement, the vendor classes that show up most often in CIO shortlists, and how the fit shifts by organizational scale.

Evaluation Criteria For An MPI In 2026

Six criteria carry the most weight.

Matching algorithm transparency. The MPI has to explain why it linked or did not link two records. Algorithms hidden behind a vendor wall create audit problems that compound over time.

FHIR Patient resource conformance. The MPI has to read and write FHIR Patient resources cleanly, including the identifier-slicing patterns the organization uses internally.

Performance under matching load. Large organizations run millions of matching operations per day during peak periods; the MPI has to handle the throughput without backing up the rest of the integration pipeline.

Handling of edge cases. Newborns, twins, name changes after marriage, address moves, and homeless populations each break the naive matching path. The MPI engines that handle newborn and twin records walkthrough covers the most-discussed edge case.

Integration with the rest of the identity stack. The MPI has to talk to the EHR, the registration system, the lab feeds, and the payer-facing FHIR surface without introducing a second identifier domain.

Audit and remediation tooling. CIOs answer for the MPI's decisions; the tool has to expose the audit trail and provide a workflow for remediating bad matches.

Vendor Classes That Show Up In CIO Shortlists

The market in 2026 sorts into three classes.

The first is the enterprise MPI class, where IBM Initiate, NextGate, and Verato sit. These are mature commercial products with deep US healthcare deployments, strong audit tooling, and procurement processes that fit CIO-level decision making.

The second is the FHIR-native MPI class, where Aidbox Patient Matching, Smile Digital Health's MPI module, and several smaller vendors operate. These are newer products that treat FHIR Patient as the primary data model rather than translating from a legacy MPI representation.

The third is the open-source class, where OpenEMPI and a few community-maintained projects exist. Adopted mostly by organizations with strong engineering capacity and a preference for transparent matching logic.

How The Fit Shifts By Scale

Large hospital systems and health information exchanges almost always land on an enterprise MPI for the audit tooling and the procurement profile. The multi-hospital systems walkthrough covers this segment in detail.

Mid-size systems split between the enterprise class and the FHIR-native class, with the choice usually turning on how FHIR-anchored the rest of the architecture is. Smaller organizations and FHIR-first startups lean toward the FHIR-native or open-source class for the cost shape and the architectural fit.

Algorithm choice carries its own decision weight regardless of vendor class; the deterministic versus probabilistic walkthrough covers the matching-logic axis that often gets discussed in parallel with vendor selection.