Privacy e Sicurezza in sanità:
alcune esperienze concrete alcune esperienze concrete
Claudio Eccher eHealth (cleccher@fbk.eu)
Michele Trainotti eGovernment (mtrainotti@fbk.eu)
I dati in sanita’
MMG
Privacy e Sicurezza
Medico Specialista Cittadino/Paziente
Privacy e Sicurezza
Gli scenari presentati
Sanita’ provinciale/regionale Politiche sociali
Cittadino/Paziente
Cooperazione Socio Sanitaria
Il Fascicolo Sanitario Elettronico
Il Fascicolo Sanitario Elettronico
• Almeno due casi di accesso alle informazioni del paziente:
– Visita programmata – Emergenza urgenza – Emergenza urgenza
Domande per l’accesso alle informazioni
Chi?
Chi?
Con che
ruolo? Perche’?
Principali progetti
• E-Heart Failure: cartella clinica Web per la gestione condivisa dello paziente affetto da scompenso cardiaco;
scompenso cardiaco;
• Trec - Cartella Clinica del Cittadino: fascicolo sanitario elettronico del cittadino per la
gestione dei propri dati sanitari.
Il progetto e-Heart Failure (2002-2005)
• Il contesto
Hospital Physicians Hospital Physicians and
and NursesNurses ofof Domiciliary Care Domiciliary Care
(family)
Heart Failure Patient
and
and NursesNurses ofof
•• Cardiology WardCardiology Ward
•• Gerontology WardGerontology Ward
•• Internal Medicine WardInternal Medicine Ward
Domiciliary Care Domiciliary Care Nurses Nurses
General Practitioners General Practitioners (GPs) (GPs)
L’interfaccia Web della EPR e-HF
Patient information Patient information Patient information Patient information
Relevant problems Clinical history
Contact history
Navigation Navigation Navigation Navigation toolbar
toolbar toolbar toolbar
Shared Shared Shared Shared management management management management tooltool tooltool
Patient information Patient information Patient information Patient information managed by the health managed by the health managed by the health managed by the health
care professional care professional care professional care professional
Asyncrhonous
Teleconsultation tool
Il nuovo CPDP 196/03
• Il 30 giugno 2003 fu approvato il nuovo
Codice di Protezione dei Dati Personali- CPDP (DL 196/03) e relativo Disciplinare Tecnico.
• Il TITOLO V del CPDP regola in modo
dettagliato l’archiviazione e la gestione dei
• Il TITOLO V del CPDP regola in modo
dettagliato l’archiviazione e la gestione dei dati personali sanitari.
• Durante tutto il 2004 abbiamo lavorato per rendere il sistema a norma CPDP.
Misure minime
• Le misure minime del Disciplinare Tecnico
possono essere raggruppate a seconda che si voglia assicurare:
– La disponibilità dei dati;
– La disponibilità dei dati;
– La riservatezza dei dati (art. 34 CPDP);
– L’integrità dei dati.
Riservatezza dei dati
• Autenticazione informatica
– Procedura connessa ad uno specifico trattamento o ad un insieme di trattamenti, per il superamento della quale gli incaricati del trattamento devono essere dotati di opportune credenziali di
essere dotati di opportune credenziali di autenticazione.
• Autorizzazione
Riservatezza dei dati
• Autenticazione informatica
• Autorizzazione
– Procedura mediante la quale si decide quali privilegi assegnare ad un incaricato del
privilegi assegnare ad un incaricato del
trattamento dei dati che sia stato identificato e autenticato.
– I profili di autorizzazione possono essere definiti per ciascun incaricato, ma anche per classi
Autenticazione
• Ad ogni incaricato sono assegnate una o più credenziali per identificarlo in modo certo.
• Dispositivi di autenticazione:
– Dispositivi “deboli”: User id e parola chiave.
– Dispositivi “deboli”: User id e parola chiave.
– Dispositivi “forti”: One-time password, Smart Card e Token, Caratteristica biometrica.
Procedura di autenticazione
Internet/Intranet
User
e-HF Web site [1] access request
[2] generation and sending of the challenge
[5] sending of the signed challenge and the certificate
Is valid?
[7] signature verification
CA
Postecom
[6] extraction of the certificate and the public key
[3] signature of the challenge NO
[4] signed challenge
Access denied
Access denied Is correct?
Is valid?
e-HF CA
[8] challenge verification
[9] certificate verification access
autohrized access autohrized
YES NO
YES YES
NO Token/Smart card
Private key
The access to the token functions is protected by a PIN
Art. 3 CPDP: principio di necessità
• I sistemi informativi e i programmi informatici sono configurati riducendo al minimo
l'utilizzazione di dati personali e di dati identificativi, in modo da escluderne il
trattamento quando le finalità perseguite nei trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune
modalità che permettano di identificare l'interessato solo in caso di necessità.
Art. 22 comma 6 CPDP
• I dati sensibili e giudiziari contenuti in elenchi o banche di dati, tenuti con l’ausilio di strumenti elettronici, sono trattati con tecniche di
cifratura o mediante l’utilizzo di codici identificativi o di altre soluzioni che,
identificativi o di altre soluzioni che,
considerato il numero e la natura dei dati trattati, li rendono temporaneamente
inintelligibili anche a chi è autorizzato ad
Disciplinare tecnico
• I dati sensibili contenuti in elenchi, registri o banche di dati, tenuti con l’ausilio di
strumenti elettronici, devono essere trattati
secondo le modalità descritte nel comma 6 art.
22, anche per consentire il trattamento 22, anche per consentire il trattamento
disgiunto dei medesimi dati dagli altri dati personali che consentono di identificare direttamente gli interessati.
Trattamento disgiunto
• Separazione nel database dei dati anagrafici dai dati clinici e crittografia delle associazioni tra
dati e identità dei possessori.
Principio di necessità
• In principio, un operatore sanitario che non sia
coinvolto nella cura del paziente non ha necessità (e non dovrebbe avere i permessi) di accedere ai suoi dati clinici.
• Il sistema implementava procedure differenti per i
diversi ruoli per autorizzare l’associazione tra identità diversi ruoli per autorizzare l’associazione tra identità e dati clnici.
• 4 ruoli:
– Medici di medicina generale (MMG);
– Infermieri del territorio (IT);
– Medici ospedalieri di uno specifico reparto (MO);
Procedure di accesso
• Adozione di procedure diverse per i diversi ruoli:
– MMG e IT che possono associare alcuni pazienti
(propri assistiti) ai loro dati clinici in ogni momento;
– MO e IO che possono associare tutti i pazienti ai loro – MO e IO che possono associare tutti i pazienti ai loro
dati clinici solo in alcuni momenti, durante i quali l’operatore sanitario è interessato al processo di cura del paziente, o in caso di emergenza.
Accesso ai dati: MO ed IO
Ricovero Ricovero
tempo Accettazione Dimissione
Visita Amb. Visita Amb.
Dimissione Accettazione
Emergenza
Reparto 1
Visita Amb. Visita Amb. Emergenza
Ricovero
tempo Accettazione Dimissione
Reparto 2
?
Il flusso di accesso: MMG
Il flusso di accesso: MO
Trec: Cartella Clinica del Cittadino
• Creazione di un fascicolo sanitario elettronico per la gestione e comunicazione dei propri
dati di salute.
• Problema: gli utenti devono avere la
possibilità di specificare con precisione:
• Problema: gli utenti devono avere la
possibilità di specificare con precisione:
– quali altri utenti possono accedere ai propri dati;
– a quali parti del fascicolo questi utenti possono accedere;
Modello di accesso
• Politiche comuni di accesso definite a priori e indipendenti dall’utente;
• Regole di controllo di accesso definite da ogni utente a seconda delle proprie esigenze in
modificabili in ogni momento.
• Politiche basate su ruolo (RBAC):
• Politiche basate su ruolo (RBAC):
– familiare, medico, badante, ecc.
• Ad ogni ruolo sono associati dei permessi
• Modello basato su Attributi (risorse, ruoli, operazioni, applicazioni) inseriti in strutture
Architettura logica
TreC Web Portal
TreC on iPad TreC on
Smartphone
REST Controller MIDDLEWARE TreC DB
TreC DB
1. Richiesta Dati
5. Restituzione Dati
Problematiche affrontate
• Definizione degli attibuti e delle gerarchie degli attributi;
• Assegnazione dei ruoli agli utenti;
Role ID Operation ID Resource Type ID
App
Context ID
Depth Effect
• Assegnazione dei ruoli agli utenti;
• Definizione della politica di controllo comune;
• Progettazione di un meccanismo per la
definizione da parte dell’utente delle “proprie”
Ruoli
• Record Subject
– 0-13 anni, 14-17 anni, Maggiorenni, Utenti interdetti
• Record Custodian
– Tutori per interdetti , Genitori con patria potestà
• Health Care Provider
– Operatori di PS (emergenza)
• External Application
– Dispositivi, software di medici esterni APSS, SIO
• Operatore di sportello
Operazioni sui record di dati
• Tutte le operazioni
– garantite solo al proprietario dei dati.
• Modifica
• Visualizzazione
– Un utente deve poter ‘nascondere’ un record – Un utente deve poter ‘nascondere’ un record
– Un minorenne può oscurare un dato ‘supersensibile’
anche ai familiari.
• Amministrazione
Applicazioni
Scrittura di policy per l’accesso a risorse da parte di specifiche applicazioni.
•TreC cittadino mobile
•TreC cittadino web
•TreC cittadino web
•TreC medico Web
•Dispositivi di telemonitoraggio
Altre problematiche
• Dimensione temporale di accesso al dato:
– Richieste di consulto: un medico richiede una consulenza ad un esperto esterno;
– Visite ambulatoriali: il cittadino/paziente concede per un tempo limitato l’accesso a parte dei dati per un
un tempo limitato l’accesso a parte dei dati per un periodo limitato.
• Accesso di emergenza…
• Dati Georeferenziati:
– L’analisi di dati GIS per studi epidemiologici potrebbe
Solo un problema tecnologico?
• La gestione delle privacy e della sicurezza è in minima parte un problema tecnologico:
• Implica una ridefinizione di pratiche cliniche
consolidate, consuetudini, processi organizzativi;
• È necessario prendere in considerazione molti
• È necessario prendere in considerazione molti fattori:
– Informativa trattamento al cittadino/paziente – Convenzione tra enti
– Gestione dei problemi legati al circuito di trust
Grazie per l’attenzione
Claudio Eccher eHealth (cleccher@fbk.eu)
Michele Trainotti eGovernment (mtrainotti@fbk.eu)
