Modifier

Supervision des patients à distance

Azure Data Lake Storage
Azure Databricks
Hubs d'événements Azure
Azure Machine Learning
Azure Synapse Analytics
Power BI

Les systèmes de santé, les hôpitaux et les vastes pratiques médicales se tournent vers les initiatives d’hôpital à domicile (également appelées monitoring à distance des patients). Le monitoring à distance des patients est un sous-ensemble de soins cliniques où les données physiologiques et d’activité des patients sont accessibles et délivrées en utilisant des appareils de santé distants paramétrés selon le programme de soins individualisé.

Cet article fournit des conseils sur la conception d’une solution en utilisant les Services de données de santé Azure et des appareils pour un monitoring intelligent des patients à distance. La solution vous aide à atténuer de nombreux défis liés à l’intégration des appareils auxquels votre organisation doit faire face lors de la mise en place de ce type de solution à grande échelle.

Architecture

Architecture diagram of remote patient monitoring architecture using healthcare devices and Azure services.

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

Dataflow

  1. Les appareils des patients génèrent des données physiologiques et d’activité. Les données sont ensuite extraites des appareils en utilisant un des SDK open source (OSS) Microsoft disponibles, et ingérées par Azure Event Hubs.

  2. La plateforme Life365.health prend en charge plus de 300 appareils qui génèrent des données physiologiques et d’activité L’API Life365 ingère les données physiologiques et d’activité des appareils de monitoring des patients dans Azure Event Hubs.

  3. Le service Azure MedTech tire les mesures des appareils à partir d’Event Hubs, les transformant au format FHIR (Fast Healthcare Interoperability Resources (FHIR®)) pour les passer au service Azure FHIR. L’espace de travail Services de données de santé Azure est un conteneur logique des instances de service de soins de santé, comme les services FHIR et MedTech.

  4. L’espace de travail Services de données de santé Azure envoie des messages de notification aux abonnés aux événements quand une ressource FHIR est créée, mise à jour ou supprimée dans le service Azure FHIR. Les notifications peuvent être envoyées à plusieurs points de terminaison pour déclencher l’automatisation, notamment le démarrage de workflows, ou l’envoi d’e-mails et de SMS.

  5. Les pipelines FHIR Analytics exportent de façon incrémentielle les données FHIR non anonymisées vers Azure Data Lake, ce qui permet de les analyser avec divers services de données Azure. Les données exportées peuvent également être rendues anonymes avec des outils comme Tools for Health Data Anonymization, un projet open source de Microsoft. L’anonymisation par défaut est basée sur la méthode HIPAA Safe Harbor, qui peut être étendue et modifiée en fonction des besoins.

    Important

    Les données FHIR exportées dans ce flux de données sont brutes et contiennent des informations PHI. Le processus de désidentification peut être utilisé pour supprimer les identificateurs personnels des données à des fins de recherche ou de partage. Si vous voulez désidentifier des jeux de données, vous devez prendre des mesures pour anonymiser les données avant de les exporter, en utilisant un outil comme celui mentionné ci-dessus.

  6. Une analyse approfondie des données FHIR dans les formats Parquet et JSON est faite en utilisant des pools Spark dans les services Azure Synapse, Azure Databricks et Azure Machine Learning (ML).

  7. Des vues SQL sont créées dans les pools SQL serverless dans Azure Synapse. Une vue SQL est créée pour chaque ressource FHIR à partir des fichiers Parquet dans Azure Data Lake. À partir de ces vues, les ingénieurs Données et les développeurs peuvent écrire du code SQL natif dans Microsoft SQL Management Studio, ou un autre éditeur SQL, pour interroger les ressources FHIR.

  8. Power BI et le connecteur Power Query pour FHIR sont utilisés afin d’importer et de mettre en forme des données directement à partir du point de terminaison de l’API de service FHIR. Power BI offre également des connecteurs Parquet et SQL pour accéder à la ressource FHIR directement au format Parquet ou à travers les vues SQL dans Synapse.

Composants

Appareils

Appareils consommateur

Microsoft fournit des SDK open source pour faciliter le transfert de données à partir de divers appareils consommateur pour faciliter l’ingestion dans Azure Event Hubs :

Appareils médicaux pris en charge par Life365.health

La plateforme Life365.health est intégrée à plus de 300 appareils de monitoring Bluetooth pour l’ingestion des données par Azure Event Hubs. Les appareils s’étendent sur plusieurs catégories et OEM, notamment spiromètres, thermomètres, balances, rappels pour la prise de médicaments, dispositifs de suivi d’activité, lecteurs de glycémie, moniteurs de pression artérielle, ECG, dopplers fœtaux, moniteurs de fréquence cardiaque, oxymètres de pouls, dispositifs de suivi du sommeil, etc. L’application Life365 permet également l’enregistrement manuel des lectures provenant d’appareils non Bluetooth. Cette architecture utilise l’API Life365 pour ingérer les mesures des appareils Life365 dans Event Hubs.

Autres

Bien que les options ci-dessus facilitent la tâche, cette architecture prend en charge toutes les sources de données similaires qui peuvent être ingérées de manière sécurisée dans Event Hubs, directement ou indirectement à travers une API intermédiaire.

Services Azure (collecte et stockage de données)

  • Azure Event Hubs est un service complètement managé d’ingestion des données en temps réel à la fois simple, fiable et scalable. Diffusez en continu des millions d’événements par seconde à partir de n’importe quelle source pour créer des pipelines de données dynamiques et répondre immédiatement aux défis commerciaux. Dans cette architecture, il est utilisé pour collecter et agréger les données d’appareil et les transférer vers les Services de données de santé Azure.

  • Services de données de santé Azure 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. Les services utilisés dans cet exemple d’architecture sont notamment :

    • Espace de travail Services de données de santé Azure : fournit un conteneur pour les autres instances Services de données de santé Azure et crée une limite de conformité (HIPAA, HITRUST) dans laquelle les informations de santé protégées peuvent circuler.

    • Service Azure FHIR : permet de stocker et d’échanger facilement et de manière sécurisée des informations de santé protégées (PHI) dans le cloud. Les données d’appareil sont transformées en ressources d’observation basées sur FHIR pour prendre en charge le monitoring à distance des patients.

    • Service Azure MedTech : pierre angulaire de Microsoft Cloud for Healthcare, utilisé pour prendre en charge le monitoring à distance des patients. MedTech est une Plateforme en tant que service (PaaS) qui vous permet de collecter des données en quasi-temps réel à partir de divers appareils médicaux, puis de les convertir en un format de service compatible FHIR et de les stocker dans un service FHIR. Les fonctionnalités de traduction des données d’appareil du service MedTech permettent de transformer un large éventail de données au format FHIR unifié qui assure la gestion sécurisée des données de santé dans un environnement cloud.

      Le service MedTech est important pour le monitoring à distance des patients, car les données de santé peuvent être difficilement accessibles ou analysables quand elles proviennent d’appareils, de systèmes ou de formats diversifiés ou incompatibles. Les informations médicales qui ne sont pas faciles d’accès peuvent empêcher de collecter des insights cliniques et bloquer le programme de soins de santé d’un patient. La possibilité de traduire les données de santé dans un format FHIR unifié permet au service MedTech de faire le lien correctement entre les appareils, les données de santé, les laboratoires et les soins à distance de la personne. Par conséquent, cette fonctionnalité peut faciliter la découverte d’insights cliniques importants et la capture des tendances, en apportant un support au clinicien, à l’équipe de soins, au patient à et la famille. Il peut également aider à établir des connexions à de nouvelles applications d’appareil et à lancer des projets de recherche avancés. Tout comme les programmes de soins peuvent être individualisés selon le cas d’usage, les scénarios de monitoring des patients à distance et les cas d’usage peuvent varier selon les besoins individualisés.

  • Azure Event Grid : service d’événements Services de données de santé Azure qui génère des événements chaque fois qu’une ressource FHIR est créée, mise à jour ou supprimée. Ces événements peuvent être diffusés par Azure Event Grid aux consommateurs en aval pour qu’ils puissent agir sur les données basées sur les événements.

