fixed links

Author: shellyhaverkamp

articles/healthcare-apis/.openpublishing.redirection.healthcare-apis.json

@@ -91,7 +91,7 @@
           "redirect_document_id": true
       },
       {
-          "source_path_from_root": "/articles/healthcare-apis/configure-private-link.md",
+          "source_path_from_root": "/articles/healthcare-apis/healthcare-apis-configure-private-link.md",
           "redirect_url": "/azure/healthcare-apis/fhir/configure-private-link",
           "redirect_document_id": true
       },

articles/healthcare-apis/network-access-security.md

@@ -16,38 +16,38 @@ Azure Health Data Services provides multiple options for securing network access
 
 ## Private Link
 
-[Private Link](https://learn.microsoft.com/azure/private-link/) is a network isolation technique that allows access to Azure services, including Azure Health Data Services. Private Link allows data to flow over private Microsoft networks instead of the public internet. By using Private Link, you can allow access only to specified virtual networks, and lock down access to provisioned services. For more information, see [Configuring Private Link](https://learn.microsoft.com/azure/healthcare-apis/healthcare-apis-configure-private-link).
+[Private Link](../private-link/index.yml) is a network isolation technique that allows access to Azure services, including Azure Health Data Services. Private Link allows data to flow over private Microsoft networks instead of the public internet. By using Private Link, you can allow access only to specified virtual networks, and lock down access to provisioned services. For more information, see [Configure Private Link](healthcare-apis-configure-private-link.md).
 
 ## Microsoft Trusted Services
 
-Although most interactions with Azure Health Data Services are inbound requests, there are a few features of the services that need to make outbound connections to other resources. To control access from outbound connections, we recommend that you leverage the [Microsoft Trusted Service](../storage/common/storage-network-security.md) connections in the network settings of the target resource. Each outbound feature can have slightly different setup steps and intended target resources.
+Although most interactions with Azure Health Data Services are inbound requests, there are a few features of the services that need to make outbound connections to other resources. To control access from outbound connections, we recommend that you use the [Microsoft Trusted Service](../storage/common/storage-network-security.md) connections in the network settings of the target resource. Each outbound feature can have slightly different setup steps and intended target resources.
 
 Here's a list of features that can make outbound connections from Azure Health Data Services:
 
 ### FHIR service
 
-- **Export**: [Allowing FHIR service export as a Microsoft Trusted Service](fhir/configure-export-data.md)
-- **Import**: [Allowing FHIR service import as a Microsoft Trusted Service](fhir/configure-import-data.md)
-- **Convert**: [Allowing trusted services access to Azure Container Registry](../container-registry/allow-access-trusted-services.md)
-- **Events**: [Trusted Services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
-- **Customer-managed keys**: [Allowing trusted services access to Azure Key Vault](../key-vault/general/overview-vnet-service-endpoints.md)
+- **Export**: [Allow FHIR service export as a Microsoft Trusted Service](fhir/configure-export-data.md)
+- **Import**: [Allow FHIR service import as a Microsoft Trusted Service](fhir/configure-import-data.md)
+- **Convert**: [Allow trusted services access to Azure Container Registry](../container-registry/allow-access-trusted-services.md)
+- **Events**: [Allow trusted services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
+- **Customer-managed keys**: [Allow trusted services access to Azure Key Vault](../key-vault/general/overview-vnet-service-endpoints.md)
 
 ### DICOM service
 
-- **Import, export, and analytical support**: [Trusted Services access to Azure Storage Accounts](../storage/common/storage-network-security.md)
-- **Events**: [Microsoft Trusted Services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
-- **Customer-managed keys**: [Allowing Microsoft Trusted Services access to Azure Key Vault](../key-vault/general/overview-vnet-service-endpoints.md)
+- **Import, export, and analytical support**: [Allow trusted services access to Azure Storage accounts](../storage/common/storage-network-security.md)
+- **Events**: [Allow trusted services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
+- **Customer-managed keys**: [Allow trusted services access to Azure Key Vault](../key-vault/general/overview-vnet-service-endpoints.md)
 
 ### MedTech service
 
-- **Events**: [Microsoft Trusted Services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
+- **Events**: [Allow trusted services access to Azure Event Hubs](../event-hubs/event-hubs-service-endpoints.md)
 
 ## Service tags
 
 [Service tags](../virtual-network/service-tags-overview.md) are sets of IP addresses that correspond to an Azure Service, for example Azure Health Data Services. You can use tags to control access on several Azure networking offerings such as Network Security Groups, Azure Firewall, and more.
 
-Azure Health Data Services offers a [service tag](../virtual-network/service-tags-overview.md) `AzureHealthcareAPIs` that you can use to control access to and from the services. However, there are a number of caveats that come with using Service Tags for network isolation, and we don't recommend relying on them. Instead, use the approaches described in this article for more granular controls. Service tags are shared across all users of a service, and all provisioned instances. Tags provide no isolation between customers within Azure Health Data Services, between separate instances of the workspaces, nor between the different service offerings.
+Azure Health Data Services offers a [service tag](../virtual-network/service-tags-overview.md) `AzureHealthcareAPIs` that you can use to control access to and from the services. However, there are a few caveats that come with using Service Tags for network isolation, and we don't recommend relying on them. Instead, use the approaches described in this article for more granular controls. Service tags are shared across all users of a service, and all provisioned instances. Tags provide no isolation between customers within Azure Health Data Services, between separate instances of the workspaces, nor between the different service offerings.
 
-If you use service tags, keep in mind that they are a convenient way of keeping track of sets of IP addresses, and aren't a substitute for proper network security measures.
+If you use service tags, keep in mind that they're a convenient way of keeping track of sets of IP addresses. However, tags aren't a substitute for proper network security measures.
 
 [!INCLUDE [FHIR and DICOM trademark statement](includes/healthcare-apis-fhir-dicom-trademark.md)]

articles/healthcare-apis/toc.yml

@@ -21,7 +21,7 @@
     - name: Business continuity & disaster recovery
       href: business-continuity-disaster-recovery.md
     - name: Manage network access security
-      href: network-security.md
+      href: network-access-security.md
 - name: Quickstarts
   items: 
     - name: Workspace provisioning