La nuova edizione della linea guida ISPE GAMP 5

A Luglio 2022 è stata pubblicata la seconda edizione della linea guida ISPE GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems che, pur mantenendo i principi e il quadro di riferimento della prima edizione, è stata aggiornata per recepire alcune novità tra cui:

  • Accresciuta importanza dei fornitori di servizi
  • Evoluzione degli approcci di software development (es. Agile)
  • Uso esteso di strumenti software e tool
  • Importanza del critical thinking
  • Recepimento delle indicazioni della data integrity

Argomenti nuovi e in evoluzione nel settore life science – tra cui blockchain, intelligenza artificiale (AI/ML), cloud computing, software open source (OSS) – sono stati inclusi nelle Appendix della guida, aggiornate come evidenziato in questo elenco:

  • Appendix M11 – IT Infrastructure NEW
  • Appendix M12 – Critical Thinking NEW
  • Appendix D1 – Specifying Requirements UPDATED
  • Appendix D2 – RETIRED
  • Appendix D8 – Agile Software Development NEW
  • Appendix D9 – Software Tools NEW
  • Appendix D10 – Distributed Ledger Systems (Blockchain) NEW
  • Appendix D11 – Artificial Intelligence and Machine Learning (AI/ML) NEW
  • Appendix O7 – RETIRED
  • Appendix S2 – Electronic Production Records UPDATED
  • Appendix S5 – RETIRED

CRITICAL THINKING

La nuova linea guida ISPE GAMP 5 promuove il critical thinking, cioè un processo decisionale informato utile a definire qual è l’approccio più appropriato per circostanze specifiche.

Il “pensiero critico” permette di comprendere e valutare dove il processo aziendale e il flusso dei dati può potenzialmente influire sulla sicurezza del paziente, sulla qualità del prodotto e sull’integrità dei dati, sia introducendo nuovi fattori di rischio sia mitigando rischi già presenti.

Il critical thinking funge quindi da supporto nelle decisioni di Qualità e conformità per i sistemi informatici. Ad esempio, l’applicazione del critical thinking permette di valutare l’estensione e la profondità dei test e della documentazione a supporto, ma anche la definizione delle attività della fase di mantenimento come la frequenza della periodic review.

AGILE

Un’altra novità delle GAMP 5 è la metodologia Agile per lo sviluppo del software, caratterizzata da un approccio iterativo e incrementale. Proprio per questo motivo il ciclo di vita dei software, e in particolare la fase di Project, possono essere rappresentati sia dal tradizionale modello a V (lineare) sia con l’andamento circolare tipico dei software sviluppati in Agile.

Un’altra conseguenza è l’utilizzo di tool a supporto di ogni fase del ciclo di vita del software, tool nei quali le informazioni e le evidenze sono mantenute in forma di record piuttosto che in forma di documenti cartacei.

Questi tool, inoltre, non richiedono convalida, ma un assessment per adeguatezza, oltre che l’utilizzo da parte di personale istruito e qualificato anche su tematiche GxP, la tenuta sotto controllo e la supervisione da parte dell’Assicurazione Qualità.

FORNITORI DI SERVIZI

L’aggiornamento delle GAMP 5 dà maggiore importanza al ruolo dei fornitori di servizi, in particolare in caso di sistemi cloud. Questo si rispecchia nell’importanza data agli audit e ai contratti stipulati tra fornitori e azienda regolata come strumenti di selezione e controllo dei fornitori e di riduzione dei rischi, sia durante la convalida iniziale che poi nella definizione dei processi della fase di mantenimento. É infatti necessario ricordare che la responsabilità ultima della conformità rimane dell’azienda regolata, anche quando una o più delle attività del ciclo di vita vengono delegate a un provider esterno.

Parlando di fornitori è stato sottolineato, inoltre, come questi non siano direttamente soggetti alle GXP e come sia necessario fare ricorso ad altri standard, ad esempio le ITIL, a complemento delle linee guida GAMP 5.

CATEGORIE DEL SOFTWARE

Le categorie del software non sono più da considerarsi come divisioni nette, ma come un continuum: infatti i software possono essere composti da elementi di categorie differenti. Per questo nella nuova edizione delle GAMP 5 si parla di componenti piuttosto che di prodotti.

