Monitoraggio remoto dei pazienti

Azure Data Lake Storage
Azure Databricks
Hub eventi di Azure
Azure Machine Learning
Azure Synapse Analytics
Power BI

I sistemi sanitari, gli ospedali e le grandi pratiche mediche stanno passando a iniziative ospedaliere a domicilio (noto anche come monitoraggio remoto dei pazienti). Il monitoraggio remoto dei pazienti è un sottoinsieme di cure cliniche in cui è possibile accedere ai pazienti e i dati fisiologici usando dispositivi sanitari remoti in conformità ai parametri del piano di assistenza individuale.

Questo articolo fornisce indicazioni su come progettare una soluzione usando Servizi per i dati sanitari di Azure e i dispositivi per il monitoraggio intelligente dei pazienti remoti. La soluzione consente di alleviare molte delle sfide di integrazione dei dispositivi che l'organizzazione deve affrontare durante la creazione di una soluzione su larga scala.

Architettura

Diagramma dell'architettura di monitoraggio remoto dei pazienti con dispositivi sanitari e servizi di Azure.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  1. I dispositivi dei pazienti generano attività e dati fisiologici. I dati vengono quindi estratti dai dispositivi usando uno degli SDK open source (OSS) microsoft disponibili e inseriti da Hub eventi di Azure.

  2. La piattaforma Life365.health supporta 300 dispositivi che generano attività e dati fisiologici L'API Life365 inserisce le attività e i dati fisiologici dai dispositivi di monitoraggio dei pazienti in Hub eventi di Azure.

  3. Il servizio Azure MedTech esegue il pull delle misurazioni dei dispositivi da Gub eventi, trasformandole in formato FHIR Fast Healthcare Interoperability Resources (FHIR®) e le passa al servizio Azure FHIR. L'area di lavoro Di Azure Health Data Services è un contenitore logico per le istanze del servizio sanitario, ad esempio i servizi FHIR e MedTech.

  4. L'area di lavoro di Azure Health Data Services invia messaggi di notifica ai sottoscrittori di eventi quando viene creata, aggiornata o eliminata una risorsa FHIR nel servizio Azure FHIR. Le notifiche possono essere inviate a più endpoint per attivare l'automazione, inclusi l'avvio di flussi di lavoro o l'invio di messaggi di posta elettronica e sms.

  5. Le pipeline di analisi FHIR esportano in modo incrementale i dati FHIR non anonimi in Azure Data Lake, rendendoli disponibili per l'analisi con vari servizi dati di Azure. I dati esportati possono anche essere resi anonimi sfruttando strumenti come gli strumenti open source Microsoft per l'anonimizzazione dei dati sanitari. L'anonimizzazione predefinita si basa sul metodo HIPAA Safe Harbor, che può essere esteso e modificato in base alle esigenze.

    Importante

    I dati FHIR esportati in questo flusso di dati sono non elaborati, che includono informazioni PHI. Il processo di de-identificazione può essere usato per rimuovere gli identificatori personali dai dati a scopo di ricerca o condivisione. Se si desiderano set di dati de-identificati, è necessario adottare misure per rendere anonimi i dati prima di esportarli, usando uno strumento come quello indicato in precedenza.

  6. Ulteriori analisi dei dati FHIR nei formati Parquet e JSON vengono eseguite usando i pool di Spark nei servizi Azure Synapse, Azure Databricks e Azure Machine Learning (ML).

  7. Le viste SQL vengono create nei pool SQL serverless in Azure Synapse. Viene creata una vista SQL per ogni risorsa FHIR basata sui file Parquet in Azure Data Lake. In base a queste viste, i data engineer e gli sviluppatori possono scrivere SQL nativo in Microsoft SQL Management Studio o in qualsiasi altro editor SQL per eseguire query sulle risorse FHIR.

  8. Power BI e il connettore Power Query per FHIR vengono usati per importare e modellare i dati direttamente dall'endpoint dell'API del servizio FHIR. Power BI offre anche connettori Parquet e SQL per l'accesso alla risorsa FHIR direttamente nel formato Parquet o tramite le viste SQL in Synapse.

Componenti

Dispositivi

Dispositivi consumer

Microsoft offre SDK open source per facilitare il trasferimento di dati da vari dispositivi consumer per l'inserimento da Hub eventi di Azure:

Dispositivi medici supportati da Life365.health

