Sanità virtuale in Microsoft Cloud for Healthcare

Azure

Questo articolo illustra una potenziale soluzione per la pianificazione e il follow-up di visite virtuali tra pazienti, medici e care manager.

Architettura

Architettura per la visita virtuale con Microsoft Cloud for Healthcare

Scaricare un file di Visio contenente questo diagramma dell'architettura.

I riquadri blu in questo diagramma dell'architettura rappresentano i servizi Microsoft che costituiscono i servizi sottostanti o i componenti aggiuntivi necessari per Microsoft Cloud for Healthcare, ognuno dei quali deve essere concesso in licenza separatamente. Questi componenti insieme consentono di velocizzare lo sviluppo di soluzioni sanitarie integrate per il coinvolgimento dei pazienti, la collaborazione del team sanitario e il miglioramento delle informazioni dettagliate sui dati clinici e operativi.

I dati fluiscono nel sistema attraverso vari sistemi medici esterni, come pianificazioni di pazienti e medici, cartelle cliniche, dispositivi indossabili e così via. Questi dati vengono inseriti usando Azure. Vengono quindi archiviati in Microsoft Dataverse, un archivio dati basato su Power Apps Platform. Questi dati vengono formattati per l'uso di entità e relazioni tra di esse, create usando Common Data Model (CDM), uno standard di settore per rappresentare i dati medici. Tutte le interazioni tra paziente, medico e care manager si verificano usando questi dati CDM archiviati in Dataverse.

Un paziente stabilito può accedere in modo sicuro al portale del paziente, un sito Web ospitato nei portali Power Apps. In questo portale il paziente può parlare con un assistente intelligente. Si tratta di un'istanza del servizio Azure Health Bot, che raccoglie i sintomi, fornisce suggerimenti e consiglia di chiamare il medico, se necessario. Se il paziente sceglie di connettersi al proprio medico, l'istanza di Health Bot recupera i dati sui medici disponibili per le visite virtuali e le relative pianificazioni da Dataverse. Dopo che il paziente ha selezionato un medico e un orario, il bot visualizza le informazioni di contatto ottenute dai dati EMR/EHR archiviati in Dataverse. Il paziente può convalidare o modificare queste informazioni e salvare i dati usando il bot.

Per pianificare un appuntamento, l'istanza di Health Bot si connette all'app Bookings usando l'API Microsoft Graph e prenota un appuntamento nel calendario del medico. Un messaggio di posta elettronica con le informazioni sull'appuntamento viene inviato a entrambe le parti utilizzando Microsoft Outlook. Al paziente vengono fornite le istruzioni per accedere al portale del paziente per il processo di iscrizione. Questo processo prevede la conferma o la modifica delle informazioni di contatto, pagamento e assicurazione e quindi la firma di un modulo di consenso per la visita virtuale. Dopo aver firmato il consenso, viene fornito il collegamento di Microsoft Teams per l'appuntamento.

Il medico accede a Teams per controllare la pianificazione degli appuntamenti e le informazioni di riepilogo per ognuno. Teams visualizza queste informazioni usando l'applicazione Appointment Queue. Il medico può quindi iniziare la visita virtuale in Teams per l'appuntamento pianificato. Durante la chiamata, il medico può prendere appunti e aggiungerli alla cartella del paziente.

Una nuova nota sulla cartella clinica del paziente attiva una notifica di revisione per il care manager assegnato al paziente. Quando il care manager riceve questa notifica, può accedere a Teams, dove può vedere i pazienti a lui assegnati e visualizzare le note. Tramite l'app Care Management, può apportare le modifiche necessarie al piano di cura del paziente.

Componenti

