Seguiteci su Linkedin

LA GOVERNANCE DEI DATI: QUESTIONE ANCHE DI RESPONSABILITA’ E CONSAPEVOLEZZA

Lunedì 15 Aprile 2019

Alcuni accorgimenti per garantire la sicurezza dei dati, gestire l'Audit Trail e assicurare la conformità dei propri sistemi alla Data Integrity.

Durante il seminario "Digitalizzazione dei processi e dei flussi aziendali", lo scorso 4 aprile a Cavenago di Brianza, Pier Luigi Agazzi, Senior Consultant e partner di Adeodata, è intervenuto sulla governance dei dati, proponendo misure utili alla gestione di questo tema così delicato.



Perché avere una policy?


Quando si identifica un problema di Data Integrity siamo abituati a cercare delle soluzioni tecniche adeguate. Ma questo rischia di farci sottovalutare alcuni fattori. Il modello anglosassone prevede, invece, che venga fatta una policy che tenga conto degli aspetti motivazionali, comportamentali e organizzativi, prima di procedere con le azioni risolutive. La policy corrisponde, infatti, a un documento programmatico generale in cui vengono considerati tutti questi fattori, vengano definite le responsabilità e solo allora pianificate le attività. Le linee guida sulla governance dei dati sono di origine anglosassone e non a caso seguono questo modello.

 

Le linee guida GAMP sulla Data Integrity indicano gli argomenti da inserire nella policy, il documento programmatico generale sulla governance dei dati.

 

Per garantire la sicurezza dei dati è necessario, infatti, lavorare su aspetti culturali e di sensibilizzazione del personale addetto. In questo caso il training è fondamentale per far capire come semplici azioni quotidiane apparentemente innocue possano, in realtà, minacciare la sicurezza dei dati: come una password scritta su un post-it in ufficio o su un pezzo di nastro adesivo su una autoclave. È vero che le misure tecnologiche sono importanti, ma non sono sufficienti.

 

Raw, Master & Control Data


All’interno dei nostri sistemi, se vogliamo gestire i dati in modo sostenibile, possiamo distinguere le varie tipologie di dati che vengono memorizzati su una apparecchiatura di processo o di uno strumento di laboratorio.

 

In primis ci sono i dati di sistema, che sono impostazioni legate ad esempio alla velocità, set up, tuning, ecc. del sistema utilizzato, ma non sono correlati al prodotto. Poi ci sono i master data, che sono i dati (e le istruzioni) specifiche di un certo prodotto, per la sua produzione o analisi. Includono ad esempio la ricetta di produzione, i metodi analitici o i cicli di sterilizzazione. Infine, ci sono i control data, ovvero le registrazioni relative a come sono andate veramente le attività di produzione e di analisi di uno specifico lotto di produzione.

 

Ad esempio, i master data sono dati anagrafici fissi raccolti nei master batch record, a indicazione di una serie di obiettivi da raggiungere per la produzione di un certo lotto. Una volta eseguita la produzione del lotto, il master batch record viene compilato registrando l’effettivo valore ottenuto per ciascuno dei parametri master. In questo modo diventa un control batch record. Dunque, mentre il master batch record indica come devono andare le cose, il secondo tiene conto di come sono andate realmente. Nel valutare la criticità dei dati va detto che i control data sono più critici perché indicano l’andamento reale (non quello desiderato) di un lotto. Sono infatti questi quelli che vengono utilizzati per il rilascio di un lotto.

 

Mentre i dati di sistema sono piuttosto statici e impostati dal fornitore o istallatore del sistema all’inizio delle operazioni. Anche i master data sono dati abbastanza stabili che vengono impostati per ogni prodotto. Sia i dati di sistema che i master data sono solitamente oggetto di Change Control e sono oggetto di verifiche periodiche o audit interni del QA, ma non necessitano di essere rivisti prima del rilascio di ogni lotto.

 

E l’Audit Trail?


