
The open-source MPI option used to be a narrow niche. In 2026 it has matured into a credible production path for FHIR-first stacks willing to absorb the operational burden in exchange for full control of the matching logic and predictable cost at scale. The five tools below are the ones FHIR-first organizations actually use rather than the longer list of projects that exist on paper. For more data exchange context, see more on FHIR data exchange patterns.
The general criteria sit in the FHIR MPI buyer's guide; this list narrows it to the open-source slice.
The Open-Source MPI Tools Worth Considering
- HAPI FHIR with `$match` operation. The most widely deployed open-source FHIR Patient matching path. The matching algorithm is configurable and the operation is supported by the broader HAPI ecosystem. Best fit for organizations already running HAPI.
- OpenEMPI. The longest-running open-source MPI in healthcare; pre-dates the FHIR era but has been extended with FHIR adapters in the current generation. Strong for organizations with deep matching-algorithm requirements.
- SantéMPI (Santé Suite). The matching engine inside the broader SantéSuite open-source health information platform; FHIR-native and used in global-health deployments.
- JEMPI (under OpenHIE). A Java-based open-source MPI in the OpenHIE family, with explicit FHIR conformance and a matching-algorithm framework that supports plug-in matchers.
- Synthea-trained matchers with FHIR `$match`. A pattern more than a product: synthetic-data-trained matchers built on Synthea datasets, wired to a FHIR server's `$match` endpoint. Used by FHIR-first research platforms that need transparent algorithms.
What The Open-Source Path Asks Of The Organization
Three demands separate organizations that succeed at open-source MPI from those that do not. The first is engineering capacity. The open-source path requires at least a small dedicated team to operate, tune, and patch the matching engine; organizations without that team rarely sustain the deployment past the first year.
The second is matching-algorithm sophistication. Open-source matchers ship with reasonable defaults but require tuning for the organization's specific population. Teams that invest in the tuning produce match rates competitive with commercial engines; teams that ship the defaults usually run into precision or recall gaps.
The third is the audit and remediation tooling. Commercial engines ship audit dashboards out of the box; open-source engines usually require the organization to build them. The cross-state patient identity walkthrough covers an edge case where the audit workflow gets noticeably harder.
Where Open-Source MPI Fits In 2026
The open-source path fits three organizational profiles. The first is FHIR-first digital-health startups that need cost predictability and transparent matching logic, often willing to extend the open-source engine themselves. The second is academic medical centers running research-oriented FHIR architectures, where the transparent algorithm is a feature rather than a tax. The third is global-health deployments where commercial enterprise MPI licensing is not financially feasible. The FHIR-native platforms walkthrough covers the broader space where commercial and open-source options both compete on architectural fit.
Sources
- Interoperable Digital Identity and Patient Matching IG (foundational) - HTML, HL7 FAST, 2025
- Optimizing Patient Record Linkage in MPI - HTML, JMIR / PMC, 2023
- FAST Focus: Identity & Patient Matching - PDF, HL7 FAST, August 2024












