The single-source MPI versus federated EMPI decision shows up once a US health network has more than a few member organizations and needs to decide how the patient identity layer should be structured across them. Single-source means one canonical index that every member queries. Federated means each member runs its own index and the network coordinates lookups across them. Both patterns work in 2026. The interesting question is which one matches the network's governance, technical, and budget shape.
This walkthrough lays out the trade-offs concretely. For FHIR background reading, the homepage covers more of the underlying interoperability landscape.
What Each Approach Actually Means
A single-source MPI is one matching engine, one canonical patient index, and one set of merge decisions shared across the entire network. Every member sends patient records to the central index, every cross-member lookup runs against the central index, and every merge is recorded once. The classic enterprise MPI deployments at hospital systems run this way.
A federated EMPI is multiple matching engines, multiple local indices, and a federation layer on top that coordinates cross-member queries. Each member retains its own index and its own merge decisions, and the federation layer handles the lookups that span members. State HIEs that span many independent organizations often run this way.
For the broader picture, the master patient index buyer's guide is the right primer.
Where Single-Source MPI Wins
Single-source has three structural advantages. The matching decisions are consistent across the network because the engine is one piece of software with one set of rules. The audit trail is single-rooted, which makes regulatory reviews simpler. And the operational story is one team running one system, which is cheaper than running many systems with a federation layer.
The honest weakness is governance. Single-source assumes the members have agreed on a shared identity authority, which is straightforward inside a single hospital system and harder across a network of independent organizations. The data residency conversation also gets sharper, since one member's data sits in another organization's central index.
Where Federated EMPI Wins
Federated EMPI has the governance advantage. Each member retains control of its own patient index, the data residency is at each member's site, and the merge decisions stay with the member who owns the records. For state HIEs, multi-organization care collaboratives, and ACOs that span independent member organizations, federation is often the only acceptable architecture.
The honest weakness is operational complexity. Multiple matching engines have to be kept in tune, the federation layer has to absorb the cross-member lookup work, and the audit trail spans many systems rather than one. The cost is real and shows up as ongoing engineering work.
How to Decide
A handful of questions usually settle the decision.
- Is the network a single organization, or does it span multiple independent organizations with their own IT governance?
- How strict are the data residency expectations of each member?
- Is the matching decision authority centralized or does each member retain it?
- How much operational capacity does the network have to keep multiple matching engines in tune?
If the answers favour central governance and operational efficiency, single-source MPI is reasonable. If the answers favour member autonomy and data residency, federated EMPI comes out ahead.
Some networks end up running a hybrid where each member retains its local index for source-of-truth purposes but contributes a normalized projection to a central index used only for cross-member queries. The pattern works in some governance contexts and not in others, and the decision is worth getting right before any contract is signed.
The natural companion read is the cloud EMPI vs on-prem MPI guide, which covers the hosting side of the same architectural decision.
Sources
- TEFCA Qualified Trust Framework 2.1 draft - PDF, Sequoia Project RCE, December 2025
- Role of MPI and Record Locator Services in HIE implementation - PDF, AHRQ
- Interoperable Digital Identity and Patient Matching v2.0.0 - HTML IG, HL7 FHIR FAST Identity team, 2025