In questo articolo viene descritta un'architettura di esempio di un portale digitale di servizi sanitari rivolto ai consumatori su Azure, che può facilitare la comunicazione tra operatori sanitari e pazienti. Inoltre, questa piattaforma può archiviare cartelle cliniche, immagini di diagnostica, consentire al paziente di tenere traccia dei dati sanitari e altro ancora.
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
- Questa soluzione usa il footprint globale delle funzionalità di sicurezza di Frontdoor di Azure e perimetrali di Web application firewall di Azure (WAF) per autenticare i dati in ingresso.
- I dati autenticati vengono quindi instradati da Gestione API di Azure all'interfaccia front-end per gli utenti in Servizio app di Azure o alle API ospitate in Funzioni di Azure.
Il servizio dati back-end primario usato in questa architettura è Azure Cosmos DB. Le capacità multi-modello di Azure Cosmos DB, oltre alla scalabilità e alla sicurezza, garantiscono la flessibilità per qualsiasi tipo di portale di servizi sanitari rivolto ai consumatori. Tutti i dati che non sono in un formato record vengono archiviati in Archiviazione BLOB di Azure come oggetto. Questi dati possono includere immagini mediche, foto scattate dal consumatore, documenti caricati, dati archiviati e così via. L'archiviazione BLOB offre una risorsa di archiviazione conveniente per grandi volumi di dati non strutturati. Questo tipo di dati non è ottimizzato per l'archiviazione in Azure Cosmos DB e può influire negativamente sui costi e sulle prestazioni di questo servizio.
Componenti
AZURE HIPAA HITRUST 9.2 è un progetto di Azure che usa Criteri di Azure. Consente di valutare i controlli HIPAA HITRUST 9.2 e di distribuire un set di criteri di base per i carichi di lavoro di Azure. Anche se non è garantita una copertura di conformità completa per HIPAA HITRUST, è un ottimo punto di partenza e aggiunta di altri controlli, se applicabili e necessari. La conformità alle iniziative dei criteri può essere anche visualizzata in questo progetto e nell'interfaccia di Microsoft Defender for Cloud.
Frontdoor di Azure, che viene usato per gestire il traffico perimetrale su larga scala e per migliorare le prestazioni per gli utenti finali presentando endpoint in tutto il mondo. Questa tecnologia è nativa del cloud, non richiede quindi alcuna licenza, ma i costi vengono addebitati in base al consumo. In questo scenario di carico di lavoro, Frontdoor di Azure funge da punto di ingresso per tutto il traffico verso il portale di servizi sanitari rivolto ai consumatori.
Web application firewall di Azure, che protegge le applicazioni da attacchi comuni basati sul Web, ad esempio vulnerabilità OWASP, SQL injection, scripting intersito e altro ancora. Questa tecnologia è nativa del cloud, non richiede quindi alcuna licenza, e i costi vengono addebitati in base al consumo.
Gestione API di Azure, che supporta la pubblicazione, il routing, la protezione, la registrazione e l'analisi delle API. Indipendentemente dal fatto che l'API venga usata solo dall'utente finale o integrata con terze parti per l'interoperabilità esterna, Gestione API garantisce flessibilità nel modo in cui le API vengono estese e presentate.
Servizio app di Azure, ovvero un servizio usato per ospitare servizi Web basati su HTTP. Supporta un'ampia gamma di linguaggi, può essere eseguito in Linux o Windows, si integra completamente con pipeline CI/CD e può anche eseguire carichi di lavoro contenitore come offerta PaaS. Servizio app consente sia la scalabilità verticale che la scalabilità orizzontale, oltre all'integrazione nativa con i servizi di identità, sicurezza e registrazione in Azure. È in grado di soddisfare le esigenze di scalabilità del portale di servizi sanitari rivolto ai consumatori mantenendo al tempo stesso la conformità. In questa architettura, ospita il portale Web front-end.
App per le funzioni di Azure, ovvero una soluzione di piattaforma serverless in Azure che consente agli sviluppatori di scrivere codice di calcolo su richiesta, senza dover gestire i sistemi sottostanti. In questa architettura, Funzioni di Azure può ospitare API e qualsiasi operazione che deve essere eseguita in modo asincrono, ad esempio l'esecuzione di processi periodici e il calcolo di statistiche in un determinato periodo di tempo.
Azure Cosmos DB, ovvero un database NoSQL completamente gestito e multi-modello che offre tempi di risposta a una sola cifra e garantisce prestazioni su qualsiasi scala. Ogni utente nel sistema di servizi sanitari rivolto ai consumatori visualizzerà solo dati personali. Questo aspetto giustifica l'uso di una struttura di dati NoSQL. Azure Cosmos DB offre scalabilità quasi illimitata, nonché funzionalità di lettura e scrittura multi-area. Con la drastica crescita della quantità di dati raccolti da questi tipi di sistemi di servizi sanitari rivolti ai consumatori, Azure Cosmos DB può fornire sicurezza, velocità e scalabilità appropriate, indipendentemente dal fatto che siano presenti 100 o 1.000.000 di utenti attivi.
Azure Key Vault, che è un servizio nativo di Azure usato per archiviare e accedere in modo sicuro a segreti, chiavi e certificati. Key Vault offre la sicurezza supportata da HSM e l'accesso con i controlli degli accessi in base al ruolo integrati in Microsoft Entra. Le applicazioni non devono mai archiviare chiavi o segreti in locale. Questa architettura usa Azure Key Vault per archiviare tutti i segreti, ad esempio chiavi API, password, chiavi crittografiche e certificati.
Azure Active Directory B2C, che offre identità business-to-consumer come servizio su vasta scala, il cui costo si ridimensiona insieme al numero di utenti attivi. Nelle applicazioni rivolte ai consumatori come questa soluzione, invece di creare un nuovo account, gli utenti potrebbero voler portare la propria identità. Può trattarsi di qualsiasi elemento, da un ID di social network, a un account di posta elettronica o a qualsiasi servizio di identità del provider SAML. Questo metodo offre un'esperienza di onboarding più semplice per l'utente. Il provider di soluzioni deve solo fare riferimento alle identità utente e non deve ospitarle e gestirle.
Azure Log Analytics, uno strumento di Monitoraggio di Azure, può essere usato per informazioni di diagnostica o registrazione e per eseguire query su questi dati per ordinarli, filtrarli o visualizzarli. Questo servizio ha un prezzo in base al consumo ed è ideale per ospitare i log di diagnostica e di utilizzo di tutti i servizi in questa soluzione.
Azure Application Insights, un'altra funzionalità di Monitoraggio di Azure, è il servizio Application Performance Management nativo in Azure. Può essere facilmente integrato nel servizio app front-end e in tutto il codice di Funzioni di Azure per abilitare il monitoraggio in tempo reale delle applicazioni. Application Insights può rilevare facilmente le prestazioni, le anomalie di usabilità e gli errori generati direttamente dalle applicazioni stesse e non solo dalla piattaforma di calcolo che le ospita.
I Servizi di comunicazione di Azure sono servizi basati sul cloud per cui sono disponibili API REST ed SDK delle librerie client per supportare l'integrazione delle comunicazioni nelle applicazioni. È possibile aggiungere comunicazioni alle applicazioni senza essere esperti delle tecnologie sottostanti, come ad esempio la codifica di contenuti multimediali o la telefonia. In questa soluzione, può essere usato per inviare messaggi di posta elettronica, di testo o telefonate automatiche correlati al portale di servizi sanitari rivolto ai consumatori, ad esempio conferme di appuntamenti o promemoria.
Hub di notifica di Azure, che è un motore di notifica push semplice e scalabile che consente di inviare notifiche a qualsiasi piattaforma mobile. Un portale di servizi sanitari rivolto ai consumatori, che usa un'app per dispositivi mobili, può integrarsi con Hub di notifica di Azure in modo conveniente per inviare notifiche push agli utenti che hanno installato l'app nei propri dispositivi mobili. In questa architettura, è possibile inviare notifiche per ricordare agli utenti gli appuntamenti, immettere informazioni per i dispositivi disconnessi, raggiungere determinati obiettivi di salute e così via.
Microsoft Defender per il cloud) è il nucleo del monitoraggio e della gestione della postura di sicurezza per questa soluzione nativa del cloud. Microsoft Defender for Cloud si integra con quasi tutti i principali servizi nella piattaforma Azure. Le funzionalità includono avvisi di sicurezza, rilevamento delle anomalie, raccomandazioni sulle procedure consigliate, punteggi di conformità alle normative e rilevamento delle minacce. Oltre al monitoraggio della conformità HIPAA/HITRUST e al monitoraggio generale delle procedure consigliate per la sicurezza di Azure, questa soluzione usa i set di funzionalità seguenti:
Alternative
Il Servizio FHIR di Azure nell'ambito dei Servizi per i dati sanitari di Azure può essere usato per l'interoperabilità delle cartelle cliniche usando gli standard di comunicazione HL7 o FHIR. Questo servizio deve essere usato se l'applicazione deve ricevere o trasmettere cartelle cliniche da altri sistemi. Ad esempio, se questa soluzione fosse un portale per i provider di servizi medici, API di Azure per FHIR potrebbe integrarsi direttamente con il sistema di cartelle cliniche elettroniche del provider.
Hub IoT di Azure, ovvero un servizio ottimizzato per l'inserimento dei dati del dispositivo. Se il portale è il front-end per una soluzione che raccoglie dati da un dispositivo indossabile o da qualsiasi altro dispositivo medicale, è consigliabile usare l'hub IoT per inserire questi dati. Per altre informazioni, leggere il processo INGEST dell'architettura Soluzioni per il monitoraggio remoto dei pazienti.
Email di Microsoft 365 è un servizio leader del settore usato per la posta elettronica e le comunicazioni. Molte organizzazioni hanno già investito in questo servizio, che può essere usato come alternativa ai Servizi di comunicazione di Azure più completi. In questa soluzione, può essere usato per inviare messaggi di posta elettronica correlati al portale di servizi sanitari rivolto ai consumatori, ad esempio messaggi di posta elettronica di conferma di appuntamenti o promemoria.
Dettagli dello scenario
Nel settore sanitario e life science, le organizzazioni stanno adottando strategie di salute digitale. Uno dei principali pilastri e un componente fondamentale di una soluzione di salute digitale è un portale di servizi sanitari rivolto ai consumatori. Un portale di servizi sanitari rivolto ai consumatori può essere usato per tenere traccia dello stato di avanzamento e delle statistiche di un dispositivo indossabile, per interagire con un provider di servizi medici o persino per tenere traccia delle abitudini alimentari salutari.
Potenziali casi d'uso
- Tenere traccia delle statistiche di un dispositivo indossabile.
- Ottenere l'accesso alle cartelle cliniche e interagire con un provider di servizi medici.
- Immettere tempi e dosi di farmaci, che possono essere usati per il riempimento dei dati o il rilevamento automatico dei farmaci.
- Interagire con un coach di alimentazione salutare per la perdita di peso o il diabete.
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.
Disponibilità
Questa soluzione è attualmente progettata come distribuzione in una singola area. Se lo scenario richiede una distribuzione in più aree per la disponibilità elevata, il ripristino di emergenza o anche la prossimità, può essere necessaria un'area di Azure associata con le configurazioni seguenti.
Azure Cosmos DB viene esteso per abilitare una configurazione multi-area.
Gestione API di Azure viene distribuito usando CI/CD in un'area secondaria. È anche possibile applicare la funzionalità di distribuzione in più aree di Gestione API.
Servizio app di Azure e Funzioni di Azure vengono distribuiti separatamente in più aree. Questa distribuzione può essere eseguita all'interno della pipeline CI/CD creando una distribuzione parallela. Per altre informazioni, vedere Applicazione Web a disponibilità elevata in più aree geografiche.
A seconda dei requisiti dell'obiettivo del tempo di ripristino, il servizio Archiviazione BLOB di Azure può essere configurato come archiviazione con ridondanza geografica o archiviazione con ridondanza geografica e accesso in lettura che consente le operazioni di lettura direttamente dall'area alternativa. Per altre informazioni, vedere l'articolo Ridondanza di Archiviazione di Azure.
Nel servizio Azure Key Vault sono integrati più livelli di disponibilità e ridondanza.
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.
Le sezioni seguenti descrivono le procedure consigliate per la sicurezza per ognuno dei servizi usati in questa soluzione.
Frontdoor di Azure
Il web application firewall di Frontdoor di Azure dovrebbe essere usato per attenuare molti attacchi comuni diversi. Un buon punto di partenza consiste nell'uso della versione più recente dei set di regole principali Open Web Application Security Project (OWASP) e quindi nell'aggiunta di criteri personalizzati in base alle esigenze. Anche se Frontdoor di Azure è progettato per assorbire grandi quantità di traffico, è consigliabile usare i meccanismi di memorizzazione nella cache disponibili con questo servizio per ridurre il carico di traffico verso i sistemi back-end, laddove possibile. Per la risoluzione dei problemi e il supporto di potenziali indagini di sicurezza, è necessario configurare la registrazione sia per Frontdoor di Azure che per Web application firewall. Per altre informazioni, vedere Procedure di sicurezza per Frontdoor di Azure.
Gestione API di Azure
Tutto il traffico verso Gestione API deve essere autenticato, usando l'autenticazione di Gestione API di Azure AD B2C o con sessioni identificate da token. Configurare Gestione API di Azure per archiviare i log delle risorse. Per altre informazioni, vedere Procedure di sicurezza per Gestione API di Azure.
Servizio app di Azure
Tutto il traffico verso questa architettura, incluso il servizio app, deve essere protetto end-to-end con TLS. Il servizio app deve negare i protocolli non sicuri per rafforzare la superficie di attacco. Gestione API deve inoltre passare nuovamente l'autenticazione del client al servizio app per consentirne la convalida in base all'autenticazione e all'autorizzazione del client. Tutti i segreti usati nel servizio app devono essere archiviati in Key Vault, usando un'identità del servizio gestito, laddove possibile. Il servizio app deve anche archiviare i log di diagnostica per supportare eventuali attività diagnostiche di sicurezza e deve essere integrato con Microsoft Defender per il servizio app. Per altre informazioni, vedere Procedure di sicurezza per Servizio app di Azure.
Funzioni di Azure
Tutte le richieste al servizio Funzioni di Azure in questa soluzione devono richiedere HTTPS, usare Gestione API di Azure per autenticare le richieste e usare le identità gestite, laddove possibile. Archiviare tutte le chiavi in Azure Key Vault invece di lasciarle nel codice di Funzioni. Come per qualsiasi applicazione, assicurarsi di convalidare i dati all'input e di integrarli con Microsoft Defender for Cloud. Infine, configurare sempre la registrazione e il monitoraggio per Funzioni di Azure. Per altre informazioni, vedere Procedure di sicurezza per Funzioni di Azure.
Archiviazione BLOB di Azure
Laddove possibile, limitare l'accesso all'archiviazione BLOB usando Microsoft Entra ID per autorizzare l'accesso utente e identità del servizio gestito per l'accesso delle risorse all'archiviazione BLOB. Se questi tipi di autenticazione non dovessero adattarsi all'applicazione, usare un token di firma di accesso condiviso di livello più granulare, anziché una chiave dell'account. I token di firma di accesso condiviso vengono invalidati dopo la rotazione delle chiavi dell'account.
Assicurarsi di usare anche un controllo degli accessi in base al ruolo per l'archiviazione BLOB. Usare i firewall di Archiviazione di Azure per disincentivare il traffico di rete rispetto al traffico proveniente da servizi Microsoft attendibili. Integrare sempre Archiviazione di Azure con Microsoft Defender for Cloud e configurare il monitoraggio. Per altre informazioni, vedere Procedure di sicurezza per Archiviazione BLOB di Azure.
Azure Cosmos DB
I controlli degli accessi in base al ruolo devono essere abilitati per la gestione di Azure Cosmos DB. L'accesso ai dati in Azure Cosmos DB deve essere protetto in modo appropriato. È possibile configurare Azure Cosmos DB per archiviare i log di diagnostica per le operazioni del piano di controllo e per archiviare i log delle risorse. Per altri dettagli, vedere Procedure di sicurezza per Azure Cosmos DB.
Azure Key Vault
Le richieste effettuate ad Azure Key Vault devono essere autenticate usando Microsoft Entra ID o MSI oltre ai controlli di accesso con privilegi. Integrare Key Vault con Microsoft Defender for Cloud oltre a registrare le azioni di Key Vault in Monitoraggio di Azure. Per altre informazioni, vedere Procedure di sicurezza per Azure Key Vault.
Azure AD B2C
Usare le funzionalità integrate in Azure AD B2C per la protezione da minacce come attacchi Denial of Service e basati su password. Configurare la registrazione di controllo per consentire indagini sulla sicurezza e creare avvisi di log per tutti i log di gestione delle minacce generati da B2C. Per altre informazioni, vedere Procedure di sicurezza per Azure AD B2C.
Log Analytics di Azure
I controlli degli accessi in base al ruolo devono essere disponibili per Log Analytics per consentire solo agli utenti autorizzati l'accesso ai dati inviati all'area di lavoro. Per altre informazioni, vedere Procedure di sicurezza per Azure Log Analytics.
Azure Application Insights
Eventuali dati personali devono essere offuscati prima di essere inviati ad Application Insights. È anche necessario predisporre controlli degli accessi in base al ruolo per Application Insights per consentire solo agli utenti autorizzati di visualizzare i dati inviati ad Application Insights. Per altre informazioni, vedere Procedure di sicurezza per Azure Application Insights.
Vedere anche Procedure di sicurezza per Hub di notifica 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.
I prezzi per questa architettura sono in gran parte variabili in base ai livelli di servizi utilizzati, alla capacità, alla velocità effettiva, ai tipi di query eseguite sui dati, al numero di utenti, alla continuità aziendale e al ripristino di emergenza. Possono variare da circa $2.500/mese in su.
Per iniziare, è possibile visualizzare la stima generica del calcolatore di Azure qui.
A seconda della dimensione del carico di lavoro e dei requisiti per le funzionalità aziendali, l'uso del livello di consumo di Gestione API di Azure potrebbe ridurre il costo.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Matt Hansen | Cloud Program Architect
Passaggi successivi
- Altre informazioni sul Servizio FHIR di Azure
- Informazioni sui Servizi per i dati sanitari di Azure.
- Altre informazioni sulla pubblicazione esterna delle API interne.
Risorse correlate
- Guida all'architettura dei servizi per i dati sanitari di Azure
- Intelligenza artificiale per dati sanitari conformi a HIPAA e HITRUST
- Applicazioni cloud scalabili e progettazione dell'affidabilità del sito (SRE)
- Applicazione Web con ridondanza della zona a disponibilità elevata di base
- Applicazione Web con ridondanza della zona di base
- Applicazione Web a disponibilità elevata in più aree geografiche