Questo articolo illustra come creare un sistema di telehealth usando la piattaforma cloud di Azure.
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
La soluzione si basa su quattro pilastri, tra cui:
- Client
- Componenti di comunicazione
- API e logica di business
- Servizi di archiviazione e infrastruttura
Sul lato sinistro del diagramma dell'architettura sono presenti client divisi in due gruppi, il professionista sanitario e il paziente. Il professionista sanitario usa il software di adattamento e i client del portale Web per comunicare con i pazienti. I pazienti, d'altra parte, usano un'app per dispositivi mobili collegata al dispositivo medicale tramite una connessione Bluetooth. Questa comunicazione a doppio senso si ottiene usando i servizi back-end:
- API pubbliche
- Microservizi interni responsabili dei flussi di lavoro, ad esempio videochiamate tramite Web RTC o comunicazioni da client a client tramite Signal. Signal è una libreria software per Microsoft ASP.NET che consente al codice server di inviare notifiche asincrone alle applicazioni Web lato client.
Lo stato di questi servizi viene salvato in modo permanente in diversi servizi di Azure (sul lato destro del diagramma), ad esempio Database di Azure per PostgreSQL. I file multimediali vengono salvati negli account di archiviazione di Azure. Tutti i log di tutti i servizi vengono raccolti in una soluzione di registrazione centralizzata che usa app Azure lication Insights. Infine, è possibile ottenere comunicazioni asincrone tra i client tramite notifiche push usando l'aiuto dell'hub di notifica di Azure.
La soluzione è stata impostata in questo modo per:
Trarre vantaggio dalla scalabilità dei servizi cloud in esecuzione nel back-end.
Aumentare l'autonomia dei team che compilano la soluzione. Ogni team supervisiona i domini funzionali e guida l'evoluzione dei componenti. Poiché i domini funzionali non si sovrappongono, ogni team può innovare al proprio ritmo. Inoltre, poiché le codebase dei servizi sono indipendenti, la pipeline CI/CD per l'intera soluzione è semplificata.
Creare il meccanismo di comunicazione e coordinamento tra servizi richiesto dalla distribuzione delle funzionalità tra microservizi. La soluzione descritta in questo documento usa cache di Azure per Redis per eseguire questa attività.
Ottenere il monitoraggio centrale e migliorare la possibilità di risolvere i problemi della soluzione.
Gestione semplificata di segreti, credenziali, certificati e chiavi che sfruttano le identità gestite per proteggere le comunicazioni tra i servizi.
Componenti
- Database di Azure per PostgreSQL archivia i dati relativi a utenti (pazienti e professionisti sanitari) e dispositivi. Il servizio è stato scelto perché è stabile, leggero e non è sottoposto a blocchi da parte del fornitore.
- Il servizio Azure Kubernetes ospita la logica di business dell'applicazione e offre facilità di distribuzione e flessibilità per la personalizzazione. Il servizio astrae anche la soluzione dall'hardware effettivo sottostante.
- Cache di Azure per Redis ospita i dati temporanei usati per i dati all'interno del servizio (dati condivisi). Il servizio può essere ricreato dal database in caso di scadenza dei dati dalla cache.
- Hub di notifica di Azure invia notifiche al paziente sul contenuto in ingresso: chat, videochiamate, impostazioni di configurazione del dispositivo.
- Funzioni di Azure pianifica le attività. Ad esempio, comunicazioni generali con un ampio set di utenti, coordinamento del lavoro di analisi nel back-end (aggregazioni e così via).
- Azure Application Insights centralizza segnali/eventi dal sistema (log, dati di telemetria dai log di microservizi, front-end e dispositivi) per la risoluzione dei problemi.
- Rete di distribuzione dei contenuti (rete CDN) di Azure viene usato per la manutenzione e gli aggiornamenti (recapito di file di script Java) al portale Web e per la distribuzione di file multimediali (video, immagini) tramite il portale. Tutto questo contenuto viene archiviato negli account di archiviazione di Azure in background.
- Gestione traffico di Azure bilancia il carico tra aree geografiche.
- Azure SignalR consente al codice server di inviare notifiche asincrone alle applicazioni Web lato client. I dispositivi degli utenti finali possono essere configurati in modalità standard o avanzata.
Alternative
Sul lato database è possibile usare qualsiasi altro servizio di database PaaS. Quando si ospita la logica dell'applicazione, anziché usare servizio Azure Kubernetes, è possibile usare app Azure Servizio.
Dettagli dello scenario
I dettagli si basano su un'implementazione reale del cliente che connette un'organizzazione sanitaria professionale ai relativi pazienti remoti. Anche se sono disponibili altri modi per creare un sistema di questo tipo, la soluzione descritta è stata in grado di consentire la comunicazione tra i pazienti e il provider di assistenza remota, nonché di eseguire l'ottimizzazione remota dei dispositivi medicali indossati dai pazienti.
Sono circa 700 milioni le persone che hanno disabilità uditive. Solo il 10%, tuttavia, usa dispositivi acustici per migliorare la propria vita. In alcune aree geografiche o situazioni, è impossibile per un paziente ottenere assistenza diretta quando necessario. Si considerino ad esempio i pazienti che:
- Serve aiuto in una situazione di udito specifica (ad esempio, mentre cammina nel parco, partecipa a una festa o si trova a casa), che non può essere riprodotto nell'ufficio del professionista dell'udito.
- Hanno problemi di mobilità o si trovano molto distanti dal professionista dell'udito.
- Vivono in un paese/area emergente con un numero limitato di professionisti dell'udito.
Per superare queste difficoltà, è importante avere la possibilità di fornire servizi di udito in remoto. In questo caso, il professionista sanitario usa la comunicazione tramite chat o video per interagire con i pazienti remoti. Le persone con problemi di udito usano uno smartphone per consentire l'accesso al dispositivo acustico durante la sessione remota. Il paziente sperimenta immediatamente un miglioramento dell'udito quando il professionista dell'udito apporta modifiche alla configurazione del dispositivo acustico in tempo reale.
Potenziali casi d'uso
Questa soluzione è ideale per il settore sanitario. I casi d'uso aggiuntivi seguenti hanno schemi progettuali simili:
- Dispositivi Bluetooth accessibili e modificabili da remoto usando una soluzione di questo tipo.
- Comunicazione (testo, voce, video) o scambio di conoscenze (formazione, sondaggi sulla soddisfazione) in un contesto remoto.
- Gestione di contenuti Web distribuiti a livello globale.
- internet delle cose (IoT)
Modalità
Modalità standard
In modalità standard, il software di adattamento prepara una notifica, che contiene alcuni file JSON di configurazione o contenuto per il dispositivo. La notifica viene quindi passata all'hub di notifica di Azure, che la invia al telefono dell'utente.
Modalità avanzata
In modalità avanzata, il professionista dell'udito usa il software di adattamento per eseguire il push di una configurazione dettagliata al dispositivo. Ciò richiede una connessione stabile e affidabile tra il back-end e il dispositivo, che SignalR ottiene usando WebSockets. Il telefono dell'utente finale si trova all'estremità ricevente di questo canale. Dal telefono, la connessione Bluetooth stabilisce il collegamento di comunicazione finale con il dispositivo.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
È consigliabile usare Gestione traffico con i vari cluster per ottimizzare la latenza tra le aree e come meccanismo di fallback nel caso in cui i cluster diventino non disponibili. Per i database, è consigliabile usare repliche di sola lettura per le query che richiedono il caricamento e l'aggregazione di una grande quantità di dati. È consigliabile distribuire file Web statici (.html, .js, immagini e così via) a livello globale usando una rete per la distribuzione di contenuti (rete CDN) per migliorare la velocità tramite la memorizzazione nella cache.
Distribuzione
L'aspetto più importante da considerare quando si distribuisce questo scenario è il coordinamento delle distribuzioni nel back-end basato sul cloud e nel front-end (telefoni/dispositivi). A tale scopo, è consigliabile usare il concetto di flag di funzionalità.
Gestione
Per allinearsi meglio all'idea di gestire ogni dominio funzionale usando un microservizio specifico, a lungo termine, è possibile suddividere il database in diversi database più piccoli. In questo modo, si consentirà l'isolamento del principio e l'autonomia del flusso correlato a ogni microservizio anziché concentrare i dati correlati a tutti i servizi in un singolo database. Per raggiungere questo obiettivo, sarà necessario automatizzare il provisioning e la gestione di tali database: una delle funzionalità principali di un servizio di database PaaS nel cloud. Tale livello di gestione del database deve essere integrato nella soluzione e nella soluzione di monitoraggio unificata.
Monitoraggio
È importante monitorare ogni livello e ogni facet di monitoraggio deve essere federato in un singolo bucket nel cloud. È importante abilitare la correlazione di tutti questi log e punti dati di telemetria per garantire informazioni olistiche su componenti e livelli.
Attualmente, i livelli monitorati includono:
- Applicazione Windows (software di adattamento sul desktop del professionista dell'udito)
- Logica dell'applicazione ospitata
- Servizi cloud
Dimensionamento e scalabilità
Assicurarsi di ottimizzare la configurazione dei cluster di Azure Kubernetes in modo da soddisfare i requisiti di scalabilità che fluttuano con l'ora del giorno o con i modelli dell'area. Prendere in considerazione l'offload dei carichi di lavoro di lettura, ad esempio l'aggregazione di query, usando repliche in lettura in Database di Azure per PostgreSQL.
L'uso dell'estensione TimescaleDB di PostgreSQL consentirà una gestione più efficiente dei dati relativi al tempo provenienti dai dispositivi medicali. Prendere in considerazione l'uso di una soluzione con scalabilità orizzontale, ad esempio Database di Azure per PostgreSQL - Hyperscale (Citus) per raggiungere la scalabilità globale effettuando il provisioning di più nodi di database.
Sicurezza e conformità
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Questa soluzione gestisce informazioni sanitarie protette e dati personali. Di conseguenza, è importante usare i servizi certificati per le applicazioni mediche (certificazioni HIPAA, non solo per i dati che rimangono nel database, ma anche i log e i dati di telemetria). Per informazioni dettagliate, vedere la sezione HIPAA del Centro protezione Microsoft.
L'identità gestita deve essere usata in tutti i servizi di Azure che supportano questo tipo di autenticazione senza password per semplificare la gestione delle password: servizio Azure Kubernetes, PostgreSQL, Cache Redis, Hub di notifica, Azure Key Vault e Funzioni di Azure. Vedere tutti i servizi che supportano le identità gestite per le risorse di Azure.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Per una distribuzione in una singola area, le informazioni sui prezzi di esempio sono disponibili nel Calcolatore prezzi.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Jean-Yves Devant | Product Manager principale
Passaggi successivi
Per iniziare a implementare un'architettura paragonabile per l'azienda, prendere in considerazione la creazione di competenze relative a servizi Web, database come Database di Azure per PostgreSQL e tecniche e tecnologie di sviluppo di applicazioni mobili come .NET MAUI.
Documentazione sui prodotti:
- Che cos'è Database di Azure per PostgreSQL?
- Servizio Azure Kubernetes
- Account di archiviazione di Azure
- Informazioni su cache di Azure per Redis
- Introduzione a Funzioni di Azure
- Azure Application Insights
- Che cos'è Hub di notifica di Azure?.
Comunicazioni in tempo reale:
Altre informazioni sul modo in cui WebRTC fornisce funzionalità di comunicazione in tempo reale alle applicazioni per dispositivi mobili sono disponibili nel sito del progetto WebRTC.
Turn servers (Turn servers):
Usare una libreria client come Icelink (caricata dall'applicazione sul telefono e dal software di adattamento del desktop del professionista dell'ausilio acustico) per gestire i server TURN* e i tipi di connessione (tcp, udp, p2p) tra i due client (software di adattamento e applicazione sul telefono). La libreria client:
- Crea il canale di flusso
- Stabilisce le connessioni
- Gestisce la connessione in caso di errori, pacchetti mancanti, regola automaticamente il flusso alle variazioni della larghezza di banda
- Codifica/decodifica le chiamate (audio e/o video) durante le chiamate
*I server TURN sono entità di rete responsabili dell'inoltro dei supporti nei protocolli correlati a VoIP. In questa soluzione sono ospitati da https://xirsys.com/ in diversi data center in tutto il mondo. Stabilisce una connessione diretta tra due client nella stessa sessione