La piattaforma Life365.health è integrata con oltre 300 dispositivi di monitoraggio Bluetooth per l'inserimento da parte di Hub eventi di Azure. I dispositivi si estendono su più categorie e OEM, che vanno da spirometri, termometri, scale di peso, promemoria pillole, tracker di attività, misuratori di glucosio nel sangue, monitor di pressione sanguigna, EKG / ECG, doppler irreversibili, monitor di frequenza cardiaca, pulsossimetri, sleep tracker e altro ancora. L'app Life365 consente anche la registrazione manuale delle letture provenienti da dispositivi non Bluetooth. Questa architettura usa l'API Life365 per inserire le misurazioni del dispositivo dai dispositivi Life365 in Hub eventi.

Altro

Anche se le opzioni precedenti semplificano, questa architettura supporta qualsiasi origine dati simile che può essere inserita in modo sicuro in Hub eventi, direttamente o indirettamente tramite un'API intermedia.

Servizi di Azure (raccolta dati e archiviazione)

  • Hub eventi di Azure: servizio di inserimento dati in tempo reale completamente gestito, semplice, affidabile e scalabile. Consente di trasmettere in streaming milioni di eventi al secondo da qualsiasi origine per creare pipeline di dati dinamiche e rispondere immediatamente alle sfide aziendali. In questa architettura viene usata per raccogliere e aggregare i dati del dispositivo, per il trasferimento a Servizi per i dati sanitari di Azure.

  • Servizi per i dati sanitari di Azure è un set di servizi API gestiti basati su standard aperti e framework che consentono ai flussi di lavoro di migliorare i processi sanitari e offrono soluzioni scalabili e sicure per il settore sanitario. I servizi utilizzati in questa architettura includono:

    • Area di lavoro di Servizi per i dati sanitari di Azure: fornisce un contenitore per le altre istanze di Servizi per i dati sanitari di Azure, creando un limite di conformità (HIPAA, HITRUST) in cui le informazioni sanitarie protette possono viaggiare.

    • Servizio Azure FHIR: semplifica l'archiviazione e lo scambio sicuro di informazioni sanitarie protette nel cloud. I dati dei dispositivi vengono trasformati in risorse di osservazione basate su FHIR per supportare il monitoraggio remoto dei pazienti.

    • Servizio MedTech di Azure: elemento fondamentale di Microsoft Cloud for Healthcare, usato per supportare il monitoraggio remoto dei pazienti. MedTech è una piattaforma distribuita come servizio (PaaS) che consente di raccogliere dati quasi in tempo reale da dispositivi medici diversi e convertirli in un formato di servizio conforme a FHIR e archiviarli in un servizio FHIR. Le funzionalità di traduzione dei dati dei dispositivi del servizio MedTech consentono di trasformare un'ampia gamma di dati in un formato FHIR unificato che offre una gestione sicura dei dati sanitari in un ambiente cloud.

      Il servizio MedTech è importante per il monitoraggio remoto dei pazienti perché i dati sanitari possono essere difficili da accedere o analizzare quando provengono da dispositivi, sistemi o formati diversi o incompatibili. Le informazioni mediche che non sono facili da accedere possono essere una barriera per ottenere informazioni cliniche e un piano di assistenza sanitaria del paziente. La possibilità di convertire i dati di integrità in un formato FHIR unificato consente al servizio MedTech di collegare correttamente dispositivi, dati sanitari, lab e assistenza di persona remota. Di conseguenza, questa funzionalità può facilitare la scoperta di importanti informazioni cliniche e acquisizioni di tendenza, supportando il medico, il team di assistenza, il paziente e la famiglia. Può anche aiutare a stabilire connessioni a nuove applicazioni per dispositivi e abilitare progetti di ricerca avanzati. Proprio come i piani di assistenza possono essere individualizzati per caso d'uso, gli scenari di monitoraggio dei pazienti remoti e i casi d'uso possono variare in base alle esigenze individuali.

  • Griglia di eventi di Azure - il servizio eventi di Servizi sanitari di Azure genera eventi ogni volta che viene creata, aggiornata o eliminata una risorsa FHIR. Questi eventi possono essere trasmessi da Griglia di eventi di Azure ai consumer downstream per agire sui dati basati su eventi.

Servizi e strumenti di Azure (analisi dei dati)

  • Pipeline FHIR Analytics: un progetto OSS usato per compilare componenti e pipeline per la rettangolarizzazione e lo spostamento dei dati FHIR dai server FHIR di Azure ad Azure Data Lake. In questa architettura, i dati vengono convertiti in formato JSON (JavaScript Object Notation) e Parquet, rendendoli disponibili per l'analisi con vari servizi dati di Azure.

  • Strumenti per l'anonimizzazione dei dati sanitari: un progetto OSS supportato dal team di Microsoft Healthcare consente di rendere anonimi i dati sanitari, in locale o nel cloud, per l'utilizzo secondario, ad esempio ricerca, salute pubblica e altro ancora. Il motore di base per l'anonimizzazione usa un file di configurazione per specificare parametri diversi, nonché metodi di anonimizzazione per diversi elementi di dati e tipi di dati.

  • Azure Synapse Analytics: un servizio di analisi senza limiti che riunisce funzionalità di integrazione dei dati, archiviazione dati aziendali e analisi di Big Data. Offre la libertà di eseguire query sui dati in base alle tue esigenze, usando opzioni serverless o dedicate, su larga scala. Azure Synapse combina questi mondi grazie a un'esperienza unificata per l'inserimento, l'esplorazione, la preparazione, la trasformazione, la gestione e la distribuzione dei dati per esigenze immediate di business intelligence e apprendimento automatico.

  • Pool di Apache Spark: Apache Spark è un framework open source di elaborazione parallela che supporta l'elaborazione in memoria per migliorare le prestazioni di applicazioni analitiche di Big Data. Apache Spark in Azure Synapse Analytics è una delle implementazioni Microsoft di Apache Spark nel cloud. Azure Synapse semplifica la creazione e la configurazione di un pool di Apache Spark serverless in Azure. I pool di Spark in Azure Synapse sono compatibili con Archiviazione di Azure e Azure Data Lake Storage Gen2. È quindi possibile usare i pool di Spark per elaborare i dati archiviati in Azure.

  • Azure Databricks: piattaforma di analisi dei dati ottimizzata per la piattaforma di Servizi cloud di Microsoft Azure. Databricks fornisce una piattaforma di analisi unificata per analisti dei dati, ingegneri dei dati, data scientist e professionisti di Machine Learning. Per lo sviluppo delle applicazioni a elevato utilizzo di dati, vengono offerti tre ambienti: Databricks SQL, Databricks Data Science & Engineering e Databricks Machine Learning.

  • Azure ML: servizio cloud per accelerare e gestire il ciclo di vita del progetto di apprendimento automatico. I professionisti, gli scienziati dei dati e i tecnici dell'apprendimento automatico possono usarlo nei flussi di lavoro quotidiani: eseguire il training dei modelli e distribuirli e gestire le MLOps. È possibile creare un modello in Azure Machine Learning o usare un modello creato da una piattaforma open source come Pytorch, TensorFlow o scikit-learn. Gli strumenti MLOps consentono di monitorare, ripetere il training e ridistribuire i modelli.

  • Power BI: offre analisi self-service su scala aziendale, consentendo di:

    • Creare una cultura basata sui dati con business intelligence per tutti.
    • Mantenere i dati protetti con funzionalità di sicurezza dei dati leader del settore, tra cui l'etichettatura della riservatezza, la crittografia end-to-end e l'accesso in tempo reale monitoring usati per un'ulteriore analisi dei dati FHIR.

  • I connettori di Power Query usati con Power BI includono:

  • SQL Server Management Studio: un'app desktop usata per creare query SQL native su archivi dati SQL, ad esempio pool SQL di Azure Synapse Analytics.

Alternative

Life365.health

Il vantaggio di Life365.health è che con un punto di integrazione, è possibile eseguire il push delle misurazioni da un'ampia gamma di dispositivi nell'ecosistema Life365 in Servizi dati di integrità di Azure. Esistono altre API per dispositivi indossabili, ad esempio l'API Dell'attività Di Cluster e l'API Polar AccessLink, per cui è possibile ottenere un modello di integrazione simile. Tuttavia, queste API sono esclusive per la misurazione da dispositivi dei propri produttori, ad esempio Garmin e Polar, rispettivamente.

I dispositivi e i pazienti devono essere definiti, collegati e sincronizzati tra Servizi dati sanitari di Azure e l'API Life365. Questa configurazione può essere ottenuta sincronizzando gli ID paziente e dispositivo tra Servizi dati sanitari di Azure e l'API Life365. In sostanza, viene creato e collegato un nuovo paziente e dispositivo nel servizio Azure FHIR. Il paziente e il dispositivo corrispondenti vengono quindi creati e collegati nell'API Life365. Gli ID dei pazienti e dei dispositivi creati in Servizi dati sanitari di Azure verranno quindi aggiornati come ID esterni nelle rispettive entità paziente e dispositivo nell'API Life365.

Microsoft Cloud for HealthCare

Questo esempio di carico di lavoro consente di implementare una soluzione di monitoraggio dei pazienti remoti. Microsoft Cloud for Healthcare offre anche una soluzione di monitoraggio dei pazienti da remoto. Per maggiori informazioni su questa soluzione, vedere la panoramica guidata sul monitoraggio remoto dei pazienti.

Dettagli dello scenario

C'è un'abbondanza di dispositivi medici e indossabili/consumer oggi. Per accedere alle misurazioni/letture dei dispositivi, molti dei dispositivi di monitoraggio interni (ad esempio dispositivi di pressione sanguigna o scale) forniscono connettività Bluetooth (ad esempio Bluetooth Low Energy o altre versioni precedenti dello standard Bluetooth). Ci sono anche dispositivi indossabili consumer, nonché dispositivi interni più avanzati che forniscono connettività API per accedere alle misurazioni dei dispositivi. In questo caso, i dispositivi possono sincronizzare le letture direttamente con l'API (abilitata per Wi-Fi) o connettersi a un'app per dispositivi mobili (tramite Bluetooth), consentendo all'app di sincronizzare la lettura all'API.

Presentazione del problema

Data l'ampia gamma di dispositivi medici indossabili e in casa e opzioni di connettività (da Bluetooth a specifica API), moltiplicato per il numero di pazienti all'interno dell'organizzazione sanitaria, l'integrazione dei dati e l'orchestrazione possono diventare un compito scoraggiante.

Potenziali casi d'uso

  • Studi clinici e ricerche: aiutare i team di ricerca clinica a integrare e offrire una vasta gamma di dispositivi medici indossabili e interni al partecipante dello studio. In altre parole, offrire un'opzione quasi Bring-Your-Own-Device (BYOD) ai partecipanti allo studio.

  • Analisi dell'integrità dei dati e della popolazione: l'attività e i dati fisiologici saranno disponibili nel formato standard FHIR del settore, nonché altri formati di dati open source (JSON e Parquet). Oltre al formato dei dati, vengono forniti connettori nativi per facilitare l'analisi e la trasformazione dei dati. Inclusi connettori come il connettore Power BI per FHIR, le viste SQL serverless synapse e i cluster Spark in Synapse.

    Questa soluzione fornisce anche un metodo con parametri per rendere anonimo il set di dati per scopi di ricerca non identificati. Questo "uso secondario dei dati" può essere analizzato e usato per trovare le procedure consigliate e supportare flussi di lavoro clinici basati su prove. Le osservazioni archiviate nel server FHIR possono essere usate per trovare varianza e flussi di lavoro che promuovono i risultati e le procedure ottimali.

  • Abilitare i provider di servizi sanitari:: gli operatori saranno in grado di:

    • Ottenere informazioni più dettagliate sullo stato di salute dei pazienti
    • Creare modelli di assistenza sanitaria digitale proattiva per l'assistenza medica preventiva
    • Intraprendere azioni più informate in base agli indicatori fisiologici/notifiche
    • Fornire percorsi per il rimborso del monitoraggio fisiologico remoto

  • Questionari sui risultati segnalati dai pazienti (PRO) e assistenza guidata da PRO: usando eventi e questionari PRO, è possibile creare piani di assistenza individuali e flussi di lavoro di varianza delle cure. Il paziente può avere maggiore autonomia e controllo sul piano di assistenza individuale, che aiuta l'adozione e l'uso sostenuto. L'assistenza pro-driven può essere utile anche per risolvere il divario nell'istruzione e nei risultati dei pazienti. Collegando questionari per l'istruzione e PRO, RPM può essere usato per supportare farmaci, trattamenti e/o cure di follow up, rispondendo a domande come:

    • I pazienti prendono correttamente la BP?
    • La scalabilità è usata nel momento e alla frequenza corretti?
    • Stiamo eseguendo un ciclo in PRO per l'adozione dei pazienti e la pianificazione dell'assistenza individuale?

    Per i pazienti che usano dispositivi iOS, le app di questionario possono essere create usando Apple ResearchKit. I dati del questionario vengono inseriti da Hub eventi di Azure e resi disponibili tramite il servizio FHIR, proprio come l'attività del paziente dispositivo e i dati fisiologici.

  • Consentire più tipi e dispositivi sanitari più precisi: usare dispositivi medici e medici per generare dati sanitari quasi in tempo reale per l'inserimento e l'analisi dei dati.

