Поделиться через

Disaster recovery for Azure API for FHIR

  • Статья

Это важно

Поддержка Azure API для FHIR будет прекращена 30 сентября 2026 г. Следуйте стратегиям миграции, чтобы перейти на сервис Azure Health Data Services FHIR® к указанному сроку. Из-за прекращения использования AZURE API для FHIR новые развертывания клиентов не будут разрешены с 1 апреля 2025 г. Служба Azure Health Data Services FHIR — это развивающаяся версия Azure API для FHIR, которая позволяет клиентам управлять службами FHIR, DICOM и MedTech с интеграцией с другими службами Azure.

Azure API for FHIR is a fully managed service, based on Fast Healthcare Interoperability Resources (FHIR®). To meet business and compliance requirements you can use the disaster recovery (DR) feature for Azure API for FHIR.

The DR feature provides a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 60 minutes.

How to enable DR

To enable the DR feature, create a one-time support ticket. You can choose an Azure region, where the Azure API for FHIR is supported. The Microsoft support team enables the DR feature based on the support priority.

How the DR process works

The DR process involves the following steps.

  • Репликация данных
  • Automatic failover
  • Affected region recovery
  • Manual failback

Data replication in the secondary region

By default, Azure API for FHIR offers data protection through backup and restore. When the disaster recovery feature is enabled, data replication begins. A data replica is automatically created and synchronized in the secondary Azure region. The initial data replication can take a few minutes to a few hours, or longer, depending on the amount of data. The secondary data replica is a replication of the primary data. It's used directly to recover the service, and it helps speed up the recovery process.

It's worth noting that the throughput RU/s must have the same values in the primary and secondary regions.

Diagram that shows Azure Traffic Manager.

Automatic failover

During a primary region outage, the Azure API for FHIR automatically fails over to the secondary region and the same service endpoint is used. The service is expected to resume in one hour or less, and potential data loss is up to 15 minutes' worth of data. Other configuration changes may be required. For more information, see Configuration changes in DR.

Diagram that shows failover in disaster recovery.

Affected region recovery

After the affected region recovers, it's automatically available as a secondary region and data replication restarts. You can start the data recovery process or wait until the failback step is completed.

Diagram that shows replication in disaster recovery.

When the compute fails back to the recovered region and the data hasn't, there may be potential network latencies. The main reason is that the compute and the data are in two different regions. The network latencies should disappear automatically as soon as the data fails back to the recovered region through a manual trigger.

Diagram that shows network latency.

Manual failback

The compute fails back automatically to the recovered region. The data is switched back to the recovered region manually by the Microsoft support team using the script.

Diagram that shows failback in disaster recovery.

Configuration changes in DR

Other configuration changes may be required when Private Link, Customer Managed Key (CMK), IoMT FHIR Connector (the Internet of Medical Things) and $export are used.

You can enable the private link feature before or after the Azure API for FHIR has been provisioned. You can also provision private link before or after the DR feature has been enabled. Refer to the following list when you're ready to configure Private Link for DR.

  • Configure Azure Private Link in the primary region. This step isn't required in the secondary region. For more information, see Configure private link

  • Create one Azure VNet in the primary region and another VNet in the secondary region. For information, see Create a virtual network using the Azure portal.

  • In the primary region, VNet creates a VNet peering to the secondary region VNet. Дополнительные сведения см. в статье Пиринг между виртуальными сетями.

  • Use the default settings, or you can tailor the configuration as needed. It's most important that the traffic can flow between the two virtual networks.

  • When the private DNS is set up, the VNet in the secondary region needs to be manually set up as a "Virtual network links". The primary VNet should already be added as part of the Private Link endpoint creation flow. For more information, see Virtual network links.

  • Optionally, set up one VM in the primary region VNet and one in the secondary region VNet. You can access the Azure API for FHIR from both VMs.

The private link feature should continue to work during a regional outage and after the failback has completed. Дополнительные сведения см. в разделе "Настройка приватного канала".

Примечание.

Configuring virtual networks and VNet peering does not affect data replication.

CMK

Your access to Azure API for FHIR will be maintained if the key vault hosting the managed key in your subscription is accessible. There's a possible temporary downtime as Key Vault can take up to 20 minutes to re-establish its connection. Дополнительные сведения см. в статье Доступность и избыточность хранилища ключей Azure.

$export

The export job will be picked up from another region after 10 minutes without an update to the job status. Follow the guidance for Azure storage for recovering your storage account in the event of a regional outage. Дополнительные сведения см. в статье Аварийное восстановление и отработка отказа учетной записи хранения.

Ensure that you grant the same permissions to the system identity of the Azure API for FHIR. Also, if the storage account is configured with selected networks, see How to export FHIR data.

How to test DR

While not required, you can test the DR feature on a non-production environment. For a DR test, only the data is included. The compute isn't included.

Consider the following steps for DR test.

  • Prepare a test environment with test data. It's recommended that you use a service instance with small amounts of data to reduce the time to replicate the data.

  • Create a support ticket and provide your Azure subscription, preferred Azure region for the failover, and the service name for the Azure API for FHIR for your test environment.

  • Come up with a test plan, as you would with any DR test.

  • The Microsoft support team enables the DR feature and confirms that the preferred failover region by the customer has been added

  • Conduct your DR test and record the testing results, which should include any data loss and network latency issues.

  • For failback, notify the Microsoft support team to complete the failback step.

  • (Optional) Share any feedback with the Microsoft support team.

Примечание.

The DR test will double the cost of your test environment during the test. No extra cost will incur after the DR test is completed and the DR feature is disabled.

Cost of disaster recovery

The disaster recovery feature incurs extra costs because data of the compute and data replica running in the environment in the secondary region. For more pricing details, refer to the Azure API for FHIR pricing web page.

Примечание.

The DR offering is subject to the SLA for Azure API for FHIR, 1.0.

Дальнейшие действия

In this article, you learned how DR for Azure API for FHIR works and how to enable it. To learn about Azure API for FHIR's other supported features, see

FHIR supported features.

Примечание.

FHIR® является зарегистрированным товарным знаком HL7 и используется с разрешением HL7 .