minor edits for clarity

Author: KendalBond007

articles/healthcare-apis/fhir/autoscale.md

@@ -13,19 +13,19 @@ ms.author: kesheth
 
 Azure Health Data Services provides a managed service for persisting FHIR®-compliant healthcare data and interacting with the data securely through the API service endpoint. 
 
-Autoscaling is a capability to dynamically scale FHIR service based on the load reported. The FHIR service in Azure Health Data Services provides the built-in autoscaling capability and the process is automated. This capability provides elasticity and enables provisioning of more instances for FHIR service customers on demand.
+Autoscaling is a capability to dynamically scale FHIR service based on the load reported. The FHIR service in Azure Health Data Services provides the built-in autoscaling capability, which is automated. This capability provides elasticity and enables on demand provisioning of more instances for FHIR service customers.
 
 The autoscaling feature for FHIR service is available in all regions where the FHIR service is supported.
 > [!NOTE]
-> Autoscaling feature is subject to the resources availability in Azure regions.
+> The autoscaling feature is subject to the resources availability in Azure regions.
 
 The autoscaling feature adjusts computing resources automatically to optimize service scalability. There's no action required from customers.
 
 ## Autoscale at the compute level
 
 ### Scaling trigger
 
-Scaling triggers describes when scaling of the service is performed. Conditions 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.
+Scaling triggers describes when scaling of the service is performed. Conditions defined in the trigger are checked periodically to determine if a service should be scaled or not. Only the following triggers are currently supported: Average CPU, Max Worker Thread, Average LogWrite, Average data IO.
 
 ### Scaling mechanism
 
@@ -41,7 +41,7 @@ The autoscaling feature incurs no extra costs.
 
 ### What should customers do if there's high volume of HTTP 429 errors?
 
-We recommend that you gradually increase the request rate to see if it reduces HTTP 429 errors. For consistent 429 errors, create a support ticket through the Azure portal. The support team engages with you to understand your scaling trigger needs.
+We recommend that you gradually increase the request rate to see if it reduces HTTP 429 errors. For consistent 429 errors, create a support ticket through the Azure portal. The support team will engage with you to understand your scaling trigger needs.
 
 ## Related content
 

articles/healthcare-apis/fhir/azure-active-directory-identity-configuration-old.md

@@ -12,28 +12,28 @@ ms.author: kesheth
 
 # Microsoft Entra identity configuration for FHIR service
 
-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. FHIR service in the Azure Health Data Services 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 will apply to any FHIR server and any identity provider, we'll walk through the FHIR service and Microsoft Entra ID as our identity provider in this article.
+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. FHIR service in the Azure Health Data Services 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 walk through the FHIR service and Microsoft Entra ID as our identity provider in this article.
 
 ## Access control overview
 
-In order for a client application to access the FHIR service, 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.
+In order for a client application to access the FHIR service, 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.
 
-There are many ways to obtain a token, but the FHIR service doesn't care how the token is obtained as long as it's an appropriately signed token with the correct claims. 
+The FHIR service doesn't care how the token is obtained, as long as it's an appropriately signed token with the correct claims. 
 
-Using [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md) as an example, accessing a FHIR server goes through the four steps below:
+Using [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md) as an example, accessing a FHIR server goes through the following four steps.
 
 ![FHIR Authorization](media/azure-active-directory-fhir-service/fhir-authorization.png)
 
-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 (see below).
-1. The client application exchanges the authorization code for an *access token* at the `/token` endpoint of Microsoft Entra ID. When requesting 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).
+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). Select the link for 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 (following).
+1. The client application exchanges the authorization code for an *access token* at the `/token` endpoint of Microsoft Entra ID. When requesting a token, the client application may have to provide a client secret (the applications password). Select the link for details on [obtaining an access token](../../active-directory/develop/v2-oauth2-auth-code-flow.md#redeem-a-code-for-an-access-token).
 1. The client makes a request to the FHIR service, for example `GET /Patient` to search all patients. When making 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.
-1. The FHIR service 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.
+1. The FHIR service 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.
 
-It's important to note that the FHIR service 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. The FHIR service simply validates that the token is signed correctly (it's authentic) and that it has appropriate claims.
+It's important to note that the FHIR service 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. The FHIR service simply validates that the token is signed correctly (is authentic) and that it has appropriate claims.
 
 ## Structure of an access token
 
-Development of FHIR applications often involves debugging access issues. If a client is denied access to the FHIR service, 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. 
+Development of FHIR applications often involves debugging access issues. If a client is denied access to the FHIR service, it's useful to understand the structure of the access token and how it can be decoded to inspect the contents (claims) of the token. 
 
 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:
 
@@ -57,11 +57,11 @@ FHIR servers typically expect a [JSON Web Token](https://en.wikipedia.org/wiki/J
     }
 ```
 
-**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.
+**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, validate that the token was issued by a specific identity provider, and hasn't been tampered with.
 
 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).
 
-An example token is seen below:
+Here's an example token:
 
 ```
 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
@@ -85,14 +85,14 @@ The token can be decoded and inspected with tools such as [https://jwt.ms](https
 
 ## Obtaining an access token
 
-As mentioned above, 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).
+As previously 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).
 
 Use either of the following authentication protocols:
 
 * [Authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md).
 * [Client credentials flow](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md).
 
-There are other variations (for example, on behalf of flow) for obtaining a token. Check the Microsoft Entra documentation for details. When using the FHIR service, there are also some shortcuts for obtaining an access token (for debugging purposes) [using the Azure CLI](get-healthcare-apis-access-token-cli.md).
+There are other variations for obtaining a token (for example, on behalf of flow). Check the Microsoft Entra documentation for details. When using the FHIR service, there are also shortcuts to obtaining an access token for debugging purposes [using the Azure CLI](get-healthcare-apis-access-token-cli.md).
 
 ## Next steps