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

Audit Trail: le non conformità più comuni

Durante le ispezioni si riscontrano spesso non conformità legate ai sistemi computerizzati. In cima alla lista troviamo quelle legate all’Audit Trail.

An audit trail is a chronology of the “who, what, when, and why” of a record.

FDA Data Integrity Guidance for Industry, 2016

Dunque l’Audit Trail è definito come l’insieme dei metadati registrati in merito alle informazioni critiche per permettere la ricostruzione delle attività GMP.

I requisiti regolatori

Le non conformità riscontrate nel corso delle ispezioni in relazione all’Audit Trail sono molteplici e spesso correlate al software utilizzato. Infatti i fornitori di software o di sistemi spesso non forniscono ciò che è effettivamente richiesto dalle normative

Ma dove viene il requisito per la funzionalità di audit trail in un sistema computerizzato?
Un riferimento si trova nel capitolo 4 delle EU GMP:

… Any change to an entry in a document should be signed off and dated. Despite modification, the original information should remain legible. If indicated, the reason for the change should be recorded.

EU GMP, § 4.9

Queste informazioni possono essere trovate anche nella linea guida GAMP Records and Data Integrity:

“Audit trails should be considered part of records.”

GAMP, §18.7

Anche l’Annex 11 parla di Audit Trail richiedendone la presenza sulla base di un risk assessment e inserendo tra i requisiti anche la review.

Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated “audit trail”). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.

Annex 11, EU GMP

Nel 2018, anche MHRA ha unito il concetto di review alla valutazione del rischio. Nello stesso documento si fa specifico riferimento a chi si occupa della review e si afferma l’importanza di una conoscenza sufficiente allo svolgimento dell’attività.

Routine data review should include a documented audit trail review where this is determined by a risk assessment.

[…] Reviewers should have sufficient knowledge and system access to review relevant audit trails, raw data and metadata.

MHRA ‘GXP’ Data Integrity Guidance and Definitions, 2018

Non conformità trovate da FDA

Ma non sono solo gli ispettori Europei a trovare non conformità relative agli Audit Trail in sede di ispezione. Ecco qualche esempio proveniente da Warning Letter FDA:

We also note that your SOP does not have provisions for any audit trail reviews to ensure that deletions and/or modifications do not occur.

Gulf Pharmaceutical Industries, 2012

In addition, your firm’s review of laboratory data does not include a review of an audit trail or revision history to determine if unapproved changes have been made.

Sunrise, 2010

During the walkthrough of the Control Room where Formulation Plant processes were being monitored using a Building Automation System, we observed that the system was not qualified and had no audit trail capabilities. In addition, when asked about the alarms on the system, the Sr. Assistant Instrumentation group, stated that he would reset and clear the alarms.

Strides Pharma Science Limited, India, 2019

FDA ha inoltre pubblicato la Guidance for Industry Data Integrity and Compliance with drug CGMP_ Questions and Answers.
La linea guida è la versione aggiornata della bozza pubblicata nel 2016 e comprende informazioni aggiornate sul punto di vista dell’Agenzia in merito alle best practice per progettare, mettere in opera, monitorare e mantenere un sistema di data integrity.
La struttura del documento prevede 18 domande e risposte. Le domande 8 e 9 riguardano la review dell’audit trail.

Ne avevamo parlato in questo articolo

Non conformità più comuni

Tante sono le non conformità che vengono riscontrare riguardanti l’Audit Trail. Le più comuni sono le seguenti:

  • Un membro del personale di Laboratorio ha i diritti di un amministratore di sistema ed è in grado di apportare modifiche non rilevabili durante le analisi, di attivare o disattivare l’Audit Trail.
  • Non viene descritta alcuna azione da intraprendere in caso di problemi durante la review.
  • Non esiste una politica chiara su chi sia autorizzato a disabilitare la funzionalità di Audit Trail e su come documentare questa attività.
  • Il rilascio del lotto viene effettuato senza la revisione dei dati rilevanti dell’Audit Trail.
  • Mancano SOP e istruzioni sulla gestione dell’Audit Trail:
    • Quando e con che frequenza effettuare la review
    • Chi deve eseguire la review
    • Come archiviare l’Audit Trail
    • Quando un Audit Trail può essere cancellato
    • Quali dati sono considerati critici
    • Come documentare la review
    • Quali azioni intraprendere in caso si identifichino dei problemi durante la review.

