Monitoraggio remoto dei pazienti

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

I sistemi sanitari, gli ospedali e le grandi procedure mediche stanno passando a iniziative ospedaliere a casa (noto anche come monitoraggio remoto dei pazienti). Il monitoraggio remoto dei pazienti è un subset 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 Azure Health Data Services e i dispositivi per il monitoraggio intelligente dei pazienti remoti. La soluzione aiuterà ad alleviare molte delle sfide di integrazione dei dispositivi associate all'organizzazione quando si crea una soluzione su larga scala.

Architettura

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

Scaricare un file di Visio di questa architettura.

Flusso di dati

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

  2. Life365.health platform supporta 300+ dispositivi che generano attività e dati fisiologici L'API Life365 inserisce l'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 Hub eventi, trasformandoli in formato FHIR Fast Healthcare Interoperability Resources (FHIR) e li 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 Azure Health Data Services invia messaggi di notifica ai sottoscrittori degli eventi quando viene creata una risorsa FHIR, aggiornata o eliminata nel servizio Azure FHIR. Le notifiche possono essere inviate a più endpoint per attivare l'automazione, tra cui l'avvio di flussi di lavoro o l'invio di messaggi di posta elettronica e di testo.

  5. FHIR Analytics Pipelines esporta in modo incrementale i dati FHIR non anonimi in Azure Data Lake, rendendolo disponibile per l'analisi con vari servizi dati di Azure. I dati esportati possono anche essere anonimi sfruttando strumenti come gli strumenti open source Microsoft per l'anonimato dei dati di integrità. 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 non vengono elaborati, che includono informazioni PHI. Il processo di de-identificazione può essere usato per rimuovere gli identificatori personali dai dati per scopi di ricerca o condivisione. Se si desidera identificare i set di dati non identificati, è necessario adottare misure per rendere anonimi i dati prima di esportarlo, usando uno strumento come quello indicato in precedenza.

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

  7. Le visualizzazioni SQL vengono create nei pool SQL serverless in Azure Synapse. Viene creata una visualizzazione SQL per ogni risorsa FHIR basata sui file Parquet in Azure Data Lake. In base a queste visualizzazioni, 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 accedere alla risorsa FHIR direttamente nel formato Parquet o tramite le visualizzazioni 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 OEMs, tra cui gli spirometri, i termometri, le scale di peso, i promemoria delle pillole, i contatori di attività, i misuratori di glucosio del sangue, i monitor di pressione sanguigna, EKG/ECG, i monitor doppler fetali, i monitoraggi della frequenza cardiaca, gli oximetri di impulsi, i tracker di sonno e altro ancora. L'app Life365 consente anche la registrazione manuale delle letture eseguite da dispositivi non Bluetooth. Questa architettura usa l'API Life365 per inserire le misurazioni dei dispositivi dai dispositivi Life365 in Hub eventi.

Altri

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

