Five years at Opala gave me hands-on time across the four FHIR servers that matter. Intersystems IRIS for Health, Smile CDR, and Fire.ly Server I shipped to production: picked, configured, tuned, broken, and fixed under real load with real audit pressure. HAPI FHIR I have used extensively in test, evaluation, and conformance work, but never shipped a production payer or provider endpoint on stock HAPI directly. (Smile CDR runs HAPI underneath, so a lot of HAPI internals were in scope anyway.) The notes below reflect that distinction honestly.
Most comparisons of these are written by vendors or analysts who have never had to operate one for real. This is not that. This is what a practitioner notices after the demo is over and the surveillance window opens.
The honest summary first
| Server | Best at | Worst at | Pick when |
|---|---|---|---|
| Intersystems IRIS for Health | High-volume EHR-grade workloads, multi-protocol (HL7 v2 + FHIR + DICOM in one engine) | Licensing cost, ObjectScript learning curve, lock-in friction | You are a hospital system or large payer that already runs IRIS or Caché, or you need v2-to-FHIR bridging in one product |
| Smile CDR | Production-managed HAPI with enterprise auth, MDM, and an actual support contract | Cost, opinionated config patterns, you are still running HAPI underneath | You want HAPI's flexibility without owning the operations, and you need vendor accountability for HIPAA audits |
| HAPI FHIR (extensive use, not shipped in prod) | Standards conformance, customization, community velocity, free | You operate it. All of it. Forever. | You have a strong engineering team, you want full control, and you can carry the on-call |
| Fire.ly Server | .NET shops, US Core profile validation, clean implementation guides | Smaller community than HAPI, Windows-centric history | You are on Azure or .NET, or you specifically need Fire.ly's validator strengths |
Pick the server that matches the team you have, not the team you wish you had. The biggest production failure I have seen is a startup adopting HAPI because "it's free" and then discovering that operating HAPI well is a full-time engineering job.
Intersystems IRIS for Health
What it is good at
IRIS for Health is the only one of these four that genuinely handles enterprise EHR-class workloads out of the box. The multi-model engine (relational, object, document, key-value in the same data layer) means you can serve FHIR, HL7 v2, and DICOM from a single product. For health systems already running InterSystems Caché or Ensemble, the migration path is short.
Where it hurts
- Licensing. Enterprise pricing. Not a Series A budget.
- ObjectScript. If your team is Java-or-Python-only, you will hit the productivity wall fast. Hiring is harder than for any other server on this list.
- Lock-in. Once your business logic is in ObjectScript, leaving is a project. Plan accordingly.
Production note
For real-time clinical workflows where downtime is unacceptable and PHI volumes are massive, IRIS earns its price. For everything else, look at the alternatives first.
Smile CDR
What it is good at
Smile CDR is HAPI FHIR with the enterprise edges sanded down. Authentication, authorization, multi-tenancy, MDM (master data management), terminology services, all preconfigured and supported. The support contract matters: when surveillance lands and a regulator asks you for evidence, you have a vendor who is accountable for the FHIR endpoint behavior.
Where it hurts
- Cost. Not as expensive as IRIS, but no longer free.
- Opinionated config. Smile makes certain decisions for you (deployment patterns, MDM behavior, SMART config). If you want to do something different, you are working against the grain.
- Still HAPI underneath. When you hit a deep bug, you are debugging HAPI internals. The vendor abstraction is real but not absolute.
Production note
For a digital health company that wants HAPI's standards alignment without owning operations, Smile CDR is often the right tradeoff. The support contract has saved us during audits more than once.
HAPI FHIR
What it is good at
HAPI is the reference implementation that the FHIR specification authors lean on. Standards conformance is excellent. The codebase is Apache 2.0, the community is large, and you can fix anything you find. Most public FHIR test sandboxes, including ONC Inferno examples, work cleanly against HAPI.
Where it hurts
- You operate everything. JVM tuning, JPA tuning, database choice, partitioning, terminology service hosting, security model, audit logging. There is no managed-service version that is free.
- Documentation gaps. Excellent for happy paths. Sparse for production tuning, multi-tenancy patterns, and the kind of edge cases an OCR auditor will ask about.
- Performance ceiling. HAPI is fast for most workloads, but at high concurrency you will be tuning JPA, caching, and database indexes for weeks. That work is not optional.
Practitioner note
I have used HAPI extensively in evaluation, conformance testing, and as the substrate of Smile CDR, but never shipped stock HAPI as a production payer or provider endpoint. The strengths and gotchas above reflect that: hands-on with the codebase and the tooling, not on-call ownership of a live HAPI deployment at scale. HAPI is the right pick when you have engineering depth and you want full control over your FHIR layer. It is the wrong pick when your engineering team is small and your runway is short. "Free" in licensing is "expensive" in headcount.
Fire.ly Server
What it is good at
Fire.ly's strength is profile validation. Their tooling for US Core and other implementation guides is among the cleanest available, and for .NET shops the integration story is smooth. The free public test server (server.fire.ly) is also the one I most often use to demonstrate what a passing HTI-1 capability discovery looks like in a TAP audit.
Where it hurts
- Community size. Smaller than HAPI. Stack Overflow answers are sparser.
- .NET-centric history. Improving on cross-platform, but if your stack is Java or Python you are paying a higher integration tax than with HAPI.
- Commercial tier complexity. The licensing matrix has gotten richer over time. Read the terms before you commit.
Production note
For Azure or .NET shops, Fire.ly often beats HAPI on developer productivity. For everyone else, it is the second-look option.
What I tell payer and provider engineering teams
The right question is not "which FHIR server is best?" It is "which FHIR server matches the team and operational model I actually have?"
- Big hospital system already on InterSystems, real-time multi-protocol needs: IRIS.
- Digital health Series A or B, small team, needs managed FHIR with HAPI flexibility: Smile CDR.
- Strong engineering team, full control desired, willing to operate it: HAPI FHIR.
- Azure or .NET shop, profile validation is the workload: Fire.ly.
And whatever you pick: conformance test it against the same suite the certifier will use. ONC Inferno, HL7 Touchstone, your ACB's surveillance script. Find what they would find, while there is still time to fix it. That is what we do at TAP.