Pharmacovigilance

elaborazione dei casi di eventi avversi

Governare un agente di farmacovigilanza per la ricezione degli eventi avversi e l'elaborazione dei casi

13 min · Updated 2026-06-02

Answer

Si governa un agente di elaborazione dei casi di farmacovigilanza intercettando le decisioni ad alto impatto prima che producano effetti — validità del caso, gravità e prevedibilità, codifica MedDRA, orologio del Giorno 0 e qualsiasi invio o chiusura automatica di ICSR — con un controllo di policy che restituisce allow, warn, require_approval o block. Le decisioni sulla segnalabilità e sulla chiusura automatica vengono instradate, tramite un'Escalation maker-checker, a una persona qualificata nominata; un Lineage Record verificabile crittograficamente viene sigillato e funge anche da pista di controllo ai sensi di 21 CFR Part 11. KLA non costruisce l'agente PV del cliente: governa l'agente del cliente e produce evidenze GVP, ICH e Part 11 a ogni esecuzione.

KLA is the independent runtime governance and assurance layer forthis Process. KLA governs the agent you already built, whether it was built in-house or on a commercial agent framework: it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.

The Process

The job & where the agent takes high-stakes action

Un agente di elaborazione dei casi di farmacovigilanza (PV) acquisisce segnalazioni di eventi avversi da canali spontanei, dalla letteratura, sollecitati e digitali, quindi porta un caso regolamentato fino alla decisione regolatoria. I suoi punti decisionali ad alto impatto sono: (1) validità del caso — stabilire se sono soddisfatti i quattro criteri minimi ICH E2D (segnalatore identificabile, paziente identificabile, reazione avversa, prodotto sospetto), determinando così se esiste un ICSR valido; (2) codifica MedDRA — selezionare i Lowest Level Terms (LLT) secondo ICH M1 per reazioni, indicazioni e anamnesi; (3) valutazione della gravità — classificare l'evento secondo i sei criteri di gravità ICH E2D (decesso, pericolo di vita, ospedalizzazione o prolungamento, disabilità persistente o significativa, anomalia congenita, evento clinicamente importante); (4) prevedibilità — confrontare la reazione con l'etichetta locale o SmPC; (5) causalità e segnalabilità — decidere se il caso è segnalabile e quale termine regolatorio si applica; (6) termine regolatorio — fissare il Giorno 0, la data in cui una persona dell'azienda ha ricevuto per la prima volta un caso che soddisfaceva i criteri minimi e quelli per la procedura accelerata; e (7) scrittura terminale — redigere e inviare un ICSR come messaggio E2B(R3), oppure chiudere automaticamente un caso come non valido o non segnalabile. I punti decisionali 5, 6 e 7 sono quelli in cui l'agente può avviare un invio regolatorio, mancare una scadenza o chiudere silenziosamente un caso segnalabile nel database di sicurezza, il sistema di riferimento.

Stakes

Why it's high-stakes

Una reazione avversa grave e inattesa a un farmaco deve essere segnalata appena possibile e comunque entro 15 giorni di calendario dalla ricezione iniziale ai sensi di ICH E2D §4.3 e 21 CFR 314.80(c)(1)(i); secondo EMA GVP Module VI il termine parte dal Giorno 0, nel momento in cui una persona dell'azienda — inclusi un informatore scientifico o un collaboratore — riceve i criteri minimi, e non quando il dipartimento di sicurezza la registra. Se l'agente codifica erroneamente un evento grave come non grave, giudica prevista una reazione incerta o chiude automaticamente un caso che avrebbe dovuto essere segnalabile, il termine di 15 giorni non parte oppure scade senza essere rispettato. Il problema resta invisibile fino a un'ispezione: non c'è alcun invio da trovare né alcun allarme, solo un caso chiuso silenziosamente. Le segnalazioni accelerate tardive o omesse sono una constatazione ricorrente nelle ispezioni di farmacovigilanza EMA e FDA e possono determinare provvedimenti regolatori contro l'autorizzazione all'immissione in commercio. La conseguenza per la sicurezza dei pazienti — un segnale reale di danno che non raggiunge mai l'autorità — aggrava l'esposizione alla non conformità.

What goes wrong

Failure modes specific to this agent

Un declassamento silenzioso della gravità chiude l'orologio accelerato prima che inizi

L'agente legge una narrazione in testo libero ('il paziente è rimasto ricoverato durante la notte in osservazione e si è ripreso') e codifica l'evento come non grave perché non compare alcuna parola chiave esplicita, ignorando che l'ospedalizzazione è di per sé un criterio di gravità ICH E2D. Poiché la gravità attiva l'orologio accelerato di 15 giorni, una classificazione non grave impedisce all'agente di aprire il percorso accelerato: il caso entra nel percorso non grave di 90 giorni o viene chiuso, e il Giorno 0 viene di fatto abbandonato.