Questa architettura è costituita dai componenti seguenti:

  • PAS. I Patient Administration System (PAS) sono sistemi che automatizzano i documenti amministrativi nelle organizzazioni sanitarie, come gli ospedali. Sono i componenti principali dell'infrastruttura IT di un'organizzazione di questo tipo. Un PAS registra i dati demografici del paziente, come il nome, l'indirizzo di casa, la data di nascita e così via. Registra anche informazioni dettagliate su tutti i contatti che il paziente ha avuto con l'ospedale, sia ambulatoriali che ospedalieri. Con l'aiuto di PAS, gli ospedali moderni possono segnalare e pianificare le risorse in tutta l'organizzazione. PAS è un'origine chiave di dati di pianificazione in questa soluzione. Poiché questi dati sono esterni e possono essere in un formato non standard, è importante convertirli in un formato compreso da tutti i componenti di questa soluzione.

  • EMR/EHR. I record medici elettronici (EMR) e i record sanitari elettronici (EHR) forniscono le registrazioni digitali delle informazioni mediche e sanitarie di un paziente, tra cui diagnosi, farmaci, immunizzazioni e così via. Possono essere destinate a un singolo studio medico, come le EMR, o progettate per avere un ambito molto più ampio, viaggiando con i pazienti in qualsiasi struttura vadano, come le EHR. Si tratta di origini dati esterne importanti in questa soluzione e possono essere non strutturate in formato non standard. Di conseguenza, questi dati devono essere convertiti in un formato che possa essere usato dai componenti di questa soluzione.

  • API di Azure per FHIR. Azure è il primo passaggio del processo di integrazione dei dati nell'ecosistema Microsoft e in Microsoft Cloud for Healthcare. Questo livello fornisce un'interfaccia sicura tra i dati esterni e i componenti interni di questa architettura. L'API di Azure per FHIR inserisce i dati provenienti da origini diverse come EMR, PAS, dispositivi, sia strutturati che non strutturati, li converte in FHIR e li salva in modo permanente in Azure. Questi dati possono quindi essere usati in Microsoft Cloud for Healthcare per diversi servizi. L'API di Azure per FHIR è stata creata tenendo conto della sicurezza e della conformità ed è stata progettata per i dati PHI (Protected Health Information). Per altre informazioni su questo livello, vedere Azure per il settore sanitario e l'API di Azure per FHIR

  • Common Data Model. Con Common Data Model, Microsoft fornisce un sistema di definizione dei metadati standardizzato estendibile e personalizzabile per esigenze aziendali specifiche. Le entità CDM sono disponibili per aree tematiche come CRM, Healthcare, Talent e così via. Per informazioni dettagliate, vedere le informazioni sull'utilizzo di Common Data Model. Oltre a queste entità, i clienti possono inserire dati proprietari definendo la tabella di entità e i campi sottostanti nel Common Data Model, che possono quindi essere usati facilmente con altre entità in tutta la soluzione.

  • Microsoft Dataverse. Dataverse, un database relazionale su cui si basa Microsoft Dynamics 365, è il repository per i dati rappresentati nel Common Data Model. Contiene i database per le informazioni sui pazienti, contenenti dettagli sui nomi, informazioni sulla famiglia, condizioni mediche, anamnesi farmacologica e così via. Contiene anche le informazioni ottenute da tutti i dispositivi indossabili usati e registrati dai pazienti, nonché i dati di pianificazione e gestione dell'organizzazione sanitaria. Questi dati vengono definiti usando il Common Data Model.

  • Portale del paziente. Questo portale di Power Apps consente ai pazienti di visualizzare le cartelle cliniche, prenotare appuntamenti, chattare con l'istanza di Health Bot e così via e può essere esteso per supportare altri dati. Il portale fa parte di Microsoft Cloud for Healthcare e consente di creare facilmente un portale, che può connettersi con entità in Dataverse, inserendo dati come informazioni sui pazienti, piani di cura, appuntamenti e così via.

  • Assistenza intelligente. Si tratta di un'istanza del servizio Azure Health Bot, accessibile ai pazienti tramite il portale del paziente. Questa istanza di Health Bot viene caricata all'interno di un sito Web del Servizio app di Azure. È personalizzabile e può essere programmata usando gli scenari richiesti dai clienti.

  • App Bookings. L'app Bookings è un servizio di Microsoft 365, incluso in Microsoft Cloud for Healthcare. Facilita la pianificazione degli eventi del calendario e consente di creare riunioni di Teams.

  • Microsoft Outlook. Questa soluzione usa Microsoft Outlook come client di posta elettronica. L'app Bookings che invia la notifica di posta elettronica è integrata con Outlook. In alternativa, è possibile usare il client di posta elettronica preferito dell'operatore sanitario.

  • Microsoft Teams. Microsoft Teams è un componente di Microsoft Cloud for Healthcare e fornisce il front-end per le interazioni tra i pazienti, i provider e i responsabili dell'assistenza. Gli utenti possono usare una versione installata localmente o la versione Web. Per altre informazioni su Teams, vedere la documentazione di Microsoft Teams.

  • Appointment Queue. Questo strumento genera una pagina HTML con i dati estratti da Dataverse usando l'API Web di Dynamics 365. Fornisce al medico le informazioni sugli appuntamenti pianificati per la giornata e il riepilogo di ognuno. Fornisce anche un collegamento per accedere alle informazioni sul paziente tramite l'applicazione Care Management. Appointment Queue è stato sviluppato per supportare questo scenario e non fa parte di Microsoft Cloud for Healthcare. Le origini dati per questo strumento sono principalmente i sistemi PAS e i record EMR/EHR. Se questi sistemi dispongono di strumenti integrati per visualizzare questi dati, tali strumenti possono sostituire questo componente in una distribuzione effettiva.

  • Care Management. Lo strumento Care Management è un componente di Microsoft Cloud for Healthcare. È un'applicazione di Power Apps distribuita tramite Dynamics 365. Inserisce i dati dei pazienti EMR/EHR archiviati in Dataverse in formato CDM e presenta una vista aggregata in Teams. La soluzione di un centro di cura potrebbe scegliere di usare il proprio sistema per le relative funzionalità, a seconda di come si vuole visualizzare queste informazioni.

  • Power BI Analytics. Si tratta di uno strumento di analisi creato per questo scenario e non è disponibile con Microsoft Cloud for Healthcare. In questa soluzione genera informazioni derivate dai dispositivi IoMT del paziente. Possono trattarsi di dati come la frequenza cardiaca, il livello di ossigeno nel sangue e così via. L'app Care Management usa questi dati per fornire ai medici informazioni dettagliate aggiuntive sui pazienti in base alle attività quotidiane.

  • Dispositivi connessi. Si tratta di dispositivi IoMT (Internet of Medical Things), ovvero dispositivi intelligenti per uso medico o sanitario. Tra gli esempi di dispositivi IoMT sono inclusi dispositivi indossabili, come Apple Watch o Fitbit, monitor medici o vitali e così via. I pazienti possono effettuare il provisioning dei propri dispositivi tramite Azure e scegliere di consentire al sistema di gestione dell'assistenza sanitaria di raccogliere questi dati IoMT per l'uso da parte dei medici. I medici possono ottenere ulteriori informazioni da tali dispositivi, quasi in tempo reale, e collegare anomalie come una frequenza cardiaca elevata per un periodo di tempo con i sintomi attuali del paziente.

  • Automazione con Power Automate. Si tratta di uno strumento personalizzato creato per supportare questo scenario e non è disponibile con Microsoft Cloud for Healthcare. Poiché si tratta di uno scenario di visita virtuale, il medico potrebbe essere solo un medico di guardia e non il medico abituale del paziente. Questo strumento consente alle note del medico di attivare una notifica Teams al care manager. Un care manager è un membro del team medico che funge da collegamento tra il medico di base e il paziente e si occupa della gestione dell'assistenza a lungo termine. Una notifica inviata al care manager, indicando l'aggiunta di nuove note per il paziente, gli consente di rivedere e apportare le modifiche appropriate nella gestione dell'assistenza del paziente dopo la visita.

