grammar updates

Author: evachen96

articles/healthcare-apis/fhir/fhir-bulk-update.md

@@ -61,7 +61,7 @@ You can use FHIR search parameters in the request. The bulk update operation sup
 
  `PATCH {FHIR-SERVICE-HOST}/DiagnosticReport/$bulk-update?_lastUpdated=lt2021-12-12&_include=DiagnosticReport:based-on:ServiceRequest&_include:iterate=ServiceRequest:encounter`
 
-4. Metadata-only updates with `_meta-history` query parameter: When FHIR server the versioning policy is set to either `versioned` or `version-update`, the `_meta-history` parameter allows you to control whether metadata-only changes to a resource create a new historical version of the resource or not. By default, any change to a resource, including metadata-only changes, creates a new version and saves the previous version as a historical record. When you set the `_meta-history` parameter to false, metadata-only changes do not create a new version, and the previous version is not saved as a historical record. This feature is useful for scenarios where frequent metadata updates are made, and you want to avoid cluttering the resource history with numerous versions that only differ in metadata. For more information and examples, see [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).  
+4. Metadata-only updates with `_meta-history` query parameter: When the FHIR server versioning policy is set to either `versioned` or `version-update`, the `_meta-history` parameter allows you to control whether metadata-only changes to a resource create a new historical version of the resource or not. By default, any change to a resource, including metadata-only changes, creates a new version and saves the previous version as a historical record. When you set the `_meta-history` parameter to false, metadata-only changes do not create a new version, and the previous version is not saved as a historical record. This feature is useful for scenarios where frequent metadata updates are made, and you want to avoid cluttering the resource history with numerous versions that only differ in metadata. For more information and examples, see [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).  
 
  `PATCH https://{FHIR-SERVICE-HOST}/$bulk-update?_meta-history=false`  
 

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

@@ -71,7 +71,7 @@ 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'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.
+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` 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 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.  
 

articles/healthcare-apis/fhir/rest-api-capabilities.md

@@ -182,7 +182,7 @@ Content-Type: `application/json`
 ```
 
 #### Patch with `_meta-history` parameter
-The FHIR service supports the `_meta-history` query parameter with both `PUT` and `PATCH` operations.  When FHIR server the versioning policy is set to either `versioned` or `version-update`, the `_meta-history` parameter allows you to control whether metadata-only changes to a resource create a new historical version of the resource or not. By default, any change to a resource, including metadata-only changes, creates a new version and saves the previous version as a historical record. When you set the `_meta-history` parameter to `false`, metadata-only changes do not create a new version, and the previous version is not saved as a historical record. This feature is useful for scenarios where frequent metadata updates are made, and you want to avoid cluttering the resource history with numerous versions that only differ in metadata. For more information and examples, see [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
+The FHIR service supports the `_meta-history` query parameter with both `PUT` and `PATCH` operations.  When the FHIR server versioning policy is set to either `versioned` or `version-update`, the `_meta-history` parameter allows you to control whether metadata-only changes to a resource create a new historical version of the resource or not. By default, any change to a resource, including metadata-only changes, creates a new version and saves the previous version as a historical record. When you set the `_meta-history` parameter to `false`, metadata-only changes do not create a new version, and the previous version is not saved as a historical record. This feature is useful for scenarios where frequent metadata updates are made, and you want to avoid cluttering the resource history with numerous versions that only differ in metadata. For more information and examples, see [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
 
 `PATCH <fhir server>/Patient/test-patient?_meta-history=false`