Cet article présente une solution potentielle de planification et de suivi des consultations virtuelles entre les patients, les prestataires et les gestionnaires de soins.
Architecture
Téléchargez un fichier Visio contenant ce diagramme d’architecture.
Dans ce diagramme d'architecture, les encadrés bleus représentent les services Microsoft qui correspondent aux services sous-jacents ou aux modules complémentaires requis pour Microsoft Cloud for Healthcare, chacun devant faire l'objet d'une licence distincte. L'ensemble de ces composants permet d'accélérer le développement de solutions de santé intégrées pour l'engagement des patients, la collaboration des équipes de santé et l'amélioration des insights relatifs aux données cliniques et opérationnelles.
Les données entrent dans le système par le biais de divers systèmes médicaux externes, tels que les plannings des patients et des prestataires de soins, les dossiers médicaux, les appareils portables, etc. Ces données sont ingérées à l’aide d’Azure. Elles sont ensuite stockées dans Microsoft Dataverse, un magasin de données alimenté par la plateforme Power Apps. Ces données sont mises en forme pour utiliser des entités et avoir des relations entre elles, créées à l'aide du modèle CDM (Common Data Model), une norme sectorielle relative aux données médicales. Toutes les interactions entre le patient, le prestataire et le gestionnaire de soins se font à l'aide de ces données CDM stockées dans Dataverse.
Un patient établi peut se connecter en toute sécurité au Portail des patients, un site web hébergé sur les portails Power Apps. Sur ce portail, le patient peut communiquer avec un Assistant intelligent. Il s'agit d'une instance du service Azure Health Bot qui recueille ses symptômes, fournit des suggestions et recommande, si nécessaire, d'appeler le praticien. Si le patient choisit de contacter un prestataire de soins, l'instance de Health Bot récupère à partir de Dataverse les données relatives aux prestataires disponibles pour les consultations virtuelles ainsi que leurs plannings. Une fois que le patient a sélectionné un prestataire et une heure de rendez-vous, le bot lui présente ses coordonnées, obtenues à partir des données DME/DSE stockées dans Dataverse. Le patient peut valider ou modifier ces informations, et enregistrer les données à l'aide du bot.
Pour fixer un rendez-vous, l'instance de Health Bot se connecte à l'application Bookings à l'aide de l'API Microsoft Graph et prend un rendez-vous auprès du prestataire. Un e-mail contenant les informations relatives au rendez-vous est envoyé aux deux parties à l'aide de Microsoft Outlook. Le patient reçoit des instructions afin de se connecter au Portail des patients pour le processus d'admission. Ce processus implique la confirmation ou la modification de ses informations de contact, de paiement et d'assurance maladie, puis la signature d'un formulaire de consentement pour la consultation virtuelle. Une fois le consentement signé, le patient reçoit le lien Microsoft Teams à utiliser pour le rendez-vous.
Le prestataire se connecte à Teams pour consulter son planning de rendez-vous et les informations récapitulatives de chacun d'entre eux. Teams présente ces informations à l'aide de l'application File d'attente des rendez-vous. Le prestataire est alors en mesure de lancer sur Teams la consultation virtuelle correspondant au rendez-vous planifié. Pendant l'appel, le prestataire peut prendre des notes et les ajouter au dossier du patient.
L'ajout d'une nouvelle note dans le dossier médical du patient déclenche une notification de révision pour le gestionnaire de soins attribué au patient. Lorsque le gestionnaire de soins reçoit cette notification, il peut se connecter à Teams pour consulter la liste des patients qui lui sont attribués ainsi que les notes. L'application Care Management lui permet d'apporter les modifications nécessaires au programme de soins du patient.
Composants
L’architecture est constituée des composants suivants :
PAS. Les systèmes d'administration des patients (Patient Administration Systems, PAS) sont des systèmes qui automatisent les formalités administratives dans les établissements de soins tels que les hôpitaux. Ce sont les composants de base de l'infrastructure informatique de ces établissements. Un système PAS enregistre les données démographiques du patient, telles que son nom, son adresse, sa date de naissance, etc. Il enregistre également des informations détaillées sur tous les contacts que le patient a eus avec l'hôpital, qu'il s'agisse de consultations externes ou d'hospitalisations. Les systèmes PAS permettent aux hôpitaux modernes d'établir des rapports et de planifier les ressources à l'échelle de l'établissement. Dans cette solution, le système PAS est une source essentielle de données de planification. Dans la mesure où ces données sont externes et qu'elles peuvent se présenter sous un format non standard, il est important de les convertir dans un format compris par tous les composants de la solution.
DME/DSE. Les dossiers médicaux électroniques (EMR) et les dossiers de santé électroniques fournissent les dossiers numériques des informations médicales et médicales d’un patient, y compris les diagnostics, les médicaments, les vaccinations, et ainsi de suite. Ils peuvent être limités à un seul cabinet médical (DME), ou être conçus pour avoir une portée beaucoup plus large et accompagner les patients dans n'importe quel établissement (DSE). Il s'agit, dans cette solution, de sources de données externes importantes qui peuvent se présenter sous un format non structuré et non standard. Ces données doivent donc être converties dans un format utilisable par les composants de la solution.
API Azure pour FHIR. Azure est la première étape du processus d'intégration des données dans l'écosystème Microsoft et dans Microsoft Cloud for Healthcare. Cette couche fournit une interface sécurisée entre les données externes et les composants internes de cette architecture. L'API Azure pour FHIR ingère les données provenant de sources disparates (dossiers DME, systèmes PAS, appareils, etc.), qu'elles soient structurées ou non, les convertit en ressources FHIR et les fait persister dans Azure. Ces données peuvent ensuite être utilisées dans Microsoft Cloud for Healthcare pour différents services. L'API Azure pour FHIR a été conçue pour les données médicales protégées, dans un souci de sécurité et de conformité. Pour plus d’informations sur cette couche, consultez Azure pour la santé et API Azure pour FHIR.
Common Data Model. Avec Common Data Model (CDM), Microsoft fournit un système de définition de métadonnées standardisé, extensible et personnalisable pour répondre à des besoins métier spécifiques. Les entités CDM sont disponibles pour des domaines tels que la gestion des relations client, la santé, la gestion des compétences, etc. Pour plus d'informations, consultez Informations relatives à l'utilisation du modèle Common Data Model. En plus de ces entités, les clients peuvent extraire des données propriétaires en définissant cette table d'entités et les champs sous-jacents dans le modèle Common Data Model, et celles-ci peuvent ensuite être utilisées de manière transparente avec d'autres entités au sein de leur solution.
Microsoft Dataverse. Dataverse est une base de données relationnelle qui alimente Microsoft Dynamics 365 ; il s'agit du référentiel des données représentées dans le modèle Common Data Model. Il contient des bases de données sur les patients, avec leur nom, des informations sur leur famille, leur état de santé, leurs antécédents médicaux, etc. Il contient également les informations obtenues à partir de tous les appareils portables utilisés et enregistrés par les patients, ainsi que les données de planification et de gestion de l'établissement de santé. Ces données sont définies à l'aide du modèle Common Data Model.
Portail des patients. Ce portail Power Apps permet aux patients de consulter leurs dossiers médicaux, de prendre des rendez-vous, de communiquer avec l'instance de Health Bot, etc. Il peut être étendu pour prendre en charge d'autres données. Ce portail fait partie de Microsoft Cloud for Healthcare et vous permet de créer facilement un portail, qui peut se connecter à des entités de Dataverse, en extrayant des données telles que des informations sur les patients, des programmes de soins, des rendez-vous, etc.
Assistance intelligente. Il s'agit d'une instance du service Azure Health Bot, accessible aux patients via le Portail des patients. Cette instance de Health Bot est chargée dans un site web Azure App Service. Elle est personnalisable et peut être programmée à l'aide des scénarios requis par les clients.
Application Bookings. L'application Bookings est un service Microsoft 365 inclus dans Microsoft Cloud for Healthcare. Elle facilite la planification des événements de calendrier et permet de créer des réunions Teams.
Microsoft Outlook. Cette solution utilise Microsoft Outlook comme client de messagerie. L'application Bookings qui envoie la notification par e-mail est intégrée à Outlook. Il est également possible d'utiliser le client de messagerie préféré du prestataire de soins.
Microsoft Teams. Microsoft Teams est un composant de Microsoft Cloud for Healthcare qui fournit l’interface pour les interactions entre les patients, les soignants et le personnel encadrant. Les utilisateurs peuvent utiliser une version installée localement ou la version web. Pour plus d'informations sur Teams, consultez la documentation Microsoft Teams.
File d'attente des rendez-vous. Cet outil génère une page HTML avec les données extraites de Dataverse, à l'aide de l'API web Dynamics 365. Il présente au prestataire des informations sur les rendez-vous prévus pour la journée et un résumé de chacun d'entre eux. Il fournit également un lien d'accès aux informations du patient via l'application Care Management. L'application File d'attente des rendez-vous a été développée pour prendre en charge ce scénario et ne fait pas partie de Microsoft Cloud for Healthcare. Les sources de données de cet outil sont principalement les systèmes PAS et les dossiers DME/DSE. Si ces systèmes disposent d'outils intégrés pour présenter ces données, ces outils peuvent remplacer ce composant dans un déploiement réel.
Care Management. L'outil Care Management est un composant de Microsoft Cloud for Healthcare. Il s'agit d'une application Power Apps déployée via Dynamics 365. Celle-ci récupère les données patient DME/DSE stockées dans Dataverse au format CDM, et présente une vue agrégée de celles-ci dans Teams. Pour sa solution, un centre de soins peut choisir d'utiliser son propre système avec ses propres fonctionnalités, en fonction de la manière dont il souhaite présenter ces informations.
Power BI Analytics. Il s'agit d'un outil d'analyse créé pour ce scénario et non disponible avec Microsoft Cloud for Healthcare. Dans cette solution, il génère des informations dérivées des appareils IoMT des patients. Il peut s'agir de données telles que la fréquence cardiaque, le taux d'oxygène dans le sang, etc. L'application Care Management utilise ces données pour présenter aux prestataires de soins des informations supplémentaires sur leurs patients en fonction de leurs activités quotidiennes.
Appareils connectés. Il s'agit d'appareils IoMT (Internet of Medical Things) , qui sont des appareils intelligents destinés à un usage médical. Les appareils portables Apple Watch et Fitbit, ainsi que les moniteurs médicaux ou de surveillance des signes vitaux sont des exemples d'appareils IoMT. Les patients peuvent approvisionner leurs appareils par l'intermédiaire d'Azure et choisir d'autoriser leur système de gestion des soins à recueillir ces données IoMT à l'intention des prestataires qui les suivent. Les prestataires de soins peuvent obtenir des informations supplémentaires à partir de ces appareils, quasiment en temps réel, et établir un lien entre des anomalies telles qu'une fréquence cardiaque élevée et les symptômes du patient.
Automatisation avec Power Automate. Il s'agit d'un outil personnalisé créé pour prendre en charge ce scénario, et il n'est pas disponible avec Microsoft Cloud for Healthcare. Dans la mesure où il s'agit d'un scénario de consultation virtuelle, le prestataire peut n'être qu'un médecin de garde et non le médecin habituel du patient. Cet outil permet aux notes du prestataire de déclencher une notification Teams à l'intention du gestionnaire de soins. Le gestionnaire de soins est le membre de l'équipe médicale qui assure la liaison entre le médecin traitant et le patient, et s'occupe de la gestion des soins de longue durée. Une notification envoyée au gestionnaire de soins, signalant l'ajout de nouvelles notes relatives au patient, lui permet d'examiner et d'apporter les modifications appropriées à la gestion des soins du patient après la consultation.
Autres solutions
Les services Azure pour la santé, tels que l'API Azure pour FHIR et Azure Health Bot, l'interface Common Data Model, Microsoft Dataverse et Microsoft Teams, constituent les composants de base de cette solution. La plupart des autres composants de ce système peuvent être remplacés par les systèmes en cours d'utilisation par l'établissement de santé :
Si le système DME/DSE est fourni avec des modules intégrés pour la réservation, la planification et la gestion des soins, ces modules peuvent être utilisés à la place des composants correspondants de cette solution.
Les systèmes utilisés par l'établissement de santé peuvent remplacer Bookings et Outlook pour la planification et les notifications par e-mail. Ces opérations peuvent être effectuées via le système DSE ou à l'aide d'une application tierce. L'application doit fournir une API que l'instance de Health Bot peut utiliser pour créer et programmer des rendez-vous, ainsi que la possibilité de créer des réunions virtuelles.
Si le prestataire dispose déjà d'un portail patients implémenté par le biais de son système DME/DSE, il peut l'utiliser à la place du Portail des patients. Il est facile d'intégrer un tel composant externe à cette solution, car ces composants utilisent des interfaces standard, par exemple une interface iFrame pour communiquer avec l'instance de Health Bot. Les composants qui prennent en charge ce flux peuvent être créés sur le portail propriétaire, comme le formulaire de consentement que le patient doit signer avant de rejoindre la réunion Teams.
Il convient de noter qu'un déploiement réel nécessitera des outils de remplacement pour certains composants de cette solution, comme l'application File d'attente des rendez-vous, les notifications automatiques et les outils d'analyse Power BI. Ces composants devront être créés et personnalisés en fonction des besoins du prestataire de soins.
Détails du scénario
Dans le contexte de la pandémie actuelle de COVID-19 (coronavirus), beaucoup de patients peuvent préférer consulter les prestataires de soins virtuellement plutôt qu'en présentiel, dans la mesure du possible. Dans ce monde virtuel, il devient important d'améliorer les insights cliniques et opérationnels liés à la santé. Il s'agit notamment de relier les données provenant de différents systèmes, de créer des insights pour prévenir les risques, et d'améliorer les soins, l'assurance qualité et l'efficacité opérationnelle.
Cette solution repose sur Microsoft Cloud for Healthcare. Microsoft Cloud for Healthcare rassemble des fonctionnalités approuvées de Microsoft 365, d'Azure, de Dynamics 365, de Power Platform et du vaste écosystème de partenaires de Microsoft pour aider les établissements de soins à créer des solutions de santé rapides, efficaces et sécurisées.
Cas d’usage potentiels
Cette solution a pour but de proposer des consultations virtuelles aux patients dans le cadre de la pandémie actuelle. Cela dit, les prestataires de soins peuvent facilement l'appliquer aux scénarios suivants :
Planification d'un suivi virtuel des consultations en présentiel
Offre de conseils médicaux non urgents aux patients en déplacement
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
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é.
Dans la mesure où le système repose sur les données des patients, des considérations de base sur la sécurité des informations privées doivent être appliquées lors du développement de cette solution :
Seules les données requises doivent circuler dans le système à un moment donné. Par exemple, seules les données nécessaires à la planification et à la gestion des consultations virtuelles doivent être extraites des systèmes DME/DSE. Examinez les règles de conformité HIPAA établies pour savoir où les données des patients doivent être stockées, ce qui peut en être fait et qui doit y avoir accès. Tenez compte de l'importance de la conformité dans le secteur de la santé lors du développement de votre solution. Pour plus d'informations, consultez Conformité dans Microsoft Cloud for Healthcare.
Seul le personnel autorisé doit avoir accès aux données des patients, et uniquement aux données exigées par sa fonction. À différents points du système, tels que l'application Care Management et les analyses qui l'alimentent, l'application File d'attente des rendez-vous ou les systèmes de notification, il convient d'authentifier et d'autoriser le personnel, et de limiter son accès aux seules informations requises sur les patients.
Les modules qui interagissent avec les patients, tels que l'Assistance intelligente et l'application Bookings, recueillent, stockent et utilisent les données des patients. Un contrôle d'accès et une authentification appropriés à ces modules permettent de respecter les exigences de confidentialité.
En raison de la nature des données privées impliquées, la sécurité et la conformité constituent les principes de base de Microsoft Cloud for Healthcare.
Cet exemple repose également sur les règles de sécurité définies par Dynamics 365 et Teams :
Les services individuels inclus dans Microsoft Cloud for Healthcare fournissent leur propre niveau de sécurité et de conformité :
Pour les contrôles de sécurité personnalisés, envisagez d'utiliser Microsoft Entra ID et le contrôle d'accès basé sur les rôles.
Enfin, lors de l'implémentation de cette solution, gardez à l'esprit les meilleures pratiques et les conseils relatifs au développement de solutions Azure sécurisées.
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.
Pour plus d'informations sur les tarifs de Microsoft Cloud for Healthcare, consultez Comment acheter Microsoft Cloud for Healthcare. Des conditions de licence spécifiques s'appliquent aux composants de Microsoft Cloud for Healthcare :
Pour recréer des composants personnalisés dans cette architecture, tenez compte des informations tarifaires des services sous-jacents que vous choisissez d'utiliser.
Déployer ce scénario
La solution doit être déployée par étapes :
Certains produits/services doivent être installés comme conditions préalables à Microsoft Cloud for Healthcare. Consultez la liste détaillée dans cet article consacré aux exigences en matière de licence.
Microsoft Cloud for Healthcare peut être déployé en suivant les instructions fournies dans Déployer des solutions Microsoft Cloud for Healthcare avec Dynamics 365.
Microsoft Cloud for Healthcare fournit des composants de base pour entamer la création d'une solution de santé virtuelle, tels que le Portail des patients, Teams, Bookings, etc. Les données qui seront utilisées pour alimenter ces blocs de construction doivent être personnalisées en fonction des besoins métier.
Les composants disponibles dans Microsoft Cloud for Healthcare et ses prérequis doivent être personnalisés pour prendre en charge les besoins métier :
Des flux Power Automate doivent être créés pour prendre en charge les notifications du gestionnaire de soins.
Le Portail des patients doit être configuré. Il peut être nécessaire de créer des formulaires supplémentaires pour les éléments tels que les formulaires d'enregistrement et de consentement. Pour plus d'informations, consultez Configurer un portail Accès des patients.
Le service Azure Health Bot doit être connecté à la base de données Dataverse et personnalisé pour la communication avec les patients. Pour plus d'informations, consultez Configurer des conversations automatiques à l'aide de Microsoft Health Bot.
Consultez Configurer la synchronisation avec les données cliniques à l'aide d'Azure FHIR Sync Agent et Incorporer des rapports Power BI à des fins d'analyse afin de vous familiariser avec d'autres configurations qui peuvent s'avérer nécessaires.
Les composants supplémentaires qui ont été spécifiquement créés pour cette solution ne sont pas disponibles pour une utilisation en production. L'établissement de santé peut être amené à créer sa propre version de ces applications :
File d'attente des rendez-vous
Notifications automatisées à l'aide de Power Automate
Application de création de rapports à l'aide de Power BI
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Slavica Frljanic | Responsable principale des programmes du groupe
- Dhanashri Kshirsagar | Senior Content PM
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Qu’est-ce que Microsoft Cloud pour les soins de santé ?
- Pour en savoir plus sur les offres Azure pour la santé, consultez Azure pour la santé - Solutions de santé.
- Différence entre DME et DSE
- Règles de conformité HIPAA
- Qu’est-ce que l’API Azure pour FHIR ?
- Présentation de Microsoft Dataverse
- Présentation d’Azure Health Bot Service
- Qu’est-ce que Power BI ?
- Découvrez comment utiliser Microsoft Dynamics 365