Alternative

I servizi di Azure per il settore sanitario quali API di Azure per FHIR e Azure Health Bot, l'interfaccia Common Data Model, Microsoft Dataverse e Microsoft Teams costituiscono i componenti principali di questa soluzione. La maggior parte degli altri componenti di questo sistema può essere sostituita da sistemi attualmente usati dalla struttura sanitaria:

  • Se il sistema EMR/EHR è dotato di componenti predefiniti per la prenotazione, la pianificazione e la gestione dell'assistenza, è possibile usare questi componenti anziché i componenti corrispondenti in questa soluzione.

  • Le pianificazioni e le notifiche tramite posta elettronica di Bookings e Outlook possono essere sostituite dai sistemi usati dalla struttura sanitaria. Queste operazioni possono essere eseguite tramite il sistema EHR o usando un'applicazione di terze parti. L'applicazione deve fornire un'API che l'istanza di Health Bot può usare per creare e pianificare appuntamenti, oltre alla possibilità di creare riunioni virtuali.

  • Se il medico ha già un portale per i pazienti implementato tramite il proprio sistema EMR/EHR, può essere usato al posto del portale del paziente. È facile integrare un componente esterno di questo tipo con tale soluzione, perché questi componenti usano interfacce standard, ad esempio un'interfaccia iFrame per comunicare con l'istanza di Health Bot. I componenti che supportano questo flusso possono essere creati nel portale proprietario, come il modulo di consenso che il paziente deve firmare prima di partecipare alla riunione di Teams.

  • È opportuno sottolineare che una distribuzione effettiva richiederà strumenti sostitutivi per alcuni componenti di questa soluzione, come Appointment Queue, le notifiche automatizzate e gli strumenti di analisi di Power BI. Questi componenti dovranno essere creati e personalizzati in base alle esigenze aziendali dell'operatore sanitario.

Dettagli dello scenario

Nell'attuale pandemia di COVID-19 (coronavirus), molti pazienti potrebbero preferire visitare il proprio medico virtualmente anziché di persona, quando possibile. Migliorare le informazioni cliniche e operative nel settore sanitario diventa importante in un mondo virtuale di questo tipo. Ciò include la connessione dei dati da sistemi diversi, la creazione di informazioni dettagliate per prevedere i rischi e contribuire a migliorare l'assistenza ai pazienti, la garanzia di qualità e l'efficienza operativa.

La base di questa soluzione è Microsoft Cloud for Healthcare. Microsoft Cloud for Healthcare riunisce funzionalità attendibili di Microsoft 365, Azure, Dynamics 365, Power Platform e l'ampio ecosistema di partner Microsoft per aiutare le organizzazioni sanitarie a creare soluzioni sanitarie rapide, efficienti e sicure.

Potenziali casi d'uso

Questa soluzione è mirata a fornire assistenza virtuale ai pazienti nell'attuale pandemia. Tuttavia, gli operatori sanitari possono applicarla facilmente agli scenari seguenti:

  • Pianificazione di follow-up virtuali per le visite di persona.

  • Offerta di assistenza medica non di emergenza ai pazienti durante il viaggio.

Considerazioni

Queste considerazioni implementano 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.

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.

