Frequently asked questions about Azure API for FHIR

The Fast Healthcare Interoperability Resources (FHIR - Pronounced "fire") is an interoperability standard intended to enable the exchange of healthcare data between different health systems. This standard was developed by the HL7 organization and is being adopted by healthcare organizations around the world. The most current version of FHIR available is R4 (Release 4). The Azure API for FHIR supports R4 and the previous version STU3 (Standard for Trial Use 3). For more information on FHIR, visit HL7.org.

Yes, the data is stored in managed databases in Azure. The Azure API for FHIR doesn't provide direct access to the underlying data store.

In the managed service, you can't access the underlying data. This is to ensure that the Azure API for FHIR offers the privacy and compliance certifications needed for healthcare data. If you need access to the underlying data, you can use the open-source FHIR server.

We support Microsoft Entra ID as the identity provider.

No, we don't support B2C in the Azure API for FHIR. If you need more granular access controls, we recommend looking at the open-source FHIR proxy.

Data for the managed service is backed up automatically every 4 hours and two backups are maintained. So the retention duration is 8 hours. Data recovery is done by the support team and the recovery point objective (RPO) is less than 240 minutes.

Customers can make a request to restore the data, or change the default data backup policy, through a support ticket.

We support versions 4.0.0 and 3.0.1. For more information, see the FHIR supported features. You can also read about what has changed between FHIR versions (STU3 to R4) in the version history for HL7 FHIR.

Azure IoT Connector for FHIR (preview) currently supports only FHIR version R4 and is visible on R4 instances of Azure API for FHIR.

Azure API for FHIR is a generally available managed FHIR service. Azure Health Data Services allows you to deploy a FHIR service and a DICOM service in the same workspace. The Azure Health Data Services overview provides more details.

Azure API for FHIR is a hosted and managed version of the open-source Microsoft FHIR Server for Azure. In the managed service, Microsoft provides all maintenance and updates.

When you run the FHIR Server for Azure, you have direct access to the underlying services, but we're responsible for maintaining and updating the server and all required compliance work if you're storing PHI data.

We have general availability for both public and government in multiple geo-regions. For information about government cloud services at Microsoft, see Azure services by FedRAMP.

The release notes page provides an overview of everything that has shipped to the managed service in the previous month.

For more information about what's releasing in Azure API for FHIR, see releases of the open-source FHIR Server. We have worked to tag items with Azure-API-for-FHIR if they'll release to the managed service and are usually available two weeks after they are on the release page in open-source. We have also included instructions on how to test the build if you'd like to test in your own environment.

To see what release package is currently in the managed service, you can view the capability statement for the Azure API for FHIR under the software.version property. You'll see which package is deployed.

You can find the exact FHIR version exposed in the capability statement under the fhirVersion property.

No. We don't have a way to change the version of an existing database. You'll need to create a new Azure API for FHIR and reload the data. You can leverage the JSON to FHIR converter as a place to start with converting STU3 data into R4.

No. You can't change the URL for the Azure API for FHIR.

SMART (Substitutable Medical Applications and Reusable Technology) on FHIR is a set of open specifications to integrate partner applications with FHIR Servers and other Health IT systems, such as Electronic Health Records and Health Information Exchanges. By creating a SMART on FHIR application, you can ensure that your application can be accessed and leveraged by a plethora of different systems. For more information about SMART, visit the SMART Health IT website.

Yes, SMART on FHIR capability is supported using AHDS samples. This is referred to as SMART on FHIR(Enhanced). SMART on FHIR(Enhanced) can be considered to meet requirements with SMART on FHIR Implementation Guide (v 1.0.0) and §170.315(g)(10) Standardized API for patient and population services criterion. For more information, visit SMART on FHIR(Enhanced) Documentation.

We don't allow custom FHIR resources. If you need a custom FHIR resource, you can build a custom resource on top of the Basic resource with extensions.

We allow you to load any valid FHIR JSON data into the server. If you want to store the structure definition that defines the extension, you can save this as a structure definition resource. To search on extensions, you'll need to define your own search parameters.

Your resource must be just under 2 MB. This is a limitation from the underlying datastore, and we can't increase this value.

In the managed service, we only support JSON. The open-source FHIR server supports JSON and XML. To view the XML version in open-source, use _format= application/fhir+xml.

The current limit on _count is 1000. If you set _count to more than 1000, you'll receive a warning in the bundle that only 1000 records will be shown.

For Group Export, we only export the included references from the group and not all the characteristics of the group resource.

We currently support posting batch bundles, but we don't support posting transaction bundles in Azure API for FHIR. You can use the FHIR service in Azure Health Data Services if you need transaction bundle support.

You can use the Patient-$everything operation, or you can use a compartment search in Azure API for FHIR. This allows you to get all the resources related to a specific patient. Note that the patient compartment includes all the resources related to the patient but not the patient itself, so you'll need to also search to get the patient if you need the patient resource in your results.

We support sorting by the date last updated: _sort=_lastUpdated. We also support _sort on FirstName, LastName, BirthDate, and ClinicalDate elements. For more information about other supported search parameters, see Overview of FHIR Search.

Yes, we do have support for patient-$everything. For more information, see the Patient-$Everything how-to guide.

No, Azure API for FHIR doesn't support terminology operations today.

$export is part of the FHIR specification. If the FHIR service is configured with a managed identity and a storage account, and if the managed identity has access to that storage account, you can call $export on the FHIR API and all the FHIR resources will be exported to the storage account. For more information, see the article $export.

We have an open-source tool to de-identify FHIR data. The same technology is also integrated to Azure API for FHIR in the form of de-identified export.

Anonymized export is currently supported only on a full system export (/$export) and not for Patient export (/Patient/$export). We're working on making it available at the Patient level as well.

There are two basic Delete types supported within Azure API for FHIR. These are Delete and Conditional Delete.

• With Delete, you can choose to do a soft delete (most common type) and still be able to recover historic versions of your record.
• With Conditional Delete, you can pass a search criteria to delete a resource one item at a time or several at a time.
• With either Delete or Conditional Delete, if you passed the hardDelete parameter, all the records and history are deleted and unrecoverable.

You can recover deleted files if you don't use the hardDelete parameter. The record(s) in Azure API for FHIR should still exist. The record(s) can be found by doing a history search on the resource and by looking for the last version with data.

For details on enabling audit logs and sample queries, see Enable Diagnostic Logging in Azure API for FHIR. If you want to include additional information in the logs, see using custom HTTP headers.

To resolve this you can increase your throughput or switch over to autoscaling to ensure that you have enough compute to process the requests. If you're still having issues, please open a support ticket.

The minimum RU value needs to be at least 40 RU per GB. As you load data, the RUs on the database will increase if you are below this minimum value.

We have a collection of reference architectures available on the Health Architecture GitHub page.

To perform health check on FHIR service, enter {{fhirurl}}/health/check in the GET request. You should be able to see Status of FHIR service. HTTP Status code response with 200 and OverallStatus as "Healthy" in response, means your health check is successful. In case of errors, you will receive error response with HTTP status code 404 (Not Found) or status code 500 (Internal Server Error), and detailed information in response body in some scenarios.

Yes, Azure API for FHIR allows configuring customer-managed keys, leveraging support from Azure Cosmos DB. For more information about encrypting your data with a personal key, see Configure customer-managed keys at REST.

Check if disaster recovery is enabled for the FHIR resource. If it is, disable the disaster recovery feature.