Federated healthcare networks have a harder MPI problem than single-tenant systems do. The data sits across organizational boundaries, the governance has to satisfy several parties, and no single member is authoritative for the identity model. The practices below are the ones that consistently work in federated deployments in 2026, with notes on why each one matters and how to implement it without inviting trouble downstream.
For broader context, the FHIR learning shelf is a useful starting point.
What Federation Changes About the MPI
A single-tenant MPI lives inside one organization that owns the identity model end to end. A federated MPI sits between organizations, each of which has its own Patient identifiers and its own data-entry conventions. The architectural question is no longer just "how do we match" but "who is allowed to assert that two records refer to the same person, and what happens when two members disagree."
The practices below address that broader question across architecture, governance, and operations.
The Practices Worth Codifying
- Stable Logical Patient Identifiers. Each member organization keeps its own Patient identifiers, but the federation needs a stable cross-network identifier that resolves to the same logical patient over time. A working pattern is to assign a network-scoped Patient.identifier with a clear assigning authority that all members trust. The identifier survives source-system migrations, which matters because federated deployments often outlive any one member's EHR.
- Patient.link Across Organizational Boundaries. When the MPI determines that two records refer to the same patient, it has to express that decision in a way downstream consumers in any member organization can act on. Patient.link with appropriate semantic codes is the canonical mechanism. The federation has to agree on which link codes to use for which semantic relationships and to apply them consistently across member systems.
- Distributed Audit With Central Resolution Records. Audit is harder in a federated environment because each member captures local audit data. A working pattern records the resolution decision and its supporting evidence centrally, with member-side audit pointing back to the central record. The central record survives member-side data lifecycle policies, which matters for long-running identity decisions.
- Conflict Resolution Workflow With Defined Authority. Members will occasionally disagree about whether two records refer to the same person. A working federation defines upfront who has authority in a disagreement and what the resolution workflow looks like. The deterministic vs probabilistic patient matching for FHIR systems walkthrough covers how the underlying engine choice affects the kinds of disagreements that arise.
- Member-Side Local Indexes With Central Coordination. A pure-centralized model creates a single point of failure and a single point of governance friction. A pure-federated model creates a coordination problem. A working middle pattern has each member run a local index that handles in-organization matching and a central service that coordinates cross-organization links. Both layers see the same Patient resources, but they operate at different governance levels.
- Versioned Algorithm and Threshold Governance. The matching algorithm and thresholds will evolve. The federation has to agree on a versioning scheme, on how changes are reviewed before they ship, and on how to handle the records that were matched under a prior algorithm version. A working practice captures the algorithm version in the resolution record, which keeps the audit trail honest as the algorithm changes.
- Cross-Network Performance and Availability Targets. The federation has to agree on availability and performance targets that span members. A single member with a slow $match endpoint can degrade the experience for the whole network. A working practice sets cross-network SLAs and routes accordingly when a member is slow or unavailable.
How a Federation Should Roll Out These Practices
The practices above are easier to define upfront than to retrofit after the federation is live. New federations should codify them in the governing agreement before any production traffic flows. The top 5 master patient index tools for hospital networks in 2026 shortlist covers products that support federated deployments well, and the FHIR Master Patient Index overview is the right starting point for broader architectural context. The honest read in 2026 is that federation is the harder MPI mode, and the practices above are the difference between a working federated identity layer and one that quietly accumulates drift.
Sources
- PDF, ONC, current - Master Data Management within HIE Infrastructures (federated MPI patterns)
- PDF slides, Grahame Grieve (HL7), DevDays 2020 - One FHIR Facade for Multiple Servers (federation pattern)
- PDF, ONC, current - Perspectives on Patient Matching white paper
