Pharma Engineering Insights

Automation e Data Integrity nei Sistemi di Sterilizzazione: recipe, alarm, audit trail e cycle record

Ricette e dati devono rendere ricostruibile il ciclo eseguito. Architettura, accessi, audit trail, guasti, backup e prove per sistemi di sterilizzazione.

A Aldo Xhango 9 min di lettura
✓ Fonti e riferimenti ufficiali ✓ Approccio operativo ✓ Per professionisti del pharma
GUIDEGXP · PRACTICAL GMP INSIGHTS
Quadro PLC e postazione di controllo dei dati per un sistema di sterilizzazione

Una ricetta viene modificata dopo una prova di sviluppo, ma il report conserva soltanto il nome del ciclo. Il processo successivo termina senza allarmi e il lotto viene collegato a un PDF che non identifica la versione utilizzata. La macchina può avere eseguito correttamente la propria logica, ma manca il collegamento tra parametri approvati, configurazione effettiva e materiale trattato. È questo collegamento che l'automazione deve rendere verificabile.

1. Definire il confine del sistema computerizzato

Il sistema comprende più del PLC. Considerare HMI, registratore indipendente, historian, server, database, gestione degli utenti, sincronizzazione temporale, backup e interfacce con MES o sistemi di qualità. Identificare dove nascono i dati, dove vengono trasformati e dove sono conservati. Un diagramma dei flussi deve descrivere anche comunicazioni interrotte e funzionamento temporaneamente autonomo.

Distinguere controllo del processo e gestione documentale. Una ricetta approvata nel sistema qualità non dimostra che gli stessi parametri siano attivi nel PLC. Una registrazione corretta nel PLC non prova che l'esportazione abbia conservato tutti gli eventi. Le interfacce sono parte dell'uso previsto e devono essere incluse nella valutazione.

[REGULATORY REQUIREMENT] EU GMP Annex 11 richiede un approccio al ciclo di vita basato sul rischio per i sistemi computerizzati utilizzati nelle attività GMP. Il testo vigente elencato da EudraLex al momento della verifica è quello del 2011; eventuali proposte di revisione non devono essere presentate come requisiti già applicabili.

2. Trasformare la strategia di processo in stati verificabili

Descrivere la sequenza come stati e transizioni: pronto, carico identificato, condizionamento, esposizione, asciugatura o raffreddamento, completamento, anomalia e arresto. Per ogni transizione definire condizioni necessarie, timeout, eventi registrati e stato delle uscite. Il comportamento deve essere comprensibile anche senza leggere il codice sorgente.

La transizione all'esposizione deve riflettere la strategia validata. Se dipende da più misure, chiarire come sono trattati valori mancanti o non validi. La perdita di un segnale non deve essere interpretata accidentalmente come soddisfacimento della condizione. Lo stesso principio vale per fine ciclo, autorizzazione allo scarico e passaggio verso un'area più critica.

[GEP] Utilizzare una matrice causa-effetto per interblocchi e allarmi critici. Documentare evento, fase, azione, stato sicuro e condizioni di ripristino. La matrice sostiene sviluppo, revisione e prove, riducendo le differenze tra specifica funzionale, programma e procedura operativa.

3. Gestire ricette e parametri come configurazioni controllate

Ogni ricetta deve avere identità, versione, stato e ambito di utilizzo. Separare ricette di sviluppo, test e produzione, con regole che impediscano l'uso involontario di configurazioni non approvate. Definire quali parametri siano fissi, quali selezionabili e quali modificabili entro limiti autorizzati.

La revisione deve confrontare contenuto precedente e nuovo, motivazione, impatto e approvazioni richieste. Il record di ciclo deve identificare la versione effettivamente eseguita e conservare i valori necessari a ricostruire la sequenza. Registrare soltanto il nome «ciclo componenti» non consente di distinguere configurazioni diverse con la stessa etichetta.

Considerare il momento in cui la ricetta viene caricata nel controllore. Se una modifica viene approvata mentre un ciclo è già in esecuzione, deve essere chiaro quale versione governa quel ciclo. Le prove devono verificare che aggiornamenti o sincronizzazioni non cambino silenziosamente i parametri di una sequenza attiva.

4. Progettare accessi coerenti con le responsabilità

Definire ruoli per operatore, supervisore, manutenzione, amministratore e revisore. Assegnare i privilegi necessari alle attività e distinguere l'esecuzione del ciclo dalla modifica della configurazione. Valutare la separazione delle responsabilità per le operazioni critiche, tenendo conto della struttura del sito e delle misure compensative documentate.

Gli account devono consentire di attribuire le azioni alle persone autorizzate. Le credenziali condivise riducono questa capacità e richiedono una valutazione concreta delle limitazioni del sistema. L'accesso di servizio del fornitore deve avere scopo, autorizzazione, durata e registrazione coerenti con le procedure del sito.

