This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
Challenge:
In today's healthcare landscape, secure and efficient management of health data is paramount. Azure Health Data Services (AHDS) provides a powerful platform for healthcare organizations to store, process, and analyze their sensitive data while adhering to stringent security and compliance standards. However, deploying AHDS in a complex enterprise environment can be challenging without a clear reference architecture and implementation guide.
Solution:
In this blog, we present AHDS Reference Architecture and a comprehensive Reference Implementation. This resource aims to empower healthcare customers by providing them with a clear blueprint for deploying AHDS securely and integrating it with various Azure services. By following the recommended best practices outlined in this guide, organizations can gain confidence in their ability to safeguard their health data effectively.
Deployment and Testing:
To deploy follow the steps under Getting Started section and to test use Testing section in GitHub. AHDS Reference Architecture
Potential use cases:
- Once the reference architecture deployed successfully, FHIR messages (individual/bulk) can be loaded in to FHIR service securely via Application Gateway.
- FHIR data can be retrieved securely via Application Gateway & API Management. APIM provides more capabilities to authenticate/authorize incoming calls and throttle requests as needed.
- To analyze FHIR data and extract insights, FHIR Sync Agent can be deployed as shown in the architecture diagram (not deployed part of Bicep script). It reads data from FHIR service, converts to parquet files and writes it to Azure Data Lake Gen2 (ADLS Gen2). Azure Synapse can connect to ADLS Gen2 to query and analyze FHIR data.
- This solution can be extended to receive medical devices/wearable data using MedTech service part of Azure Health Data Services and eventually persist in to FHIR service for extracting further insights using Synapse.
- This solution can be extended to ingest non FHIR data (HL7 V2 & C-CDA), convert to FHIR standard using Liquid templates (can be stored in Azure Container Registry) and persist in FHIR service.
Reference Architecture:
Details of the Reference Architecture:
- Azure Application Gateway securely receives individual (single) Fast Healthcare Interoperability Resources (FHIR®) data (example patient data) over a TLS connection using client credentials flow and sends it to FHIR Service to persist via API Management.
- Simultaneously a client can securely read same FHIR data (example: patient data) over TLS connection using client credentials flow via Application Gateway using tools like Postman.
- For bulk data processing, Azure Application Gateway securely receives FHIR bundles over a TLS connection using client credentials flow and loads into storage account. VNet integrated FHIR Loader Function process FHIR bundles and loads it in to FHIR service.
- Optionally Web Application Firewall (WAF) can be added to Application Gateway, but there are known limitations with WAF not recognizing FHIR objects and treating it as malicious code. If WAF is needed, then WAF ruleset needs to be manually tweaked to work with FHIR objects.
- If the incoming data is in HL7v2 or in C-CDA format (not in FHIR format) then it can be converted to FHIR format first using $convert-data endpoint in the FHIR service, then it can be posted to FHIR service via Application Gateway.
- API Management can used to authenticate/authorize incoming requests as well as throttle (rate-limit) calls, etc. as needed.
- FHIR service under Azure Health Data Services with private endpoint is deployed to ensure no publicly accessible endpoint and to securely persist FHIR data.
- Azure Container Registry (ACR) with private endpoint is used for securely storing customized liquid templates for converting HL7v2/C-CDA data to FHIR data. While ACR is shown in the architecture diagram, HL7v2/C-CDA to FHIR conversion using $convert-data is not implemented part of bicep reference implementation.
- FHIR to Synapse Sync Agent extracts data from FHIR service, converts to hierarchical parquet files, and writes it to Azure Data Lake Gen2 (ADLS Gen2). While this is shown in the architecture diagram, it's not implemented part of bicep reference implementation.
- Azure Synapse uses serverless SQL/Spark pool to connect to ADLS Gen2 to query and analyze FHIR data. While this is shown in the architecture diagram, it's not implemented part of bicep reference implementation.
- Hub VNet contains Azure Firewall, this ensures egress traffic from Hub VNet (Jumpbox VM subnet) are forced to go to Azure Firewall using route table to ensure data exfiltration doesn't happen. Similarly, route table routes can be created and attached to necessary Spoke VNet subnets as well to prevent any PHI data exfiltration.
- Hub VNet contains Jumpbox VM along with Azure Bastion Host to securely access FHIR service configuration, testing FHIR service endpoints without Application Gateway or API Management, bulk loading FHIR data manually through Azure storage, etc.
- If on-premises network connectivity established over Site-to-Site VPN or Express Route then on-premises users/services can directly access FHIR service over this connection if needed, instead of connecting through Application Gateway.
- Microsoft Defender for Cloud along HIPAA & HITRUST compliance initiatives ensures Azure infrastructure deployment adhere to Microsoft Security Benchmark and Healthcare industry compliance requirements.
Credit:
- Credit goes to Victor Santana, Sonalika Roy & Srini Padala who helped immensely in putting together this Reference Architecture & Reference Implementation.
- This was started as Microsoft Global hackathon project and following team members helped in building the idea: Ankesh Anupam, Nabeel Muhammad, Elaine van Bergen, Seena Nakeri, Abhishek Shaw, Anil K B, Juan Trujillo & Camille Jetzer.
- Finally, thanks to Chami Rupasinghe, Steve Ordahl & Mikael Weaver from AHDS Product Group for reviewing and providing guidance as needed.