Why it's hard to catch: Non compare alcun errore o allarme: l'agente ha prodotto un caso sintatticamente valido, coerente al suo interno e corredato da una motivazione apparentemente difendibile. I set di test QA sono costruiti su casi storici già codificati, quindi premiano la corrispondenza con l'etichetta invece dell'individuazione di un criterio grave implicito nella narrazione. L'errore emerge solo quando un ispettore riconcilia i documenti di origine con il database di sicurezza mesi dopo, quando la scadenza è ormai passata da tempo e l'omissione è una violazione documentata, non un quasi-errore.

Valutazione errata della prevedibilità per una versione sbagliata dell'etichetta o per una propensione verso «attesa»

ICH E2D §2.4 richiede che, quando il titolare non è certo che una reazione sia prevista, essa venga trattata come inattesa: un'impostazione prudenziale a favore della segnalabilità. Un agente LLM ragiona in termini probabilistici e, nell'incertezza, spesso sceglierà l'esito più comune, «attesa», che è l'opposto dell'impostazione predefinita regolatoria; può anche confrontare la reazione con una versione dell'etichetta obsoleta o riferita alla regione sbagliata. Così trasforma un caso grave e inatteso segnalabile in un caso grave previsto non segnalabile.

Why it's hard to catch: Il ragionamento appare competente: l'agente cita un termine reale dell'etichetta e una corrispondenza plausibile. Il risultato non segnala di aver risolto l'incertezza nella direzione sbagliata o di aver usato lo SmPC del giorno precedente. La prevedibilità è un giudizio senza una chiave di verità di riferimento, quindi i test di accuratezza non possono valutarla. Inoltre, poiché l'impostazione predefinita regolatoria (incerto = inatteso) è l'inverso della probabilità statistica del modello, l'errore è sistematico anziché casuale e il controllo a campione di alcuni casi corretti crea una falsa sicurezza.

Una codifica MedDRA al livello o con la versione sbagliati altera gravità e segnale

L'agente seleziona un termine MedDRA al livello Preferred Term quando era richiesto l'LLT (secondo GVP Module VI / ICH M1), sceglie un LLT clinicamente vicino ma errato oppure codifica con una versione MedDRA superata dopo un cambio di versione MSSO. Una reazione codificata con un LLT benigno invece di quello clinicamente importante può uscire dalla valutazione della gravità e interamente dal rilevamento aggregato dei segnali.

Why it's hard to catch: Il termine codificato è una voce MedDRA valida, quindi la validazione dello schema e l'accettazione dal gateway E2B(R3) superano il controllo: il messaggio è ben formato e viene riconosciuto. L'errore clinico è visibile solo a un codificatore formato che confronti il termine con il testo letterale del segnalatore. A livello aggregato la codifica errata altera silenziosamente il rilevamento dei segnali: i casi interessati non si raggruppano sotto il termine corretto, quindi il segnale di sicurezza viene soppresso invece di essere rilevato.

Deriva del Giorno 0: l'agente fa partire l'orologio dall'acquisizione nel sistema anziché dalla prima ricezione

L'agente assegna il Giorno 0 al momento in cui il caso entra nel database di sicurezza, o in cui elabora l'e-mail, ma GVP Module VI e ICH E2D definiscono il Giorno 0 come la data in cui una persona dell'azienda ha ricevuto per la prima volta i criteri minimi — spesso giorni prima, quando un informatore scientifico, un servizio di informazioni mediche o un collaboratore ne è venuto a conoscenza. La data successiva dell'agente consuma silenziosamente parte della finestra di 15 giorni e l'elemento E2B(R3) C.1.4, «data della prima ricezione dalla fonte», viene valorizzato con l'origine errata.

Why it's hard to catch: Ogni calcolo successivo è aritmeticamente corretto rispetto alla data di inizio sbagliata, quindi il caso appare puntuale in ogni pannello interno. La discrepanza esiste solo tra la data di contatto del documento di origine e la data di acquisizione nel sistema, dati che spesso l'agente non vede e che i test non forniscono. Un ispettore che recuperi la registrazione del canale di ricezione originale trova un Giorno 0 antecedente di una settimana a quello del sistema e rende retroattivamente tardivi invii definiti «puntuali».

How KLA governs it

Runtime controls, mapped to each decision point

KLA evaluates each consequential action with a policy gate that runs before the action executes: a Decision Request to POST /v1/decisions.evaluate: resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.