Services et outils Azure (analytique données)

  • Pipelines FHIR Analytics : projet OSS utilisé afin de générer des composants et des pipelines pour rectangulariser et déplacer les données FHIR, à partir des serveurs Azure FHIR vers Azure Data Lake. Dans cette architecture, les données sont converties au format JSON (JavaScript Object Notation) et Parquet pour pouvoir les analyser avec divers services de données Azure.

  • Tools for Health Data Anonymization : projet OSS soutenu par l’équipe Microsoft Healthcare qui permet d’anonymiser les données de santé, localement ou dans le cloud, pour une utilisation secondaire, comme la recherche, la santé publique, etc. Le moteur principal d’anonymisation utilise un fichier de configuration pour spécifier différents paramètres, ainsi que des méthodes d’anonymisation pour différents éléments de données et types de données.

  • Azure Synapse Analytics : service analytique illimité qui réunit l’intégration de données, l’entreposage de données d’entreprise et l’analytique Big Data. Il vous permet d’interroger les données avec vos propres mots, en utilisant des options serverless ou dédiées, à grande échelle. Azure Synapse réunit ces domaines avec une expérience unifiée qui permet d’ingérer, d’explorer, de préparer, de transformer, de gérer et de servir des données pour répondre aux besoins immédiats du décisionnel et du machine learning.

  • Pools Apache Spark : Apache Spark est un framework de traitement parallèle qui prend en charge le traitement en mémoire pour améliorer les performances des applications d’analytique Big Data. Apache Spark dans Azure Synapse Analytics est l’une des implémentations par Microsoft d’Apache Spark dans le cloud. Azure Synapse facilite la création et la configuration d’un pool Apache Spark serverless dans Azure. Les pools Spark dans Azure Synapse sont compatibles avec Stockage Azure et le stockage Azure Data Lake Generation 2. Vous pouvez donc utiliser des pools Spark pour traiter vos données stockées dans Azure.

  • Azure Databricks : plateforme d’analytique données optimisée pour la plateforme de services cloud Microsoft Azure. Databricks fournit une plateforme analytique unifiée pour les analystes de données, les ingénieurs Données, les scientifiques des données et les ingénieurs du machine learning. Trois environnements sont offerts pour développer des applications consommant beaucoup de données : Databricks SQL, Databricks Data Science & Engineering et Databricks Machine Learning.

  • Azure ML : service cloud Azure permettant d’accélérer et de gérer le cycle de vie des projets de machine learning. Les professionnels du Machine Learning, les scientifiques des données et les ingénieurs peuvent l’utiliser dans leurs flux de travail quotidiens : apprentissage et déploiement des modèles, et gestion du MLOps. Vous pouvez créer un modèle dans Azure Machine Learning ou utiliser un modèle conçu à partir d’une plateforme open source comme PyTorch, TensorFlow ou scikit-learn. Les outils MLOps vous permettent d’effectuer un monitoring des modèles, de les recycler et de les redéployer.

  • Power BI : fournit des analyses en libre-service à l’échelle de l’entreprise, ce qui vous permet de :

    • Créer une culture pilotée par les données avec le décisionnel pour tous.
    • Sécuriser vos données avec des fonctionnalités de pointe pour la sécurité des données, notamment l’étiquetage de confidentialité, le chiffrement de bout en bout et le monitoring de l’accès en temps réel. Power BI est utilisé pour l’analyse des données FHIR.

  • Les connecteurs Power Query utilisés avec Power BI sont notamment :

  • SQL Server Management Studio : application de bureau utilisée pour créer des requêtes SQL natives sur des magasins de données SQL, comme les pools SQL Azure Synapse Analytics.

Autres solutions

Life365.health

L’avantage de Life365.health est qu’avec un seul point d’intégration, vous pouvez pousser les mesures d’un large éventail d’appareils de l’écosystème Life365 dans les Services de données de santé Azure. D’autres API d’appareil wearable existent, comme l’API Garmin Activity et l’API Polar AccessLink, pour lesquelles un modèle d’intégration similaire peut être obtenu. Toutefois, ces API sont réservées exclusivement aux mesures des appareils de leurs propres fabricants, comme Garmin et Polar respectivement.

Les appareils et les patients doivent être définis, liés et synchronisés entre les Services de données de santé Azure et l’API Life365. Cette configuration peut être obtenue en synchronisant les ID de patient et d’appareil entre les Services de données de santé Azure et l’API Life365. En substance, un patient et un appareil sont d’abord créés et liés dans le service Azure FHIR. Ensuite, le patient et l’appareil correspondants sont créés et liés dans l’API Life365. Les ID des patients et des appareils, créés en premier dans les Services de données de santé Azure, sont ensuite mis à jour comme ID externes dans les entités patient et appareil respectives de l’API Life365.

