Merge pull request #233952 from msjasteppe/overview-updates

Updates to docset

Author: v-shils

articles/healthcare-apis/iot/how-to-use-mapping-debugger.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: iomt
 ms.topic: how-to
-ms.date: 04/06/2023
+ms.date: 04/10/2023
 ms.author: jasteppe
 ---
 
@@ -21,10 +21,10 @@ ms.author: jasteppe
 In this article, learn how to use the MedTech service Mapping debugger. The Mapping debugger is a self-service tool that is used for creating, updating, and troubleshooting the MedTech service device and FHIR destination mappings. The Mapping debugger enables you to easily view and make inline adjustments in real-time, without ever having to leave the Azure portal. The Mapping debugger can also be used for uploading test device messages to see how they'll look after being processed into normalized messages and transformed into FHIR Observations.
 
 > [!TIP]
-> To learn about how the MedTech service transforms and persists device message data into the FHIR service see, [Overview of the MedTech service device message processing stages](overview-of-device-message-processing-stages.md).
+> To learn about how the MedTech service transforms and persists device message data into the FHIR service see, [Overview of the MedTech service device data processing stages](overview-of-device-message-processing-stages.md).
 
 The following video presents an overview of the Mapping debugger:
-
+>
 > [!VIDEO https://youtube.com/embed/OEGuCSGnECY]
 
 ## Overview of the Mapping debugger
@@ -62,7 +62,7 @@ The following video presents an overview of the Mapping debugger:
    :::image type="content" source="media\how-to-use-mapping-debugger\mapping-debugger-save-mappings.png" alt-text="Screenshot of the Mapping debugger and the Save button." lightbox="media\how-to-use-mapping-debugger\mapping-debugger-save-mappings.png":::
 
    > [!NOTE]
-   > The MedTech service only saves the mappings that have been changed/updated. For example: If you only made a change to the **device mapping**, only those changes are saved to your MedTech service and no changes would be saved to the FHIR destination mapping. This is by design and to help with performance of the MedTech service.
+   > The MedTech service only saves the mappings that have been changed/updated. For example: If you only made a change to the **device mapping**, only those changes are saved to your MedTech service and no changes would be saved to the **FHIR destination mapping**. This is by design and to help with performance of the MedTech service.
 
 4. Once the device and FHIR destination mappings are successfully saved, a confirmation from **Notifications** is created within the Azure portal.
 

articles/healthcare-apis/iot/overview-of-device-message-processing-stages.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: iomt
 ms.topic: overview
-ms.date: 04/04/2023
+ms.date: 04/07/2023
 ms.author: jasteppe
 ---
 
@@ -57,7 +57,7 @@ Group is the next *optional* stage where the normalized messages available from
 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.
 
 ## Transform
-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.
+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.
 
 > [!NOTE]
 > 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,
 > [!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 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.
+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.
 
 > [!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.
+> 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:
 >
@@ -96,10 +96,10 @@ The MedTech service provides near real-time processing and also attempts to redu
 > }
 > ```
 >
-> 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.
+> 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 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.
+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.
 
 ## Next steps
 

articles/healthcare-apis/iot/overview.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: fhir
 ms.topic: overview
-ms.date: 04/06/2023
+ms.date: 04/13/2023
 ms.author: jasteppe
 ---
 
@@ -15,83 +15,61 @@ ms.author: jasteppe
 > [!NOTE]
 > [Fast Healthcare Interoperability Resources (FHIR®)](https://www.hl7.org/fhir/) is an open healthcare specification.
 
-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.
+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. 
 
-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.
+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.
 
 The following video presents an overview of the MedTech service:
-
+>
 > [!VIDEO https://youtube.com/embed/_nMirYYU0pg]
 
 ## How the MedTech service works
 
-The following diagram outlines the basic elements of how the MedTech service transforms device data into a standardized FHIR resource in the cloud.
+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) for persistence in the FHIR service.
 
 :::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":::
 
-These elements are:
-
-### Deployment
-
-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.
-
-### Devices
-
-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.
-
-### Event Hubs service
+The MedTech service processes device data in five stages:
 
- 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.
+1. **Ingest** - The MedTech service asynchronously loads the device messages from the event hub at high speed.
 
-### The MedTech service
-
-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.
-
-These stages are:
-
-1. **Ingest** - The MedTech service asynchronously loads the device data from the event hub at high speed.
-
-2. **Normalize** - After the data has been ingested, the MedTech service uses device mapping to streamline and translate it into a normalized schema format.
+2. **Normalize** - After the device message has been ingested, the MedTech service uses the device mapping to streamline and convert the device data into a normalized schema format.
 
 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.
 
-4. **Transform** - When the normalized data is grouped, it's transformed through FHIR destination mapping templates and is ready to become FHIR Observation resources.
-
-5. **Persist** - After the transformation is done, the new data is sent to FHIR service and persisted as an Observation resource.
-
-### FHIR service
+4. **Transform** - When the normalized data is grouped, it's transformed through the FHIR destination mapping and is ready to become FHIR Observations.
 
-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.
+5. **Persist** - After the transformation is done, the new data is sent to FHIR service and persisted as FHIR Observations.
 
 ## Key features of the MedTech service
 
-The MedTech service has many features that make it secure, configurable,  scalable, and extensible.
+The MedTech service has many features that make it secure, configurable, scalable, and extensible.
 
 ### Secure
 
-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. 
+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. 
 
 ### Configurable
 
-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.
+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.
 
 Useful options could include:
 
-- Linking devices and consumers together for enhanced insights, trend capture, interoperability between systems, and proactive and remote monitoring.
+- Link devices and consumers together for enhanced insights, trend captures, interoperability between systems, and proactive and remote monitoring.
 
-- FHIR observation resources that can be created or updated according to existing or new templates.
+- Update or create FHIR Observations according to existing or new mapping template types.
 
-- Being able to choose data terms that work best for your organization and provide consistency in device data ingestion.
+- Choose data terms that work best for your organization and provide consistency in device data ingestion.
 
-- 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.
+- Customize, edit, test, and troubleshoot MedTech service device and FHIR destination mappings with the [Mapping debugger](how-to-use-mapping-debugger.md) tool.
 
 ### Scalable
 
-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.
+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.
 
 ### Integration
 
-The MedTech service may also be integrated into our [open-source projects](git-projects.md) for ingesting IoMT device data from these wearables:
+The MedTech service may also be integrated for ingesting device data from these wearables using our [open-source projects](git-projects.md): 
 
 - Fitbit®
 
@@ -113,10 +91,10 @@ The following Microsoft solutions can use MedTech service for extra functionalit
 
 In this article, you learned about the MedTech service and its capabilities.
 
-To learn about how the MedTech service processes device messages, see
+To learn about how the MedTech service processes device data, see
 
 > [!div class="nextstepaction"]
-> [Overview of the MedTech service device message processing stages](overview-of-device-message-processing-stages.md)
+> [Overview of the MedTech service device data processing stages](overview-of-device-message-processing-stages.md)
 
 To learn about the different deployment methods for the MedTech service, see