More feedback edits

Author: msjasteppe

articles/healthcare-apis/iot/frequently-asked-questions.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.custom: references_regions
 ms.service: healthcare-apis
 ms.topic: reference
-ms.date: 02/27/2023
+ms.date: 02/28/2023
 ms.author: jasteppe
 ---
 
@@ -29,17 +29,17 @@ To learn more about the MedTech service open-source projects, see [Open-source p
 
 ## What versions of FHIR does the MedTech service support?
 
-The MedTech service currently only supports the persistence of [HL7 FHIR® R4](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=491).
+The MedTech service supports the [HL7 FHIR® R4](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=491) standard.
 
 ## Why do I have to provide device and FHIR destination mappings to the MedTech service?
 
-The MedTech service requires device and FHIR destination mappings to perform normalization and transformation processes on the device message data. To learn how the MedTech service transforms device message data into FHIR Observations resources, see [Understand the MedTech service device message data transformation](understand-service.md). 
+The MedTech service requires device and FHIR destination mappings to perform normalization and transformation processes on device message data. To learn how the MedTech service transforms device message data into Observation resources, see [Understand the MedTech service device message data transformation](understand-service.md). 
 
 ## How long does it take for device message data to show up in the FHIR service?
 
-The MedTech service buffers FHIR Observation resources created during the transformation stage and provides near real-time processing. However, this buffer can potentially delay the persistence of FHIR Observations to the FHIR service up to five minutes. To learn how the MedTech service transforms device message data into FHIR Observations resources, see [Understand the MedTech service device message data transformation](understand-service.md).
+The MedTech service buffers Observation resources created during the transformation stage and provides near real-time processing. However, this buffer can potentially delay the persistence of Observation resources to the FHIR service up to five minutes. To learn how the MedTech service transforms device message data into Observations resources, see [Understand the MedTech service device message data transformation](understand-service.md).
 
-## Why are the device messages added to the event hub not showing up as FHIR Observation resources in the FHIR service?
+## Why are the device messages added to the event hub not showing up as Observation resources in the FHIR service?
 
 > [!TIP]
 > Having access to MedTech service logs is essential for troubleshooting and assessing the overall health and performance of your MedTech service.
@@ -60,7 +60,7 @@ The MedTech service buffers FHIR Observation resources created during the transf
 
 ## Does the MedTech service perform backups of device messages?
 
-No. The MedTech service doesn't back up the device messages that is sent to the event hub. The event hub owner controls the device message retention period within their event hub, which can be from one to 90 days. (Event hubs can be deployed in [three different service tiers](/azure/event-hubs/event-hubs-quotas?source=recommendations#basic-vs-standard-vs-premium-vs-dedicated-tiers). Message retention limits are tier-dependent: Basic one day, Standard 1-7 days, Premium 90 days.) If the device message data is successfully processed by the MedTech service, it's persisted in the FHIR service, and the FHIR service backup policy applies. 
+No. The MedTech service doesn't back up the device messages that is sent to the event hub. The event hub owner controls the device message retention period within their event hub, which can be from one to 90 days. Event hubs can be deployed in [three different service tiers](/azure/event-hubs/event-hubs-quotas?source=recommendations#basic-vs-standard-vs-premium-vs-dedicated-tiers). Message retention limits are tier-dependent: Basic one day, Standard 1-7 days, Premium 90 days. If the device message data is successfully processed by the MedTech service, it's persisted in the FHIR service, and the FHIR service backup policy applies. 
 
 To learn more about event hub message retention, see [What is the maximum retention period for events?](/azure/event-hubs/event-hubs-faq#what-is-the-maximum-retention-period-for-events-) 
 

articles/healthcare-apis/iot/troubleshoot-errors-deployment.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: iomt
 ms.topic: troubleshooting
-ms.date: 02/27/2023
+ms.date: 02/28/2023
 ms.author: jasteppe
 ---
 

articles/healthcare-apis/iot/troubleshoot-errors-logs.md

@@ -6,7 +6,7 @@ author: msjasteppe
 ms.service: healthcare-apis
 ms.subservice: iomt
 ms.topic: troubleshooting
-ms.date: 02/27/2023
+ms.date: 02/28/2023
 ms.author: jasteppe
 ---
 
@@ -38,7 +38,7 @@ This property represents the operation being performed by the MedTech service wh
 |OperationName|Description|
 |-------------|-----------|
 |Normalization|The data flow stage where the device message gets normalized.|
-|FHIRConversion|The data flow stage where the grouped-normalized data is transformed into a FHIR Observation resource.|
+|FHIRConversion|The data flow stage where the grouped-normalized data is transformed into an Observation resource.|
 
 > [!NOTE]
 > To learn about the MedTech service device message data transformation, see [Understand the MedTech service device message data transformation](understand-service.md).
@@ -190,7 +190,7 @@ Also, on the Azure portal, go to the **Device mapping** blade of your MedTech se
 
 ### InvalidQuantityFhirValueException
 
-**Description**: The value with a Quantity FHIR data type is invalid (for example, it may be in a format that isn’t supported). The value with the error is specified in the error message.
+**Description**: The value with a Quantity resource data type is invalid (for example, it may be in a format that isn’t supported). The value with the error is specified in the error message.
 
 **Severity**: Non-blocking
 
@@ -220,13 +220,22 @@ The template’s type and line with the error are specified in the error message
 
 **Severity**: Blocking
 
-**Fix**: On the Azure portal, go to the **Identity** blade of your MedTech service, and ensure the following: 
+**Fix**: The fix depends on the type of managed identity that you'd like to use. (The difference between a system-assigned and a user-assigned managed identity can be reviewed at [Managed identity types](/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types). **Note**: The MedTech service only supports one identity, either a system-assigned managed identity or a single user-assigned managed identity identity.
 
-* The system-assigned managed identity’s **Status** is set to **On**.
+If you'd like to use a system-assigned managed identity:
+  1. If you're deploying a MedTech service using an ARM template, ensure that your MedTech service resource in the ARM template has an `identity` property containing the `type` value of `"SystemAssigned"` (see example ARM template in the *azuredeploy.json* file on [GitHub](https://github.com/azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors-with-iothub)).
+  2. On the Azure portal, go to the **Identity** blade of your MedTech service, and ensure the following:
+      * The system-assigned managed identity’s **Status** is set to **On**.
+      * The **Azure role assignments** show that your event hub has an **Azure Event Hubs Data Receiver** role assigned to your MedTech service’s system-assigned managed identity (if not, follow these [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub)).
 
-* The **Azure role assignments** show that your event hub has an **Azure Event Hubs Data Receiver** role assigned to your MedTech service’s system-assigned managed identity (if not, follow these [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub)).
+If you'd like to use a user-assigned managed identity:
+  1. Create a user-assigned managed identity [using the Azure portal](/azure/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp#create-a-user-assigned-managed-identity) or [using an ARM template](/azure/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-arm#create-a-user-assigned-managed-identity-3).
+  2. Assign the user-assigned managed identity to your MedTech service by deploying the MedTech service using an ARM template that's similar to [this example](/azure/active-directory/managed-identities-azure-resources/qs-configure-template-windows-vm#assign-a-user-assigned-managed-identity-to-an-azure-vm). Your MedTech service resource in the ARM template should have an `identity` property containing 1) the `type` value of `"userAssigned"` and 2) a `userAssignedIdentities` value that includes your user-assigned managed identity's name.
+  3. On the Azure portal, go to the **Identity** blade of your MedTech service, and ensure that the system-assigned managed identity’s **Status** is set to **Off**.
+  4.  On the Azure portal, go to your event hub, and assign the **Azure Event Hubs Data Receiver** role to your MedTech service's user-assigned managed identity (see [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub), but use the user-assigned managed identity instead of the system-assigned managed identity).
 
-* If you're deploying a MedTech service using an ARM template, ensure that the MedTech service resource in the ARM template has an identity property containing the type value of "SystemAssigned" (see example ARM template in the *azuredeploy.json* file on [GitHub](https://github.com/azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors-with-iothub)).
+> [!NOTE]
+>
 
 ### MultipleResourceFoundException
 
@@ -246,7 +255,7 @@ The template’s type and line with the error are specified in the error message
 
 ### PatientDeviceMismatchException
 
-**Description**: A FHIR Device resource in the FHIR destination references a Patient FHIR resource with an identifier that doesn’t match the patient identifier given in the device message (meaning, the device is linked to another patient).
+**Description**: A Device resource in the FHIR destination references a Patient FHIR resource with an identifier that doesn’t match the patient identifier given in the device message (meaning, the device is linked to another patient).
 
 **Severity**: Non-blocking