Merge pull request #286500 from KendalBond007/FHIReditsBatch10_Sep24

FHIReditsBatch10_Sep24

Author: AnnaMHuff

articles/healthcare-apis/fhir/fhir-service-resource-manager-template.md

@@ -11,7 +11,7 @@ ms.date: 06/06/2022
 
 # Deploy a FHIR service within Azure Health Data Services - using ARM template
 
-In this article, you'll learn how to deploy FHIR service within the Azure Health Data Services (hereby called FHIR service) using the Azure Resource Manager template (ARM template). We provide you two options using PowerShell or using CLI.
+In this article, you'll learn how to deploy FHIR® service within the Azure Health Data Services using the Azure Resource Manager template (ARM template). We provide two options: using PowerShell or using CLI.
 
 An [ARM template](../../azure-resource-manager/templates/overview.md) is a JSON file that defines the infrastructure and configuration for your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment without writing the sequence of programming commands to create the deployment.
 
@@ -38,11 +38,11 @@ The template used in this article is from [Azure Quickstart Templates](https://a
 
 The template defines three Azure resources:
 - Microsoft.HealthcareApis/workspaces
-- Microsoft.HealthcareApis/workspaces/fhirservices      
+- Microsoft.HealthcareApis/workspaces/fhirservices     
 - Microsoft.Storage/storageAccounts
 
 > [!NOTE]
-> Local RBAC is deprecated. Access Policies configuration associated with Local RBAC in ARM template are deprecated. Existing customers using Local RBAC need to migrate to Azure RBAC by November 2024. For questions, please [contact us](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview).
+> Local RBAC is deprecated. Access Policies configuration associated with Local RBAC in ARM templates are deprecated. Existing customers using Local RBAC need to migrate to Azure RBAC by November 2024. For questions, please [contact us](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview).
 
 You can deploy the FHIR service resource by **removing** the workspaces resource, the storage resource, and the `dependsOn` property in the “Microsoft.HealthcareApis/workspaces/fhirservices” resource.
 
@@ -186,19 +186,19 @@ You can deploy the FHIR service resource by **removing** the workspaces resource
 
 You can deploy the ARM template using two options: PowerShell or CLI.
 
-The sample code provided below uses the template in the “templates” subfolder of the subfolder “src”. You may want to change the location path to reference the template file properly.
+The following sample code uses the template in the “templates” subfolder of the subfolder “src”. You may want to change the location path to reference the template file properly.
 
-The deployment process takes a few minutes to complete. Take a note of the names for the FHIR service and the resource group, which you'll use later.
+The deployment process takes a few minutes to complete. Take a note of the names for the FHIR service and the resource group, which you use later.
 
 # [PowerShell](#tab/PowerShell)
 
 ### Deploy the template: using PowerShell
 
-Run the code in PowerShell locally, in Visual Studio Code, or in Azure Cloud Shell, to deploy the FHIR service. 
+To deploy the FHIR service, run the code in PowerShell locally, in Visual Studio Code, or in Azure Cloud Shell. 
 
 If you haven't logged in to Azure, use "Connect-AzAccount" to log in. Once you've logged in, use "Get-AzContext" to verify the subscription and tenant you want to use. You can change the subscription and tenant if needed.
 
-You can create a new resource group, or use an existing one by skipping the step or commenting out the line starting with “New-AzResourceGroup”.
+You can create a new resource group, or use an existing one by skipping the step, or commenting out the line starting with “New-AzResourceGroup”.
 
 ```powershell-interactive
 ### variables
@@ -228,11 +228,11 @@ New-AzResourceGroupDeployment -ResourceGroupName $resourcegroupname -TemplateFil
 
 ### Deploy the template: using CLI
 
-Run the code locally, in Visual Studio Code or in Azure Cloud Shell, to deploy the FHIR service. 
+To deploy the FHIR service, run the code in PowerShell locally, in Visual Studio Code, or in Azure Cloud Shell. 
 
 If you haven’t logged in to Azure, use "az login" to log in. Once you've logged in, use "az account show --output table" to verify the subscription and tenant you want to use. You can change the subscription and tenant if needed.
 
-You can create a new resource group, or use an existing one by skipping the step or commenting out the line starting with "az group create".
+You can create a new resource group, or use an existing one by skipping the step, or commenting out the line starting with "az group create".
 
 ```azurecli-interactive
 ### variables
@@ -261,11 +261,11 @@ az deployment group create --resource-group $resourcegroupname --template-file '
 
 ## Review the deployed resources
 
-You can verify that the FHIR service is up and running by opening the browser and navigating to `https://<yourfhir servic>.azurehealthcareapis.com/metadata`. If the capability statement is displayed or downloaded automatically, your deployment is successful. 
+You can verify that the FHIR service is up and running by opening a browser and navigating to `https://<yourfhir servic>.azurehealthcareapis.com/metadata`. If the capability statement is displayed or downloaded automatically, your deployment is successful. 
 
 ## Clean up the resources
 
-When the resource is no longer needed, run the code below to delete the resource group.
+When the resource is no longer needed, run the following code to delete the resource group.
 
 # [PowerShell](#tab/PowerShell)
 ```powershell-interactive
@@ -286,4 +286,4 @@ In this quickstart guide, you've deployed the FHIR service within Azure Health D
 >[!div class="nextstepaction"]
 >[Supported FHIR Features](fhir-features-supported.md)
 
-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
+[!INCLUDE [FHIR trademark statement](../includes/healthcare-apis-fhir-trademark.md)]

articles/healthcare-apis/fhir/fhir-versioning-policy-and-history-management.md

@@ -11,25 +11,25 @@ ms.author: kesheth
 
 # Versioning policy and history management
 
-The versioning policy in the Azure Health Data Services FHIR service is a configuration, which determines how history is stored for every resource type with the option for resource specific configuration. This policy is directly related to the concept of managing history for FHIR resources.
+The versioning policy in the Azure Health Data Services FHIR® service is a configuration which determines how history is stored for every resource type, with the option for resource specific configuration. This policy is directly related to the concept of managing history for FHIR resources.
 
 ## History in FHIR
 
-History in FHIR gives you the ability to see all previous versions of a resource. History in FHIR can be queried at the resource level, type level, or system level. The HL7 FHIR documentation has more information about the [history interaction](https://www.hl7.org/fhir/http.html#history). History is useful in scenarios where you want to see the evolution of a resource in FHIR or if you want to see the information of a resource at a specific point in time.
+History in FHIR gives you the ability to see all previous versions of a resource. History in FHIR can be queried at the resource level, type level, or system level. The HL7 FHIR documentation has more information about the [history interaction](https://www.hl7.org/fhir/http.html#history). History is useful when you want to see the evolution of a resource in FHIR, or if you want to see a resource's information at a specific point in time.
 
-All past versions of a resource are considered obsolete and the current version of a resource should be used for normal business workflow operations. However, it can be useful to see the state of a resource as a point in time when a past decision was made.
+All past versions of a resource are considered obsolete, and the current version of a resource should be used for normal business workflow operations. However, it can be useful to see the state of a resource as a point in time when a past decision was made.
 
 ## Versioning policy
 
-Versioning policy in the FHIR service lets you decide how history is stored either at a FHIR service level or at a specific resource level. 
+Versioning policy in the FHIR service lets you decide how history is stored, either at a FHIR service level or at a specific resource level. 
 
 There are three different levels for versioning policy:
 
 - `versioned`: History is stored for operation on resources. Resource version is incremented. This is the default.
 - `version-update`: History is stored for operation on resources. Resource version is incremented. Updates require a valid `If-Match` header. For more information, see [VersionedUpdateExample.http](https://github.com/microsoft/fhir-server/blob/main/docs/rest/VersionedUpdateExample.http).
 - `no-version`: History isn't created for resources. Resource version is incremented.
 
-Versioning policy available to configure at as a system-wide setting and also to override at a resource level. The system-wide setting is used for all resources in your FHIR service, unless a specific resource level versioning policy has been added.
+Versioning policy is available to configure as a system-wide setting, and also to override at a resource level. The system-wide setting is used for all resources in your FHIR service, unless a specific resource level versioning policy has been added.
 
 ### Versioning policy comparison
 
@@ -44,15 +44,15 @@ Versioning policy available to configure at as a system-wide setting and also to
 
 ## Configuring versioning policy
 
-To configure versioning policy, select the **Versioning Policy Configuration** blade inside your FHIR service.
+To configure versioning policy, select **Versioning Policy Configuration** inside your FHIR service.
 
 :::image type="content" source="media/versioning-policy/fhir-service-versioning-policy-configuration.png" alt-text="Screenshot of the Azure portal Versioning Policy Configuration." lightbox="media/versioning-policy/fhir-service-versioning-policy-configuration.png":::
 
-After you've browsed to Versioning Policy Configuration, you'll be able to configure the setting at both system level and the resource level (as an override of the system level). The system level configuration (annotated as 1) will apply to every resource in your FHIR service unless a resource specific override (annotated at 2) has been configured.
+After you've browsed to Versioning Policy Configuration, you'll be able to configure the setting at both system level and the resource level (as an override of the system level). The system level configuration (annotated as 1) applies to every resource in your FHIR service unless a resource specific override (annotated as 2) has been configured.
 
 :::image type="content" source="media/versioning-policy/system-level-versus-resource-level.png" alt-text="Screenshot of Azure portal versioning policy configuration showing system level vs resource level configuration." lightbox="media/versioning-policy/system-level-versus-resource-level.png":::
 
-When configuring resource level configuration, you'll be able to select the FHIR resource type (annotated as 1) and the specific versioning policy for this specific resource (annotated as 2). Make sure to select the **Add** button (annotated as 3) to queue up this setting for saving.
+When configuring resource level configuration, you're able to select the FHIR resource type (annotated as 1) and the specific versioning policy for this specific resource (annotated as 2). Make sure to select the **Add** button (annotated as 3) to queue up this setting for saving.
 
 :::image type="content" source="media/versioning-policy/resource-versioning.jpg" alt-text="Screenshot of Azure portal versioning policy configuration showing resource level configuration." lightbox="media/versioning-policy/resource-versioning.jpg":::
 
@@ -62,12 +62,12 @@ When configuring resource level configuration, you'll be able to select the FHIR
 
 ## History management
 
-History in FHIR is important for end users to see how a resource has changed over time. It's also useful in coordination with audit logs to see the state of a resource before and after a user modified it. In general, it's recommended to keep history for a resource unless you know that the history isn't needed. Frequent updates of resources can result in a large amount of data storage, which can be undesired in FHIR services with a large amount of data.
+History in FHIR is important for end users to see how a resource has changed over time. It's also useful in coordination with audit logs to see the state of a resource before and after a user modified it. In general, it's recommended to keep history for a resource unless you know that the history isn't needed. Frequent resource updates can result in a large amount of data storage, which can be undesirable in FHIR services with a large amount of data.
 
-Changing the versioning policy either at a system level or resource level won't remove the existing history for any resources in your FHIR service. If you're looking to reduce the history data size in your FHIR service, you must use the [$purge-history](purge-history.md) operation.
+Changing the versioning policy, either at a system level or resource level, won't remove the existing history for any resources in your FHIR service. If you're looking to reduce the history data size in your FHIR service, you must use the [$purge-history](purge-history.md) operation.
 
 > [!NOTE] 
-> The query parameter _summary=count and _count=0 can be added to _history endpoint to get count of all versioned resources. This count includes soft deleted resources.
+> The query parameter _summary=count and _count=0 can be added to _history endpoint to get a count of all versioned resources. This count includes soft deleted resources.
 
 ## Next steps
 
@@ -76,5 +76,4 @@ In this article, you learned how to purge the history for resources in the FHIR
 >[!div class="nextstepaction"]
 >[Purge history operation](purge-history.md)
 
-FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
-
+[!INCLUDE [FHIR trademark statement](../includes/healthcare-apis-fhir-trademark.md)]

articles/healthcare-apis/fhir/get-started-with-fhir.md

@@ -20,7 +20,7 @@ As a prerequisite, you need an Azure subscription and permissions to create Azur
 
 ## Create a workspace in your Azure subscription
 
-You can create a workspace from the [Azure portal](../healthcare-apis-quickstart.md), or using PowerShell, Azure CLI, and REST API. You can find scripts from the [Azure Health Data Services samples](https://github.com/microsoft/healthcare-apis-samples/tree/main/src/scripts).
+Create a workspace from the [Azure portal](../healthcare-apis-quickstart.md), or using PowerShell, Azure CLI, and REST API. You can find scripts from the [Azure Health Data Services samples](https://github.com/microsoft/healthcare-apis-samples/tree/main/src/scripts).
 
 > [!NOTE]
 > There are limits to the number of workspaces and the number of FHIR service instances you can create in each Azure subscription.
@@ -33,7 +33,7 @@ Optionally, you can create a [DICOM service](../dicom/deploy-dicom-services-in-a
 
 ## Access the FHIR service
 
-The FHIR service is secured by Microsoft Entra ID that can't be disabled. To access the service API, you must create a client application also referred to as a service principal in Microsoft Entra ID and grant it with the right permissions.
+The FHIR service is secured by Microsoft Entra ID that can't be disabled. To access the service API, you must create a client application (also referred to as a service principal) in Microsoft Entra ID, and grant it the right permissions.
 
 ### Register a client application
 
@@ -49,7 +49,7 @@ You can grant access permissions or assign roles in the [Azure portal](../config
 
 ### Perform create, read, update, and delete (CRUD) transactions
 
-You can perform Create, Read (search), Update, and Delete (CRUD) transactions against the FHIR service in your applications or by using tools such as Postman, REST Client, and cURL. Because the FHIR service is secured by default, you need to obtain an access token and include it in your transaction request.
+You can perform Create, Read (search), Update, and Delete - CRUD - transactions against the FHIR service in your applications or by using tools such as Postman, REST Client, and cURL. Because the FHIR service is secured by default, you need to obtain an access token and include it in your transaction request.
 
 #### Get an access token
 
@@ -71,7 +71,7 @@ You can find more details on interoperability and patient access, search, profil
 
 ### Export data
 
-Optionally, you can export ($export) data to [Azure Storage](../data-transformation/export-data.md) and use it in your analytics or machine-learning projects. You can export the data "as-is" or [deID](../data-transformation/de-identified-export.md) in `ndjson` format. 
+Optionally, you can export ($export) data to [Azure Storage](../data-transformation/export-data.md) and use it in your analytics or machine-learning projects. You can export the data "as-is" or [de-identified](../data-transformation/de-identified-export.md) in `ndjson` format. 
 
 ### Convert data