L’evoluzione delle norme sul tema della Computer System Validation

Nel febbraio 1983, la Food and Drug Administration (FDA) statunitense pubblica il “Bluebook”, la prima guida per l’ispezione dei sistemi computerizzati nella produzione farmaceutica. Il presupposto della guida, derivato dai principi di convalida per l’ingegneria viene esteso per la prima volta all’industria dei software concentrandosi sulla necessità di garantire la loro affidabilità nell’ambito del controllo dei processi produttivi. Per orientarsi sulla corretta gestione delle nuove tecnologie e consentirne il più ampio uso possibile nel 1997, l’FDA emette la 21 CFR parte 11 poi rivista nel 2003, mentre per i regolamenti GMP dell’Unione Europea solo un anno dopo nel 1998 si introdurrà il capitolo 11 dell’Eudralex poi rivisto quasi integralmente nel 2011. Dal 1997 in poi lo sforzo di convalidare ogni singolo software ad impatto GMP per dimostrare l’aderenza alle normative vigenti è stato identificato come uno dei principali ostacoli all’adozione di nuove tecnologie, l’esatto opposto di ciò che la FDA cercava di promuovere come un vantaggio sostanziale per garantire una maggiore sicurezza, qualità ed efficacia del prodotto.

Il primo effetto indesiderato è stato quindi quello di evitare gli investimenti in tecnologie sempre più moderne e conseguentemente i costi della convalida valutati proibitivi. Il secondo effetto indesiderato è stato quello di spendere molte risorse per una strategia di convalida guidata principalmente dalla preoccupazione di documentare all’estremo le fasi di test (IQ/OQ e PQ) che, in caso contrario, avrebbero posto l’azienda a rischio di potenziali osservazioni regolatorie. Ancora oggi, non è così raro che l’ispettore possa trovarsi in una situazione in cui non ha a disposizione tempo sufficiente per svolgere un audit efficace su un sistema computerizzato dovendo analizzare una notevole quantità di documenti prodotti durante le fasi di test. Se l’auditor riuscisse piuttosto a visionare i documenti e le fasi di test salienti, avrebbe un’idea sufficientemente affidabile del grado di conformità del sistema auditato? La riflessione più importante in merito a queste problematiche deve riguardare la strategia di convalida che seppur ben declinata nell’applicazione pratica proposta dalle linee guida GAMP5 dell’ISPE è uno standard che non è stato rivoluzionato tenendo conto della grandissima varietà di piattaforme e tecnologie diverse e del reale rischio in cui si incorre quando l’evoluzione tecnologica precede le regolamentazioni in vigore.

Perché è necessario rilanciare un nuovo approccio alla CSV e cosa comporta esattamente il nuovo modello CSA proposto dall’FDA?

Nel 2011, durante una revisione dei dati sulla qualità dei dispositivi medici, il Center for Devices and Radiological Health (CDRH) della FDA ha investigato i potenziali rischi che influivano sulla qualità del prodotto ed il risultato li ha spinti a lanciare l’iniziativa “Case for Quality”. Uno dei risultati chiave del “Case for Quality” è stato il tema della Computer System Validation (CSV); per sostenere ancora una volta l’uso di nuove tecnologie, la FDA ha avviato la redazione di una nuova linea guida intitolata “Computer Software Assurance for Manufacturing, Operations, and Quality System Software”, la guida affronterà i problemi derivanti dall’attuale approccio alla computer system validation e presenterà il nuovo modello di transizione alla Computer Software Assurance (CSA) sempre basato sul rischio come già promosso da ICHQ9 ma meno oneroso in termini di pratica delle fasi di test e di produzione della documentazione di convalida.

Qual è la reale differenza tra la tradizionale CSV e la CSA?

