Azure Health Data Services

About Azure Health Data Services

Azure Health Data Services is Microsoft's managed healthcare data platform for organizations that need to store, exchange and analyze protected health information using healthcare standards such as FHIR and DICOM. It sits inside Microsoft Azure and is aimed at healthcare providers, payers, life sciences teams, health software vendors and data platforms that need managed APIs rather than operating their own FHIR or imaging infrastructure. The service is not a generic database. Its value comes from combining healthcare-specific data models, security controls and interoperability services inside an Azure workspace.

What does Azure Health Data Services include?

Microsoft currently describes Azure Health Data Services as a suite of managed services rather than one database engine. The main components are the FHIR service for structured clinical data exchange, the DICOM service for medical imaging, and the de-identification service for removing or replacing protected health information in unstructured clinical text. A workspace can contain FHIR and DICOM services together, which helps teams keep clinical and imaging data under a related Azure health-data architecture.

The FHIR service exposes a managed REST API based on the HL7 FHIR standard and supports SMART on FHIR for web and mobile application access. The DICOM service supports DICOMweb-enabled systems and applications for storing, searching, retrieving and exchanging medical imaging. The de-identification service can tag, redact or surrogate protected entities in clinical text while preserving more of the structure needed for analytics and research.

How is the FHIR service different from Azure API for FHIR?

Azure Health Data Services FHIR service is the current Microsoft direction for managed FHIR workloads. Microsoft stopped allowing new Azure API for FHIR customer deployments on April 1, 2025 and plans to retire Azure API for FHIR on September 30, 2026. Existing Azure API for FHIR users therefore need a migration plan rather than treating the older service as the long-term destination.

The newer platform is broader than the older Azure API for FHIR because it can combine FHIR and DICOM services within a workspace and adds platform capabilities such as Private Link, customer-managed keys and logging. Buyers evaluating a new healthcare data platform should start with Azure Health Data Services rather than designing around the retiring Azure API for FHIR.

How does the DICOM service handle medical imaging?

The DICOM service is designed for cloud-based medical imaging workflows. Microsoft documents support for storing, managing and exchanging DICOM data with DICOMweb-enabled systems, including studies, series and instances. It also supports extended query tags, a change feed, export workflows and DICOMcast integration for connecting imaging metadata with FHIR records.

Microsoft states that the service can scale from smaller imaging archives to petabyte-scale datasets. Data is replicated with Azure locally redundant storage within a region. Healthcare teams should still evaluate regional availability, network design, retention requirements and downstream imaging workflows before moving large archives, because storage volume and transfer patterns can materially affect cost and migration effort.

What security and privacy controls are available?

Azure Health Data Services is built for protected health information, but using the service does not remove an organization's own compliance responsibilities. Microsoft documents Microsoft Entra role-based access control for health data services, Azure Private Link for private network access, customer-managed keys for supported encryption-at-rest scenarios, diagnostic logging and Azure Policy controls.

Private endpoints are configured at the workspace level and can apply to services inside the workspace. Microsoft also publishes policy definitions that can audit whether FHIR and DICOM services use customer-managed keys and whether FHIR cross-origin access is too broad. Buyers should map these controls to their own HIPAA, GDPR, regional data-residency, audit and least-privilege requirements rather than assuming that deployment alone makes an application compliant.

How does Azure Health Data Services pricing work?

Pricing was checked on August 28, 2026. Microsoft uses usage-based pricing rather than one flat subscription fee. The current pricing model includes dimensions such as structured storage, Blob storage for imaging, API requests, transformation operations, de-identification, export operations and event processing. The exact rate varies by region, currency and Microsoft agreement, so a single universal monthly price would be misleading.

The DICOM service can generate both structured-storage and Blob-storage charges because image metadata and image objects are billed differently. FHIR workloads can also incur costs based on requests and the amount of data stored. Teams planning large imaging, export or transformation workloads should model these meters separately in the Azure pricing calculator instead of estimating from storage alone.

What are the current limitations and lifecycle issues?

Not every healthcare-data scenario is on the same lifecycle. Microsoft's MedTech service deprecation began on May 3, 2025, and Microsoft states that support for active MedTech instances in listed regions ends on May 3, 2028. Organizations using device-data ingestion through MedTech should therefore review migration or replacement plans before expanding that architecture.

The managed FHIR service also has product-specific limits. Microsoft currently documents a maximum FHIR search _count of 1000 records per page, and custom FHIR resources are not supported as first-class custom resource types. Extensions are supported, but custom search behavior can require defining search parameters. These details matter for teams migrating custom or highly specialized FHIR servers.

How should teams deploy or migrate to Azure Health Data Services?

A practical deployment starts with a workspace, then adds the FHIR and DICOM services required by the workload. Teams should decide region, networking, identity, encryption, logging and data-ingestion paths before bulk migration. Applications then access FHIR or DICOM endpoints through standard APIs, while Azure services can be used around them for integration, analytics and AI.

Existing Azure API for FHIR customers should prioritize migration because of the September 30, 2026 retirement date. Imaging migrations should include storage and export-cost estimates, while FHIR migrations should test profiles, extensions, search parameters, SMART on FHIR applications and downstream integrations before cutover. Healthcare data migrations deserve validation with representative clinical data, not only synthetic happy-path samples.

Who should choose something else?

Choose something else if the workload is not primarily healthcare interoperability, clinical imaging or protected health data. A normal transactional application may be better served by Azure SQL Database, Azure Cosmos DB or another general data service. Teams that only need object storage for files may not need a healthcare-specific API layer at all.

Organizations that require full control of a custom FHIR server, unsupported custom resource behavior or a self-managed deployment model should compare open-source or self-hosted FHIR platforms. Teams still planning around MedTech should also account for its announced deprecation and avoid treating it as a new long-term foundation. Azure Health Data Services is strongest when managed FHIR, DICOM, privacy controls and Azure integration reduce more operational work than they add.