La qualifica di un Environmental Monitoring System non è una sequenza di protocolli da eseguire: è la dimostrazione documentata che ogni requisito della URS è stato verificato con un metodo adeguato. Se la URS è stata scritta bene, la qualifica è in larga parte già definita: ogni requisito porta con sé il metodo con cui sarà verificato e la fase in cui la verifica avverrà. Se la URS è stata scritta male, la qualifica diventa una trattativa con il fornitore su che cosa sia accettabile.
La distinzione da tenere ferma dall'inizio è questa: qualificare un sistema di monitoraggio ambientale non significa qualificare la cleanroom, e non significa classificarla. Sono tre attività con scopi e criteri diversi. La qualifica dell'EMS dimostra che il sistema misura, registra, allarma e conserva come previsto; la qualifica della cleanroom riguarda le prestazioni dell'ambiente; la classificazione è una determinazione eseguita secondo metodi normati. Un EMS qualificato non rende un ambiente classificato, e viceversa.
Perché la struttura della qualifica va decisa presto
La strategia di qualifica influenza il contratto, il piano di progetto e i costi molto prima che il primo protocollo venga scritto. Se si intende utilizzare le attività svolte presso il fornitore per ridurre le verifiche in sito, occorre averlo previsto nella specifica di gara, averlo concordato contrattualmente e aver definito quali documenti verranno consegnati e in che forma. Deciderlo dopo la firma significa, quasi sempre, non poterlo fare.
La seconda ragione riguarda la sequenza fisica dei lavori. La verifica dell'installazione richiede documentazione as-built completa; l'esecuzione della fase prestazionale richiede un ambiente in condizioni operative rappresentative. Se queste dipendenze non sono nel programma, la qualifica viene compressa alla fine e si trasforma in un esercizio formale eseguito sotto pressione, che è esattamente la condizione in cui si generano deviazioni.
Il quadro regolatorio
| Livello | Cosa stabilisce rispetto alla qualifica dell'EMS |
|---|---|
| Requisito regolatorio (EudraLex Volume 4, Annex 15) | Definisce l'impianto della qualifica e della validazione: specifica dei requisiti, verifica del progetto, qualifica di installazione, di funzionamento e di prestazione, gestione delle deviazioni, controllo delle modifiche e riqualifica su base di rischio. È il riferimento principale per la struttura del percorso. |
| Requisito regolatorio (Annex 11, revisione gennaio 2011) | Si applica alla componente computerizzata: validazione, tracciabilità dei requisiti, gestione del fornitore, sicurezza, audit trail, gestione dei dati. |
| Requisito regolatorio (EudraLex Volume 4, Annex 1) | Richiede che il monitoraggio sia adeguato alla criticità e che il programma sia parte della strategia di controllo della contaminazione: è il riferimento per l'intended use rispetto a cui il sistema viene qualificato. |
| Requisito di norma tecnica (serie ISO 14644; ISO 21501-4) | Definiscono metodi di classificazione e requisiti prestazionali e di taratura degli strumenti. Rilevanti come criteri tecnici, se richiamate. |
| Buona pratica ingegneristica | Commissioning e verifiche di cantiere: riducono l'onere della qualifica se pianificati e documentati, ma non la sostituiscono. |
| Raccomandazione operativa GuideGxP | Redigere un piano di qualifica che assegni ogni requisito della URS a una fase e a un metodo di verifica prima di scrivere i protocolli, e concordare contrattualmente i deliverable del fornitore in fase di gara. |
Le fasi, e che cosa ha senso verificare in ciascuna
Verifica del progetto
Prima della costruzione si verifica che la soluzione proposta risponda ai requisiti: architettura, posizioni dei punti rispetto al risk assessment, interfacce, accessibilità per manutenzione e calibrazione, requisiti di data integrity nella configurazione prevista. È la fase in cui correggere costa poco. Le osservazioni più costose di un progetto EMS — punti non accessibili, lunghezze di linea non ammesse, permessi non separabili — sono quasi tutte individuabili qui.
FAT — verifica presso il fornitore
Si eseguono presso il fornitore le verifiche che non richiedono l'ambiente reale: funzionalità del software, gestione degli utenti e dei permessi, comportamento dell'audit trail, logica degli allarmi, reportistica, comportamento in condizioni anomale simulate. Il vantaggio non è solo di programma: correggere un difetto software prima della spedizione è incomparabilmente più semplice che correggerlo su un sistema installato in area classificata.
Condizioni perché il FAT sia utile: protocollo approvato prima dell'esecuzione, presenza di personale del committente, registrazione puntuale degli esiti e delle anomalie, e chiarezza su quali test verranno ripetuti in sito e quali no. Un FAT eseguito su una configurazione diversa da quella che verrà installata ha valore limitato e va dichiarato come tale.
SAT — verifica in sito dopo la consegna
Verifica che il sistema arrivato e installato corrisponda a quanto approvato, che i collegamenti siano corretti e che le funzioni già provate presso il fornitore si comportino allo stesso modo nell'ambiente reale. È anche il momento in cui emergono le differenze tra il progetto e ciò che il cantiere ha effettivamente realizzato.
IQ — qualifica di installazione
Verifica documentata che il sistema sia installato conformemente alla specifica e alla documentazione as-built. Elementi tipici:
- corrispondenza tra componenti installati e distinta approvata, con identificativi e numeri di serie;
- posizioni dei punti di monitoraggio rispetto alla mappa approvata, con registrazione di ogni scostamento;
- percorsi e lunghezze effettive delle linee di campionamento, conformi ai limiti dichiarati dal costruttore;
- corretta esecuzione degli attraversamenti e delle sigillature;
- collegamenti elettrici e di rete, alimentazione e continuità;
- presenza dei certificati di taratura degli strumenti e della documentazione tecnica;
- versioni software e configurazione installata, registrate come riferimento.
OQ — qualifica di funzionamento
Verifica che il sistema funzioni come specificato, in tutte le condizioni previste, comprese quelle anomale. È la fase in cui la qualità della URS si vede: ogni requisito verificabile diventa un test. Aree tipiche:
- acquisizione e integrità del dato lungo tutta la catena, dal punto di misura al record archiviato;
- gestione degli allarmi: generazione, propagazione, notifica, presa in carico, registrazione dell'intero ciclo;
- utenti e permessi: verifica che ciascun ruolo possa fare esattamente ciò che deve e nulla di più;
- audit trail: verifica su ciascun tipo di evento tracciato, e verifica che non sia disattivabile;
- sincronizzazione oraria tra strumenti, server e sistemi collegati;
- comportamento in condizioni anomale: perdita di rete, mancanza di alimentazione, riavvio, saturazione dello spazio di archiviazione;
- backup e ripristino nella configurazione reale;
- report ed esportazioni, verificati contro i dati sorgente;
- interfacce con altri sistemi, se presenti.
PQ — qualifica di prestazione
Verifica che il sistema si comporti in modo affidabile nelle condizioni operative reali e per un periodo rappresentativo, eseguendo il programma di monitoraggio come definito. Non è una ripetizione dell'OQ in ambiente: è la verifica che l'insieme — sistema, procedure, persone — funzioni.
Va evitato l'errore concettuale più comune di questa fase: la PQ dell'EMS non serve a dimostrare che l'ambiente rispetta i limiti. Serve a dimostrare che il sistema è in grado di rilevare, registrare, segnalare e conservare in modo affidabile. Il comportamento dell'ambiente è oggetto della qualifica della cleanroom e del programma di monitoraggio, che sono attività distinte.
Strumento operativo: matrice di tracciabilità
È il documento che collega requisiti, verifiche ed esiti, e che consente di rispondere in ispezione alla domanda «come avete verificato questo requisito?». Struttura minima:
| ID requisito | Requisito (sintesi) | Categoria | Fase di verifica | Metodo | Riferimento test | Esito |
|---|---|---|---|---|---|---|
| URS-xxx | Acquisizione continua nei punti critici | Requisito regolatorio | OQ / PQ | Test funzionale e osservazione in esercizio | ||
| URS-xxx | Audit trail non disattivabile | Requisito regolatorio | OQ | Tentativo di disattivazione da utenza amministrativa | ||
| URS-xxx | Comportamento alla perdita di rete | Decisione basata sul rischio | OQ | Simulazione di interruzione e verifica di completezza | ||
| URS-xxx | Accessibilità delle sonde per calibrazione | Buona pratica ingegneristica | Verifica di progetto / IQ | Revisione documentale e ispezione in campo | ||
| URS-xxx | Esportazione dati in formato leggibile | Raccomandazione GuideGxP | OQ | Esportazione di prova e rilettura indipendente |
La matrice va compilata a partire dalla URS, non ricostruita a valle dei protocolli. Un requisito senza metodo di verifica assegnato è un requisito che nessuno verificherà.
Scenario pratico
In un sito che chiameremo Sito Delta — esempio realistico ma di fantasia — il piano di qualifica prevede di sfruttare il FAT per ridurre i test in sito. Il FAT viene eseguito e chiuso positivamente. In fase di OQ emerge però che la configurazione dei permessi utente verificata presso il fornitore era quella dimostrativa, non quella definita nella matrice dei ruoli del sito, approvata nel frattempo.
La conseguenza è duplice: i test sui permessi vanno rieseguiti integralmente in sito, e la riduzione di scope prevista non è più giustificabile. Il problema non era il FAT in sé, ma il fatto che fosse stato eseguito prima che la configurazione definitiva fosse decisa, senza dichiarare esplicitamente questa limitazione nel protocollo e nel report.
La correzione adottata per i progetti successivi è semplice: il protocollo di FAT dichiara, per ciascun test, se è eseguito sulla configurazione definitiva o su una configurazione dimostrativa, e solo i primi possono essere utilizzati per ridurre le verifiche in sito. La sequenza corretta prevede inoltre che la matrice dei ruoli sia approvata prima del FAT, non dopo.
Errori comuni e segnali di allarme
- Scrivere i protocolli senza matrice di tracciabilità. Il risultato tipico è un insieme di test che verificano ciò che è facile verificare, lasciando scoperti i requisiti più rilevanti.
- Sfruttare il FAT senza averlo previsto contrattualmente. Senza accordo preventivo, i deliverable del fornitore raramente sono nella forma che serve.
- Eseguire l'IQ contro una documentazione as-built non aggiornata. La qualifica perde il proprio riferimento e va rifatta.
- Testare solo il funzionamento nominale. Le condizioni anomale sono quelle in cui il sistema deve dimostrare di comportarsi in modo prevedibile.
- Confondere la PQ dell'EMS con la qualifica della cleanroom. È l'errore concettuale che più spesso emerge in ispezione.
- Gestire le deviazioni di qualifica in modo informale. Ogni scostamento va registrato, valutato per impatto e chiuso prima del rilascio.
- Non definire i criteri di accettazione prima dell'esecuzione. Criteri definiti dopo aver visto il risultato non sono criteri.
- Rilasciare in uso GMP senza una conclusione formale. Il passaggio dall'attività di progetto all'uso operativo va documentato in modo esplicito.
- Non definire i trigger di riqualifica. Modifiche, spostamenti di punti, aggiornamenti software e interventi maggiori devono avere criteri predefiniti di valutazione.
Come documentare
- Piano di qualifica: scope, strategia, fasi, responsabilità, criteri di accettazione generali, uso previsto della documentazione del fornitore.
- Matrice di tracciabilità: requisiti, fase, metodo, riferimento del test ed esito.
- Protocolli approvati prima dell'esecuzione, con criteri di accettazione espliciti.
- Registrazioni di esecuzione con dati grezzi, esiti e firme.
- Gestione delle deviazioni: registrazione, valutazione di impatto, azioni e chiusura.
- Report di fase e report riassuntivo, con conclusione esplicita sull'idoneità all'uso previsto.
- Rilascio all'uso GMP formalizzato, con eventuali restrizioni residue dichiarate.
- Criteri di riqualifica definiti e collegati al change control.
Punti chiave
- Una qualifica ben impostata è in larga parte già scritta nella URS.
- La matrice di tracciabilità si costruisce dai requisiti, non dai protocolli.
- Il FAT vale se eseguito sulla configurazione definitiva e se previsto contrattualmente.
- L'IQ non può essere eseguita senza documentazione as-built affidabile.
- L'OQ deve coprire le condizioni anomale, non solo quelle nominali.
- La PQ dell'EMS dimostra l'affidabilità del sistema, non la conformità dell'ambiente.
Domande frequenti
Il FAT è obbligatorio?
Non è un obbligo in sé: è una scelta di strategia. Diventa particolarmente utile per la componente software, dove correggere prima della spedizione è molto meno oneroso. Se lo si vuole utilizzare per ridurre le verifiche in sito, va previsto in gara e nel piano di qualifica.
Si può usare la documentazione del fornitore al posto dei propri protocolli?
Può essere utilizzata come parte del dossier se è adeguata allo scopo, valutata e approvata dall'azienda, e se il fornitore è stato valutato. La responsabilità sulla conclusione resta comunque dell'azienda utilizzatrice.
Quanto deve durare la PQ?
Per un periodo rappresentativo delle condizioni operative reali, definito e giustificato dall'azienda in funzione della criticità e della variabilità attesa. Non esiste una durata standard: va motivata nel piano.
Che differenza c'è tra qualifica dell'EMS e qualifica della cleanroom?
La prima dimostra che il sistema misura, registra, allarma e conserva come previsto; la seconda riguarda le prestazioni dell'ambiente. Sono attività distinte, con protocolli, criteri e responsabilità propri, anche quando vengono pianificate nello stesso progetto.
Quando serve una riqualifica?
Quando una modifica può avere impatto sullo stato qualificato: spostamento o aggiunta di punti, aggiornamenti software, modifiche di configurazione rilevanti, interventi maggiori sull'infrastruttura. L'estensione si determina con valutazione di impatto all'interno del change control, con approccio basato sul rischio.
Come si gestiscono le deviazioni durante la qualifica?
Registrandole quando si verificano, valutandone l'impatto sui requisiti coinvolti, definendo le azioni e chiudendole prima del rilascio. Una deviazione aperta al momento del rilascio deve essere esplicitamente giustificata e le eventuali restrizioni residue devono essere dichiarate.
Riferimenti normativi e tecnici
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Commissione europea): Annex 15 (in vigore dal 1° ottobre 2015), Annex 11 (revisione gennaio 2011), Annex 1 (applicabile dal 25 agosto 2024).
- ISO 14644-1 — Cleanrooms and associated controlled environments: classification of air cleanliness by particle concentration.
- ISO 21501-4 — Determination of particle size distribution: light scattering airborne particle counter for clean spaces.
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
- PIC/S — Guides and Guidance Documents.
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, l'installazione di sonde e linee e il software tra Annex 11 e data integrity.
- A valle: calibrazione, manutenzione e periodic review.
- Fondamenti regolatori GuideGxP: piano di monitoraggio ambientale audit-ready.
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.