Pharmacovigilance

adverse-event case processing

Gobernanza de un agente de procesamiento de casos y admisión de eventos adversos de farmacovigilancia

13 min · Updated 2026-06-02

Answer

Se gobierna un agente de procesamiento de casos de farmacovigilancia interceptando sus decisiones de alto riesgo antes de ejecutarlas: validez del caso, gravedad y previsibilidad, codificación MedDRA, reloj del Día 0 y cualquier envío o cierre automático de ICSR. Una puerta de política devuelve allow, warn, require_approval o block, dirige las decisiones de reportabilidad y cierre automático a una persona cualificada designada mediante una escalada maker-checker y sella un Lineage Record verificable criptográficamente que también sirve como rastro de auditoría de 21 CFR Parte 11. KLA no crea el agente de farmacovigilancia; gobierna el agente del cliente y produce evidencia de GVP, ICH y Parte 11 en cada ejecución.

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 de procesamiento de casos de farmacovigilancia (PV) recibe informes de eventos adversos de canales espontáneos, bibliográficos, solicitados y digitales, y conduce un caso regulado hasta una decisión regulatoria. Sus decisiones de alto riesgo son: (1) validez del caso: decidir si se cumplen los cuatro criterios mínimos de ICH E2D (notificador identificable, paciente identificable, reacción adversa y producto sospechoso), lo que determina si existe un ICSR válido; (2) codificación MedDRA: seleccionar términos de nivel más bajo (LLT) conforme a ICH M1 para reacciones, indicaciones e historial médico; (3) evaluación de gravedad: clasificar el evento según los seis criterios graves de ICH E2D (muerte, peligro para la vida, hospitalización o prolongación, discapacidad persistente o significativa, anomalía congénita o importancia médica); (4) previsibilidad: comparar la reacción con la etiqueta local o SmPC; (5) causalidad y reportabilidad: decidir si el caso debe notificarse y qué plazo regulatorio aplica; (6) reloj regulatorio: fijar el Día 0, la fecha en que cualquier persona de la empresa recibió por primera vez un caso que cumplía los criterios mínimos y acelerados; y (7) escritura final: redactar y enviar un ICSR como mensaje E2B(R3), o cerrar automáticamente un caso como no válido o no notificable. Las decisiones 5, 6 y 7 pueden activar una notificación regulatoria, incumplir un plazo o cerrar silenciosamente un caso notificable en la base de datos de seguridad, el sistema de registro.

Stakes

Why it's high-stakes

Se debe informar una reacción adversa grave e inesperada a un medicamento lo antes posible y a más tardar 15 días calendario desde su recepción inicial según ICH E2D §4.3 y 21 CFR 314.80(c)(1)(i); El reloj del Módulo VI de EMA GVP comienza el día 0, en el momento en que cualquier personal de la empresa, incluido un representante de ventas o un contratista, recibe los criterios mínimos, no cuando el departamento de seguridad los registra. Si el agente codifica erróneamente un evento grave como no grave, considera que una reacción incierta es "esperada" o cierra automáticamente un caso que debería haber sido reportable, el reloj de 15 días nunca comienza o expira sin cumplirse. El fallo es invisible hasta una inspección: no hay ninguna presentación que encontrar, ninguna alerta, sólo un caso que se cerró silenciosamente. Los informes acelerados tardíos o perdidos son un hallazgo principal en las inspecciones de farmacovigilancia de la EMA y la FDA y pueden desencadenar acciones regulatorias contra la autorización de comercialización. La consecuencia para la seguridad del paciente (una señal real de que el daño nunca llega al regulador) agrava la exposición al cumplimiento.

What goes wrong

Failure modes specific to this agent

La degradación silenciosa de la gravedad cierra el reloj acelerado antes de que comience

El agente lee una narrativa de texto libre ("el paciente pasó la noche en observación y se recuperó") y codifica el evento como no grave porque no aparece ninguna palabra clave grave explícita, sin tener en cuenta que la hospitalización como paciente hospitalizado es en sí misma un criterio grave de ICH E2D. Debido a que la gravedad es el desencadenante del reloj acelerado de 15 días, una clasificación no grave significa que el agente nunca abre la vía acelerada: el caso pasa al carril no grave de 90 días o se cierra, y el día 0 se abandona efectivamente.

