Audit trail review nel CDS: esempi, priorità e decisioni

Il report di audit trail non mostra anomalie, ma nel CDS esiste una sequenza interrotta che il report non include. Il problema non è soltanto leggere meglio le righe: è dimostrare che il perimetro della review comprende la storia pertinente. Una registrazione disponibile, una review eseguita e un’indagine conclusa sono tre evidenze diverse.

1. Partire dal dataset e distinguere le registrazioni

Definisci quale decisione sostiene la review e quali campioni, sequenze, iniezioni, metodi e risultati vi appartengono. Poi individua le registrazioni necessarie: acquisizione, elaborazione, configurazione e sicurezza possono essere distribuite in viste o archivi diversi. Un log di accesso non ricostruisce da solo le modifiche d’integrazione; il report dei risultati non documenta tutti gli eventi.

Per ogni evento rilevante collega identificativo dell’oggetto, utente, data e ora, azione, valori o versioni precedenti e successive e motivazione pertinente. Comprendi fuso orario e significato del timestamp; un’esportazione ordinata per data non garantisce da sola la corretta cronologia.

Le basi generali dell’audit trail sono trattate separatamente. Qui l’obiettivo è ricostruire il percorso di uno specifico dataset cromatografico, senza trasformare ogni evento di sistema in una presunta anomalia analitica.

2. Stabilire perimetro, responsabilità e frequenza

Identifica prima i requisiti applicabili alla revisione del record. La FDA, nella guidance 2018 Q7–8, collega la review delle modifiche al riesame del record e richiede di rispettare le frequenze previste dalle regole CGMP pertinenti. Dove la frequenza non è specificata, la valutazione del rischio considera criticità, controlli e impatto sul prodotto. Il rischio non autorizza a rinviare un controllo obbligatorio.

Assegna revisori formati sul metodo e sul CDS, con accesso sufficiente alle evidenze e indipendenza pertinente rispetto a chi ha generato o modificato i dati. La review non deve necessariamente essere svolta tutta da QA: definisci attività del reparto e supervisione dell’unità qualità secondo il sistema qualità e i requisiti applicabili.

Distingui la review collegata all’operazione dal riesame periodico di eventi di sistema, configurazioni e privilegi. Se un evento di sistema può incidere sul dataset in esame, va collegato alla valutazione corrente; non basta archiviarlo in un controllo futuro. Nessuna periodicità unica è adatta a tutti i CDS.

3. Verificare che filtri e report non nascondano eventi

Documenta quali sorgenti il report interroga, intervallo temporale, fusi, utenti, progetti, stati e tipi di evento inclusi o esclusi. Controlla se mostra solo sequenze completate, risultati approvati o versioni correnti. Valuta anche paginazione, limiti d’esportazione e possibilità di tornare all’evento e al dato originali.

Un esempio editoriale di prova usa cinque eventi sintetici noti: acquisizione completata, interruzione, rielaborazione, modifica del metodo e cambio autorizzato di ruolo. Prima di applicare il filtro, stabilisci quali eventi devono comparire nel report e quali sono riesaminati tramite un’altra registrazione. Confronta atteso e osservato e documenta le differenze, non soltanto il numero di righe.

La prova va progettata in un ambiente isolato e autorizzato; non richiede cancellazioni di dati o disattivazione dell’audit trail. Ripetila quando cambiano query, configurazione o versione con impatto sulla copertura. La review per eccezioni richiede criteri giustificati e affidabilità dimostrata: “nessuna eccezione” ha valore solo se la selezione funziona.

4. Collegare ogni evento a una domanda e a un’azione

Questa matrice originale orienta la review, senza sostituire la procedura o predeterminare l’esito. Un evento può essere spiegato correttamente, richiedere integrazioni o aprire un’indagine; la parola usata dal software non decide da sola.

Per valutare una rielaborazione dei picchi, il log va letto insieme al segnale e al metodo. Ripetizioni, esclusioni o modifiche dopo la review richiedono contesto. Un accesso fallito, invece, non dimostra automaticamente una manipolazione del dato: valuta identità, attività successive e controlli.

5. Caso simulato e registrazione della conclusione

Un riepilogo mostra una sequenza completata. Il confronto con l’elenco delle acquisizioni rivela una precedente sequenza interrotta sugli stessi campioni. Il revisore verifica il filtro: selezionava soltanto lo stato “completato”. Preserva entrambe le sequenze e ricostruisce iniezioni eseguite, motivo dell’interruzione, ripresa e risultati utilizzati.

Se la ricostruzione è completa, documenta l’esito analitico e corregge in modo controllato il processo di reporting. Valuta anche quali review precedenti potrebbero essere state interessate. Se mancano dati o ragioni, mantiene aperta l’anomalia e attiva l’escalation prevista. Non dichiara completa la review perché la sequenza finale è conforme.

Registra perimetro, sorgenti, versione del report o criteri di ricerca, revisore, data, evidenze consultate, quesiti, risposte, conclusione e collegamenti alle indagini. Una firma senza perimetro non rende ripetibile il controllo. La chiusura di un quesito di review non equivale automaticamente alla chiusura di un’indagine o al rilascio del lotto.

Riesamina periodicamente il processo: filtri modificati, eventi non riconosciuti, formazione e problemi ricorrenti possono richiedere aggiornamenti. Valuta la qualità delle conclusioni e la copertura, senza misurare l’efficacia soltanto dal numero di righe lette.

6. Riferimenti e applicabilità

Fonti verificate il 1–2 ottobre 2026. Contesto di laboratorio GMP per medicinali umani; esempi simulati, nessuna attività su sistemi reali. I dettagli operativi dipendono dal CDS e dalle procedure approvate.

• FDA — Data Integrity and Compliance With Drug CGMP, finale dicembre 2018, Q1c e Q7–8: definizione, responsabilità e frequenza. Guidance non vincolante, da leggere con le regole CGMP applicabili.
• Commissione europea — Annex 11, revisione gennaio 2011, operativa dal 30 giugno 2011, §§9, 12–13: audit trail, sicurezza e incidenti. La proposta 2025 resta distinta dal testo adottato.
• PIC/S — PI 041-1, finale 1 luglio 2021, §9.6: configurazione, comprensione e review degli audit trail. Guidance ispettiva GMP/GDP; la matrice sopra è originale e non riproduce quella PIC/S.