Questo è il secondo di una serie di tre articoli che presentano le lezioni apprese dal nostro team di convalida durante il completamento di un paio di progetti di convalida che utilizzavano la bozza della FDA della Computer Software Assurance for Production and Quality System Software Guidance (CSA). Il numero di risorse, la quantità di lavoro svolto e il numero di deliverable completati sono sempre al massimo livello durante la fase di esecuzione. Per questo motivo, la fase di esecuzione è quella in cui si verifica la maggior parte dei problemi durante l’attività di convalida, con un impatto significativo sui costi e sulle tempistiche del progetto. Questo articolo presenta le azioni che possono essere implementate per prevenire o almeno ridurre l’impatto dei problemi che si verificano durante l’implementazione delle metodologie CSA nella fase di esecuzione del progetto.
Lezione 1: Creare piani e protocolli di test completi per tutti i test di verifica
Il piano di convalida identifica i risultati necessari per completare la convalida dei sistemi. Inoltre, il contenuto dei piani e dei protocolli di test deve contenere informazioni e test che soddisfino i requisiti di verifica definiti nel piano. Un’area problematica che si presenta quando si utilizza la guida CSA è l’uso di documenti generati dal fornitore per verificare i requisiti a basso rischio. I documenti di test del fornitore sono solitamente creati al di fuori dell’ambito dello sforzo di validazione e spesso non includono aspettative e risultati di test documentati, l’identificazione e la risoluzione dei problemi o l’identificazione dell’esecutore del test e della data di esecuzione dello stesso. La guida CSA richiede queste informazioni nella documentazione di test quando si utilizzano i risultati dei test per verificare il funzionamento del sistema. La mancata registrazione di questi elementi durante i test può portare a ritardi nel completamento del progetto a causa della ripetizione dei test non adeguatamente documentati. Valutare il programma e le procedure di qualità di un fornitore per confermare che i suoi prodotti soddisfino i requisiti della guida per le registrazioni appropriate. Se i test del fornitore vengono esaminati e non soddisfano questi requisiti, è possibile modificare i test per soddisfare la guida prima che vengano eseguiti. Potrebbe trattarsi dell’aggiunta di un ulteriore spazio per le iniziali/date, di un riferimento alla risoluzione di un problema riscontrato o di una spiegazione più chiara dell’obiettivo del test. Un approccio proattivo all’aggiornamento dei documenti di test del fornitore può eliminare la riesecuzione dei test del fornitore che non soddisfano originariamente i requisiti di documentazione CSA per la verifica dei registri GxP.
I requisiti a medio o alto rischio vengono solitamente verificati utilizzando protocolli più robusti, creati con processi e procedure conformi alle norme GxP e rivisti e approvati dal produttore del farmaco anziché dal fornitore. I risultati dei test contengono di solito tutti gli elementi elencati nel CSA per una documentazione di test accettabile. Quando si creano questi documenti, una buona pratica è quella di includere nei protocolli una sezione che identifichi i requisiti verificati con i test già completati e che non richiedono ulteriori verifiche. Ad esempio, i Test di Accettazione del Sito (SAT) possono fare riferimento ai Test di Accettazione della Fabbrica (FAT) o ai test di sviluppo che verificano i requisiti a basso rischio. Le qualifiche di installazione e di funzionamento possono fare riferimento ai SAT o ai FAT nello stesso modo. L’approvazione dei protocolli che contengono queste sezioni dimostra che i gruppi di convalida e garanzia della qualità hanno accettato i risultati prima di passare alla fase di test successiva. Seguendo queste pratiche si evita di eseguire test eccessivi e non necessari e si evitano sorprese agli stakeholder del progetto quando si rivedono i requisiti e i risultati dei test in una fase successiva del progetto.
Lezione 2: Monitorare attentamente tutti i test
Ricorda che molti fornitori sono abituati a eseguire i loro test di sviluppo e di fabbrica con poca supervisione, registrando in modo informale i risultati dei test e documentando solo in minima parte i problemi e le relative risoluzioni. Documentare formalmente i risultati dei test, registrare i problemi riscontrati (e la loro risoluzione) e firmare e datare tutti i dati inseriti sono spesso pratiche nuove. Anche dopo aver partecipato a una sessione di formazione per spiegare il nuovo processo di test/documentazione, è possibile che i clienti ricadano nelle vecchie abitudini, soprattutto quando si tratta di problemi e deviazioni. Questo può far sì che i risultati dei test e la documentazione consegnata non soddisfino i requisiti di buona documentazione (GDP) (GDP) per l’utilizzo nell’attività di validazione. L’implementazione di meccanismi di monitoraggio continuo per individuare e risolvere tempestivamente i problemi durante l’esecuzione può ridurre al minimo il numero di risultati di test inaccettabili che vengono forniti dai test eseguiti dal fornitore. È particolarmente importante monitorare i prodotti del fornitore durante i test di sviluppo finale e il FAT, quando il fornitore si concentra sull’approvazione del sistema e non sulla generazione di una documentazione di convalida accettabile.
Un metodo utilizzato per fornire questa ulteriore supervisione è quello di organizzare brevi riunioni di stato durante i test del fornitore per rispondere alle domande e rafforzare i requisiti dei test. Esaminando un campione di risultati di test durante queste riunioni e presentando esempi di risultati di test correttamente documentati, soprattutto nelle prime fasi del test, si può verificare l’aderenza ai protocolli, fornire un esempio visivo di risultati di test correttamente registrati ed evitare di dover modificare molti risultati di test documentati più avanti nel progetto. Queste modifiche aggiungono un numero sorprendente di risorse e di tempo alle fasi successive del progetto, quindi è una buona pratica rivedere i risultati dei test in anticipo per evitare che causino problemi in seguito. Questo tipo di supervisione accelera anche la risoluzione dei problemi nelle prime fasi del progetto, in quanto scoraggia la pratica passata dei fornitori di notare molti problemi rilevati durante i test di sviluppo e persino il FAT, ma di non completare la riparazione fino ai test SAT o di qualificazione. Questo era accettabile prima del CSA perché la maggior parte delle aziende accettava i risultati dei test di qualificazione solo durante il loro sforzo di convalida. Tuttavia, è un problema quando i risultati dello sviluppo e del FAT vengono utilizzati come record appropriati nella convalida del sistema.
Lezione 3: Comunicazione/Collaborazione
I piani di convalida che seguono le metodologie di convalida esistenti richiedono una comunicazione efficace e molta flessibilità durante la loro esecuzione. L’impiego di nuove pratiche che utilizzano le linee guida CSA rende ancora più importante l’utilizzo di questi due strumenti per tutta la durata del progetto. È necessario organizzare riunioni che si concentrino sui problemi, soprattutto quelli legati all’adesione alla guida CSA. Promuovi l’apertura del team, poiché alcuni membri potrebbero sentirsi a disagio per i cambiamenti e avere bisogno di rinforzi per operare come desiderato. Promuovi un approccio collaborativo alla deviazione e alla risoluzione dei problemi anche durante queste riunioni. Stabilisci canali di comunicazione chiari per segnalare e affrontare i problemi, fornire aggiornamenti al progetto e identificare le risorse adeguate per completare i compiti. Queste azioni aiutano a mantenere la tempistica del progetto accelerando la risoluzione dei problemi, tenendo informati i membri del team e aumentando l’efficienza dell’esecuzione. Una buona pratica è quella di creare una matrice di tracciabilità dei requisiti all’inizio del progetto e aggiornarla durante ogni fase di convalida. In questo modo si identifica il rischio di ogni requisito, il rigore di test associato e il documento che verifica i risultati dei test per il requisito, ma si documenta anche visivamente l’avanzamento del progetto, si identificano eventuali modifiche ai deliverable e si riducono al minimo le lacune identificate quando il progetto sta per essere completato. Questa capacità di modificare rapidamente la convalida ridurrà al minimo l’impatto sui piani di test e sul calendario.
La fase di esecuzione sarà sempre la fase più imprevedibile di un progetto di convalida e l’implementazione della guida CSA espone molte risorse a una filosofia di convalida del software diversa da quella a cui erano abituate, il che può rendere i test ancora più imprevedibili. L’implementazione delle azioni suggerite in questo articolo può eliminare un po’ di imprevedibilità dalla fase di esecuzione, correggendo i problemi nelle prime fasi del progetto per ridurre le successive rielaborazioni. I risultati della fase di esecuzione sono estremamente importanti perché forniscono a eventuali revisioni normative o future una prova documentata di come il sistema è stato convalidato. I risultati della convalida devono essere chiari, concisi e completi e verificare che i requisiti del sistema siano soddisfatti, indipendentemente dalla quantità di test e ritest, quindi ha senso organizzarsi per farlo bene la prima volta.