Considerazioni

Queste considerazioni indirizzano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

La disponibilità di dati e informazioni clinici in tempo reale è fondamentale per molte organizzazioni sanitarie. Di seguito sono riportati alcuni modi per ridurre al minimo i tempi di inattività dei servizi di Azure indicati in questa soluzione:

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

I dati sanitari spesso includono informazioni sanitarie protette e informazioni personali riservate. Per proteggere questi dati sono disponibili le risorse seguenti:

  • Data Lake Storage usa il controllo degli accessi in base al ruolo (RBAC) di Azure e gli elenchi di controllo di accesso per creare un modello di controllo di accesso.

  • Servizi dati sanitari di Azure è una raccolta di servizi gestiti protetti che usano Microsoft Entra ID, un provider di identità globale che supporta OAuth 2.0. Quando si crea un nuovo servizio di Servizi per i dati sanitari di Azure, per impostazione predefinita i dati vengono crittografati usando chiavi gestite da Microsoft. Per maggiori dettagli, consultare la sezione Autenticazione e autorizzazione per Servizi dati sanitari di Azure .

  • Hub eventi di Azure fornisce la crittografia dei dati inattivi con Azure Storage Service Encryption (SSE).. Come tali, le regole IP Firewall possono essere applicate a livello dello spazio dei nomi di Hub eventi. È anche possibile configurare l'accesso agli endpoint privati e alla rete virtuale.

  • Synapse RBAC estende le funzionalità di Azure RBAC per le aree di lavoro Synapse e il relativo contenuto. Il controllo degli accessi in base al ruolo di Azure consente di gestire le autorizzazioni di chi può creare, aggiornare o eliminare l'area di lavoro di Synapse e i relativi pool SQL, pool di Apache Spark e runtime di integrazione.

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.

I prezzi per molti dei componenti di Azure sono disponibili in Calcolatore prezzi di Azure. In definitiva, i prezzi per questa soluzione si basano su fattori quali:

  • Servizi di Azure in uso.
  • Volume di dati, in termini di numero di pazienti/dispositivi e il numero di tipi di dati fisiologici e di attività inseriti.
  • Requisiti di capacità e velocità effettiva per Hub eventi.
  • Risorse di calcolo necessarie per eseguire il training e le distribuzioni di Machine Learning, pool di Spark synapse e cluster Databricks.
  • Soluzione di visualizzazione e creazione di report, ad esempio Power BI.

Quando si implementa questa soluzione, prendere in considerazione i criteri di conservazione e archiviazione dei dati per Azure Data Lake sottostante. Sfruttare la gestione del ciclo di vita di Azure Storage per offrire un modo automatizzato per:

  • transizione di BLOB di file fino al livello di accesso sporadico
  • livelli archivio in base all'ultima modifica del file.

Per maggiori informazioni sui piani e sui prezzi di Life365.health, consultare la sezione Life365 API Connect Data in Microsoft Azure Marketplace

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

Questa soluzione offre un'architettura scalabile quasi in tempo reale per il monitoraggio remoto dei pazienti. È importante riconoscere il flusso di dati multi-layer dall'interfaccia tra i dispositivi e l'API Life365, all'inserimento dall'API Life365 e Hub eventi di Azure, alla trasformazione nel servizio MedTech nel servizio dati di integrità di Azure e infine all'esportazione incrementale e all'anonimizzazione nel formato data lake. Di conseguenza, il flusso di dati verrà elaborato quasi in tempo reale e tutte le applicazioni downstream e/o le integrazioni devono essere progettate come tali. Tuttavia, le prestazioni di questa soluzione possono essere ridimensionate per offrire un numero elevato di dispositivi e pazienti a livello aziendale.

  • Questa soluzione sfrutta Hub eventi di Azure come punto di inserimento principale. La scalabilità di Hub eventi può essere gestita con unità elaborate, unità di elaborazione e unità di capacità. Di conseguenza, il partizionamento può essere utile per l'elaborazione di grandi volumi di eventi in Hub eventi.

  • La funzionalità di scalabilità automatica del pool di Apache Spark per Azure Synapse Analytics consente di aumentare o ridurre automaticamente il numero di nodi in un istanza del cluster.

  • Azure Machine Learning offre la distribuzione per l'inferenza con processori GPU e FPGA di Azure che consentono di ottenere una bassa latenza per l'inferenza in tempo reale.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Tecnologie e risorse rilevanti per l'implementazione di questa architettura: