You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/healthcare-apis/iot/understand-service.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,10 +75,10 @@ If no Device resource for a given device identifier exists in the FHIR service,
75
75
> [!NOTE]
76
76
> The `Resolution Type` can also be adjusted post deployment of the MedTech service if a different `Resolution Type` is later required.
77
77
78
-
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.
78
+
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.
79
79
80
80
> [!NOTE]
81
-
> 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.
81
+
> 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.
82
82
>
83
83
> For example:
84
84
>
@@ -104,7 +104,7 @@ The MedTech service provides near real-time processing and will also attempt to
104
104
> }
105
105
> ```
106
106
>
107
-
> 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.
107
+
> 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.
108
108
109
109
## Persist
110
110
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.
0 commit comments