Approfondisci il tema della data integrity in Laboratorio

Conclusione

In conclusione, ci sono alcune cose che è bene tenere in considerazione quando si parla di Audit Trail:

  • L’Audit Trail è parte della documentazione GMP ed è un requisito normativo
  • Così come per tutti i documenti GMP, la sua review è necessaria
  • Il risk assessment serve a determinare quando effettuare la review e con che frequenza
  • L’audit trail dovrebbe essere parte della convalida del sistema. La documentazione di convalida serve a dimostrare che gli audit trail sono funzionali e che tutte le attività e i cambiamenti sono registrati in una forma utilizzabile.

Per il futuro, si spera che in una nuova revisione dell’Annex 11 vengano dettagliati e specificati meglio i requisiti per l’Audit Trail in modo da ridurre sensibilmente le non conformità riscontrate in sede di ispezione.


Fonti

EU GMP Capitolo 4

EU GMP Annex 11

FDA Data Integrity and Compliance with drug CGMP_ Questions and Answers.

Periodic Review: quando, come e perchè

Articolo a cura di Ing. Laura Monti, Subject Matter Expert, Adeodata srl


La Periodic Review è di fondamentale importanza per confermare nel tempo lo stato di convalida dei sistemi computerizzati. Non a tutti è chiaro quando svolgerla, cosa verificare, come documentarla.
Facciamo un po’ di chiarezza insieme.

I sistemi computerizzati GxP critici devono essere convalidati per assicurare che “quando un’operazione manuale viene effettuata da un sistema computerizzato non venga ridotta la qualità del prodotto, il controllo del processo e l’assicurazione della qualità. Inoltre, non ci dovrebbe essere alcun incremento del rischio complessivo del processo” (EU GMP Annex 11). La convalida è necessaria, inoltre, per garantire “accuratezza, affidabilità, performance prevista e capacità di distinguere record non validi o alterati” (FDA 21 CFR part 11.10(a)).

A differenza degli equipment, non è necessario riqualificare periodicamente i sistemi computerizzati poiché non sono soggetti ad usura. Per confermare nel tempo lo stato di convalida dei sistemi computerizzati la Periodic Review è, quindi, di fondamentale importanza.

Inoltre, la Periodic Review è richiesta esplicitamente dell’EU GMP Annex 11 §11:

I sistemi computerizzati devono essere periodicamente valutati per verificare il mantenimento dello stato di convalida e la conformità alle normative GMP. Tali valutazioni dovrebbero includere, dove appropriato, funzionalità correnti, deviazioni, incidenti, problemi, aggiornamenti, prestazioni, affidabilità, sicurezza e relazioni sullo stato di convalida.

Indicazioni sulle modalità di esecuzione della Periodic Review sono riportate nell’Appendix O8 delle linee guida GAMP5.

QUANDO SVOLGERE LA PERIODIC REVIEW

La Periodic Review deve essere svolta periodicamente, secondo un criterio documentato che consideri:

  • il grado di criticità del sistema (impatto GxP)
  • la sua complessità
  • il suo grado di novità

Tipicamente la Periodic Review viene eseguita ogni uno o due anni, ma possono essere definite frequenze diverse in base alla categoria GAMP5 del sistema e/o del tempo intercorso dalla fine della sua convalida iniziale.

Inoltre, è possibile eseguire anche Periodic Review straordinarie (cioè prima della loro scadenza naturale) in caso di:

  • Problemi riscontrati nell’operatività del sistema
  • Significativi cambiamenti apportati al sistema o svariate modifiche minori
  • Significativi cambiamenti normativi che impattano sul sistema

RESPONSABILITÀ DELLA PERIODIC REVIEW

È responsabilità del Process Owner garantire che venga eseguita la Periodic Review del sistema e che le eventuali azioni correttive identificate siano implementate in modo appropriato.

È responsabilità della Quality Unit assicurare che le revisioni periodiche siano programmate, eseguite e documentate.