Why it's hard to catch: No hay error ni alerta: el agente presentó un caso sintácticamente válido e internamente consistente con una justificación que parecía defendible. Los conjuntos de pruebas de control de calidad se construyen a partir de casos históricos ya codificados, por lo que recompensan el hecho de coincidir con la etiqueta, sin detectar un criterio serio implícito enterrado en la narrativa. El error sólo sale a la luz cuando un inspector concilia los documentos originales con la base de datos de seguridad meses después, momento en el que el plazo ya expiró y la omisión es una infracción documentada en lugar de un casi error.

Error de expectativa frente a una instantánea de etiqueta incorrecta o un razonamiento predeterminado respecto a lo esperado

ICH E2D §2.4 requiere que cuando el titular no esté seguro de si se espera una reacción, ésta debe ser tratada como inesperada (a prueba de fallos para la reportabilidad). Un agente de LLM razona probabilísticamente y, en condiciones de incertidumbre, a menudo elegirá el resultado "esperado" más común (lo opuesto al incumplimiento regulatorio) o comparará la reacción con una versión de etiqueta obsoleta o de región incorrecta, convirtiendo un caso grave-inesperado reportable en uno grave-esperado no reportable.

Why it's hard to catch: El razonamiento parece competente: el agente cita un término de etiqueta real y una coincidencia plausible. Nada en los resultados indica que haya resuelto la incertidumbre en la dirección equivocada o que haya utilizado el RCP de ayer. La expectativa es un juicio sin clave de verdad fundamental, por lo que las pruebas de precisión no pueden calificarla; y debido a que el valor predeterminado regulatorio (incierto = inesperado) es el inverso del adelanto estadístico del modelo, el error es sistemático en lugar de aleatorio, por lo que verificar al azar algunos casos correctos da una confianza falsa.

La codificación errónea de MedDRA en el nivel incorrecto o en la versión incorrecta cambia la gravedad y la señal

El agente selecciona un término de MedDRA en el nivel de Término Preferido cuando se requería el LLT (según GVP Módulo VI/ICH M1), elige un LLT clínicamente adyacente pero incorrecto, o codifica una versión de MedDRA reemplazada después de un cambio de versión de MSSO. Una reacción codificada en un LLT benigno en lugar de uno médicamente importante puede quedar fuera de la evaluación de gravedad y de la detección de señales agregadas por completo.

Why it's hard to catch: El término codificado es una entrada válida de MedDRA, por lo que la validación del esquema y la aceptación de la puerta de enlace E2B(R3) se realizan sin problemas: el mensaje está bien formado y se reconoce. La incorrección clínica sólo es visible para un codificador capacitado que compara el término con el texto literal. A nivel agregado, el código erróneo sesga silenciosamente la detección de señales: los casos afectados nunca se agrupan bajo el término correcto, por lo que la señal de seguridad se suprime en lugar de señalarse.

Deriva del día 0: el agente fecha el reloj desde la ingesta del sistema, no desde el primer recibo

El agente marca el día 0 desde que el caso ingresó a la base de datos de seguridad (o cuando procesó el correo electrónico), pero el Módulo VI de GVP y el ICH E2D definen el Día 0 como la fecha en que el personal de la empresa recibió por primera vez los criterios mínimos, a menudo días antes, cuando un representante de ventas, una línea de información médica o un contratista lo escucharon por primera vez. La fecha posterior del agente consume silenciosamente parte de la ventana de 15 días y el elemento E2B(R3) C.1.4 'fecha de primera recepción de la fuente' se completa con el origen incorrecto.

