Modifica

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 dati di integrità 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

Architecture diagram of remote patient monitoring architecture using healthcare devices and Azure services.

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 Hub 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 sull'integrità. L'anonimizzazione predefinita si basa sul metodo HIPAA Cassaforte 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. Altre 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:

  • Fitbit on FHIR OSS SDK supporta i dispositivi Fitbit.
  • Fit on FHIR OSS SDK supporta i dispositivi Google Fit.
  • HealthKitToFhir Swift Library OSS SDK supporta i dispositivi Apple.

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 sppirometri, 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, impulsi oximetri, tracker sonno 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 completamente gestito e 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 Servizi dati di integrità di Azure.

  • Servizi dati di Integrità di Azure è un set di servizi API gestiti basati su standard e framework aperti che consentono ai flussi di lavoro di migliorare il settore sanitario e offrire soluzioni sanitarie scalabili e sicure. I servizi usati in questa architettura includono:

    • Area di lavoro di Servizi dati di Integrità di Azure: fornisce un contenitore per le altre istanze di Servizi dati di integrità 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 Azure MedTech: un 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 dati di Integrità 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 di analisi FHIR: 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 sull'integrità : 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 illimitato 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 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 di elaborazione parallela che supporta l'elaborazione in memoria per migliorare le prestazioni delle 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 dei servizi cloud di Microsoft Azure. Databricks offre una piattaforma di analisi unificata per analisti dei dati, data engineer, data scientist e ingegneri 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 quotidiani: 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 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.is usati per un'ulteriore analisi dei dati FHIR.

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

    • Connettore di origine dati file Parquet: usato per accedere ai dati del file Parquet di Azure Data Lake.
    • Connettore Power Query per FHIR : usato per importare e modellare i dati da un server FHIR.
    • Connettore dell'origine dati SQL di Azure Synapse Analytics: usato per la creazione di query SQL su Azure Synapse Analytics.

  • 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 La Classe 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 paziente e dispositivo tra Azure Health Data Services e Life365 API. 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 Azure Health Data Services 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 remota. Per altre 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 là fuori oggi. Per accedere alle misurazioni/letture dei dispositivi, molti dei dispositivi di monitoraggio interni (ad esempio dispositivi di pressione sanguigna, scala... ecc.) fornire 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: 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 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 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 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 Framework ben progettato di Microsoft Azure.

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 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 Archiviazione 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 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 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 S edizione Standard). 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 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 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 Archiviazione di Azure gestione del ciclo di vita per offrire un modo automatizzato per:

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

Per altre informazioni sui piani e sui prezzi di Life365.health, vedere l'offerta Life365 API Connessione 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 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 ridimensiona automaticamente il numero di nodi in un'istanza del cluster verso l'alto e verso il basso.

  • 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: