Dal 25 maggio 2018 ogni trattamento di dati sanitari parte da un divieto e poggia su una sola deroga dell’art. 9(2) del Regolamento (UE) 2016/679. Quale deroga scegli non è una formalità da informativa: decide chi è autorizzato a leggere il dato, sotto quale obbligo di segreto, fin dove lo puoi trasferire e quando un dataset clinico deve restare separato da uno di ricerca. È una decisione di architettura, presa con il linguaggio del diritto.

Contesto

Il GDPR si applica direttamente in tutti gli Stati membri dal 25 maggio 2018, senza alcun atto nazionale di recepimento. In Italia il D.Lgs. 196/2003 (Codice Privacy) resta formalmente in vigore in attesa del decreto di adeguamento, ancora in iter parlamentare. Il Regolamento si applica comunque, e con esso l’art. 9, che colloca i dati relativi alla salute tra le categorie particolari di dati personali — insieme ai dati genetici (art. 4(13)) e a quelli biometrici usati per l’identificazione (art. 4(14)).

La definizione di dato sanitario all’art. 4(15) è ampia: tutti i dati attinenti alla salute fisica o mentale, compresa la prestazione di servizi di assistenza, che rivelano informazioni sullo stato di salute. Il Considerando 35 allarga il perimetro ai numeri identificativi assegnati a fini sanitari, agli esiti di esami su parti del corpo o su sostanze biologiche, alle informazioni su malattia, disabilità, rischio di malattia e anamnesi. Per chi progetta un sistema il confine del dato sanitario non coincide con i campi diagnostici espliciti: ci rientrano anche un identificativo paziente o il timestamp di accesso a un servizio.

Il problema: dieci deroghe, non una

L’art. 9(1) vieta il trattamento. L’art. 9(2) elenca dieci eccezioni tassative. Per la sanità pesano soprattutto quattro lettere, e ciascuna porta vincoli tecnici diversi.

La lettera (h) — medicina preventiva, diagnosi, assistenza o terapia, gestione dei sistemi sanitari — è la base ordinaria della cura. Il paragrafo 3 dell’articolo la condiziona: il trattamento deve avvenire da parte di, o sotto la responsabilità di, un professionista tenuto al segreto professionale. In pratica diventa un controllo di accesso che lega la lettura del dato a un ruolo clinico identificato, non a un’utenza generica di sistema.

La lettera (i) — interesse pubblico nella sanità pubblica, sorveglianza epidemiologica, farmacovigilanza — regge i registri di patologia e i sistemi di sorveglianza, e chiede una base normativa di diritto dell’Unione o dello Stato membro.

La lettera (j) — ricerca scientifica, archiviazione nel pubblico interesse, fini statistici — è la base degli studi osservazionali e dei database di ricerca. L’art. 89(1) chiede garanzie adeguate: minimizzazione e, dove si può, pseudonimizzazione.

La lettera (a) — consenso esplicito — resta disponibile ma fragile in un contesto di cura. Lo squilibrio di potere tra paziente e struttura indebolisce il requisito del consenso liberamente prestato; il WP29 ne sconsiglia l’uso come base primaria del trattamento clinico e lo riserva a finalità ulteriori e distinte.

In concreto, la stessa cartella clinica letta per curare un paziente sta sotto la (h); letta per uno studio retrospettivo sta sotto la (j). Sono due trattamenti diversi — basi giuridiche, perimetri di accesso e obblighi documentali diversi — sullo stesso dato di partenza.

Il punto critico: separare cura e ricerca

La conseguenza architetturale più netta nasce dall’incrocio tra le deroghe e il principio di minimizzazione dell’art. 5(1)(c): trattare solo i dati necessari alla finalità dichiarata. Se cura e ricerca convivono nello stesso datastore con gli stessi diritti di accesso, la minimizzazione è violata già in partenza: il ricercatore vede più di quanto serve alla sua finalità, il clinico lavora su un dataset arricchito da elaborazioni di ricerca.

