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
Azure API for FHIR, as a managed service, allows customers to persist with Fast Healthcare Interoperability Resources (FHIR®) compliant healthcare data and exchange it securely through the service API. To accommodate different transaction workloads, customers can use manual scale or autoscale.
16
+
Azure API for FHIR, as a managed service, allows customers to persist with Fast Healthcare Interoperability Resources (FHIR®) compliant healthcare data, and exchange it securely through the service API. To accommodate different transaction workloads, customers can use manual scale or autoscale.
17
17
18
18
Azure API for FHIR provides scaling capabilities at database and compute level.
19
19
20
20
## Auto scale at Database level
21
21
22
22
By default, Azure API for FHIR is set to manual for database scaling. This option works well when the transaction workloads are known and consistent. Customers can adjust the throughput `RU/s` through the portal up to 100,000 and submit a request to increase the limit.
23
23
24
-
The autoscale feature is designed to scale Azure resources including the database throughput automatically according to the workloads, eliminating possible bottlenecks in the data layer.
24
+
The autoscale feature is designed to scale Azure resources - including the database throughput - automatically according to the workloads, eliminating possible bottlenecks in the data layer.
25
25
26
-
Lets understand how to enable autoscaling at database level with next sections
26
+
The following sections provide guidance on how to enable autoscaling at database level.
27
27
28
-
### Guidance to enable autoscale
28
+
### Enable autoscale
29
29
30
-
In general, customers should consider autoscale when their workloads vary significantly and are unpredictable.
30
+
In general, customers should consider autoscale when their workloads vary significantly, and are unpredictable.
31
31
32
-
To enable the autoscale feature, customer needs to create a one-time support ticket to request it through Azure portal. The Microsoft support team enables the autoscale feature based on the support priority.
32
+
To enable the autoscale feature, the customer needs to create a one-time support ticket request through Azure portal. The Microsoft support team enables the autoscale feature based on the support priority.
33
33
34
34
> [!NOTE]
35
35
> The autoscale feature isn't available from the Azure portal.
36
36
37
37
### Autoscale for RU/s
38
38
39
-
When autoscale is enabled, the system calculates and sets the initial `Tmax` value. The scalability is governed by the maximum throughput `RU/s` value, or `Tmax`, and scales between `0.1 *Tmax` (or 10% `Tmax`) and `Tmax RU/s`. The `Tmax` increases automatically as the total data size grows. To ensure maximum scalability, the `Tmax` value should be kept as-is. However, customers can request that the value be changed to something between 10% and 100% of the `Tmax` value.
39
+
When autoscale is enabled, the system calculates and sets the initial `Tmax` value. Scalability is governed by the maximum throughput `RU/s` value, or `Tmax`, and scales between `0.1 *Tmax` (or 10% `Tmax`) and `Tmax RU/s`. The `Tmax` increases automatically as the total data size grows. To ensure maximum scalability, the `Tmax` value should be kept as-is. However, customers can request that the value be changed to something between 10% and 100% of the `Tmax` value.
40
40
41
41
You can increase the max `RU/s` or `Tmax` value and go as high as the service supports. When the service is busy, the throughput `RU/s` are scaled up to the `Tmax` value. When the service is idle, the throughput `RU/s` are scaled down to 10% `Tmax` value.
42
42
43
-
You can also decrease the max `RU/s` or `Tmax` value. When you lower the max `RU/s`, the minimum value you can set it to is: `MAX (4000, highest max RU/s ever provisioned / 10, current storage in GB * 400)`, rounded to the nearest 1000 `RU/s`.
43
+
You can also decrease the max `RU/s` or `Tmax` value. When you lower the max `RU/s`, the minimum value you can set it to is: `MAX (4000, highest max RU/s ever provisioned / 10, current storage in GB * 400)` rounded to the nearest 1000 `RU/s`.
44
44
45
45
***Example 1**: You have 1-GB data and the highest provisioned `RU/s` is 10,000. The minimum value is Max (**4000**, 10,000/10, 1x400) = 4000. The first number, **4000**, is used.
46
46
***Example 2**: You have 20-GB data and the highest provisioned `RU/s` is 100,000. The minimum value is Max (4000, **100,000/10**, 20x400) = 10,000. The second number, **100,000/10 =10,000**, is used.
@@ -53,11 +53,11 @@ You can adjust the max `RU/s` or `Tmax` value through the portal if it's a valid
53
53
54
54
## Autoscale at Compute Level
55
55
56
-
Autoscaling policies defined for FHIR service compute level consists:
56
+
The following are autoscaling policies defined for the FHIR service compute level.
57
57
58
58
* Scaling Trigger
59
59
60
-
Scaling Trigger describes when scaling of the service will be performed. Conditions that are defined in the trigger are checked periodically to determine if a service should be scaled or not. All triggers that are currently supported are Average CPU, Max Worker Thread, Average LogWrite, Average data IO.
60
+
Scaling Trigger describes when scaling of the service is performed. Conditions that are defined in the trigger are checked periodically to determine if a service should be scaled or not. The triggers that are currently supported are: Average CPU, Max Worker Thread, Average LogWrite, Average data IO.
61
61
62
62
* Scaling mechanism
63
63
@@ -67,17 +67,17 @@ To ensure the best possible outcome, we recommend customers to gradually increas
67
67
68
68
## FAQ
69
69
70
-
### How to estimate throughput RU/s required?
70
+
### How do I estimate the throughput RU/s required?
71
71
72
72
The data size is one of several factors used in calculating the total throughput RU/s required for manual scale and autoscale. You can find the data size using the Metrics menu option under **Monitoring**. Start a new chart and select **Cosmos DB Collection Size** in the Metric dropdown box and **Max** in the "Aggregation" box.
73
73
74
-
[Screenshot of metrics_new_chart](media/cosmosdb/metrics-new-chart.png)](media/cosmosdb/metrics-new-chart.png#lightbox)
74
+
:::image type="content" source="media/cosmosdb/metrics-new-chart.png" alt-text="Screenshot of metrics_new_chart":::
75
75
76
76
You should be able to see the Max data collection size over the time period selected. Change the "Time Range" if necessary, for example from "Last 30 minutes" to "Last 48 Hours".
77
77
78
-
[Screenshot of cosmosdb_collection_size](media/cosmosdb/cosmosdb-collection-size.png)](media/cosmosdb/cosmosdb-collection-size.png#lightbox)
78
+
:::image type="content" source="media/cosmosdb/cosmosdb-collection-size.png" alt-text="Screenshot of cosdmosdb_collection_size":::
79
79
80
-
Use the formula to calculate required RU/s.
80
+
Use the following formulas to calculate required RU/s.
81
81
82
82
- Manual scale: storage in GB * 40
83
83
- Autoscale: storage in GB * 400
@@ -86,19 +86,19 @@ Keep in mind that this is only an estimate based on data size and that there are
86
86
87
87
### I enabled autoscale how can I migrate to scaling manually?
88
88
89
-
A support ticket is required to change autoscale to manual scale and specify the throughput RU/s. The minimum value for manual scale you can set it to is: `MAX (400, highest max RU/s ever provisioned / 100, current storage in GB * 40)`, rounded to the nearest 1000 `RU/s`. The numbers used here are different from those used in autoscale.
89
+
A support ticket is required to change autoscale to manual scale and specify the throughput RU/s. The minimum value for manual scale you can set is: `MAX (400, highest max RU/s ever provisioned / 100, current storage in GB * 40)` rounded to the nearest 1000 `RU/s`. The numbers used here are different from those used in autoscale.
90
90
91
91
Once the change is completed, the new billing rates are based on manual scale.
92
92
93
93
### What is the cost impact of autoscale?
94
94
95
-
The autoscale feature incurs costs because of managing the provisioned throughput units automatically. The actual costs depend on hourly usage, but keep in mind that there are minimum costs of 10% of `Tmax` for reserved throughput RU/s. However, this cost increase doesn't apply to storage and runtime costs. For information about pricing, see [Azure API for FHIR pricing](https://azure.microsoft.com/pricing/details/azure-api-for-fhir/).
95
+
The autoscale feature incurs costs because of managing the provisioned throughput units automatically. The actual costs depend on hourly usage, but keep in mind that there are minimum costs of 10% of `Tmax` for reserved throughput RU/s. The cost increase doesn't apply to storage and runtime costs. For information about pricing, see [Azure API for FHIR pricing](https://azure.microsoft.com/pricing/details/azure-api-for-fhir/).
96
96
97
97
## Next steps
98
98
99
-
In this document, you learned about the autoscale feature for Azure API for FHIR. For an overview about Azure API for FHIR, see
99
+
In this document, you learned about the autoscale feature for Azure API for FHIR. For an overview of the Azure API for FHIR, see
100
100
101
101
>[!div class="nextstepaction"]
102
102
>[About Azure API for FHIR](overview.md)
103
103
104
-
FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
When you're working with healthcare data, it's important to ensure that the data is secure, and it can't be accessed by unauthorized users or applications. FHIR servers use [OAuth 2.0](https://oauth.net/2/) to ensure this data security. [Azure API for FHIR](https://azure.microsoft.com/services/azure-api-for-fhir/) is secured using [Microsoft Entra ID](../../active-directory/index.yml), which is an example of an OAuth 2.0 identity provider. This article provides an overview of FHIR server authorization and the steps needed to obtain a token to access a FHIR server. While these steps apply to any FHIR server and any identity provider, we'll walk through Azure API for FHIR as the FHIR server and Microsoft Entra ID as our identity provider in this article.
18
+
When you're working with healthcare data, it's important to ensure that the data is secure, and can't be accessed by unauthorized users or applications. FHIR servers use [OAuth 2.0](https://oauth.net/2/) to ensure this data security. [Azure API for FHIR](https://azure.microsoft.com/services/azure-api-for-fhir/) is secured using [Microsoft Entra ID](../../active-directory/index.yml), which is an example of an OAuth 2.0 identity provider. This article provides an overview of FHIR server authorization and the steps needed to obtain a token to access a FHIR server. The following steps apply to any FHIR server and any identity provider. We walk through Azure API for FHIR as the FHIR server and Microsoft Entra ID as our identity provider in this article.
19
19
20
20
## Access control overview
21
21
22
-
In order for a client application to access Azure API for FHIR, it must present an access token. The access token is a signed, [Base64](https://en.wikipedia.org/wiki/Base64) encoded collection of properties (claims) that convey information about the client's identity and roles and privileges granted to the client.
22
+
In order for a client application to access Azure API for FHIR, it must present an access token. The access token is a signed, [Base64](https://en.wikipedia.org/wiki/Base64) encoded collection of properties (claims) that convey information about the client's identity, roles, and privileges granted to the client.
23
23
24
-
There are many ways to obtain a token, but the Azure API for FHIR doesn't care how the token is obtained as long as it's an appropriately signed token with the correct claims.
24
+
There are many ways to obtain a token. Azure API for FHIR doesn't care how the token is obtained as long as it's an appropriately signed token with the correct claims.
25
25
26
-
For example like when you use [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md), accessing a FHIR server goes through the following four steps:
26
+
For example, when you use [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md), accessing a FHIR server goes through the following four steps:
1. The client sends a request to the `/authorize` endpoint of Microsoft Entra ID. Microsoft Entra ID will redirect the client to a sign-in page where the user will authenticate using appropriate credentials (for example username and password or two-factor authentication). See details on[obtaining an authorization code](../../active-directory/develop/v2-oauth2-auth-code-flow.md#request-an-authorization-code). Upon successful authentication, an *authorization code* is returned to the client. Microsoft Entra ID will only allow this authorization code to be returned to a registered reply URL configured in the client application registration.
30
+
1. The client sends a request to the `/authorize` endpoint of Microsoft Entra ID. Microsoft Entra ID will redirect the client to a sign-in page where the user authenticates using appropriate credentials (for example username and password, or two-factor authentication). For details, see[obtaining an authorization code](../../active-directory/develop/v2-oauth2-auth-code-flow.md#request-an-authorization-code). Upon successful authentication, an *authorization code* is returned to the client. Microsoft Entra ID will only allow this authorization code to be returned to a registered reply URL configured in the client application registration.
31
31
1. The client application exchanges the authorization code for an *access token* at the `/token` endpoint of Microsoft Entra ID. When you request a token, the client application may have to provide a client secret (the applications password). See details on [obtaining an access token](../../active-directory/develop/v2-oauth2-auth-code-flow.md#redeem-a-code-for-an-access-token).
32
32
1. The client makes a request to Azure API for FHIR, for example `GET /Patient`, to search all patients. When the client makes the request, it includes the access token in an HTTP request header, for example `Authorization: Bearer eyJ0e...`, where `eyJ0e...` represents the Base64 encoded access token.
33
-
1. Azure API for FHIR validates that the token contains appropriate claims (properties in the token). If everything checks out, it will complete the request and return a FHIR bundle with results to the client.
33
+
1. Azure API for FHIR validates that the token contains appropriate claims (properties in the token). If everything checks out, it completes the request and returns a FHIR bundle with results to the client.
34
34
35
35
It's important to note that Azure API for FHIR isn't involved in validating user credentials and it doesn't issue the token. The authentication and token creation is done by Microsoft Entra ID. Azure API for FHIR simply validates that the token is signed correctly (it's authentic) and that it has appropriate claims.
36
36
37
37
## Structure of an access token
38
38
39
39
Development of Fast Healthcare Interoperability Resources (FHIR®) applications often involves debugging access issues. If a client is denied access to Azure API for FHIR, it's useful to understand the structure of the access token and how it can be decoded to inspect the contents (the claims) of the token.
40
40
41
-
FHIR servers typically expect a [JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token) (JWT, sometimes pronounced "jot"). It consists of three parts:
41
+
FHIR servers typically expect a [JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token) (JWT, sometimes pronounced "jot"). It consists of the following three parts.
42
42
43
43
**Part 1**: A header, which could look like:
44
44
```json
@@ -60,11 +60,11 @@ FHIR servers typically expect a [JSON Web Token](https://en.wikipedia.org/wiki/J
60
60
}
61
61
```
62
62
63
-
**Part 3**: A signature, which is calculated by concatenating the Base64 encoded contents of the header and the payload and calculating a cryptographic hash of them based on the algorithm (`alg`) specified in the header. A server will be able to obtain public keys from the identity provider and validate that this token was issued by a specific identity provider and it hasn't been tampered with.
63
+
**Part 3**: A signature, which is calculated by concatenating the Base64 encoded contents of the header and the payload, and calculating a cryptographic hash of them based on the algorithm (`alg`) specified in the header. A server is able to obtain public keys from the identity provider and validate that this token was issued by a specific identity provider and it hasn't been tampered with.
64
64
65
-
The full token consists of the Base64 encoded (actually Base64 url encoded) versions of those three segments. The three segments are concatenated and separated with a `.` (dot).
65
+
The full token consists of the Base64 url encoded versions of those three segments. The three segments are concatenated and separated with a `.`.
@@ -88,20 +88,20 @@ The token can be decoded and inspected with tools such as [https://jwt.ms](https
88
88
89
89
## Obtaining an access token
90
90
91
-
As mentioned, there are several ways to obtain a token from Microsoft Entra ID. They're described in detail in the [Microsoft Entra developer documentation](../../active-directory/develop/index.yml).
91
+
As mentioned, there are several ways to obtain a token from Microsoft Entra ID, described in detail in the [Microsoft Entra developer documentation](../../active-directory/develop/index.yml).
92
92
93
-
Use either of the following authentication protocols:
93
+
Use either of the following authentication protocols.
There are other variations (for example due to flow) for obtaining a token. Refer to the [Microsoft Entra documentation](../../active-directory/index.yml) for details. When you use Azure API for FHIR, there are some shortcuts for obtaining an access token (such as for debugging purposes) [using the Azure CLI](get-healthcare-apis-access-token-cli.md).
98
+
There are other variations for obtaining a token (for example due to flow). Refer to the [Microsoft Entra documentation](../../active-directory/index.yml) for details. When you use Azure API for FHIR, there are some shortcuts for obtaining an access token (such as for debugging purposes) [using the Azure CLI](get-healthcare-apis-access-token-cli.md).
99
99
100
100
## Next steps
101
101
102
102
In this document, you learned some of the basic concepts involved in securing access to the Azure API for FHIR using Microsoft Entra ID. For information about how to deploy the Azure API for FHIR service, see
103
103
104
104
>[!div class="nextstepaction"]
105
-
>[Deploy Azure API for FHIR](fhir-paas-portal-quickstart.md)
105
+
>[Deploy Azure API for FHIR](fhir-paas-portal-quickstart.md).
106
106
107
-
FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
0 commit comments