Decision point	Intercept (before action)	Policy checks → reason codes	Human routing (maker-checker)	Evidence captured
Validità del caso — esiste un ICSR valido (quattro criteri minimi ICH E2D / GVP Module VI)?	Govern in Place: un punto di controllo dell'SDK KLA avvolge il passaggio commit_case_validity dell'agente e invia una Decision Request a POST /v1/decisions.evaluate prima che l'agente contrassegni il caso come valido o non valido, oppure lo instradi alla fase successiva. Lo stesso passaggio può essere eseguito centralmente attraverso i controlli KLA tramite l'Executions API.	PV.VALIDITY.MIN_CRITERIA_INCOMPLETE — avvisa se manca uno dei quattro criteri minimi (segnalatore identificabile, paziente identificabile, reazione avversa, prodotto sospetto), allegando l'obbligo di verifica e follow-up PV.VALIDITY.AUTOCLOSE_AS_INVALID — blocca qualsiasi tentativo di chiudere definitivamente un caso come «ICSR non valido» quando è presente un criterio di gravità o un prodotto sospetto, con rimedio: instradare alla persona qualificata PV.VALIDITY.FOLLOWUP_REQUIRED — avvisa e contrassegna per il follow-up invece di chiudere quando i criteri sono soddisfatti solo in parte	block o require_approval instrada un'Escalation maker-checker al revisore nominato per l'elaborazione dei casi PV e, per la chiusura automatica di un caso potenzialmente valido, alla Qualified Person for Pharmacovigilance o al medico di sicurezza reperibile, in Decision Desk. Il revisore approva, respinge o re-instrada.	quali dei quattro criteri minimi sono stati rilevati rispetto a quelli mancanti la versione del pacchetto di policy e i reason code restituiti la motivazione di validità dell'agente e i campi di origine l'id del Lineage Record che collega il canale di ricezione a questa decisione
Gravità, prevedibilità e codifica MedDRA — la valutazione medica che determina il percorso regolatorio	Il punto di controllo Govern in Place dell'SDK, nel passaggio assess_case dell'agente, invia una Decision Request a POST /v1/decisions.evaluate prima che il risultato di gravità, prevedibilità e codifica venga scritto nel caso.	PV.SERIOUS.IMPLICIT_CRITERION — require_approval quando la narrazione segnala un criterio di gravità ICH E2D (ospedalizzazione, pericolo di vita, disabilità, anomalia congenita, decesso, evento clinicamente importante) ma l'agente ha codificato il caso come non grave PV.EXPECTED.UNCERTAIN_DEFAULT — blocca una classificazione «prevista / non segnalabile» adottata in presenza di incertezza segnalata dal modello; ICH E2D §2.4 richiede di impostare come predefinito «inattesa», con rimedio: trattare come inattesa in attesa della firma QPPV PV.EXPECTED.LABEL_VERSION_STALE — avvisa se la versione dell'etichetta/SmPC utilizzata non è quella attualmente in vigore per la regione del caso PV.MEDDRA.LEVEL_OR_VERSION — avvisa se una reazione è codificata sopra il livello LLT o con una versione MedDRA non corrente secondo la raccomandazione MSSO associata	require_approval o block apre un'Escalation instradata al revisore medico o medico di sicurezza nominato, quale controllo maker-checker sulla valutazione medica dell'agente; la QPPV è la destinazione per il re-instradamento delle decisioni contestate sulla prevedibilità.	i criteri di gravità valutati e il verdetto per ciascun criterio la decisione sulla prevedibilità, l'id della versione dell'etichetta e ogni indicatore di incertezza la versione MedDRA, l'LLT selezionato e il testo letterale del segnalatore i reason code e il verdetto umano sull'Escalation
Segnalabilità e orologio regolatorio — fissare il Giorno 0 e il percorso di 15 o 90 giorni	Il punto di controllo Govern in Place dell'SDK, nel passaggio determine_reportability dell'agente, invia una Decision Request a POST /v1/decisions.evaluate prima che al caso venga assegnato un termine regolatorio e venga instradato all'invio o alla chiusura.	PV.CLOCK.DAY0_SOURCE — blocca un Giorno 0 ricavato dalla marca temporale di acquisizione nel sistema; richiede la prima data di ricezione da parte di una persona dell'azienda secondo GVP Module VI VI.B.7, con rimedio: riconciliare con la data di contatto del canale di ricezione PV.CLOCK.SERIOUS_UNEXPECTED_15D — require_approval per confermare il percorso accelerato di 15 giorni di calendario ogni volta che il caso è grave e inatteso PV.REPORTABILITY.AUTOCLOSE_NONREPORTABLE — blocca la chiusura automatica di un caso grave come non segnalabile; instrada a una persona qualificata PV.CLOCK.DEADLINE_AT_RISK — avvisa / intensifica quando il tempo rimanente alla scadenza di 15 giorni scende sotto il buffer SLA	require_approval apre un'Escalation maker-checker al revisore nominato per la segnalabilità o alla Qualified Person for Pharmacovigilance; dopo l'approvazione l'esecuzione riprende esattamente dal punto di pausa (idempotency_key garantisce un solo invio); in caso di rifiuto l'esecuzione termina senza eseguire alcuna scrittura.	il Giorno 0 calcolato, la sua data di origine e l'esito della riconciliazione il percorso assegnato (15 giorni accelerato o 90 giorni non grave) e la scadenza identità dell'approvatore, significato della firma, marca temporale versione del pacchetto di policy e reason code
Scrittura terminale — inviare l'ICSR come messaggio E2B(R3) o chiudere automaticamente il caso nel sistema di riferimento	Il punto di controllo Govern in Place dell'SDK avvolge la chiamata allo strumento submit_e2b / close_case; la Decision Request a POST /v1/decisions.evaluate è l'ultimo controllo prima della scrittura irreversibile nel gateway o nel database di sicurezza.	PV.E2B.SCHEMA_AND_SUBSET — blocca un invio non conforme al sottoinsieme ICH E2B(R3) di ISO/HL7 27953-2 (elementi obbligatori malformati o mancanti, come C.1.4 data della prima ricezione o E.i.3.2 gravità) PV.E2B.UNSIGNED_ASSESSMENT — blocca l'invio di qualsiasi caso la cui gravità, prevedibilità o segnalabilità non sia stata firmata da una persona quando la policy lo richiede PV.CLOSE.WITHOUT_VERDICT — blocca la chiusura automatica di un caso privo di un verdetto registrato sulla segnalabilità e, quando richiesto, di una firma umana PV.E2B.IDEMPOTENCY — consente con un idempotency_key affinché un invio approvato venga trasmesso esattamente una volta	Gli esiti block sospendono la scrittura e aprono un'Escalation al revisore nominato per l'invio o alla QPPV; nessun ICSR viene trasmesso e nessun caso viene chiuso finché l'Escalation non si risolve con un'approvazione.	il payload E2B(R3) esatto (o il suo hash), inclusi gli elementi C.1.4 ed E.i.3.2 la conferma del gateway e l'id del messaggio il Lineage Record completo dalla ricezione alla trasmissione con tutte le decisioni di policy e i verdetti umani allegati il Sealed Evidence Bundle / Control Pack relativo a questo caso

Least-privilege execution & data boundaries

Validità del caso — esiste un ICSR valido (quattro criteri minimi ICH E2D / GVP Module VI)?: La Release dell'agente associa solo gli strumenti di lettura del database di sicurezza e di assegnazione dei tag al caso nel Tool Catalog; nella fase di validità non dispone di alcuno strumento submit_e2b o close_case, quindi non può eliminare definitivamente un caso qui anche se il suo ragionamento è errato.
Gravità, prevedibilità e codifica MedDRA — la valutazione medica che determina il percorso regolatorio: La Release associa, tramite Data Boundaries, una versione fissata del dizionario MedDRA e il repository corrente delle etichette come sole fonti di codifica; l'agente non può accedere a un'etichetta arbitraria o in cache e gli strumenti di codifica sono di sola lettura sul dizionario fissato.
Segnalabilità e orologio regolatorio — fissare il Giorno 0 e il percorso di 15 o 90 giorni: Il passaggio di segnalabilità non dispone di uno strumento di invio in rete; solo dopo l'approvazione umana la Release espone il passaggio di invio sottoposto a controllo. La firma umana viene acquisita come manifestazione di firma elettronica ai sensi del 21 CFR 11.50 (nome stampato, data e ora, significato = approvazione).
Scrittura terminale — inviare l'ICSR come messaggio E2B(R3) o chiudere automaticamente il caso nel sistema di riferimento: submit_e2b e close_case sono gli strumenti con l'ambito più ristretto nel Tool Catalog, associati solo alla Release attiva dell'agente ed esposti solo dopo il superamento dei controlli precedenti; Data Boundaries mantengono la trasmissione al gateway nella regione approvata.

Mapped to regulation

Regulatory mapping