La separazione passa per la pseudonimizzazione, definita all’art. 4(5): trattare i dati in modo che non siano più attribuibili a un interessato senza informazioni aggiuntive, tenute separate e protette. Un dato pseudonimizzato resta un dato personale e resta dentro il GDPR — la pseudonimizzazione è una mitigazione che il Regolamento riconosce, non un’uscita dal suo perimetro. Tecnicamente impone una tabella di corrispondenza custodita altrove rispetto al dataset di ricerca, con un confine di accesso che il sistema fa rispettare, senza affidarlo alla disciplina degli operatori.

L’anonimizzazione è un’altra cosa. Il GDPR non la definisce; il riferimento è l’Opinion 05/2014 del WP29 sulle tecniche di anonimizzazione, che fissa una soglia esigente: un dato è anonimo solo se non consente l’identificazione con mezzi ragionevolmente disponibili, né da solo né incrociato con altri dataset. Un dato davvero anonimo esce dal GDPR. Nei dati sanitari quella soglia è difficile da raggiungere: età, codice di avviamento postale, una diagnosi rara e le date di ricovero, messi insieme, possono re-identificare una persona anche senza il nome. L’Opinion analizza i limiti di k-anonymity, l-diversity e aggiunta di rumore, e la conclusione operativa è che un’anonimizzazione robusta va valutata caso per caso e raramente si ottiene togliendo i soli identificatori diretti.

Implicazioni operative

Sul piano organizzativo gli obblighi che pesano di più sulle strutture sanitarie sono noti e, per il 2018, ancora in larga parte da implementare. Il Data Protection Officer (DPO) è obbligatorio (art. 37); le Linee guida WP243 del WP29 chiariscono che trattare i dati dei pazienti è attività core di un ospedale e configura un trattamento su larga scala, sopra la soglia che impone il DPO. La valutazione d’impatto sulla protezione dei dati — Data Protection Impact Assessment (DPIA), art. 35 — è dovuta per i trattamenti sistematici di categorie particolari su larga scala, presunti ad alto rischio. Il registro dei trattamenti (art. 30) documenta ogni trattamento con la sua base giuridica: è qui che la scelta tra (h), (i) e (j) diventa tracciabile e verificabile.

Sul piano tecnico l’art. 25 — protezione dei dati fin dalla progettazione e per impostazione predefinita — sposta il vincolo a monte, nella configurazione di default dei sistemi. La notifica di violazione (art. 33-34) impone tracciatura e capacità di rilevamento entro 72 ore. Per le infrastrutture cloud pesa il Capo V (art. 44-50) sui trasferimenti verso Paesi terzi: al maggio 2018 il Privacy Shield UE-USA, adottato nel luglio 2016, è il meccanismo operativo verso i fornitori statunitensi, già però sotto contestazione giurisdizionale con un esito incerto.

Limiti

L’art. 9(4) lascia agli Stati membri lo spazio per mantenere o introdurre condizioni ulteriori, comprese limitazioni, su dati genetici, biometrici e sanitari. In Italia quello spazio sarà occupato dal decreto di adeguamento atteso, con misure di garanzia da definire con provvedimento del Garante. Finché quel quadro non si chiude, una parte delle scelte — quali trattamenti richiedano ancora il consenso, quali garanzie specifiche servano per i dati genetici — resta sospesa tra Regolamento applicabile e diritto nazionale in transizione. Le architetture progettate adesso vanno costruite per assorbire vincoli nazionali non ancora pubblicati, non per fotografare lo stato del 25 maggio.

Immagine di copertina: Gli edifici della Corte di giustizia dell’Unione europea a Kirchberg, Lussemburgo, con una fila di bandiere degli Stati membri in… — foto di Cedric Puisney, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:European_Court_of_Justice_(ECJ)_in_Luxembourg_with_flags_0017_(1674479483).jpg