Merge pull request #228231 from msjasteppe/understand-updates

Adding in note regarding latest data ingested

Author: denrea

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

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: iomt
 ms.topic: overview
-ms.date: 02/14/2023
+ms.date: 02/22/2023
 ms.author: jasteppe
 ---
 
@@ -29,7 +29,7 @@ The MedTech service device message data processing follows these steps and in th
 :::image type="content" source="media/understand-service/understand-device-message-flow.png" alt-text="Screenshot of a device message as it processed by the MedTech service." lightbox="media/understand-service/understand-device-message-flow.png":::
 
 ## Ingest
-Ingest is the first stage where device messages are received from an [Azure Event Hubs](../../event-hubs/index.yml) event hub (`device message event hub`) and immediately pulled into the MedTech service. The Event Hubs service supports high scale and throughput with the ability to receive and process millions of device messages per second. It also enables the MedTech service to consume messages asynchronously, removing the need for devices to wait while device messages are processed. 
+Ingest is the first stage where device messages are received from an [Azure Event Hubs](../../event-hubs/index.yml) event hub and immediately pulled into the MedTech service. The Event Hubs service supports high scale and throughput with the ability to receive and process millions of device messages per second. It also enables the MedTech service to consume messages asynchronously, removing the need for devices to wait while device messages are processed. 
 
 The device message event hub uses the MedTech service's [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md#managed-identity-types) and [Azure resource-based access control (Azure RBAC)](../../role-based-access-control/overview.md) for secure access to the device message event hub.
 
@@ -73,9 +73,38 @@ At this point, the [Device](https://www.hl7.org/fhir/device.html) resource, alon
 If no Device resource for a given device identifier exists in the FHIR service, the outcome depends upon the value of [Resolution Type](deploy-new-config.md#configure-the-destination-tab) set at the time of the MedTech service deployment. When set to `Lookup`, the specific message is ignored, and the pipeline continues to process other incoming device messages. If set to `Create`, the MedTech service creates minimal Device and Patient resources in the FHIR service.  
 
 > [!NOTE]
-> The `Resolution Type` can also be adjusted post deployment of the MedTech service in the event that a different type is later desired.
+> The `Resolution Type` can also be adjusted post deployment of the MedTech service if a different `Resolution Type` is later required.
 
-The MedTech service buffers the FHIR Observations resources created during the transformation stage and provides near real-time processing. However, it can potentially take up to five minutes for FHIR Observation resources to be persisted 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 [normalized messages](#normalize). If there's a low volume of data, and 300 normalized messages haven't been added to the group, then the corresponding FHIR Observations in that group are persisted to the FHIR service after ~five minutes. This means that when there's fewer than 300 normalized messages to be processed, 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 groups of 300 normalized messages), only the data corresponding to the latest device message for that FHIR Observation is persisted.
+>
+> For example:
+>
+> Device message 1:
+> ```json
+> {    
+>    "patientid": "testpatient1",    
+>    "deviceid": "testdevice1",
+>    "systolic": "129",    
+>    "diastolic": "65",    
+>    "measurementdatetime": "2022-02-15T04:00:00.000Z"
+> } 
+> ```
+>
+> Device message 2:
+> ```json
+> {   
+>    "patientid": "testpatient1",    
+>    "deviceid": "testdevice1",    
+>    "systolic": "113",    
+>    "diastolic": "58",    
+>    "measurementdatetime": "2022-02-15T04:00:00.000Z"
+> }
+> ```
+>
+> Assuming these device messages were ingested within the same ~five minute window or in the same group of 300 normalized 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.