Modifier

Share via


Guide d’architecture des Services de données de santé Azure

Azure Health Data Services
Gestion des API Azure
Azure Application Gateway
Azure Synapse Analytics
Pare-feu Azure

La gestion sécurisée et efficace des données de santé est essentielle pour les organisations de santé. Services de données de santé Azure fournit une plateforme puissante que ces organisations peuvent utiliser pour stocker, traiter et analyser des données sensibles tout en respectant des normes de sécurité et de conformité strictes. Toutefois, le déploiement de Services de données de santé dans un environnement d’entreprise complexe peut être difficile si vous n’avez pas d’une architecture de référence et d’un guide d’implémentation.

Cet article fournit un exemple d’architecture, un exemple d’implémentation associé et un blueprint pour déployer Services de données de santé avec une sécurité renforcée et l’intégrer à d’autres services Azure. Le respect des pratiques décrites dans ce guide peut améliorer votre capacité à protéger vos données de santé.

Architecture

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

Téléchargez un fichier Visio de cette architecture.

Workflow

  1. Azure Application Gateway reçoit des messages FHIR (Fast Healthcare Interoperability Resources) individuels (par exemple, les données des patients) via une connexion TLS à sécurité renforcée qui utilise un flux des informations d’identification du client. Application Gateway envoie les données via Gestion des API Azure au service FHIR des Services de données de santé, où elles sont conservées.
  2. Simultanément, un client peut lire les mêmes données FHIR via une connexion TLS via Application Gateway et Gestion des API à l’aide d’un outil comme Postman.
  3. Pour le traitement des données en bloc, Application Gateway reçoit des bundles FHIR via une connexion TLS qui utilise un flux des informations d’identification du client et charge les données dans un compte de stockage. Une fonction Azure chargeur FHIR intégrée au réseau virtuel traite les bundles FHIR et charge les données dans le service FHIR.
  4. Si les données entrantes sont au format HL7 version 2 ou C-CDA, vous pouvez d’abord les convertir au format FHIR à l’aide du point de terminaison $convert-data dans le service FHIR. Vous pouvez ensuite publier les données sur le service FHIR à l’aide d’Application Gateway. Azure Container Registry, connecté via un point de terminaison privé, est utilisé pour stocker, avec une sécurité renforcée, des modèles Liquid personnalisés pour convertir des données HL7 v2 ou C-CDA en données FHIR. Container Registry est montré dans le diagramme d’architecture, mais la conversion HL7 v2/C-CDA en FHIR via $convert-data n’est pas implémentée par l’exemple de modèle d’implémentation Bicep.
  5. FHIR to Synapse Sync Agent extrait les données du service FHIR (pour les données ingérées via le flux de données individuel ou en bloc), convertit les données extraites en fichiers Parquet hiérarchiques et les écrit dans Azure Data Lake Storage.
  6. Azure Synapse Analytics utilise un pool SQL ou Spark serverless pour se connecter à Data Lake Storage afin d’interroger et d’analyser les données FHIR. Azure Synapse Analytics est présenté dans le diagramme d’architecture, mais il n’est pas implémenté par le modèle d’implémentation Bicep.
  7. Le réseau virtuel hub contient une machine virtuelle jumpbox (VM) et un hôte Azure Bastion pour fournir un accès à sécurité renforcée à la configuration du service FHIR. Les administrateurs et les opérateurs peuvent également utiliser la machine virtuelle jumpbox pour tester les points de terminaison de service FHIR sans passer par Application Gateway et pour charger en bloc des données FHIR manuellement via le stockage Azure, en contournant Application Gateway.
  8. Si vous établissez une connectivité réseau locale via Azure ExpressRoute ou une connexion de site à site, les utilisateurs et services locaux peuvent accéder directement au service FHIR via cette connexion.

Remarque

Vous pouvez éventuellement ajouter Web Application Firewall (WAF) à Application Gateway, mais il existe un problème connu avec WAF qui identifie mal les objets FHIR et les traite comme du code malveillant. Si vous avez besoin de WAF, vous devez modifier manuellement votre ensemble de règles WAF pour permettre à WAF de fonctionner avec des objets FHIR.