Poiché il sistema è basato sui dati dei pazienti, quando si sviluppa questa soluzione è necessario applicare considerazioni di sicurezza di base per le informazioni private:

  • Solo i dati necessari devono passare attraverso il sistema in un determinato momento. Ad esempio, inserire solo i dati dei sistemi EMR/EHR necessari per la pianificazione e la gestione delle visite virtuali. Rivedere le regole di conformità HIPAA stabilite per indicazioni su dove archiviare i dati dei pazienti, su come usarli e su chi deve accedervi. Tenere presente l'importanza della conformità nel settore sanitario durante lo sviluppo della soluzione. Per altre indicazioni, vedere Conformità in Microsoft Cloud for Healthcare.

  • Solo il personale autorizzato deve avere accesso ai dati dei pazienti e solo ai dati necessari per il proprio ruolo. In vari punti del sistema, come Care Management e le analisi incluse, Appointment Queue o i sistemi di notifica, è necessario fare attenzione ad autenticare e autorizzare il personale e limitare l'accesso solo alle informazioni necessarie sul paziente.

  • I moduli che interagiscono con i pazienti, come l'Assistenza intelligente e l'app Bookings, ricevono, archiviano e usano i dati dei pazienti. Un controllo e un'autenticazione appropriati degli accessi in questi moduli assicurano la gestione dei problemi di privacy.

A causa della natura dei dati privati coinvolti, la sicurezza e la conformità costituiscono i principi di base di Microsoft Cloud for Healthcare.

Questo esempio si basa anche sulle regole di sicurezza impostate da Dynamics 365 e Teams:

I singoli servizi inclusi in Microsoft Cloud for Healthcare forniscono il proprio livello di sicurezza e conformità:

Per i controlli di sicurezza personalizzati, è consigliabile usare Microsoft Entra ID e il controllo degli accessi in base al ruolo.

Infine, quando si implementa questa soluzione, tenere presenti le procedure consigliate e le linee guida per lo sviluppo di soluzioni di Azure sicure.

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 informazioni dettagliate sui prezzi di Microsoft Cloud for Healthcare, vedere Come acquistare Microsoft Cloud for Healthcare. I componenti che costituiscono Microsoft Cloud for Healthcare hanno requisiti di licenza propri, ad esempio:

Per ricreare in questa architettura i componenti personalizzati, prendere in considerazione le informazioni sui prezzi per i servizi sottostanti che si sceglie di usare.

Distribuire lo scenario

La soluzione deve essere distribuita in più fasi:

  1. Alcuni prodotti/servizi devono essere installati come prerequisiti per Microsoft Cloud for Healthcare. Vedere l'elenco dettagliato in questo articolo sui requisiti di licenza.

  2. Microsoft Cloud for Healthcare può essere distribuito usando le istruzioni fornite in Distribuire le soluzioni di Microsoft Cloud for Healthcare basate su Dynamics 365.

  3. Microsoft Cloud for Healthcare fornisce i componenti di base per iniziare subito a creare una soluzione sanitaria virtuale, ad esempio portale del paziente, Teams, Bookings e così via. I dati che verranno usati per creare questi blocchi predefiniti devono essere personalizzati in base alle esigenze aziendali.

  4. I componenti disponibili in Microsoft Cloud for Healthcare e i relativi prerequisiti devono essere personalizzati per supportare le esigenze aziendali:

    1. È necessario creare flussi di Power Automate per supportare le notifiche del care manager.

    2. È necessario configurare il portale del paziente. Potrebbe essere necessario creare moduli aggiuntivi per elementi come i moduli di registrazione/consenso. Per altre informazioni, vedere Configurare un portale di accesso del paziente.

    3. Il servizio Azure Health Bot deve essere connesso al database Dataverse e personalizzato per la comunicazione con i pazienti. Per altre informazioni, vedere Configurare chat automatiche con Microsoft Health Bot.

    4. Vedere Configurare la sincronizzazione con i dati clinici usando l'agente di sincronizzazione FHIR di Azure e Incorporare i report di Power BI per l'analisi per comprendere altre configurazioni che potrebbero essere necessarie.

  5. I componenti aggiuntivi creati specificamente per questa soluzione non sono disponibili per l'utilizzo a livello di produzione. La struttura sanitaria potrebbe dover creare la propria versione di queste applicazioni:

    1. Appointment Queue

    2. Notifiche automatizzate con Power Automate

    3. Applicazione per la creazione di report con Power BI

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