Dati personali negli ICSR: la conformità è una questione di architettura di sistema

La gestione dei dati personali negli Individual Case Safety Report (ICSR) è oggi uno dei punti più delicati della governance in farmacovigilanza in quanto richiede un presidio tecnico sempre più strutturato. Le indicazioni sul trasferimento internazionale dei casi di farmacovigilanza, l’Addendum II al Modulo VI GVP e i principi del GDPR richiedono un controllo serrato dei flussi in uscita. In questo articolo analizziamo cosa hanno in comune queste evoluzioni normative e perché la conformità deve essere incorporata nell’architettura del safety database.

Nel contesto della farmacovigilanza europea, le aziende farmaceutiche sono i titolari (data controller) del trattamento dei dati personali contenuti negli ICSR e restano quindi responsabili del loro utilizzo e della loro trasmissione. Questa responsabilità persiste anche quando i dati sono pseudonimizzati: nel quadro del GDPR, infatti, la pseudonimizzazione non equivale ad anonimizzazione. Un insieme di quasi-identificatori presenti nel caso può comunque rendere un soggetto indirettamente identificabile e mantenere quindi il dato all’interno della sfera dei dati personali.

Il GDPR introduce il principio di minimizzazione del dato e, soprattutto, quello di data protection by design.  Nel contesto della farmacovigilanza, questo implica che nei flussi ICSR debbano essere trasmessi solo i dati personali strettamente necessari alle finalità regolatorie, evitando la diffusione di elementi identificativi non indispensabili.

Nel caso degli ICSR, il momento più delicato non è la registrazione del caso nel safety database, ma la generazione dell’output regolatorio: XML E2B(R2/R3), CIOMS, trasferimenti verso autorità di Paesi terzi. È in questa fase che il dato interno diventa flusso strutturato.

Potrebbe interessarti anche: Trasferimento ICSR extra UE: come ottemperare al GDPR

L’Addendum II al Modulo VI GVP introduce istruzioni puntuali sui data element ICH E2B(R3), distinguendo tra campi che devono essere sempre mascherati, come i dati identificativi del reporter o i numeri di cartella clinica, campi che devono essere lasciati vuoti e campi che, pur potendo contenere dati personali, devono essere comunque trasmessi perché necessari ai processi di signal detection, duplicate detection e ICSR processing.

Queste indicazioni non sono meramente formali. Impongono che il sistema sia in grado di applicare in modo coerente le regole di masking e di esclusione previste dalla normativa, senza alterare i dati necessari ai fini regolatori.

Potrebbe interessarti anche: Addendum II modulo VI GVP: come adeguarsi alle nuove regole EMA sulla sottomissione degli ICSR

Gli ICSR contengono inevitabilmente dati personali, anche quando pseudonimizzati. Le evoluzioni normative hanno chiarito che la responsabilità del titolare non si esaurisce nella raccolta del dato, ma si estende alla sua trasmissione. A questo punto il filo logico diventa chiaro: il GDPR introduce il principio di data protection by design, l’Addendum II specifica quali campi devono essere mascherati o lasciati vuoti e le indicazioni EMA sui trasferimenti extra-UE richiamano alla minimizzazione del contenuto trasmesso. Tutte queste disposizioni convergono su un unico punto operativo: il momento dell’export. È qui che la compliance smette di essere un tema documentale e diventa una questione di architettura.

Un safety database conserva il dato completo per finalità di farmacovigilanza, audit e ispezioni. Tuttavia, non tutto ciò che è legittimamente conservato può essere trasmesso.

Qui emerge un principio fondamentale: la separazione tra dato interno e dato trasmissibile.

Un sistema evoluto deve essere in grado di conservare integralmente il caso per le finalità di safety, ma anche applicare regole di filtraggio selettivo in fase di export, generare XML R2/R3 e CIOMS conformi alle istruzioni regolatorie e modulare il livello di masking in funzione del destinatario. Se questa distinzione non è implementata a livello di sistema, il controllo si sposta sulla procedura manuale, con un aumento del rischio operativo.

In questo scenario si colloca la scelta progettuale adottata in SafetyDrugs. Il modulo GDPR introduce una modalità dedicata, denominata “Under data protection”, che agisce come layer di controllo applicato al flusso in uscita.

La configurazione consente di definire un elenco di data element soggetti a protezione e di applicare regole automatiche di sostituzione, come l’utilizzo del nullFlavor “MSK”, l’impostazione di campi vuoti, la sostituzione del country code con “EU” o “NONEU” e, ove necessario nei trasferimenti extra-UE secondo le indicazioni EMA, la sostituzione del nome commerciale con la sostanza attiva al fine di evitare l’identificazione indiretta del Paese di origine. È inoltre possibile intervenire sulle sezioni narrative con testo parametrico o oscuramento, gestire i destinatari impostando per ciascuno la modalità di invio “under data protection” e generare automaticamente XML R2/R3 e CIOMS conformi, con esclusione opzionale degli allegati.

La configurazione “Under data protection” non modifica il dato interno conservato nel database, ma viene applicata esclusivamente nella fase di esportazione. In questo modo il sistema preserva l’integrità informativa necessaria alle attività di farmacovigilanza e garantirà al contempo la minimizzazione richiesta nei flussi regolatori. La conformità non è quindi un controllo esterno al sistema, ma una logica integrata nel suo funzionamento.

Per approfondire le funzionalità del modulo GDPR e valutare come integrare un controllo strutturato dei flussi in uscita nel proprio sistema di farmacovigilanza, contatta il nostro team.