Microsoft Cloud for HealthCare

Cet exemple de charge de travail illustre une façon d’implémenter une solution de monitoring des patients à distance. Microsoft Cloud for Healthcare fournit également une solution de monitoring des patients à distance. Pour plus d’informations sur cette solution, consultez la visite guidée du monitoring des patients à distance.

Détails du scénario

Il existe aujourd’hui une abondance d’appareils médicaux wearables/consommateur. Pour accéder aux mesures/lectures des appareils, de nombreux appareils de monitoring à domicile (comme les appareils de mesure de la pression artérielle, les balances... etc.) fournissent une connectivité Bluetooth (par exemple, Bluetooth basse consommation, ou d’autres versions antérieures de la norme Bluetooth). Il existe également des appareils wearables consommateur, ainsi que des appareils plus avancés à domicile, qui fournissent une connectivité d’API pour accéder aux mesures d’appareil. Dans ce cas, les appareils peuvent synchroniser les lectures directement sur l’API (Wifi activé) ou se connecter à une application mobile sur un téléphone intelligent (via Bluetooth), ce qui permet à l’application de synchroniser la lecture sur l’API.

Définition du problème

Compte tenu de la large gamme d’appareils médicaux wearables et à domicile, et des options de connectivité (du Bluetooth à la spécification d’API), multiplié par le nombre de patients au sein de l’organisation de santé, l’intégration et l’orchestration des données peuvent devenir une tâche intimidante.

Cas d’usage potentiels

  • Essais et recherche cliniques – Aidez les équipes de recherche clinique à intégrer et offrir un large éventail d’appareils médicaux à domicile et wearables pour le participant à l’étude. En d’autres termes, proposez une option quasi-BYOD (Apportez votre propre appareil) aux personnes qui participent à votre étude.

  • Science des données et analyse de la santé de la population : les données physiologiques et d’activité sont disponibles au format standard FHIR du secteur, ainsi que dans d’autres formats de données open source (JSON et Parquet). En plus du format de données, des connecteurs natifs sont fournis pour faciliter l’analyse et la transformation des données. Notamment des connecteurs comme le connecteur Power BI pour FHIR, les vues SQL Synapse Serverless et les clusters Spark dans Synapse.

    Cette solution fournit également une méthode paramétrisée pour anonymiser le jeu de données à des fins de recherche désidentifiée. Ces « données d’utilisation secondaire » peuvent être analysées et utilisées pour rechercher les bonnes pratiques et prendre en charge les workflows basés sur des preuves cliniques. Les observations stockées dans le serveur FHIR peuvent être utilisées pour rechercher des variances, et des workflows qui favorisent les meilleurs résultats et pratiques.

  • Aider les prestataires de soins de santé : les prestataires peuvent :

    • obtenir de meilleurs insights sur l’état de santé des patients
    • créer des modèles de soins de santé numériques proactifs pour les soins médicaux préventifs
    • prendre des décisions plus éclairées en fonction des indicateurs/notifications physiologiques
    • fournir des voies de remboursement pour le monitoring physiologique à distance

  • Questionnaire sur les résultats signalés par le patient (PRO) et soins pilotés par PRO - En utilisant des événements et des questionnaires PRO, vous pouvez créer des programmes de soins individualisés et des workflows de variance de soins. Le patient peut avoir plus d’autonomie et de contrôle sur le programme de soins individualisé, ce qui favorise l’adoption et l’utilisation soutenue. Les soins pilotés par PRO peuvent également être utiles pour résoudre l’écart des résultats observés par le corps médical et ceux signalés par les patients. En faisant le lien entre les questionnaires académiques et les PRO, RPM peut être utilisé pour orienter la prescription de médicaments, les traitements et/ou le suivi des soins, en répondant à des questions de type :

    • Les patients prennent-ils correctement leur pression artérielle ?
    • La balance est-elle utilisée au bon moment et avec la bonne fréquence ?
    • Retombons-nous sur nos pieds dans les PRO pour l’adoption des patients et la planification des soins individualisés ?

    Pour les patients utilisant des appareils iOS, les applications de questionnaire peuvent être créées en utilisant Apple ResearchKit. Les données de questionnaire sont ingérées par Azure Event Hubs et mises à disposition via le service FHIR, tout comme les données physiologiques et d’activité des patients sur l’appareil.

  • Autoriser des appareils de santé de plusieurs types et plus précis : utilisez des appareils de santé médicaux et à domicile afin de générer des données de santé en quasi-temps réel pour l’ingestion et l’analyse des données.

