This chapter covers Azure Health Data Services (AHDS) with a focus on the FHIR service, a key component for healthcare interoperability on Azure. For the AZ-305 exam, questions on healthcare data solutions appear in approximately 5-10% of exams, primarily in the Data Storage domain (objective 2.4). Understanding FHIR resources, the FHIR service architecture, and integration patterns is essential for designing compliant, scalable healthcare data solutions. This chapter provides the depth needed to answer scenario-based questions about patient data exchange, compliance with HIPAA and GDPR, and integration with existing healthcare systems.
Jump to a section
Imagine a global hospital network where each department speaks a different language: cardiology uses French, radiology uses German, and administration uses Spanish. To share patient records, you need a translator that converts any language into a common standard—say, English—so everyone can understand and exchange information without custom point-to-point translations. FHIR (Fast Healthcare Interoperability Resources) acts as that universal translator. It defines a set of 'resources' (like patient, observation, medication) that are structured in JSON or XML, just as English has standard grammar and vocabulary. When a French-speaking cardiology system sends a heart rate reading, FHIR converts it into a standardized 'Observation' resource with predefined fields (code, value, unit, timestamp). Any system that speaks FHIR can then read it, regardless of its native language. The translator doesn't store the original language; it just ensures the message is understood universally. Azure Health Data Services provides a FHIR service that hosts this translator in the cloud, enabling secure, compliant exchange of healthcare data across different systems—even between on-premises EHRs and cloud apps—without needing custom interfaces for each pair.
What is Azure Health Data Services and FHIR?
Azure Health Data Services (AHDS) is a Platform-as-a-Service (PaaS) offering that provides managed services for healthcare data in the cloud. It includes three core services: the FHIR service, the DICOM service (for medical imaging), and the MedTech service (for ingesting IoT device data). The FHIR service is an implementation of the HL7 FHIR (Fast Healthcare Interoperability Resources) standard, specifically R4 (Release 4). FHIR is a modern standard for exchanging healthcare information electronically. It defines a set of 'resources' that represent granular clinical concepts (e.g., Patient, Observation, MedicationRequest) and an API (RESTful) to manage them. Azure Health Data Services hosts these resources in a scalable, managed environment that supports authentication via Azure AD, auditing, and compliance with regulations like HIPAA and GDPR.
Why FHIR Exists
Healthcare data is notoriously fragmented. Electronic Health Records (EHRs) from different vendors (Epic, Cerner, etc.) use proprietary formats and APIs. Before FHIR, integration required custom point-to-point interfaces (HL7 v2, v3) that were costly and brittle. FHIR provides a standardized, modern API that any system can implement, reducing integration time and cost. It uses web technologies (HTTP, JSON, XML) and is designed for mobile and web applications. The standard is maintained by HL7 International and is now mandated by many health authorities (e.g., the US ONC Cures Act requires certified EHRs to support FHIR).
How the FHIR Service Works Internally
Azure Health Data Services FHIR service is a multi-tenant, managed FHIR server. When a client (e.g., an EHR system or a mobile app) sends a request, the following steps occur:
1. Authentication and Authorization: The request must include a valid access token from Azure AD. The FHIR service uses Azure RBAC to determine if the caller has permission to perform the operation (e.g., read, write, delete). The FHIR service supports SMART on FHIR for granular authorization scopes.
2. API Gateway: The request hits an API gateway that routes it to the FHIR server. The FHIR service supports standard FHIR operations: read, vread (version read), search, create, update, patch, delete, and batch/transaction.
3. Validation: The FHIR server validates the resource against the FHIR specification (e.g., required fields, data types, cardinality). For example, a Patient resource must have a name field. The server also checks for business rules (e.g., a MedicationRequest must reference a Patient).
4. Storage: The validated resource is stored in an Azure Cosmos DB database. Cosmos DB provides low-latency reads and writes, automatic indexing, and global distribution. Each resource is stored as a document with metadata (id, versionId, lastUpdated). The FHIR service uses a custom index on search parameters to enable efficient queries.
5. Search: FHIR search is powerful. The server indexes specific search parameters (e.g., patient name, date of birth, codeable concepts). When a client searches for Patient?family=Smith, the server uses Cosmos DB queries to find matching documents. The FHIR service supports chained searches (e.g., Observation?subject:Patient.family=Smith) and reverse chaining.
6. Versioning: Each resource has a versionId. Every update creates a new version. The vread operation retrieves a specific version. The server retains all versions (configurable retention policy).
7. Export and Import: The FHIR service supports bulk export (using the $export operation) to export all resources of a given type to Azure Storage in NDJSON format. Bulk import is also supported via the $import operation.
Key Components, Values, Defaults, and Timers
Resource Types: FHIR R4 defines over 150 resource types. The most common are Patient, Observation, Condition, MedicationRequest, Encounter, Organization, Practitioner.
API Endpoint: The FHIR service is accessed via a base URL like https://<workspace-fhir-service>.fhir.azurehealthcareapis.com. The workspace is a logical container for FHIR, DICOM, and MedTech services.
Authentication: Requires Azure AD token with audience set to the FHIR service URL. Supported grant types: authorization code, client credentials, and device code.
SMART on FHIR: Uses OAuth 2.0 with scopes like patient/*.read, user/*.write. The FHIR service supports EHR launch and standalone launch.
Search Parameters: Each resource type has a set of search parameters (e.g., Patient.name, Observation.code). The FHIR service indexes these by default. Custom search parameters can be defined (up to 100 per workspace).
Throttling: The FHIR service has limits: 1000 requests per second per instance (default). You can scale up by increasing the number of scale units (each unit adds 10 RUs of Cosmos DB throughput).
Cosmos DB: The FHIR service uses Cosmos DB with a default throughput of 400 RUs per GB of data. You can configure throughput up to 100,000 RUs per container.
Retention: Resource versions are retained indefinitely by default. You can set a retention period (in days) for deleted resources via the $purge-history operation.
Export: Bulk export can export up to 100 GB per job. The output is stored in Azure Blob Storage.
Audit Logs: All operations are logged to Azure Monitor. Logs include caller IP, resource type, operation, and HTTP status.
Configuration and Verification Commands
To create a FHIR service, you first need an Azure Health Data Services workspace. You can use the Azure portal, CLI, or ARM/Bicep templates. Example CLI commands:
# Create a resource group
az group create --name myHealthRG --location eastus
# Create a workspace
az healthcareapis workspace create --resource-group myHealthRG --name myworkspace --location eastus
# Create a FHIR service within the workspace
az healthcareapis fhir-service create --resource-group myHealthRG --name myfhirservice --workspace-name myworkspace --location eastus --kind fhir-R4To verify the service is running, you can make a GET request to the metadata endpoint:
curl -H "Authorization: Bearer <token>" https://myworkspace-myfhirservice.fhir.azurehealthcareapis.com/metadataThis returns a CapabilityStatement resource listing supported operations.
Interaction with Related Technologies
Azure API for FHIR (legacy): The older PaaS offering. AHDS FHIR service is the replacement, with better scalability and integration with DICOM and MedTech services.
Azure API Management: Can be placed in front of the FHIR service for additional security (e.g., IP whitelisting, rate limiting) and transformation.
Azure Logic Apps: Can trigger workflows when FHIR resources are created or updated (via Azure Event Grid integration).
Azure Synapse Analytics: Can connect to the FHIR service via the FHIR export feature to analyze healthcare data.
Azure Machine Learning: FHIR data can be exported to Azure ML for predictive modeling.
Microsoft Cloud for Healthcare: An industry solution that includes FHIR service, Power BI, and Dynamics 365 for patient engagement.
Provision the workspace
Create an Azure Health Data Services workspace in a supported region (e.g., East US, West Europe). The workspace is a logical container that holds one or more FHIR, DICOM, and MedTech services. It provides a common identity and audit scope. Use the Azure portal, CLI, or ARM template. Workspace names must be globally unique within the Azure Health Data Services namespace. Default Cosmos DB throughput is 400 RUs per GB, but you can adjust later.
Create the FHIR service
Within the workspace, create a FHIR service. Specify the kind (fhir-R4) and optionally set the Cosmos DB throughput and scale units. The FHIR service endpoint is automatically generated as `https://<workspace-name>-<fhir-service-name>.fhir.azurehealthcareapis.com`. You can also enable SMART on FHIR and configure CORS. The service is deployed as a multi-tenant PaaS instance.
Configure authentication
Register an application in Azure AD to represent the FHIR client. Set the redirect URIs and API permissions. In the FHIR service, assign roles (e.g., FHIR Data Reader, FHIR Data Contributor, FHIR Data Exporter) to users or service principals. Authentication requires an OAuth 2.0 token with audience set to the FHIR service URL. The token must include the appropriate scopes (e.g., `patient/*.read` for patient-level access).
Ingest patient data
Use the FHIR REST API to create resources. For example, POST a Patient resource to `https://<fhir-url>/Patient`. The server validates the resource, assigns an id (or uses the one provided), and stores it in Cosmos DB. The response includes the resource with the `id` and `meta.versionId` fields. You can also use the `$import` operation for bulk ingestion from NDJSON files in Azure Blob Storage. The import is asynchronous and can handle millions of resources.
Search and retrieve data
Perform searches using FHIR search syntax. For example, `GET https://<fhir-url>/Patient?family=Smith&birthdate=gt1970-01-01`. The server uses indexed search parameters to query Cosmos DB. Results are returned in a Bundle resource with `total` count and `entry` array. The server supports pagination via `_count` and `_offset` parameters. Chained searches allow querying across resource references (e.g., `Observation?subject:Patient.family=Smith`).
Enterprise Scenario 1: Health System Interoperability
A large health system with multiple hospitals uses Epic and Cerner EHRs. They need to share patient data between them and with a new patient portal app. They deploy Azure Health Data Services with a FHIR service. They configure the Epic and Cerner systems to push FHIR resources (Patient, Encounter, Observation) to the FHIR service via the REST API. The patient portal app reads the data using SMART on FHIR. The system handles 500,000 patients and 10 million observations. They scale the FHIR service by increasing Cosmos DB throughput to 10,000 RUs and adding 5 scale units. Misconfiguration: If they don't set proper RBAC roles, the portal app might get 403 errors. They also need to configure CORS to allow the portal's domain.
Enterprise Scenario 2: Clinical Research Data Lake
A pharmaceutical company needs to extract de-identified patient data from multiple clinical sites for research. Each site has a different EHR. They use the FHIR service to normalize data into FHIR resources. They then use the $export operation to export all resources to Azure Data Lake Storage Gen2 in NDJSON format. The export job runs nightly. The data is then processed by Azure Synapse Analytics to create a de-identified dataset for machine learning. Common issue: Export jobs can fail if the target storage account is in a different region or if the FHIR service's managed identity doesn't have Storage Blob Data Contributor permissions on the storage account. They also need to ensure the export doesn't include PHI that should be removed.
Enterprise Scenario 3: IoT Device Integration for Remote Monitoring
A hospital wants to ingest vital signs from home monitoring devices (e.g., blood pressure cuffs, glucose meters). They use the MedTech service in AHDS to ingest device data via IoT Hub. The MedTech service maps the device data (e.g., JSON from a device) to FHIR Observation resources using a device mapping template. The FHIR service stores these observations. Clinicians can view real-time data via a dashboard that queries the FHIR service. The system handles 10,000 devices sending data every 5 minutes. Scaling: The MedTech service can scale to handle high throughput, but the FHIR service must be scaled accordingly. If the mapping template is incorrect, the Observation resources may be malformed, causing validation errors. They use Azure Monitor to set alerts for ingestion failures.
AZ-305 Exam Focus on FHIR
This topic falls under Domain 2: Data Storage, Objective 2.4: Design a data storage solution for healthcare data. The exam tests your ability to choose between Azure Health Data Services and other storage options (e.g., Azure SQL Database, Cosmos DB directly) for healthcare scenarios. Key points:
FHIR Service vs. Azure API for FHIR: The exam may ask which service to use for new deployments. The correct answer is Azure Health Data Services FHIR service because it is the newer, more scalable offering with DICOM and MedTech integration. Azure API for FHIR is legacy but still supported.
SMART on FHIR: Know the two launch scenarios: EHR launch (app launched from within an EHR) and standalone launch (app launched independently). The exam may present a scenario where a patient portal needs to access FHIR data; the correct authorization flow is SMART on FHIR with appropriate scopes.
Bulk Export: The $export operation is used to export data to Azure Storage. The exam may test that the export requires the FHIR service to have a managed identity with Storage Blob Data Contributor role on the storage account. Also, export is asynchronous and can be monitored via the job status endpoint.
Compliance and Security: AHDS is HIPAA eligible and GDPR compliant. The exam may ask about data residency and encryption. By default, data is encrypted at rest with Microsoft-managed keys. Customer-managed keys (CMK) are supported for Cosmos DB (which stores FHIR data).
Common Wrong Answers:
Choosing Azure API for FHIR instead of AHDS FHIR service (trap: both exist, but AHDS is the recommended path).
Thinking FHIR service uses Azure SQL Database (it uses Cosmos DB).
Assuming that FHIR service automatically de-identifies data (it does not; you must use Azure Data Lake or other tools).
Edge Cases:
The FHIR service does not support the $everything operation (returns all resources for a patient) natively; you must implement it via custom code.
The FHIR service has a limit of 100 custom search parameters per workspace.
The MedTech service requires an IoT Hub to be in the same region as the workspace.
How to Eliminate Wrong Answers:
If the scenario involves medical imaging (DICOM), the answer must include the DICOM service, not just FHIR.
If the scenario requires real-time ingestion from IoT devices, include MedTech service.
If the scenario is about exchanging data with external partners, FHIR service with SMART on FHIR is the right choice.
Azure Health Data Services FHIR service is the recommended PaaS for storing and exchanging FHIR R4 resources in Azure.
The FHIR service uses Azure Cosmos DB for storage; throughput can be scaled from 400 to 100,000 RUs.
Authentication requires Azure AD tokens; SMART on FHIR provides granular scopes for patient and user access.
Bulk export ($export) outputs resources to Azure Blob Storage in NDJSON format; requires managed identity with Storage Blob Data Contributor role.
The FHIR service supports up to 100 custom search parameters per workspace.
For medical imaging, use the DICOM service within the same workspace; for IoT device data, use the MedTech service.
Azure Health Data Services is HIPAA eligible and GDPR compliant; supports customer-managed keys for Cosmos DB.
The FHIR service does not de-identify data; de-identification must be done separately.
The FHIR service is multi-tenant but can be isolated via dedicated workspaces.
Azure API for FHIR is legacy; new deployments should use Azure Health Data Services.
These come up on the exam all the time. Here's how to tell them apart.
Azure Health Data Services FHIR Service
Newer PaaS offering with better scalability (supports scale units up to 10)
Integrated with DICOM and MedTech services in the same workspace
Uses Cosmos DB with configurable throughput (up to 100,000 RUs)
Supports SMART on FHIR v2.0
Recommended for new deployments
Azure API for FHIR (Legacy)
Older PaaS offering, still supported but no new features
Standalone service, no native DICOM or MedTech integration
Uses Cosmos DB but with fixed throughput (typically 400 RUs per GB)
Supports SMART on FHIR v1.0
Being phased out in favor of AHDS FHIR service
Mistake
FHIR service can store any type of data, including imaging files.
Correct
FHIR service is for structured clinical data defined by FHIR resources. Medical imaging (DICOM) is stored in the DICOM service within the same workspace. FHIR can reference imaging via the ImagingStudy resource, but the binary data is stored separately.
Mistake
All FHIR resources are automatically de-identified when exported.
Correct
The FHIR service does not de-identify data. Export outputs the exact resources as stored. De-identification must be done separately using tools like Azure Data Factory or custom scripts.
Mistake
The FHIR service uses Azure SQL Database for storage.
Correct
The FHIR service uses Azure Cosmos DB as its underlying data store. This provides low-latency reads/writes and automatic indexing. Azure SQL Database is not used.
Mistake
SMART on FHIR is only for patient-facing apps.
Correct
SMART on FHIR supports both patient-facing and provider-facing apps. It provides granular scopes (e.g., patient/*.read, user/*.write) and can be used in EHR launch or standalone launch scenarios.
Mistake
The FHIR service automatically replicates data across regions for disaster recovery.
Correct
By default, the FHIR service is deployed in a single region. For disaster recovery, you must configure geo-replication at the Cosmos DB level or use a secondary FHIR service in another region with data replication.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Health Data Services FHIR service is the newer, recommended offering. It provides better scalability (scale units up to 10), integrates with DICOM and MedTech services in the same workspace, and supports SMART on FHIR v2.0. Azure API for FHIR is the legacy service that is still supported but not recommended for new deployments. The exam may test this distinction: choose AHDS FHIR service for new projects.
The FHIR service requires Azure Active Directory tokens for all requests. You must register a client application in Azure AD and assign it appropriate roles (e.g., FHIR Data Reader, FHIR Data Contributor). The token must have an audience set to the FHIR service URL. For patient-level access, use SMART on FHIR scopes like `patient/*.read`. Authorization is done via Azure RBAC on the FHIR service itself.
Yes, the FHIR service supports the `$export` operation for bulk export. You can export all resources of a given type (e.g., `Patient`, `Observation`) or the entire data store. The export is asynchronous and outputs NDJSON files to an Azure Blob Storage container. The FHIR service must have a managed identity with Storage Blob Data Contributor role on the storage account. You can monitor the export job via the status endpoint.
The FHIR service uses Azure Cosmos DB as its storage backend. Cosmos DB provides low-latency reads and writes, automatic indexing, and global distribution. You can configure the throughput (RUs) per container. The FHIR service does not use Azure SQL Database or Blob Storage for primary storage (Blob is used only for export/import).
No, the FHIR service does not de-identify data. It stores and serves data exactly as received. De-identification must be performed separately using tools like Azure Data Factory, Azure Machine Learning, or third-party solutions. For example, you can export data, then run a de-identification pipeline before loading it into a data lake.
The MedTech service is part of Azure Health Data Services. It ingests device data from Azure IoT Hub, normalizes it, and maps it to FHIR Observation resources using a device mapping template. The resulting Observations are stored in the FHIR service. This enables real-time remote patient monitoring. The MedTech service must be in the same workspace as the FHIR service.
No, the FHIR service is for structured clinical data (FHIR resources). DICOM images are stored in the DICOM service, which is also part of Azure Health Data Services. The FHIR service can reference DICOM studies via the ImagingStudy resource, but the binary image data is stored in the DICOM service.
You've just covered Azure Health Data Services (FHIR) — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?