Why it's hard to catch: Cada cálculo posterior es aritméticamente correcto con respecto a la fecha de inicio incorrecta, por lo que el caso aparece a tiempo en cada panel interno. La discrepancia solo existe en la brecha entre la fecha de contacto del documento fuente y la fecha de ingesta del sistema: datos que el agente a menudo nunca ve y las pruebas nunca inyectan. Un inspector que extrae el registro del canal de admisión original encuentra un día 0 anterior al del sistema en una semana, lo que retrasa retroactivamente los envíos "a tiempo".

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
Validez del caso: ¿existe un ICSR válido (cuatro criterios mínimos del Módulo VI de ICH E2D/GVP)?	Govern in Place: un punto de control KLA SDK envuelve el paso commit_case_validity del agente y envía un Decision Request a POST /v1/decisions.evaluate antes de que el agente marque el caso como válido o inválido, o lo dirija a la siguiente etapa. Los implementadores pueden ejecutar el mismo paso de forma centralizada mediante las puertas KLA y la API de ejecuciones.	PV.VALIDITY.MIN_CRITERIA_INCOMPLETE — warn si alguno de los cuatro criterios mínimos (notificador identificable, paciente identificable, reacción adversa, producto sospechoso) está ausente, adjuntando la obligación de seguimiento con diligencia debida PV.VALIDITY.AUTOCLOSE_AS_INVALID — block cualquier intento de cerrar definitivamente un caso como 'ICSR no válido' cuando está presente un criterio grave o un producto sospechoso, con solución: ruta a una persona calificada PV.VALIDITY.FOLLOWUP_REQUIRED — warn y etiquetar para seguimiento en lugar de cerrar cuando los criterios se cumplen parcialmente	block o require_approval dirige una escalada maker-checker al revisor de procesamiento de casos PV designado y, para el cierre automático de un caso potencialmente válido, a la persona cualificada para farmacovigilancia o al médico de seguridad de guardia, en Decision Desk. Esa persona aprueba, rechaza o redirige la decisión.	¿Cuáles de los cuatro criterios mínimos se detectaron o faltaron? la versión del paquete de políticas y los códigos de motivo devueltos el fundamento de validez del agente y los campos de origen Lineage Record ID que vincula el canal de admisión con esta decisión
Seriedad, expectativa y codificación MedDRA: la evaluación médica que establece el camino regulatorio	El punto de control KLA SDK de Govern in Place, en el paso assess_case del agente, envía un Decision Request a POST /v1/decisions.evaluate antes de escribir en el caso el resultado de gravedad, previsibilidad y codificación.	PV.SERIOUS.IMPLICIT_CRITERION — require_approval cuando la narrativa señala un criterio grave de ICH E2D (hospitalización, peligro para la vida, discapacidad, anomalía congénita, muerte, médicamente importante) pero el agente codificó el caso como no grave PV.EXPECTED.UNCERTAIN_DEFAULT — block una clasificación 'esperada/no reportable' tomada bajo incertidumbre marcada por el modelo; ICH E2D §2.4 requiere que el valor predeterminado sea inesperado, con remediación: tratar como inesperado pendiente de aprobación de QPPV PV.EXPECTED.LABEL_VERSION_STALE — warn si la etiqueta/instantánea SmPC utilizada no es la versión efectiva actual para la región del caso PV.MEDDRA.LEVEL_OR_VERSION — warn si una reacción está codificada por encima del nivel LLT o contra una versión no actual de MedDRA según la recomendación vinculante de MSSO	require_approval / block abre una escalada dirigida al revisor médico/médico de seguridad designado (maker-checker sobre la evaluación médica del agente); el QPPV es el objetivo de redireccionamiento para llamadas de expectativa impugnadas.	criterios de seriedad evaluados y el veredicto por criterio decisión de expectativa, identificación de la versión de la etiqueta y cualquier indicador de incertidumbre Versión MedDRA, LLT seleccionado y texto literal Códigos de razón y veredicto humano sobre la escalada.
Reportabilidad y reloj regulatorio: fijación del día 0 y la vía de 15 días versus 90 días	El punto de control Govern in Place SDK en el paso determine_reportability del agente envía un Decision Request a POST /v1/decisions.evaluate antes de que se le asigne un reloj al caso y se envíe para su envío o cierre.	PV.CLOCK.DAY0_SOURCE: block un día 0 derivado de la marca de tiempo de ingesta del sistema; Requerir la fecha de primer recibo más temprana de cualquier personal de la compañía según el Módulo VI VI.B.7 de GVP, con remediación: conciliar con la fecha de contacto del canal de admisión. PV.CLOCK.SERIOUS_UNEXPECTED_15D — require_approval para confirmar la ruta acelerada de 15 días calendario siempre que sea grave + inesperado PV.REPORTABILITY.AUTOCLOSE_NONREPORTABLE — block cierre automático de un caso grave como no reportable; ruta hacia humanos calificados PV.CLOCK.DEADLINE_AT_RISK — warn / escalar cuando el tiempo restante hasta el plazo de 15 días cae por debajo del buffer del SLA	require_approval abre un maker-checker Escalado al revisor de reportabilidad designado/Persona Calificada para Farmacovigilancia; tras la aprobación, la ejecución se reanuda exactamente donde se detuvo (idempotency_key garantiza que el envío se ejecute una vez); Al negarse, la ejecución finaliza sin escribir.	Día 0 calculado, su fecha de origen y el resultado de la conciliación la vía asignada (15 días acelerada versus 90 días no seria) y la fecha límite identidad del aprobador, significado de la firma, marca de tiempo Versión del paquete de políticas y códigos de motivo.
Escritura de terminal: envíe el ICSR como un mensaje E2B(R3) o cierre automáticamente el caso en el sistema de registro.	El punto de control del SDK Govern in Place envuelve la llamada a la herramienta submit_e2b / close_case; el Decision Request al POST /v1/decisions.evaluate es la última puerta antes de la escritura irreversible en la puerta de enlace o en la base de datos de seguridad.	PV.E2B.SCHEMA_AND_SUBSET: block un envío que no se ajusta al subconjunto E2B(R3) ICH de ISO/HL7 27953-2 (elementos obligatorios mal formados o faltantes, como C.1.4 fecha de primera recepción o gravedad E.i.3.2) PV.E2B.UNSIGNED_ASSESSMENT — block presentación de cualquier caso cuya gravedad/expectatividad/reportabilidad no estuviera firmada por humanos cuando la política así lo requería PV.CLOSE.WITHOUT_VERDICT — block cierre automático de un caso que carece de un veredicto de reportabilidad registrado y (cuando sea necesario) una aprobación humana PV.E2B.IDEMPOTENCY: allow con un idempotency_key para que un envío aprobado se transmita exactamente una vez	Los resultados block retienen la escritura y abren una escalada al revisor de envío designado/QPPV; ningún ICSR transmite y ningún caso se cierra hasta que el Escalado resuelva aprobarlo.	la carga útil exacta de E2B(R3) (o su hash), incluidos los elementos C.1.4 y E.i.3.2 el reconocimiento de la puerta de enlace / ID del mensaje el Lineage Record completo desde la admisión hasta la transmisión con todas las decisiones políticas y veredictos humanos adjuntos el Sealed Evidence Bundle / Control Pack que cubre este caso