Provare creazione, modifica, disattivazione e scadenza degli accessi, oltre al login ordinario. Verificare cosa accade a una sessione aperta quando un ruolo viene revocato e come vengono gestiti account non più utilizzati. Le funzioni amministrative devono essere incluse nella verifica, perché possono modificare i controlli su cui si basa la fiducia nei dati.

5. Rendere l'audit trail utile alla revisione

L'audit trail deve permettere di capire chi ha eseguito un'azione, quando, su quale elemento e con quale risultato. Per modifiche rilevanti, conservare valori precedenti e successivi e la motivazione quando richiesta. La configurazione del tracciamento deve essere protetta e verificata per le funzioni che possono influenzare processo o record.

Non tutte le voci hanno lo stesso significato. Una modifica della ricetta, la disabilitazione di un allarme, un cambio di orologio e un tentativo di accesso fallito sostengono valutazioni diverse. Definire quali eventi vengono riesaminati per ciclo, quali periodicamente e quali richiedono un intervento immediato. La frequenza deve essere motivata dal rischio e dall'uso.

Una funzione di esportazione deve mantenere ordine, identità e contesto delle voci. Verificare filtri, paginazione e intervalli temporali per evitare che una stampa apparentemente completa ometta eventi. Conservare anche la possibilità di recuperare i dati originali: uno screenshot non è un sostituto generale del record elettronico.

6. Collegare allarmi, abort e restart

Un abort interrompe o porta in sicurezza la sequenza secondo una logica definita. Il restart può comportare ripresa, nuova sequenza o divieto di continuazione, a seconda del processo. Questi comportamenti devono essere stabiliti durante lo sviluppo e validati; non possono dipendere soltanto dalla preferenza dell'operatore al momento del guasto.

Definire quali eventi rendano non dimostrabile la prestazione del ciclo, anche se non provocano un danno meccanico. Perdita di dati critici, errore di ricetta o mancata verifica di una condizione possono richiedere una gestione diversa da un semplice avviso. Il messaggio finale deve rappresentare correttamente lo stato e non cancellare la storia precedente.

Al riavvio dopo perdita di alimentazione, il sistema deve riconoscere lo stato del ciclo interrotto e rendere disponibili le informazioni conservate. Le prove devono valutare i diversi momenti della sequenza. Un riavvio riuscito del PLC dimostra disponibilità tecnica, non la conformità del carico presente durante l'interruzione.

7. Definire il record originale e le copie

Stabilire quali dati costituiscono il record necessario alla decisione GMP e dove risiedono. Includere identificazione del carico, versione della ricetta, valori effettivi, eventi, metadati e approvazioni pertinenti. Se il record è distribuito, documentare collegamenti e responsabilità di conservazione.

Un PDF può essere una copia utile per la revisione, ma occorre dimostrare che conservi le informazioni necessarie per l'uso previsto. Dati dinamici, audit trail o dettagli non esportati possono richiedere la disponibilità del sistema originale o di un archivio adeguato. La scelta deve essere giustificata, non basata soltanto sulla facilità di stampa.

Verificare completezza e accuratezza dei trasferimenti verso historian o MES. Considerare duplicati, ritardi, record fuori ordine e perdita temporanea della rete. Le regole di riconciliazione devono rendere visibili i problemi, impedendo che un report venga dichiarato completo quando manca una parte dei dati.

8. Matrice delle prove essenziali

Funzione Scenario da verificare Evidenza attesa
Ricetta Modifica approvata prima e durante un ciclo Versione applicata inequivocabile e controllata
Accessi Utente senza privilegio tenta una modifica critica Azione impedita e tracciamento pertinente
Allarme Perdita di una misura critica in esposizione Risposta, esito e dati coerenti con la specifica
Comunicazione Interruzione tra PLC e sistema di registrazione Lacuna rilevata e recupero riconciliato
Backup Ripristino su configurazione autorizzata Dati leggibili, integri e utilizzabili
Orologio Cambio autorizzato o perdita di sincronizzazione Sequenza temporale ricostruibile

Gli scenari sono una base operativa [GUIDEGXP RECOMMENDATION], non un elenco normativo esaustivo. Il piano deve includere i rischi specifici del sistema e criteri definiti prima dell'esecuzione. Una prova soddisfacente deve dimostrare il comportamento richiesto, non soltanto l'assenza di un messaggio di errore.

9. Backup, ripristino e continuità operativa

Il backup deve comprendere dati e configurazioni necessari al recupero. Identificare ricette, programmi, parametri, utenti, certificati e componenti pertinenti secondo l'architettura. Proteggere le copie e verificare che il processo funzioni. La presenza di un file nella cartella di destinazione non dimostra che il ripristino sia possibile.

Le prove di restore devono mostrare che il sistema recuperato è utilizzabile e che i record restano completi e leggibili. Definire le condizioni di esecuzione della prova per evitare effetti sulla produzione. Documentare versione, ambiente, dati campione e risultato, con una valutazione delle limitazioni del test.