Servizi di Azure (raccolta dati e archiviazione)

  • Hub eventi di Azure: un servizio di inserimento dati completamente gestito, in tempo reale, semplice, attendibile 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 Azure Health Data Services.

  • Azure Health Data Services è un set di servizi API gestiti basati su standard e framework aperti che consentono ai flussi di lavoro di migliorare l'assistenza sanitaria e offrire soluzioni sanitarie scalabili e sicure. I servizi usati in questa architettura includono:

    • Area di lavoro di Azure Health Data Services : fornisce un contenitore per le altre istanze di Azure Health Data Services, creando un limite di conformità (HIPAA, HITRUST) in cui possono viaggiare informazioni sull'integrità protette.

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

    • Servizio Azure MedTech: una pietra chiave di Microsoft Cloud for Healthcare, usata per supportare il monitoraggio remoto dei pazienti. MedTech è un servizio paaS (Platform as a service) che consente di raccogliere dati quasi in tempo reale da dispositivi medici diversi e convertirli in un formato di servizio conforme a FHIR e archiviarlo in un servizio FHIR. Le funzionalità di traduzione dei dati dei dati del servizio MedTech consentono di trasformare un'ampia gamma di dati in un formato FHIR unificato che fornisce la gestione sicura dei dati di integrità 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 tradurre i dati di integrità in un formato FHIR unificato consente al servizio MedTech di collegare correttamente i dispositivi, i dati di integrità, i lab e l'assistenza remota in persona. Di conseguenza, questa funzionalità può facilitare l'individuazione di importanti informazioni cliniche e acquisizioni di tendenze, supportando il medico, il team di assistenza, il paziente e la famiglia. Può anche aiutare a creare connessioni alle nuove applicazioni del dispositivo e abilitare progetti di ricerca avanzati. Così come i piani di assistenza possono essere individuali per caso d'uso, scenari di monitoraggio dei pazienti remoti e casi d'uso possono variare per ogni singola necessità.

  • Griglia di eventi di Azure: il servizio eventi di Azure Health Data Services genera eventi ogni volta che viene creata una risorsa FHIR, aggiornata o eliminata (CUD). 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 di analisi FHIR : un progetto OSS usato per creare 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 JavaScript Object Notation (JSON) e Parquet , rendendoli disponibili per l'analisi con vari servizi dati di Azure.

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

  • Azure Synapse Analytics: un servizio di analisi senza limiti che riunisce l'integrazione dei dati, il data warehousing aziendale e l'analisi dei Big Data. Offre la libertà di eseguire query sui dati in base alle condizioni, usando opzioni serverless o dedicate, su larga scala. Azure Synapse riunisce questi mondi con un'esperienza unificata per inserire, preparare, preparare, trasformare, gestire e gestire i dati per esigenze immediate di BI e Machine Learning.

  • Pool di Apache Spark: Apache Spark è un framework di elaborazione parallela che supporta l'elaborazione in memoria per migliorare le prestazioni delle applicazioni di analisi 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 : una piattaforma di analisi dei dati ottimizzata per la piattaforma dei servizi cloud di Microsoft Azure. Databricks offre una piattaforma di analisi unificata per gli analisti dei dati, i tecnici dei dati, i data scientist e i tecnici di Machine Learning. Sono disponibili tre ambienti per lo sviluppo di applicazioni a elevato utilizzo di dati: Databricks SQL, Databricks Data Science & Engineering e Databricks Machine Learning.

  • Azure ML : un servizio cloud di Azure per accelerare e gestire il ciclo di vita del progetto di Machine Learning. I professionisti di Machine Learning, i data scientist e i tecnici possono usarli nei flussi di lavoro giornalieri: Eseguire il training e la distribuzione di modelli e gestire 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 larga scala aziendale, consentendo di:

    • Creare una cultura basata sui dati con business intelligence per tutti.
    • Mantenere i dati sicuri 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.is usato per un'ulteriore analisi dei dati FHIR.
  • Power Query connettori usati con Power BI includono:

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

Alternativi

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 Azure Health Data Services. Esistono altre API del dispositivo indossabili, ad esempio l'API Attività Garmin 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 Azure Health Data Services e l'API Life365. Questa configurazione può essere ottenuta sincronizzando gli ID del paziente e del dispositivo tra l'API Azure Health Data Services e 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 per la prima volta in Servizi dati di integrità di Azure verranno aggiornati come ID esterni nelle rispettive entità paziente e dispositivo nell'API Life365.

Microsoft Cloud for HealthCare

Questo carico di lavoro di esempio consente di implementare una soluzione di monitoraggio dei pazienti remota. Il Microsoft Cloud for Healthcare fornisce anche una soluzione di monitoraggio remoto dei pazienti. Per altre informazioni su questa soluzione, vedere la panoramica guidata sul monitoraggio remoto dei pazienti.

Dettagli dello scenario