Least-privilege execution & data boundaries

Validez del caso: ¿existe un ICSR válido (cuatro criterios mínimos del Módulo VI de ICH E2D/GVP)?: El Release del agente vincula solo las herramientas de lectura de la base de datos de seguridad y de etiqueta de caso en el Tool Catalog; no tiene ninguna herramienta submit_e2b o close_case en la etapa de validez, por lo que no puede deshacerse definitivamente de un caso aquí incluso si su razonamiento es erróneo.
Seriedad, expectativa y codificación MedDRA: la evaluación médica que establece el camino regulatorio: El Release vincula una versión fijada del diccionario MedDRA y el repositorio de etiquetas actual como las únicas fuentes de datos de codificación a través de Data Boundaries; el agente no puede acceder a una etiqueta arbitraria o almacenada en caché, y las herramientas de codificación son de solo lectura en el diccionario fijado.
Reportabilidad y reloj regulatorio: fijación del día 0 y la vía de 15 días versus 90 días: El paso de reportabilidad no está vinculado a una herramienta de envío a la red; solo después de que un humano lo apruebe, el Release muestra el paso de envío cerrado. La aprobación del ser humano se captura como una manifestación de firma electrónica 21 CFR 11.50 (nombre impreso, fecha/hora, significado = aprobación).
Escritura de terminal: envíe el ICSR como un mensaje E2B(R3) o cierre automáticamente el caso en el sistema de registro.: submit_e2b y close_case son las herramientas de mayor alcance en Tool Catalog, vinculadas solo en el Release activo del agente y emergieron solo después de que pasaron las puertas ascendentes; Data Boundaries mantiene la transmisión de la puerta de enlace dentro de la región aprobada.

Mapped to regulation

Regulatory mapping