La continuità operativa deve chiarire cosa fare quando il sistema elettronico non è disponibile. Una procedura manuale temporanea è accettabile solo se prevista, adeguata e capace di preservare i controlli necessari. Non introdurre registrazioni retroattive prive di evidenza per colmare una perdita di dati.

10. Esempio: report completo, dati incompleti

In un caso illustrativo, il PDF riporta l'esito positivo del PLC, mentre l'historian ha perso la connessione durante una fase critica. La ricostruzione mostra che il controllore possiede alcuni dati locali, ma il sistema di stampa non segnala la lacuna. Il team sospende l'accettazione automatica e valuta la disponibilità delle evidenze originali.

L'indagine distingue la prestazione fisica dalla completezza del record e verifica se i dati locali consentano una ricostruzione affidabile. La correzione comprende la segnalazione dei trasferimenti incompleti e una procedura di riconciliazione. Le prove successive includono la perdita di connessione, il recupero e la prevenzione dei duplicati.

La lezione operativa è che il formato del report non deve creare un'apparenza di completezza superiore ai dati disponibili. Il risultato finale deve esplicitare lo stato del record e le eccezioni. Il sistema qualità decide sul materiale sulla base delle evidenze effettive, non dell'impaginazione del documento.

11. Validazione e gestione del fornitore

Valutare competenza, processi di sviluppo, gestione delle versioni e supporto del fornitore. Documentazione e test del costruttore possono contribuire alla verifica, se adeguati e riesaminati. La responsabilità del sito per l'uso GMP non viene trasferita acquistando un pacchetto denominato «validato».

[GUIDANCE] GAMP 5, seconda edizione del 2022, offre un quadro di buone pratiche per i sistemi computerizzati. Non è una norma di legge né una certificazione automatica del software. Il livello di evidenza deve essere proporzionato al rischio, all'uso previsto e alla conoscenza del sistema.

Collegare URS, specifiche, valutazione del rischio, prove e deviazioni. Definire criteri di rilascio e responsabilità per la manutenzione dello stato validato. Un elenco di test eseguiti non basta se non è chiaro quali requisiti copra e quali rischi rimangano aperti.

12. Cambiamenti, obsolescenza e revisione periodica

Aggiornamenti software, patch, sostituzioni hardware, migrazioni e modifiche alle interfacce possono influenzare controllo o dati. Il change control deve valutare impatto, prove necessarie, piano di ripristino e aggiornamento della documentazione. La definizione di «equivalente» deve essere sostenuta da caratteristiche rilevanti, non soltanto dal modello commerciale.

La revisione periodica considera incidenti, accessi, prestazioni, backup, modifiche, documentazione e supportabilità. Valutare anche dipendenze esterne e componenti non più supportati. Pianificare il retrofit prima che una sostituzione urgente costringa a decisioni senza evidenze sufficienti.

Le red flag principali sono account condivisi senza controllo, ricette senza versione, audit trail non revisionabile, backup mai ripristinati e report che nascondono lacune. Una buona automazione rende visibile la relazione tra configurazione approvata, azioni degli utenti, processo eseguito e dati conservati.

13. Criteri di consegna alla produzione

Prima del rilascio, verificare che la configurazione installata coincida con quella provata e che le ricette produttive siano approvate. Confermare disponibilità delle procedure, formazione degli utenti, gestione delle anomalie e responsabilità amministrative. Le deviazioni aperte devono avere una valutazione documentata dell'impatto e una decisione autorizzata, evitando che una lista di attività residue nasconda funzioni critiche non dimostrate.

Consegnare una baseline recuperabile di software e configurazioni, con riferimenti alle versioni e alle prove. Il sito deve sapere come ottenere assistenza e quali interventi del fornitore richiedano autorizzazione preventiva. Stabilire anche come verificare l'assenza di modifiche inattese dopo un accesso remoto o un intervento di manutenzione.

Un passaggio di consegne efficace comprende una dimostrazione operativa con gli utenti: selezione del carico, avvio, lettura del record, gestione di un'eccezione e recupero dei dati archiviati. La capacità di svolgere queste attività conferma che il sistema è utilizzabile secondo le procedure. Non sostituisce la validazione, ma può evidenziare lacune organizzative prima dell'uso produttivo.

Riferimenti e percorsi

Fonti verificate il 23 settembre 2026: EU GMP Annex 11, versione vigente elencata, e Annex 15; ISPE GAMP 5, seconda edizione 2022, catalogo ufficiale. Le matrici di questo articolo sono originali e non riproducono procedure proprietarie.

Approfondisci Sterilization & Depyrogenation Systems, monitoraggio dei cicli, qualification degli sterilizzatori e Automation & Digital Systems.

THE PRAGMATIC GMP · OGNI LUNEDÌ

Le GMP che contano, in 7 minuti.

Un tema GMP, un esempio concreto e un’azione pratica. Con aggiornamenti basati su fonti ufficiali e tendenze ispettive.
Scopri The Pragmatic GMP →