La Periodic Review deve essere condotta da una o più persone a seconda dell’ambito della revisione. Il Team di revisione può includere: Quality Unit, Subject Matter Expert (SME), Utenti, IT, Engineering, Compliance e/o Consulenti esterni.

COSA VERIFICARE

Oggetto di revisione sono:

  • Stato di aggiornamento delle procedure operative e di manutenzione
  • Stato di aggiornamento della documentazione (es. specifiche, elenchi di eventi e allarmi…)
  • Disponibilità delle registrazioni delle sessioni di istruzione in linea con i ruoli utente a sistema
  • Applicazione delle procedure di Change e Configuration Management e stato delle registrazioni
  • Disponibilità di contratti e licenze
  • Applicazione delle misure di sicurezza logica e fisica previste per il sistema
  • Prestazioni del sistema
  • Eventuali aggiornamenti normativi
  • Sostituzione del personale con ruoli e responsabilità sul sistema
  • Deviazioni, incident, problemi ed eventi legati all’uso del sistema e CAPA correlate

A queste verifiche si possono aggiungere tutte quelle attività che devono essere eseguite a cadenza regolare, come le prove periodiche di restore (EU GMP Annex11 §7.2) e alcune attività legate alla Audit Trail review (EU GMP Annex11 §9). In particolare, è necessario verificare che la funzionalità di Audit Trail sia mantenuta in stato di convalida, ossia che:

  • L’Audit Trail sia attivo
  • La data, l’ora e la time zone del sistema siano corrette e sicure
  • La funzionalità di Audit Trail, le policy di sistema, le configurazioni e i parametri che possono avere impatto sulla modificabilità dei dati (es. configurazione dei profili utenti e relativi privilegi) siano rimasti invariati rispetto a quanto registrato e verificato durante la convalida iniziale, a meno di eventuali modifiche correttamente gestite in accordo alle SOP di Change Control e Configuration Management

COME DOCUMENTARLA

Alla fine della revisione viene redatto un report, o una check list, che include l’elenco degli aspetti del sistema verificati, le risultanze ed eventuali azioni correttive o raccomandazioni.

Vuoi approfondire l’argomento?
Convalida dei sistemi informatizzati e conformità all’Annex 11 e 21 CFR Part 11
16 Settembre 2021, 9:00 – 16:00

EMA: Sistemi computerizzati per gli studi clinici

I sistemi computerizzati sono sempre più utilizzati nella ricerca clinica. La complessità di questi sistemi e degli stessi trial clinici si è evoluta rapidamente negli ultimi anni, portando ad un aumento dell’utilizzo di sistemi computerizzati.

L’EMA ‘Reflection Paper on expectations for electronic source data and data transcribed to electronic data collection tools in clinical trials’ ha iniziato ad affrontare questi temi già dalla sua pubblicazione nel 2010.

La nuova linea guida (per ora in bozza) Guideline on computerised systems and electronic data in clinical trials ha lo scopo di assistere gli sponsor, i ricercatori e le altre parti coinvolte nelle sperimentazioni cliniche sull’uso di sistemi computerizzati e sulla raccolta di dati elettronici nelle sperimentazioni cliniche nel rispetto dei requisiti della legislazione vigente (Direttiva 2001/20/CE e Direttiva 2005/28/CE) e dell’ICH E6 Good Clinical Practice Guideline.
La bozza sarà disponibile per i commenti fino a fine 2021.

Di seguito si fornisce una panoramica generale e non esaustiva dei requisiti presentati nella bozza della nuova linea guida.