La categoria di appartenenza del software non è poi l’unico fattore di definizione dello sforzo di test o del formalismo della documentazione, ma vanno prese in considerazione l’analisi dei rischi, la valutazione del fornitore, la novelty e la complessità del sistema, nonché il già citato critical thinking. La categoria rappresenta anche un criterio per la valutazione dei fornitori.

Un’altra importante novità è data dall’estensione della categoria 1, ora meglio dettagliata in Sistemi Operativi, software tool non GxP critici (es. tool IT) e software tool GxP critici (cioè che impattano direttamente un processo GxP o dati GxP critici).

LA CONVALIDA DEI SISTEMI COMPUTERIZZATI

Per quanto riguarda la convalida iniziale dei sistemi, le novità principali risiedono nella definizione dei requisiti e nella attività di testing.

SPECIFYING REQUIREMENTS (Appendice D1)

Una delle più grandi novità della nuova linea guida ISPE GAMP 5 è l’accorpamento di User Requirements e Functional Specification negli Specifying Requirements. Questi ultimi:

  • sono responsabilità dell’azienda regolata, ma possono essere raccolti da una terza parte (es. il Product Owner di un progetto Agile);
  • definiscono l’intended use e le funzioni attese del software nel suo contesto operativo;
  • possono essere in forma di documento o di record/informazioni in un tool.

L’Appendice D1 parla di Specifying Requirements prendendo in considerazione sistemi di categoria 4 o 5, mentre per sistemi a basso rischio e/o complessità (es. categoria 3) può essere applicato il critical thinking per determinare l’approccio più appropriato per definire i requisiti.

TESTING (Appendice D5)

Lo scopo principale dei test è identificare i difetti, ridurre il rischio di failure, dimostrare che il sistema soddisfi l’uso atteso e i requisiti regolatori, e assicurare che le misure di riduzione del rischio siano efficaci. Cambia quindi il focus delle attività di test con una conseguente disincentivazione alla produzione eccessiva di evidenze documentali.

Le GAMP 5 introducono inoltre il concetto di unscripted test, che si differenziano dagli scripted test per il fatto che non necessitano di azioni di test step-by-step, ma si basano sull’intuizione e l’esperienza dei tester per individuare i difetti del sistema ed esplorano le sue funzionalità al di là delle specifiche e dei manuali – per questo motivo sono dinamici e scarsamente riproducibili. Unscripted test non significa però “non documentato”, infatti è comunque necessario indicare cosa è stato testato, da chi, quando, con quali obiettivi e che risultati ha prodotto.

Tra gli uscripted test troviamo:

  • Test ad-hoc
  • Error guessing
  • Exploratory
  • Day in the life

Anche nel caso di testing, è incentivato l’uso di tool automatici al posto dei test «classici» se le informazioni fornite sono complete, accurate, disponibili e adeguate.

MANTENIMENTO DELLO STATO DI CONVALIDA DEI SISTEMI COMPUTERIZZATI

Per quanto riguarda la fase di mantenimento, le principali novità riguardano – oltre ai già citati tool e all’utilizzo del critical thinking – una migliore descrizione dei processi e la creazione di link tra questi, nonché riferimenti allo stato dell’arte tecnologico (ad esempio, per le soluzioni di backup e di archiviazione) e considerazioni sui servizi erogati da provider esterni.

BACKUP E RESTORE (Appendice 09) e BUSINESS CONTINUITY MANAGEMENT (Appendice O10)

Nella nuova versione delle GAMP 5 questi due processi, pur rimanendo descritti in appendici diverse, presentano una trattazione parallela a partire dall’analisi dei rischi e dalla definizione di RTO (Recovery Time Objective) e RPO (Recovery Point Objective).

Interessanti sono, inoltre, l’introduzione dei test di integrità delle copie di backup e l’estensione di BCP (Business Continuity Plan) e DR (Disaster Recovery) alla perdita di infrastruttura IT, service provider, accesso ai locali, connettività, attacchi di cybersecurity, pandemia, in aggiunta alla perdita dell’applicativo software.


