Nota applicativa

Utilizzo della metodologia GAMP per la validazione del software dei sistemi di monitoraggio ambientale

Integrità dei dati e ALCOA++ nei sistemi di monitoraggio continuo GxP

In quanto sistemi automatizzati, i sistemi di monitoraggio possono essere gestiti in conformità alle linee guida GAMP® (Good Automated Manufacturing Practice) dell’ISPE, in particolare alla GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture e a GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems. Queste linee guida assicurano conformità, qualità e sicurezza dei pazienti attraverso una gestione strutturata e basata sul rischio delle applicazioni di monitoraggio.

Life Science

Validazione CMS: un approccio basato su GAMP

Nelle attività GxP è essenziale mantenere condizioni ambientali controllate. I sistemi di monitoraggio in continuo (CMS) automatizzano questo processo, fornendo allarmi in tempo reale e registrazioni accurate che consentono di dimostrare che i prodotti sono stati fabbricati, lavorati e conservati nel rispetto delle specifiche.

Come tutti i sistemi basati su software, anche un sistema CMS segue un ciclo di vita: acquisizione, installazione, rilascio, manutenzione e infine dismissione. Tale ciclo rispecchia il ciclo di vita dello sviluppo software (SDLC) applicabile al software GMP. In questo articolo ci concentriamo sulle fasi di qualifica e validazione, spesso trascurate perché i sistemi di monitoraggio operano silenziosamente in background. Trascurare la validazione può comportare osservazioni da parte delle autorità regolatorie e quesiti difficili da affrontare durante gli audit.

L'applicazione della metodologia GAMP offre un approccio sistematico basato sul rischio per garantire che il software di monitoraggio rimanga conforme e funzioni come previsto durante l'intero ciclo di vita. Presentiamo una guida in dieci passaggi per semplificare la validazione, integrarla nel sistema di gestione della qualità e allineare il lavoro alla complessità del sistema (secondo le categorie del sistema GAMP). L’applicazione della metodologia GAMP non solo rafforza la conformità, ma prolunga anche la vita utile del sistema di monitoraggio, migliorandone l’affidabilità e l’usabilità.

Questo articolo presenta un processo in 10 passaggi, con percorsi diversi in funzione delle categorie di sistemi GAMP. Ogni metodo di validazione, corrispondente alla classificazione del sistema, comporta livelli diversi di attività di validazione.

Termini chiave

Termini chiave

Un documento della specifica dei requisiti utente (User Requirements Specification - URS) definisce le funzionalità che il sistema deve offrire per soddisfare le esigenze dell'utente finale. I requisiti possono essere classificati come obbligatori, desiderabili, facoltativi oppure previsti per versioni future. Esempio: "Il sistema deve prevenire i falsi allarmi durante attività normali come l'apertura delle porte".

Un documento Functional Specification (FS) descrive le funzioni del sistema e il modo in cui soddisfano i requisiti definiti nella URS. Definisce i metodi per verificare la conformità, ma non entra nel dettaglio dell'progettazione interna del sistema, concentrandosi invece sulle interazioni tra il sistema e gli utenti finali.

Una matrice di tracciabilità (Traceability Matrix - TM) consente di tracciare i requisiti per verificarne il soddisfacimento. Generalmente presentata sotto forma di tabella, collega ogni requisito o specifica al relativo test di verifica. La matrice di tracciabilità guida lo sviluppo dei test e deve essere verificata al termine delle attività di test per confermare che tutti i requisiti siano stati adeguatamente soddisfatti

Passaggio 1: definire le esigenze mediante un documento URS (User Requirements Specification)

Il primo passo nella scelta di un sistema di monitoraggio in continuo (CMS) consiste nel definire le proprie esigenze in un documento di User Requirements Specification (URS), un'operazione che dovrebbe essere eseguita prima di scegliere il sistema, anche se, nella realtà, viene spesso saltata o ritardata. Nel processo GAMP, la URS rappresenta il documento più importante per garantire che il sistema sia adeguato alle esigenze dell'organizzazione.

Un documento URS descrive le funzionalità richieste del CMS e può raccogliere le esigenze di diversi stakeholder, favorendo il raggiungimento di un consenso durante il processo di selezione. Il suo obiettivo principale è allineare il sistema CMS al sistema Quality Management System (QMS) esistente. Minore è il divario tra il sistema CMS e il sistema QMS, minori sono i rischi di non conformità e di sicurezza del prodotto.

