di Mauro VITACCA
Nello svolgimento di una DPIA in ambito sanitario, la valutazione dei rischi è naturalmente la fase più saliente della DPIA in particolare nella fase di individuazione delle minacce.
È in questa fase, inoltre, che si evidenzia la necessità che di far sì che la predisposizione del registro dei trattamenti non sia un mero esercizio formale, ma che sia l’esito di un’attenta valutazione del contesto organizzativo di riferimento e dei processi aziendali da cui le attività di trattamento dei dati scaturiscono.
L’analisi delle minacce non può limitarsi al mero “rischio dato” di perdita della integrità, disponibilità e confidenzialità, ma si deve spingere a prendere in considerazione quale effetto questo rischio può a sua volta avere per i diritti e le libertà delle persone fisiche.
Per tale motivo, nella valutazione delle minacce il Garante invita a prendere in considerazione gli effetti complessivi del trattamento rischioso includendo, ad esempio, come evidenziato bene anche in un apposito tutorial(1), i possibili danni fisici o patologici, la possibile discriminazione, magari conseguente al fatto che soggetti non legittimati vengano a conoscenza dei dati sulla salute dell’interessato, l’impossibilità di esercitare i propri diritti.
Volendo pertanto immaginare un possibile approccio, l’individuazione delle minacce in un ambito sanitario, può avvenire seguendo diverse prospettive, non alternative fra di loro che si potrebbero così schematizzare:
Il focus sui processi
Qualsiasi valutazione del rischio, non può essere avulsa dalla valutazione di chi, perché, con quali strumenti e in quale contesto tratta i dati. Ci viene in aiuto, a questo proposito, il contenuto di uno standard ISO 12967 “Health Informatics Service Architecture HISA” che parte dalla constatazione che i sistemi informativi delle organizzazioni in ambito sanitario devono soddisfare due bisogni di base potenzialmente in conflitto tra di loro:
- da una parte supportare le esigenze di ogni singolo dipartimento o user, secondo un approccio di specializzazione verticale,
- dall’altra assicurare la coerenza e l’integrazione dei sistemi a livello di unità operativa, organizzazione, territoriale.
Su tali basi la ISO si pone l’obiettivo di identificare i fondamentali aspetti architetturali che rendano possibile l’integrazione e l’interoperabilità dei sistemi informativi(2); il focus non è tanto sugli standard di comunicazione e trasmissione dei dati (es. HL7, Dicom) già sufficientemente maturi, quanto sulla metodologia di organizzazione dei dati al fine di garantire la necessaria interoperabilità semantica dei sistemi. Volendo definire la struttura di un Clinical Data Repository, occorre considerare che nell’arco della sua vita un paziente ha diversi episodi sanitari (ricoveri, DH, ambulatoriali, ecc.); durante ogni contatto il paziente riceve determinate prestazioni (visite, esami, terapie, interventi ecc.). Ogni prestazione genera un atto sanitario per il quale può essere necessario produrre dati clinici e impiegare risorse (materiali, attrezzature, spazi). A loro volta i dati clinici possono essere strutturati in documenti più complessi ed aggregati/consultati in funzione delle diverse esigenze cliniche ed operative delle diverse attività (protocolli), classificati secondo diverse codifiche e nomenclatori, cui accedono diverse tipologie di utenti che operano in unità organizzative (strutture), con differenti livelli di abilitazione ed utilizzati nell’ambito di diversi processi dell’organizzazione (es. percorsi diagnostici, terapeutici o assistenziali).
Modello HISA (3)
Questo ci consente di mettere in relazione le attività svolte, i dati trattati, le risorse (organizzative e tecnologiche) favorendo un approccio multidisciplinare sempre più indispensabile e che pertanto deve abbracciare gli aspetti legati alla sicurezza del paziente, di continuità operativa e di cybersecurity che rendono evidenti le minacce in caso di compromissione della integrità, disponibilità, riservatezza dei dati nonché della capacità di resilienza dei sistemi (rif. art. 32 del GDPR).
Nel valutare, ad esempio, un ERP sanitario, non possono essere trascurati aspetti legati alla sicurezza del paziente (quali ad esempio la corretta identificazione del paziente, la coerenza tra prescrizione e somministrazione di una terapia, la correttezza di inserimenti manuali, la criticità nel passaggio delle consegne, la tempestività e significatività di determinati alert ecc.) o alla effettiva possibilità di acquisire il consenso del paziente non solo al trattamento dei dati ma anche alla prestazione stessa nonché alla necessità di tracciare e documentare ogni atto sanitario-assistenziale (assicurare il log management, garanzia di non cancellazione/non sovrascrittura di dati, assicurare autenticità, data certa e versioni di dati e documenti rilevanti, ecc.).
Il focus sulle risorse
Sebbene una valutazione delle risorse, umane e tecnologiche, non può essere scissa dalle valutazioni di processo, sicuramente assumono una rilevanza significativa gli aspetti di Health Technology assessment (HTA) e di cybersecurity.
L’Health Technology assessment (HTA) si può definire come “la complessiva e sistematica valutazione multidisciplinare (descrizione, esame e giudizio) delle conseguenze assistenziali, economiche, sociali ed etiche provocate in modo diretto e indiretto, nel breve e nel lungo periodo, dalle tecnologie sanitarie esistenti e da quelle di nuova introduzione”(4). Il nuovo, Regolamento Europeo sui dispositivi medici (Reg 2017/745), prevede espressamente, nella classificazione dei dispositivi medici, i “software destinati a fornire informazioni utilizzate per prendere decisioni a fini diagnostici e terapeutici”. Oltre a prevedere l’istituzione di una banca dati europea sui dispositivi medici (Eudmed) ed un sistema di trasparenza e tracciabilità dei dispositivi (sistema UDI), il regolamento prevede, oltre che una valutazione fondata sulla sicurezza, anche una valutazione clinica circa la destinazione d’uso che sia equivalente al dispositivo cui si riferiscono i dati. Sempre secondo tale regolamento un software – sia esso software stand-alone software o embedded (incorporato in altro dispositivo medico) – diventa dispositivo medico quando ha uno “scopo medico”. Tale scopo deve emerge ovviamente dalle funzionalità concrete del software, che rappresentano la destinazione d’uso del dispositivo medico. Nel concreto il software può avere scopo medico quando:
i) controlla direttamente un dispositivo medico;
ìì) fornisce informazioni decisionali mediche immediate;
iii) fornisce supporto agli operatori sanitari.
I fatti di cronaca evidenziano come il settore sanitario sia uno dei settori più esposti sul versante cybersecurity. Proprio le problematiche di sicurezza cyber evidenziano come l’attenzione sugli aspetti tecnologici non può essere disgiunta dall’attenzione degli aspetti organizzativi delle risorse umane. Tra i fattori di rischio che incidono maggiormente possiamo evidenziare:
i) l’ampia diversificazione delle figure professionali coinvolte (non sempre legate da un rapporto gerarchico-subordinato nei confronti del titolare) con diversi profili di autorizzazione nei sistemi e che spesso accedono a più applicativi o attrezzature collegate in rete;
ii) la necessità di integrare applicativi e attrezzature fortemente diversificate sia all’interno dell’organizzazione che lungo la supply-chain;
iii) la necessità di integrare e garantire l’interoperabilità sistemi che si sono stratificati in tempi differenti non di rado caratterizzati da fenomeni di lock-in tecnologico/contrattuale;
iv) l’utilizzo di attrezzature medicali, e sempre di più soluzioni IoT, non sempre progettate secondo una logica di sicurezza by-design e che non di rado sono caratterizzate dall’integrazione hardware/software con sistemi operativi obsoleti o per i quali non sono facilmente disponibili patch.
È quindi auspicabile una valutazione congiunta di safety e security delle tecnologie in ambito medico; a questo proposito possono fungere da punto di riferimento diversi standard, tra i quali possiamo citare AAMI/UL 2800 – Safety and security requirements of introperable medical systems e AAMI TIR 57 Principles for medical device security – risk management(5).
Più in generale sul versante cybersecurity, oltre alle note misure minime di sicurezza AgID per le PPAA, un interessante riferimento è il Framework Nazionale per la Cybersecurity e la Data Protection del Cini (Consorzio Interuniversitario Nazionale per l’Informatica), realizzato in collaborazione con il Garante per la protezione dei dati, per supportare le organizzazioni che necessitano di strategie e processi volti alla protezione dei dati personali e alla sicurezza cyber. Il Framework, che eredita le tre nozioni fondamentali del Cybersecurity Framework NIST:
- Framework Core,
- Profile Tier e
- Implementation Tier,
è strutturato gerarchicamente in function, category e subcategory.
Le function, concorrenti e continue, sono: IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER e costituiscono le principali tematiche da affrontare per operare una adeguata gestione del rischio cyber in modo strategico e presenta riferimenti che legano la singola subcategory alle pratiche di sicurezza note previste da standard di settore (ISO, SP800-53r4, COBIT-5, SANS20 e altri) o da regolamentazioni generali vigenti (Regolamento UE 2016/679 General Data Protection Regulation, Direttiva UE 2016/1148 NIS)(6).
Il focus sui diritti degli interessati
Come noto il GDPR riconosce agli interessati numerosi diritti esercitabili nei confronti del titolare: diritto di accesso, rettifica, cancellazione, limitazione, opposizione, portabilità, revoca del consenso.
Come noto, con riferimento all’art. 9 par. 2 del GDPR, in ambito sanitario il trattamento dei dati è ammesso:
- per motivi di interesse pubblico rilevante sulla base del diritto dell’Unione o di uno stato membro (lettera f),
- per motivi di interesse pubblico nel settore della sanità pubblica (lett. i) e
- per finalità di cura (lettera h) effettuati da (o sotto la responsabilità di) un professionista sanitario soggetto al segreto professionale.
Pertanto, il consenso non costituisce più, come in passato, presupposto di legittimità al trattamento se non in casi residuali, uno dei quali è il caso della gestione del “dossier sanitario” cioè lo strumento costituito presso un’unica struttura sanitaria (ospedale, azienda sanitaria, casa di cura) che raccoglie informazioni sulla salute di un paziente al fine di documentarne la storia clinica presso quella singola struttura. Con il provvedimento del 4 giugno 2015, il Garante per la protezione dei dati personali ha varato le Linee guida che prevede il consenso per la costituzione e implementazione del dossier (essendo questo un trattamento separato e specifico rispetto a quello previsto per la prestazione sanitaria) e, oltre a garantire al paziente l’esercizio dei diritti, prevede anche la possibilità di “oscurare” alcuni dati relativi a informazioni c.d. “di maggior tutela”.
Pertanto, nell’ambito sanitario i diritti che assumono maggiore rilievo sono quelli:
- del diritto di accesso (sia accesso ai dati come previsto dal GDPR che ai documenti sanitari tout court in ottemperanza alla L. 241/90 inerente il diritto di accesso ai documenti amministrativi e/o alla L. 24/2017 c.d. “Legge Gelli-Bianco”),
- di oscuramento nell’ambito della gestione del dossier sanitario e
- di revoca del consenso, laddove questo sia stato dato in precedenza per finalità ulteriori rispetto a quello di cura (es. per finalità di ricerca).
È altresì facile intuire come la gestione di questi diritti comporti l’adozione e l’implementazione di soluzioni tecnologiche ed organizzative non banali che, nell’ambito della gestione documentale e nella processazione delle prestazioni, garantiscano adeguati livelli di autorizzazione di accesso ai dati da parte degli operatori, sistemi di firma e raccolta dei consensi analogici e/o digitali, sistemi di archiviazione e conservazione (anche questi analogici e/o digitali), eventuale cancellazione dei dati al termine del periodo di trattamento.
Rischi di individuazione del singolo
Le attività di ricerca svolte da strutture sanitarie differenti dagli IRCCS (Istituti di ricovero e cura a carattere scientifico) comportano il riutilizzo dei dati originariamente raccolti per finalità di diagnosi e cura. In altri casi i dati devono essere condivisi con altri soggetti nell’ambito di convenzioni istituzionali o rapporti di partnership. Tralasciando in questa sede l’approfondimento di quale possa essere la base di legittimità che consente il riutilizzo dei dati in tali casi, il riferimento all’art. 89 del GDPR chiarisce che presupposto fondamentale per procedere al trattamento ulteriore è l’adozione di adeguate garanzie per i diritti e le libertà fondamentali dell’interessato, ovvero di misure tecniche ed organizzative idonee a perseguire il principio minimizzazione dei dati, le quali possono includere la pseudonimizzazione.
Non è sempre facile percepire, da parte di chi opera, che non è sufficiente togliere ogni elemento anagrafico o il numero identificativo di ricovero dai data base utilizzati affinché i dati si trasformino da personali ad anonimi ed il rischio di identificare una persona è ovviamente tanto più elevato quanto si ha a che fare con patologie rare. È utile tenere presente che con un Provvedimento del 14 gennaio 2021, il Garante ha approvato un “Codice di condotta per l’utilizzo di dati sulla salute a fini didattici e di pubblicazione scientifica” predisposto dalla Regione Veneto su proposta dell’Azienda Sanitaria ULSS 9 che fa a sua volta diretto riferimento al parere 05/2014 del WP Articolo 29 relativo alle tecniche di anonimizzazione. Il documento ripercorre le principali tecniche di randomizzazione e di generalizzazione degli attributi ricordandone comunque i limiti in quanto anche le tecniche più evolute di anonimizzazione sono soggette a rischi di individuazione (è ancora possibile individuare una persona), di correlabilità (è ancora possibile collegare i dati relativi a una persona) e di deduzione (è possibile dedurre informazioni riguardanti una persona). D’altra parte, il parere del WP Articolo 29 raccomanda di prestare particolare attenzione quando si decide di applicare una determinata tecnica alla situazione specifica o di ricorrere a un insieme di tecniche di anonimizzazione al fine di accrescere l’affidabilità dell’esito. Pertanto, spesso non vi è altra soluzione che procedere a pseudonimizzazione. Il Codice di condotta citato elenca alcune tecniche di pseudonimizzazione “più usate” (non sembra quindi escludere a priori la possibilità di utilizzarne altre) riconducibili sostanzialmente alla crittografia, all’applicazione di una funzione di hash o altre tecniche che risultino dalla combinazione di queste.
Conclusioni
Gli elementi di riflessione riportati non vogliono essere naturalmente esaustivi, tuttavia si è voluto fornire un contributo per evidenziare il fatto che per assicurare un approccio by design in occasione dell’introduzione di nuove tecnologie, nuovi processi o nuovi assetti organizzativi che impattano sui trattamenti in essere o che ne aggiungono di nuovi, è necessario un approccio multidisciplinare finalizzato ad integrare la DPIA con gli altri processi aziendali e creare altresì le premesse per una revisione della stessa ogniqualvolta sia opportuno. L’utilizzo di alcuni strumenti quali il Modello HISA, le tecniche di Health Technology Assessment, il Framework del Cini, possono costituire riferimenti concettuali importanti per coinvolgere professionalità diverse in tali valutazioni.
A parere di chi scrive difficilmente, pertanto, tale approccio può essere compatibile con tools standardizzati, così come l’individuazione delle misure di sicurezza – atte a raggiungere un rischio residuo accettabile deve comprendere un’ampia gamma di possibili soluzioni siano esse di carattere tecnologico, organizzativo o di maggiore consapevolezza degli operatori – vanno naturalmente valutate caso per caso. Del resto, lo stesso Garante, nel mettere a disposizione sul proprio sito istituzionale il software del CNIL, precisa che lo stesso non costituisce un modello al quale fare riferimento in ogni situazione di trattamento, essendo stato concepito soprattutto come ausilio metodologico per le PMI.
2/2
Intervento del Dr. Mauro Vitacca Compliance Manager c/o Fondazione Opera San Camillo – Milano
LEGGI QUI l’articolo precedente 1/2, Gli aspetti peculiari di una DPIA in ambito sanitario
Per approfondimenti, consultare i seguenti link e/o riferimenti:
(1) Garante Privacy – DPIA, Individuazione e Gestione del Rischio
(2) ISO 12967-1:2020-11 Introduction
(3) I modelli necessari a strutturare un Clinical Data Repository. Paolo Locatelli, Davide Zacchetti, Fabio Chiodini, Fabrizio Massimo Ferrara; Progettare per la Sanità nr. 5/19
(4) Società Italiana di HTA. La Carta di Trento