C'è un'ampia quantità di dispositivi medici e indossabili/consumer là fuori oggi. Per accedere alle misurazioni/letture dei dispositivi, molti dei dispositivi di monitoraggio interno (ad esempio dispositivi di pressione sanguigna, scala... ecc.) fornire connettività Bluetooth (ad esempio Bluetooth Low Energy o altre versioni precedenti dello standard Bluetooth). Sono disponibili anche dispositivi indossabili consumer, oltre a 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 (Wifi abilitato) 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 domestici 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 un'ampia 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 dati, vengono forniti connettori nativi per facilitare l'analisi e la trasformazione dei dati. Inclusi i connettori, ad esempio il connettore Power BI per FHIR, le viste SQL serverless di Synapse e i cluster Spark in Synapse.

    Questa soluzione fornisce anche un metodo con parametri per rendere anonimo il set di dati a scopo di ricerca de-identificata. Questo "uso secondario dei dati" può essere analizzato e usato per trovare 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 : i provider 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 basata su PRO : usando eventi e questionari PRO, è possibile creare piani di assistenza individuali e flussi di lavoro di varianza di assistenza. Il paziente può avere maggiore autonomia e controllo sul piano di assistenza individuale, che aiuta l'adozione e l'uso sostenuto. La cura basata su PRO può essere utile anche per risolvere il divario nell'istruzione e nei risultati dei pazienti. Collegando questionari educativi e PRO, RPM può essere usato per supportare farmaci, trattamenti e/o assistenza di follow-up, rispondendo a domande quali:

    • I pazienti prendono correttamente la BP?
    • La scala usata al momento e alla frequenza corrette?
    • 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.

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

Considerazioni

Queste considerazioni riguardano 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 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 clinici e informazioni dettagliate è fondamentale per molte organizzazioni sanitarie. Ecco i 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 dei dati e dei 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 di Azure e gli elenchi di controllo di accesso (ACL) per creare un modello di controllo di accesso

  • Servizi dati di Integrità di Azure è una raccolta di servizi gestiti protetti tramite Azure Active Directory (Azure AD), 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 altre informazioni, vedere Autenticazione e autorizzazione per Servizi dati di integrità di Azure .

  • Hub eventi di Azure fornisce la crittografia dei dati inattivi con Crittografia del servizio di archiviazione di Azure(Azure SSE). Di conseguenza, le regole del firewall IP possono essere applicate a livello di spazio dei nomi di Hub eventi. È anche possibile configurare l'accesso agli endpoint privati e alla rete virtuale .

  • Il controllo degli accessi in base al ruolo di Synapse estende le funzionalità del controllo degli accessi in base al ruolo di Azure per le aree di lavoro di Synapse e il relativo contenuto. Il controllo degli accessi in base al ruolo di Azure viene usato per gestire chi può creare, aggiornare o eliminare l'area di lavoro 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 nel Calcolatore prezzi di Azure. In definitiva, i prezzi per questa soluzione si basano su fattori come:

  • Servizi di Azure in uso.
  • Volume di dati, in termini di numero di pazienti/dispositivi e il numero di attività e tipi di dati fisiologici 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.
  • La 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 Archiviazione di Azure per offrire un modo automatizzato per:

  • transizione di BLOB di file fino al livello di accesso sporadico
  • livelli di archiviazione basati sull'ultima modifica del file.

Per altre informazioni sui piani e i prezzi di Life365.health, vedere l'offerta Life365 API Connect Data in Microsoft Azure Marketplace

Efficienza delle prestazioni

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

Questa soluzione offre un'architettura quasi in tempo reale scalabile per il monitoraggio remoto dei pazienti. È importante riconoscere il flusso di dati a più livelli 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 qualsiasi applicazione downstream e/o integrazioni deve essere progettata come tale. Tuttavia, le prestazioni di questa soluzione possono essere ridimensionate a un numero elevato di dispositivi e pazienti a livello aziendale.

Autori di contributi

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

Autori principali:

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

Passaggi successivi

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