La redazione della URS può inoltre far emergere nuove funzionalità o approcci di monitoraggio più efficienti. La redazione della URS non rappresenta quindi soltanto un esercizio di conformità, ma anche un’opportunità per adottare un approccio strategico, creativo e orientato al futuro, assicurando che il sistema scelto soddisfi le esigenze degli ambienti, dei prodotti e dei processi di qualità.

Una tipica URS per un sistema di monitoraggio in continuo (CMS) dovrebbe prendere in considerazione funzioni fondamentali quali sensori, rete, utenze, infrastruttura, sicurezza, gestione degli allarmi e IT, nonché eventuali esigenze specifiche della struttura o del prodotto. Ogni requisito deve essere SMART (Specifico, Misurabile, Attuabile, Rilevante e Testabile).

Definizione dei requisiti funzionali nel documento URS

Le considerazioni sui test dovrebbero guidare la stesura dei requisiti: se un requisito non può essere testato è destinato a causare problemi. Ad esempio, nella sezione "Gestione degli allarmi" si potrebbe specificare quanto segue:

Il sistema deve avvisare il personale quando i valori rilevati dai sensori superano le soglie definite.
Il sistema deve consentire di configurare ritardi degli allarmi compresi tra 0 e 60 minuti.
Deve inoltre consentire di impostare più soglie superiori e inferiori.
Il sistema deve comunicare gli allarmi tramite SMS, e-mail e telefono.

Requisiti di questo tipo sono specifici e verificabili. La redazione della URS dovrebbe essere affidata a un comitato composto dalle parti interessate, ciascuna delle quali apporta le proprie competenze. Il coinvolgimento delle parti interessate fin dalle prime fasi contribuisce a garantirne il consenso e il supporto nelle fasi successive. Le revisioni sono una parte normale del processo e alcuni requisiti rimarranno inevitabilmente insoddisfatti. I requisiti non soddisfatti devono essere documentati ai fini della tracciabilità, assicurando che eventuali soluzioni alternative siano trasparenti e integrate nel QMS. Sebbene la scelta del sistema comporti inevitabilmente dei compromessi, una URS che rifletta le effettive esigenze GxP, anziché limitarsi a rispecchiare quanto già disponibile sul mercato, favorisce sia una maggiore rispondenza del sistema alle esigenze dell’organizzazione sia l’innovazione da parte dei fornitori.

Passaggio 2: iniziare a predisporre una matrice di tracciabilità

La matrice di tracciabilità è lo strumento principale per organizzare l’intero processo di qualifica, a partire dalla selezione del sistema. Collega ciascun requisito della URS alla funzione corrispondente del sistema, assicurando che ogni requisito sia implementato e sottoposto a test.

Si tratta essenzialmente di un foglio di calcolo strutturato, nella cui prima colonna sono elencati i requisiti della URS. Le colonne successive — Specifica funzionale, Specifica di configurazione e Protocollo di test — vengono compilate progressivamente nel corso delle attività di selezione e qualifica. Questo documento, aggiornato durante l’intero processo, consente di verificare facilmente che ogni requisito sia stato preso in considerazione, ogni funzione sia stata verificata e nessun elemento critico sia stato tralasciato.

Requirement	Functional Specification	Configuration Specification	Test Protocol
Il sistema deve prevenire i falsi allarmi causati da attività normali come l'apertura delle porte.

Passaggio 3: sottoporre ad audit i fornitori e selezionare un prodotto

Il passaggio successivo consiste nell’individuare un sistema che soddisfi i requisiti definiti nella URS. Utilizzare la URS come riferimento per valutare l’allineamento di ciascun potenziale sistema di monitoraggio in continuo (CMS) al sistema di gestione della qualità (QMS). Prendere in considerazione anche ulteriori vincoli, quali il budget di acquisizione, il costo totale di proprietà a lungo termine e le capacità interne di validazione dell’organizzazione. Ad esempio, è possibile gestire internamente l’installazione e la qualifica oppure sarà necessario ricorrere al supporto del fornitore o di un appaltatore esterno?

L’obiettivo è creare un elenco ristretto di sistemi candidati da sottoporre a una valutazione più approfondita. Gli audit dei fornitori possono assumere due forme:

Sottoporre ad audit il sistema di qualità e la struttura del fornitore per valutarne l’impegno nei confronti della qualità.
Sottoporre ad audit il CMS utilizzando la matrice di tracciabilità. Creare una copia della matrice per ciascun sistema, quindi confrontarne le funzionalità con i propri requisiti.