Framework	Article / section	Obligation (plain language)	How a KLA runtime control satisfies it	Source
EMA GVP Module VI (Rev 2) — EMA/873138/2011 Rev 2	VI.B.7 — Invio degli ICSR (Giorno zero / avvio del termine) e VI.B.7.1 (15 giorni per i casi gravi; 90 giorni per i casi non gravi)	Il termine per l'invio parte, al Giorno 0, nel momento in cui i criteri minimi vengono portati all'attenzione di qualsiasi persona dell'azienda — inclusi informatori scientifici e collaboratori — e non quando il dipartimento di sicurezza li registra. Gli ICSR validi gravi devono essere inviati entro 15 giorni di calendario da quella ricezione, iniziale o di follow-up; quelli non gravi entro 90 giorni.	Il controllo di segnalabilità e termine (runtime_controls[2]) blocca un Giorno 0 derivato dall'orario di acquisizione nel sistema (PV.CLOCK.DAY0_SOURCE), impone la riconciliazione con la prima data di ricezione e usa require_approval per confermare il percorso di 15 giorni ogni volta che il caso è grave e inatteso; la scadenza e il relativo calcolo sono sigillati nel Lineage Record.	Source
EMA GVP Module VI (Rev 2) — EMA/873138/2011 Rev 2	VI.B.2 — Validazione degli ICSR (quattro criteri minimi)	Possono essere inviati solo ICSRs validi; la validazione richiede quattro criteri minimi (segnalatore identificabile, un paziente identificabile, sostanza/prodotto sospetto, reazione avversa sospetta). La mancanza di un elemento rende il caso incompleto e non idoneo all'invio.	Il controllo di validità del caso (runtime_controls[0]) avvisa quando manca uno dei criteri (PV.VALIDITY.MIN_CRITERIA_INCOMPLETE) e blocca la chiusura automatica terminale come 'non valido' quando è presente un criterio grave o un prodotto sospetto, instradando a una persona qualificata invece di permettere all'agente di eliminare il caso.	Source
ICH E2D (Gestione dei dati di sicurezza post-autorizzazione) + FDA 21 CFR 314.80	ICH E2D §2.3 (gravità), §4.3 (termine di 15 giorni / Giorno 0); 21 CFR 314.80(c)(1)(i) (segnalazioni di allerta entro 15 giorni)	Un caso è grave se provoca decesso, è potenzialmente letale, richiede/prolunga un'ospedalizzazione, causa una disabilità persistente/significativa, è un'anomalia congenita o un evento clinicamente importante; la gravità attiva l'orologio accelerato. Le reazioni gravi e inattese devono essere segnalate appena possibile e comunque entro 15 giorni di calendario dalla ricezione iniziale (l'analogo US in 314.80 è identico).	Il controllo della valutazione medica (runtime_controls[1]) instrada con require_approval ogni caso in cui la narrazione segnali un criterio grave codificato dall'agente come non grave (PV.SERIOUS.IMPLICIT_CRITERION); il controllo del termine (runtime_controls[2]) conferma il percorso di 15 giorni per un caso grave e inatteso, così l'elemento che lo attiva e la scadenza vengono applicati insieme anziché presunti.	Source
EMA GVP Module VI (Rev 2) — Contenuto/formato degli ICSRs elettronici (MedDRA / ICH M1)	VI.C — Reazioni avverse codificate con ICH M1 (MedDRA) al livello LLT	Le reazioni avverse negli ICSR devono essere codificate usando MedDRA (ICH M1) al livello Lowest Level Term, seguendo la guida «MedDRA Term Selection: Points to Consider» e le raccomandazioni MSSO sulla versione.	Il controllo di codifica (runtime_controls[1], PV.MEDDRA.LEVEL_OR_VERSION) avvisa quando una reazione è codificata sopra il livello LLT o con una versione MedDRA non corrente, mentre Data Boundaries vincola l'agente a una singola versione del dizionario, impedendogli di codificare con una versione MedDRA obsoleta o arbitraria.	Source
ICH E2B(R3) — Trasmissione elettronica degli ICSRs (EMA/CHMP/ICH/287/1995)	Standard di messaggistica (ISO/HL7 27953-2, sottoinsieme ICH); E.i.3.2 (gravità a livello di evento); C.1.4 (data della prima ricezione della segnalazione dalla fonte)	La trasmissione elettronica degli ICSR deve essere conforme allo standard di messaggistica E2B(R3) (un sottoinsieme ICH di ISO/HL7 27953-2), riportare la gravità come criteri discreti per evento collegati alle definizioni E2A/E2D e valorizzare C.1.4 con la data in cui i quattro criteri minimi sono stati soddisfatti per la prima volta, origine dell'orologio regolatorio.	Il controllo di scrittura terminale (runtime_controls[3], PV.E2B.SCHEMA_AND_SUBSET) blocca un invio non conforme al sottoinsieme ICH o privo degli elementi obbligatori C.1.4 / E.i.3.2, e il payload esatto (o il suo hash), inclusi tali elementi, viene sigillato nel Lineage Record.	Source
FDA 21 CFR Part 11 (Record elettronici; firme elettroniche)	11.10 (controlli per sistemi chiusi; lettera a, convalida; lettera e, piste di controllo sicure, generate dal computer e con marca temporale)	I sistemi chiusi che creano, modificano o trasmettono registrazioni elettroniche devono garantirne autenticità, integrità e non ripudio; devono essere convalidati per individuare registrazioni non valide o alterate e mantenere piste di controllo sicure, generate dal computer e con marca temporale. Tali piste registrano autonomamente chi ha modificato una registrazione e quando, senza oscurare i dati precedenti; sono conservate almeno quanto la registrazione e rese disponibili all'autorità.	Il registro Evidence-by-Default di KLA, acquisito in tutti i runtime_controls e sigillato in runtime_controls[3], calcola l'hash di ogni controllo di sicurezza, chiamata a strumento e verdetto umano in un registro ImmuDB di sola aggiunta che produce prove Merkle. È una pista di controllo sicura, generata dal computer, con marca temporale e a prova di manomissione, che un revisore verifica autonomamente tramite il Sealed Evidence Bundle senza dover fare affidamento su KLA.	Source
FDA 21 CFR Part 11 (Record elettronici; firme elettroniche)	11.50 — Manifestazioni della firma	Le registrazioni elettroniche firmate devono mostrare il nome in caratteri stampati del firmatario, la data e l'ora della firma e il significato della firma — revisione, approvazione, responsabilità o paternità — in una forma leggibile dall'uomo.	Quando il controllo di segnalabilità o invio (runtime_controls[2], runtime_controls[3]) restituisce require_approval, il verdetto dell'approvatore indicato in Decision Desk viene acquisito come manifestazione di firma Part 11 — nome stampato, marca temporale e significato = approvazione — e sigillato nel Lineage Record insieme all'azione autorizzata.	Source
Legge sull'IA dell'UE (Regolamento (UE) 2024/1689)	Articolo 14, paragrafo 4, lettere d) ed e) — Supervisione umana (annullamento o inversione; arresto in stato sicuro)	Le persone incaricate della supervisione devono poter decidere di non usare, ignorare, annullare o invertire il risultato di un sistema di IA e poter intervenire o interromperlo tramite una procedura di arresto che lo porti a uno stato sicuro. Il riferimento esprime un allineamento trasversale di governance; non afferma che l'elaborazione dei casi PV sia ad alto rischio ai sensi dell'allegato III, che non enumera la farmacovigilanza. I regimi vincolanti qui sono GVP, ICH e Part 11.	Ogni esito require_approval o block (runtime_controls[1]-[3]) realizza questo arresto in stato sicuro: l'esecuzione dell'agente viene trattenuta, non considerata fallita, e una persona nominata può approvare, respingere, annullare, invertire o re-instradare l'azione in Decision Desk prima di qualsiasi scrittura irreversibile.	Source
Legge sull'IA dell'UE (Regolamento (UE) 2024/1689)	Articolo 12, paragrafo 1 — Conservazione dei record (registrazione automatica degli eventi)	I sistemi di IA dovrebbero consentire tecnicamente la registrazione automatica degli eventi per tutta la loro vita operativa. Il riferimento esprime un allineamento trasversale soddisfatto dal Lineage Record di KLA; il regime vincolante per la registrazione in farmacovigilanza è 21 CFR 11.10(e).	KLA acquisisce evidenze per impostazione predefinita: ogni chiamata a strumento, decisione di policy e verdetto umano viene registrato automaticamente nel registro di sola aggiunta per tutta la vita dell'agente (runtime_controls[0]-[3]), soddisfacendo insieme la registrazione dell'articolo 12 e il requisito più rigoroso della pista di controllo previsto dalla Part 11.	Source

Prove the control held

Audit-evidence checklist

Provenienza della ricezione: il canale originale (spontaneo / letteratura / sollecitato / digitale), la data del contatto di prima ricezione usata per fissare il Giorno 0 e la riconciliazione con l'ora di acquisizione nel sistema
Esito del rilevamento dei quattro criteri minimi (presente o mancante per elemento) al controllo di validità
Verdetto di gravità per ciascun criterio ICH E2D, con l'intervallo della narrazione che ha attivato un'eventuale escalation per criterio implicito
Decisione sulla prevedibilità con l'id esatto della versione dell'etichetta o SmPC e ogni indicatore di incertezza del modello, a dimostrazione che è stata applicata l'impostazione predefinita incerto = inatteso
Versione MedDRA, LLT selezionati e testo letterale del segnalatore da cui sono stati codificati
Percorso regolatorio assegnato (15 giorni accelerato o 90 giorni non grave) e scadenza calcolata
Ogni decisione di policy con la versione firmata del pacchetto di policy e i reason code (allow / warn / require_approval / block)
Ogni verdetto umano come manifestazione di firma 21 CFR 11.50: nome stampato, data/ora, significato (revisione/approvazione), associato all'azione autorizzata
Payload E2B(R3) trasmesso, o il suo hash, con gli elementi C.1.4 della prima ricezione ed E.i.3.2 della gravità, oltre alla conferma del gateway e all'id del messaggio
Lineage Record di sola aggiunta con una radice Merkle che il revisore ricalcola autonomamente (GET /v1/lineage/{id}/verify), esportato come Sealed Evidence Bundle o Control Pack mappato alle clausole GVP e Part 11

A concrete intercept