Considérations

Ces considérations sont alignées avec les piliers d’Azure Well-Architected Framework, qui est un ensemble de doctrines permettant d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

La disponibilité de données et d’insights cliniques est essentielle pour de nombreuses organisations de santé. Voici quelques exemples pour réduire les temps d’arrêt des services Azure indiqués dans cette solution :

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Les données de santé incluent souvent des informations confidentielles protégées et des informations personnelles. Les ressources suivantes sont disponibles pour sécuriser ces données :

  • Data Lake Storage utilise le contrôle d’accès en fonction du rôle (RBAC) et les listes de contrôle d’accès Azure pour créer un modèle de contrôle d’accès

  • Services de données de santé Azure est une collection de services gérés sécurisés utilisant Microsoft Entra ID, un fournisseur d’identité global prenant en charge OAuth 2.0. Quand vous créez un service d’Azure Health Data Services, vos données sont chiffrées par défaut à l’aide de clés managées par Microsoft. Consultez Authentification et autorisation pour les Services de données de santé Azure pour plus d’informations.

  • Azure Event Hubs fournit un chiffrement des données au repos avec Azure Storage Service Encryption (Azure SSE). À ce titre, des règles de pare-feu IP peuvent être appliquées au niveau de l’espace de noms Event Hubs. L’accès aux points de terminaison privés et au réseau virtuel peut également être configuré.

  • Synapse RBAC étend les fonctionnalités d’Azure RBAC pour les espaces de travail Synapse et leur contenu. RBAC Azure est utilisé pour gérer les utilisateurs autorisés à créer, mettre à jour ou supprimer l’espace de travail Synapse et ses pools SQL, pools Apache Spark et runtimes d’intégration.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les tarifs de nombreux composants Azure sont indiqués dans la calculatrice de prix Azure. En définitive, le prix de cette solution est basé sur des facteurs comme :

  • Les services Azure utilisés.
  • Le volume de données, en termes de nombre de patients/appareils et de nombre de types de données physiologiques et d’activités ingérés.
  • Les exigences de capacité et de débit pour Event Hubs.
  • Les ressources de calcul nécessaires pour effectuer des déploiements et des entraînement de machine learning, les pools Synapse Spark et les clusters Databricks.
  • La solution de visualisation et de création de rapports, comme Power BI.

Quand vous implémentez cette solution, tenez compte de la stratégie de conservation et d’archivage des données du lac de données Azure sous-jacent. Tirez parti de la gestion du cycle de vie du Stockage Azure pour fournir un moyen automatique de :

  • faire descendre les blobs de fichiers au niveau d’accès sporadique
  • faire passer le fichier au niveau d’archive en fonction de la date de dernière modification du fichier.

Pour en savoir plus sur les plans et les tarifs Life365.health, consultez l’offre Life365 API Connect Data dans la Place de marché Microsoft Azure

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Cette solution fournit une architecture scalable en quasi-temps réel pour le monitoring à distance des patients. Notez le flux de donnée multicouche : de l’interface entre les appareils et l’API Life365 à l’ingestion entre l’API Life365 et Azure Event Hubs, puis la transformation des données dans le service MedTech au sein d’Azure Health Data Service, et enfin l’exportation incrémentielle et l’anonymisation des données au format du lac de données. Par conséquent, le flux de données est traité en quasi-temps réel et toutes les applications et/ou intégrations en aval doivent être conçues de la même façon. Toutefois, les performances de cette solution peuvent être adaptées à un grand nombre d’appareils et de patients au niveau de l’entreprise.

Contributeurs

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

Auteurs principaux :

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

Étapes suivantes

Technologies et ressources liées à l’implémentation de cette architecture :