Cet article explique comment créer un système de téléconsultation à l’aide de la plateforme cloud Azure.
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
La solution repose sur quatre piliers, à savoir :
- Clients
- Composants de communication
- API et logique métier
- Services de stockage et d’infrastructure
Sur le côté gauche du diagramme architectural, il y a des clients répartis en deux groupes, les professionnels de la santé et les patients. Les professionnels de la santé utilisent le logiciel de réglage et les clients du portail web pour communiquer avec leurs patients. Les patients, en revanche, utilisent une application mobile qui est liée à l’appareil médical via une connexion Bluetooth. Cette communication bidirectionnelle est obtenue à l’aide de services principaux :
- API côté public ;
- microservices internes responsables de flux de travail tels que des appels vidéo via une communication RTC web ou client-client utilisant Signal. Signal est une bibliothèque de logiciels pour Microsoft ASP.NET, qui permet au code serveur d’envoyer des notifications asynchrones à des applications web côté client.
L’état de ces services est conservé dans plusieurs services Azure (sur le côté droit du diagramme), par exemple, Azure Database pour PostgreSQL. Les fichiers multimédias sont enregistrés dans des comptes de stockage Azure. Tous les journaux de tous les services sont collectés dans une solution de journalisation centralisée qui utilise Azure Application Insights. Enfin, une communication asynchrone peut être obtenue entre les clients via des notifications Push à l’aide d’Azure Notification Hub.
La solution a été configurée de cette manière pour atteindre les objectifs suivants :
Tirer parti de la scalabilité des services cloud en cours d’exécution sur le serveur principal.
Augmenter l’autonomie des équipes qui créent la solution. Chaque équipe supervise des domaines fonctionnels et pilote l’évolution de ses composants. Étant donné que les domaines fonctionnels ne se chevauchent pas, chaque équipe peut innover à son propre rythme. En outre, étant donné que les codes base des services sont indépendants, le pipeline CI/CD pour l’ensemble de la solution est simplifié.
Créer le mécanisme de communication et de coordination entre services requis pour la distribution de fonctionnalités entre microservices. La solution décrite dans ce document utilise Azure Cache pour Redis pour accomplir cette tâche.
Obtenir une surveillance centrale et améliorer la capacité à résoudre les problèmes de la solution.
Gestion simplifiée des secrets, des informations d’identification, des certificats et des clés en tirant parti des identités managées pour sécuriser la communication entre les services.
Composants
- Azure Database pour PostgreSQL stocke des données relatives aux utilisateurs (patients et professionnels de santé) et aux appareils. Le service a été choisi, parce il est stable, léger et n’a pas de verrouillage de fournisseur.
- Azure Kubernetes Service héberge la logique métier de l’application et facilite le déploiement et la flexibilité à des fins de personnalisation. Le service abstrait également la solution du matériel réel utilisé ci-dessous.
- Azure Cache pour Redis héberge les données temporaires utilisées pour les données intra-service (données partagées). Le service peut être recréé à partir de la base de données au cas où les données expirent dans le cache.
- Azure notification Hub informe le patient du contenu entrant : conversation, appel vidéo, paramètres de configuration de l’appareil.
- Azure Functions planifie des tâches. Par exemple, communications étendues à un grand ensemble d’utilisateurs, coordination du travail d’analytique dans le serveur principal (agrégations...).
- Azure Application Insights centralise les signaux/événements du système (journaux, télémétrie de journaux des microservices, frontal et appareils) à des fins de résolution des problèmes.
- Azure Content Delivery Network (CDN) est utilisé pour la maintenance et les mises à jour (livraison de fichier de scripts Java) sur le portail web et pour livrer des fichiers multimédias (vidéos, images) via le portail. Tout ce contenu est stocké dans les comptes de stockage Azure en arrière-plan.
- Azure Traffic Manager équilibre la charge entre les emplacements géographiques.
- Azure SignalR permet au code serveur d’envoyer des notifications asynchrones aux applications web côté client. Les appareils des utilisateurs finaux peuvent être configurés en mode Standard ou Avancé.
Autres solutions
Du côté de la base de données, tous les autres services de base de données PaaS peuvent être utilisés. Lorsque vous hébergez la logique de l'application, plutôt que d'utiliser Azure Kubernetes Service, vous pouvez envisager d'utiliser Azure App Service.
Détails du scénario
Les détails sont basés sur une implémentation de client réel qui connecte un organisme de santé professionnel à ses patients à distance. Bien qu’il existe d’autres façons de créer un système de ce type, la solution décrite a permis la communication entre les patients et leur prestataire de soins à distance, ainsi que le réglage à distance des appareils médicaux dont les patients sont porteurs.
Quelque 700 millions de personnes souffrant d’un handicap auditif. En revanche, seuls 10 % d’entre elles utilisent des prothèses auditives pour améliorer leur vie. Dans certaines zones géographiques ou situations, il est impossible pour un patient d’obtenir une assistance directe quand il en a besoin. Songez, par exemple, aux patients qui :
- ont besoin d’une aide auditive dans des situations spécifiques (par exemple, à l’extérieur, en société ou à la maison), impossibles à reproduire dans le cabinet de l’audioprothésiste.
- rencontrent des problèmes de mobilité ou résident dans des emplacements situés à grande distance de leur audioprothésiste ;
- vivent dans un pays ou une région émergents comptant un nombre limité d’audioprothésistes.
Pour surmonter ces difficultés, il est important d’avoir la possibilité de fournir des services de soins auditifs à distance. Dans ce cas, le professionnel de la santé utilise une communication vidéo ou une conversation pour communiquer avec ses patients à distance. Les personnes malentendantes utilisent un smartphone pour autoriser l’accès à l’audioprothèse pendant la session à distance. Le patient bénéficie immédiatement d’une meilleure audition, car l’audioprothésiste déploie les modifications apportées à la configuration de l’audioprothèse en temps réel.
Cas d’usage potentiels
Cette solution est idéale pour le secteur de la santé. Les cas d’utilisation supplémentaires suivants correspondent à des modèles de conception similaires :
- appareil compatible Bluetooth accessible et réglable à distance à l’aide d’une solution de ce type ;
- communication (texte, audio, vidéo) ou échange de connaissances (enseignement, enquêtes de satisfaction) dans un contexte/une situation d’éloignement ;
- gestion de contenu web distribué dans le monde entier.
- Internet des objets (IoT)
Modes
Mode standard
En mode Standard, le logiciel de réglage prépare une notification contenant un fichier JSON de configuration ou du contenu pour l’appareil. La notification est ensuite transmise à Azure notification Hub qui l’envoie au téléphone de l’utilisateur.
Mode Avancé
En mode avancé, l’orthoprothésiste utilise le logiciel de réglage pour envoyer (push) la configuration détaillée à l’appareil. Cela nécessite une connexion stable et fiable entre le serveur principal et l’appareil, que SignalR établit à l’aide de WebSockets. Le téléphone de l’utilisateur final se trouve à l’extrémité réceptrice de ce canal. À partir du téléphone, la connexion Bluetooth établit le lien de communication final avec l’appareil.
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.
Nous vous recommandons d’utiliser un gestionnaire de trafic devant les différents clusters pour optimiser la latence entre régions et en tant que mécanisme de secours si les clusters devenaient disponibles. Pour les bases de données, nous vous recommandons d’utiliser des réplicas en lecture seule pour les requêtes qui nécessitent le chargement et l’agrégation d’une grande quantité de données. Nous vous recommandons de livrer les fichiers web statiques (.html, .js, images, etc.) à l’échelle mondiale à l’aide d’un réseau de distribution de contenu (CDN) afin d’améliorer la vitesse grâce à la mise en cache.
Déploiement
L’aspect le plus important à prendre en compte lors du déploiement de ce scénario est la coordination des déploiements sur le serveur principal basé sur le cloud et le serveur frontal (téléphones/appareils). Envisagez de recourir au concept d’indicateur de fonctionnalité pour y parvenir.
Gestion
Pour mieux s’aligner sur l’idée que chaque domaine fonctionnel soit traité avec l’aide d’un microservice spécifique, à long terme, il est possible de diviser la base de données en plusieurs bases de données plus petites. Cette approche permet l’isolation et l’autonomie de principe du flux lié à chaque microservice au lieu de concentrer les données relatives à tous les services dans une seule base de données. Pour atteindre cet objectif, vous devez automatiser l’approvisionnement et la gestion de ces bases de données, ce qui constitue l’une des principales fonctionnalités d’un service de base de données PaaS dans le cloud. Cette couche de gestion de base de données doit être intégrée dans la solution, ainsi que dans la solution de surveillance unifiée.
Surveillance
Il est important de monitorer chacun des niveaux, et chaque facette du monitoring doit être fédérée dans un compartiment unique du cloud. Il est important d’activer la corrélation de tous ces journaux et des points de données de télémétrie pour garantir l’obtention d’insights holistiques sur les composants et les couches.
Aujourd’hui, les couches surveillées sont les suivantes :
- application Windows (logiciel de réglage sur le bureau de l’audioprothésiste)
- Logique d’application hébergée
- Services cloud
Dimensionnement et mise à l’échelle
Veillez à optimiser la configuration des clusters Azure Kubernetes pour répondre aux exigences de mise à l’échelle qui fluctuent selon l’heure de la journée ou des modèles régionaux. Envisagez de décharger les charges de travail de lecture (telles que l’agrégation des requêtes) à l’aide de réplicas en lecture dans Azure Database pour PostgreSQL.
L’utilisation de l’extension TimescaleDB de PostgreSQL permet une gestion plus efficace des données de temps provenant des appareils médicaux. Utilisez une solution de scale-out parallèle comme Azure Database pour PostgreSQL - Hyperscale (Citus) afin d’atteindre une échelle mondiale en provisionnant plusieurs nœuds de base de données.
Sécurité et conformité
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é.
Cette solution gère les données de renseignements médicaux protégés (PHI) et les données personnelles. Par conséquent, il est important d’utiliser des services certifiés pour les applications médicales (certifications HIPAA, non seulement pour les données qui restent dans la base de données, mais aussi pour les journaux et les données de télémétrie). Pour plus d’informations, consultez la section HIPAA du Centre de gestion de la confidentialité Microsoft.
L’identité managée doit être utilisée sur tous les services Azure qui prennent en charge ce type d’authentification sans mot de passe pour simplifier la gestion des mots de passe : AKS, PostgreSQL, Cache Redis, Notification Hub, Azure Key Vault et Azure Functions. Consultez tous les services Azure qui prennent en charge les identités gérées pour les ressources Azure.
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 un déploiement dans une région unique, des exemples d’informations de tarification sont disponibles dans la Calculatrice de prix.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Jean-Yves Devant | Principal Product Manager
Étapes suivantes
Pour commencer à implémenter une architecture comparable pour votre entreprise, envisagez d’acquérir des compétences dans le domaine des services web, des bases de données telles qu’Azure Database pour PostgreSQL et des techniques et technologies de développement d’applications mobiles telles que NET MAUI.
Documentation du produit :
- Qu’est-ce qu’Azure Database pour PostgreSQL ?
- Azure Kubernetes Service
- Des comptes de stockage Azure
- À propos du cache Azure pour Redis
- Présentation d’Azure Functions
- Azure Application Insights
- Présentation d’Azure Notification Hubs.
Communications en temps réel :
Pour plus d’informations sur la façon dont WebRTC fournit des fonctionnalités de communication en temps réel aux applications mobiles, consultez le Site de projet WebRTC.
Serveurs TURN :
Utilisez une bibliothèque de client telle qu’Icelink (chargée par l’application sur le téléphone et par le logiciel de réglage du bureau de l’audioprothésiste) afin de gérer les serveurs turn* et les types de connexion (TCP, UDP, P2P) entre les deux clients (logiciel et application de réglage sur le téléphone). La bibliothèque de client :
- Crée le canal de diffusion.
- Établit les connexions.
- Gère la connexion en cas d’erreur, de paquets manquants, et ajuste automatiquement la diffusion en continu aux variations de la bande passante.
- Encode/décode les appels (audio et/ou vidéo) pendant les appels.
*Les serveurs turn sont des entités réseau responsables du relais des médias dans les protocoles VoIP. Dans cette solution, elles sont hébergées par https://xirsys.com/ dans plusieurs centres de données à travers le monde. Établit une connexion directe entre deux clients dans le cadre de la même session.