Il software di un Environmental Monitoring System è la parte del sistema che produce il record, e quindi la parte su cui si concentra la maggior parte delle domande in ispezione. Chi può modificare una soglia, chi può invalidare un dato, come si dimostra che un valore non è stato alterato, chi rivede l'audit trail e con quale criterio, dove sono i dati di cinque anni fa e chi può ancora leggerli: sono domande che riguardano la configurazione e la gestione del software, non la qualità degli strumenti di misura.
La regola di fondo è che la data integrity si progetta, non si aggiunge. Ruoli, permessi, tracciabilità e conservazione vanno definiti prima della configurazione: dopo il rilascio in esercizio, ogni correzione strutturale richiede change control, ri-verifica e spesso interventi sui dati già prodotti. La seconda regola è che occorre distinguere con precisione che cosa è un requisito regolatorio applicabile al proprio contesto e che cosa è una scelta aziendale: confondere i due piani porta a spendere dove non serve e a scoprire lacune dove sarebbe servito.
Perché il software è il punto più esposto del sistema
Un sistema di monitoraggio ambientale computerizzato concentra tre funzioni che, in un mondo cartaceo, sarebbero separate: acquisisce il dato, lo elabora e lo conserva, e ne consente la revisione. Chi controlla il software controlla, potenzialmente, tutte e tre. È questa concentrazione che rende necessari i controlli su accessi, segregazione dei compiti e tracciabilità delle modifiche.
La seconda ragione è la durata. Gli strumenti si sostituiscono; i dati restano per l'intero periodo di conservazione applicabile, e devono restare leggibili e ricostruibili anche quando il sistema che li ha generati non esiste più. Le decisioni prese oggi sui formati, sull'esportabilità e sull'archiviazione determinano se fra anni sarà possibile rispondere a una domanda su un lotto prodotto oggi.
Il quadro regolatorio: che cosa si applica davvero
| Livello | Cosa stabilisce rispetto al software EMS |
|---|---|
| Requisito regolatorio (EudraLex Volume 4, Annex 11 — revisione di gennaio 2011) | È la versione applicabile. Si applica ai sistemi computerizzati impiegati in attività GMP e fissa aspettative su validazione, gestione dei fornitori, sicurezza e gestione degli accessi, audit trail, controllo delle modifiche, backup e archiviazione, gestione degli incidenti, continuità e periodic evaluation. |
| Testo in consultazione (revisione dell'Annex 11 in corso) | Non è un requisito vigente. Può essere considerato per orientare scelte progettuali destinate a durare, purché sia dichiarato esplicitamente come elemento prospettico. Non va mai usato come criterio di accettazione in qualifica né citato come obbligo. |
| Requisito regolatorio (21 CFR Part 11, FDA) | Si applica ai record elettronici e alle firme elettroniche nell'ambito dei prodotti soggetti alla regolamentazione FDA e dei relativi predicate rule. La sua applicabilità al proprio sistema va determinata e documentata: non è automatica per un sito che non fornisce il mercato statunitense. |
| Requisito regolatorio (EudraLex Volume 4, Annex 15) | Definisce l'impianto della qualifica e della validazione, applicabile anche alla componente computerizzata. |
| Aspettativa / guidance (documenti PIC/S sulla data integrity, guidance delle autorità, ICH Q9(R1)) | Chiariscono le aspettative su completezza, attribuibilità, leggibilità, contemporaneità, originalità e accuratezza dei dati, e sull'approccio basato sul rischio nella loro gestione. |
| Buona pratica di settore | Modelli di categorizzazione del software e approcci strutturati alla validazione dei sistemi computerizzati diffusi nel settore. Sono metodologie riconosciute, non prescrizioni regolatorie. |
| Raccomandazione operativa GuideGxP | Redigere una valutazione di applicabilità scritta — quali requisiti si applicano al sistema, perché, e quali no — approvata prima della configurazione. È il documento che rende difendibile ogni scelta successiva. |
Guida tecnica
Ruoli utente e segregation of duties
La matrice dei ruoli va definita prima della configurazione, non ricavata dai profili predefiniti del fornitore. I principi:
- Identificazione univoca: ogni utente ha credenziali personali e non condivise; le utenze generiche di reparto sono una delle osservazioni più comuni.
- Privilegio minimo: ciascun ruolo dispone dei soli permessi necessari alla propria funzione.
- Separazione dei compiti: chi configura il sistema non dovrebbe essere la stessa persona che rivede i record prodotti; chi opera non dovrebbe poter modificare i parametri che governano il proprio operato.
- Amministrazione di sistema: i privilegi amministrativi vanno assegnati a un numero ristretto di persone, preferibilmente esterne alla funzione che utilizza operativamente il sistema, con attività tracciate.
- Ciclo di vita degli account: creazione, modifica, sospensione e disattivazione vanno gestite con un processo definito, collegato ai movimenti del personale.
- Accessi del fornitore: temporanei, autorizzati caso per caso, tracciati e revocati al termine dell'intervento.
Audit trail: contenuto e revisione
Un audit trail utile risponde, per ogni evento rilevante, a quattro domande: chi, che cosa, quando e perché. Gli elementi da verificare in fase di specifica e di qualifica:
- copertura degli eventi rilevanti: creazione, modifica e invalidazione dei record, modifiche di configurazione e di soglie, gestione degli allarmi, eventi di accesso;
- impossibilità di disattivazione o alterazione da parte degli utenti, amministratori inclusi;
- presenza del motivo della modifica dove la modifica è consentita;
- leggibilità in forma comprensibile senza strumenti del fornitore;
- possibilità di filtrare e revisionare in modo efficiente: un audit trail tecnicamente completo ma non revisionabile nella pratica non assolve la sua funzione;
- conservazione per l'intero periodo richiesto per i record cui si riferisce.
La revisione dell'audit trail va pianificata con un approccio basato sul rischio: quali eventi vengono rivisti, da chi, con quale frequenza e con quale evidenza della revisione. La frequenza non discende da una regola generale ma dalla criticità dei dati e dal processo aziendale, e va giustificata per iscritto.
Record elettronici, firme e gestione dei dati
- Definizione del record grezzo: stabilire che cosa costituisce il dato originale e dove risiede è il presupposto di ogni controllo successivo.
- Metadati: il record non è solo il valore; comprende le informazioni che ne consentono l'interpretazione e la ricostruzione.
- Firme elettroniche: se impiegate, vanno definite le operazioni che le richiedono, il significato della firma e i controlli associati. Se il contesto non le richiede, va documentata la scelta di non impiegarle.
- Gestione dei dati anomali: la possibilità di escludere o annotare un dato deve essere governata da procedura, con motivazione registrata e tracciabilità completa. La cancellazione di dati grezzi non è una funzione da configurare.
- Esportazioni e report: vanno verificati come parte della qualifica; un report che presenta i dati in modo incompleto o fuorviante è un problema di sistema, non di utilizzo.
Configurazione, personalizzazione e validazione
L'impegno di validazione dipende da quanto il sistema si discosta dal prodotto standard. Un sistema configurato con parametri previsti dal fornitore comporta un impegno diverso da un sistema con sviluppi specifici per il cliente. Il criterio operativo: ogni elemento configurato o sviluppato deve essere documentato, giustificato e verificato, e la documentazione di configurazione deve essere mantenuta aggiornata come parte del sistema, non archiviata a fine progetto.
La valutazione del fornitore — capacità di sviluppo, gestione delle versioni, supporto, documentazione disponibile — fa parte dell'impianto e va documentata; il suo esito influenza legittimamente la profondità delle verifiche da eseguire in proprio.
Conservazione, archiviazione e migrazione
- Periodo di conservazione: definito in coerenza con i requisiti applicabili ai record cui i dati si riferiscono.
- Leggibilità nel tempo: il formato di archiviazione deve restare interpretabile anche in caso di dismissione del sistema; la dipendenza esclusiva da un formato proprietario è un rischio da valutare esplicitamente.
- Migrazione: ogni trasferimento di dati storici richiede un piano, criteri di verifica di completezza e accuratezza, ed evidenza del risultato.
- Strategia di uscita: come si accede ai dati dopo la fine del contratto o del supporto è una domanda da porre in fase di gara, non alla dismissione.
Periodic review del sistema computerizzato
Il sistema va rivisto periodicamente per confermare che sia ancora in stato di controllo: modifiche intervenute, incidenti registrati, deviazioni, esito delle revisioni dell'audit trail, gestione degli accessi, stato del supporto e dell'obsolescenza, prove di ripristino eseguite. La periodic review non è una ripetizione della qualifica: è una verifica documentata che le assunzioni su cui la qualifica poggiava sono ancora valide.
Strumento operativo: checklist di configurazione data-integrity-oriented
| Area | Da definire prima della configurazione | Evidenza attesa |
|---|---|---|
| Accessi | Matrice ruoli-permessi approvata | Documento approvato e configurazione corrispondente verificata |
| Accessi | Processo di gestione del ciclo di vita degli account | Procedura e registrazioni |
| Audit trail | Elenco degli eventi tracciati | Verifica in OQ su ciascun tipo di evento |
| Audit trail | Piano di revisione basato sul rischio | Procedura con frequenza giustificata e registrazioni di revisione |
| Dati | Definizione di record grezzo e metadati | Documento di sistema |
| Dati | Regole per la gestione dei dati anomali | Procedura e tracciabilità in sistema |
| Soglie e allarmi | Chi può modificarli e con quale autorizzazione | Configurazione dei permessi e tracciamento delle modifiche |
| Report | Report previsti e loro verifica | Verifica in OQ contro i dati sorgente |
| Conservazione | Periodo, formato e collocazione | Politica documentata |
| Ripristino | Prova di restore nella configurazione reale | Report della prova |
| Fornitore | Valutazione documentata | Rapporto di valutazione |
| Applicabilità | Quali requisiti si applicano e perché | Valutazione di applicabilità approvata |
Scenario pratico
In un sito che chiameremo Sito Delta — esempio realistico ma di fantasia — il gruppo di progetto configura l'EMS utilizzando i profili utente predefiniti proposti dal fornitore, per non ritardare l'avvio. Il profilo destinato ai supervisori di reparto include, per comodità operativa, la possibilità di modificare le soglie di allarme.
La qualifica si chiude senza rilievi: il sistema fa esattamente ciò che è stato configurato per fare. Il problema emerge alla prima revisione periodica, quando l'audit trail mostra modifiche di soglia effettuate da personale operativo durante le lavorazioni. Nessuna di quelle modifiche era irregolare secondo la configurazione; tutte erano incompatibili con il principio di separazione tra chi opera e chi definisce i parametri che governano l'operatività.
La correzione — ridefinire la matrice dei ruoli, riconfigurare i permessi, ri-verificare, valutare retrospettivamente le modifiche già avvenute e documentarne l'impatto — richiede un impegno molto superiore a quello che sarebbe servito per definire la matrice prima della configurazione. È il caso tipico in cui il tempo risparmiato all'inizio viene restituito con gli interessi.
Errori comuni e segnali di allarme
- Adottare i profili utente predefiniti del fornitore. Rispecchiano un'ipotesi organizzativa generica, non la separazione dei compiti del sito.
- Utenze condivise o generiche. Rendono impossibile l'attribuibilità, che è il primo dei principi di data integrity.
- Audit trail attivo ma mai rivisto. La registrazione senza revisione non produce controllo; l'assenza di un piano di revisione giustificato è un rilievo frequente.
- Citare l'Annex 11 in revisione come requisito vigente. La versione applicabile resta quella di gennaio 2011; un testo in consultazione non è un obbligo.
- Assumere che la Part 11 si applichi sempre. L'applicabilità va determinata e documentata; assumerla senza analisi porta a controlli non giustificati, negarla senza analisi porta a lacune.
- Non definire il record grezzo. Senza questa definizione, ogni discussione su integrità e conservazione resta ambigua.
- Configurare la possibilità di cancellare dati. La gestione dei dati anomali si fa con annotazione tracciata, non con rimozione.
- Trascurare l'esportabilità e la migrazione. Sono i temi che rendono costosa o impossibile la sostituzione del sistema anni dopo.
- Trattare la periodic review come una formalità. È lo strumento con cui si dimostra che il sistema è ancora in stato di controllo.
Come documentare
- Valutazione di applicabilità: quali requisiti si applicano al sistema e perché, quali no e con quale motivazione.
- Matrice ruoli-permessi approvata con il razionale della separazione dei compiti.
- Specifica di configurazione mantenuta aggiornata come documento vivo.
- Piano di revisione dell'audit trail con frequenza giustificata e responsabilità assegnate.
- Definizione di record grezzo, metadati e periodo di conservazione.
- Valutazione del fornitore e sua influenza sulla strategia di verifica.
- Report di qualifica della componente computerizzata, con tracciabilità rispetto ai requisiti.
- Registrazioni di periodic review e azioni conseguenti.
Punti chiave
- La data integrity si progetta prima della configurazione: dopo, ogni correzione costa molto di più.
- La versione applicabile dell'Annex 11 è quella di gennaio 2011; un testo in consultazione non è un requisito.
- L'applicabilità della Part 11 va determinata e documentata, non assunta.
- Un audit trail non revisionabile nella pratica non assolve la propria funzione.
- La separazione dei compiti è una scelta organizzativa che si traduce in configurazione, non il contrario.
- Esportabilità, archiviazione e strategia di uscita si negoziano in gara, non alla dismissione.
Domande frequenti
Quale versione dell'Annex 11 è applicabile?
La revisione di gennaio 2011 resta la versione applicabile. Un testo in consultazione può essere considerato per orientare scelte destinate a durare, ma va sempre dichiarato come tale e non può essere usato come criterio di accettazione in qualifica.
La 21 CFR Part 11 si applica al nostro EMS?
Dipende dal contesto: si applica ai record elettronici e alle firme elettroniche nell'ambito dei prodotti soggetti alla regolamentazione FDA e dei relativi predicate rule. La determinazione va fatta caso per caso e documentata in una valutazione di applicabilità approvata.
Con quale frequenza va rivisto l'audit trail?
Non esiste una frequenza universale. Va definita con approccio basato sul rischio, in funzione della criticità dei dati e del processo, e giustificata per iscritto insieme all'ambito della revisione e alle responsabilità.
Si possono usare utenze di reparto quando più operatori si alternano?
No, se i record devono essere attribuibili a una persona. L'attribuibilità è uno dei principi fondamentali di data integrity; esigenze operative di rapidità vanno risolte con soluzioni tecniche di autenticazione, non con la condivisione delle credenziali.
Chi dovrebbe poter modificare le soglie di allarme?
Non chi opera sotto quelle soglie. La scelta specifica dipende dall'organizzazione, ma il principio di separazione tra esecuzione e definizione dei parametri va rispettato e documentato nella matrice dei ruoli.
Che cosa succede ai dati quando si sostituisce il sistema?
Devono restare leggibili e ricostruibili per l'intero periodo di conservazione. Le opzioni — migrazione verso il nuovo sistema, archiviazione in formato indipendente, mantenimento in sola lettura del vecchio sistema — vanno valutate con un piano documentato. Il tema si collega alla sostituzione di sistemi esistenti, trattata nell'articolo sul retrofit di un EMS.
Riferimenti normativi e tecnici
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Commissione europea): Annex 11 (revisione gennaio 2011), Annex 15 (in vigore dal 1° ottobre 2015), Annex 1 (applicabile dal 25 agosto 2024).
- 21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR).
- PIC/S — Guides and Guidance Documents, inclusa la guidance sulla data integrity negli ambienti regolamentati.
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
Continua il percorso progettuale
Questo articolo fa parte del percorso Environmental Monitoring Systems di GuideGxP, che segue il ciclo di vita di un progetto EMS dalla definizione dei requisiti fino alla gestione in esercizio.
- A monte: la URS del sistema e l'infrastruttura di rete e alimentazione.
- A valle: FAT, SAT, IQ, OQ e PQ del sistema e gestione in esercizio.
- Fondamenti regolatori GuideGxP: data integrity, ALCOA+ e audit readiness secondo l'Annex 11.
Vuoi ricevere analisi come questa direttamente via email? Iscriviti a The Pragmatic GMP, la newsletter GuideGxP dedicata a chi lavora ogni giorno con GMP, qualifica e data integrity.
