Minor updates

Author: msjasteppe

articles/healthcare-apis/iot/understand-service.md

@@ -75,14 +75,14 @@ If no Device resource for a given device identifier exists in the FHIR service,
 > [!NOTE]
 > The `Resolution Type` can also be adjusted post deployment of the MedTech service if a different `Resolution Type` is later required.
 
-The MedTech service provides near real-time processing and will also attempt to reduce the number of requests made to the FHIR service by grouping requests into batches of 300 FHIR Observations. If there is a low volume of data, and 300 FHIR Observations haven't been added to the group, FHIR Observations in that group are persisted to the FHIR service after ~five minutes. This means that when there's less than 300 messages added to the event hub, there may be a delay of ~five minutes before FHIR Observations are created/updated in the FHIR service.
+The MedTech service provides near real-time processing and will also attempt to reduce the number of requests made to the FHIR service by grouping requests into batches of 300 FHIR Observations. If there's a low volume of data, and 300 FHIR Observations haven't been added to the group, FHIR Observations in that group are persisted to the FHIR service after ~five minutes. This means that when there's fewer than 300 messages added to the event hub, there may be a delay of ~five minutes before FHIR Observations are created or updated in the FHIR service.
 
 > [!NOTE]
 > When multiple device messages contain data for the same FHIR Observation, have the same timestamp, and are sent within the same device message batch (for example, within the ~five minute window or in device message groups of 300 device messages), only the data corresponding to the latest device message for that FHIR Observation is persisted.
 >
 > For example:
 >
-> Device message one:
+> Device message 1:
 > ```json
 > {    
 >    "patientid": "testpatient1",    
@@ -93,7 +93,7 @@ The MedTech service provides near real-time processing and will also attempt to
 > } 
 > ```
 >
-> Device message two:
+> Device message 2:
 > ```json
 > {   
 >    "patientid": "testpatient1",    
@@ -104,7 +104,7 @@ The MedTech service provides near real-time processing and will also attempt to
 > }
 > ```
 >
-> Assuming these device messages were ingested within the same ~five minute window or in the same group of 300 device messages, and since the `measurementdatetime` is the same for both device messages (indicating these contain data for the same FHIR Observation), only device message two is persisted to represent the latest/most recent data.
+> Assuming these device messages were ingested within the same ~five minute window or in the same group of 300 device messages, and since the `measurementdatetime` is the same for both device messages (indicating these contain data for the same FHIR Observation), only device message 2 is persisted to represent the latest/most recent data.
 
 ## Persist
 Persist is the final stage where the FHIR Observation resources from the transform stage are persisted in the [FHIR service](../fhir/overview.md). If the FHIR Observation resource is new, it's created in the FHIR service. If the FHIR Observation resource already existed, it gets updated in the FHIR service.