Test degli allarmi in un sistema di monitoraggio efficiente: un approccio ibrido

Riceviamo spesso domande da professionisti del settore delle Life Sciences sulle migliori pratiche per la creazione e la gestione di ambienti GxP. In questo blog condivideremo con voi una domanda posta di recente da un tecnico impegnato nell'installazione del sistema di monitoraggio in continuo viewLinc.  

Domanda:  Sono uno specialista della validazione a contratto che lavora per un'azienda farmaceutica globale. Al momento lavoro all'implementazione del sistema di monitoraggio in continuo viewLinc di Vaisala in un nuovo magazzino e ho in programma l'esecuzione di alcuni test sulle funzioni di allarme di viewLinc.  Da quanto ho capito, quando si testano le impostazioni di allarme soglia, il sistema viewLinc non consente a un utente di "forzare" o di simulare un valore di input analogico. La mia domanda è: è possibile configurare i data logger rispetto a un calibratore in loop per forzare i valori di input? Vi ringrazio anticipatamente per l'aiuto.

Risposta: Grazie per la domanda e sono felice di sentire che le impostazioni di allarme vengono testate.  Non tutti lo fanno, ma eseguire test periodici sulle impostazioni di allarme è fondamentale.   Come professionista nel campo della validazione, non ritengo necessariamente che gli allarmi siano soggetti ai requisiti GMP perché i criteri di rilascio si basano in genere sulle temperature effettive e non sulla presenza o assenza di allarmi.  

Tuttavia, gli allarmi sono importanti per proteggere le risorse correlate ai prodotti e rappresentano uno dei motivi principali per cui i clienti ricorrono a sistemi di monitoraggio automatizzati.

Faccio questa distinzione (che potrebbe non essere una differenza effettiva) qualora ti sia utile per considerare le funzioni di allarme come un rischio aziendale e non come un rischio GMP.  Detto questo, non so se mi sentirei di sostenere questa distinzione durante un audit.  Ti sconsiglio vivamente di provare a forzare i valori di input su qualsiasi logger Vaisala.  Non sono progettati per questo scopo e potrebbero subire danni.  

Come alternativa, propongo due opzioni:  

Scelta 1: utilizza DL1416 (o un altro data logger con sonda esterna) e colloca la sonda esterna in un bagno di calibrazione a secco. Utilizza questa configurazione per creare la temperatura di allarme.  Il vantaggio consiste nel poter testare la soglia al valore configurato esatto.  Lo svantaggio sta nella complessità e nella scarsa praticità del bagno.

Scelta 2: manipola direttamente le impostazioni di soglia.  Se devi dimostrare che l'allarme soglia ALTO sul Logger X funziona, modifica la soglia in modo da impostare il valore soglia al di sotto di quello corrente.  In questo modo, attiverai la sequenza di allarmi ed eventuali notifiche associate.  Il vantaggio consiste nel poter testare la soglia senza alcun simulatore o apparecchiatura di calibrazione ecc.  Lo svantaggio sta nel fatto che l'allarme viene testato a un valore arbitrario, NON a un valore configurato esatto.  

Personalmente preferisco la scelta 2, perché ritengo di poter facilmente affermare che l'allarme alto è stato generato e la sequenza di notifiche ha funzionato, sebbene il valore soglia alto sia stato impostato su 8 °C e il test di allarme alto sia stato eseguito su un valore arbitrario, ad esempio 5 °C. E ho verificato che il valore soglia alto è configurato correttamente su 8 °C.  Quindi, l'unico rischio è che per qualche ragione sconosciuta, o errore di codice nascosto, l'allarme non funzioni a 8 °C, ma a 5°C. Lo considero comunque un rischio minimo. 

Un approccio ibrido ai test di allarme

Per i test di allarme consiglio un approccio ibrido che tenga conto di altri dati noti sul sistema, in particolare la presenza di sensori calibrati e il fatto che le soglie siano tutte basate su modelli.

1)    Prova una singola posizione in modo che mostri che l'allarme scatta al valore previsto.  È piuttosto semplice: prova con un refrigeratore con un allarme impostato su 8 °C e apri la porta per aumentare la temperatura.  Verifica che l'allarme venga generato quando i valori di temperatura effettivi superano la soglia prevista.  Stabilirai che il sistema genera un allarme quando un valore effettivo supera un valore soglia.  Potresti anche utilizzare l'approccio della Scelta 1 con il bagno di calibrazione.  Ma procedi con un solo logger (o tre se il tuo cliente ha richiesto la verifica in triplicato).  Ma NON farlo per ogni logger e per ogni soglia.

2)    Verifica che tutti i data logger con soglie programmate siano calibrati.  Stabilirai che i valori immessi nel sistema per gli allarmi sono corretti.  Sembra banale, ma vi sono persone che strutturano i test di allarme in modo da trasformarli in nulla di più di semplici controlli della calibrazione con maggiore incertezza.

3)    Testa tutti gli altri modelli di allarme con il metodo della Scelta 2, modificando il valore soglia per attivare l'allarme.  Non testare ogni data logger.  Esegui questo test solo una volta per SOGLIA, per MODELLO DI SOGLIA (o per MODELLO DI NOTIFICA).  Se il sistema è configurato in modo efficiente, con l'utilizzo di modelli per gli allarmi, dovrai testarne molti meno.

Quindi, l'idea alla base dell'utilizzo dei modelli consiste nel testare ogni modello UNA VOLTA e poi, per ogni data logger o posizione, nel verificare che venga utilizzato il modello corretto (che hai appena testato).

Spero che sia utile! Sono disponibili molte guide e indicazioni tecniche per viewLinc nel nostro Portale della documentazione  e siamo sempre disponibili a offrirti il nostro aiuto. Visita il Portale di supporto Vaisala.