La convalida dei sistemi computerizzati (CSV) è stata tradizionalmente definita come un processo sistematico basato su evidenze documentate atte a dimostrare che un software funziona secondo le specifiche previste e le aspettative degli enti regolatori. Molteplici osservazioni regolatorie hanno dimostrato che l’onerosità e l’inefficacia delle attuali strategie di convalida dipendono dal fatto che la fase di test pesa il 20% dell’intero processo di convalida mentre l’80% è solo uno sforzo documentale; il nuovo modello della Computer Software Assurance (CSA) si propone di superare questo gap, dedicando l’80% delle risorse alle verifiche per l’affidabilità dei software. Il modello della Computer Software Assurance (CSA) sta quindi emergendo come una disciplina in grado di aumentare il grado di affidabilità di un software ma limitare le fasi di test e l’evidenza documentale alle sole funzioni che incidono direttamente sulla qualità del prodotto e sulla sicurezza del paziente. Inoltre, CSA incoraggia le aziende ad utilizzare la documentazione dei fornitori di software per ridurre il carico di test e conseguire più velocemente il rilascio di un sistema computerizzato in produzione. Le aziende potranno assicurare una maggiore affidabilità dei sistemi indirizzando i test di convalida solo alle attività ad alto rischio e in accordo alla destinazione d’uso del sistema.

CSA: l’attuazione del modello e l’approccio basato sul rischio

Il modello CSA è suddiviso in quattro fasi principali:

1. Identificare la destinazione d’uso del software
2. Determinare i fattori di rischio
3. Adottare il “Leveraging Approach”
4. Sviluppare strategie e metodi di test agili

1. Identificare la destinazione d’uso del software.
   CSA promuove l’esecuzione di test di convalida a livelli di intensità crescente in base al rischio associato all’uso del software. La CSA richiede in primis di identificare la destinazione d’uso del sistema e di stabilire se questi influisce direttamente sulla qualità del prodotto e/o sulla sicurezza del paziente. Secondo la FDA, ad esempio, i software gestionali non possono essere soggetti agli stessi rigorosi requisiti di convalida dei sistemi informatici che sono utilizzati per il processo produttivo. Anche i software per la gestione dei documenti, la gestione dei change control e la gestione degli audit non richiedono lo stesso rigore nei test su software deputati alla lavorazione di un prodotto.

2. Determinare i fattori di rischio
   L’approccio basato sul rischio richiede anche di valutare le aree o le funzioni che possono influire sulla qualità del prodotto, sulla sicurezza del paziente o sull’integrità del sistema e identificare ogni potenziale “failure” di un sistema informatico; il metodo di analisi tradizionale si concentra sul calcolo della gravità del danno (S), della probabilità di accadimento (P) che combinate insieme alla rilevabilità dell’errore (R) portano ad un valore di rischio globale (R=SxPxR). Il metodo consigliato con la CSA è il calcolo del rischio/impatto sulla sicurezza del paziente e sulla qualità del prodotto, in relazione al metodo di implementazione di ogni funzionalità del software (es. una personalizzazione o una configurazione) come mostra la tabella 1 sotto:

Per valutare il rischio cui incorre il paziente è necessario fare le seguenti valutazioni sulla destinazione d’uso del software:

• Alto rischio (es. sistemi di ispezione, di etichettatura e batch disposition) richiederà certamente test e deliverables uguali alle aspettative attuali, ovvero più rischiosa è l’applicazione, maggiori test e documentazione sono richiesti.
• Medium rischio è un software che non ha un impatto diretto sulla sicurezza del prodotto o del paziente, ma ha un impatto sul sistema di qualità (ad es. software per la gestione dei reclami, la gestione dei change control, le procedure o altri documenti ad impatto GMP). Non è quindi necessario lo stesso rigore nei test e certamente richiedono meno documentazione rispetto ai sistemi ad alto rischio.
• Basso: è un software che non rientra nelle due categorie precedenti. La strategia di test è estremamente semplificata sia nelle fasi di test che nei documenti da produrre.
• Nessuno: è un software che non ha alcun impatto né diretto né indiretto sulla sicurezza del prodotto o del paziente, il software non gestisce, processa o mantiene dati rilevanti ai fini GMP.

