Azure API for FHIR provides a fully managed deployment of the Microsoft FHIR Server for Azure. The server is an implementation of the FHIR standard. This document lists the main features of the FHIR Server.
Latest version supported:
Previous versions also currently supported include:
Below is a summary of the supported RESTful capabilities. For more information on the implementation of these capabilities, see FHIR REST API capabilities.
|API||Azure API for FHIR||FHIR service in Azure Health Data Services||Comment|
|update with optimistic locking||Yes||Yes|
|patch||Yes||Yes||Support for JSON Patch and FHIRPath Patch only.|
|patch (conditional)||Yes||Yes||Support for JSON Patch and FHIRPath Patch only.|
|create||Yes||Yes||Support both POST/PUT|
|create (conditional)||Yes||Yes||Issue #1382|
|search||Partial||Partial||See Overview of FHIR Search.|
|chained search||Yes||Yes||See Note below.|
|reverse chained search||Yes||Yes||See Note below.|
In the Azure API for FHIR and the open-source FHIR server backed by Azure Cosmos DB, the chained search and reverse chained search is an MVP implementation. To accomplish chained search on Azure Cosmos DB, the implementation walks down the search expression and issues sub-queries to resolve the matched resources. This is done for each level of the expression. If any query returns more than 1000 results, an error will be thrown.
All the operations that are supported that extend the REST API.
|Search parameter type||Azure API for FHIR||FHIR service in Azure Health Data Services||Comment|
|$export||Yes||Yes||Supports system, group, and patient.|
The Microsoft FHIR Server has a pluggable persistence module (see
Azure Cosmos DB is a globally distributed multi-model (NoSQL, MongoDB, and others) database. It supports different consistency levels. The default deployment template configures the FHIR Server with
Strong consistency, but the consistency policy can be modified (generally relaxed) on a request by request basis using the
x-ms-consistency-level request header.
Role-based access control
The FHIR Server uses Azure Active Directory for access control. Specifically, role-based access control (RBAC) is enforced, if the
FhirServer:Security:Enabled configuration parameter is set to
true, and all requests (except
/metadata) to the FHIR Server must have
Authorization request header set to
Bearer <TOKEN>. The token must contain one or more roles as defined in the
roles claim. A request will be allowed if the token contains a role that allows the specified action on the specified resource.
Currently, the allowed actions for a given role are applied globally on the API.
Request Units (RUs) - You can configure up to 100,000 RUs in the portal for Azure API for FHIR. You'll need a minimum of 400 RUs or 40 RUs/GB, whichever is larger. If you need more than 100,000 RUs, you can put in a support ticket to have the RUs increased. The maximum available is 1,000,000. In addition, we support autoscaling of RUs.
Bundle size - Each bundle is limited to 500 items.
Data size - Data/Documents must each be slightly less than 2 MB.
Subscription limit - By default, each subscription is limited to a maximum of 10 FHIR server instances. If you need more instances per subscription, open a support ticket and provide details about your needs.
In this article, you've read about the supported FHIR features in Azure API for FHIR. For information about deploying Azure API for FHIR, see
FHIR® is a registered trademark of HL7 and is used with the permission of HL7.