edits for clarity or conformity

Author: KendalBond007

articles/healthcare-apis/fhir/convert-data-overview.md

@@ -35,7 +35,7 @@ The health data for conversion is delivered to the FHIR service in the body of t
 
 ##  Parameters
 
-A `$convert-data` operation call packages the health data for conversion inside a JSON-formatted [parameters](http://hl7.org/fhir/parameters.html) in the body of the request. The parameters are described in the following table: 
+A `$convert-data` operation call packages the health data for conversion inside JSON-formatted [parameters](http://hl7.org/fhir/parameters.html) in the body of the request. The parameters are described in the following table.
 
 | Parameter name | Description           | Accepted values |
 | -------------- | ----------------------------------------------------------------------- | --------------- |
@@ -48,7 +48,7 @@ A `$convert-data` operation call packages the health data for conversion inside
 
 - **FHIR STU3 to FHIR R4 templates are Liquid templates** that provide mappings of field differences only between a FHIR STU3 resource and its equivalent resource in the FHIR R4 specification. Some of the FHIR STU3 resources are renamed or removed from FHIR R4. For more information about the resource differences and constraints for FHIR STU3 to FHIR R4 conversion, see [Resource differences and constraints for FHIR STU3 to FHIR R4 conversion](https://github.com/microsoft/FHIR-Converter/blob/main/docs/Stu3R4-resources-differences.md).
 
-- **JSON templates are sample templates for use in building your own conversion mappings.** They aren't default templates that adhere to any predefined health data message types. JSON itself isn't specified as a health data format, unlike HL7v2 or C-CDA. Therefore, instead of providing default JSON templates, we provide some sample JSON templates as a starting point for your own customized mappings.
+- **JSON templates are sample templates for use in building your own conversion mappings.** They aren't default templates that adhere to any predefined health data message types. JSON itself isn't specified as a health data format, unlike HL7v2 or C-CDA. As a result, instead of providing default JSON templates, we provide some sample JSON templates as a starting point for your own customized mappings.
 
 > [!WARNING]
 > Default templates are released under the MIT License and aren't supported by Microsoft.

articles/healthcare-apis/fhir/convert-data-troubleshoot.md

@@ -24,14 +24,14 @@ Two main factors come into play that determine how long a `$convert-data` operat
 Any loops or iterations in the templates can have large impacts on performance. The `$convert-data` operation has a post processing step that is run after the template is applied. In particular, the deduping step can mask template issues that cause performance problems. Updating the template so duplicates aren’t generated can greatly increase performance. For more information and details about the post processing step, see [Post processing](#post-processing).
 
 ## Post processing
-The `$convert-data` operation applies post processing logic after the template is applied to the input. This post processing logic can result in the output looking different or unexpected errors compared to if you ran the default Liquid template directly. Post processing ensures the output is valid JSON and removes any duplicates based on the ID properties generated for resources in the template. To see the post processing logic in more detail, see the [FHIR-Converter GitHub repository](https://github.com/microsoft/FHIR-Converter/blob/main/src/Microsoft.Health.Fhir.Liquid.Converter/OutputProcessors/PostProcessor.cs).
+The `$convert-data` operation applies post processing logic after the template is applied to the input. This post processing logic can result in the output looking different, or unexpected errors compared to running the default Liquid template directly. Post processing ensures the output is valid JSON and removes any duplicates based on the ID properties generated for resources in the template. To see the post processing logic in more detail, see the [FHIR-Converter GitHub repository](https://github.com/microsoft/FHIR-Converter/blob/main/src/Microsoft.Health.Fhir.Liquid.Converter/OutputProcessors/PostProcessor.cs).
 
 ## Message size
-There isn’t a hard limit on the size of the messages allowed for the `$convert-data` operation, however, for content with a request size  greater than 10 MB, server 500 errors are possible. If you're receiving 500 server errors, ensure your requests are under 10 MB.
+There isn’t a hard limit on the size of the messages allowed for the `$convert-data` operation. However, for content with a request size greater than 10 MB, server errors `500` are possible. If you're receiving `500` server errors, ensure your requests are under 10 MB.
 
 ## Why are my dates being converted when transforming JSON data?
 
-It's possible for dates supplied within JSON data to be returned in a different format than what was supplied. During deserialization of the JSON payload strings that are identified as dates get converted into .NET DateTime objects. These objects then get converted back to strings before going through the Liquid template engine. This conversion can cause the date value to be reformatted and represented in the local timezone of the FHIR service.
+It's possible for dates supplied within JSON data to be returned in a different format than what was supplied. During deserialization of the JSON payload, strings that are identified as dates get converted into .NET DateTime objects. These objects then get converted back to strings before going through the Liquid template engine. This conversion can cause the date value to be reformatted, and represented in the local timezone of the FHIR service.
 
 The coercion of strings to .NET DateTime objects can be disabled using the boolean parameter `jsonDeserializationTreatDatesAsStrings`. When set to `true`, the supplied data is treated as a string and won't be modified before being supplied to the Liquid engine.