Merge pull request #208260 from v-pbartley/AHDS_docs_update

prmerger-automator[bot] · web-flow · commit 3e99076e6be1 · 2022-08-17T15:01:47.000Z
Ahds docs update
diff --git a/articles/healthcare-apis/fhir/configure-export-data.md b/articles/healthcare-apis/fhir/configure-export-data.md
@@ -30,7 +30,7 @@ In this step, browse to your FHIR service in the Azure portal and select the **I
 
 ## Give permission in the storage account for FHIR service access
 
-1. Go to your ADLS Gen2 storage account in the Azure portal.
+1. Go to your ADLS Gen2 account in the Azure portal.
 
 2. Select **Access control (IAM)**.
 
@@ -52,7 +52,7 @@ In this step, browse to your FHIR service in the Azure portal and select the **I
 
 For more information about assigning roles in the Azure portal, see [Azure built-in roles](../../role-based-access-control/role-assignments-portal.md).
 
-Now you're ready to configure the FHIR service with the ADLS Gen2 account as the default storage account for export.
+Now you're ready to configure the FHIR service by setting the ADLS Gen2 account as the default storage account for export.
 
 ## Specify the storage account for FHIR service export
 
@@ -121,7 +121,7 @@ After running this command, in the **Firewall** section under **Resource instanc
 
   :::image type="content" source="media/export-data/storage-networking-2.png" alt-text="Screenshot of Azure Storage Networking Settings with resource type and instance names." lightbox="media/export-data/storage-networking-2.png":::
 
-You're now ready to securely export FHIR data to the storage account. Note that the storage account is on selected networks and isn't publicly accessible. To securely access the files, you can enable private endpoints for the storage account.
+You're now ready to securely export FHIR data to the storage account. Note that the storage account is on selected networks and isn't publicly accessible. To securely access the files, you can enable [private endpoints](../../storage/common/storage-private-endpoints.md) for the storage account.
 
 ### Allowing specific IP addresses from other Azure regions to access the Azure storage account
 
diff --git a/articles/healthcare-apis/fhir/de-identified-export.md b/articles/healthcare-apis/fhir/de-identified-export.md
@@ -66,8 +66,8 @@ You will need to create a container for the de-identified export in your ADLS Ge
 
 |Query parameter            | Example |Optionality| Description|
 |---------------------------|---------|-----------|------------|
-| `anonymizationConfig`   |`anonymizationConfig.json`|Required for de-identified export |Name of the configuration file. See the configuration file format [here](https://github.com/microsoft/FHIR-Tools-for-Anonymization#configuration-file-format). This file should be kept inside a container named `anonymization` within the ADLS Gen2 account that is configured as the export location. |
-| `anonymizationConfigEtag`|"0x8D8494A069489EC"|Optional for de-identified export|This is the Etag of the configuration file. You can get the Etag using Azure Storage Explorer from the blob property.|
+| `anonymizationConfig`   |`anonymizationConfig.json`|Required for de-identified export |Name of the configuration file. See the configuration file format [here](https://github.com/microsoft/FHIR-Tools-for-Anonymization#configuration-file-format). This file should be kept inside a container named `anonymization` within the configured ADLS Gen2 account. |
+| `anonymizationConfigEtag`|"0x8D8494A069489EC"|Optional for de-identified export|This is the Etag of the configuration file. You can get the Etag from the blob property using Azure Storage Explorer.|
 
 > [!IMPORTANT]
 > Both the raw export and de-identified export operations write to the same Azure storage account specified in the export configuration for the FHIR service. If you have need for multiple de-identification configurations, it is recommended that you create a different container for each configuration and manage user access at the container level.
diff --git a/articles/healthcare-apis/fhir/export-data.md b/articles/healthcare-apis/fhir/export-data.md
@@ -16,7 +16,7 @@ Before attempting to use `$export`, make sure that your FHIR service is configur
 
 ## Calling the `$export` endpoint
 
-After setting up the FHIR service to connect with an ADLS Gen2 account, you can call the `$export` endpoint and the FHIR service will export data into a blob storage container inside the storage account. The example request below exports all resources into a container specified by name (`{{containerName}}`) within the ADLS Gen2 account. Note that the container in the ADLS Gen2 account must be created beforehand if you want to specify the `{{containerName}}` in the request.
+After setting up the FHIR service to connect with an ADLS Gen2 account, you can call the `$export` endpoint and the FHIR service will export data into a blob storage container inside the storage account. The example request below exports all resources into a container specified by name (`{{containerName}}`). Note that the container in the ADLS Gen2 account must be created beforehand if you want to specify the `{{containerName}}` in the request.
 
 ```
 GET {{fhirurl}}/$export?_container={{containerName}}
@@ -29,7 +29,7 @@ For general information about the FHIR `$export` API spec, please see the [HL7 F
 
 **Jobs stuck in a bad state**
 
-In some situations, there's a potential for a job to be stuck in a bad state while attempting to `$export` data from the FHIR service. This can occur especially if the ADLS Gen2 account permissions haven't been set up correctly. One way to check the status of your `$export` operation is to go to your storage account's **Storage browser** and see if any `.ndjson` files are present in the export container. If the files aren't present and there are no other `$export` jobs running, then there's a possibility the current job is stuck in a bad state. In this case, you can cancel the `$export` job by calling the FHIR service API with a `DELETE` request. Later you can requeue the `$export` job and try again. Information about canceling an `$export` operation can be found in the [Bulk Data Delete Request](https://hl7.org/fhir/uv/bulkdata/export/index.html#bulk-data-delete-request) documentation from HL7. 
+In some situations, there's a potential for a job to be stuck in a bad state while the FHIR service is attempting to export data. This can occur especially if the ADLS Gen2 account permissions haven't been set up correctly. One way to check the status of your `$export` operation is to go to your storage account's **Storage browser** and see if any `.ndjson` files are present in the export container. If the files aren't present and there are no other `$export` jobs running, then there's a possibility the current job is stuck in a bad state. In this case, you can cancel the `$export` job by calling the FHIR service API with a `DELETE` request. Later you can requeue the `$export` job and try again. Information about canceling an `$export` operation can be found in the [Bulk Data Delete Request](https://hl7.org/fhir/uv/bulkdata/export/index.html#bulk-data-delete-request) documentation from HL7. 
 
 > [!NOTE] 
 > In the FHIR service, the default time for an `$export` operation to idle in a bad state is 10 minutes before the service will stop the operation and move to a new job. 