Per valutare il metodo di implementazione si deve fare riferimento alle categorie software proposte dal modello GAMP5 dell’ISPE.

Il risultato che si ottiene incrociando il metodo di implementazione della funzionalità del software con il rischio verso il paziente finale è un livello di rischio complessivo che indirizza la robustezza e la consistenza dei test di verifica.

3. Adottare il “leveraging approach”
   Il punto in cui il valore aggiunto del modello di CSA inizia ad emergere risiede nello sfruttamento intelligente delle attività di test eseguite dagli stessi fornitori del software. Il vantaggio maggiore è applicabile ai sistemi con funzionalità a rischio medio- basso dove lo sforzo richiesto è minimo o nullo. Le aziende, quindi, devono limitare l’utilizzo delle loro risorse e non replicare la convalida dei fornitori se già qualificati con successo né riprodurre deliverables già disponibili. Se il fornitore dispone di documentazione tecnica, l’indirizzo è quello di sfruttarla previa valutazione della consistenza. La figura 1 sotto mostra l’X- Model, è una vista delle fasi necessarie per specificare, progettare e sviluppare tutte le soluzioni software. La maggior parte delle soluzioni acquistate avrà già la sezione inferiore eseguita dal fornitore e alcune delle sezioni della parte superiore che spettano al produttore possono essere eseguite insieme in fasi combinate. L’X- Model mostra infatti la relazione tra i 2 V-Model quello lato produttore software e quello lato azienda produttrice.

4. Sviluppare strategie e metodi di test agili
   Adottare la strategia di test “Scripted” oppure “Unscripted” secondo le necessità ed in base al rischio è uno dei pilastri del nuovo modello CSA. Spieghiamo sotto la differenza tra i due tipi di test!

• Scripted
  Il test basato su script è quello tradizionale e secondo l’approccio CSA da utilizzare solo per sistemi ad alto rischio che influiscono direttamente sul prodotto o sulla sicurezza del paziente. Questo tipo di test documenta la tradizionale procedura step by step in un protocollo che include i risultati attesi e il giudizio di conformità (Superato/Fallito) sull’esito finale del test.

• Unscripted
  Il test senza script deve invece essere utilizzato per sistemi a medio-basso rischio che non influiscono direttamente sul prodotto o sulla sicurezza del paziente. Non sono necessari in questo caso script di test dettagliati, ma le aziende possono documentare semplicemente l’obiettivo del test e l’esito del test (Superato/Fallito).La tabella 4 di seguito descrive come il livello di rigorosità dei test si debba tradurre nel protocollo di qualifica, nei risultati e nella raccolta delle evidenze.

Tabella 4. Strategia di test secondo il modello CSA

Cosa significa oggi il modello CSA per le organizzazione ed il sistema di gestione della qualità?

La differenza sostanziale tra il metodo CSV tradizionale e il nuovo modello CSA risiede nella valorizzazione delle risorse economiche ed umane attraverso l’applicazione del pensiero cosiddetto critico. I sistemi di gestione della qualità hanno applicato i principi del Quality Risk Management senza trarne mai reali vantaggi di semplificazione nei processi di convalida; oggi l’analisi di rischio deve tradursi in un esercizio che unisce il ragionamento inteso come sforzo di approfondimento alla logica intesa come capacità di delineare una strategia al fine di assicurare:

• una convalida robusta con il massimo grado di rigore verso le classi di rischio più elevate;
• un grado di affidabilità maggiore dei software nella fase successiva la “go-live”;
• un tempo di rilascio del software ridotto;
• un costo complessivo più sostenibile.

Il modello CSA per gli enormi vantaggi che promette dovrà essere incentivato dall’alta direzione e sostenuto dal sistema di qualità interno delle aziende in quanto la sua adozione potrebbe in assenza di uno sponsor, essere un processo lungo e faticoso rispetto al tradizionale approccio alla computer system validation.

AUTRICE

• Gabriella Di Stefano, Senior Business Manager di AKKA Technologies