Editar

Compartir a través de


Guía de arquitectura de Azure Health Data Services

Azure Health Data Services
Azure API Management
Azure Application Gateway
Azure Synapse Analytics
Azure Firewall

La administración segura y eficaz de los datos sanitarios es fundamental para las organizaciones sanitarias. Azure Health Data Services proporciona una plataforma poderosa que estas organizaciones pueden usar para almacenar, procesar y analizar datos confidenciales a la vez que cumplen los estrictos estándares de seguridad y cumplimiento. Sin embargo, la implementación de Health Data Services en un entorno empresarial complejo puede ser difícil si no tiene una guía de implementación y arquitectura de referencia.

En este artículo se proporciona una arquitectura de ejemplo, una implementación de ejemplo complementaria y un plano técnico para implementar Health Data Services con seguridad mejorada e integrarla con otros servicios de Azure. Siguiendo los procedimientos descritos en esta guía puede mejorar su capacidad de proteger los datos de salud.

Architecture

Architecture diagram that shows how to deploy Health Data Services on Azure and integrate with other Azure services.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  1. Azure Application Gateway recibe mensajes de recursos de interoperabilidad sanitaria (FHIR) individuales (por ejemplo, datos de pacientes) a través de una conexión TLS de seguridad mejorada que usa un flujo de credenciales de cliente. Application Gateway envía los datos mediante Azure API Management al servicio FHIR de Health Data Services, donde se conservan.
  2. Simultáneamente, un cliente puede leer los mismos datos de FHIR a través de una conexión TLS mediante Application Gateway y API Management por medio de una herramienta como Postman.
  3. Para el procesamiento masivo de datos, Application Gateway recibe agrupaciones de FHIR a través de una conexión TLS que usa un flujo de credenciales de cliente y carga los datos en una cuenta de almacenamiento. Una función Cargador de FHIR de Azure que está integrada con la red virtual procesa los paquetes de FHIR y carga los datos en el servicio de FHIR.
  4. Si los datos entrantes están en formato HL7 versión 2 o C-CDA, primero puede convertirlos al formato FHIR mediante el punto de conexión $convert-data en el servicio FHIR. A continuación, puede publicar los datos en el servicio FHIR mediante Application Gateway. Azure Container Registry, conectado mediante un punto de conexión privado, se usa para almacenar, con seguridad mejorada, plantillas Liquid personalizadas para convertir datos de HL7 v2 o C-CDA en datos de FHIR. Container Registry se muestra en el diagrama de arquitectura, pero la plantilla de implementación de Bicep de ejemplo no implementa la conversión de HL7 v2/C-CDA a FHIR a través de $convert-data.
  5. FHIR al agente de sincronización de Synapse extrae datos del servicio FHIR (para los datos ingeridos a través del flujo de datos individual o masivo), convierte los datos extraídos en archivos jerárquicos de Parquet y los escribe en Azure Data Lake Storage.
  6. Azure Synapse Analytics usa un grupo de SPARK o SQL sin servidor para conectarse a Data Lake Storage para consultar y analizar datos de FHIR. Azure Synapse Analytics se muestra en el diagrama de arquitectura, pero la plantilla de implementación de Bicep no la implementa.
  7. La red virtual del centro de conectividad contiene una máquina virtual (VM) jumpbox y un host de Azure Bastion para proporcionar acceso de seguridad mejorada a la configuración del servicio FHIR. Los administradores y operadores también pueden usar la máquina virtual jumpbox para probar los puntos de conexión de servicio de FHIR sin pasar por Application Gateway y cargar manualmente los datos de FHIR manualmente a través de Azure Storage, pasando Application Gateway.
  8. Si establece conectividad de red local mediante Azure ExpressRoute o VPN de sitio a sitio, los usuarios y servicios locales pueden acceder directamente al servicio FHIR a través de esta conexión.

Nota:

Opcionalmente, puede agregar Web Application Firewall (WAF) a Application Gateway, pero hay un problema conocido con los objetos FHIR que identifican de forma incorrecta WAF y los tratan como código malintencionado. Si necesita WAF, debe modificar manualmente el conjunto de reglas de WAF para permitir que WAF funcione con objetos FHIR.