Reference scenario: Un caso proveniente dalla letteratura che l'agente vuole chiudere automaticamente come non grave viene trattenuto per la QPPV

1
Ricezione: l'agente acquisisce un caso pubblicato; sono presenti un autore identificabile (segnalatore), un singolo paziente, un prodotto sospetto e una reazione, quindi i quattro criteri minimi ICH E2D sono soddisfatti ed esiste un ICSR valido.
2
Valutazione: la narrazione dice che il paziente «è stato ricoverato per due giorni ed è stato dimesso in condizioni migliori»; l'agente codifica l'evento come non grave, senza una parola chiave esplicita sulla gravità e, incerto sulla prevedibilità, propende per «prevista», dirigendosi verso la chiusura automatica come caso non grave di 90 giorni.
3
Intercettazione: prima che il risultato di assess_case venga scritto, il punto di controllo Govern in Place dell'SDK invia una Decision Request a POST /v1/decisions.evaluate. La policy PV.SERIOUS.IMPLICIT_CRITERION trova corrispondenza perché la narrazione segnala un'ospedalizzazione mentre l'agente ha codificato il caso come non grave; trova corrispondenza anche PV.EXPECTED.UNCERTAIN_DEFAULT, poiché è stata scelta una reazione prevista in presenza di incertezza segnalata.
4
Esito: la precedenza risolve in block per la decisione sulla prevedibilità e in require_approval per la gravità; l'esecuzione si sospende, senza essere considerata fallita, e KLA apre un'Escalation.
5
Instradamento: l'Escalation arriva in Decision Desk al medico di sicurezza nominato, che vede la narrazione letterale, la codifica dell'agente, i due reason code, la versione dell'etichetta usata e un collegamento al Lineage Record. Ricodifica l'evento come grave, per l'ospedalizzazione, imposta la reazione come inattesa secondo ICH E2D §2.4 e approva il percorso corretto grave e inatteso, registrando una firma 21 CFR 11.50 (nome, marca temporale, significato = approvazione).
6
Ripresa e sigillo: l'approvazione riprende l'esecuzione esattamente dal punto in cui era stata sospesa (idempotency_key garantisce un solo invio); il caso entra ora nel percorso accelerato di 15 giorni con il Giorno 0 fissato alla data di prima ricezione nella letteratura. L'intera traccia dalla ricezione alla decisione — ragionamento dell'agente, entrambi i reason code, correzione e firma del medico — viene sigillata nel Lineage Record di sola aggiunta ed esportata come Control Pack mappato a GVP Module VI e Part 11.

What most teams get wrong

The non-obvious insight

Il controllo che minaccia maggiormente la scadenza è la valutazione di gravità e prevedibilità, non il passaggio di invio; un agente LLM può fallire in modo sistematico, invertendo la logica regolatoria. ICH E2D §2.4 stabilisce che, quando la prevedibilità è incerta, occorre impostare la reazione come inattesa, a favore della segnalabilità, ma un modello linguistico in condizioni di incertezza tende verso l'esito statisticamente più comune, «prevista». L'errore dell'agente non è quindi rumore casuale da compensare con altri casi di test: è una distorsione direzionale che va contro la segnalabilità e colpisce proprio il momento in cui si decide se l'orologio di 15 giorni debba partire.

Why it matters: I team tendono istintivamente a porre il controllo più severo sul passaggio irreversibile di invio, ma a quel punto il danno — un caso grave classificato erroneamente come non grave e previsto — è già incorporato e un invio formalmente corretto della classificazione sbagliata sembra pienamente conforme. La governance deve intervenire prima, durante la valutazione, e codificare l'impostazione predefinita regolatoria come regola di policy rigida: block di una reazione «prevista» in presenza di incertezza segnalata, perché la probabilità stimata dal modello va nella direzione opposta. Questo rilegge anche 21 CFR Part 11: lo stesso Lineage Record che dimostra la pista di controllo consente all'ispettore di vedere la decisione iniziale errata dell'agente e la correzione documentata dalla persona. La correzione diventa evidenza del controllo, anziché un difetto nascosto.

Ai sensi di ICH E2D §4.3 e 21 CFR 314.80(c)(1)(i), una reazione avversa grave e inattesa deve essere segnalata entro 15 giorni di calendario dalla ricezione iniziale; EMA GVP Module VI fissa il Giorno 0 nel momento in cui una persona dell'azienda, compresi un informatore scientifico o un collaboratore, riceve per la prima volta i criteri minimi, e non quando il dipartimento di sicurezza registra il caso. L'implicazione rilevante per la governance è che un agente di elaborazione dei casi che calcola il Giorno 0 dall'acquisizione nel sistema è strutturalmente in ritardo prima ancora di elaborare un singolo campo, perché l'orologio regolatorio corre da quando una persona ha ricevuto la segnalazione, giorni prima. (source)

