Selecting an HL7 FHIR server requires answering specific questions upfront. Getting these right prevents 6-12 months of downstream rework.

Question 1: What FHIR version and profiles?

R4 with US Core baseline for US deployments. R4B for Subscription-Topic support. R5 for niche cases. Match US Core version explicitly.

Question 2: What write throughput?

Sustained POST/s at expected peak. HAPI ~1500-1800/s, Aidbox ~2500-3000/s, Medplum ~3000-3200/s (moderate hardware). Load-test before commit.

Question 3: What read patterns?

Point-of-care queries (fast, indexed), bulk analytics (via $export), or search-heavy? Different patterns favor different servers.

Question 4: What terminology needs?

SNOMED CT, LOINC, RxNorm baseline. In-process terminology (HAPI, Aidbox) simpler operationally; standalone (Ontoserver) more capable.

Question 5: What auth model?

SMART on FHIR baseline. Built-in (Aidbox, Medplum, Firely) simpler; add-on (HAPI + Keycloak) more flexible.

Question 6: What compliance targets?

CMS-0057 attestation, ONC certification, or state-specific? Different vendors have different conformance depth.

Question 7: What scale trajectory?

Grow to 10M resources or 100M+? Storage backend matters. JSONB Postgres works to 100M; Cosmos DB scales further with more cost.

Selection matrix

Deployment considerations

1. Kubernetes-native deployment. 2. Postgres backup/restore process. 3. Monitoring integration. 4. Team support for chosen stack.

Common selection mistakes

1. Peak throughput as decision criterion (sustained matters). 2. Ignoring terminology needs. 3. Underestimating auth complexity. 4. Assuming vendor claims without verification. 5. Not matching to team's language expertise.

HL7 FHIR server requirements are best captured before RFP. The seven questions above cover most decision factors.