Framework	Article / section	Obligation (plain language)	How a KLA runtime control satisfies it	Source
Módulo VI de EMA GVP (Rev 2) — EMA/873138/2011 Rev 2	VI.B.7 — Presentación de ICSR (día cero/inicio del reloj) y VI.B.7.1 (grave de 15 días; no grave de 90 días)	El reloj de presentación comienza (día 0) en el momento en que los criterios mínimos se comunican a CUALQUIER personal de la empresa, incluidos los representantes médicos y los contratistas, no cuando el departamento de seguridad los registra; Los ICSR serios válidos deben presentarse a más tardar 15 días naturales después de dicha recepción (inicial y de seguimiento), los no serios dentro de los 90 días.	El control de reportabilidad/reloj (runtime_controls[2]) bloquea un día 0 derivado del tiempo de ingesta del sistema (PV.CLOCK.DAY0_SOURCE), fuerza la conciliación con la fecha de primera recepción más temprana y require_approval confirma la ruta de 15 días siempre que sea grave o inesperado; la fecha límite y su cómputo están sellados en el Lineage Record.	Source
Módulo VI de EMA GVP (Rev 2) — EMA/873138/2011 Rev 2	VI.B.2 — Validación de ICSR (cuatro criterios mínimos)	Sólo se pueden presentar ICSR válidos; la validación requiere cuatro criterios mínimos (notificador identificable, un paciente identificable, sustancia/producto sospechoso, reacción adversa sospechada). La falta de algún elemento significa que el caso está incompleto y no califica para su presentación.	El control de validez del caso (runtime_controls[0]) advierte cuando falta alguno de los cuatro criterios (PV.VALIDITY.MIN_CRITERIA_INCOMPLETE) y bloquea el cierre automático del terminal como "no válido" cuando está presente un criterio grave o un producto sospechoso, dirigiéndose a un humano calificado en lugar de permitir que el agente se deshaga del caso.	Source
ICH E2D (Gestión de datos de seguridad posterior a la aprobación) + FDA 21 CFR 314.80	ICH E2D §2.3 (grave), §4.3 (reloj de 15 días / Día 0); 21 CFR 314.80(c)(1)(i) (informes de alerta de 15 días)	Un caso es grave si provoca la muerte, pone en peligro la vida, requiere/prolonga la hospitalización, causa una discapacidad persistente/significativa, es una anomalía congénita o es un evento médicamente importante, y la gravedad activa el reloj acelerado. Las reacciones graves e inesperadas deben informarse lo antes posible, pero a más tardar 15 días calendario desde la recepción inicial (el análogo estadounidense en 314.80 es idéntico).	El control de evaluación médica (runtime_controls[1]) require_approval-enruta cualquier caso donde la narrativa señala un criterio serio que el agente codificó como no serio (PV.SERIOUS.IMPLICIT_CRITERION); el control del reloj (runtime_controls[2]) confirma la ruta de 15 días para situaciones graves+inesperadas, por lo que el desencadenante y la fecha límite se aplican juntos en lugar de asumirse.	Source
Módulo VI de EMA GVP (Rev 2) — Contenido/formato de los ICSR electrónicos (MedDRA / ICH M1)	VI.C — Reacciones adversas codificadas con ICH M1 (MedDRA) a nivel LLT	Las reacciones adversas en los ICSR deben codificarse utilizando MedDRA (ICH M1) en el nivel de término de nivel más bajo, siguiendo la selección de términos de MedDRA: guía de puntos a considerar y las recomendaciones de la versión MSSO.	El control de codificación (runtime_controls[1], PV.MEDDRA.LEVEL_OR_VERSION) advierte cuando una reacción está codificada por encima de LLT o contra una versión de MedDRA no actual, y Data Boundaries fija el agente a una única versión de diccionario para que no pueda codificar contra una compilación de MedDRA obsoleta o arbitraria.	Source
ICH E2B(R3) — Transmisión electrónica de ICSR (EMA/CHMP/ICH/287/1995)	Estándar de mensajes (ISO/HL7 27953-2 'subconjunto ICH'); E.i.3.2 (gravedad a nivel de evento); C.1.4 (fecha en que el informe se recibió por primera vez de la fuente)	La transmisión electrónica ICSR debe cumplir con el estándar de mensajes E2B(R3) (un subconjunto ICH de ISO/HL7 27953-2), tener seriedad como criterio discreto por evento vinculado a las definiciones E2A/E2D y completar C.1.4 con la fecha en que se cumplieron por primera vez los cuatro criterios mínimos: el origen del reloj reglamentario.	El control de escritura de terminal (runtime_controls[3], PV.E2B.SCHEMA_AND_SUBSET) bloquea un envío que no se ajusta al subconjunto ICH u omite elementos C.1.4/E.i.3.2 obligatorios, y la carga útil exacta (o su hash), incluidos esos elementos, se sella en Lineage Record.	Source
FDA 21 CFR Parte 11 (Registros electrónicos; Firmas electrónicas)	11.10 (controles para sistemas cerrados; (a) validación; (e) pistas de auditoría seguras, generadas por computadora y con marca de tiempo)	Los sistemas cerrados que crean, modifican o transmiten registros electrónicos deben garantizar la autenticidad, la integridad y el no repudio, ser validados para discernir registros inválidos o alterados y mantener registros de auditoría seguros, generados por computadora y con marca de tiempo que registren de forma independiente quién cambió un registro y cuándo, sin ocultar nunca los datos anteriores, retenidos al menos durante tanto tiempo como el registro y disponibles para la revisión de la agencia.	El libro mayor Evidence-by-Default de KLA (capturado en todos los runtime_controls, sellado en runtime_controls[3]) agrupa cada control de seguridad, llamada de herramienta y veredicto humano en un libro mayor ImmuDB de solo anexado que produce Merkle pruebas: un registro de auditoría seguro, generado por computadora, con fecha y evidencia de manipulación, que un auditor verifica de forma independiente a través del Sealed Evidence Bundle sin confiar en KLA.	Source
FDA 21 CFR Parte 11 (Registros electrónicos; Firmas electrónicas)	11.50 — Manifestaciones de firmas	Los registros electrónicos firmados deben mostrar el nombre impreso del firmante, la fecha/hora de la firma y el significado de la firma (revisión, aprobación, responsabilidad, autoría), incluidos en cualquier formato legible por humanos.	Cuando el control de presentación o reportabilidad (runtime_controls[2], runtime_controls[3]) devuelve require_approval, el veredicto Decision Desk del aprobador nombrado se captura como una manifestación de firma de la Parte 11 (nombre impreso, marca de tiempo y significado=aprobación) y se sella en el Lineage Record junto con la acción que autorizó.	Source
Ley de IA de la UE (Reglamento (UE) 2024/1689)	Artículo 14(4)(d)-(e) — Supervisión humana (anular/revertir; detener a un estado seguro)	Las personas supervisoras deben poder decidir no utilizar, ignorar, anular o revertir la salida de un sistema de IA, e intervenir o interrumpirlo mediante un procedimiento de "detención" para llevarlo a un estado seguro. Citado como alineación de gobernanza transversal: NO es una afirmación de que el procesamiento de casos de PV sea de alto riesgo según el Anexo III (el Anexo III no enumera la farmacovigilancia; los regímenes vinculantes aquí son GVP/ICH/Parte 11).	Cada resultado de require_approval / block (runtime_controls[1]-[3]) es exactamente este estado de parada a seguridad: la ejecución del agente se detiene, no falla, y un humano designado puede aprobar, rechazar (anular/revertir) o redirigir la acción en Decision Desk antes de cualquier escritura irreversible.	Source
Ley de IA de la UE (Reglamento (UE) 2024/1689)	Artículo 12, apartado 1: Mantenimiento de registros (registro automático de eventos)	Los sistemas de IA deberían permitir técnicamente el registro automático de eventos durante toda la vida útil del sistema. Se cita como una alineación transversal que respalda el linaje de KLA; el régimen de registro vinculante para farmacovigilancia es 21 CFR 11.10(e).	KLA captura evidencia de forma predeterminada: cada llamada de herramienta, decisión de política y veredicto humano se registra automáticamente en el libro de registro de solo anexado durante la vida útil del agente (runtime_controls[0]-[3]), satisfaciendo al mismo tiempo el registro del Artículo 12 y el requisito más estricto de seguimiento de auditoría de la Parte 11.	Source