Componentes

  • Microsoft Entra ID es un servicio multiinquilino, basado en la nube, de administración de directorios e identidades. Las aplicaciones cliente se registran en Microsoft Entra ID y se pueden usar para acceder al servicio FHIR de Azure Health Data Services.

  • Application Gateway es un equilibrador de carga de capa 7 de plataforma como servicio (PaaS) que puede actuar como un servicio de proxy inverso. Los usuarios internos y externos acceden a las API de FHIR a través de Application Gateway mediante API Management.

  • API Management es una plataforma de nube múltiple híbrida para administrar API en todos los entornos. Puede importar las API de FHIR a API Management mediante la definición de la API de Swagger. Puede usar API Management para limitar las llamadas entrantes, autenticar o autorizar a los usuarios y realizar otras tareas.

  • Health Data Services es un conjunto de servicios de API administrados basados en estándares y marcos abiertos que permiten flujos de trabajo que mejoran la atención médica y ofrecen soluciones de atención sanitaria escalables y de seguridad mejorada. El servicio FHIR de Health Data Services se implementa con un punto de conexión privado para ayudar a garantizar que solo se pueda acceder desde la red virtual o desde usuarios externos a través de Internet mediante Application Gateway.

  • FHIR Loader es una solución de Azure Functions que proporciona servicios para importar paquetes FHIR (comprimidos y no comprimidos) y archivos NDJSON en un servicio FHIR.

  • Azure Key Vault es un servicio de Azure para almacenar y acceder a secretos, claves y certificados con una seguridad mejorada. Key Vault proporciona seguridad respaldada por HSM y acceso auditado a través de controles de acceso basados en roles que se integran con Microsoft Entra ID. En esta arquitectura, Key Vault almacena las credenciales de jumpbox, los certificados Application Gateway, los detalles del servicio FHIR y los detalles del cargador de FHIR.

  • Container Registry es un servicio de registro administrado que se basa en Docker Registry 2.0 de código abierto. En esta arquitectura, se usa para hospedar plantillas Liquid. Puede usar el punto de conexión personalizado $convert-data en el servicio FHIR para convertir datos de salud de HL7 v2 y C-CDA a FHIR. La operación $convert-data usa plantillas Liquid del Convertidor de FHIR para la conversión de datos de FHIR.

  • FHIR a agente de sincronización de Synapse es una aplicación de contenedor de Azure que extrae datos de un servidor FHIR mediante las API de recursos de FHIR, los convierte en archivos Parquet jerárquicos y los escribe en Data Lake Storage casi en tiempo real. También contiene un script para crear tablas y vistas externas en Azure Synapse grupo de SQL sin servidor de Analytics que apuntan a los archivos Parquet. Aunque el diagrama de arquitectura muestra FHIR al agente de sincronización de Synapse, Data Lake Storage y Azure Synapse Analytics, la implementación de Bicep no incluye actualmente el código para implementar estos servicios.

  • Azure Firewall es un servicio de firewall de red inteligente nativo de la nube que brinda protección contra amenazas para las cargas de trabajo en la nube en Azure. En esta arquitectura, se usa una tabla de rutas para enrutar el tráfico de salida desde la red virtual del concentrador a través de Azure Firewall para ayudar a garantizar que no se produzca la filtración de datos. Del mismo modo, puede crear rutas de tabla de rutas y adjuntarlas a subredes de red virtual de radio según sea necesario para ayudar a evitar la filtración de datos de información de salud pública (PHI).

  • Jumpbox es una máquina virtual de Azure que ejecuta Linux o Windows a la que los administradores y operadores pueden conectarse mediante el Protocolo de escritorio remoto (RDP) o Secure Shell (SSH). Dado que la mayoría de los servicios (Health Data Services, API Management, Key Vault y otros) en esta arquitectura se implementan con un punto de conexión privado, necesita una máquina virtual jumpbox para realizar cambios de configuración o probar estos servicios. Solo se puede acceder a jumpbox mediante Azure Bastion.

  • Azure Bastion le permite conectarse a una máquina virtual mediante un navegador, Azure Portal o mediante el cliente SSH/RDP nativo en el equipo. En esta implementación, Azure Bastion proporciona acceso de seguridad mejorada a la máquina virtual jumpbox.

  • Las iniciativas de directivas de cumplimiento de Defender for Cloud y HIPAA y HITRUST ayudan a garantizar que la implementación de la infraestructura de Azure cumpla con la directiva de cumplimiento de referencia de seguridad en la nube de Microsoft y los requisitos de cumplimiento del sector del cuidado sanitario.

Detalles del escenario

Esta solución proporciona instrucciones sobre cómo implementar Health Data Services con seguridad mejorada, ingerir datos individuales y masivos de FHIR y conservar los datos en el servicio FHIR de Health Data Services.

Puede usar la solución para cargar mensajes de FHIR de forma individual y masiva en el servicio FHIR mediante una conexión de Application Gateway de seguridad mejorada.

Para analizar los datos de FHIR y extraer información, puede implementar FHIR en el agente de sincronización de Synapse, como se muestra en el diagrama. Azure Synapse Analytics puede conectarse a Data Lake Storage para consultar y analizar datos de FHIR.

Puede ampliar la solución para recibir datos de dispositivos médicos y portátiles mediante el servicio de tecnologías médicas de Health Data Services. Puede usar este servicio para transformar datos en formato FHIR y conservarlos en el servicio FHIR para que pueda extraer información mediante Azure Synapse Analytics.

También puede ampliar la solución para ingerir datos que no son de FHIR (HL7 v2 y C-CDA), convertirlo en FHIR mediante plantillas Liquid, que puede almacenar en Container Registry y conservarla en el servicio FHIR.

Implementación de la solución

Para implementar esta solución, siga los pasos en Introducción.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes