markdown, editorial updates

Author: KendalBond007

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,7 +186,7 @@ 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.
 
@@ -198,7 +198,7 @@ Run the code in PowerShell locally, in Visual Studio Code, or in Azure Cloud She
 
 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
@@ -232,7 +232,7 @@ Run the code locally, in Visual Studio Code or in Azure Cloud Shell, to deploy t
 
 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,5 @@ 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 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.
 
-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,11 +44,11 @@ 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) will apply 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":::
 
@@ -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)]