fix acrolinx

Author: evachen96

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

@@ -12,7 +12,7 @@ ms.custom: sfi-image-nochange
 
 # 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 that 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
 
@@ -71,9 +71,9 @@ Changing the versioning policy, either at a system level or resource level, won'
 > 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.
 
 ## Metadata-only updates and versioning
-If the versioning policy is set to either `versioned` or `version-update`, metadata-only updates (changes to FHIR resources that only affect the metadata) increment the resource version, create a new version, and save the old version as a historical record. If you are making metadata-only changes using PUT, PATCH, or `$bulk-update`, you can use the query parameter _meta-history for PUT, PATCH, and `$bulk-update` to configure whether or not the old version is saved as a historical record.
+If the versioning policy is set to either `versioned` or `version-update`, metadata-only updates (changes to FHIR resources that only affect the metadata) increment the resource version, create a new version, and save the old version as a historical record. If you're making metadata-only changes using PUT, PATCH, or `$bulk-update`, you can use the query parameter _meta-history for PUT, PATCH, and `$bulk-update` to configure whether or not the old version is saved as a historical record.
 - `_meta-history=true` is set by default. By default, the resource version is incremented, a new version is created, and the old version is saved as a historical record. The lastUpdated timestamp is updated to reflect the change.
-- `_meta-history=false` The `_meta-history` parameter can be configured to `false`. This means that the resource version is incremented, a new version is created, but the old version is not saved as a historical record. The lastUpdated timestamp is also still updated to reflect the change. This configuration can be used to help reduce data storage when making metadata-only updates.  
+- `_meta-history=false` The `_meta-history` parameter can be configured to `false`. This means that the resource version is incremented, a new version is created, but the old version isn't saved as a historical record. The lastUpdated timestamp is also still updated to reflect the change. This configuration can be used to help reduce data storage when making metadata-only updates.  
 
 
 ### Example of `_meta-history=false` with PUT
@@ -92,7 +92,7 @@ To demonstrate the use of the `_meta-history` parameter with PUT, follow this ex
     ]
 }
 ```
-2. Create a new version of the resource with `PUT <fhir server>/Patient/test-patient`. This will have version 2.
+2. Create a new version of the resource with `PUT <fhir server>/Patient/test-patient`. This has version 2.
 ```
 {
     "id": "test-patient",
@@ -127,7 +127,7 @@ To demonstrate the use of the `_meta-history` parameter with PUT, follow this ex
     ]
 }
 ```
-5. This will increment resource version and create a new version 3, but the old version 2 will not be saved as a historical record. To see this, run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 3. Please note that `_meta-history=false` query parameter only affects metadata-only changes made using PUT or PATCH. Using the query parameter to make metadata updates along with other non-metadata field value changes will increment the resource version and save the old version as a historical record.
+5. This increments resource version and create a new version 3, but the old version 2 won't be saved as a historical record. To see this, run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 3. Please note that `_meta-history=false` query parameter only affects metadata-only changes made using PUT or PATCH. Using the query parameter to make metadata updates along with other non-metadata field value changes will increment the resource version and save the old version as a historical record.
 
 
 ### Example of `_meta-history=false` with PATCH or `$bulk-update`