Picking a FHIR server is the first decision in building a FHIR platform, but the platform-level decisions that come after are what determine whether the deployment scales cleanly. The five criteria below are what production teams evaluate once server selection is done.
1. Terminology server co-location. Every write needs terminology validation. Every read that returns a coded value benefits from expanded metadata. Running terminology in-process (HAPI's terminology module) or via a colocated network service (Ontoserver on the same subnet) has real latency implications. Cross-region terminology calls add 50-200ms per operation.
2. Authorization architecture. The SMART on FHIR launch spec assumes a separate authorization server. Which one you pick — Keycloak, Auth0, custom OAuth 2.0 implementation — shapes every downstream integration. SMART v2 scopes (Observation.rs vs Observation.read) need explicit scope validation.
3. Bulk export infrastructure. Bulk Data Access IG $export is now table-stakes for CMS-0057 and analytics pipelines. Server support is not enough — you also need output storage (S3 or equivalent), a manifest service, and cleanup of expired export files.
4. Subscription and event delivery. FHIR Subscription requires reliable event delivery. Rest-hook is the common transport, but production systems need retry semantics, dead-letter handling, and back-pressure. Some servers ship these; most need external event infrastructure.
5. Observability at the resource-type level. Per-endpoint metrics (Patient reads/s, Observation writes/s) are useful; per-resource-type metrics (which resource types are hot, which are slow) are more useful. Wire Prometheus or equivalent to expose per-resource stats.
Vendor platform completeness, mid-2026
| Server | Terminology co-located | Auth server | Bulk export storage | Subscription retry | Per-type metrics |
|---|---|---|---|---|---|
| HAPI JPA | In-process | Add-on | Manual | Add-on | JMX |
| Aidbox | In-process | Built-in | Native | Built-in | Prometheus |
| Medplum | Basic | Built-in | Native | Built-in | OpenTelemetry |
| InterSystems IRIS for Health | Enterprise | Enterprise | Enterprise | Enterprise | Enterprise |
FHIR platform selection is not just about server capabilities — it's about which platform-level components ship together and which need to be assembled. Teams that assemble usually take 6-9 months longer than teams that pick a bundled platform, but end up with more flexibility.
