Validazione Safety Database PV: CSV, Annex 11 e audit trail

Validazione del Safety Database in Farmacovigilanza: cosa serve davvero per superare un audit

Se dovessi identificare la singola domanda che fa saltare la sedia a molti team PV durante un’ispezione è questa:

“Mi mostrate l’evidenza che il vostro safety database è validato per l’uso previsto, che i dati sono integri e che le modifiche sono sotto controllo?”

Il punto critico non è “avere un software famoso”. È dimostrare che il sistema produce ICSRs corretti, mantiene integrità dei dati, e rende tracciabile chi ha fatto cosa e quando (soprattutto quando il volume casi cresce e la pressione sulle tempistiche aumenta). Nella Guida Master, il safety database è descritto come cuore tecnologico della farmacovigilanza e viene esplicitato quanto sia cruciale che sia validato e sicuro.

Perché il safety database è GxP-critical (anche se non lo chiamate “GxP”)

In farmacovigilanza il database non è un semplice archivio: è un sistema che deve supportare processi regolatori con impatto diretto su pazienti e compliance. In pratica deve:

• mantenere auditability end-to-end (data entry → medical review → submission)
• generare output strutturati (E2B(R3)) senza errori di mapping/interfacce
• gestire MedDRA versioning e ricodifiche senza perdere tracciabilità
• proteggere la confidenzialità (accessi profilati) e garantire business continuity (backup/restore)

La Guida Master richiama chiaramente che il QPPV deve essere informato sullo stato del sistema e che il database deve garantire integrità e sicurezza dei dati.

Il mito pericoloso (contrarian insight): “Il vendor ha già validato, quindi siamo coperti”

Questa è una pratica obsoleta e rischiosa.

Perché è un mito:
La validazione del fornitore copre il prodotto standard. L’audit (e il buon senso GxP) chiede evidenza sul vostro intended use: configurazioni, workflow, ruoli, interfacce, reportistica, e soprattutto come il sistema è realmente usato in azienda.

Rischio tipico in audit: database “vendor-validated” ma:

• configurazioni cambiate “al volo” senza test documentati
• profili utente troppo permissivi (nessuna segregazione dei compiti)
• audit trail presente ma mai revisionato
• patch/upgrade applicati senza regression test

L’approccio che regge in ispezione: CSV risk-based + Data Integrity (ALCOA+)

Quando parliamo di Computer System Validation (CSV) in PV, l’approccio più difendibile è:

1. definire l’intended use (cosa deve fare il sistema nel vostro PV system)
2. applicare una validazione risk-based (non “testare tutto”, ma testare ciò che impatta compliance e paziente)
3. dimostrare Data Integrity con logiche ALCOA+:

 LSI terms (nuovi rispetto agli articoli precedenti): ALCOA+, audit trail review, Computer System Validation (CSV), URS, IQ/OQ/PQ, GAMP 5, Annex 11, 21 CFR Part 11, RBAC, Validation Traceability Matrix.

Deliverable “minimi” che un auditor si aspetta (e che dovreste trovare in 2 minuti)

Blocco	Evidenza che funziona in audit	“Red flag” tipica
Governance CSV	Validation Plan + responsabilità + strategia risk-based	“Abbiamo un pacchetto del vendor”
Requisiti	URS (User Requirements Specification) approvata	URS assente o generica
Tracciabilità	Validation Traceability Matrix (URS → test)	test “slegati” dai requisiti
Test	IQ/OQ/PQ o equivalente documentato	solo screenshot non controllati
Controllo accessi	RBAC, ruoli, segregazione compiti	admin condivisi / accessi eccessivi
Part 11/Annex 11	e-signature, audit trail, time sync	audit trail disabilitato/non revisionato
Change control	ticket, impatto, regression test, approvazioni	modifiche “config” non tracciate
Business continuity	backup + restore test + DR test	backup dichiarato ma mai provato
Interfacce	test e riconciliazione (gateway, E2B)	mismatch di campi, casi “persi”

I 7 punti tecnici che “fanno finding” (quasi sempre)

1) Audit trail: c’è, ma non viene usato

Un audit trail non serve a nulla se:

• nessuno lo sa estrarre
• non c’è una procedura di audit trail review
• non esistono criteri per definire cosa è “anomalo”

Pratica che regge: una revisione periodica risk-based (es. mensile) focalizzata su:

• modifiche a seriousness/expectedness
• change di prodotti sospetti/concomitanti
• cancellazioni/merge
• override di regole automatiche

2) Accessi non profilati e “super-user culture”

In fase di audit, il pattern più frequente è vedere:

• troppi utenti con privilegi elevati
• account condivisi
• assenza di revisione periodica degli accessi

Suggerimento operativo: prevedere una User Access Review trimestrale con evidenza firmata (PV + QA/IT).

3) Time zone & date logic (sottovalutatissime)

Gli auditor amano i bug “silenziosi”:

• data di ricezione vs data di awareness
• fusi orari affiliate → calcolo deadline errato
• campi obbligatori non realmente obbligatori

Impatto reale: late reporting “di sistema”, non “umano”.

4) Interfacce e mapping E2B(R3)

Se avete gateway verso EudraVigilance o integrazioni (MI/CRM/email intake), l’auditor spesso chiede:

• prove di mapping
• esiti di riconciliazione
• gestione dei failure (re-try, queue, incident)

5) Migrazioni dati e ricostruzione della storia

Cambio versione o cambio vendor? Senza una strategia di data migration con controlli di completezza, vi trovate con:

• casi privi di storia di follow-up
• narrative troncate
• allegati non linkati

6) MedDRA: gestione versione e re-coding controllato

Non è un tema “solo medico”. È data governance:

• quando cambiate versione MedDRA?
• come gestite recoding e impatto su aggregate/report?

7) Backup & disaster recovery: dichiarati, non testati

Qui l’auditor vuole evidenza concreta: restore test documentato e (idealmente) un disaster recovery test periodico.

Mini-checklist “30 secondi” (per il QPPV e per QA/IT)

Se oggi arrivasse una notifica di ispezione, riuscite a produrre subito:

• URS approvata + matrice di tracciabilità
• ultimi report di change control e regression test
• evidenza di audit trail review
• evidenza di access review (RBAC)
• report ultimo backup/restore test
• log incident e deviazioni sul sistema PV
• training record utenti chiave (PV/IT/QA)

Box “Da ricordare”

Validazione non significa “non avere problemi”. Significa avere un sistema che:

1. intercetta gli errori
2. li traccia
3. li corregge con change control
4. dimostra che i dati restano affidabili.

Conclusione (e perché conviene farla bene)

Una CSV fatta bene in PV non è burocrazia: è ciò che vi evita late reporting sistemici, invii E2B errati e—soprattutto—finding critici che poi si trasformano in CAPA costose e urgenti.