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.
About this comparison. Practitioner opinion based on direct production experience at Opala (2020 to 2025) and ongoing public-server evaluation. Not legal, procurement, or investment advice. Vendor features, pricing, and product behavior change over time; verify current state with each vendor before purchase.
Vendor corrections welcomed. If a factual claim on this page is inaccurate or has changed since publication, email terry@yourdata.health and the page will be updated within 5 business days, with a visible change log if material.
Last reviewed: 2026-05-16.
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) | Most expensive of the four. Difficult to configure, requires IRIS specialists. ObjectScript learning curve. Lock-in friction. | You are a hospital system or large payer that already runs IRIS or Caché, has IRIS expertise on staff, and needs 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
- The most expensive of the four. Enterprise pricing across licensing, support tiers, and add-ons. Not a Series A budget. Even mid-stage digital health teams typically rule it out on cost alone.
- Very difficult to configure. Standing up IRIS for Health properly is a multi-week effort even for senior engineers. The interoperability productions, namespaces, security model, and FHIR repository configuration each have their own learning curve. Expect to engage InterSystems professional services or hire a contractor who has done it before.
- Requires IRIS specialists. A generalist Java or Python engineer cannot reliably operate IRIS in production. ObjectScript is rare on the open market, and hiring is harder than for any other server on this list. Plan for either dedicated specialists on staff or an ongoing vendor relationship to cover gaps.
- Lock-in. Once your business logic is in ObjectScript and your data is in the multi-model store, leaving is a project. Plan accordingly.
Practitioner note
For real-time clinical workflows where downtime is unacceptable, PHI volumes are massive, and you already have IRIS specialists on the team, IRIS earns its price. For digital health startups, payers running on commodity stacks, or any team without dedicated IRIS expertise, the configuration burden and total cost of ownership push you toward Smile CDR or Fire.ly before you should even consider IRIS.
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.
Side-by-side comparison
One table, four servers, the dimensions that actually matter when you have to operate one. Shipped means I personally took it through a production payer or provider deployment; extensive use means I used it in evaluation, conformance work, or as a substrate, but did not own the on-call.
| Dimension | Intersystems IRIS | Smile CDR | HAPI FHIR | Fire.ly Server |
|---|---|---|---|---|
| Licensing | Commercial, enterprise | Commercial, with support | Apache 2.0, free | Commercial tiers (free dev, paid prod) |
| Hosting model | Self-hosted or vendor cloud | Self-hosted or vendor-managed | Self-hosted (you operate it) | Self-hosted or Fire.ly cloud |
| Primary stack | ObjectScript, Java, Python | Java (HAPI under the hood) | Java / Spring | .NET / C# (cross-platform) |
| FHIR R4 conformance | Strong, multi-protocol (HL7 v2 + FHIR + DICOM) | Strong, HAPI-derived | Reference-grade | Strong, profile-validation strengths |
| US Core / IG validation | Solid | Solid, with managed terminology | Solid, but you wire it | Best-in-class profile validator |
| SMART on FHIR | Supported, configurable | Preconfigured, vendor-supported | Supported, you tune it | Supported, .NET-flavored |
| Multi-protocol (HL7 v2 / DICOM) | Yes, native | Limited | No | No |
| Multi-tenancy | Strong, mature | First-class | Configurable, DIY | Supported |
| Community size | Smaller, enterprise-focused | Mid, growing | Largest in FHIR | Mid, active |
| Vendor support | Yes, enterprise SLA | Yes, contract-backed | Community only | Yes, on commercial tiers |
| Configuration difficulty | High. Multi-week stand-up, requires IRIS specialists | Low. Vendor-guided, opinionated defaults | Moderate. You wire everything, but stack is familiar | Moderate. Cleaner on Azure or .NET, harder elsewhere |
| Operational burden | Moderate (vendor + your specialists) | Low (vendor handles most) | High (entirely on you) | Moderate |
| Cost posture | $$$$ (most expensive) | $$$ | $ (license) / $$$ (people) | $$ to $$$ |
| Practitioner experience | Shipped at Opala | Shipped at Opala | Extensive use, not shipped | Shipped at Opala |
| Best fit | Large hospital systems, multi-protocol shops | Digital health needing managed HAPI | Strong eng teams who want full control | Azure / .NET shops, profile-heavy work |
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 exactly what TAP automates.