COSA POSSIAMO FARE PER VOI

Adeodata può darti una mano con attività di consulenza e di supporto a tutte le attività del ciclo di vita dei software (convalida iniziale, attività di mantenimento, redazione di SOP, dismissione dei sistemi,…) .

Se ti interessa approfondire le nuove GAMP 5, l’8 Novembre è in programma il seminario Convalida dei sistemi informatizzati e conformità all’Annex 11 e 21 CFR Parte 11.
Inoltre, è possibile richiedere un corso di approfondimento sulle novità della nuova edizione delle GAMP5 o, più in generale, sulla convalida dei sistemi computerizzati nella modalità di corso in house.

Articolo a cura di:
Alice Germani, Marketing Specialist di Adeodata
Laura Monti, GxP Compliance Expert di Adeodata

Data Integrity nel Laboratorio QC: le cose da ricordare

Ormai da diversi anni la data integrity è un punto chiave della compliance aziendale, ciononostante gli ispettori continuano a riscontrare non-conformità, soprattutto all’interno dei laboratori QC.

Quali tipi di dati vengono raccolti in laboratorio?

  • dati dai lotti testati e dati del personale che esegue i test
  • dati su campionamento e conservazione dei campioni, registrazioni, osservazioni
  • peso e preparazione dei campioni, standard e reagenti utilizzati
  • dati di qualifica e calibrazione degli strumenti utilizzati
  • controlli sugli strumenti
  • sequenze di dati complete
  • dati che devono essere registrati
  • dati di processo
  • calcoli specifici di dispositivo
  • picchi
  • calcoli
  • trend
  • risultati dei suitability test
  • report generati da dati elettronici
  • audit trail, deviazioni e cambi
  • osservazioni documentate
  • calcoli eseguiti utilizzando software esterni

Tutti questi dati devono essere in compliance con i principi ALCOA, o meglio ALCOA plus.

Prendiamo ora in esame gli aspetti fondamentali della data integrity durante la generazione di un dato.


Data integrity in laboratorio: cosa ricordare

  • L’accesso alle funzionalità chiave di amministrazione del sistema (abilitare/disabilitare l’audit trail, cambiare data e ora…) deve essere limitato al solo personale autorizzato e indipendente (segregation of duties).
  • Gli account devono essere, quando applicabile, nominali e non di tipo amministrativo. Non devono esserci account di gruppo o login anonimi. I privilegi degli utenti devono essere assegnati in funzione del ruolo a sistema. Non devono essere assegnati in funzione del ruolo aziendale (es. il QC manager non necessariamente deve aver i privilegi più alti: se entra in un sistema solo per eseguire analisi, deve avere il ruolo di analista junior).
  • E’ essenziale la qualifica, la convalida, la taratura periodica e la manutenzione di tutti i sistemi computerizzati critici, degli strumenti di laboratorio e dei sistemi di valutazione e controllo. 
  • I dati e l’Audit Trail devono essere rivisti prima di prendere decisioni basate sui dati, in particolare per il rilascio del lotto. Le deviazioni devono essere indagate. Devono esserci meccanismi di blocco dei dati per impedire le modifiche a dati verificati/approvati.
  • Non è ammessa la cancellazione, la sovrascrittura di raw data e risultati e il testing-into-compliance.
  • Ogni modifica ai dati (integrazione manuale, riprocessamento o modifica a fattori di calcolo, pesi e quantità) deve essere documentata, deve essere eseguita in accordo a una procedura scritta e deve essere oggetto di revisione.
  • Le analisi devono essere eseguite in accordo a procedure scritte e metodi qualificati. Ogni analisi ripetuta deve essere giustificata in forma scritta.
  • OOS, OOT, OOE o deviazioni devono essere investigate.
  • Se i dati mancano di robustezza e accuratezza (per esempio per una calibrazione o una convalida incomplete) non devono essere utilizzati.
  • L’audit trail deve essere attivo.
  • Le registrazioni devono essere contemporanee e nella documentazione ufficiale (es. quaderni di laboratorio, copie controllate dei moduli,,…).
  • I backup devono essere eseguiti, monitorati e verificati.