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

Validation Specialist Academy: revisione documentale

L’intero percorso Validation Specialist Academy è pensato in 5 incontri.
È tuttavia possibile iscriversi singolarmente ad uno o più eventi.
Il costo dell’iscrizione si riferisce ad un evento singolo.

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 corso è indirizzato a quelle funzioni aziendali che desiderano approfondire argomenti legati alla Computer System Validation.​

La partecipazione è riservata a coloro che si occupano di CSV da almeno due anni e che abbiano una conoscenza consolidata degli argomenti base e delle predicate rules dei sistemi computerizzati.

Programma

Gli incontri di programma hanno come obiettivo la formazione di Validation Specialists con competenze tecniche approfondite sulla CSV che, al termine del ciclo di lezioni, saranno in grado di gestire in autonomia la convalida dei sistemi computerizzati in uso in azienda. ​

Ogni incontro è strutturato come un momento di approfondimento e confronto con gli altri partecipanti, grazie alla guida del docente-moderatore. ​

Non si tratta quindi di lezioni frontali ma di momenti in cui scambiare esperienze, chiarire dubbi e approfondire alcuni argomenti chiave legati alla convalida dei sistemi computerizzati. ​

Durante gli incontri verranno effettuate anche esercitazioni pratiche sugli argomenti trattati.

Principali argomenti in agenda

  • 23.09.22: Risk Assessment
    • Come approcciare l’analisi dei rischi di alto livello di un sistema al fine di determinare la strategia di test​
  • 28.10.22: Gestione dei fornitori
    • Come effettuare e documentare l’assessment / audit dei fornitori di sistemi e servizi IT
    • Cos’è lo SLA e quando serve​
  • 25.11.22: Change Management​
    • La gestione dei cambiamenti ai sistemi computerizzati:
      • il processo;
      • le responsabilità;
      • casi particolari;
      • esempi pratici di modifiche e definizione della strategia di convalida;
      • change control vs configuration management​.
  • 13.01.23: Approfondimento sui requisiti regolatori​
  • 10.02.23: Revisione documentale
    • Come revisionare la documentazione:
    • documentazione del fornitore;
    • documentazione di convalida;
    • SOP relative ai processi di mantenimento dei sistemi.

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


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.

Immagine in evidenza: Infografica vettore creata da vectorjuice – it.freepik.com

Validation Specialist Academy: approfondimento sui requisiti regolatori

L’intero percorso Validation Specialist Academy è pensato in 5 incontri.
È tuttavia possibile iscriversi singolarmente ad uno o più eventi.
Il costo dell’iscrizione si riferisce ad un evento singolo.

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 corso è indirizzato a quelle funzioni aziendali che desiderano approfondire argomenti legati alla Computer System Validation.​

La partecipazione è riservata a coloro che si occupano di CSV da almeno due anni e che abbiano una conoscenza consolidata degli argomenti base e delle predicate rules dei sistemi computerizzati.

Programma

Gli incontri di programma hanno come obiettivo la formazione di Validation Specialists con competenze tecniche approfondite sulla CSV che, al termine del ciclo di lezioni, saranno in grado di gestire in autonomia la convalida dei sistemi computerizzati in uso in azienda. ​

Ogni incontro è strutturato come un momento di approfondimento e confronto con gli altri partecipanti, grazie alla guida del docente-moderatore. ​

Non si tratta quindi di lezioni frontali ma di momenti in cui scambiare esperienze, chiarire dubbi e approfondire alcuni argomenti chiave legati alla convalida dei sistemi computerizzati. ​

Durante gli incontri verranno effettuate anche esercitazioni pratiche sugli argomenti trattati.

Principali argomenti in agenda

  • 23.09.22: Risk Assessment
    • Come approcciare l’analisi dei rischi di alto livello di un sistema al fine di determinare la strategia di test​
  • 28.10.22: Gestione dei fornitori
    • Come effettuare e documentare l’assessment / audit dei fornitori di sistemi e servizi IT
    • Cos’è lo SLA e quando serve​
  • 25.11.22: Change Management​
    • La gestione dei cambiamenti ai sistemi computerizzati:
      • il processo;
      • le responsabilità;
      • casi particolari;
      • esempi pratici di modifiche e definizione della strategia di convalida;
      • change control vs configuration management​.
  • 13.01.23: Approfondimento sui requisiti regolatori​
  • 10.02.23: Revisione documentale​
    • Come revisionare la documentazione del fornitore, di convalida e le SOP relative ai processi di mantenimento dei sistemi ​

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


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.

Immagine in evidenza: Infografica vettore creata da vectorjuice – it.freepik.com

Validation Specialist Academy: gestione fornitori

L’intero percorso Validation Specialist Academy è pensato in 5 incontri.
È tuttavia possibile iscriversi singolarmente ad uno o più eventi.
Il costo dell’iscrizione si riferisce ad un evento singolo.

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 corso è indirizzato a quelle funzioni aziendali che desiderano approfondire argomenti legati alla Computer System Validation.​

La partecipazione è riservata a coloro che si occupano di CSV da almeno due anni e che abbiano una conoscenza consolidata degli argomenti base e delle predicate rules dei sistemi computerizzati.

Programma

Gli incontri di programma hanno come obiettivo la formazione di Validation Specialists con competenze tecniche approfondite sulla CSV che, al termine del ciclo di lezioni, saranno in grado di gestire in autonomia la convalida dei sistemi computerizzati in uso in azienda. ​

Ogni incontro è strutturato come un momento di approfondimento e confronto con gli altri partecipanti, grazie alla guida del docente-moderatore. ​

Non si tratta quindi di lezioni frontali ma di momenti in cui scambiare esperienze, chiarire dubbi e approfondire alcuni argomenti chiave legati alla convalida dei sistemi computerizzati. ​

Durante gli incontri verranno effettuate anche esercitazioni pratiche sugli argomenti trattati.

Principali argomenti in agenda

  • 23.09.22: Risk Assessment
    • Come approcciare l’analisi dei rischi di alto livello di un sistema al fine di determinare la strategia di test​
  • 28.10.22: Gestione dei fornitori
    • Come effettuare e documentare l’assessment / audit dei fornitori di sistemi e servizi IT
    • Cos’è lo SLA e quando serve​
  • 25.11.22: Change Management​
    • La gestione dei cambiamenti ai sistemi computerizzati:
    • il processo;
    • le responsabilità;
    • casi particolari;
    • esempi pratici di modifiche e definizione della strategia di convalida;
    • change control vs configuration management​.
  • 13.01.23: Approfondimento sui requisiti regolatori​
  • 10.02.23: Revisione documentale​
    • Come revisionare la documentazione:documentazione del fornitore;
    • documentazione di convalida;
    • SOP relative ai processi di mantenimento dei sistemi.

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


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.

Immagine in evidenza: Infografica vettore creata da vectorjuice – it.freepik.com

Validation Specialist Academy: Risk Assessment

L’intero percorso Validation Specialist Academy è pensato in 5 incontri.
È tuttavia possibile iscriversi singolarmente ad uno o più eventi.
Il costo dell’iscrizione si riferisce ad un evento singolo.

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 corso è indirizzato a quelle funzioni aziendali che desiderano approfondire argomenti legati alla Computer System Validation.​

La partecipazione è riservata a coloro che si occupano di CSV da almeno due anni e che abbiano una conoscenza consolidata degli argomenti base e delle predicate rules dei sistemi computerizzati.

Programma

Gli incontri di programma hanno come obiettivo la formazione di Validation Specialists con competenze tecniche approfondite sulla CSV che, al termine del ciclo di lezioni, saranno in grado di gestire in autonomia la convalida dei sistemi computerizzati in uso in azienda. ​

Ogni incontro è strutturato come un momento di approfondimento e confronto con gli altri partecipanti, grazie alla guida del docente-moderatore. ​

Non si tratta quindi di lezioni frontali ma di momenti in cui scambiare esperienze, chiarire dubbi e approfondire alcuni argomenti chiave legati alla convalida dei sistemi computerizzati. ​