Prove the control held

Audit-evidence checklist

Procedencia de la ingesta: el canal original (espontáneo/literatura/solicitado/digital), la fecha de contacto del primer recibo utilizada para fijar el Día 0 y la conciliación con el tiempo de ingesta del sistema.
El resultado de detección de cuatro criterios mínimos (presente/faltante por elemento) en la puerta de validez
Veredicto de gravedad según el criterio ICH E2D, con el alcance narrativo que desencadenó cualquier escalada del criterio implícito
Decisión de expectativa con la etiqueta exacta/identificación de la versión del RCP y cualquier indicador de incertidumbre del modelo (que demuestre que se mantiene el valor predeterminado incierto=inesperado)
Versión de MedDRA, LLT seleccionados y el texto literal a partir del cual fueron codificados
La vía reglamentaria asignada (15 días acelerada versus 90 días no grave) y la fecha límite calculada
Cada decisión de política con su versión firmada del paquete de políticas y códigos de motivo (allow / warn / require_approval / block)
Cada veredicto humano como manifestación de firma 21 CFR 11.50: nombre impreso, fecha/hora, significado (revisión/aprobación), vinculado a la acción que autorizó
La carga útil E2B(R3) transmitida (o su hash) con elementos de fecha de primera recepción C.1.4 y gravedad E.i.3.2, más el reconocimiento de puerta de enlace/ID de mensaje.
El Lineage Record de solo agregar con una raíz Merkle que el auditor vuelve a calcular de forma independiente (GET /v1/lineage/{id}/verify), exportado como Sealed Evidence Bundle / Control Pack asignado a cláusulas GVP / Parte 11

A concrete intercept

Reference scenario: Un caso basado en literatura que el agente quiere cerrar automáticamente como no grave se mantiene para el QPPV

