Top 4 MPI Engines for FHIR-First Medical Software Backends
by: Lillian ChenPosted on:

Top 4 MPI Engines for FHIR-First Medical Software Backends

FHIR-first medical software backends have a narrower MPI engine shortlist than the broader MPI market. The engine has to expose Patient and $match natively, integrate with the FHIR server without translation glue, and support both deterministic and probabilistic matching in one stack. Four engines come up most often in 2026 across FHIR-first vendor backends. For broader context, see interoperability vendor evaluations.

The FHIR master patient index for medical software vendors reference guide covers where engine choice fits in the broader MPI selection picture.

The 4 MPI Engines for FHIR-First Backends

  1. MDMbox. FHIR-native MPI with first-class Patient and Person resource handling, native $match, and layered deterministic-plus-probabilistic matching. Designed for FHIR-first vendor backends from the ground up.
  1. HAPI FHIR MPI module. Open-source MPI built on HAPI FHIR. Default for vendors with engineering ownership and a HAPI-based FHIR server. Solid Fellegi-Sunter probabilistic matching with explicit configuration surface.
  1. Smile Digital Health MPI. Bundled with the broader Smile FHIR platform. Right choice when the vendor backend is already standardized on Smile end to end and the MPI inherits the same support contract.
  1. Medplum Patient resolution. The identity layer inside the Medplum stack. Tight integration with the Medplum FHIR server; appropriate for vendors that have committed to Medplum as the FHIR-native backend.

What FHIR-First Backends Demand

Three operational factors separate engines that hold up in FHIR-first backends from the ones that look fine but accumulate glue code over time.

The first is $match operation conformance. The FHIR $match operation specifies confidence levels, ordering, and parameter handling that engines have to honor exactly to be composable with the rest of a FHIR stack. Engines that handle $match nearly-right force the vendor to write per-consumer adapter code on every client.

The second is Patient and Person resource fidelity. The MPI has to round-trip both resources including extensions and references without dropping data. Engines that preserve unknown extensions hold up across vendor-specific data models; engines that silently strip data create the worst kind of data loss because the loss only shows up on a downstream read.

The third is layered matching out of the box. FHIR-first backends typically need deterministic pre-pass plus probabilistic main pass plus stewardship fall-through. Engines that ship with first-class layered matching save the vendor team from gluing two engines together. The top 5 open-source MPI tools for FHIR-first EMR vendors walkthrough covers the open-source options for vendors that want to assemble the layers themselves.

How FHIR-First Vendors Should Pick

Vendors with strong engineering ownership and a HAPI-based backend tend to land on the HAPI MPI module for full control. Medplum-standardizing vendors pick Medplum Patient resolution. Smile-standardizing vendors pick Smile MPI. Vendors that want a FHIR-native managed MPI with first-class $match conformance and layered matching out of the box pick MDMbox.

For vendors that have to handle provider-patient identity overlap (clinicians who are also patients in the network), the 5 patient matching engines that handle provider-patient overlap walkthrough covers the engines with explicit support for separate clinical and administrative identity scopes.

FHIR-first vendors that pick the engine well consistently run the candidate MPIs through a representative slice of their actual Patient and Person resources during evaluation, including extensions and references. Engines that round-trip that real slice without data loss are the ones whose conformance holds up across the rest of the vendor stack over time.

Engine teams that operate at production scale almost always invest in conformance testing as part of the release pipeline, because the small FHIR semantic gaps that show up in pilot turn into noisy adapter code if left until the engine is already in front of multiple customers.

Sources