You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/healthcare-apis/azure-api-for-fhir/disaster-recovery.md
+8-18Lines changed: 8 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Azure API for FHIR is a fully managed service, based on Fast Healthcare Interope
15
15
16
16
The DR feature provides a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 60 minutes.
17
17
18
-
## How to enable DR
18
+
## How to enable DR
19
19
20
20
To enable the DR feature, create a one-time support ticket. You can choose an Azure paired region or another region where the Azure API for FHIR is supported. The Microsoft support team will enable the DR feature based on the support priority.
21
21
@@ -33,30 +33,29 @@ By default, Azure API for FHIR offers data protection through backup and restore
33
33
34
34
It's worth noting that the throughput RU/s must have the same values in the primary and secondary regions.
[](media/disaster-recovery/azure-traffic-manager.png#lightbox)
37
37
38
38
### Automatic failover
39
39
40
40
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](#configuration-changes-in-dr).
41
41
42
-
[](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
42
+
[](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
43
43
44
44
### Affected region recovery
45
45
46
46
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.
47
47
48
-
[](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
48
+
[](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
49
49
50
50
When the compute has failed 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.
[](media/disaster-recovery/network-latency.png#lightbox)
54
53
55
54
### Manual failback
56
55
57
56
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.
58
57
59
-
[](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
58
+
[](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
60
59
61
60
## Configuration changes in DR
62
61
@@ -93,13 +92,6 @@ The export job will be picked up from another region after 10 minutes without an
93
92
94
93
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](../fhir/export-data.md).
95
94
96
-
### IoMT FHIR Connector
97
-
98
-
Any existing connection won't function until the failed region is restored. You can create a new connection once the failover has completed and your FHIR server is accessible. This new connection will continue to function when failback occurs.
99
-
100
-
> [!NOTE]
101
-
> IoMT Connector is a preview feature and does not provide support for disaster recovery.
102
-
103
95
## How to test DR
104
96
105
97
While not required, you can test the DR feature on a non-production environment. For DR test, only the data will be included and the compute won't be included.
@@ -120,7 +112,6 @@ Consider the following steps for DR test.
120
112
121
113
* (Optional) Share any feedback with the Microsoft support team.
122
114
123
-
124
115
> [!NOTE]
125
116
> 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.
126
117
@@ -131,12 +122,11 @@ The disaster recovery feature incurs extra costs because data of the compute and
131
122
> [!NOTE]
132
123
> The DR offering is subject to the [SLA for Azure API for FHIR](https://azure.microsoft.com/pricing/details/health-data-services), 1.0.
133
124
134
-
135
125
## Next steps
136
126
137
127
In this article, you've 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
Copy file name to clipboardExpand all lines: articles/healthcare-apis/azure-api-for-fhir/export-data.md
+1-44Lines changed: 1 addition & 44 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,50 +93,7 @@ You're now ready to export FHIR data to the storage account securely. Note that
93
93
> [!IMPORTANT]
94
94
> The user interface will be updated later to allow you to select the Resource type for Azure API for FHIR and a specific service instance.
95
95
96
-
### Allowing specific IP addresses for the Azure storage account in a different region
97
-
98
-
Select **Networking** of the Azure storage account from the
99
-
portal.
100
-
101
-
Select **Selected networks**. Under the Firewall section, specify the IP address in the **Address range** box. Add IP ranges to
102
-
allow access from the internet or your on-premises networks. You can
103
-
find the IP address in the table below for the Azure region where the
104
-
Azure API for FHIR is provisioned.
105
-
106
-
|**Azure Region**|**Public IP Address**|
107
-
|:----------------------|:-------------------|
108
-
| Australia East | 20.53.44.80 |
109
-
| Canada Central | 20.48.192.84 |
110
-
| Central US | 52.182.208.31 |
111
-
| East US | 20.62.128.148 |
112
-
| East US 2 | 20.49.102.228 |
113
-
| East US 2 EUAP | 20.39.26.254 |
114
-
| Germany North | 51.116.51.33 |
115
-
| Germany West Central | 51.116.146.216 |
116
-
| Japan East | 20.191.160.26 |
117
-
| Korea Central | 20.41.69.51 |
118
-
| North Central US | 20.49.114.188 |
119
-
| North Europe | 52.146.131.52 |
120
-
| South Africa North | 102.133.220.197 |
121
-
| South Central US | 13.73.254.220 |
122
-
| Southeast Asia | 23.98.108.42 |
123
-
| Switzerland North | 51.107.60.95 |
124
-
| UK South | 51.104.30.170 |
125
-
| UK West | 51.137.164.94 |
126
-
| West Central US | 52.150.156.44 |
127
-
| West Europe | 20.61.98.66 |
128
-
| West US 2 | 40.64.135.77 |
129
-
130
-
> [!NOTE]
131
-
> The above steps are similar to the configuration steps described in the document **Converting your data to FHIR**. For more information, see [Configure the ACR firewall](../../healthcare-apis/fhir/configure-settings-convert-data.md#step-6-configure-the-azure-container-registry-firewall-for-secure-access).
132
-
133
-
### Allowing specific IP addresses for the Azure storage account in the same region
134
-
135
-
The configuration process is the same as above except a specific IP
136
-
address range in CIDR format is used instead, 100.64.0.0/10. The reason why the IP address range, which includes 100.64.0.0 – 100.127.255.255, must be specified is because the actual IP address used by the service varies, but will be within the range, for each $export request.
137
-
138
-
> [!NOTE]
139
-
> It is possible that a private IP address within the range of 10.0.2.0/24 may be used instead. In that case, the $export operation will not succeed. You can retry the $export request, but there is no guarantee that an IP address within the range of 100.64.0.0/10 will be used next time. That's the known networking behavior by design. The alternative is to configure the storage account in a different region.
96
+
[!INCLUDE [Specific IP ranges for storage account](../includes/common-ip-address-storage-account.md)]
Copy file name to clipboardExpand all lines: articles/healthcare-apis/fhir/configure-import-data.md
+4-40Lines changed: 4 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,7 +30,7 @@ In this document we go over the three steps used in configuring import settings
30
30
31
31
## Step 1: Enable managed identity on the FHIR service
32
32
33
-
The first step is to enable system wide managed identity on the service. This will be used to grant FHIR service an access to the storage account.
33
+
The first step is to enable system wide managed identity on the service. This will be used to grant FHIR service access to the storage account.
34
34
For more information about managed identities in Azure, see [About managed identities for Azure resources](../../active-directory/managed-identities-azure-resources/overview.md).
35
35
36
36
Follow the steps to enable managed identity on FHIR service
@@ -95,7 +95,7 @@ Do following changes to JSON:
95
95
After you've completed this final step, you're ready to perform **Incremental mode** import using $import.
96
96
97
97
98
-
Note : You can also use the **Deploy to Azure** button to open custom Resource Manager template that updates the configuration for $import.
98
+
Note that you can also use the **Deploy to Azure** button to open custom Resource Manager template that updates the configuration for $import.
99
99
100
100
[](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.healthcareapis%2Ffhir-import%2Fazuredeploy.json)
101
101
@@ -147,44 +147,8 @@ After you've executed above command, in the **Firewall** section under **Resourc
147
147
148
148
You're now ready to securely import FHIR data from the storage account. The storage account is on selected networks and isn't publicly accessible. To securely access the files, you can enable [private endpoints](../../storage/common/storage-private-endpoints.md) for the storage account.
149
149
150
-
### Option 2: Allowing specific IP addresses to access the Azure storage account
151
-
#### Option 2.1: Access storage account provisioned in different Azure region than FHIR service
152
-
153
-
In the Azure portal, go to the ADLS Gen2 account and select the **Networking** blade.
154
-
155
-
Select **Enabled from selected virtual networks and IP addresses**. Under the Firewall section, specify the IP address in the **Address range** box. Add IP ranges to allow access from the internet or your on-premises networks. You can find the IP address in the table below for the Azure region where the FHIR service is provisioned.
156
-
157
-
|**Azure Region**|**Public IP Address**|
158
-
|:----------------------|:-------------------|
159
-
| Australia East | 20.53.44.80 |
160
-
| Canada Central | 20.48.192.84 |
161
-
| Central US | 52.182.208.31 |
162
-
| East US | 20.62.128.148 |
163
-
| East US 2 | 20.49.102.228 |
164
-
| East US 2 EUAP | 20.39.26.254 |
165
-
| Germany North | 51.116.51.33 |
166
-
| Germany West Central | 51.116.146.216 |
167
-
| Japan East | 20.191.160.26 |
168
-
| Korea Central | 20.41.69.51 |
169
-
| North Central US | 20.49.114.188 |
170
-
| North Europe | 52.146.131.52 |
171
-
| South Africa North | 102.133.220.197 |
172
-
| South Central US | 13.73.254.220 |
173
-
| Southeast Asia | 23.98.108.42 |
174
-
| Switzerland North | 51.107.60.95 |
175
-
| UK South | 51.104.30.170 |
176
-
| UK West | 51.137.164.94 |
177
-
| West Central US | 52.150.156.44 |
178
-
| West Europe | 20.61.98.66 |
179
-
| West US 2 | 40.64.135.77 |
180
-
181
-
#### Option 2.2: Access storage account provisioned in same Azure region as FHIR service
182
-
183
-
The configuration process for IP addresses in the same region is just like above except a specific IP address range in Classless Inter-Domain Routing (CIDR) format is used instead (that is, 100.64.0.0/10). The reason why the IP address range (100.64.0.0 – 100.127.255.255) must be specified is because an IP address for the FHIR service will be allocated each time an `$import` request is made.
184
-
185
-
> [!Note]
186
-
> It is possible that a private IP address within the range of 10.0.2.0/24 may be used, but there is no guarantee that the `$import` operation will succeed in such a case. You can retry if the `$import` request fails, but until an IP address within the range of 100.64.0.0/10 is used, the request will not succeed. This network behavior for IP address ranges is by design. The alternative is to configure the storage account in a different region.
187
-
150
+
### Option 2:
151
+
[!INCLUDE [Specific IP ranges for storage account](../includes/common-ip-address-storage-account.md)]
Copy file name to clipboardExpand all lines: articles/healthcare-apis/includes/common-ip-address-storage-account.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ Select **Enabled from selected virtual networks and IP addresses**. Under the Fi
41
41
42
42
### Allowing specific IP addresses to access the Azure storage account in the same region
43
43
44
-
The configuration process for IP addresses in the same region is just like above except a specific IP address range in Classless Inter-Domain Routing (CIDR) format is used instead (i.e., 100.64.0.0/10). The reason why the IP address range (100.64.0.0 – 100.127.255.255) must be specified is because an IP address for the FHIR service will be allocated each time an `$export` request is made.
44
+
The configuration process for IP addresses in the same region is just like above except a specific IP address range in Classless Inter-Domain Routing (CIDR) format is used instead (i.e., 100.64.0.0/10). The reason why the IP address range (100.64.0.0 – 100.127.255.255) must be specified is because an IP address for the FHIR service will be allocated each time an operation request is made.
45
45
46
46
> [!NOTE]
47
-
> It is possible that a private IP address within the range of 10.0.2.0/24 may be used, but there is no guarantee that the `$export`operation will succeed in such a case. You can retry if the `$export` request fails, but until an IP address within the range of 100.64.0.0/10 is used, the request will not succeed. This network behavior for IP address ranges is by design. The alternative is to configure the storage account in a different region.
47
+
> It is possible that a private IP address within the range of 10.0.2.0/24 may be used, but there is no guarantee that the operation will succeed in such a case. You can retry if the operation request fails, but until an IP address within the range of 100.64.0.0/10 is used, the request will not succeed. This network behavior for IP address ranges is by design. The alternative is to configure the storage account in a different region.
0 commit comments