Q&A

Frequently asked questions

Governare un agente di elaborazione dei casi PV significa che la Legge sull'IA dell'UE lo classifica come ad alto rischio?

No. L'allegato III della Legge sull'IA dell'UE non enumera la farmacovigilanza, quindi l'elaborazione dei casi PV non è automaticamente ad alto rischio ai sensi di tale allegato; l'IA per dispositivi medici segue un distinto percorso di valutazione della conformità ai sensi dell'allegato I. I regimi vincolanti per questo flusso sono GVP, ICH E2D/E2B(R3) e 21 CFR Part 11/GxP. KLA si allinea comunque ai principi trasversali della Legge sull'IA in materia di supervisione umana, articolo 14, e registrazione, articolo 12, come buone pratiche di governance; gli obblighi applicabili soddisfatti dai controlli sono quelli della farmacovigilanza.

Perché la pista di controllo di 21 CFR Part 11 è adatta al Lineage Record di KLA?

La sezione 11.10(e) richiede una pista di controllo sicura, generata dal computer e con marca temporale, che registri autonomamente chi ha creato, modificato o eliminato una registrazione e quando, senza oscurare i dati precedenti, e che venga conservata almeno quanto la registrazione. KLA acquisisce per impostazione predefinita ogni controllo di sicurezza, chiamata a strumento e verdetto umano e ne calcola l'hash in un registro ImmuDB di sola aggiunta che produce prove Merkle. Questo fornisce una pista di controllo Part 11; poiché il revisore ricalcola autonomamente le prove, l'integrità non dipende dalla fiducia nel fornitore e supporta il requisito di convalida della sezione 11.10(a), ossia individuare registrazioni non valide o alterate.

Come impedisce KLA all'agente di mancare il termine accelerato di 15 giorni?

Due controlli operano insieme. Il controllo di segnalabilità e termine blocca un Giorno 0 ricavato dall'orario di acquisizione nel sistema e impone la riconciliazione con la prima data di ricezione, secondo GVP Module VI VI.B.7, così il termine parte dalla data stabilita dall'autorità. require_approval conferma poi il percorso accelerato di 15 giorni di calendario ogni volta che un caso è grave e inatteso e avvisa o intensifica quando il tempo residuo scende sotto il buffer SLA. La scadenza, la data d'origine e la riconciliazione vengono sigillate nel Lineage Record come evidenza.

L'agente può chiudere automaticamente un caso non segnalabile senza una persona?

Solo entro i limiti rigorosi della policy. KLA blocca la chiusura automatica di un caso grave come non segnalabile e blocca la chiusura definitiva come «ICSR non valido» quando è presente un criterio grave o un prodotto sospetto; in entrambi i casi instrada un'Escalation maker-checker a una persona qualificata nominata. I casi realmente non validi o chiaramente non segnalabili possono essere chiusi con allow, registrando il verdetto e la motivazione, ma lo strumento close_case è associato alla Release dell'agente ed esposto solo dopo il superamento dei controlli di validità e segnalabilità. L'agente non può quindi eliminare un caso per il quale non ha autorità.

Chi approva concretamente una decisione PV trattenuta e come viene registrata per un'ispezione?

L'instradamento è dichiarato nella policy, quindi un'Escalation arriva al responsabile nominato di quel rischio: in genere un revisore dell'elaborazione dei casi PV, un revisore medico o medico di sicurezza per le valutazioni, oppure la Qualified Person for Pharmacovigilance per la segnalabilità contestata. La persona approva, respinge o re-instrada in Decision Desk. Ogni verdetto viene acquisito come manifestazione di firma 21 CFR 11.50 — nome stampato, data e ora e significato, revisione o approvazione — collegata all'azione esatta che ha autorizzato e sigillata nel Lineage Record. Ciò consente di rispondere alla domanda dell'ispettore: «chi ha approvato, su quale base e quando?».

Come impedisce KLA invii E2B(R3) malformati o con l'origine errata dell'orologio?

Il controllo di scrittura terminale è l'ultimo controllo prima della trasmissione irreversibile. Blocca ogni invio non conforme al sottoinsieme ICH di E2B(R3) ISO/HL7 27953-2 o privo di elementi obbligatori come C.1.4, data della prima ricezione dalla fonte e origine del termine, o E.i.3.2, criteri di gravità a livello di evento. Blocca anche l'invio di un caso la cui gravità, prevedibilità o segnalabilità non sia stata firmata da una persona quando la policy lo richiede e usa un idempotency_key affinché un messaggio approvato venga trasmesso una sola volta. Il payload o il suo hash, con C.1.4 ed E.i.3.2, viene sigillato nel registro delle evidenze.

Related blueprints & guides

Primary sources

Govern this Process without re-platforming the agent

KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.

Book a demo Read the governance guide