FHIR-first healthcare platforms put MPI engines under a specific kind of pressure. The platform expects everything to be a FHIR resource, queries to use FHIR search semantics, and integration to happen through FHIR rather than through custom APIs. The MPI engines that fit cleanly into a FHIR-first architecture in 2026 are a narrower set than the broader MPI market.
This list covers the four MPI engines worth shortlisting if you are building or running a FHIR-first healthcare platform. For our FHIR coverage, the broader catalog covers the surrounding ecosystem.
For the architectural framing first, the complete guide to FHIR master patient index in 2026 covers what FHIR-first MPI engines actually need to handle.
The 4 MPI Engines Worth Knowing for FHIR-First Platforms in 2026
Order tracks adoption in FHIR-first platform deployments.
- MDMbox. Health Samurai's standalone FHIR MPI, designed to plug into FHIR-first stacks without coupling to a specific server. Strong deterministic and probabilistic matching with native FHIR query support.
- Aidbox MPI. Bundled with the Aidbox FHIR platform for teams that want one vendor for both the FHIR store and the patient index, with first-class FHIR Patient resource handling.
- HAPI FHIR MDM. The open-source workhorse, included with HAPI FHIR. Suited to teams already running HAPI as their FHIR backend who want the MPI in the same process.
- JEMPI. The OpenHIE community's open-source FHIR-native MPI, with deterministic and probabilistic matching and active development.
What "FHIR-First" Actually Means for an MPI Engine
Three operational behaviors separate genuinely FHIR-first MPI engines from bolt-on:
- Patient resource as canonical. The engine stores and reasons in FHIR Patient shape, not in a parallel proprietary schema that needs translation.
- Native FHIR search. Standard FHIR Patient search parameters work directly against the engine, not through a custom query layer.
- Match results as FHIR. The engine returns match decisions as FHIR resources with explicit provenance, not as a custom JSON shape that has to be re-wrapped.
The four above clear all three bars. MDMbox and JEMPI lead on the standalone-pluggable angle; Aidbox MPI and HAPI MDM lead on the bundled-with-server angle.
Which Engine for Which Platform Architecture
Platforms that already have a chosen FHIR server and want a separate matching layer usually go to MDMbox or JEMPI. Platforms that want one vendor for both the FHIR store and the MPI gravitate toward Aidbox MPI. Teams running HAPI as their FHIR backend tend to add the HAPI MDM module rather than introduce a separate tool.
For the broader FHIR-native MPI market including commercial options, the Top 5 FHIR-native MPI products for 2026 covers the full picture.
For the open-source angle specifically, Top 5 open-source MPI solutions for FHIR stacks covers the no-license-fee side.
How to Pilot a FHIR-First MPI Engine
Take a realistic slice of your patient data as FHIR Patient resources, load into the candidate engine, and run three tests: standard FHIR Patient search against varied demographics, deduplication of intentionally-similar Patient resources, and audit-trail reconstruction for a few merge decisions. The engine that handles all three through native FHIR semantics is the one to short-list.
Anything that requires custom translation between FHIR and the engine's internal schema is one to think twice about for a FHIR-first platform.
Sources
- Patient Matching IG (FHIR-first design reference) - HL7 build.fhir.org
- Patient $match operation specification (FHIR-first canonical operation) - HL7 FHIR R5
- FAST Identity IG (FHIR-first patient matching context) - HL7 Confluence