Durante gli incontri verranno effettuate anche esercitazioni pratiche sugli argomenti trattati.

Principali argomenti in agenda

  • 23.09.22: Risk Assessment​
    • Come approcciare l’analisi dei rischi di alto livello di un sistema al fine di determinare la strategia di test​
  • 28.10.22: Gestione dei fornitori
    • Come effettuare e documentare l’assessment / audit dei fornitori di sistemi e servizi IT
    • Cos’è lo SLA e quando serve​
  • 25.11.22: Change Management​
    • La gestione dei cambiamenti ai sistemi computerizzati:
      • il processo;
      • le responsabilità;
      • casi particolari;
      • esempi pratici di modifiche e definizione della strategia di convalida;
      • change control vs configuration management​.
  • 13.01.23: Approfondimento sui requisiti regolatori​
  • 10.02.23: Revisione documentale​
    • Come revisionare la documentazione:
      • documentazione del fornitore;
      • documentazione di convalida;
      • SOP relative ai processi di mantenimento dei sistemi.

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


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.

Immagine in evidenza: Infografica vettore creata da vectorjuice – it.freepik.com

Audit di Data Integrity: scopo, checklist e auditor

Introduzione

Ormai da diversi anni la compliance alla data integrity costituisce un focus di primaria importanza durante gli audit, siano questi di prima, seconda o terza parte.

In contesti e ruoli differenti, le aziende sono tenute a conoscerne gli aspetti fondamentali per assicurare e/o verificare che l’integrità dei dati ad impatto GMP sia mantenuta durante l’intero ciclo di vita degli stessi.

Assicurare la data integrity richiede un appropriato quality e risk management, inclusa l’aderenza a principi scientifici e alle good documentation practices – aspetti, tra gli altri, che devono essere sfidati in fase di audit.

Le buone pratiche di gestione dei dati si applicano a tutti gli elementi del Sistema di Qualità Farmaceutico e i corrispondenti principi si applicano, allo stesso modo, ai dati generati da sistemi elettronici e cartacei. E’ possibile affermare, pertanto, che in un audit di data integrity è coinvolta l’intera struttura qualitativa aziendale.


Vuoi approfondire l’argomento?
Ne parleremo nel webinar

Garantire la Data Integrity nel Laboratorio QC

Contesto normativo

Numerosi sono i riferimenti in ambito normativo internazionale che possono essere considerati nell’approccio alla data integrity:

  • WHO, Technical Report Series No. 996, Maggio 2016e Guideline on Data Integrity (DRAFT Giugno 2020)
  • EMA, Data integrity Q&A, Agosto 2016
  • FDA, Data integrity and compliance with drug CGMP Questions and Answers Guidance for industry, Dicembre 2018
  • MHRA, ‘GxP’ Data Integrity Guidance and Definitions, Marzo 2018
  • ISPE GAMP, Records and Data Integrity Guide, Marzo 2017; GPG Data Integrity – Key Concepts, Ottobre 2018; GPG Data Integrity – Manufacturing Records, Maggio 2019; GPG Data Integrity – Data Integrity by Design, Ottobre 2020

Nel contesto dell’audit di data integrity, il più recente riferimento è rappresentato dalla PIC/SGuidance, Good Practices for data management and integrity in regulated GMP/GDP environments, doc. PI 041-1” del 1° Luglio 2021.

La linea guida è stata scritta per le ispezioni di siti che svolgono attività di produzione (GMP) e distribuzione (GDP). I principi contenuti in questa guida sono applicabili a tutte le fasi del ciclo di vita del prodotto e possono essere utilizzati anche per audit di prima parte o come preparazione per audit di terza parte.

Audit di Data Integrity

Un audit di Data Integrity deve essere indirizzato alla verifica della compliance ai principi dell’ALCOA+, ma deve anche essere focalizzato sull’intera gestione del ciclo di vita del dato.

Come indicato dalla PIC/S, la gestione dei dati si riferisce a tutte quelle attività svolte durante il trattamento dei dati, inclusi, a titolo esemplificativo ma non esaustivo, la politica dei dati, la documentazione, la qualità e la sicurezza.

Le buone pratiche di gestione dei dati influenzano la qualità di tutti i dati generati e registrati da un produttore. Queste pratiche dovrebbero, naturalmente, garantire che i dati siano attribuibili, leggibili, contemporanei, originali, accurati, completi, coerenti, durevoli e disponibili; ma, i principi contenuti nelle PIC/S dovrebbero essere considerati anche nel più ampio contesto di un corretto sistema di Data Governance e quindi, in tutte quelle disposizioni che garantiscono lintegrità dei dati stessi.

Un audit di data integrity non sarà solo focalizzato sulla gestione tecnica del dato, ma riguarderà anche la disponibilità delle risorse, la cultura della trasparenza, il coinvolgimento del senior management, la formazione, il sistema procedurale, i processi di monitoraggio, etc. Unitamente a questo non dovranno mancare punti di attenzione sui sistemi computerizzati e sulla documentazione cartacea.

Operativamente, l’auditor potrà seguire un approccio a flussi, ad esempio verificando il flusso completo dei dati relativi ad un’analisi o ad un processo produttivo., Oppure potrà utilizzare un approccio che identifichi e valuti dal punto di vista dell’integrità i CQA (Critical Quality Attribute) e i CPP (Critical Process Parameter) dei processi.

Check list

Ai fini della esecuzione o della preparazione per un audit di data integrity, potrebbe essere utile la preparazione di check lists indicative dei principali punti da sfidare. Le check lists possono essere preparate come documenti esaustivi, considerando tutti i requisiti indicati nei criteri di riferimento adottati, o possono essere personalizzate di volta in volta, in accordo ad approcci risk based stabiliti sulla base delle criticità riscontrate.

Nel caso di audit di prima o seconda parte, personalizzare le check lists sulla base del know how aziendale e delle criticità emerse durante la fase di raccolta informazioni preliminare, è da considerarsi un utile punto di partenza.

Gli audit e, conseguentemente, le check lists possono essere suddivise in macro argomenti, a titolo esemplificativo:

  • verifica della governance
  • verifica della gestione dei sistemi computerizzati
  • verifica della gestione di dati elettronici
  • verifica della gestione delle true copies
  • verifica della gestione dei dati cartacei
  • verifica della gestione dei sistemi ibridi

Ciascun marco argomento, suddiviso in dettagli, può rappresentare una guida per l’auditor. Sotto sono riportati stralci esemplificativi di check lists:

Governance
DomandaEsitoNoteRif. linee guida PIC/S 041-1 2021
Esiste una Governance o Policy per la gestione dell’integrità dei dati?5.2.3
È stato eseguito un Risk Assessment per verificare la conformità dei sistemi, in particolare strumentazione di laboratorio e equipment di processo, verso i requisiti di Data Integrity?5.3.4
Durante le Self Inspection vengono osservati aspetti di Data Integrity?5.2.3
Convalida sistemi computerizzati
DomandaEsitoNoteRif. linee guida PIC/S 041-1 2021
I software ad impatto GxP sono stati convalidati verso le normative rilevanti (Annex 11, 21CFR part 11, ecc.)?9.3 (expectation 1)
I SW sono mantenuti in stato di convalida (SOP di mantenimento e periodic review)?9.3 (expectation 5)
Le interfacce tra sistemi (e.g. PLC macchina, software gestionali, strumenti di laboratorio) sono convalidate?9.4 (expectation 1)
Data Integrity: DATI ELETTRONICI
DomandaEsitoNoteRif. linee guida PIC/S 041-1 2021
Il ruolo di amministratore del sistema è assegnato a enti aziendali che non sono direttamente coinvolti nella gestione dei dati critici, in accordo al principio della segregation of duties?9.5 (expectation 1)
L’accesso ai sistemi informatici è consentito mediante username e password personali?9.5 (expectation 1)
Il sistema consente la modifica della password da parte dell’utente?9.5 (expectation 1)
Data Integrity: AUDIT TRAIL
DomandaEsitoNoteRif. linee guida PIC/S 041-1 2021
La funzionalità dell’audit trail è convalidata?9.6 (expectation 1)
L’audit trail è periodicamente rivisto?9.8 (expectation 2)
Data Integrity: DATI CARTACEI
DomandaEsitoNoteRif. linee guida PIC/S 041-1 2021
Esiste una procedura che regoli la generazione dei documenti Master (e.g. Master Batch Record, versione Master di una SOP, Metodo, ecc.)?
I master sono identificati con codice univoco, versione, riferimento a SOP.
8.1.3
Esiste una procedura che regoli la generazione di documenti a partire dai documenti Master che assicuri l’integrità di questi ultimi?8.1.3
Le procedure cartacee sono generate in maniera tale che sia assicurata la loro riconciliazione (distribuzione controllata)?8.1.3