1
Ingesta: el agente ingiere un informe de caso publicado; están presentes un autor identificable (reportero), un solo paciente, un producto sospechoso y una reacción, por lo que se cumplen los cuatro criterios mínimos de ICH E2D y existe una ICSR válida.
2
Evaluación: la narrativa dice que el paciente 'estuvo ingresado dos días y fue dado de alta mejoró'; el agente codifica el evento como no grave (sin palabra clave explícitamente grave) y, sin estar seguro de lo esperado, se inclina por "esperado", dirigiéndose hacia el cierre automático como un caso no grave de 90 días.
3
Intercepción: antes de que se escriba el resultado assess_case, el punto de control del SDK Govern in Place envía un Decision Request a la política POST /v1/decisions.evaluate. coincidencias PV.SERIOUS.IMPLICIT_CRITERION (la narrativa indica hospitalización mientras el agente codifica como no grave) y coincidencias PV.EXPECTED.UNCERTAIN_DEFAULT (se espera elegido bajo incertidumbre marcada).
4
Resultado: la prioridad se resuelve en block en la llamada de expectativa y require_approval en la gravedad; la ejecución se detiene (la ejecución se detiene, no falla) y KLA abre una escalada.
5
Ruta: la escalada aterriza en Decision Desk frente al médico de seguridad designado, quien ve la narrativa palabra por palabra, la codificación del agente, los dos códigos de motivo, la versión de etiqueta utilizada y un enlace al Lineage Record. Recodifican el evento grave (hospitalización), establecen la expectativa como inesperada según ICH E2D §2.4 y aprueban la vía corregida grave-inesperada, registrando una firma 21 CFR 11.50 (nombre, marca de tiempo, significado = aprobación).
6
Reanudar y sellar: la aprobación reanuda la ejecución exactamente donde se detuvo (idempotency_key garantiza un envío único); el caso ahora pasa a la vía acelerada de 15 días con el día 0 fijado en la fecha de primera recepción de la literatura, y el seguimiento completo desde el ingreso hasta la decisión (razonamiento del agente, ambos códigos de motivo, corrección y firma del médico) se sella en el Lineage Record de solo anexado y se exporta como un Control Pack asignado al Módulo VI y Parte 11 de GVP.

What most teams get wrong

The non-obvious insight

El control que más amenaza el plazo es la evaluación de seriedad/expectativas, no el paso de presentación, y un agente de LLM lo falla de manera sistemática, invirtiendo la regulación. ICH E2D §2.4 dice que cuando las expectativas son inciertas, se debe usar por defecto lo inesperado (hacia la reportabilidad), pero un modelo de lenguaje bajo incertidumbre toma por defecto el resultado "esperado" estadísticamente más común. Por lo tanto, el error del agente no es un ruido aleatorio que se puede promediar con más casos de prueba; es un sesgo direccional que siempre va en contra de la reportabilidad, y golpea en el momento exacto que decide si alguna vez se abre el reloj de 15 días.

Why it matters: Los equipos instintivamente colocan la puerta más pesada en el paso de envío irreversible, pero para entonces el daño (un caso grave mal etiquetado como no grave y esperado) ya está asentado, y un envío limpio de la clasificación incorrecta parece perfectamente conforme. La gobernanza tiene que actuar antes, en la evaluación, y tiene que codificar el incumplimiento regulatorio como una regla de política estricta (block 'esperada' bajo incertidumbre marcada) precisamente porque el modelo anterior funciona de manera incorrecta. Esto también reformula 21 CFR Parte 11: el mismo Lineage Record que prueba que la pista de auditoría es lo que permite a un inspector ver la decisión equivocada original del agente y la corrección humana documentada: la corrección se convierte en evidencia de control, no en un defecto oculto.

Según ICH E2D §4.3 y 21 CFR 314.80(c)(1)(i), una reacción adversa grave e inesperada a un medicamento debe informarse a más tardar 15 días calendario desde la recepción inicial, y el Módulo VI de EMA GVP fija el día 0 en el momento en que cualquier personal de la empresa, incluido un representante de ventas o un contratista, recibe por primera vez los criterios mínimos, no cuando el departamento de seguridad registra el caso. La implicación relevante para la gobernanza: un agente de procesamiento de casos que fecha el Día 0 desde la ingesta del sistema llega estructuralmente tarde antes de procesar un solo campo, porque el reloj regulatorio ha estado corriendo desde que una persona escuchó el informe días antes. (source)

Q&A

Frequently asked questions

¿Regir a un agente de procesamiento de casos de farmacovigilancia significa que la Ley de IA de la UE lo clasifica como de alto riesgo?

