Complex FHIR platform deployments use specific integration patterns. Five that show up in enterprise settings.

Pattern 1: FHIR API gateway. Central gateway routes to backend FHIR servers, enforces auth, normalizes responses. Uses FHIR REST spec as canonical contract.

Pattern 2: Multi-tenant FHIR server. Single deployment, multiple tenants isolated by data partition. Common in health plan platforms.

Pattern 3: Federated MPI across systems. Multiple FHIR servers each with local Patient; central MPI federates identity.

Pattern 4: Shared terminology server. One terminology server serves multiple FHIR deployments. Consistent bindings.

Pattern 5: Cross-system audit aggregation. AuditEvent resources from all systems aggregated to central audit store.

When each pattern applies

Gateway responsibilities

1. Auth boundary (SMART tokens, OAuth 2.0). 2. Rate limiting per token/scope. 3. Request routing to backend. 4. Response normalization. 5. CORS handling. 6. Audit logging.

Multi-tenant challenges

1. Data isolation per tenant. 2. Terminology scoping. 3. Cross-tenant leakage prevention. 4. Per-tenant billing/metering.

Federated MPI complexity

1. Match candidates across systems. 2. Merge coordination. 3. Reference resolution across systems. 4. Consistency during network partitions.

Common integration mistakes

1. Missing gateway → auth inconsistency. 2. Multi-tenant without isolation → data leaks. 3. Federated MPI without governance → duplicates. 4. Multiple terminology servers → drift. 5. Fragmented audit → HIPAA gaps.

Vendor tooling

1. API gateway: Kong, Envoy, or custom. 2. Multi-tenant: Aidbox, Medplum multi-tenant modes. 3. Federated MPI: Verato, NextGate cross-source. 4. Shared terminology: Ontoserver, Aidbox terminology. 5. Audit aggregation: custom pipelines.

FHIR platform integration for complex deployments is a design discipline. The five patterns above cover most enterprise settings.