Three FHIR server options dominate US healthcare integrations in 2026: HAPI FHIR (the open-source Java reference implementation), Microsoft Azure Health Data Services FHIR (the managed service inside Azure), and Google Cloud Healthcare API FHIR store (the managed service inside GCP). Between them they cover the great majority of production FHIR workloads — from small SMART apps to national population-health platforms.
Choosing between them isn't about which is "best" — they each win in different contexts. This guide lays out the honest tradeoffs, pricing bands, and use-case fit so you can match the right option to your workload.
We've deployed all three in production for clients — sometimes multiple in the same architecture — so this is a working practitioner's view, not a marketing comparison. For the broader FHIR context, see our FHIR integration guide and healthcare interoperability guide.
1. TL;DR — Which to Pick
- Pick HAPI FHIR if you want maximum control and extensibility, have engineering and operational capacity, plan to run at scale where per-request pricing hurts, or need on-prem / multi-cloud deployment. Best price-performance at enterprise scale; highest operational burden.
- Pick Azure Health Data Services FHIR if you're already on Azure, want tight Entra ID integration for SMART on FHIR, need Synapse/Power BI analytics, or want the cleanest turn-key compliance posture. Best time-to-market for enterprise Microsoft shops.
- Pick Google Cloud Healthcare API if you're on GCP, want BigQuery-native analytics, need FHIR alongside HL7v2 and DICOM stores, or have a data-science/AI-heavy roadmap. Best analytics pipeline of the three.
- Common hybrid pattern: HAPI FHIR as the clinical system of record plus a managed cloud FHIR store for analytics / patient-facing apps. We deploy this for clients where flexibility and analytics both matter.
The rest of this guide expands each dimension in detail.
2. What We Compare
At a glance, the three options:
HAPI FHIR (self-hosted)
Hosting: Open-source Java server you run on your own infrastructure (VMs, containers, Kubernetes)
Pricing: Software free; infrastructure and ops labor cost — typically $400 – $3,500 / month infra + 10–40 ops hours / month
Strength: Maximum control, extensibility, no per-request pricing, cost-effective at scale
Weakness: Operational overhead, HA/DR is your problem, compliance paperwork is your problem
When it fits: You have engineering capacity, need deep customization, plan to exceed 5M FHIR resources, or require on-prem deployment
Azure Health Data Services FHIR
Hosting: Fully-managed PaaS inside Microsoft Azure — part of the broader Health Data Services platform alongside DICOM and MedTech
Pricing: ~$0.40 – $2.50 per 100k requests (tiered); ~$1.20 – $2.50 per GB/month storage; usage-based with volume discounts
Strength: Tight Azure integration, native Bulk Data, strong identity (AAD), HIPAA BAA, regional compliance coverage
Weakness: Vendor lock-in to Azure, extensibility more limited than HAPI, pricing at very high scale becomes significant
When it fits: You're already on Azure, want managed compliance, benefit from AAD / Entra ID integration, and scope is bounded (up to tens of millions of resources)
Google Cloud Healthcare API FHIR
Hosting: Fully-managed service inside Google Cloud — FHIR store as one of multiple data-type stores (DICOM, HL7v2, Consent)
Pricing: ~$1.20 – $3.00 per 100k structured storage ops; ~$0.025 – $0.09 per GB/month storage; egress charges apply
Strength: Excellent analytics pipeline (BigQuery export), HL7v2 alongside FHIR, strong HCLS ecosystem on GCP, Vertex AI integration
Weakness: Per-op pricing adds up with heavy read workloads; fewer healthcare-specific enterprise support options than Azure; complex IAM model
When it fits: You're on GCP, want FHIR + HL7v2 + analytics in one platform, need AI/ML integration, or have a data-science-heavy roadmap
3. HAPI FHIR (Self-Hosted)
HAPI FHIR is the open-source reference implementation maintained by Smile Digital Health (formerly Smile CDR), with a large contributor community. It's Java-based, Apache 2.0 licensed, and used in production by health systems, national programs, EHR vendors, and digital-health startups worldwide.
Architecture
- Spring Boot application running on JVM 17+ (current).
- Relational database backend — PostgreSQL most common; MySQL, MSSQL also supported.
- Optional ElasticSearch / Lucene for free-text and advanced search.
- Deployed as JAR, container, or via official Docker images.
- Scales horizontally behind a load balancer; database is typical bottleneck.
Strengths in production
- Version coverage: DSTU2 through R5. If you need to straddle FHIR versions (not uncommon in HIE work), HAPI is often the only viable choice.
- Extensibility: server interceptors, custom search parameters, custom storage strategies, custom authentication — HAPI is a toolkit as much as a server.
- No per-request pricing: infrastructure cost scales with actual resource usage, not API call volume. Massive advantage at scale.
- Portability: runs on any JVM-capable infrastructure — AWS, Azure, GCP, on-prem, hybrid. Data is in standard Postgres; migrations are tractable.
- Community: active issue tracker, public roadmap, regular releases.
Tradeoffs
- Operational burden: you own patching, HA, DR, monitoring, alerting, backup. For a production clinical workload that requires 24/7 uptime, this is real work.
- Compliance posture: HIPAA Security Rule alignment is your responsibility. You inherit none of the platform's existing BAA coverage.
- SMART on FHIR setup: more assembly required than Azure/Google. Typically involves fronting HAPI with Keycloak, Okta, Auth0, or a custom OAuth 2 server.
- Expertise required: Java, Spring, database operations, HTTP stack tuning. The skill bar is higher than drag-and-drop managed services.
Typical deployment stack (our default pattern)
# Simplified production layout
- HAPI FHIR JPA server (container) x 2 (HA pair)
- PostgreSQL 15+ primary x 1
- PostgreSQL 15+ replica x 1
- NGINX or cloud ALB (TLS termination)
- Keycloak / Okta (SMART OAuth 2)
- Prometheus + Grafana (metrics + dashboards)
- Loki or ELK (log aggregation)
- S3-compatible object store (Bulk Data export)
- Backups + cross-region replication (DR)4. Azure Health Data Services FHIR
Microsoft's managed FHIR offering, part of Azure Health Data Services alongside DICOM and MedTech services. Successor to the Azure API for FHIR service.
What Microsoft operates for you
- FHIR R4, R4B, and R5 server with managed HA, patching, scaling.
- Integration with Microsoft Entra ID (formerly Azure AD) for OAuth 2 / SMART on FHIR.
- Built-in $export to Azure Storage, with Synapse and Fabric integrations downstream.
- Audit logging into Azure Monitor / Log Analytics.
- Regional deployment with data residency options.
- Azure BAA coverage for HIPAA compliance out of the box.
Strengths
- Time-to-market: provisioning in hours rather than weeks.
- Identity integration: Entra ID makes SMART App Launch almost trivial for Microsoft-native deployments.
- Analytics pipeline: $export to Storage, then Synapse or Fabric for analytics, all first-party.
- MedTech integration: if you're ingesting IoMT data, MedTech service plus FHIR service pairs cleanly.
- Enterprise support: Microsoft's healthcare-specific support tier is mature.
Tradeoffs
- Lock-in: portable in principle (FHIR is standard), less portable in practice once Entra ID, Event Grid, and Storage pipelines are wired in.
- Extensibility ceiling: custom resource types, exotic search parameters, and deep server-side logic are harder than with HAPI.
- Cost at scale: per-request pricing adds up for high-volume read workloads; evaluate at your actual scale before committing.
- Azure-only: if your data platform strategy is multi-cloud, this service anchors you to Azure.
5. Google Cloud Healthcare API FHIR
Google's healthcare-specific managed service — FHIR is one of several data-type stores, alongside DICOM, HL7v2, and Consent. Part of the broader Google Cloud Healthcare ecosystem that includes Vertex AI for healthcare, Healthcare Natural Language, and BigQuery healthcare analytics patterns.
What Google operates for you
- FHIR R4, R4B, and R5 store with regional and multi-region deployment.
- Integration with Google Identity Platform for OAuth 2 / SMART on FHIR.
- Native streaming export to BigQuery for analytics — arguably the strongest analytics story of the three.
- Audit logging into Cloud Audit Logs and Cloud Logging.
- IAM-based access control at FHIR store level.
- GCP BAA coverage for HIPAA compliance.
- HL7v2, DICOM, and Consent stores co-resident for unified clinical data platforms.
Strengths
- BigQuery streaming export: FHIR data flowing into BigQuery in near real time, queryable as structured tables. For data-science teams, this is a decisive advantage.
- Vertex AI: model training and inference on FHIR data without moving data out of the platform.
- Multi-store coherence: FHIR + HL7v2 + DICOM in one platform with consistent IAM and logging.
- Developer experience: API design is clean; gcloud CLI and SDKs are mature.
Tradeoffs
- Per-op pricing: heavy read workloads get expensive; model carefully.
- Healthcare enterprise support: fewer healthcare-specific support tiers than Microsoft; compensate with strong self-service docs.
- IAM complexity: GCP's IAM model is powerful but steep for teams not already on GCP.
- GCP-only: similar lock-in concerns as Azure.
6. Comparison Table
Dimension-by-dimension comparison. Use this as a quick reference when communicating tradeoffs to non-technical stakeholders.
7. Hosting Model and Pricing
Pricing is the most-asked question and also the most workload-dependent. The ranges below are educated estimates for 2026; confirm current rates with each vendor and with your specific workload pattern.
Very small (dev / POC)
<10k resources, <1k writes/dayCloud free tiers help here; HAPI on a $40 DigitalOcean droplet works fine
Small production
10k–250k resources, 1k–50k writes/dayManaged services become attractive vs. self-host operational cost
Mid-size (most clinical apps)
250k–5M resources, 50k–500k writes/daySweet spot for managed. HAPI starts to compete once you have dedicated ops staff.
Large (enterprise health system / national vendor)
5M–50M+ resources, 500k–10M+ writes/daySelf-hosted HAPI competes aggressively at this scale if you have operational maturity
Very large (population-health / national HIE)
50M+ resources, 10M+ writes/dayArchitecture decisions dominate over pricing at this scale — often hybrid
For broader cost context across an entire EHR integration program, see our EHR integration cost guide 2026.
8. SMART on FHIR Support
SMART App Launch is the dominant pattern for clinical apps embedded in EHRs. All three platforms support SMART, but with meaningfully different developer experience.
HAPI FHIR
Launch support: Supported via SMART authorization server plugin or external IdP (Keycloak, Okta, Auth0) fronting HAPI
Scopes: Full — launch/patient, patient/*.read, offline_access, openid fhirUser, etc.
Token introspection: Configurable; common to use an external OAuth 2 server with HAPI as resource server
App context: Launch context parameters passed in OAuth response via custom claim configuration
Practical notes: You own the OAuth/OIDC infrastructure — more work but full flexibility and no additional per-token charges
Azure Health Data Services FHIR
Launch support: First-class via Microsoft Entra ID (formerly Azure AD); documented SMART App Launch flows
Scopes: Standard SMART scopes supported; Entra ID app registration per client app
Token introspection: Standard Entra ID token validation
App context: Launch context delivered via standard SMART claims
Practical notes: If you're already in the Microsoft identity ecosystem, integration is clean. Federation to external IdPs is doable but adds complexity.
Google Cloud Healthcare API
Launch support: Supported via Google Identity Platform and IAM; SMART flows documented
Scopes: Standard SMART scopes; per-FHIR-store IAM policies
Token introspection: Google-signed JWT tokens with standard validation
App context: Launch context via custom claims / SMART conformance
Practical notes: Works well for apps embedded in GCP-native experiences; federating to other IdPs requires Identity Platform or external OIDC broker
9. Bulk Data Access
The Bulk Data Access IG ($export) is how population-health, payer, and analytics use cases move large FHIR datasets. Performance and ergonomics differ across platforms.
HAPI FHIR
Export support: Group-level and System-level $export operations supported with Bulk Data plugin
Async jobs: Job-queue backed; requires configuration of persistence and output storage
Output format: ndjson to S3-compatible storage or local disk; configurable
Practical notes: Works well but requires thoughtful resource planning for large exports; scale by adding workers and output storage
Azure Health Data Services FHIR
Export support: Patient, Group, and System-level $export as native service operations
Async jobs: Managed by the service; long-running jobs produce status endpoints automatically
Output format: ndjson written to Azure Storage accounts
Practical notes: The export-to-Storage-to-Synapse pipeline is a major strength of the Azure offering; minimal custom engineering needed
Google Cloud Healthcare API
Export support: FHIR store export to GCS or BigQuery is a first-class operation
Async jobs: Google Cloud Operations long-running job model
Output format: ndjson to GCS, or direct streaming to BigQuery as structured tables
Practical notes: BigQuery export is the best analytics pipeline of the three — often decisive for data-science-heavy projects
10. FHIR R4 and R5 Coverage
R4 remains the production-dominant FHIR version in 2026 because the major EHRs are R4-first. R5 is current normative and adoption is growing — the three platforms differ slightly in how aggressively they ship R5.
- HAPI FHIR: full R4, R4B, and R5 support in current releases; also retains DSTU2/DSTU3 for legacy integrations.
- Azure FHIR: R4 generally available; R4B supported; R5 in varying preview / GA states by region.
- Google Healthcare: R4 generally available; R4B supported; R5 available in preview in most regions.
For greenfield projects in 2026, start on R4 unless you have a specific R5 requirement — your trading partners are almost certainly R4. For deeper FHIR version strategy, see our FHIR integration guide.
11. Developer Experience
Subjective but consequential — teams ship faster on platforms they enjoy working with.
HAPI FHIR
- Strong Java API for both server and client development.
- Public Docker images, GitHub repository with active PRs.
- Local stand-up in minutes via Docker Compose.
- Good community forums, Zulip chat, Stack Overflow presence.
- Documentation is extensive but uneven — some areas excellent, others require source-reading.
Azure Health Data Services FHIR
- Clean portal-driven provisioning; ARM / Bicep / Terraform supported.
- Postman collections and SDK samples for .NET, JavaScript, Python.
- Good first-party documentation; tight integration with Microsoft Learn.
- Azure CLI and az healthcare-apis commands.
- Developer sandbox options limited compared to HAPI's local run.
Google Cloud Healthcare API
- Excellent SDK coverage across languages.
- gcloud CLI is mature and consistent with the rest of GCP.
- Documentation is clean and example-driven.
- Emulators for local development during the build phase.
- Learning curve is steeper for teams not already fluent in GCP IAM.
12. Production Readiness and Compliance
Production readiness covers availability, audit, disaster recovery, and HIPAA/HITRUST/FedRAMP posture.
For an end-to-end HIPAA program context across your whole integration stack, see the healthcare interoperability guide.
13. When to Pick Each
A direct decision framework based on what we see in actual client engagements:
Pick HAPI FHIR when
- You have or are building a Java-capable engineering team that can operate production services.
- Your scope will exceed 5–10M FHIR resources and per-request cloud pricing will bite.
- You need on-prem, hybrid, or multi-cloud deployment flexibility.
- You need deep extensibility — custom operations, exotic search, complex storage strategies.
- You require straddling FHIR versions for legacy partners (DSTU3 alongside R4, etc.).
- Your compliance posture is already built internally and doesn't benefit much from a cloud vendor's turnkey posture.
Pick Azure Health Data Services FHIR when
- Your organization is on Azure and the rest of your stack is Microsoft-native.
- You want identity, eventing, analytics, and compliance to stay inside one cloud.
- SMART on FHIR is a primary workload and you want Entra ID to handle OAuth flows.
- You want Synapse or Microsoft Fabric as the analytics destination.
- Your scope fits comfortably in the managed-tier pricing model.
- You want a strong enterprise support story without building one.
Pick Google Cloud Healthcare API when
- Your organization is on GCP and has BigQuery as its analytics warehouse.
- Your roadmap involves heavy data science or AI on clinical data (Vertex AI integration).
- You need FHIR + HL7v2 + DICOM + Consent stores under unified IAM and logging.
- Your team is comfortable with GCP IAM and infrastructure-as-code on GCP.
- You want streaming export to BigQuery as a first-class capability.
Common hybrid patterns we deploy
- HAPI + cloud analytics: HAPI as the clinical system of record, with nightly ETL into Azure Synapse or Google BigQuery for analytics.
- Mirth + managed FHIR: Mirth Connect for HL7v2 ingestion and transformation, with output posted to Azure or Google FHIR. See our Mirth Connect guide for architectural patterns.
- Multi-region HAPI: two or more HAPI deployments with cross-region replication for DR, especially for large health systems with strong data-residency requirements.
For the broader engine-choice context across integration stacks, see best HL7 integration engines 2026 and Mirth Connect alternatives 2026.
14. Frequently Asked Questions
Which is cheapest — HAPI FHIR self-hosted or one of the managed services?
At small scale, managed services are often cheaper once labor is included. At mid scale, they're roughly at parity with a well-operated HAPI deployment. At enterprise scale (tens of millions of resources), self-hosted HAPI typically wins on cost by a significant margin, provided you have operational staff already. The break-even is usually somewhere between 500k and 5M FHIR resources.
Do all three support FHIR R4 fully?
Yes. All three have production-ready R4 support and are moving toward R5. HAPI FHIR has the most comprehensive version coverage (DSTU2 through R5). Azure and Google both support R4, R4B, and have R5 in various preview states. For greenfield projects in 2026, start on R4 with an eye toward R5 interoperability.
Can I migrate between these later if I change my mind?
Yes, because FHIR is a standard — you can $export from one server and import into another. The migration is primarily operational (re-pointing clients, redoing identity integration, re-provisioning search parameters) rather than data-structural. That said, deeply-customized HAPI servers or workflows tightly coupled to Azure/GCP eventing do increase switching cost. Design for portability if you anticipate migration.
Is HIPAA BAA available with Azure and Google FHIR services?
Yes. Both Microsoft Azure and Google Cloud offer Business Associate Agreements covering their healthcare APIs as standard. Azure Health Data Services and Google Cloud Healthcare API are both BAA-eligible under their respective cloud BAAs — verify by account region and service tier, but for US commercial clouds both have robust coverage.
What about FHIR R5 support?
R5 became the current normative FHIR release in 2023. HAPI FHIR has full R5 support in current releases. Azure and Google both support R5 in preview/GA status depending on region and tier. For most clinical interoperability scenarios in 2026, R4 remains the safer production choice because downstream systems (Epic, Cerner, MEDITECH) are still R4-first, but R5 greenfield work is increasingly viable.
Can I use Mirth Connect with any of these?
Yes — Mirth Connect is commonly deployed as a front-end that transforms HL7v2 into FHIR and posts resources to any of the three. This pattern is common: Mirth does MLLP termination and HL7v2-to-FHIR transformation, then uses a FHIR destination connector to write to HAPI, Azure, or Google. See our {' '}Mirth Connect complete guide for the architectural patterns.
Which has the best SMART on FHIR support?
Azure has the cleanest native SMART experience because Entra ID handles the full OAuth/OIDC flow without additional infrastructure. Google is close behind with Identity Platform. HAPI can deliver an equally good SMART experience but you assemble it from components (HAPI + Keycloak, or HAPI behind an API gateway) — more flexibility, more work. For greenfield SMART apps, managed services are usually faster to build on.
What about Bulk FHIR for population-health use cases?
All three support the Bulk Data IG. Azure and Google have turnkey integrations into their respective storage (Azure Storage, Google Cloud Storage) and analytics (Synapse, BigQuery) platforms. HAPI requires you to build the downstream pipeline yourself — typically to an S3-compatible store and then to your analytics warehouse. For analytics-heavy roadmaps, the managed services offer a significant head start.
Which one does the US government use?
Various agencies use different options. The VA has long-standing HAPI FHIR deployments alongside its FHIR Mapper. CMS uses multiple FHIR servers including cloud-hosted and custom Java implementations. State HIEs vary widely. There is no single federal standard — each program evaluates based on workload, data residency, and existing cloud posture.
Can I run HAPI FHIR on Azure or Google Cloud rather than using their native FHIR services?
Absolutely, and this is a common pattern. Azure Kubernetes Service or Google Kubernetes Engine running HAPI FHIR gives you HAPI's flexibility with the cloud provider's infrastructure benefits. It's often the best of both worlds — managed infrastructure and managed compliance for the cloud platform, plus open-source flexibility for the FHIR server itself. Engineering labor is higher than using the native managed service but lower than bare-metal self-hosting.
Related Reading
- FHIR Integration: The Complete Guide
- HL7 Integration: The Complete Guide
- EHR Integration: The Complete Guide
- Healthcare Interoperability: The Complete Guide
- Mirth Connect: The Complete Guide
- Epic EHR Integration
- Cerner / Oracle Health Integration
- EHR Integration Cost Guide 2026
- EHR Integration Project Timeline
- How to Choose an EHR Integration Partner
- Mirth Connect Alternatives 2026
- Best HL7 Integration Engines 2026
- Mirth Support & HL7 Integration Across the USA
- Mirth Helpdesk
- Our Services