Principi e concetti chiave

  • Data integrity:
    Il mancato mantenimento dell’integrità dei dati durante il periodo di conservazione previsto può rendere i dati inutilizzabili ed equivale alla perdita o alla distruzione dei dati stessi. La mancanza della data integrity è considerata una non conformità GCP.
  • Responsabilità:
    I ruoli e le responsabilità negli studi clinici devono essere chiari. La responsabilità della conduzione di uno studio viene assegnata legalmente a due parti (gli sperimentatori e le loro istituzioni, e gli sponsor), ciascuna delle quali potrebbe utilizzare sistemi computerizzati per gestire dati relativi allo studio.
  • Dato elettronico e concetto di metadato:
    Senza il contesto fornito dai metadati, i dati non hanno alcun significato.
  • Dato fonte:
    Il primo dato permanente ottenibile dalla generazione elettronica di dati è considerato il dato fonte.
    Questo processo deve essere convalidato per assicurare che il dato fonte sia rappresentativo dell’osservazione originale e contenga i matadati necessari ad assicurare i requisiti ALCOA.
  • ALCOA ++
  • Criticità e rischi:
    L’ICH-GCP E6(R2) introduce la necessità di un sistema di gestione qualità con un approccio risk-based. I rischi devono essere considerati sia a livello di sistema che a livello di trial clinico specifico. I rischi relativi all’utilizzo dei sistemi computerizzati, specialmente quelli legati all’integrità dei dati, devono essere identificati, analizzati e mitigati. L’approccio utilizzato per ridurre il rischio deve essere proporzionato al rischio.
  • Raccolta dati:
    Il protocollo approvato della sperimentazione clinica dovrebbe specificare quali dati debbano essere generati/acquisiti, da chi, quando, e quali strumenti o procedure debbano essere utilizzati.
  • Firma elettronica:
    Ogni volta che una firma elettronica viene utilizzata all’interno di una sperimentazione clinica per sostituire una firma richiesta dalle GCP, la funzionalità della firma elettronica deve soddisfare le aspettative in merito ad autenticazione, non ripudio, collegamento indissolubile e marcatura temporale.
  • Protezione dei dati:
    La riservatezza dei record che potrebbero identificare i partecipanti allo studio deve essere protetta rispettando le regole sulla privacy e sulla riservatezza previste dai requisiti normativi.
  • Convalida dei sistemi computerizzati:
    Tutti i sistemi computerizzati utilizzati in uno studio clinico devono essere soggetti a un processo che confermi il rispetto dei requisiti e la performance del sistema. La convalida dovrebbe garantire accuratezza, affidabilità e prestazioni previste, dalla progettazione fino alla dismissione del sistema o alla transizione ad un nuovo sistema. I processi utilizzati per la convalida devono essere decisi dal proprietario del sistema (ad esempio sponsor, ricercatori, strutture tecniche) e descritti in un documento.
    I proprietari del sistema devono assicurare un’adeguata supervisione delle attività di convalida e della documentazione da parte dei contraenti per garantire che siano in atto procedure adeguate e che queste vengano rispettate. La documentazione deve essere conservata per dimostrare che il sistema è mantenuto nello stato convalidato e deve essere disponibile sia per la convalida del software che per la convalida della configurazione specifica per lo studio clinico. La convalida della configurazione specifica deve garantire che il sistema sia coerente con i requisiti del protocollo di sperimentazione clinica approvato e che vengano effettuati test approfonditi della funzionalità.
  • Accesso diretto ai sistemi computerizzati

Vuoi approfondire l’argomento?
L’11 novembre 2021 partecipa al nostro webinar
Sistemi computerizzati in ambito GCP

Requisiti per i sistemi computerizzati

La linea guida richiede che siano presenti:

  • una descrizione dei sistemi e dell’allocazione dei dati, delle responsabilità, dei database utilizzati e una valutazione della loro idoneità allo scopo previsto;
  • procedure scritte per l’utilizzo dei sistemi;
  • training per l’uso dei sistemi computerizzati;
  • processi di sicurezza e misure atte a garantire la data integrity e la protezione dei dati.

Dati elettronici

Per ogni studio, è necessario sapere quali dati e record elettronici saranno raccolti, modificati, importati
ed esportati, archiviati e le modalità di trasmissione. Dati elettronici, e corrispettivi audit trail, devono essere accessibili a sperimentatori, monitor, auditor e ispettori senza compromettere la riservatezza delle identità dei partecipanti allo studio (ICH-GCP 1.21).

  • Raccolta dati e posizione
    La posizione di tutti i dati di origine deve essere specificata prima dell’inizio del processo e tenuta aggiornata. (ICH-GCP 8.1. Appendice).
  • Trascrizione da carta a elettronico
    I dati originali raccolti su carta devono essere trascritti manualmente o tramite uno strumento di immissione convalidato nel sistema o nei database. In caso di trascrizione manuale, dovrebbero essere implementati metodi basati sul rischio per garantire la qualità dei dati trascritti.
  • Trasferimento tra sistemi elettronici
    I dati dello studio vengono trasferiti regolarmente all’interno dell’organizzazione e tra sistemi. Tutti i trasferimenti di file e di dati devono essere convalidati.
  • Acquisizione diretta di dati
    L’acquisizione diretta dei dati può essere eseguita da dispositivi automatizzati o da altri strumenti tecnici. Tali dati devono essere sempre accompagnati dai metadati relativi al dispositivo utilizzato.
  • Verifica data entry
    I controlli sull’immissione dei dati devono essere convalidati. La sospensione dei controlli deve essere documentata e giustificata.

Requisiti per l’audit trail

  • Audit trail:
    In un sistema computerizzato, l’audit trail deve essere sicuro, generato dal computer, con data e ora. L’audit trail deve essere robusto e non deve essere possibile per un utente normale disattivarlo.
  • Audit trail review:
    Dovrebbero essere predisposte procedure per la review di audit trail basate sul rischio e l’esecuzione della revisione dei dati deve essere documentata. La revisione dei dati deve concentrarsi sui dati critici ed essere proattiva e continua.
  • Firma dei dati:
    Gli sperimentatori sono responsabili dei dati inseriti nei sistemi sotto la loro supervisione. Questi dati devono essere revisionati e firmati. La firma dello sperimentatore principale e di un membro autorizzato del suo staff rappresenta la conferma documentata che i dati rispettano i requisiti ALCOA.
  • Dati copiati:
    I dati possono essere copiati o trascritti per diversi scopi. Se un dato viene sostituito in modo irreversibile da una copia, questa deve essere certificata (ICH-GCP 1.63).
  • Copie certificate:
    Quando si crea una copia certificata, è necessario considerare la natura del documento originale. Il processo di copia deve basarsi su un processo convalidato.
  • Hosting e controllo dei dati:
    Tutti i dati generati durante uno studio clinico relativi ai partecipanti devono essere disponibili per lo sperimentatore durante e dopo lo studio. Lo sponsor non deve avere il controllo esclusivo dei dati inseriti in un sistema computerizzato.
  • Cloud:
    In caso di utilizzo di una soluzione cloud, lo sponsor (ICH-GCP 5.2.1) e/o lo sperimentatore (ICH-GCP 4.2.6) dovrebbero garantire che la parte contraente che fornisce il cloud sia qualificata (vedere Allegato 4). La giurisdizione dei dati può essere complessa data la natura delle soluzioni e dei servizi cloud condivisi su diversi siti, Paesi e continenti; tuttavia, eventuali incertezze dovrebbero essere affrontate e risolte mediante obblighi contrattuali prima dell’uso di una soluzione cloud.
    Se il responsabile sceglie di eseguire da sè la qualifica del sistema informatizzato, il cloud provider dovrebbe mettere a disposizione un ambiente di test identico all’ambiente di produzione.
  • Back-up:
    È necessario eseguire regolarmente il backup dei dati e delle configurazioni. Si raccomanda l’uso di server replicati. I backup devono essere archiviati in posizioni fisiche e reti logiche separate e non dietro lo stesso firewall dei dati originali per evitare la distruzione o l’alterazione simultanea. La frequenza dei backup e la loro conservazione devono essere determinati con un approccio basato sul rischio.
  • Migrazione dei dati:
    Dovrebbe essere garantito che la migrazione non influisca negativamente sui dati e sui metadati esistenti. Dopo la migrazione dovrebbe essere eseguita una verifica sui dati chiave.
  • Archiviazione:
    Lo sperimentatore e lo sponsor devono essere a conoscenza dei periodi di conservazione richiesti per i dati e i documenti relativi agli studi clinici. I periodi di conservazione devono rispettare il principio di protezione dei dati sulla limitazione della conservazione.
  • Decommissioning:
    Dopo la conclusione della sperimentazione, i database possono essere disattivati. Si raccomanda di decidere il momento della disattivazione prendendo in considerazione, ad esempio, se la sperimentazione clinica sarà utilizzata o meno nei termini di una domanda di autorizzazione all’immissione in commercio nel prossimo futuro, nel qual caso si potrebbe raccomandare di conservare i database. Una copia datata e autenticata dei database e dei dati deve essere archiviata e disponibile su richiesta. In caso di disattivazione, lo sponsor deve garantire la possibilità di ripristinare i database.

Annex

La bozza della nuova linea guida EMA si compone anche di 5 Annex che trattano nello specifico:

  1. Contratti
  2. Convalida dei sistemi computerizzati
  3. Gestione utenti
  4. Sicurezza
  5. Requisiti legati a specifici tipi di sistemi, processi e dati.

Fonte

Guideline on computerised systems and electronic data in clinical trials, draft,10 giugno 2021

Sistemi computerizzati in ambito GCP

Sconto del 15% per iscrizioni anticipate (entro 30 giorni dalla data dell’evento)
Sconto del 20% dal secondo iscritto della medesima azienda

A chi si rivolge

Il webinar si rivolge al personale di QA degli sponsor ed in particolare di chi si occupa degli audit, ma più in
generale a chi gestisce gli studi clinici, anche all’interno delle CRO.

Programma

Quality Systems propone un webinar di approfondimento sul tema “Sistemi informatici in ambito GCP”.
I relatori, consulenti del settore, illustreranno i requisiti regolatori e le aspettative delle Autorità sulla convalida dei sistemi informatici utilizzati per gli studi clinici, anche alla luce del crescente impiego di Software in cloud.

Saranno trattati in dettaglio i criteri di base della convalida dei sistemi informatici nell’ambito della ricerca clinica
e ci saranno momenti di confronto e dibattito durante i quali i relatori risponderanno alle domande dei partecipanti.
Non verrà tralasciato l’approfondimento normativo, e sarà presa in esame anche la nuova draft EMA Guideline on computerised systems and electronic data in clinical trials.

Si ricorda che le iscrizioni chiudono 7 giorni lavorativi prima dell’evento

Principali argomenti in agenda

  • Definizioni e Data Integrity per GCP
  • Requisiti regolatori
    • La nuova draft EMA Guideline on computerised systems and electronic data in clinical trials
  • Convalida degli Electronic Data Systems
    • Software Life Cycle
    • Platform Life Cycle
    • Study Life Cycle
  • Convalida e outsourcing

POLICY DI CANCELLAZIONE
Non è possibile annullare gratuitamente la propria iscrizione dopo il ricevimento della email di CONFERMA dell’evento. Trascorso tale termine, sarà addebitata l’intera quota di iscrizione.
L’eventuale disdetta di partecipazione dovrà essere comunicata in forma scritta.
In qualsiasi momento sarà possibile sostituire il nominativo dell’iscritto con altro nominativo purchè questo venga comunicato via posta elettronica almeno 1 giorno prima della data dell’evento.

Approvare documenti GxP da remoto è possibile con qualche accorgimento

A causa della pandemia di COVID-19, molte aziende hanno incentivato il lavoro da remoto. Tuttavia i maggiori problemi che si riscontrano sono quelli relativi alla firma e all’approvazione della documentazione GxP.

MHRA ha quindi pubblicato una linea guida che prende in considerazione cosa fare per approvare i documenti anche in smart working.

L’agenzia suggerisce alle aziende che dispongono già di sistemi elettronici convalidati che supportano le firme elettroniche in remoto di continuare ad utilizzarli per l’approvazione documentale.

Nonostante possano essere condivisi con chi lavora da remoto, spesso per i documenti tradizionalmente stampati su carta – quali protocolli di convalida, risk assessment, technical report, SOP o richieste di change – mancano sistemi formali che descrivano il processo di revisione e approvazione fuori dal sito.

Principi per approvare i documenti da remoto

La soluzione a questo problema dipende dalle aziende, dal tipo di documenti, dagli strumenti disponibili (stampanti, scanner, software) e dalle persone che devono approvare i documenti.

Indipendentemente dal sistema o dal processo utilizzato, è necessario che:

  • I controlli siano proporzionati al rischio e considerino il tipo di documento e i metodi usati per distribuirlo e approvarlo.
  • La firma da remoto sia equivalente alla firma manoscritta del firmatario.
  • Il metodo per la distribuzione e l’approvazione dei documenti minimizzi il rischio di errore dovuto a fraintendimenti su cosa vada rivisto/approvato.

Ad esempio:

  • il documento firmato deve riportare il nome e il numero del documento/la versione in modo che sia chiaro qual è il documento approvato;
  • se la persona non ha a disposizione uno scanner, la scansione può essere sostituita da una fotografia a patto che il documento sia chiaramente leggibile;
  • non è accettabile incollare l’immagine della firma su un documento perchè si perdono l’attribuibilità e la compliance ai requisiti GxP; bisogna invece che il documento sia stampato, firmato e scansionato;
  • approvare un documento/processo per email è appropriato solo per processi a basso rischio (ad esempio l’approvazione della revisione di una SOP) ma non per firme su documenti che impattano la qualità del prodotto;
  • in caso di documenti in cartelle condivise è necessario che ci siano controlli per evitare modifiche ai documenti e garantire la disponibilità dell’ultima versione di un file.

Approvare i documenti da remoto: i rischi

Nella valutazione dei rischi legati all’approvazione di documenti GxP da remoto, bisogna considerare:

  • l’attribuibilità della firma ad un individuo
  • i requisiti legislativi e le linee guida GxP sulla firma
  • la criticità della firma (ad esempio la firma della QP per il rilascio di un lotto è più critica della firma per l’approvazione di un piano di training)
  • la sicurezza della firma elettronica
  • la registrazione dell’azione di firma in modo che il documento non possa essere alterato senza invalidare la firma stessa
  • la disponibilità di tutti i dati associati alla firma.

Fonti

Potrebbe interessarti anche:

videocorso

Audit Trail review per sistemi computerizzati dei laboratori analitici

Sconto del 15% per iscrizioni anticipate
(entro 30 giorni dalla data dell’evento)
Sconto del 20% dal secondo iscritto della medesima azienda

A chi si rivolge

Il seminario è dedicato ai responsabili e al personale del Lab QC, ai QA coinvolti nella review dei dati di laboratorio o negli audit di data integrity e agli auditor responsabili di auto-ispezioni e audit presso i fornitori. 

Programma

L’Annex 11 delle EU GMP sui sistemi computerizzati richiede esplicitamente la review periodica dell’audit trail. 

Anche le linee guida MHRA, WHO, FDA, EMA e PIC/S sul data integrity sottolineano la necessità di eseguire la review dell’audit trail, ma senza dettagliare come farla, lasciando a ciascun laboratorio l’interpretazione e l’implementazione: serve una funzione di Audit Trail per tutti i software? chi deve eseguirla? con quale frequenza? 

Questa situazione è ulteriormente complicata dal fatto che molte applicazioni software sono state progettate prima che la data integrity diventasse di interesse per le Autorità. 

Questo corso è sviluppato per aiutare le aziende farmaceutiche e di API a comprendere come gestire la review dell’Audit Trail e come effettuarla utilizzando un approccio risk based. 

Si ricorda che le iscrizioni chiudono 7 giorni lavorativi prima dell’evento

Obiettivi

  • Comprendere i requisiti regolatori per la review dell’Audit Trail dei sistemi computerizzati di laboratorio.
  • Identificare le responsabilità e le modalità per l’esecuzione della review.
  • Identificare probabili problemi di data integrity grazie all’analisi di esempi di Audit Trail.

Principali argomenti in agenda

  • Requisiti regolatori: EU, FDA, MHRA, WHO e PIC/S 
  • Audit Trail durante le ispezioni: quali sono le aspettative dell’Autorità? 
  • Tipologie e Life cycle dei dati nel Laboratorio 
  • Convalida delle funzioni di Audit Trail 
  • Audit Trail review 

POLICY DI CANCELLAZIONE
Non è possibile annullare gratuitamente la propria iscrizione dopo il ricevimento della email di CONFERMA dell’evento. Trascorso tale termine, sarà addebitata l’intera quota di iscrizione.
L’eventuale disdetta di partecipazione dovrà essere comunicata in forma scritta.
In qualsiasi momento sarà possibile sostituire il nominativo dell’iscritto con altro nominativo purchè questo venga comunicato via posta elettronica almeno 1 giorno prima della data dell’evento.

audit

Corso per Auditor/Lead Auditor di Sistemi di Gestione per la Qualità ISO 9001 e EU-GMP, MODULO 2

Corso qualificato AICQ-SICEV

A chi si rivolge

Il corso è dedicato a tutti coloro che intendono intraprendere l’attività di auditor, sia in ambito di certificazione (parte terza) sia in contesti aziendali (auditor interni) o presso i fornitori della propria organizzazione. Risulterà utile a tutti coloro che sono coinvolti nella realizzazione di Sistemi di Qualità o migliorare la gestione dei sistemi già esistenti.

Il corso completo (MOD1 e MOD2-GMP) permette di soddisfare i requisiti di formazione richiesti da AICQ-SICEV per l’ammissione agli esami di Valutatore dei Sistemi di Gestione per la Qualità ISO con qualifica GMP 

Prerequisiti per la partecipazione:

  • Conoscenza di base dei requisiti ISO 9001:2015, ISO 19011:2018, ISO 17021:2015
  • Conoscenza di base delle EU GMP parte I e II
  • L’accesso al MOD2 è possibile anche a tutti coloro che già possiedono un riconoscimento di Auditor di Sistema di Gestione della Qualità ISO.

ATTENZIONE
La frequenza ai due moduli è obbligatoria nel caso si voglia accedere al percorso di certificazione di AUDITOR presso AICQ-SICEV ma resta indipendente nel caso non si voglia percorrere tale strada.
Il numero di partecipanti è limitato a 20, le iscrizioni saranno accettate in ordine di ricevimento.

Programma

Il corso ha l’obbiettivo di formare i partecipanti al ruolo di Auditor/Lead Auditor dei sistemi di gestione della Qualità secondo le ISO 9001 e le GMP del settore farmaceutico (per produzione principi attivi e prodotto finito), garantendo una formazione teorica e pratica sulla conduzione di audit in ambito farmaceutico.

Il corso completo ha una durata di 4 giorni per un totale di 32h complessive e consentirà di acquisire gli elementi e gli strumenti di base necessari per gli auditor di sistemi di gestione della qualità.
Il percorso è MODULARE per consentire a coloro che già possiedono una certificazione di Auditor  ISO di poter accedere alla sola parte di “approfondimento” relativa alle GMP (Modulo 2-GMP).

La partecipazione allo specifico MODULO 2-GMP sarà utile per comprendere e rinforzare i comportamenti idonei per condurre un efficace Audit ISO-GMP nelle diverse aree aziendali.

IL MODULO 1 NON E’ PROPEDEUTICO ALLA PARTECIPAZIONE AL MODULO 2

AGENDA_ MODULO 2 – GMP

Giorno 1

  • Rapido richiamo ai concetti esposti nel MOD1
  • Condurre un Audit GMP al Magazzino di Materie Prime e Prodotti finiti
  • Esercitazione 1: check list per audit in magazzino
  • Condurre un Audit GMP in Produzione di prodotti finiti
  • Condurre un Audit GMP al Confezionamento farmaceutico
  • Verifica dei documenti GMP di produzione
  • Condurre un Audit GMP in Produzione API
  • Esercitazione 2: check list per audit in produzione

Giorno 2

  • Condurre un Audit GMP al laboratorio Controllo Qualità
  • Esercitazione 1: role paly – a spasso nel Laboratorio CQ
  • Condurre un Audit GMP a un impianto dell’acqua (Purified Water e Water for Injection)
  • Esercitazione 2: check list per impianto acqua
  • Condurre un Audit GMP ai sistemi computerizzati
  • condurre un Audit GMP alla Quality Assurance
  • Esercitazione 3: conduzione di una riunione di chiusura (Role Play)
  • Test finale di valutazione delle conoscenze acquisite: 1 test di valutazione di circa 10 scenari per la classificazione delle NC + 10 punti GMP da individuare 
  • Cleaning Validation
  • Discussione e verifica del test finale