Composants

  • Microsoft Entra ID est un service cloud mutualisé de gestion d'annuaire et d'identité. Les applications clientes sont inscrites dans Microsoft Entra ID et peuvent être utilisées pour accéder au service FHIR Services de données de santé Azure.

  • Application Gateway est un équilibreur de charge PaaS (platform as a service) de couche 7 qui peut agir comme un service de proxy inverse. Les utilisateurs internes et externes accèdent aux API FHIR via Application Gateway via Gestion des API.

  • Gestion des API est une plateforme multicloud hybride dédiée à la gestion des API dans tous les environnements. Vous pouvez importer des API FHIR dans Gestion des API à l’aide de la définition d’API Swagger. Vous pouvez utiliser Gestion des API pour limiter les appels entrants, authentifier/autoriser des utilisateurs et effectuer d’autres tâches.

  • Services de données de santé est un ensemble de services d’API managés, basés sur des frameworks et des standards ouverts, qui permettent aux workflows d’améliorer les soins de santé, et offrent des solutions de santé scalables et sécurisées. Le service FHIR Services de données de santé est déployé avec un point de terminaison privé pour garantir qu’il est accessible uniquement à partir de votre réseau virtuel ou par des utilisateurs externes via Internet via Application Gateway.

  • FHIR Loader est une solution Azure Functions qui fournit des services permettant d’importer des bundles FHIR (compressés et non compressés) et des fichiers NDJSON dans un service FHIR.

  • Azure Key Vault est un service Azure qui permet de stocker des secrets, des clés et des certificats et d’y accéder avec une sécurité renforcée. Key Vault offre une sécurité basée sur HSM et un accès audité via des contrôles d'accès basés sur les rôles intégrés à Microsoft Entra ID. Dans cette architecture, Key Vault stocke les informations d’identification de jumpbox, les certificats Application Gateway, les détails du service FHIR et les détails du chargeur FHIR.

  • Container Registry est un service de registre managé qui est basé sur le registre Docker open source 2.0. Dans cette architecture, il est utilisé pour héberger des modèles Liquid. Vous pouvez utiliser le point de terminaison personnalisé $convert-data dans le service FHIR pour convertir les données de santé HL7 v2 et C-CDA en FHIR. L’opération $convert-data utilise des modèles Liquid du convertisseur FHIR pour la conversion de données FHIR.

  • FHIR to Synapse Sync Agent est une application conteneur Azure qui extrait des données d’un serveur FHIR à l’aide des API de ressources FHIR, les convertit en fichiers Parquet hiérarchiques et les écrit dans Data Lake Storage en quasi-temps réel. Elle contient également un script permettant de créer des tables et des vues externes dans le pool serverless SQL Azure Synapse Analytics qui pointent vers les fichiers Parquet. Bien que le diagramme d’architecture montre FHIR to Synapse Sync Agent, Data Lake Storage et Azure Synapse Analytics, l’implémentation Bicep n’inclut pas actuellement le code permettant de déployer ces services.

  • Pare-feu Azure est un service de pare-feu réseau intelligent et nativement cloud, qui assure la protection contre les menaces des charges de travail cloud dans Azure. Dans cette architecture, une table de routage est utilisée pour acheminer le trafic de sortie à partir du réseau virtuel hub via Pare-feu Azure pour vous assurer que l’exfiltration de données ne se produit pas. De même, vous pouvez créer des itinéraires de table de routage et les attacher à des sous-réseaux de réseau virtuel spoke si nécessaire pour empêcher l’exfiltration de données d’informations de santé publique (PHI).

  • La jumpbox est une machine virtuelle Azure exécutant Linux ou Windows à laquelle les administrateurs et les opérateurs peuvent se connecter à l’aide du protocole RDP (Remote Desktop Protocol) ou de Secure Shell (SSH). Étant donné que la plupart des services (Services de données de santé, Gestion des API, Key Vault et autres) dans cette architecture sont déployés avec un point de terminaison privé, vous avez besoin d’une machine virtuelle jumpbox pour apporter des modifications à la configuration ou tester ces services. La jumpbox est accessible uniquement via Azure Bastion.

  • Azure Bastion vous permet de vous connecter à une machine virtuelle à l’aide d’un navigateur, du portail Azure ou via le client SSH/RDP natif sur votre ordinateur. Dans cette implémentation, Azure Bastion fournit un accès à sécurité renforcée à la machine virtuelle jumpbox.

  • Les initiatives de stratégie de conformité Microsoft Defender pour le cloud et HIPAA et HITRUST permettent de garantir que le déploiement de l’infrastructure Azure respecte le point de référence de sécurité Microsoft cloud et les exigences de conformité du secteur de la santé.

Détails du scénario

Cette solution fournit des conseils sur la façon de déployer Services de données de santé avec une sécurité renforcée, d’ingérer des données FHIR individuelles et en bloc et de conserver les données dans le service FHIR Services de données de santé.

Vous pouvez utiliser la solution pour charger des messages FHIR, individuellement et en bloc, dans le service FHIR à l’aide d’une connexion Application Gateway à sécurité renforcée.

Pour analyser des données FHIR et extraire des informations, vous pouvez déployer FHIR to Synapse Sync Agent, comme indiqué dans le diagramme. Azure Synapse Analytics peut se connecter au Data Lake Storage pour interroger et analyser des données FHIR.

Vous pouvez étendre la solution pour recevoir des données à partir d’appareils médicaux et portables à l’aide du service MedTech des Services de données de santé. Vous pouvez utiliser ce service pour transformer des données au format FHIR et les rendre persistantes dans le service FHIR afin de pouvoir extraire des informations à l’aide d’Azure Synapse Analytics.

Vous pouvez également étendre la solution pour ingérer des données non-FHIR (HL7 v2 et C-CDA), les convertir en FHIR à l’aide de modèles Liquid, que vous pouvez stocker dans Container Registry et les conserver dans le service FHIR.

Déployer cette solution

Pour déployer cette solution, suivez les étapes décrites dans le Guide de démarrage.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes