Merge pull request #240390 from msjasteppe/iotjsonpathcontent-updates

Major updates to IotJsonPathContent article

Author: v-dirichards

articles/healthcare-apis/iot/device-messages-through-iot-hub.md

@@ -124,7 +124,7 @@ When deployment is completed, the following resources and access roles are creat
 
   * **Azure Event Hubs Data Sender** role. In this deployment, the sender role is named *devicedatasender* and can be used to provide access to the event hub using a shared access signature (SAS). To learn more about authorizing access using a SAS, see [Authorizing access to Event Hubs resources using Shared Access Signatures](../../event-hubs/authorize-access-shared-access-signature.md). The **Azure Event Hubs Data Sender** role isn't used in this tutorial.
 
-* IoT hub with [message routing](../../iot-hub/iot-hub-devguide-messages-d2c.md) configured to send device messages to the event hub.
+* IoT hub with [message routing](../../iot-hub/iot-hub-devguide-messages-d2c.md) configured to route device messages to the event hub.
 
 * [User-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md), which provides send access from the IoT hub to the event hub. The managed identity has the **Azure Event Hubs Data Sender** role in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.
 
@@ -211,7 +211,7 @@ You complete the steps by using Visual Studio Code with the Azure IoT Hub extens
    After you select **Send**, it might take up to five minutes for the FHIR resources to be available in the FHIR service.
 
    > [!IMPORTANT]
-   > To avoid device spoofing in device-to-cloud (D2C) messages, Azure IoT Hub enriches all device messages with additional properties before sending it to the MedTech service device event hub. For example: **Properties**: `iothub-creation-time-utc` and **SystemProperties**: `iothub-connection-device-id`. For more information, see [Anti-spoofing properties](../../iot-hub/iot-hub-devguide-messages-construct.md#anti-spoofing-properties) and [How to use IotJsonPathContent mappings](how-to-use-iot-jsonpath-content-mappings.md). 
+   > To avoid device spoofing in device-to-cloud (D2C) messages, Azure IoT Hub enriches all device messages with additional properties before routing them to the event hub. For example: **Properties**: `iothub-creation-time-utc` and **SystemProperties**: `iothub-connection-device-id`. For more information, see [Anti-spoofing properties](../../iot-hub/iot-hub-devguide-messages-construct.md#anti-spoofing-properties) and [How to use IotJsonPathContent templates with the MedTech service device mapping](how-to-use-iotjsonpathcontent-templates.md). 
    >
    > You do not want to send this example device message to your IoT hub as the enrichments will be duplicated by the IoT hub and cause an error with your MedTech service. This is only an example of how your device messages are enriched by the IoT hub. 
    >

articles/healthcare-apis/iot/how-to-use-calculatedcontent-templates.md

@@ -5,7 +5,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: fhir
 ms.topic: how-to
-ms.date: 06/07/2023
+ms.date: 07/20/2023
 ms.author: jasteppe
 ---
 
@@ -48,8 +48,8 @@ In the following example, `typeMatchExpression` is defined as:
 
 The CalculatedContent templates allow matching on and extracting values from a device message read from an Azure Event Hubs event hub through the following expressions:
 
-|Element|Description|JSONPath expression|JMESPath expression|
-|:------|:----------|:------------------|:------------------|
+|Element|Description|JSONPath expression example|JMESPath expression example|
+|:------|:----------|:--------------------------|:--------------------------|
 |typeMatchExpression|The expression that the MedTech service evaluates against the device message payload. If the service finds a matching token value, it considers the template a match. The service evaluates all later expressions against the extracted token value matched here.|`$..[?(@heartRate)]`|``[Body][?contains(keys(@), `heartRate`)] \| @[0]``|
 |deviceIdExpression|The expression to extract the device identifier.|`$.matchedToken.deviceId`|`@.matchedToken.deviceId`|
 |timestampExpression|The expression to extract the timestamp value for the measurement's `OccurrenceTimeUtc` value.|`$.matchedToken.endDate`|`@.matchedToken.endDate`|
@@ -58,6 +58,9 @@ The CalculatedContent templates allow matching on and extracting values from a d
 |correlationIdExpression|*Optional*: The expression to extract the correlation identifier. You can use this output to group values into a single observation in the FHIR destination mapping.|`$.matchedToken.correlationId`|`@.matchedToken.correlationId`|
 |values[].valueExpression|The expression to extract the wanted value.|`$.matchedToken.heartRate`|`@.matchedToken.heartRate`|
 
+> [!NOTE]
+> The **Resolution type** specifies how the MedTech service associates device data with Device resources and Patient resources. The MedTech service reads Device and Patient resources from the FHIR service using [device identifiers](https://www.hl7.org/fhir/r4/device-definitions.html#Device.identifier) and [patient identifiers](https://www.hl7.org/fhir/r4/patient-definitions.html#Patient.identifier). If an [encounter identifier](https://hl7.org/fhir/r4/encounter-definitions.html#Encounter.identifier) is specified and extracted from the device data payload, it's linked to the observation if an encounter exists on the FHIR service with that identifier.  If the [encounter identifier](../../healthcare-apis/release-notes.md#medtech-service) is successfully normalized, but no FHIR Encounter exists with that encounter identifier, a **FhirResourceNotFound** exception is thrown. For more information on configuring the MedTech service **Resolution type**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).
+
 ## Expression languages
 
 When you're specifying the language to use for the expression, the following values are valid:
@@ -67,7 +70,7 @@ When you're specifying the language to use for the expression, the following val
 | JSONPath            | `JsonPath` |
 | JMESPath            | `JmesPath` |
 
-Because JSONPath is the default expression language, it's not required to include the expression language within a CalculatedContent template:
+Because JSONPath is the default expression language, it's not required to include the expression language within a CalculatedContent template.
 
 ```json
 "templateType": "CalculatedContent",
@@ -110,49 +113,50 @@ In this example, we're using a device message that is capturing `heartRate` data
 
 ```json
 {
-  "heartRate": "78",
-  "endDate": "2023-03-13T22:46:01.8750000",
-  "deviceId": "device01"
+    "heartRate": "78",
+    "endDate": "2023-03-13T22:46:01.8750000",
+    "deviceId": "device01"
 }
 ```
 
 The event hub enriches the device message before the MedTech service reads the device message from the event hub:
 
 ```json
 {
-  "Body": {
-    "heartRate": "78",
-    "endDate": "2023-03-13T22:46:01.8750000",
-    "deviceId": "device01"
-  }
+    "Body": {
+        "heartRate": "78",
+        "endDate": "2023-03-13T22:46:01.8750000",
+        "deviceId": "device01"
+    }
 }
 ```
 
 We're using this device mapping for the normalization stage:
 
 ```json
 {
-  "templateType": "CollectionContent",
-  "template": [
-    {
-      "templateType": "CalculatedContent",
-      "template": {
-        "typeName": "heartrate",
-        "typeMatchExpression": "$..[?(@heartRate)]",
-        "deviceIdExpression": "$.matchedToken.deviceId",
-        "timestampExpression": "$.matchedToken.endDate",
-        "values": [
-          {
-            "required": true,
-            "valueExpression": "$.matchedToken.heartRate",
-            "valueName": "hr"
-          }
-        ]
-      }
-    }
-  ]
+    "templateType": "CollectionContent",
+    "template": [
+        {
+            "templateType": "CalculatedContent",
+            "template": {
+                "typeName": "heartrate",
+                "typeMatchExpression": "$..[?(@heartRate)]",
+                "deviceIdExpression": "$.matchedToken.deviceId",
+                "timestampExpression": "$.matchedToken.endDate",
+                "values": [
+                    {
+                        "required": true,
+                        "valueExpression": "$.matchedToken.heartRate",
+                        "valueName": "hr"
+                    }
+                ]
+            }
+        }
+    ]
 }
 ```
+
 > [!IMPORTANT]
 > The MedTech service evaluates `typeMatchExpression` against the incoming device data payload. If the service finds a matching token value, it considers the template a match.
 >
@@ -162,34 +166,34 @@ We're using this device mapping for the normalization stage:
 
 ```json
 {
-  "Body": {
-    "heartRate": "78",
-    "endDate": "2023-03-13T22:46:01.8750000",
-    "deviceId": "device01"
-  },
-  "matchedToken": {
-    "heartRate": "78",
-    "endDate": "2023-03-13T22:46:01.8750000",
-    "deviceId": "device01"
-  }
+    "Body": {
+        "heartRate": "78",
+        "endDate": "2023-03-13T22:46:01.8750000",
+        "deviceId": "device01"
+    },
+    "matchedToken": {
+        "heartRate": "78",
+        "endDate": "2023-03-13T22:46:01.8750000",
+        "deviceId": "device01"
+    }
 }
 ```
 
 The resulting normalized message will look like this after the normalization stage:
 
 ```json
 [
-  {
-    "type": "heartrate",
-    "occurrenceTimeUtc": "2023-03-13T22:46:01.875Z",
-    "deviceId": "device01",
-    "properties": [
-      {
-        "name": "hr",
-        "value": "78"
-      }
-    ]
-  }
+    {
+        "type": "heartrate",
+        "occurrenceTimeUtc": "2023-03-13T22:46:01.875Z",
+        "deviceId": "device01",
+        "properties": [
+            {
+                "name": "hr",
+                "value": "78"
+            }
+        ]
+    }
 ]
 ```
 
@@ -202,9 +206,14 @@ The resulting normalized message will look like this after the normalization sta
 
 In this article, you learned how to use CalculatedContent templates with the MedTech service device mapping.
 
-To learn how to use the MedTech service custom functions, see:
+To learn how to use the MedTech service custom functions, see
 
 > [!div class="nextstepaction"]
 > [How to use custom functions with the MedTech service device mapping](how-to-use-custom-functions.md)
 
+For an overview of the MedTech service FHIR destination mapping, see
+
+> [!div class="nextstepaction"]
+> [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md)
+
 FHIR® is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office, and is used with permission.