Spesso, il principale elemento di differenziazione tra i sistemi è rappresentato dal tipo di software, così come definito dalle linee guida GAMP.

Passaggio 4: determinare il tipo di software

Le linee guida GAMP dell’ISPE classificano il software in cinque categorie; per i sistemi di monitoraggio, le principali sono:

Categoria 3: Off-the-shelf (disponibile in commercio) (GAMP 4: "Standard", GAMP 5: "Non-configured" (Non configurato)): software «plug-and-play» pronto all’uso, che richiede esclusivamente configurazioni eseguibili durante il normale utilizzo, come l’impostazione delle intestazioni dei report, delle stampanti predefinite o dei tipi di utente. Non richiede modifiche dei processi aziendali né lo sviluppo di codice personalizzato.

Categoria 4: Configured (Configurato) (GAMP 4: "Configured software" (Software configurato), GAMP 5: "Configured products" (Prodotti configurati)): software che richiede una configurazione più articolata, oltre alle impostazioni eseguibili durante il normale utilizzo, per essere adattato ai processi aziendali, ad esempio mediante menu a discesa personalizzati o formati specifici dei report. Utilizza codice standard sottoposto a test dal fornitore, senza richiedere lo sviluppo di nuovo codice.

Categoria 5: Custom (Personalizzato) (GAMP 4: "Custom software" (Software personalizzato), GAMP 5: "Custom products" (Prodotti personalizzati)): software che comporta lo sviluppo di nuovo codice, dalle applicazioni realizzate interamente su misura fino alle semplici macro VBA in Excel. Tutto il nuovo codice deve essere sottoposto a test dall’utente, poiché non è stato validato dal fornitore.

Queste categorie consentono di stimare l’impegno e i costi della validazione, nonché di chiarire in che modo un nuovo sistema si integrerà nei processi di qualità.

Domande frequenti: cosa occorre sapere sui sistemi di monitoraggio in parallelo?

Alcune aziende utilizzano in parallelo un sistema di gestione degli edifici (BMS - Building Management System) e un sistema di monitoraggio in continuo (CMS), dimostrando agli ispettori un forte impegno nel garantire la continuità delle registrazioni. In genere, uno viene designato come «sistema di registrazione» e l’altro come «sistema di controllo». Tuttavia, le uscite del BMS coinvolgono spesso sensori eterogenei e programmazione personalizzata, rendendo onerosa la validazione GMP. Un’alternativa più conveniente consiste nell’utilizzare come sistema di registrazione un CMS disponibile in commercio e progettato per applicazioni GxP. Questo approccio semplifica la validazione, mette a disposizione documentazione pronta per gli audit e assicura una registrazione aggiuntivo, garantendo la continuità dei dati in caso di interruzioni dell’alimentazione elettrica o della rete.

Ulteriori informazioni sui sistemi paralleli

Passaggio 5: sviluppare un documento di specifica funzionale (Functional Specification - FS)

Dopo aver individuato un elenco ristretto di sistemi candidati, è necessario predisporre un documento di specifica funzionale (Functional Specification - FS). La FS descrive ciascuna funzione del software e spiega in che modo soddisfa i requisiti definiti nella URS.

Per i sistemi disponibili in commercio o configurati, la FS deve essere specifica e dettagliata; spesso il fornitore può metterne a disposizione una versione preliminare. Per i sistemi personalizzati, la FS può essere inizialmente meno definita, poiché il sistema non è ancora stato realizzato. In questi casi, la sua redazione è responsabilità dello sviluppatore, compresi eventuali team interni.

Durante la redazione o la revisione della FS possono emergere nuove applicazioni o funzionalità per il CMS, che devono essere aggiunte alla URS per garantirne l’allineamento. Ciascun requisito della URS deve essere collegato a una funzione corrispondente e ogni funzione deve essere documentata nella matrice di tracciabilità a supporto delle attività di verifica e test.

Requirement	Functional Specification	Configuration Specification	Test Protocol
Il sistema deve prevenire i falsi allarmi causati da attività normali come l'apertura delle porte.	Il sistema disporrà di una funzione per configurare i ritardi degli allarmi per prevenire i falsi allarmi.

I documenti URS e FS raramente coincidono perfettamente e l'aggiornamento della matrice di tracciabilità permette di confermare quali requisiti siano soddisfatti e quali no. Non tutti i requisiti hanno la stessa rilevanza: alcuni sono essenziali, mentre altri sono semplicemente desiderabili. Collaborare con le parti interessate per definirne le priorità e aggiornare la URS indicando gli eventuali requisiti non soddisfatti e le relative soluzioni alternative documentate.

A questo punto, finalizzare la selezione del sistema. Occorre ricordare che il tipo di software scelto (Categoria 3, 4 o 5) incide direttamente sull’impegno richiesto per la validazione. I software di Categoria 3 («off-the-shelf») generalmente non richiedono specifiche aggiuntive, consentendo di procedere direttamente alla redazione della documentazione di test (Passaggio 7). I sistemi di Categoria 4 e 5 richiedono ulteriore documentazione prima dell’avvio dei test. La maggior parte dei sistemi di monitoraggio rientra nella Categoria 4, mentre la Categoria 5 comprende spesso più dispositivi di fornitori diversi, integrati mediante codice personalizzato.

Suggerimento: le risorse necessarie per la validazione aumentano con la complessità del sistema; occorre quindi pianificarle di conseguenza.

Domande frequenti: come viene verificata l’applicazione delle linee guida GAMP?

GAMP è costituita da linee guida di settore elaborate da esperti in materia per contribuire a garantire che i prodotti farmaceutici siano fabbricati secondo i più elevati standard di qualità. Uno dei principi fondamentali di GAMP stabilisce che la qualità debba essere integrata in ogni fase della produzione.

Sebbene le linee guida GAMP non costituiscano un requisito normativo, sono ampiamente riconosciute come buona pratica di settore. Gli auditor possono mettere in discussione eventuali scostamenti dalle raccomandazioni GAMP e richiedere una spiegazione dell’approccio alternativo adottato e delle relative motivazioni. In caso di scostamento dalle pratiche conformi alle linee guida GAMP, occorre essere pronti a giustificare la decisione con motivazioni fondate ed evidenze documentate.

Passaggio 6: predisporre i documenti di specifica dettagliata (DS)

I documenti di specifica dettagliata (Detailed Specification - DS) descrivono il modo in cui il sistema sarà configurato o programmato per svolgere le funzioni definite nella specifica funzionale (FS). Questi documenti non sono necessari per i sistemi di Categoria 3, che sono già nella versione definitiva.

Categoria 4 (Sistemi configurati)
Per i sistemi di Categoria 4, la DS è denominata specifica di configurazione (Configuration Specification - CS). La CS descrive nel dettaglio come sarà configurato il sistema per allinearlo ai processi aziendali, ad esempio attraverso l’impostazione dei parametri, delle opzioni di menu e dei formati dei report. La configurazione viene generalmente eseguita in loco dopo l’installazione e può essere effettuata dal fornitore.

Categoria 5 (Sistemi personalizzati)
Per i sistemi di Categoria 5, la DS è denominata specifica dettagliata di progettazione (Detailed Design Specification - DDS). Poiché il sistema non è ancora stato realizzato, la DDS ne definisce nel dettaglio la struttura, la programmazione e le modalità di utilizzo, sviluppando ulteriormente quanto indicato nella FS. Ecco perché i sistemi di Categoria 5 richiedono il maggior numero di test e di documentazione. (Lo sviluppo della DDS non rientra nell’ambito del presente articolo.)

Tutti gli elementi della CS o della DDS devono essere riportati nella matrice di tracciabilità in corrispondenza dei requisiti e delle funzioni a cui si riferiscono. Le descrizioni della configurazione devono essere sufficientemente dettagliate da supportare sia la configurazione sia il test di ciascuna funzione.

Requirement	Functional Specification	Configuration Specification	Test Protocol
Il sistema deve prevenire i falsi allarmi causati da attività normali come l'apertura delle porte.	Il sistema disporrà di una funzione per configurare i ritardi degli allarmi per prevenire i falsi allarmi.	La funzione di configurazione degli allarmi sarà configurata per un ritardo di 10 minuti prima dell'attivazione dell'allarme.

Passaggio 7: predisporre la documentazione di test

Una volta finalizzate le specifiche, è possibile iniziare a predisporre la documentazione di test. Tale documentazione è necessaria per tutte le categorie di sistemi e deve prendere in considerazione tutti gli elementi rilevanti ai fini GMP riportati nella URS, nella FS e nella CS. Utilizzare la valutazione del rischio per concentrarsi sulle funzioni effettivamente rilevanti ai fini GMP: i requisiti S.M.A.R.T. contribuiranno a identificare ciò che deve essere sottoposto a test e ciò che può essere escluso.

