Multi-hospital systems run patient matching across more boundaries than a single-site MPI was ever designed for. Different EHR instances, different registration desks, different lab systems, and different identifier policies all converge on the same MPI, and the tool has to hold up across that breadth without producing a different answer to the same matching question on different days. The tools below are the ones US multi-hospital systems converge on in 2026. For more SDC and forms context that overlaps the registration surface, see the FHIR forms and SDC reference.
The full criteria sit in the FHIR MPI buyer's guide; this list narrows the picture to the multi-hospital case.
The MPI Tools That Anchor Multi-Hospital Deployments
- NextGate EMPI. The dominant enterprise choice for US multi-hospital systems, with deep audit tooling and a track record across large health system implementations. Strong support for the federated identifier patterns that multi-hospital systems run into.
- IBM Initiate (now under HCL). The other enterprise anchor, with comparable depth and a procurement footprint that fits multi-hospital CIO purchasing.
- Verato Universal MPI. A newer enterprise option with strong probabilistic matching and a cloud-native deployment story; common in multi-hospital systems modernizing the MPI off older on-prem deployments.
- Smile Digital Health MPI. The FHIR-native MPI module integrated with the Smile FHIR server; chosen by multi-hospital systems running Smile as the primary FHIR back end.
- Aidbox Patient Matching. The FHIR-native MPI capability inside Aidbox; chosen by multi-hospital systems running Aidbox-anchored modernization projects.
What Multi-Hospital MPI Selection Has To Solve
Three demands shape the choice. The first is cross-EHR identifier reconciliation. A multi-hospital system rarely runs one EHR across all sites; the MPI has to reconcile identifiers across multiple EHR domains without flattening the differences that legitimately exist between them.
The second is throughput at peak admission load. Multi-hospital systems see registration peaks that exceed single-hospital peaks by an order of magnitude; the MPI has to handle the throughput without backing up the rest of the registration workflow.
The third is audit and remediation across sites. A bad match at one site has to be remediated in a way that updates the canonical record everywhere; tools that ship cross-site remediation workflows save the system from building it. The patient matching engines for HIE walkthrough covers the adjacent HIE case that often runs the same workloads at even larger scale.
How Selection Settles In Multi-Hospital Systems
The choice tracks the existing identity strategy more than any single MPI feature. Multi-hospital systems with mature audit tooling on a legacy enterprise MPI usually stay on NextGate or Initiate and modernize incrementally. Multi-hospital systems running greenfield FHIR-anchored modernization pick a FHIR-native MPI like Smile or Aidbox for the architectural fit. Multi-hospital systems with active payer-side data-exchange obligations look at the patterns in the payer-driven patient reconciliation walkthrough, where the MPI choice has to align with the payer contracts in addition to the clinical use case.
Sources
- Interoperable Digital Identity and Patient Matching IG v2.0.0 - HTML, HL7 FAST, 2025
- Scaling Patient Identity Solutions: The Role of FAST IG - HTML, HL7 blog, 2024
- FAST Focus: Identity & Patient Matching - PDF, HL7 FAST, August 2024














