Identity resolution is the practical job a master patient index does in a FHIR-based stack. The headline is matching, but the operational reality requires several features working together. The five features below are the ones a serious MPI has to handle well in 2026 to be useful in production, with notes on why each one matters and what a weak implementation looks like.
For broader context, more on healthcare data exchange is a useful starting point.
The Five Features That Matter
- Standards-Conformant $match Operation. The FHIR $match operation is the canonical entry point for identity resolution requests. An MPI that handles $match conformantly, including the required parameters and the expected response shape, integrates cleanly with other FHIR systems. An MPI that exposes a non-standard matching endpoint forces every consumer to write custom integration code, which adds friction at every touch point.
A strong implementation honors the spec and surfaces the match score in the response, with enough metadata for the caller to act on the result without a second round-trip.
- Patient.link Semantics. When two records resolve to the same patient, the MPI has to express that resolution in a way downstream systems can act on. The FHIR Patient.link element, with its semantic codes for replaced-by, replaces, refer, and seealso, is the canonical mechanism. An MPI that emits Patient.link relationships with the right semantics keeps downstream consumers honest about which Patient resource is authoritative for which workflow.
A weak implementation either skips the link relationships or uses them inconsistently, which forces consumers to build their own resolution layer on top of the MPI.
- Audit Trail That Survives Review. Identity resolution decisions have to be auditable. A regulator, a compliance reviewer, or an internal audit team needs to be able to ask why two records were merged and get a clear answer. A strong MPI captures the matching evidence, the algorithm version, the operator if a human approved a review-queue item, and the timestamp of the decision.
A weak audit trail surfaces a Boolean match result without the underlying evidence, which fails the first serious review.
- Configurable Match Thresholds and Review Queue. Real identity workflows have to handle the gray zone where the matching engine cannot decide confidently. A strong MPI exposes the threshold controls to the operations team and routes uncertain cases to a review queue that a human operator can work through. The deterministic vs probabilistic patient matching for FHIR systems walkthrough covers the engine trade-offs in more detail.
A weak implementation hardcodes the thresholds and either auto-merges too aggressively or drops too many cases to a default-non-match, both of which create downstream cleanup work.
- Federation-Ready API. FHIR-based identity resolution increasingly spans organizational boundaries. A strong MPI exposes its match results in a way that other networks can consume, including stable Patient logical identifiers and link relationships that survive cross-organization references. A weak implementation locks the identity model inside a single deployment, which forces every cross-network use case into custom integration work.
How These Features Combine in Production
The pattern that holds across mature MPI deployments in 2026 is that no single feature carries the implementation. The five features above have to work together: $match has to honor the spec, Patient.link has to express the resolution decisions, the audit trail has to capture the evidence, the review queue has to handle the gray zone, and the federation API has to make the result usable across boundaries.
What a Weak Implementation Costs
A weak feature set on any one of the five creates a downstream tax that grows over time. A non-conformant $match forces every consumer to write custom integration code. A missing Patient.link layer makes downstream consumers build their own resolution layer. A thin audit trail fails the first compliance review. Each tax compounds across the years the MPI is in production.
Where to Go From Here
For broader product context, the top 5 master patient index tools for hospital networks in 2026 shortlist covers the products that implement these features in production. The FHIR Master Patient Index overview is a useful read for teams thinking about the broader architecture.
The honest read is that an MPI that handles all five features is a real platform component. An MPI that handles fewer is a starting point that the team will replace within two or three years.
Sources
- PDF slides, Grahame Grieve (HL7), DevDays 2019 - Managing Patient Merge (Patient.link, $match)
- PDF slides, Francois Peverali, DevDays 2023 - ISIK Specification and Patient-merge
- PDF, ONC, 2014 - Patient Identification and Matching Final Report (foundational)