L’auditor

Indipendentemente dall’utilizzo della check list, il lead auditor selezionato deve essere competente nelle norme che si applicano, nelle tecniche di verifica ispettiva, nella conduzione di un gruppo d’ispezione; deve essere stato preventivamente qualificato e la sua qualifica deve essere stata mantenuta nel tempo.

L’auditor deve inoltre assicurare imparzialità, eticità, segretezza, oltre che possedere caratteristiche personali tali che gli permettano di eseguire l’attività con completezza e professionalità, nel rispetto delle caratteristiche specifiche del compito da svolgere.

In conclusione

Concludendo, un audit di data integrity necessita di un’attenta analisi di tutte le attività effettuate per la gestione dei dati, dall’organizzazione aziendale al sistema di qualità. L’attività deve essere svolta da personale competente e tecnicamente preparato, in modo tale che le evidenze siano raccolte secondo approccio risk based e che siano significative delle conclusioni dell’audit stesso.

Il contributo di Quality Systems

Possiamo darti una mano con attività di consulenza o di supporto alla preparazione delle procedure, e possiamo prenderci prenderci cura della tua formazione GxP, sia con un ricco calendario di eventi che con la possibilità di organizzare attività in-house.

Articolo a cura di Marta Carboniero, GxP Expert di Quality Systems

Warning Letter: gestione inadeguata dei record di produzione

Una corretta gestione dei record di produzione non è solo un requisito normativo, ma rappresenta anche un segnale del buon funzionamento e dell’efficacia delle funzioni di qualità all’interno di un’azienda.
L’adesione a pratiche documentali adeguate e la conformità al requisito di data integrity hanno importanza critica, come attesta una Warning Letter FDA inviata ad un produttore di API.

La Warning Letter

Gli ispettori hanno criticato l’azienda per il ruolo giocato dal suo reparto qualità. Hanno infatti individuato inadeguatezze nell’esercizio di funzioni di Quality Control e Quality Assurance, ed hanno attribuito tali inadeguatezze ad una mancata indipendenza dell’area qualità dal reparto di Produzione.

Le non conformità rilevate infatti, oltre a rappresentare delle criticità, rivelavano agli occhi degli ispettori una mancanza di autorità da parte della Quality Unit.
Ciò ha avuto come conseguenza l’impossibilità di operare in maniera affidabile e di garantire il rispetto delle buone pratiche documentali.

Il contesto normativo

All’interno della stessa lettera, FDA indica come riferimento normativo la propria linea guida: Data Integrity and Compliance with Drug CGMP.
Nel documento, viene precisato il valore «critico» del requisito di data integrity:

«La data integrity è critica attraverso tutto il ciclo di vita dei dati cGMP, incluso durante la creazione, modifica, processing, manutenzione, archivio, recupero, trasmissione e dismissione dopo la fine del periodo di ritenzione del record.»

FDA Data Integrity and Compliance With Drug CGMP Guidance for Industry, III a) “What is data integrity?”

La linea guida chiarisce inoltre le responsabilità della Quality Unit rispetto ai record GMP critici:

