Risposta breve: la sicurezza in un'app sanitaria risponde a quattro domande, in ordine. Chi è questo? Identità: un utente verificato (paziente, medico, sistema) tramite OpenID Connect e, per i medici, l'identità professionale nazionale; il livello di verifica è più importante della robustezza della password. Cosa possono fare? Autorizzazione: token OAuth 2.0 (in transizione verso il 2.1) con scope nella sintassi SMART on FHIR, derivati dal consenso del paziente per uno scopo e una durata, applicati a livello di dati. Cosa hanno fatto? Responsabilità: un registro degli accessi che il paziente può leggere e una traccia FHIR AuditEvent per l'organizzazione. I dati sono al sicuro a riposo, in transito e nei backup? Protezione: crittografia, gestione delle chiavi, segregazione, ripristini testati. Attorno a questi: la base di ISO 27001 e 27799, NIS2 e la Security Rule di HIPAA, e le minacce specifiche ai dati sanitari (navigazione interna, archiviazione errata, ransomware).
La mappa
La sicurezza e l'identità in un'app sanitaria si compongono di sette livelli: identità tramite OpenID Connect e ID nazionali o professionali, autorizzazione tramite OAuth 2.0 e scope SMART on FHIR, consenso come fonte di ogni concessione, responsabilità tramite log di accesso e FHIR AuditEvent, protezione tramite crittografia e backup, una base di ISO 27001, ISO 27799, NIS2 e HIPAA, e condivisione avviata dal paziente.
| Livello | Standard o pratica | Cosa ti offre | Pagina |
|---|---|---|---|
| Identità | OpenID Connect; identità nazionali (eIDAS, NHS login, GesundheitsID); identità professionali (eHBA, CPS, UZI) | Un soggetto verificato con un livello di garanzia | Spiegazione di SMART App Launch |
| Autorizzazione | OAuth 2.0 e 2.1 (PKCE obbligatorio, nessun grant implicito o password); scope SMART on FHIR (patient/Observation.rs); servizi backend con autenticazione client asimmetrica | Token legati a un utente, un contesto paziente e uno scope | Spiegazione di SMART App Launch, Backend SMART on FHIR |
| Consenso | FHIR Consent; grant legati a scopo e tempo; revoca; break-the-glass con giustificazione e avviso | Il paziente come fonte di ogni autorizzazione | Piattaforma di consenso del paziente, Richieste di accesso clinico |
| Responsabilità | Registri di accesso per ogni record visibili al paziente; FHIR AuditEvent; archiviazione a prova di manomissione; conservazione | Chi ha visto cosa, quando, perché | Chi ha visualizzato la mia cartella clinica? |
| Protezione | TLS 1.2+, crittografia a riposo con chiavi gestite, crittografia a livello di campo per gli identificatori, ambienti segregati, backup con ripristino testato | Riservatezza e disponibilità | ISO 27001 vs ISO 27799 |
| Base | ISMS ISO 27001, controlli sanitari ISO 27799, misure NIS2, Security Rule di HIPAA, schemi nazionali (HDS, DSPT, C5) | Cosa si aspettano ospedali, revisori e regolatori | NIS2 per ospedali e fornitori, HIPAA vs GDPR |
| Condivisione | SMART Health Links e Cards; credenziali verificabili | Condivisione avviata dal paziente con un link o QR, revocabile | Spiegazione di SMART Health Links |
Identità: garanzia oltre le password
L'identità in un'app sanitaria si basa sull'affidabilità piuttosto che sulla robustezza delle password: i livelli di affidabilità dell'identità come NIST IAL, eIDAS sostanziale e alto, o NHS login P9 descrivono quanto una persona sia stata verificata con forza al momento dell'iscrizione, mentre l'autenticazione a più fattori e le passkey descrivono ogni accesso. I medici sono identificati tramite identità professionali che vengono revocate quando lasciano l'organizzazione.
Un'app per pazienti che mostra una cartella completa deve sapere che sta parlando con quel paziente. I livelli di garanzia dell'identità (IAL di NIST, sostanziale e alto di eIDAS, NHS login P9) descrivono quanto fortemente l'identità è stata verificata al momento dell'iscrizione; la robustezza dell'autenticazione (multi-fattore, passkey) descrive ogni accesso. Ospedali e sistemi nazionali richiedono sempre più identità verificate da schemi riconosciuti piuttosto che registrazioni auto-dichiarate, e il Portafoglio Digitale dell'UE diventerà un mezzo accettato. Per i medici, l'identità professionale (e la sua revoca quando qualcuno lascia) è il sistema di riferimento per chiunque possa agire come medico.
Autorizzazione: il consenso diventa scope
L'autorizzazione in un registro controllato dal paziente traduce il consenso del paziente, ad esempio consentire a una clinica di leggere i risultati di laboratorio e le condizioni per 90 giorni, in scope OAuth e contesto del paziente sul token, in sintassi SMART on FHIR come patient/Observation.rs, applicata a livello di dati su ogni richiesta e revocata quando il paziente ritira il consenso. Il "break-the-glass" è un percorso separato e registrato.
In una cartella controllata dal paziente, il consenso del paziente è la politica: questa clinica può leggere i miei risultati di laboratorio e le mie condizioni per 90 giorni. Il sistema lo traduce in scope OAuth e contesto (quale paziente, quali risorse, quali operazioni) sul token che il sistema della clinica riceve, li applica a ogni richiesta a livello di dati e li revoca quando il paziente ritira il consenso. La sintassi degli scope di SMART on FHIR (patient/Observation.rs, patient/Condition.rs) è la lingua franca per questo; scope granulari (per categoria o codice) esistono in SMART v2 per un controllo più fine. Il "break-the-glass" (accesso di emergenza senza consenso) è un percorso separato e registrato con giustificazione obbligatoria e un avviso al paziente, mai un'opzione predefinita. Vedi Piattaforma di consenso del paziente.
Responsabilità: il registro che il paziente legge
La responsabilità in un'app sanitaria significa che ogni accesso a un registro, da parte di chi, quando, cosa e sotto quale consenso, viene scritto in un log append-only che il paziente può leggere nella propria app e in una traccia di audit organizzativa in FHIR AuditEvent. ISO 27799 tratta questo come obbligatorio, e un log visibile è il deterrente più forte contro la navigazione interna non autorizzata.
Ogni accesso a una cartella, da parte di chi, quando, cosa, sotto quale consenso, scritto in un registro append-only che il paziente può leggere nella sua app, e in una traccia di audit organizzativa (FHIR AuditEvent) per i team di sicurezza. ISO 27799 lo considera obbligatorio per le informazioni sanitarie; il principio di trasparenza del GDPR e i diritti del paziente dell'EHDS puntano nella stessa direzione; il più grande deterrente nel mondo reale alla navigazione interna è un registro visibile. Vedi Chi ha visualizzato la mia cartella clinica?.
Protezione: la base ingegneristica
La base ingegneristica per la protezione dei dati sanitari è TLS ovunque, crittografia a riposo con chiavi gestite e ruotate, crittografia o tokenizzazione separata per gli identificatori diretti, ambienti segregati con dati sintetici al di fuori della produzione, accesso con privilegi minimi con autenticazione a più fattori per gli amministratori, gestione dei segreti e delle vulnerabilità, backup crittografati testati tramite ripristino contro ransomware e risposta agli incidenti entro i tempi previsti da GDPR e NIS2.
TLS ovunque, con cifrari moderni e certificate pinning nelle app dove appropriato; crittografia a riposo con chiavi in un servizio di gestione chiavi e rotazione; crittografia separata o tokenizzazione per identificatori diretti; segregazione della produzione dallo sviluppo, con dati sintetici al di fuori della produzione; accesso basato sul principio del minimo privilegio per il personale, nessun account condiviso, multi-fattore per tutto l'accesso amministrativo; gestione dei segreti; gestione delle dipendenze e delle vulnerabilità con divulgazione; backup crittografati, testati tramite ripristino e protetti contro il ransomware che ha colpito ripetutamente ospedali e laboratori (WannaCry nel 2017, l'ospedale di Düsseldorf nel 2020, Change Healthcare e Synnovis nel 2024). Risposta agli incidenti con gli orologi di 72 ore del GDPR e 24 ore del NIS2 in un unico runbook.
Minacce specifiche ai dati sanitari
Le minacce specifiche ai dati sanitari includono la navigazione interna dei record di conoscenti, la errata archiviazione tra pazienti, la condivisione eccessivamente ampia concessa per troppo tempo, gli SDK pubblicitari all'interno delle app che gestiscono dati sanitari, l'iniezione di documenti in funzionalità AI e la conservazione a lungo termine per decenni durante i quali chiavi, formati e regole di accesso devono sopravvivere a personale e fornitori.
- Navigazione interna di cartelle di conoscenti o figure pubbliche: accesso basato sulle relazioni e registri visibili.
- Archiviazione errata tra pazienti: riconciliazione dell'identità e provenienza, non solo controllo degli accessi.
- Condivisione eccessivamente ampia: una clinica a cui è stato concesso "tutto" per un anno; scope e durate con valori predefiniti sensati.
- App con SDK pubblicitari: nessun tracker di terze parti in qualsiasi cosa gestisca dati sanitari.
- Iniezione tramite documenti nelle funzionalità AI: il contenuto è dati, mai istruzioni (RAG su cartelle cliniche).
- Conservazione a lungo termine: le cartelle vivono per decenni; chiavi, formati e regole di accesso devono sopravvivere al personale e ai fornitori.
In Anpheros
Anpheros applica la mappa di sicurezza a sé stessa con OAuth 2.0 con PKCE per le app e autenticazione client asimmetrica per i backend, consenso per scopo e durata come fonte di accesso di ogni clinica, un log di accesso per record nell'app della persona, crittografia a riposo e in transito, hosting UE, nessun SDK pubblicitario e un ISMS secondo ISO 27001 e 27799.
Anpheros applica questa mappa a se stessa: OAuth 2.0 con PKCE per le app e autenticazione client asimmetrica per i backend; consenso per scopo e durata come fonte di accesso di ogni clinica, con revoca e nessun "break-the-glass" silenzioso; un registro degli accessi per ogni record nell'app della persona; crittografia a riposo e in transito, hosting UE, nessun SDK pubblicitario; un ISMS secondo ISO 27001 con i controlli sanitari 27799. Il sito per sviluppatori documenta autenticazione, consenso e sicurezza.
Pagine correlate
- Spiegazione di SMART App Launch
- Piattaforma di consenso del paziente
- Chi ha visualizzato la mia cartella clinica?
- Spiegazione di SMART Health Links
- ISO 27001 vs ISO 27799
- NIS2 per ospedali e fornitori di tecnologia sanitaria
- Sicurezza della piattaforma (sito per sviluppatori)
- Autenticazione (sito per sviluppatori)
Fonti
- HL7 SMART App Launch
- IETF: OAuth 2.1 (bozza)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Linee guida per l'approvvigionamento di cybersecurity negli ospedali
Domande frequenti
OAuth 2.1 è diverso da 2.0?
OAuth 2.1 consolida 2.0 con le sue best practice di sicurezza: PKCE è richiesto per tutti i client, i grant impliciti e password sono stati rimossi, gli URI di reindirizzamento devono corrispondere esattamente e i token di aggiornamento per i client pubblici devono essere legati o ruotati. SMART on FHIR v2 richiede già la maggior parte di questo.
Cos'è il "break-the-glass"?
Accesso di emergenza a una cartella senza il previo consenso del paziente, da parte di un medico che dichiara una giustificazione. Deve essere raro, registrato, revisionato e segnalato al paziente; non è mai il percorso di accesso predefinito.
Perché i pazienti dovrebbero vedere il registro degli accessi?
Perché è il deterrente più forte contro accessi inappropriati e la più chiara espressione di controllo: la persona vede quale clinica ha letto cosa e quando, e può revocare l'accesso. ISO 27799 e l'EHDS puntano nella stessa direzione.
Ho bisogno di un sistema di audit separato?
È necessario un registro di audit append-only (FHIR AuditEvent o equivalente) che l'applicazione non possa alterare, conservato secondo le policy, e una vista rivolta al paziente derivata da esso. Se si tratta di un sistema separato o di uno spazio protetto all'interno della piattaforma è una scelta di implementazione.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →