Firme elettroniche Annex 11 e Part 11: cosa si aspettano gli ispettori
Una lettura pratica dell’EU GMP Annex 11 e del 21 CFR Part 11: firme, audit trail, controllo degli accessi, ALCOA+ e revisioni periodiche, nonché le evidenze che un ispettore chiederà di vedere.
Il vostro sito sta trasferendo la revisione dei batch record, le approvazioni delle deviazioni o la firma delle SOP dalla carta a un sistema elettronico, oppure lo ha già fatto e ha un’ispezione in programma. In entrambi i casi, presto qualcuno vi chiederà di dimostrare che una firma elettronica nel vostro sistema ha lo stesso significato che aveva una firma autografa e che nessuno può modificare di nascosto un record dopo averlo firmato. Questo articolo illustra i requisiti effettivi dell’EU GMP Annex 11 e del 21 CFR Part 11 per i record e le firme elettronici, come le linee guida sull’integrità dei dati di MHRA e PIC/S traducono tali requisiti nella pratica ispettiva e quali evidenze preparare.
Due testi, un unico obiettivo
L’EU GMP Annex 11 (EudraLex Volume 4, Sistemi computerizzati) è in vigore dal 30 giugno 2011. È breve, circa cinque pagine, e basato su principi: la gestione dei rischi determina il livello di convalida e di controlli per l’integrità dei dati. Una revisione notevolmente più ampia è stata pubblicata in bozza per consultazione nel luglio 2025, insieme a un capitolo 4 rivisto e a un nuovo Annex 22 sull’intelligenza artificiale. Fino all’adozione e all’entrata in vigore del testo definitivo, sarete ispezionati rispetto alla versione del 2011, anche se la bozza offre una buona indicazione degli aspetti su cui si concentrerà l’attenzione degli ispettori.
Il 21 CFR Part 11 è la normativa statunitense per i record e le firme elettronici. È più prescrittivo dell’Annex 11 e, se fornite il mercato statunitense o siete sottoposti ad audit da un partner statunitense, dovrete rispettarlo. I due testi raramente entrano in conflitto. Laddove l’Annex 11 indica il risultato atteso, il Part 11 spesso specifica esattamente quali informazioni devono essere presenti; di conseguenza, un sistema progettato per entrambi tende a soddisfare i requisiti di ciascuno.
Firme elettroniche: significato, collegamento e identità
La clausola 14 dell’Annex 11 è lunga tre righe. Le firme elettroniche devono avere lo stesso valore delle firme autografe all’interno dei confini dell’azienda, essere collegate in modo permanente al rispettivo record e includere la data e l’ora di apposizione. La clausola 15 aggiunge che, quando un sistema registra la certificazione dei batch, solo le Qualified Persons possono certificare e devono farlo con una firma elettronica.
Il Part 11 fornisce maggiori dettagli. La sezione 11.50 richiede che un record firmato riporti il nome in stampatello del firmatario, la data e l’ora della firma e il significato della firma, ad esempio revisione, approvazione, responsabilità o paternità, e che tali dettagli compaiano in qualsiasi versione leggibile da una persona del record, inclusa una stampa o un PDF. La sezione 11.70 richiede che le firme siano collegate ai record in modo da non poter essere estratte, copiate o trasferite per falsificare un altro record. La sezione 11.100 stabilisce che ogni firma sia univoca per una persona e non venga mai riassegnata; la 11.200 richiede almeno due componenti di identificazione distinti, come un ID utente e una password, per le firme non basate su dati biometrici.
Le linee guida GXP data integrity di MHRA (sezione 6.14) sono esplicite riguardo alla scorciatoia più comune: l’immagine inserita di una firma, o una nota a piè di pagina che dichiara che un documento è stato firmato elettronicamente, non è adeguata, a meno che non provenga dal processo di firma convalidato. Le linee guida definiscono il nome visibile, il titolo, la data e il significato come «manifestazione della firma». PIC/S PI 041-1 aggiunge il test che mette in luce la maggior parte dei sistemi carenti: se un record firmato viene modificato successivamente, la firma dovrebbe essere invalidata finché il record non viene nuovamente esaminato e firmato.
Quindi, quando testate un sistema, firmate la chiusura di una deviazione e poi provate tre cose. Modificate un campo del record firmato. Stampatelo o esportatelo e verificate che la manifestazione sia ancora presente. Chiedete a un amministratore di modificare l’identità del firmatario. In un sistema ben progettato, la prima azione invalida la firma o impone la creazione di una nuova versione; la seconda mostra nome, data, ora e significato; la terza è impossibile oppure, come minimo, lascia una voce nell’audit trail che identifica l’amministratore.
Requisiti dell’audit trail nella pratica
La clausola 9 dell’Annex 11 richiede che, in base a una valutazione dei rischi, il sistema registri tutte le modifiche e le cancellazioni rilevanti per le GMP, documentandone il motivo; richiede inoltre che gli audit trail siano disponibili, convertibili in un formato generalmente comprensibile e sottoposti a revisione regolare. La sezione 11.10(e) del Part 11 richiede audit trail sicuri, generati dal computer e provvisti di timestamp, che registrino in modo indipendente le voci degli operatori e le azioni che creano, modificano o cancellano record, senza oscurare le informazioni registrate in precedenza.
Le linee guida di MHRA (sezione 6.13) descrivono il contenuto come il «chi, cosa, quando e perché» di ogni azione, includendo il fuso orario ove pertinente, e specificano che gli utenti non devono poter modificare o disattivare l’audit trail. La sezione 9.6 di PIC/S PI 041-1 va oltre. La funzionalità di audit trail dovrebbe essere abilitata e bloccata; se un amministratore può disattivarla, l’azione dovrebbe essere registrata automaticamente. Gli audit trail critici dovrebbero essere esaminati insieme agli altri record di un’operazione prima che questa sia completata, ad esempio prima del rilascio del batch. Gli audit trail non critici possono essere esaminati durante la revisione periodica del sistema.
È proprio nella revisione che i siti più spesso non sono all’altezza. Nessuno si aspetta che un revisore legga ogni evento di accesso; le linee guida di MHRA lo dicono esplicitamente. Gli ispettori si aspettano invece una decisione documentata su quali voci dell’audit trail siano rilevanti, una procedura che specifichi chi le esamina e quando, e i record che dimostrino che la revisione è stata effettuata. È accettata una revisione per eccezione: filtrate le modifiche ai campi critici, le cancellazioni, le firme apposte dopo un lungo ritardo o le modifiche effettuate dagli amministratori, quindi documentate ciò che avete riscontrato e le azioni intraprese.
Un esempio pratico. Viene aperta una deviazione per un’escursione di temperatura in una cella frigorifera. Inizialmente l’investigatore registra l’escursione come pari a 40 minuti, poi due giorni dopo la modifica a 25 minuti. L’audit trail dovrebbe mostrare entrambi i valori, chi ha effettuato la modifica, quando e perché («corretto dopo la revisione dell’esportazione del data logger»). Il revisore che approva la chiusura della deviazione dovrebbe vedere la modifica e il record della revisione dell’audit trail dovrebbe indicare che è stata esaminata. Se il campo del motivo riporta «refuso» e i dati del logger indicano 40 minuti, avete creato voi stessi una non conformità relativa all’integrità dei dati.
Controllo degli accessi
La clausola 12 dell’Annex 11 richiede controlli fisici o logici che limitino l’accesso alle persone autorizzate, in misura proporzionata alla criticità del sistema; record relativi alla creazione, alla modifica e alla revoca delle autorizzazioni di accesso; e sistemi progettati per registrare l’identità di chiunque inserisca, modifichi, confermi o cancelli dati, con data e ora. La sezione 11.10(d) e (g) del Part 11 richiede di limitare l’accesso alle persone autorizzate e di effettuare verifiche delle autorizzazioni su chi può firmare, modificare i record o eseguire operazioni.
Le linee guida di MHRA sono esplicite: non si devono usare credenziali condivise né accessi utente generici per i dati GxP, nemmeno quando gli account individuali richiedono licenze aggiuntive. L’accesso degli amministratori di sistema dovrebbe essere limitato al minor numero possibile di persone e i privilegi di amministratore non dovrebbero essere assegnati a chi ha un interesse diretto nei dati, come l’analista i cui risultati sono presenti nel sistema. PIC/S aggiunge che il sistema dovrebbe poter generare un elenco di tutti gli utenti e dei rispettivi ruoli, da utilizzare nelle revisioni periodiche degli accessi degli utenti.
In una piccola azienda è qui che la situazione si fa scomoda. Il responsabile QA è spesso anche l’amministratore di sistema. Se non è possibile evitarlo, documentate la valutazione dei rischi, mantenete un account amministratore nominativo separato da usare solo per le attività amministrative e incaricate un’altra persona di esaminare l’audit trail di quell’account.
ALCOA+ come lista di controllo operativa
Sia le linee guida di MHRA (sezione 3.10) sia PIC/S PI 041-1 utilizzano ALCOA+: Attribuibili, Leggibili, Contemporanei, Originali e Accurati, più Completi, Coerenti, Durevoli e Disponibili. MHRA precisa che le aspettative non cambiano a seconda dell’acronimo utilizzato. Il modello diventa utile quando lo si applica a un tipo di record alla volta.
| Principio | Domanda da porsi per un record elettronico di deviazione |
|---|---|
| Attribuibile | È possibile ricondurre ogni voce a una persona identificata per nome? |
| Leggibile | È possibile leggerlo e comprenderlo per tutto il periodo di conservazione, incluse le esportazioni? |
| Contemporaneo | Il sistema applica un timestamp alle voci quando vengono inserite, senza retrodatazioni? |
| Originale | I dati acquisiti per primi vengono conservati, oppure è conservata una copia autentica verificata? |
| Accurato | Le voci critiche vengono verificate e le correzioni sono tracciabili? |
| Completo | Vengono conservate tutte le versioni, gli allegati e le voci di audit, comprese quelle rifiutate o annullate? |
| Coerente | I timestamp seguono una sequenza su un orologio sincronizzato? |
| Durevole | Sopravviverà a un aggiornamento del sistema, al cambio di fornitore o a una migrazione? |
| Disponibile | È possibile produrlo per un ispettore entro i tempi richiesti? |
Applicate questa tabella ai record di deviazioni, CAPA, controllo delle modifiche e formazione: avrete le basi di una valutazione dei rischi per l’integrità dei dati.
Revisione periodica
La clausola 11 dell’Annex 11 richiede che i sistemi computerizzati siano valutati periodicamente per confermare che restino in uno stato convalidato e conformi alle GMP. La valutazione dovrebbe includere, ove appropriato, le funzionalità attuali, i record delle deviazioni, gli incidenti, i problemi, la cronologia degli aggiornamenti, le prestazioni, l’affidabilità, la sicurezza e lo stato di convalida. PIC/S PI 041-1 richiede che la frequenza sia definita in base al rischio e che la revisione tenga conto dell’effetto cumulativo delle modifiche dall’ultima revisione.
Per un eQMS cloud che riceve diversi aggiornamenti all’anno, l’aspetto cumulativo è importante. Ogni aggiornamento potrebbe aver superato la propria valutazione d’impatto, ma nel corso di un anno l’insieme degli aggiornamenti può cambiare il flusso di approvazione o ciò che viene registrato nell’audit trail. Una revisione annuale efficace confronta il sistema convalidato con quello effettivamente in uso, verifica nuovamente gli accessi degli utenti, esamina a campione i record delle revisioni dell’audit trail, conferma che sia stato testato un ripristino da backup (Annex 11, clausola 7.2) e si conclude con una conclusione firmata: il sistema è ancora in uno stato convalidato oppure no, con le relative azioni da intraprendere.
Cosa chiedono di vedere gli ispettori
Di solito gli ispettori vi chiederanno di mostrare il sistema in tempo reale anziché consultare un raccoglitore. Aspettatevi richieste di questo tipo:
- L’inventario dei sistemi computerizzati e delle relative funzioni GMP (Annex 11, clausola 4.3).
- Il riepilogo della convalida del sistema in esame e il modo in cui i requisiti utente sono tracciati rispetto ai test.
- Un record firmato, seguito da una dimostrazione di cosa accade quando qualcuno prova a modificarlo.
- L’audit trail di un record specifico scelto dall’ispettore e il record della relativa revisione.
- L’elenco aggiornato degli utenti con i rispettivi ruoli e l’ultima revisione periodica degli accessi.
- L’accordo con il fornitore del sistema e la vostra valutazione del fornitore (Annex 11, clausola 3).
- L’ultimo rapporto di revisione periodica e le evidenze di un ripristino da backup.
- Per i record di rilascio dei batch, una stampa che mostri se i dati sono stati modificati dopo l’inserimento originale (Annex 11, clausola 8.2).
Esercitatevi. Chiedete alla persona che guiderà la dimostrazione di fare una prova su un record di test, con un collega indipendente nel ruolo dell’ispettore e libero di scegliere il record.
In sintesi
Annex 11 e Part 11 chiedono la stessa cosa con parole diverse: una firma deve identificare una sola persona, dichiarare il significato della firma, restare legata esattamente al record firmato e mantenere queste caratteristiche anche in stampa; un audit trail deve mostrare chi ha modificato cosa, quando e perché, e qualcuno deve esaminarlo. Questa settimana scegliete tre tipi di record, applicate la tabella ALCOA+ e i test sulle firme e correggete ciò che non supera i controlli prima che lo trovi un ispettore.
Se desiderate eseguire questi test su un sistema progettato per i produttori regolamentati, InnoQualis è un eQMS ospitato nell’UE con un audit trail append-only e firme elettroniche progettate per supportare il 21 CFR Part 11 e l’EU GMP Annex 11.