«I dati creati come parte di un record cGMP devono essere valutati dalla Quality Unity come parte dei criteri di rilascio (vedi 21 CFR §§ 211.22 e 212.70) e mantenuti a scopo cGMP (e.g. 21 CFR §211.180).»

FDA op. cit., §2

Le non conformità più rilevanti

Tra le principali criticità rilevate:

  • Un diario di Batch Manufacturing del reparto Produzione è stato trovato con alcune pagine strappate via;
  • Nel laboratorio R&D non ufficiale sono stati trovati diversi batch record già firmati, parzialmente compilati e privi della dicitura “Copia Controllata“;
  • Il batch record relativo a un lotto di API in distribuzione negli Stati Uniti era stato distrutto, come il relativo campione di ritenzione. FDA ha presupposto che le procedure per la conservazione degli API non erano state seguite o non esistevano del tutto.

Le misure richieste in risposta alla Warning Letter

L’Autorità americana ha richiesto diverse misure in risposta alla Warning Letter.

  • Per prima cosa, FDA ha richiesto una valutazione ed un piano di rimedio per assicurare l’effettivo funzionamento della Quality Unit. Tale valutazione deve includere alcuni punti cardine:
    • valutazione di solidità e appropriatezza delle procedure usate dall’azienda;
    • supervisione di tutte le attività operative da parte della QU;
    • review completa d’ogni lotto prima delle decisioni della QU a riguardo;
    • supervisione ed approvazione delle investigazioni e adempimento di tutti gli altri doveri della QU per assicurare efficacia, qualità e purezza di tutti i prodotti.
  • L’Autorità ha chiesto inoltre di verificare come l’Alta Direzione supporti la Quality Assurance. In particolar modo ha richiesto di verificare se essa fornisce risorse adeguate per affrontare tempestivamente i problemi via via emersi.
  • Infine, FDA ha richiesto una valutazione completa dei sistemi di documentazione usati nei reparti di Produzione e Laboratorio, in modo da determinare dove la documentazione sia insufficiente. Questa valutazione deve includere un piano CAPA per correggere le pratiche di documentazione dell’azienda ed assicurare che tutti i record possiedano le caratteristiche ALCOA.

Vuoi approfondire il tema?

Cerchi un’introduzione alla tematica della data integrity? Scopri di più seguendo le linee guida emesse sull’argomento.
Ne parliamo nel webinar:

Data Integrity secondo le nuove linee guida 2021

Qual è la documentazione da verificare durante un audit?
Quali sono le metodologie impiegate per una verifica efficace?
Ne parliamo nel webinar:

La verifica documentale in un audit


Fonte:

Gap di data integrity in laboratorio: la Warning Letter FDA

Evitare dei gap di data integrity può avere un impatto immediato sulle attività produttive e di laboratorio, come mostra un peculiare episodio documentato in una Warning Letter di FDA.
In questo caso, un’ispezione rilevò una gestione inadeguata di esiti OOS di test di laboratorio. Ulteriori indagini misero in luce come dei grossi gap di data integrity avessero influito sulle attività di testing.

La punta dell’iceberg: i risultati OOS

L’azienda protagonista di questa Warning Letter ottenne risultati OOS dopo i test su un lotto del proprio prodotto.
Procedette quindi ad un re-testing dello stesso campione, ottenendo di nuovo risultanti insoddisfacenti.

Seguendo le procedure stabilite dal proprio cliente, l’azienda preparò dei nuovi campioni dal medesimo lotto ed eseguì nuovamente dei test. Questa volta l’esito fu considerato adeguato.
L’azienda considerò quindi risolto il problema e chiuse la procedura investigativa senza identificare una root cause.
FDA rilevò questo fatto e lo notificò come osservazione, sollecitando una risposta da parte dell’azienda.