Inserire ciascun protocollo di test nella matrice di tracciabilità per confermare la copertura di tutti i requisiti. Ad esempio, se la URS specifica un ritardo dell’allarme di 10 minuti, aggiungere «Test del ritardo dell’allarme» alla matrice per verificare che la funzione sia configurata correttamente e operi come previsto.

I requisiti di test variano a seconda del tipo di sistema:

Categoria 3: richiede esclusivamente IQ e OQ. La PQ non è necessaria perché i processi aziendali non possono essere modificati e tutte le funzioni vengono sottoposte a test completo durante la OQ.

Categoria 4: richiede IQ, OQ e PQ. La PQ conferma che le funzioni configurate soddisfano le esigenze del processo.

Categoria 5: richiede le attività più estese (revisione del codice, test dei moduli, FAT, messa in servizio, SAT, IQ, OQ e PQ).

Tutti i tipi di sistema richiedono la messa in servizio e i test SAT come parte dell'installazione dell'hardware. L’ambito dei test dovrebbe incidere in modo significativo sulla scelta del sistema: occorre trovare un equilibrio tra le esigenze funzionali e le risorse disponibili per la validazione.

Requirement	Functional Specification	Configuration Specification	Test Protocol
Il sistema deve prevenire i falsi allarmi causati da attività normali come l'apertura delle porte.	Il sistema disporrà di una funzione per configurare i ritardi degli allarmi per prevenire i falsi allarmi.	La funzione di configurazione degli allarmi sarà configurata per un ritardo di 10 minuti prima dell'attivazione dell'allarme.	Test del ritardo dell'allarme

I requisiti di test per i sistemi di Categoria 3 e Categoria 4 sono in gran parte gli stessi, la principale differenza è data dall'inclusione di Performance Qualification (PQ) (qualifica delle prestazioni) per la Categoria 4. Nei sistemi di Categoria 3, la PQ non è necessaria perché i processi aziendali non possono essere modificati e tutte le funzioni vengono sottoposte a test completo durante la qualifica operativa (OQ).

Categoria 3: richiede esclusivamente la qualifica dell’installazione (Installation Qualification - IQ) e la OQ.

Categoria 4: richiede IQ, OQ e PQ per verificare che le funzioni configurate soddisfino le esigenze di processo.

Categoria 5: richiede le attività di test più estese: revisione del codice, test dei moduli, test di accettazione in fabbrica (Factory Acceptance Testing - FAT), messa in servizio, test di accettazione in sito (SAT), IQ, OQ e PQ.

Tutti i tipi di sistema richiedono la messa in servizio e i test SAT come parte dell'installazione dell'hardware. L’ambito dei test dovrebbe costituire uno dei principali fattori nella selezione del sistema: occorre scegliere una categoria che consenta di bilanciare le esigenze operative con le risorse disponibili per la validazione.

Passaggio 8: finalizzare la matrice di tracciabilità

La matrice di tracciabilità (TM) deve essere aggiornata durante l’intero processo, integrando le informazioni provenienti dalla URS, dalla FS, dalla CS, dalla DS e da tutta la documentazione di test. Durante la revisione finale, verificare la presenza di eventuali lacune o duplicazioni:

Test non associati a requisiti: stabilire se il test sia effettivamente necessario.

Requisiti non associati a test: documentare il motivo per cui il requisito non può essere sottoposto a test e specificare la soluzione alternativa adottata.

Controllo finale:

URS: finalizzata e approvata. Tutti i requisiti sono riportati nella TM.
FS: finalizzata e approvato. Tutte le funzioni sono riportate nella TM e collegate ai relativi requisiti.
CS: finalizzata e inserita nella TM; per ciascuna funzione configurabile è stata definita la relativa configurazione.
Protocolli di test: redatti, approvati e collegati ai requisiti pertinenti.
Matrice di tracciabilità: completa, approvata e pronta per l'esecuzione.

Una volta confermato quanto sopra, è possibile procedere con i test.

Passaggio 9: Eseguire i test di sistema

