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/overview-of-device-message-processing-stages.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ author: msjasteppe
6
6
ms.service: healthcare-apis
7
7
ms.subservice: iomt
8
8
ms.topic: overview
9
-
ms.date: 04/04/2023
9
+
ms.date: 04/07/2023
10
10
ms.author: jasteppe
11
11
---
12
12
@@ -57,7 +57,7 @@ Group is the next *optional* stage where the normalized messages available from
57
57
Device identity and measurement type grouping are optional and enabled by the use of the [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData) measurement type. The SampledData measurement type provides a concise way to represent a time-based series of measurements from a device message into FHIR Observations. When you use the SampledData measurement type, measurements can be grouped into a single FHIR Observation that represents a 1-hour period or a 24-hour period.
58
58
59
59
## Transform
60
-
Transform is the next stage where normalized messages are processed using the user-selected/user-created conforming and valid [FHIR destination mapping](how-to-configure-fhir-mappings.md). Normalized messages get transformed into FHIR Observation resources if a matching FHIR destination mapping has been authored. At this point, the [Device](https://www.hl7.org/fhir/device.html) resource, along with its associated [Patient](https://www.hl7.org/fhir/patient.html) resource, is also retrieved from the FHIR service using the device identifier present in the device message. These resources are added as a reference to the FHIR Observation being created.
60
+
Transform is the next stage where normalized messages are processed using the user-selected/user-created conforming and valid [FHIR destination mapping](how-to-configure-fhir-mappings.md). Normalized messages get transformed into FHIR Observations if a matching FHIR destination mapping has been authored. At this point, the [Device](https://www.hl7.org/fhir/device.html) resource, along with its associated [Patient](https://www.hl7.org/fhir/patient.html) resource, is also retrieved from the FHIR service using the device identifier present in the device message. These resources are added as a reference to the FHIR Observation being created.
61
61
62
62
> [!NOTE]
63
63
> All identity look ups are cached once resolved to decrease load on the FHIR service. If you plan on reusing devices with multiple patients, it is advised you create a virtual device resource that is specific to the patient and send the virtual device identifier in the device message payload. The virtual device can be linked to the actual device resource as a parent.
@@ -67,10 +67,10 @@ If no Device resource for a given device identifier exists in the FHIR service,
67
67
> [!NOTE]
68
68
> The **Resolution type** can also be adjusted post deployment of the MedTech service if a different **Resolution type** is later required.
69
69
70
-
The MedTech service provides near real-time processing and also attempts 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.
70
+
The MedTech service provides near real-time processing and also attempts 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 approximately five minutes. When there's fewer than 300 normalized messages to be processed, there may be a delay of approximately five minutes before FHIR Observations are created or updated in the FHIR service.
71
71
72
72
> [!NOTE]
73
-
> 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.
73
+
> 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.
74
74
>
75
75
> For example:
76
76
>
@@ -96,10 +96,10 @@ The MedTech service provides near real-time processing and also attempts to redu
96
96
> }
97
97
> ```
98
98
>
99
-
> 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.
99
+
> 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.
100
100
101
101
## Persist
102
-
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 is new, it's created in the FHIR service. If the FHIR Observation already existed, it gets updated in the FHIR service. The FHIR service 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 FHIR service.
102
+
Persist is the final stage where the FHIR Observations from the transform stage are persisted in the [FHIR service](../fhir/overview.md). If the FHIR Observation is new, it's created in the FHIR service. If the FHIR Observation already existed, it gets updated in the FHIR service. The FHIR service 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 FHIR service.
Copy file name to clipboardExpand all lines: articles/healthcare-apis/iot/overview.md
+30-26Lines changed: 30 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ author: msjasteppe
6
6
ms.service: healthcare-apis
7
7
ms.subservice: fhir
8
8
ms.topic: overview
9
-
ms.date: 04/06/2023
9
+
ms.date: 04/10/2023
10
10
ms.author: jasteppe
11
11
---
12
12
@@ -15,83 +15,87 @@ ms.author: jasteppe
15
15
> [!NOTE]
16
16
> [Fast Healthcare Interoperability Resources (FHIR®)](https://www.hl7.org/fhir/) is an open healthcare specification.
17
17
18
-
This article provides an introductory overview of the MedTech service. The MedTech service in Azure Health Data Services is a Platform as a service (PaaS) that enables you to gather data from diverse devices and convert it into a FHIR service format. The MedTech service's device data translation capabilities make it possible to transform a wide variety of data into a unified FHIR format that provides secure data management in a cloud environment.
18
+
This article provides an introductory overview of the MedTech service. The MedTech service is a Platform as a Service (PaaS) within the Azure Health Data Services. The MedTech service that enables you to ingest device data, transform it into a unified FHIR format, and store it in an enterprise-scale, secure, and compliant cloud environment.
19
19
20
-
The MedTech service is important because data can be difficult to access or lost when it comes from diverse or incompatible devices, systems, or formats. If this information isn't easy to access, it may have a negative effect on gaining key insights and capturing trends. The ability to transform many types of device data into a unified FHIR format enables the MedTech service to successfully link device data with other datasets to support the end user. As a result, this capability can facilitate the discovery of important clinical insights and trend capture. It can also help make connections to new device applications and enable advanced research projects.
20
+
The MedTech service was built to help customers that were dealing with the challenge of gaining relevant insights from device data coming in from multiple and diverse sources. No matter the device or structure, the MedTech service normalizes that device data into a common format, allowing the end user to then easily capture trends, run analytics, and build Artificial Intelligence (AI) models. In the enterprise healthcare setting, the MedTech service is used in the context of remote patient monitoring, virtual health, and clinical trials.
21
21
22
22
The following video presents an overview of the MedTech service:
23
-
23
+
>
24
24
> [!VIDEO https://youtube.com/embed/_nMirYYU0pg]
25
25
26
26
## How the MedTech service works
27
27
28
-
The following diagram outlines the basic elements of how the MedTech service transforms device data into a standardized FHIR resource in the cloud.
28
+
The following diagram outlines the basic elements of how the MedTech service transforms device data into standardized [FHIR Observations](https://www.hl7.org/fhir/R4/observation.html) in Azure.
29
29
30
30
:::image type="content" source="media/overview/what-is-simple-diagram.png" alt-text="Simple diagram showing the MedTech service." lightbox="media/overview/what-is-simple-diagram.png":::
31
31
32
-
These elements are:
33
-
34
32
### Deployment
35
33
36
-
In order to implement the MedTech service, you need to have an Azure subscription, set up a workspace, and set up a namespace to deploy three Azure services: MedTech service, FHIR service, and Event Hubs service. This setup creates the PaaS configuration required to receive and process data from Internet of Things (IoT) devices.
34
+
In order to implement the MedTech service, you need to have these resources:
35
+
* An Azure subscription.
36
+
* A resource group.
37
+
* An Azure Event Hubs namespace containing an event hub.
38
+
* An Azure Health Data service workspace.
39
+
40
+
With the resources in place, deploy the MedTech service and the FHIR service within the workspace. This setup creates the PaaS configuration required to receive and process device data from Internet of Things (IoT) devices.
37
41
38
42
### Devices
39
43
40
-
After the PaaS deployment is completed, high-velocity and low-velocity data can be collected from a wide range of JSON-compatible IoMT devices, systems, and formats.
44
+
After the deployments are completed, high-velocity and low-velocity device data can be collected from a wide range of JSON-compatible IoT devices, systems, and formats.
41
45
42
-
### Event Hubs service
46
+
### Event hub
43
47
44
-
IoT data is then sent from a device over the Internet to Event Hubs service to hold it temporarily in the cloud. The event hub can asynchronously process millions of data points per second, eliminating data traffic jams, making it possible to easily handle huge amounts of information in real-time.
48
+
Device data is sent from a device over the Internet to an event hub to hold it temporarily in Azure. The event hub can asynchronously process millions of data points per second, eliminating data traffic jams, making it possible to easily handle huge amounts of information in real-time.
45
49
46
50
### The MedTech service
47
51
48
-
When the device data has been loaded into Event Hubs service, the MedTech service can then process it in five stages to convert the data into a unified FHIR format.
52
+
When the device data has been loaded into event hub, the MedTech service can then process it in five stages to transform the device data into a unified FHIR format.
49
53
50
54
These stages are:
51
55
52
56
1.**Ingest** - The MedTech service asynchronously loads the device data from the event hub at high speed.
53
57
54
-
2.**Normalize** - After the data has been ingested, the MedTech service uses device mapping to streamline and translate it into a normalized schema format.
58
+
2.**Normalize** - After the device data has been ingested, the MedTech service uses the device mapping to streamline and convert it into a normalized schema format.
55
59
56
60
3.**Group** - The normalized data is then grouped by parameters to prepare it for the next stage of processing. The parameters are: device identity, measurement type, time period, and (optionally) correlation ID.
57
61
58
-
4.**Transform** - When the normalized data is grouped, it's transformed through FHIR destination mapping templates and is ready to become FHIR Observation resources.
62
+
4.**Transform** - When the normalized data is grouped, it's transformed through the FHIR destination mapping and is ready to become FHIR Observations.
59
63
60
-
5.**Persist** - After the transformation is done, the new data is sent to FHIR service and persisted as an Observation resource.
64
+
5.**Persist** - After the transformation is done, the new data is sent to FHIR service and persisted as FHIR Observations.
61
65
62
66
### FHIR service
63
67
64
-
The MedTech service data processing is complete when the new FHIR Observation resource is successfully persisted, saved into the FHIR service, and ready for use.
68
+
The MedTech service data processing is complete when the new FHIR Observations are successfully persistedinto the FHIR service and ready for use.
65
69
66
70
## Key features of the MedTech service
67
71
68
-
The MedTech service has many features that make it secure, configurable, scalable, and extensible.
72
+
The MedTech service has many features that make it secure, configurable, scalable, and extensible.
69
73
70
74
### Secure
71
75
72
-
The MedTech service delivers your data to FHIR service in Azure Health Data Services, ensuring that your data has unparalleled security and advanced threat protection. The FHIR service isolates your data in a unique database per API instance and protects it with multi-region failover. In addition, the MedTech service uses [Azure role-based access control (Azure RBAC)](../../role-based-access-control/overview.md) and a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) for extra security and control of your MedTech service assets.
76
+
The MedTech service delivers your device data into FHIR service, ensuring that your data has unparalleled security and advanced threat protection. The FHIR service isolates your data in a unique database per API instance and protects it with multi-region failover. In addition, the MedTech service uses [Azure role-based access control (Azure RBAC)](../../role-based-access-control/overview.md) and a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) for extra security and control of your MedTech service assets.
73
77
74
78
### Configurable
75
79
76
-
The MedTech service can be customized and configured by using [device](how-to-configure-device-mappings.md) and [FHIR destination](how-to-configure-fhir-mappings.md) mappings to define the filtering and transformation of your data into FHIR Observation resources.
80
+
The MedTech service can be customized and configured by using [device](how-to-configure-device-mappings.md) and [FHIR destination](how-to-configure-fhir-mappings.md) mappings to define the filtering and transformation of your data into FHIR Observations.
77
81
78
82
Useful options could include:
79
83
80
-
- Linking devices and consumers together for enhanced insights, trend capture, interoperability between systems, and proactive and remote monitoring.
84
+
- Linking devices and consumers together for enhanced insights, trend captures, interoperability between systems, and proactive and remote monitoring.
81
85
82
-
- FHIR observation resources that can be created or updated according to existing or new templates.
86
+
- FHIR Observations that can be created or updated according to existing or new mappings.
83
87
84
88
- Being able to choose data terms that work best for your organization and provide consistency in device data ingestion.
85
89
86
-
- Facilitating customization, editing, testing, and troubleshooting MedTech service Device and FHIR destination mappings with The [IoMT Connector Data Mapper](https://github.com/microsoft/iomt-fhir/tree/master/tools/data-mapper) open-source tool.
90
+
- Facilitating customization, editing, testing, and troubleshooting MedTech service device and FHIR destination mappings with the [Mapping debugger](how-to-use-mapping-debugger.md) tool.
87
91
88
92
### Scalable
89
93
90
-
The MedTech service enables developers to easily modify and extend the capabilities of the MedTech service to support new device mapping template types and FHIR resources.
94
+
The MedTech service enables you to easily modify and extend the capabilities of the MedTech service to support new device mapping template types and FHIR resources.
91
95
92
96
### Integration
93
97
94
-
The MedTech service may also be integrated into our [open-source projects](git-projects.md) for ingesting IoMT device data from these wearables:
98
+
The MedTech service may also be integrated into our [open-source projects](git-projects.md) for ingesting device data from these wearables:
95
99
96
100
- Fitbit®
97
101
@@ -113,10 +117,10 @@ The following Microsoft solutions can use MedTech service for extra functionalit
113
117
114
118
In this article, you learned about the MedTech service and its capabilities.
115
119
116
-
To learn about how the MedTech service processes device messages, see
120
+
To learn about how the MedTech service processes device data, see
117
121
118
122
> [!div class="nextstepaction"]
119
-
> [Overview of the MedTech service device message processing stages](overview-of-device-message-processing-stages.md)
123
+
> [Overview of the MedTech service device data processing stages](overview-of-device-message-processing-stages.md)
120
124
121
125
To learn about the different deployment methods for the MedTech service, see
0 commit comments