No, y exagerar esto es un error común. El Anexo III de la Ley de IA de la UE no enumera la farmacovigilancia, por lo que el procesamiento de casos de PV no es automáticamente de alto riesgo del Anexo III (la IA de dispositivos médicos es una vía separada de evaluación de la conformidad del Anexo I). Los regímenes vinculantes para este flujo de trabajo son GVP, ICH E2D/E2B(R3) y 21 CFR Parte 11/GxP. El KLA todavía se alinea con los principios transversales de supervisión humana (Art. 14) y registro (Art. 12) de la Ley de IA porque son buena gobernanza, pero las obligaciones exigibles que satisfacen los controles son las de farmacovigilancia.

¿Por qué la pista de auditoría 21 CFR Parte 11 es una opción natural para el linaje KLA?

La Parte 11.10(e) requiere un registro de auditoría seguro, generado por computadora y con marca de tiempo que registre de forma independiente quién creó, modificó o eliminó un registro y cuándo, nunca oculte los datos anteriores y se conserve al menos mientras dure el registro. KLA captura cada control de seguridad, llamada de herramienta y veredicto humano de forma predeterminada y los agrupa en un libro mayor ImmuDB de solo anexado que produce pruebas Merkle. Es decir, casi línea por línea, una pista de auditoría de la Parte 11, y debido a que un auditor vuelve a calcular las pruebas por sí mismo, la integridad se mantiene sin confiar en el proveedor, lo que también exige el requisito de validación de 'discernir registros inválidos o alterados' de 11.10(a).

¿Cómo evita el KLA que el agente pierda el plazo acelerado de 15 días?

Dos controles funcionan juntos. El control de reportabilidad/reloj bloquea un Día 0 derivado del tiempo de ingesta del sistema y fuerza la conciliación con la fecha de primera recepción más temprana (según el Módulo VI VI.B.7 de GVP), de modo que el reloj comienza donde el regulador dice que comienza. Luego, require_approval, confirma la vía acelerada de 15 días calendario cada vez que un caso es grave e inesperado, y advierte o intensifica cuando el tiempo restante cae por debajo del buffer del SLA. La fecha límite, la fecha de origen y la conciliación están selladas en el Lineage Record como evidencia.

¿Puede el agente cerrar automáticamente un caso no reportable sin un humano?

Sólo dentro de una política estrictamente delimitada. KLA bloquea el cierre automático de un caso grave como no reportable y bloquea el cierre terminal de un caso como "ICSR no válido" cuando está presente un criterio grave o un producto sospechoso; ambos encaminan una escalada maker-checker a una persona calificada designada. Los casos genuinamente no válidos o claramente no reportables pueden cerrarse bajo allow con el veredicto y la justificación registrados, pero la herramienta close_case está vinculada al Release del agente y aparece solo después de que pasan las puertas de validez y reportabilidad, por lo que el agente no puede deshacerse de un caso del que no tiene autoridad para deshacerse.

¿Quién aprueba realmente una decisión de PV retenida y cómo se captura para una inspección?

La ruta se declara en la política, por lo que una escalada llega al propietario designado de ese riesgo, generalmente un revisor de procesamiento de casos de PV, un revisor médico/médico de seguridad para llamadas de evaluación, o la persona calificada para farmacovigilancia para reportabilidad impugnada. Aprueban, rechazan o redirigen en Decision Desk. Cada veredicto se captura como una manifestación de firma 21 CFR 11.50 (nombre impreso, fecha y hora, y el significado (revisión/aprobación)) vinculada a la acción exacta que autorizó y sellada en el Lineage Record, dando una respuesta defendible a la pregunta del inspector "quién aprobó esto, sobre qué base y cuándo".

¿Cómo previene KLA los envíos E2B(R3) con formato incorrecto o con un origen de reloj incorrecto?

El control de escritura del terminal es la última puerta antes de la transmisión irreversible. Bloquea cualquier envío que no se ajuste al subconjunto E2B(R3) ICH de ISO/HL7 27953-2 u omite elementos obligatorios como C.1.4 (informe de fecha recibido por primera vez de la fuente: el origen del reloj) o E.i.3.2 (criterios de gravedad a nivel de evento). También bloquea la presentación de un caso cuya gravedad/expectatividad/reportabilidad no estaba firmada por humanos cuando la política así lo requería, y lleva un idempotency_key para que un mensaje aprobado se transmita exactamente una vez. La carga útil o su hash, con C.1.4 y E.i.3.2, se sella en el registro de pruebas.

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