MPI architecture choices made at project start shape MPI operations for years. Three architectural patterns cover most FHIR-based deployments.
Architecture 1: Embedded MPI in FHIR server.
MPI logic lives in the FHIR server itself. Every Patient POST triggers matching logic. Aidbox MDM module works this way. Best for single-vendor stacks.
Architecture 2: Standalone MPI with FHIR sync.
Dedicated MPI service (Verato, NextGate) sits alongside the FHIR server. Patient resources sync between them. FHIR server queries MPI for match candidates. Best for multi-source integrations.
Architecture 3: MPI as gateway.
All Patient CRUD goes through MPI as a gateway. MPI decides whether to create new or reference existing Patient. Downstream FHIR server sees only resolved identities. Best for high-volume ingestion pipelines.
Trade-off comparison
| Aspect | Embedded | Standalone sync | Gateway |
|---|---|---|---|
| Ops simplicity | High | Medium | Low |
| Multi-source support | Low | High | High |
| Match sophistication | Basic | Advanced | Advanced |
| Vendor lock-in | High | Low | Medium |
| Merge tooling | Basic | Advanced | Advanced |
Integration with FHIR primitives
All three architectures use Patient.link to represent merges. Downstream systems must follow the link chain for correctness.
Common architecture mistakes
1. Embedded MPI where multi-source integration was needed → migration to standalone. 2. Standalone MPI without gateway → duplicate creation during eventual sync lag. 3. Gateway MPI without proper caching → point-of-care latency spikes.
Vendor state (mid-2026)
| MPI | Embedded fit | Standalone | Gateway |
|---|---|---|---|
| Verato | Add-on | Native | Native |
| NextGate | Add-on | Native | Configurable |
| Aidbox MDM | Native | Add-on | Add-on |
| MITRE FRIL | Standalone only | Yes | Custom |
MPI architecture is a 5-10 year decision. Get the right pattern for your source-count and volume trajectory.