A questo punto ha inizio il lavoro vero e proprio: l’esecuzione dei test definiti nei protocolli. Utilizzare la Traceability Matrix come lista di controllo principale per garantire che ogni requisito nei documenti URS, FS e CS sia verificato. L'esecuzione del sistema in un ambiente di produzione potrebbe far emergere problemi, idealmente di lieve entità. Affrontarli in modo sistematico:

Problemi minori: modificare le configurazioni o perfezionare le procedure.

Lacune nei requisiti: rivedere il documento URS per modificare il requisito o documentare una soluzione alternativa.

Difetti del sistema: contattare il fornitore per eventuali correzioni o patch.

Se un test non viene superato a causa di un bug del software, il fornitore potrebbe dover fornire una patch o una build aggiornata. Le modifiche dovranno essere ritestate per confermare che possano risolvere il problema senza crearne di nuovi. Conservare record accurati di tutti i risultati dei test, delle deviazioni e delle azioni correttive, saranno essenziali durante le verifiche.

Passaggio 10: Controllare le modifiche apportate al sistema

La validazione non finisce con la messa in funzione. Una volta che il sistema è pienamente operativo, validato e rilasciato formalmente, deve essere sottoposto a manutenzione continua per garantire conformità, affidabilità e prestazioni per l'intero ciclo di vita. La metodologia GAMP sottolinea che la responsabilità del sistema continua fino alla sua dismissione, non solo durante l'implementazione.

Le attività di manutenzione continuativa devono includere:

Procedure operative standard (SOP): mantenere le procedure operative sempre aggiornate, chiare e in linea con la pratica.
Formazione: assicurare che tutti gli utenti siano formati sulle procedure, sugli aggiornamenti del sistema e sulle best practice.
Calibrazione: effettuare la calibrazione regolare di sensori e strumenti per mantenere la precisione.
Validazione: ripetere la validazione dopo modifiche significative oppure periodicamente come previsto dal sistema di qualità.
Controllo delle modifiche: applicare una procedura formale di controllo delle modifiche per qualsiasi modifica, garantendo che le modifiche siano documentate, valutate per il rischio, testate e approvate prima dell'implementazione.

La manutenzione proattiva non solo estende la vita utile del sistema, ma riduce i rischi legati alle verifiche e ai tempi di inattività operativa. Un sistema CMS sottoposto ad adeguata manutenzione è sempre pronto per le ispezioni.

Conclusione

Dal 1991, il Good Automated Manufacturing Practice (GAMP) forum fornisce una guida chiara e pratica sull'utilizzo appropriato dei sistemi computerizzati nei settori regolamentati. La sua metodologia, riconosciuta a livello internazionale, è diventata un quadro di riferimento affidabile per la validazione e la qualifica dei sistemi che incidono sulla qualità di prodotti farmaceutici, farmaci biologici e dispositivi medici.

I passaggi e le categorie presentati qui hanno l'obiettivo di tradurre l'approccio basato sul rischio del GAMP in un processo concreto e operativo per la validazione e l'integrazione del software del sistema di monitoraggio nel sistema QMS. Applicando questi principi, è possibile garantire che il sistema funzioni in modo affidabile, sia sempre pronto ad affrontare le ispezioni e supporti sia la conformità normativa sia la qualità del prodotto per l'intero ciclo di vita.

Webinar on demand

Validazione del software del sistema di monitoraggio secondo il metodo GAMP®5

Secondo le linee guida GAMP® (Good Automated Manufacturing Practice) della International Society for Pharmaceutical Engineering (ISPE), i sistemi di monitoraggio ambientale sono classificati come "sistemi automatizzati". Questi principi riconosciuti a livello internazionale aiutano le aziende GxP a garantire le prestazioni, la conformità e l'affidabilità dei sistemi computerizzati.

In questo webinar su richiesta, Paul Daniel, Senior Regulatory Compliance Expert di Vaisala, spiega come applicare l'approccio basato sul rischio di GAMP®5 per validare il software del sistema di monitoraggio. Illustra passaggi pratici, esempi concreti e gli strumenti che è possibile utilizzare per allineare il processo di validazione alle best practice dell'ISPE.

Risorsa aggiuntiva: la pagina di destinazione del webinar include anche un'infografica gratuita sulla validazione GAMP, una guida visiva e concisa sul processo in 10 passaggi per la validazione dei sistemi di monitoraggio. Scaricarla con il webinar per consultarla rapidamente al bisogno.

Guarda ora

Prodotti e servizi per il monitoraggio continuo

Life Science Environmental Monitoring System