L’Audit Trail (AT), richiesto come requisito regolatorio (sia dall’annex 11 alle EU GMP che dal 21 CFR part 11) sarebbe la versione elettronica della correzione GMP. Infatti, quando si corregge un dato elettronico, le informazioni relative al valore che c’era scritto in precedenza e a chi l’ha corretto, quando e perché non verrebbero registrate se non fosse disponibile l’Audit Trail. L’AT viene quindi definito come un metadato, ovvero una informazione che serve a contestualizzare il dato a cui si riferisce. Occorre precisare che essendo un meccanismo di protezione dei dati in formato elettronico, l’AT non comprende la registrazione dei login e dei logout o la sequenza dell’attività produttiva. Semmai l’informazione su chi ha fatto che cosa (al di fuori delle modifiche ai dati) viene registrato nei batch record o nei quaderni di laboratorio. Quindi attenzione a non arricchire gli Audit Trail con dati che non c’entrano.

 

Parlando di revisione dell’Audit Trail possiamo dire che siamo abituati a (ri)vedere e a valutarle le correzioni GMP sulle registrazioni cartacee, mentre l’AT elettronico rimane spesso ignorato in qualche cartella del sistema. Al contrario, la verifica dell’AT dovrebbe avvenire analogamente alla verifica delle correzioni GMP.

 

Ecco dunque che la precedente classificazione dei dati diventa importante quando si tratta di determinare la frequenza di revisione dell’Audit Trail. La revisione dell’AT deve avvenire contestualmente con la revisione dei dati cui l’AT si riferisce o, detto in altro modo, si devono rivedere i dati con i relativi metadati e tra essi l’AT.

 

Quando rivedo i control data specifici di un lotto devo rivedere anche il relativo Audit Trail, non necessariamente i raw data e i master data ed i relativi AT.

 

Un’utile considerazione a questo proposito va fatta sui dati acquisiti automaticamente. Molto spesso i dati in formato elettronico relativi ad un lotto, i control data, vengono registrati automaticamente dal sistema (sono solitamente pochi i sistemi in cui i dati vengono registrati dall’operatore a seguito di osservazioni che fa sul campo). Tipicamente i dati acquisti automaticamente non sono modificabili dall’operatore, si pensi alla temperatura durante una sterilizzazione, alla sovrapressione di un locale durante la lavorazione, ma anche ai dati grezzi di un HPLC durante una analisi. Essendo non modificabili (ma questo andrebbe verificato in convalida) questi dati non necessitano di Audit Trail, né di revisione dell’Audit Trail. Quindi la revisione dell’AT si applica solo ai parametri modificabili dall’operatore durante la lavorazione come ad esempio i parametri strumentali dell’HPLC o l’impostazione della temperatura delle piastre di una blisteratrice.

 

Alcuni sistemi sono dotati di meccanismi che evidenziano (sulle stampe o in visualizzazione) se sono state fatte delle modifiche (e quindi se occorre rivedere l’AT), agevolando molto la verifica dell’AT in quanto indicano quando tale verifica sia necessaria o consentendo di selezionare le registrazioni dell’Audit Trail che interessano.

 

La sicurezza dei dati


Il primo aspetto è la gestione della sicurezza dei dati: dalla protezione dei sistemi da perdite accidentali di dati, agli accessi consentiti solo agli utenti autorizzati. Per quest’ultima sono disponibili diverse misure: con un login al sistema attraverso le credenziali di accesso; utilizzando profili-utente diversificati in relazione alla funzione e al grado di responsabilità del soggetto; limitando l’accesso ad alcune cartelle del sistema. Infine, nel caso di sistemi aperti (quando i dati transitano in Internet) è indispensabile che vengano crittografati.

 

Può essere utilizzata una qualsiasi combinazione di queste misure per limitare l’accesso ai soli utenti autorizzati, cioè che siano stati istruiti sull’utilizzo del sistema. Inoltre, queste misure devono prevenire la possibilità di modificare la data e l’ora del sistema o di cancellare i (files di) dati.

 

Nel caso di dati modificabili dall’operatore deve essere possibile generare l’Audit Trail, quindi occorrono delle credenziali di accesso individuali.

 

 

Adeodata S.r.l.
Via E. Mattei, 2

22070 Bregnano (CO)

 

 

Sede legale:

Via Carducci, 32 — 20123 Milano

P.IVA 05617310965

REA 1834791 Milano

PEC adeodata@pec.it

Adeodata SA
Via Calgari, 2

CH 6900 Lugano

IDI CHE-112.203.579

© 2019 Adeodata. All rights reserved.

Designed and developed by Carrara Communication