L’azienda rispose con report investigativi aggiornati che attribuivano i risultati OOS a “noti errori di laboratorio, come inadeguate preparazioni dei campioni“.
Ciò non bastò a soddisfare le aspettative di FDA, la quale sottolineò che questa valutazione era “contradittoria rispetto alle conclusioni della [..] investigazione iniziale“.
Di conseguenza, FDA richiese prove scientifiche a supporto di questa nuova conclusione – prove che l’azienda non aveva saputo fornire.

Gap di data integrity?

L’investigazione portò tuttavia a galla un altro problema: nel periodo di tempo esaminato era stato annotato nel logbook un ciclo operativo che non era usato nella preparazione del lotto in questione.
FDA annotò questa discrepanza come intenzionale, con ciò implicando che non era possibile pensare ad un inserimento di dati accidentale a meno che si supponessero delle violazioni dei requisiti di data integrity.

Nella risposta alle osservazioni dell’Autorità, l’azienda affermò di aver aperto una deviazione per revisionare i record generati durante quel periodo.
Questa reazione fu comunque considerata inadeguata: FDA attendeva infatti una valutazione comprensiva che descrivesse con precisione la portata di questo gap di data integrity.

Il complesso di cause

Tutto ciò fece sì che l’attenzione dell’Autorità si concentrasse sulla compliance con i requisiti di data integrity, facendo così emergere altre non-conformità.

Innanzitutto, l’azienda non disponeva di un sistema di sicurezza e di controllo degli accessi adeguato.
I singoli utenti non avevano account unici e non avevano privilegi di accesso loro assegnati, né per determinati software né per il sistema operativo Windows.
Gli esecutori delle analisi avevano perfino la possibilità di cancellare o sovrascrivere i dati – e gli ispettori trovarono effettivamente diversi oggetti cancellati (tra file e cartelle) nel cestino del sistema.

Inoltre, i fogli di calcolo usati per calcolare i saggi, le impurezze, l’uniformità del contenuto e gli esiti dei test di dissoluzione non erano uniformati ad uno standard e non erano convalidati.

L’azienda si giustificò dichiarando che stava pianificando un upgrade dell’intero sistema. Affermò anche che, in ogni caso, i file cancellati erano working copies e che gli originali erano tuttora conservati nel database.

FDA ritenne inadeguata la risposta dell’azienda, richiedendo un piano di CAPA che introducesse immediatamente dei controlli ad interim per prevenire la modifica o la cancellazione di dati.
Richiese inoltre una review retrospettiva che stabilisse l’impatto potenziale del problema rilevato, in modo da assicurare il mantenimento della data integrity.

Il Remedial Plan – indagine sui gap di data integrity

In risposta alla Warning Letter FDA chiese diverse misure, tra cui un’indagine della portata di tutte le inaccuratezze nei record e nel report di dati. L’indagine avrebbe dovuto includere:

  • protocolli e metodologie d’indagine dettagliati, un riassunto di tutti i sistemi interessati dalla valutazione e giustificazioni esplicite per ogni parte dell’operazione esclusa da quest’indagine;
  • colloqui con i dipendenti, sia attuali sia precedenti, per identificare la natura, le dimensioni e la root cause delle inaccuratezze nei dati. FDA non richiese che tali colloqui fossero condotti da una terza parte indipendente, ma lo consigliò caldamente;
  • una valutazione della portata dei difetti di data integrity in tutto lo stabilimento. Tale valutazione avrebbe inoltre dovuto descrivere in dettaglio tutte le aree operative in cui fossero stati trovati dei gap di data integrity;
  • una valutazione retrospettiva della natura dei difetti di integrity dei dati relativi ai test.
    Anche in questo caso FDA consigliò vivamente di far condurre la valutazione ad una terza parte indipendente con specifiche competenze nelle aree interessate dai problemi di data integrity.

Il Remedial Plan – le altre richieste

