Signal Management avanzato: come costruire un dossier segnale pronto per PRAC e ispezioni

Molte aziende “fanno signal detection”. Poche aziende sanno dimostrare come un segnale è stato:

• identificato,
• validato,
• prioritizzato,
• valutato,
• e chiuso (o convertito in azione).

E in ispezione, la differenza tra le due è enorme.

Nella Guida Master viene descritto che la gestione segnali include analisi aggregate e metodi di disproporzionalità (citando approcci statistici) e che il QPPV deve seguire da vicino il processo e portarlo al comitato interno.

Qui facciamo un passo oltre: come rendere il processo “difendibile”, non solo “esistente”.

Il mito da smontare (contrarian insight): “Un segnale è un numero”

È una scorciatoia classica.

• Mito: “Se la metrica non supera la soglia, non è un segnale.”
• Rischio: vi perdete segnali clinicamente rilevanti (sottosegnalati, eventi rari, popolazioni speciali).
• Mito gemello: “Ne parliamo nel prossimo PSUR.”
• Rischio: la governance appare reattiva e lenta.

In audit, quello che “pesa” non è la soglia: è la tracciabilità della decisione.

Lessico tecnico (LSI) che un auditor/esperto si aspetta di sentire

Qui i termini chiave nuovi rispetto ai vostri articoli già pubblicati:

• EVDAS (EudraVigilance Data Analysis System)
• SMQ (Standardised MedDRA Queries)
• gerarchia MedDRA SOC / HLGT / HLT / PT / LLT
• IME list (Important Medical Events)
• ROR (Reporting Odds Ratio)
• EBGM (Empirical Bayes Geometric Mean)
• Information Component (IC)
• CCSI / CCDS (Company Core Safety Information / Data Sheet)
• Reference Safety Information (RSI)
• signal validation e signal prioritization
• case-series analysis
• dechallenge/rechallenge
• time-to-onset distribution
• confounding by indication
• signal tracking log

Il processo “audit-proof” in 6 step (senza reinventare le GVP)

Step 1 — Detection (screening): definire come cercate

Le aziende solide evitano “screening a sensazione” e formalizzano 3 elementi:

• Fonte dati: safety database interno, EVDAS, letteratura, real world evidence
• Query standardizzate: uso di SMQ e cluster di PT (MedDRA) coerenti
• Filtro clinico: IME list + criteri di severità/prevenibilità

Errore tipico: screening basato su 2–3 PT “a memoria”. Risultato: non replicabile.

Step 2 — Triage: distinguere rumore da segnale prioritario

Qui serve una matrice semplice ma documentata.

Esempio criteri di prioritizzazione:

• gravità clinica (morte, life-threatening, disabilità)
• popolazioni vulnerabili (pediatria, gravidanza, insufficienza renale)
• novità rispetto a RSI/CCSI
• plausibilità biologica
• trend temporale e “clustering” (picchi improvvisi)
• rischio di errore terapeutico (medication error) o device-related (se applicabile)

Step 3 — Validation: quando lo chiamate davvero “segnale”

La signal validation non è “confermare la causalità”. È dichiarare che l’informazione merita valutazione strutturata.

In audit, il problema che emerge più spesso è: segnale discusso “a voce”, ma:

• nessun verbale,
• nessun razionale scritto,
• nessun owner,
• nessuna scadenza.

Step 4 — Evaluation: come fate la valutazione clinica (e cosa documentate)

Qui il segnale diventa dossier.

Elementi pratici che rendono la valutazione robusta:

• Case-series analysis: rivedere i casi come serie, non come singoli
• gestione duplicati: “same patient, multiple reporters”
• time-to-onset distribution: pattern compatibili/incompatibili
• dechallenge/rechallenge: quando presente, vale oro (anche se raro)
• confounding by indication: patologia di base vs farmaco
• qualità dati: missingness, follow-up ottenuti, esposizione stimata
• confronto con RSI/CCSI (expectedness)

Step 5 — Decision: chi decide, dove, con quali output

Un segnale “ben gestito” ha un output chiaro:

• chiusura (razionale e condizioni: “monitorare per 3 cicli”)
• oppure azione: label change, aggiornamento RMP, PASS, DHPC (se applicabile)

Step 6 — Action & Follow-up: il pezzo che spesso manca

Se decidete un’azione, l’auditor vuole vedere che:

• l’azione è stata implementata (non solo proposta)
• avete verificato efficacia o almeno avanzamento
• il segnale è tracciato fino alla chiusura

Il cuore operativo: il “Signal Tracking Log” (template ragionato)

Se dovessi consigliarvi un singolo artefatto “ad alto ROI” è questo: un signal tracking log unico e controllato.

Campi che rendono il log realmente difendibile:

1. Signal ID (univoco) + data apertura
2. fonte (EVDAS, interno, letteratura, affiliate)
3. trigger: SMQ/PT, IME, cluster, case-series
4. snapshot numerico: casi totali, seri, fatal, trend temporale
5. metriche: ROR / EBGM / IC (se usate) + metodo
6. confronto con RSI/CCSI (expectedness)
7. sintesi clinica (5–10 righe, non un romanzo)
8. decisione + razionale
9. azioni + owner + due date
10. link a verbali/attachments (minutes del Safety Committee)
11. stato (open/monitoring/closed) + data chiusura

Tabella: cosa vuole vedere un ispettore in un dossier segnale

Sezione dossier	Evidenza “buona”	Errore ricorrente
Screening	query replicabile (SMQ/PT) + frequenza	screening ad hoc non documentato
Qualità dati	note su missingness e follow-up	assumere che “assenza info = assenza rischio”
Analisi	case-series + confondenti	solo metrica numerica
Expectedness	confronto RSI/CCSI	confusione tra atteso/inatteso
Governance	verbali + decision owner	decisioni senza traccia
Output	chiusura motivata o action plan	“monitoriamo” senza criteri

Mini-checklist “30 secondi” per capire se siete maturi

Se prendo un segnale chiuso 6 mesi fa, riuscite a recuperare subito:

• query che lo ha generato (SMQ/PT)
• serie casi e criteri inclusione/esclusione
• razionale di chiusura o azione decisa
• verbale comitato e approvazioni
• follow-up (cosa avete monitorato dopo)

Se una di queste risposte è “no”, il rischio non è solo audit: è perdita di memoria organizzativa.

Box “Da ricordare”

Un segnale non è (solo) detection. È governance.
Il vostro obiettivo non è dimostrare che “non ci sono segnali”, ma che quando emergono avete un processo che produce decisioni coerenti, tracciabili e orientate al paziente.

Conclusione

Il signal management “avanzato” non richiede magie statistiche: richiede disciplina documentale, linguaggio comune (MedDRA/SMQ), e un log di decisione che permetta a chiunque (audit, PRAC, QPPV deputy) di ricostruire cosa è successo senza interpretazioni.