Azure Health Data Services vs AWS HealthLake

The Rise of Managed FHIR Platforms

Until recently, ingesting and querying FHIR data in the cloud meant building your own infrastructure: parsing HL7/FHIR bundles, designing a resource store, building a FHIR-compliant API layer, and managing search indexes. Both AWS and Microsoft now offer managed services that handle this for you.

AWS HealthLake (launched 2021) and Azure Health Data Services (the evolution of Azure API for FHIR, expanded in 2022) both provide managed FHIR R4 stores, SMART on FHIR authorization, and export capabilities for analytics. But they differ significantly in architecture, ecosystem depth, and analytics integration.

This guide breaks down what matters most for healthcare data engineering teams choosing between them.

What Is AWS HealthLake?

AWS HealthLake is a HIPAA-eligible, managed data lake service specifically designed for healthcare data. It provides:

• A fully managed FHIR R4-compliant data store
• Automated ingestion from HL7 v2, C-CDA, and FHIR formats
• Medical NLP via AWS Comprehend Medical (extracts ICD-10, RxNorm, SNOMED from unstructured text)
• Direct export to S3 for analytics via Athena, Redshift, or SageMaker
• SMART on FHIR authorization support

Core architecture:

EHR / Payer Source
       ↓
AWS Data Exchange / S3 / Direct API
       ↓
AWS HealthLake (FHIR R4 Store)
       ↓
S3 Export (Parquet)
       ↓
Athena / Redshift / SageMaker

What Is Azure Health Data Services?

Azure Health Data Services is Microsoft's managed platform for healthcare data interoperability. It encompasses three workspaces:

• FHIR Service — Managed FHIR R4 / DSTU2 / STU3 data store (evolution of Azure API for FHIR)
• DICOM Service — Medical imaging data storage and retrieval
• MedTech Service — IoT and device data ingestion (continuous glucose monitors, vitals feeds, wearables)

Core architecture:

EHR / Device / Imaging Source
       ↓
Azure Event Hub / Azure Data Factory
       ↓
Azure Health Data Services (FHIR + DICOM + MedTech)
       ↓
Azure Data Lake Storage Gen2
       ↓
Azure Synapse Analytics / Databricks / Power BI

FHIR Compliance

Both platforms are FHIR R4 compliant, but the depth of resource support differs.

Edge: Azure Health Data Services for FHIR feature completeness and multi-version support. HealthLake is more focused but sufficient for R4-only workflows.

Use the mdatool HL7 Parser to validate and inspect HL7 v2 messages before ingestion into either platform — especially useful when migrating from legacy HL7 pipelines to FHIR-native storage.

Analytics Integration

This is where the two platforms diverge most sharply.

AWS HealthLake Analytics Path

HealthLake exports to S3 as Parquet, which feeds natively into the AWS analytics ecosystem:

• Athena — serverless SQL directly over HealthLake S3 exports
• Redshift Spectrum — query FHIR data from Redshift without loading
• SageMaker — ML model training directly on FHIR resources
• Comprehend Medical — NLP for ICD-10, SNOMED, RxNorm extraction from clinical notes

-- Query HealthLake export in Athena
SELECT
  resource.id                           AS patient_id,
  resource.name[0].family               AS last_name,
  resource.birthDate                    AS birth_date,
  resource.address[0].state             AS state
FROM healthlake_export.patient
WHERE resource.active = TRUE;

Azure Health Data Services Analytics Path

Azure integrates with the Microsoft analytics stack:

• Azure Synapse Analytics — unified analytics over FHIR exports in ADLS Gen2
• Databricks on Azure — most popular for large-scale FHIR transformation
• Power BI — direct connectivity for operational reporting
• Azure Machine Learning — ML over clinical data

Microsoft also provides the FHIR to Synapse Sync Agent — an open-source pipeline that continuously exports FHIR resources to ADLS Gen2 in flattened Parquet format, making FHIR data queryable with standard SQL.

-- Query FHIR Synapse export in Synapse SQL
SELECT
  Id                  AS patient_id,
  Name_Family         AS last_name,
  BirthDate           AS birth_date,
  Address_State       AS state
FROM fhir.Patient
WHERE Active = 1;

Edge: AWS HealthLake for teams already on AWS. Azure Health Data Services for teams on Azure or using Microsoft's Synapse + Power BI stack. Neither platform has a clear analytics superiority — the winner is determined by your existing cloud investment.

NPI Lookup and Provider Data

Both platforms store FHIR Practitioner and Organization resources, but neither provides a built-in NPI validation layer. When ingesting provider data from HL7 feeds or payer files, use the mdatool NPI Lookup tool to validate NPI numbers against the NPPES registry before loading into your FHIR store.

Cost Model

Pricing models differ significantly:

AWS HealthLake

• Storage: $0.023 per GB/month (FHIR store)
• Queries: $0.01 per 1,000 FHIR read operations
• Import: $0.30 per GB ingested
• Export: $0.008 per 1,000 FHIR read operations for bulk export
• Comprehend Medical: Additional per-character NLP pricing

Azure Health Data Services

• FHIR Service: Request-based pricing ($0.018 per 10,000 request units)
• Storage: Azure Blob pricing for ADLS Gen2 ($0.018 per GB/month)
• DICOM Service: Per-transaction pricing
• MedTech Service: Per-message pricing for device data

Practical cost comparison: For a mid-size health system storing 50M FHIR resources and running daily analytics exports, both platforms run $3,000–$8,000/month depending on query patterns. HealthLake tends to be slightly more predictable; Azure can be more economical for read-heavy workloads with Synapse.

Security and Compliance

Both platforms are production-ready for HIPAA workloads. Government healthcare (VA, DoD, Medicaid agencies) may prefer AWS GovCloud for established FedRAMP High authorizations.

Schema and Data Modeling After Export

Once FHIR data is exported from either platform, you still need to build analytics-ready tables. FHIR's nested JSON resource model does not map cleanly to star or snowflake schemas.

The typical mapping for claims analytics:

Use the mdatool Data Modeling tool to design and validate your analytics schema after flattening FHIR exports. For terminology and definitions of FHIR resources in the context of healthcare analytics, see the mdatool Healthcare Data Dictionary.

Once your DDL is drafted, run it through the mdatool DDL Converter to generate warehouse-specific CREATE TABLE statements compatible with Redshift, Synapse, or Snowflake.

Which Platform Should You Choose?

Choose AWS HealthLake if:

• Your primary cloud is AWS
• You want Comprehend Medical NLP for unstructured clinical text
• You are building on Redshift or SageMaker for downstream analytics
• You need FedRAMP High (GovCloud)

Choose Azure Health Data Services if:

• Your primary cloud is Azure or you use Microsoft 365 / Teams in clinical settings
• You need DICOM (medical imaging) alongside FHIR
• You are ingesting IoT / medical device data (MedTech service)
• Your analytics runs on Synapse or Power BI
• You need FHIR DSTU2 or STU3 alongside R4

Use both if:

• You operate in a multi-cloud environment
• You are a health information exchange connecting payers and providers on different clouds
• You need to support multiple EHR vendors with different FHIR version requirements

Summary

AWS HealthLake and Azure Health Data Services are both mature, HIPAA-eligible platforms for FHIR-native healthcare data storage. The right choice is almost always determined by your existing cloud commitment and analytics stack — not by feature gaps. Both platforms have feature-complete FHIR R4 stores and viable analytics export paths.

Invest your engineering energy in the analytics layer above the FHIR store — schema design, data quality, and naming conventions — rather than in platform selection. The mdatool toolkit can help with DDL conversion, SQL linting, naming audits, and healthcare terminology as you build that layer.