L’Autorità richiese anche altre misure in risposta alla propria Warning Letter per valutare gli effetti dei problemi rilevati e per evitare che si ripetessero in futuro. In particolare richiese:

  • un risk assessment degli effetti potenziali di tutti i difetti rilevati sulla qualità dei farmaci testati, inclusi i rischi potenziali per la salute dei pazienti;
  • una strategia di management dell’azienda che descrivesse tutto il piano CAPA adottato.
    Tale piano avrebbe dovuto includere non solo le misure necessarie per assicurare in futuro la completezza e l’affidabilità dei dati, ma anche:
    • le misure ad interim prese per assicurare la qualità del farmaco, inclusi test addizionali, notifiche ai clienti ed eventuali richiami del prodotto;
    • una descrizione delle root causes dei gap di data integrity. Le cause individuate avrebbero dovuto essere compatibili con gli esiti del risk assessment.
      A tal scopo, l’azienda avrebbe anche dovuto indicare esplicitamente se gli individui responsabili dei gap di data integrity fossero ancora nella posizione di poter influenzare o alterare dati cGMP rilevanti.

Soluzioni contro i gap di data integrity

L’episodio qui citato illustra molto bene le conseguenze, effettive e potenziali, di una gestione inadeguata di dati GMP critici nelle attività di laboratorio.
Allo stesso tempo, la compliance con i requisiti di data integrity richiede un notevole – seppur necessario – sforzo.
Non sorprende quindi che molte aziende ricorrano a sistemi per automatizzare e digitalizzare la gestione dei dati di laboratorio.

Tra le varie soluzioni disponibili sul mercato, una da segnalare per la sua semplicità d’uso e installazione è Ioi – Integration of instruments.
Ioi incarna un approccio agile alla transizione digitale, consentendo di integrare in un unica piattaforma strumenti di qualsiasi tipo o marca (inclusi legacy instruments) ed eventualmente di comunicare con sistemi di terze parti (come MES, EBR, LIMS, ELN…).
Qui è possibile vedere una video demo del software.


Fonte:


Immagine di copertina: Dati vettore creata da stories – it.freepik.com

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

PIC/S pubblica il documento finale sulla Data Integrity

Gli ispettori farmaceutici di oltre 50 Paesi aderiscono al PIC/S per lo sviluppo di linee guida GMP/GDP armonizzate che siano di aiuto durante le ispezioni. I documenti pubblicati dal gruppo sono aperti alla consultazione ed evidenziano potenziali problemi che i produttori farmaceutici potrebbero riscontrare durante le ispezioni.

La linea guida PI 041

PIC/S ha recentemente pubblicato la versione finale della tanto attesa linea guida PI 041-1 “Good Practices for Data Management and Data Integrity in regulated GMP/GDP Environments” sulla data integrity.
La seconda bozza del documento venne pubblicata nel 2016 e successivamente messa a disposizione per la discussione. Dopo la sessione di commenti, nel 2018 venne pubblicata la terza bozza e da allora si attendeva la pubblicazione della versione finale della linea guida.

Cosa è cambiato?

La struttura del documento, composta da 14 capitoli, non è cambiata:

             1. Storia del documento
             2. Introduzione
             3. Scopo
             4. Campo di applicazione
             5. Data governance system
             6. Influenze organizzative sulla corretta gestione dell’integrità dei dati
             7. Principi generali di data integrity
             8. Considerazioni specifiche sulla data integrity per i sistemi paper-based
             9. Considerazioni specifiche sulla data integrity per i sistemi computerizzati
            10. Considerazioni sulla data integrity per le attività in outsourcing
            11. Azioni regolatorie in risposta ai findings di data integrity
            12. Soluzione dei problemi di integrità dei dati
            13. Glossario
            14. Storia delle revisioni

Le modifiche apportate invece sono le seguenti:

  • I sottocapitoli sono stati leggermente rinominati o risistemati  
  • Il paragrafo 6.2 “Codice etico e politiche” è ora “Politiche relative ai valori organizzativi, alla qualità, alla condotta del personale e all’etica
  • Il paragrafo 8.10 “True copies” è stato integrato nel capitolo 7 così come il paragrafo 8.11 “Limitations of remote review of summary reports
  • Dal capitolo 9.2 sono stati rimossi i paragrafi 9.3 “Validation and Maintenance” e 9.4 “Data Transfer

Fonte

GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS