FHIR Server Comparison: HAPI, HealthLake, Azure and Google

Approximately two-thirds of US non-federal acute-care hospitals used a FHIR API for patient access through apps in 2022, according to the ONC hospital API data brief. Engineering leads conducting a FHIR server comparison now have to distinguish widespread interoperability adoption from the capabilities their own backend must deliver. This comparison covers operating models, conformance, authorization, ingestion, compliance boundaries, and exit risk.

For a shortlist, start with HAPI FHIR when runtime control justifies operating the server yourself, or a managed service when your team accepts the provider's infrastructure boundaries. Commercial options deserve evaluation when contractual support or packaged capabilities matter, but every candidate must pass your actual integration tests.

Open-source and managed FHIR servers at a glance

AWS HealthLake is a HIPAA-eligible managed FHIR R4 data store, while HAPI FHIR is an open-source Java FHIR server and library operated in the customer's environment. Those descriptions come from the AWS HealthLake developer guide and the HAPI FHIR project, respectively.

FHIR server options by model, FHIR version and HL7 v2 scope

Option	Model and operator	FHIR version documented	HL7 v2 scope	HIPAA-eligible managed path
HAPI FHIR	Open-source Java server and library; customer-operated	Confirm selected release	Verify separately; plan an interface engine	Customer-operated compliance boundary
AWS HealthLake	AWS-operated managed data store	R4	No native HL7 v2 conversion; C-CDA and CSV conversion to R4 (Data Transformation Agent, in preview)	AWS BAA and eligible services only
Azure Health Data Services	Microsoft-operated managed service	R4	Confirm ingestion and conversion scope	Microsoft BAA and eligible services only
Google Cloud Healthcare API	Google-operated managed stores	Confirm store version before creation	HL7 v2 stores included	Google Cloud BAA and eligible services only
Smile CDR	Commercial server; operator set by contract	Obtain release-specific confirmation	Obtain written module scope	Confirm hosting, BAA, and service coverage
Medplum	Commercial platform; operator set by contract	Obtain release-specific confirmation	Obtain written ingestion scope	Confirm hosting, BAA, and service coverage

Microsoft's Azure Health Data Services documentation describes FHIR alongside DICOM and MedTech device-data services, with Entra ID and Microsoft analytics integration. Google Cloud Healthcare API documentation describes FHIR, HL7 v2, and DICOM stores, de-identification, and integration with BigQuery and Vertex AI.

Treat this as a 2026 evaluation baseline, not a dated verification of every current feature. Confirm service scope, eligibility, release support, deployment, and license terms in current documentation or the contract.

Self-hosting assigns patching, scaling, backups, observability, and incident response to customer engineering. Managed services transfer server operations to the provider, while customers retain configuration, access policy, mapping, and evidence.

For budgeting, see our EHR integration cost guide. Our FHIR platform engineering approach starts by assigning those responsibilities before selecting infrastructure.

FHIR version support and conformance testing

A version label establishes the resource model; conformance evidence establishes whether an implementation supports your workflow. The HL7 conformance module defines the role of CapabilityStatement, profiles, OperationDefinition, SearchParameter, terminology bindings, and implementation guides.

HealthLake and Azure document R4 support. Confirm Google's selected store version and HAPI's selected release; this comparison makes no R5 support claim for any platform.

Use the following acceptance sequence:

1. Validate representative Patient, Observation, DiagnosticReport, and other required resources against the target implementation guide.

2. Compare the server's CapabilityStatement with required interactions, conditional writes, validation, and terminology behavior.

3. Exercise named search parameters, modifiers, chaining, and pagination.

4. Check error responses, unsupported parameters, and OperationOutcome content.

5. Retain test fixtures, responses, configuration, and release identifiers beside throughput and latency results.

A server can accept R4 resources yet fail a required US Core, AU Core, or payer workflow. Include Inferno where its selected conformance tests apply, but don't treat a passing subset as proof of every production requirement.

Search behavior needs explicit assertions

Test GET [base]/Patient?name=Smith against expected matches, rather than accepting an HTTP success status. Storing Patient JSON doesn't establish the required search semantics.

The FHIR R4 HTTP specification constrains cross-type searches such as GET [base]?_type=Condition,Observation to parameters shared by both resource types. Verify Bundle pagination links, actual matches, included resources, and unsupported-parameter handling.

Retain expected resource identities in search tests. Matching counts alone can conceal incorrect results.

SMART authorization and bulk data export

A backend-service token that passes every read test in staging can still fail the first time it tries to kick off a system-level $export. Read authorization and export authorization are granted through different scopes, often through different configuration paths, so treat them as separate acceptance criteria.

For SMART on FHIR implementation, require agreement on OAuth behavior, supported SMART version, and scope syntax. Check whether the deployment expects older scopes such as patient/*.read or granular scopes such as patient/Patient.rs; don't assume they're interchangeable.

Test identity and export independently

Engineering verifies SMART configuration discovery, token validation, resource-level restrictions, and backend-service client authentication. The identity team owns the identity provider and trust configuration. Compliance reviews whether the resulting audit evidence supports organizational policy. When a token fails, the failure report should name which of these three parties owns the fix.

For every candidate, record these answers rather than filling the matrix with an unsupported yes:

Candidate group	SMART evidence	Bulk evidence
HAPI FHIR	Deployed authorization layer and negative-access tests	Enabled export implementation and completion test
HealthLake, Azure, Google	Current service authentication documentation and configured identity flow	Supported export mechanism, permissions, retention, and failure responses
Smile CDR, Medplum	Contracted version and configured authorization behavior	Licensed feature scope and demonstrated export result

Bulk acceptance should cover kick-off, polling, NDJSON retrieval where supported, download expiration, throttling, and partial failure. Verify whether export requires system-level authorization and whether the identity provider supports the required integration. Entra ID, AWS IAM Identity Center, and a self-managed provider aren't interchangeable configuration choices.

The FHIR R4 SearchParameter definition establishes named search semantics. For export-adjacent queries, include _count maximum-page behavior, allowing fewer returned results, and test _since and _at in their applicable history or synchronization contexts rather than assuming universal support.

For incremental export, test the supported _since behavior against known resource versions and timestamps. Include negative cases: a token that reads Patient but cannot export, an expired download URL, and a completed job with missing output.

HL7 v2 support and interface engine pairing

A FHIR backend and an HL7 v2 interface engine perform separate jobs. For an incoming ADT or ORU feed, design the engine to receive messages, map identifiers and segments, validate resulting resources, and write them to the backend.

HealthLake requires a separate HL7 v2 conversion path. Google's HL7 v2 store provides message storage, but don't equate storage with your required Patient, DiagnosticReport, and Observation mappings; confirm transformation behavior separately.

Failure	Recommended control	Replay evidence
Duplicate ADT messages	Idempotent upsert keyed on EHR identifier	Stable Patient count after replay
EHR identifier mismatch	Integration-owned identifier mapping	Correct references and patient association
Out-of-order updates	Source-aware event ordering and stale-write protection	Expected final patient state

Use MSH-10 for message identity and deduplication, not as a guaranteed sequence number. Evaluate EVN-2 with the sender's event semantics before using it for ordering; timestamps alone may not resolve every conflict.

Hypothetical worked example: An engine receives an ADT message, resolves the EHR identifier, validates a mapped Patient, and performs an idempotent write. It then receives an ORU message and writes linked DiagnosticReport and Observation resources; replaying both messages must preserve the expected counts and final state.

Our insights compare Mirth Connect alternatives, including Open Integration Engine, BridgeLink, commercial engines, and cloud services. For a downstream application such as a clinic AI assistant, keep that ingestion contract separate from application behavior.

HIPAA eligibility and shared responsibility

Ask this in the architecture review: which HIPAA control can the customer prove today, with an owner and an artifact? A HIPAA-eligible label answers whether a service can be brought into scope; the agreement, approved boundary, configuration, and risk acceptance still sit with the customer.

The HHS encryption FAQ states that encryption under 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii) is an addressable implementation specification. The regulated organization must assess whether encryption is reasonable and appropriate, then document the decision and any equivalent alternative safeguard.

Assign controls before collecting evidence

A responsibility split becomes defensible when each control names an owner and an artifact. Vendor documentation establishes service scope and BAA terms; the risk-owner mapping and evidence standard here are Ekipa's engineering view.

Control	Self-hosted deployment	Managed deployment	Evidence
Infrastructure patching	Customer	Provider within contracted boundary	Change tickets plus provider assurance reports
Access configuration	Customer	Customer	IAM exports, policy review sign-off
Keys and TLS	Customer-configured boundary	Shared, per service configuration	KMS policy, TLS settings, rotation log
Backup recovery	Customer	Shared, per service capabilities	Restore-test output with completion status
Risk analysis	Customer compliance function	Customer compliance function	Approved risk register and decisions

On any cloud, sign the provider's BAA and run PHI only on HIPAA-eligible services. Check the current eligibility list at procurement and renewal, retain the result, and give every adjacent analytics or automation service its own eligibility check.

For AWS-specific configuration planning, use our HIPAA compliance on AWS discussion. For audit preparation, our HIPAA compliance audit guide works as an operational checklist alongside the HHS requirements.

Collect signed agreements, configuration exports, access logs, key-rotation records, recovery evidence, and risk-analysis decisions. The customer's compliance function owns the legal position.

Ecosystem fit and lock-in risk

A migration can move every resource cleanly and still fail at cutover, because SMART scopes, access policies, and identity mappings live outside the exported data. Ekipa's view: the exposure ratings below are engineering judgment, not vendor claims.

Ecosystem coupling and exit checks by option

Option	Adjacent services	Lock-in exposure	Exit check
HAPI FHIR	Customer-selected infrastructure	Limited provider coupling; customer operating burden	Export and restore into another server
AWS HealthLake	AWS account and surrounding services	Data-store and service coupling	Verify export path and format
Azure Health Data Services	Entra ID, DICOM, MedTech, analytics	Identity and analytics coupling	Exercise identity migration and export
Google Cloud Healthcare API	BigQuery, Vertex AI, DICOM, HL7 v2	Pipeline and schema coupling	Validate export and downstream mapping
Smile CDR	Record contracted integrations	Assess proprietary configuration and extensions	Inventory every proprietary configuration and extension that must be recreated elsewhere
Medplum	Record contracted integrations	Assess application and identity dependencies	Rebuild application dependencies and identity mappings on the target

A portable resource export doesn't carry authorization policies, operational dashboards, custom transformations, or downstream schema assumptions. Assign an owner to rebuild each dependency before declaring migration feasible.

Require another server to load the export and pass the same clinical search assertions before accepting the exit plan.

Set an acceptable recovery window and inspect resource references, identifiers, attachments, and required history. A successful file download alone doesn't prove application portability.

When to self-host and when to choose managed

Choose self-hosting when your team needs runtime control and can sustain operations. Choose managed infrastructure when reducing server-operation responsibilities outweighs restrictions on configuration and extension.

FHIR backend decision matrix by situation

Situation	Leans toward	Risk owner	Evidence to collect
Runtime control, custom behavior, chosen hosting environment	Self-hosted HAPI FHIR	Customer engineering and security	Architecture, patch and backup runbooks
Small team without platform on-call	Managed service	Provider infrastructure; customer configuration	BAA, configuration export, access review
AWS-first estate needing R4 storage	AWS HealthLake	Shared	Current eligibility check and signed BAA
Existing Azure or Google analytics platform	Same-cloud managed service	Shared	Data flows and identity-policy review
Strict national or payer guide	Candidate passing required tests	Engineering and vendor	Retained conformance results
High-volume HL7 v2 feed	Engine/server pair passing replay	Integration team	Counts, final states, replay results

Two columns carry the weight in this matrix. "Risk owner" names the party that answers when something fails, and "evidence to collect" names what must exist before that answer is credible. A row missing either one is still an assumption.

Public, private and hybrid hosting choices matter, but the backend decision still requires workload-specific evidence.

Run a time-boxed proof before commitment: target-guide tests, production-volume export, HL7 v2 replay, and audit-log review. Record latency at actual page sizes and concurrency, and benchmark analytics separately from transactional retrieval.

Conclusion

The decision is a written boundary: who runs the server, who owns each control, and which evidence was retained. Pick the option whose gaps fall on an owner staffed to carry them. For the standards and vendor programs around these choices, see our EHR integration and interoperability guide.

If you want help choosing or running a FHIR server, book a consultation with Ekipa's HealthTech engineers.

Frequently asked questions

Which FHIR server should a small engineering team choose?

Start with a managed service in the existing cloud if its conformance and authorization behavior meet requirements. Reject it if the proof exposes gaps your team can't safely maintain around.

Does an HL7 v2 store replace an interface engine?

Not automatically. Verify message transport, mapping, acknowledgments, retries, and reconciliation before assigning those responsibilities to a storage service.

What evidence should exist before procurement sign-off?

The artifacts named in the matrix's evidence column for the chosen row: a signed BAA and access review for a managed service, patch and backup runbooks for self-hosting, retained conformance results where a guide applies, and replay results where an HL7 v2 feed exists. Sign-off is premature while any required artifact is missing.

What should trigger a re-evaluation?

Revisit the decision when the workload outgrows what the proof covered: a new national or payer guide, a second HL7 v2 feed, a change of hosting provider, or a major server version upgrade. Rerun the affected proof rather than the entire matrix.