Pourquoi la piste d'audit du 21 CFR Part 11 correspond-elle naturellement au traçabilité KLA ?

Le Part 11.10(e) exige une piste d'audit sécurisée, générée par ordinateur et horodatée, qui enregistre de manière indépendante qui a créé, modifié ou supprimé un enregistrement et quand, ne masque jamais les données antérieures et est conservée au moins aussi longtemps que l'enregistrement. KLA capture par défaut chaque contrôle de sécurité, appel d'outil et verdict humain, puis les hache dans un registre ImmuDB en ajout seul qui produit des preuves de Merkle — presque ligne pour ligne une piste d'audit Part 11 qu'un auditeur vérifie sans faire confiance au fournisseur, ce qu'exige aussi l'obligation du 11.10(a) de « discerner les enregistrements invalides ou altérés ».

Comment KLA empêche-t-il l'agent de manquer le délai de déclaration accélérée de 15 jours ?

Le contrôle de déclarabilité/horloge bloque un Jour 0 dérivé de l'heure d'ingestion système et impose une réconciliation avec la date de première réception la plus ancienne conformément au GVP Module VI VI.B.7, puis confirme via require_approval la voie accélérée de 15 jours calendaires dès qu'un cas est grave et inattendu, et escalade lorsque le temps restant passe sous la marge de SLA. L'échéance, sa date source et la réconciliation sont scellées dans le Lineage Record.

Comment KLA empêche-t-il les soumissions E2B(R3) malformées ou portant une mauvaise origine d'horloge ?

Le contrôle d'écriture terminale bloque toute soumission non conforme au sous-ensemble ICH E2B(R3) de la norme ISO/HL7 27953-2 ou omettant des éléments obligatoires tels que C.1.4 (date de première réception — l'origine de l'horloge) ou E.i.3.2 (gravité au niveau de l'événement), bloque la soumission d'un cas dont l'évaluation n'a pas été signée par un humain lorsque cela est requis, et porte une idempotency_key afin qu'un message approuvé soit transmis exactement une fois. La charge utile ou son hachage est scellé dans l'enregistrement de preuve.

Pharmacovigilance

traitement des cas d'événements indésirables

Gouverner un agent de réception des événements indésirables et de traitement des cas en pharmacovigilance

13 min · Updated 2026-06-02

Answer

Vous gouvernez un agent de traitement des cas de pharmacovigilance en interceptant ses décisions à fort enjeu avant qu'elles ne soient validées — validité du cas, gravité/caractère attendu, codage MedDRA, horloge du Jour 0, et toute soumission d'ICSR ou clôture automatique — grâce à une barrière de politique qui renvoie allow, warn, require_approval ou block, achemine les décisions de caractère déclarable et de clôture automatique vers une personne qualifiée désignée via une Escalation de type maker-checker, et scelle un Lineage Record vérifiable par cryptographie qui tient lieu de piste d'audit au sens du 21 CFR Part 11. KLA ne construit pas votre agent de PV ; KLA gouverne l'agent que vous avez construit et produit les preuves GVP/ICH/Part 11 à chaque exécution.

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 agent de traitement des cas de pharmacovigilance (PV) ingère des notifications d'événements indésirables provenant des canaux spontanés, de la littérature, des canaux sollicités et des canaux numériques, puis conduit un cas réglementé jusqu'à une décision réglementaire. Ses points de décision à fort enjeu sont : (1) la validité du cas — déterminer si les quatre critères minimaux de l'ICH E2D (un notificateur identifiable, un patient identifiable, un effet indésirable, un produit suspect) sont réunis, ce qui détermine si un ICSR valide existe seulement ; (2) le codage MedDRA — sélectionner les termes de plus bas niveau (Lowest Level Terms, LLT) conformément à l'ICH M1 pour les effets, les indications et les antécédents médicaux ; (3) l'évaluation de la gravité — classer l'événement au regard des six critères de gravité de l'ICH E2D (décès, mise en jeu du pronostic vital, hospitalisation/prolongation d'hospitalisation, incapacité persistante/significative, anomalie congénitale, événement médicalement important) ; (4) le caractère attendu — comparer l'effet à l'étiquetage local/au RCP (SmPC) ; (5) l'imputabilité et le caractère déclarable — décider que le cas est déclarable et quelle horloge réglementaire s'applique ; (6) l'horloge réglementaire — fixer le Jour 0, date à laquelle un membre quelconque du personnel de l'entreprise a reçu pour la première fois un cas répondant aux critères minimaux et aux critères de déclaration accélérée ; et (7) l'écriture finale — rédiger et soumettre un ICSR sous forme de message E2B(R3), ou clôturer automatiquement un cas comme non valide/non déclarable. Les points de décision 5, 6 et 7 sont ceux où l'agent peut déclencher une soumission réglementaire, manquer un délai ou clôturer silencieusement un cas déclarable dans la base de données de pharmacovigilance (le système de référence).

Stakes

Why it's high-stakes

Un effet indésirable médicamenteux grave et inattendu doit être déclaré dès que possible et au plus tard 15 jours calendaires après la réception initiale, tant en vertu de l'ICH E2D §4.3 que du 21 CFR 314.80(c)(1)(i) ; l'horloge du GVP Module VI de l'EMA démarre au Jour 0, c'est-à-dire au moment où un membre quelconque du personnel de l'entreprise — y compris un délégué commercial ou un sous-traitant — reçoit les critères minimaux, et non au moment où le service de pharmacovigilance enregistre le cas. Si l'agent code à tort un événement grave comme non grave, juge « attendu » un effet incertain, ou clôture automatiquement un cas qui aurait dû être déclarable, l'horloge de 15 jours soit ne démarre jamais, soit expire sans avoir été respectée. La défaillance reste invisible jusqu'à une inspection : il n'y a aucune soumission à retrouver, aucune alerte, seulement un cas qui s'est clôturé discrètement. Les déclarations accélérées tardives ou manquantes constituent une constatation majeure lors des inspections de pharmacovigilance de l'EMA et de la FDA et peuvent déclencher une action réglementaire à l'encontre de l'autorisation de mise sur le marché. La conséquence pour la sécurité des patients — un signal réel de préjudice qui ne parvient jamais au régulateur — aggrave l'exposition au risque de non-conformité.

What goes wrong

Failure modes specific to this agent

Un déclassement silencieux de la gravité ferme l'horloge accélérée avant même qu'elle ne démarre

L'agent lit un récit en texte libre (« le patient a été gardé une nuit en observation et s'est rétabli ») et code l'événement comme non grave parce qu'aucun mot-clé explicite de gravité n'apparaît, sans relever que l'hospitalisation est en elle-même un critère de gravité de l'ICH E2D. Comme la gravité déclenche l'horloge accélérée de 15 jours, une classification non grave signifie que l'agent n'ouvre jamais la voie accélérée — le cas est orienté vers la file non grave à 90 jours ou est clôturé, et le Jour 0 est de fait abandonné.

Why it's hard to catch: Il n'y a ni erreur ni alerte — l'agent a produit un cas syntaxiquement valide et cohérent en interne, assorti d'une justification d'apparence défendable. Les jeux de tests d'assurance qualité sont construits à partir de cas historiques déjà codés ; ils récompensent donc la concordance avec le codage de référence, et non la détection d'un critère de gravité implicite enfoui dans le récit. L'omission ne fait surface que lorsqu'un inspecteur rapproche les documents sources de la base de données de pharmacovigilance des mois plus tard, moment auquel le délai est expiré depuis longtemps et où l'omission constitue un manquement documenté plutôt qu'un quasi-incident.

Mauvaise évaluation du caractère attendu fondée sur une mauvaise version de l'étiquetage ou sur un raisonnement qui présume l'effet attendu par défaut

L'ICH E2D §2.4 exige que, lorsque le titulaire n'est pas certain qu'un effet est attendu, celui-ci soit traité comme inattendu (sécurité par défaut en faveur de la déclaration). Un agent LLM raisonne de manière probabiliste et, en situation d'incertitude, retiendra souvent l'issue la plus fréquente, « attendu » — l'inverse du comportement réglementaire par défaut — ou comparera l'effet à une version de l'étiquetage obsolète ou relevant d'une autre région, transformant un cas grave-inattendu déclarable en un cas grave-attendu non déclarable.

Why it's hard to catch: Le raisonnement paraît compétent : l'agent cite un terme réel de l'étiquetage et une correspondance plausible. Rien dans le résultat ne signale qu'il a tranché l'incertitude dans le mauvais sens ou qu'il a utilisé le RCP (SmPC) de la veille. Le caractère attendu est un jugement sans clé de vérité terrain, de sorte que les tests d'exactitude ne peuvent pas le noter ; et comme la règle réglementaire par défaut (incertain = inattendu) est l'inverse de l'a priori statistique du modèle, l'erreur est systématique plutôt qu'aléatoire, si bien qu'un contrôle ponctuel de quelques cas corrects donne une fausse assurance.

Un codage MedDRA erroné au mauvais niveau ou dans la mauvaise version modifie la gravité et le signal

L'agent sélectionne un terme MedDRA au niveau du terme préférentiel (PT) alors que le LLT était requis (selon GVP Module VI / ICH M1), choisit un LLT cliniquement voisin mais erroné, ou code selon une version MedDRA remplacée après un changement de version MSSO. Une réaction codée sous un LLT bénin au lieu du terme médicalement important peut disparaître de l'évaluation de la gravité et sortir entièrement de la détection agrégée des signaux.

Why it's hard to catch: Le terme codé est une entrée MedDRA valide, de sorte que la validation du schéma et l'acceptation par la passerelle E2B(R3) passent sans encombre — le message est bien formé et reçoit un accusé de réception. L'erreur clinique n'est visible que pour un codeur formé qui compare le terme au texte verbatim du notificateur. Au niveau agrégé, le mauvais codage biaise silencieusement la détection des signaux : les cas concernés ne se regroupent jamais sous le terme correct, si bien que le signal de sécurité est étouffé au lieu d'être signalé.

Dérive du jour 0 : l'agent fait partir le compteur de l'ingestion système et non de la première réception

L'agent horodate le jour 0 à l'entrée du cas dans la base de données de sécurité (ou au moment où il a traité l'e-mail), alors que GVP Module VI et ICH E2D définissent le jour 0 comme la date à laquelle un membre quelconque du personnel de l'entreprise a reçu pour la première fois les critères minimaux — souvent plusieurs jours plus tôt, lorsqu'un délégué commercial, le service d'information médicale ou un sous-traitant en a eu connaissance en premier. La date plus tardive retenue par l'agent consomme silencieusement une partie du délai de 15 jours, et l'élément E2B(R3) C.1.4 « date de première réception de la source » est renseigné avec une origine erronée.

Why it's hard to catch: Chaque calcul en aval est arithmétiquement correct par rapport à la mauvaise date de départ, de sorte que le cas paraît dans les délais sur tous les tableaux de bord internes. L'écart n'existe que dans l'intervalle entre la date de contact figurant dans le document source et la date d'ingestion par le système — des données que l'agent ne voit souvent jamais et que les tests n'injectent jamais. Un inspecteur qui consulte l'enregistrement d'origine du canal de réception trouve un jour 0 antérieur d'une semaine à celui du système, ce qui rend rétroactivement tardives des soumissions 'dans les délais'.

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é du cas — un ICSR valide existe-t-il (les quatre critères minimaux ICH E2D / GVP Module VI) ?	Govern in Place : un point de contrôle du SDK KLA encadre l'étape commit_case_validity de l'agent et soumet une Decision Request à POST /v1/decisions.evaluate avant que l'agent ne marque le cas valide/invalide ou ne le transmette plus loin. Les déployeurs qui passent par KLA contrôlent la même étape de façon centralisée via l'Executions API.	PV.VALIDITY.MIN_CRITERIA_INCOMPLETE — avertir si l'un des quatre critères minimaux (notificateur identifiable, patient identifiable, effet indésirable, produit suspect) est absent, en joignant l'obligation de suivi de diligence raisonnable PV.VALIDITY.AUTOCLOSE_AS_INVALID — bloquer toute tentative de clôture définitive d'un cas comme 'ICSR non valide' lorsqu'un critère de gravité ou un produit suspect est présent, avec remédiation : acheminer vers une personne qualifiée PV.VALIDITY.FOLLOWUP_REQUIRED — avertir et marquer pour suivi au lieu de clôturer lorsque les critères ne sont que partiellement remplis	block / require_approval achemine une Escalation maker-checker vers le réviseur désigné du traitement des cas de PV (et, pour la clôture automatique d'un cas potentiellement valide, vers la personne qualifiée responsable de la pharmacovigilance / le médecin de sécurité d'astreinte) dans Decision Desk, qui approuve, refuse ou réachemine.	quels critères minimaux parmi les quatre ont été détectés et lesquels manquaient la version du pack de politiques et les codes de motif renvoyés la justification de validité de l'agent et les champs sources id du Lineage Record reliant le canal de réception à cette décision
Gravité, caractère attendu et codage MedDRA — l'évaluation médicale qui détermine la voie réglementaire	Le point de contrôle du SDK Govern in Place sur l'étape assess_case de l'agent soumet une Decision Request à POST /v1/decisions.evaluate avant que le résultat gravité/caractère attendu/codage ne soit écrit dans le cas.	PV.SERIOUS.IMPLICIT_CRITERION — require_approval lorsque la narration signale un critère de gravité ICH E2D (hospitalisation, mise en jeu du pronostic vital, invalidité, anomalie congénitale, décès, importance médicale) mais que l'agent a codé le cas comme non grave PV.EXPECTED.UNCERTAIN_DEFAULT — block une classification « attendu / non notifiable » prise sous une incertitude signalée par le modèle ; l'ICH E2D §2.4 impose de retenir par défaut le caractère inattendu, avec remédiation : traiter comme inattendu dans l'attente de la validation du QPPV PV.EXPECTED.LABEL_VERSION_STALE — warn si l'instantané de l'étiquetage/RCP utilisé n'est pas la version en vigueur pour la région du cas PV.MEDDRA.LEVEL_OR_VERSION — warn si une réaction est codée à un niveau supérieur au LLT ou selon une version MedDRA non courante au regard de la recommandation MSSO liée	require_approval / block ouvre une Escalation acheminée vers le réviseur médical / médecin de pharmacovigilance désigné (contrôle maker-checker de l'évaluation médicale de l'agent) ; le QPPV est la cible de réacheminement pour les décisions de caractère attendu contestées.	critères de gravité évalués et verdict par critère décision sur le caractère attendu, id de version de l'étiquetage et tout indicateur d'incertitude version MedDRA, LLT sélectionné et texte verbatim du notificateur codes de motif et verdict humain sur l'Escalation
Déclarabilité et horloge réglementaire — fixer le Jour 0 et la voie à 15 jours vs 90 jours	Le point de contrôle du Govern in Place SDK sur l'étape determine_reportability de l'agent soumet une Decision Request à POST /v1/decisions.evaluate avant que le cas ne se voie attribuer une horloge et ne soit acheminé vers la soumission ou la clôture.	PV.CLOCK.DAY0_SOURCE — bloquer un Jour 0 dérivé de l'horodatage d'ingestion système ; exiger la date de première réception la plus précoce par tout membre du personnel de l'entreprise conformément au GVP Module VI VI.B.7, avec remédiation : rapprocher de la date de contact du canal de réception PV.CLOCK.SERIOUS_UNEXPECTED_15D — require_approval pour confirmer la voie accélérée de 15 jours calendaires dès lors que grave + inattendu est vrai PV.REPORTABILITY.AUTOCLOSE_NONREPORTABLE — bloquer la clôture automatique d'un cas grave comme non déclarable ; acheminer vers un humain qualifié PV.CLOCK.DEADLINE_AT_RISK — avertir / escalader lorsque le temps restant avant l'échéance de 15 jours passe sous la marge de SLA	require_approval ouvre une Escalation maker-checker vers le réviseur de déclarabilité désigné / la personne qualifiée responsable en matière de pharmacovigilance ; en cas d'approbation, l'exécution reprend exactement là où elle s'était arrêtée (l'idempotency_key garantit que la soumission ne s'exécute qu'une seule fois) ; en cas de refus, l'exécution se termine sans écriture.	le Jour 0 calculé, sa date source et le résultat du rapprochement la voie attribuée (accélérée de 15 jours vs non grave de 90 jours) et l'échéance identité de l'approbateur, signification de la signature, horodatage version du pack de politiques et codes de motif
Écriture terminale — soumettre l'ICSR sous forme de message E2B(R3), ou clôturer automatiquement le cas dans le système de référence	Le point de contrôle du Govern in Place SDK enveloppe l'appel d'outil submit_e2b / close_case ; la Decision Request adressée à POST /v1/decisions.evaluate est la dernière barrière avant l'écriture irréversible vers la passerelle ou la base de données de sécurité.	PV.E2B.SCHEMA_AND_SUBSET — bloque une soumission non conforme au sous-ensemble ICH E2B(R3) de l'ISO/HL7 27953-2 (éléments obligatoires mal formés ou manquants, tels que C.1.4 date de première réception ou E.i.3.2 gravité) PV.E2B.UNSIGNED_ASSESSMENT — bloque la soumission de tout cas dont la gravité/le caractère attendu/la notifiabilité n'a pas fait l'objet d'une signature humaine là où la politique l'exigeait PV.CLOSE.WITHOUT_VERDICT — bloque la clôture automatique d'un cas dépourvu d'un verdict de notifiabilité enregistré et (lorsque requis) d'une validation humaine PV.E2B.IDEMPOTENCY — autorise avec une idempotency_key afin qu'une soumission approuvée soit transmise exactement une fois	les décisions block suspendent l'écriture et ouvrent une Escalation vers le relecteur de soumission désigné / la QPPV ; aucun ICSR n'est transmis et aucun cas n'est clôturé tant que l'Escalation n'aboutit pas à une approbation.	la charge utile E2B(R3) exacte (ou son hachage), y compris les éléments C.1.4 et E.i.3.2 l'accusé de réception de la passerelle / l'identifiant de message le Lineage Record complet, de la réception à la transmission, avec toutes les décisions de politique et tous les verdicts humains attachés le Sealed Evidence Bundle / Control Pack couvrant ce cas

Least-privilege execution & data boundaries

Validité du cas — un ICSR valide existe-t-il (les quatre critères minimaux ICH E2D / GVP Module VI) ?: La Release de l'agent ne lie que les outils de lecture de la base de données de sécurité et d'étiquetage des cas du Tool Catalog ; l'agent n'a aucun outil submit_e2b ni close_case à l'étape de validité et ne peut donc pas clôturer définitivement un cas ici, même si son raisonnement se trompe.
Gravité, caractère attendu et codage MedDRA — l'évaluation médicale qui détermine la voie réglementaire: La Release lie une version épinglée du dictionnaire MedDRA et le référentiel d'étiquetage courant comme seules sources de données de codage via les Data Boundaries ; l'agent ne peut pas accéder à un étiquetage arbitraire ou mis en cache, et les outils de codage sont en lecture seule sur le dictionnaire épinglé.
Déclarabilité et horloge réglementaire — fixer le Jour 0 et la voie à 15 jours vs 90 jours: L'étape de déclarabilité n'a aucun outil de soumission réseau lié ; ce n'est qu'après l'approbation d'un humain que la Release expose l'étape de soumission sous contrôle. La validation de l'humain est capturée comme une manifestation de signature électronique au sens du 21 CFR 11.50 (nom imprimé, date/heure, signification = approbation).
Écriture terminale — soumettre l'ICSR sous forme de message E2B(R3), ou clôturer automatiquement le cas dans le système de référence: submit_e2b et close_case sont les outils au périmètre le plus restreint du Tool Catalog, liés uniquement dans la Release active de l'agent et exposés seulement une fois les contrôles amont franchis ; les Data Boundaries maintiennent la transmission vers la passerelle dans la région approuvée.

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 — Soumission des ICSR (jour zéro / démarrage du délai) et VI.B.7.1 (15 jours pour les cas graves ; 90 jours pour les cas non graves)	Le délai de soumission démarre (Jour 0) dès que les critères minimaux sont portés à la connaissance de TOUT membre du personnel de l'entreprise — y compris les visiteurs médicaux et les sous-traitants — et non lorsque le service de pharmacovigilance l'enregistre ; les ICSR valides graves doivent être soumis au plus tard 15 jours calendaires après cette réception (initiaux et de suivi), les non graves dans les 90 jours.	Le contrôle de notifiabilité/délai (runtime_controls[2]) bloque un Jour 0 dérivé de l'heure d'ingestion système (PV.CLOCK.DAY0_SOURCE), force le rapprochement avec la date de première réception la plus ancienne et confirme par require_approval la voie des 15 jours dès que le cas est grave+inattendu ; l'échéance et son calcul sont scellés dans le Lineage Record.	Source
EMA GVP Module VI (Rev 2) — EMA/873138/2011 Rev 2	VI.B.2 — Validation des ICSR (quatre critères minimaux)	Seuls les ICSR valides peuvent être soumis ; la validation exige quatre critères minimaux (un notificateur identifiable, un patient identifiable, une substance/un produit suspect, un effet indésirable suspecté). L'absence de l'un de ces éléments signifie que le cas est incomplet et ne peut pas être soumis.	Le contrôle de validité du cas (runtime_controls[0]) émet un avertissement lorsque l'un des quatre critères manque (PV.VALIDITY.MIN_CRITERIA_INCOMPLETE) et bloque la clôture automatique définitive en « invalide » lorsqu'un critère de gravité ou un produit suspect est présent, en routant le cas vers un humain qualifié plutôt que de laisser l'agent en disposer.	Source
ICH E2D (Gestion des données de sécurité post-autorisation) + FDA 21 CFR 314.80	ICH E2D §2.3 (gravité), §4.3 (délai de 15 jours / Jour 0) ; 21 CFR 314.80(c)(1)(i) (rapports d'alerte à 15 jours)	Un cas est grave s'il entraîne le décès, met en jeu le pronostic vital, nécessite ou prolonge une hospitalisation, provoque une invalidité persistante ou significative, constitue une anomalie congénitale ou un événement médicalement important — et la gravité déclenche le délai de déclaration accéléré. Les effets graves et inattendus doivent être déclarés dès que possible et au plus tard 15 jours calendaires après la réception initiale (l'équivalent américain dans 314.80 est identique).	Le contrôle d'évaluation médicale (runtime_controls[1]) route en require_approval tout cas dont le narratif signale un critère de gravité que l'agent a codé comme non grave (PV.SERIOUS.IMPLICIT_CRITERION) ; le contrôle de délai (runtime_controls[2]) confirme la voie à 15 jours pour les cas graves et inattendus, de sorte que le déclencheur et l'échéance sont appliqués ensemble plutôt que présumés.	Source
EMA GVP Module VI (Rev 2) — Contenu/format des ICSR électroniques (MedDRA / ICH M1)	VI.C — Effets indésirables codés avec ICH M1 (MedDRA) au niveau LLT	Les effets indésirables des ICSR doivent être codés avec MedDRA (ICH M1) au niveau du terme de plus bas niveau (Lowest Level Term), conformément au guide MedDRA Term Selection: Points to Consider et aux recommandations de version du MSSO.	Le contrôle de codage (runtime_controls[1], PV.MEDDRA.LEVEL_OR_VERSION) émet un avertissement lorsqu'un effet est codé au-dessus du niveau LLT ou avec une version MedDRA non courante, et les Data Boundaries fixent l'agent à une seule version du dictionnaire afin qu'il ne puisse pas coder avec une version MedDRA obsolète ou arbitraire.	Source
ICH E2B(R3) — Transmission électronique des ICSR (EMA/CHMP/ICH/287/1995)	Norme de message (ISO/HL7 27953-2 « sous-ensemble ICH ») ; E.i.3.2 (gravité au niveau de l'événement) ; C.1.4 (date de première réception du rapport de la source)	La transmission électronique des ICSR doit être conforme à la norme de message E2B(R3) (un sous-ensemble ICH de la norme ISO/HL7 27953-2), porter la gravité sous forme de critères distincts par événement rattachés aux définitions E2A/E2D, et renseigner C.1.4 avec la date à laquelle les quatre critères minimaux ont été réunis pour la première fois — l'origine de l'horloge réglementaire.	Le contrôle d'écriture terminale (runtime_controls[3], PV.E2B.SCHEMA_AND_SUBSET) bloque toute soumission non conforme au sous-ensemble ICH ou omettant les éléments obligatoires C.1.4 / E.i.3.2, et la charge utile exacte (ou son empreinte) incluant ces éléments est scellée dans le Lineage Record.	Source
FDA 21 CFR Part 11 (enregistrements électroniques ; signatures électroniques)	11.10 (contrôles applicables aux systèmes fermés ; (a) validation ; (e) pistes d'audit sécurisées, générées par ordinateur et horodatées)	Les systèmes fermés qui créent, modifient ou transmettent des enregistrements électroniques doivent garantir l'authenticité, l'intégrité et la non-répudiation, être validés de façon à détecter les enregistrements invalides ou altérés, et conserver des pistes d'audit sécurisées, générées par ordinateur et horodatées qui consignent de manière indépendante qui a modifié un enregistrement et quand, sans jamais masquer les données antérieures, conservées au moins aussi longtemps que l'enregistrement et disponibles pour examen par l'agence.	Le registre Evidence-by-Default de KLA (capturé sur l'ensemble des runtime_controls, scellé à runtime_controls[3]) hache chaque contrôle de sécurité, chaque appel d'outil et chaque verdict humain dans un registre ImmuDB en ajout seul produisant des preuves de Merkle — une piste d'audit sécurisée, générée par ordinateur, horodatée et dont toute altération est détectable, qu'un auditeur vérifie de manière indépendante via le Sealed Evidence Bundle sans avoir à faire confiance à KLA.	Source
FDA 21 CFR Part 11 (enregistrements électroniques ; signatures électroniques)	11.50 — Manifestations de la signature	Les enregistrements électroniques signés doivent faire apparaître le nom imprimé du signataire, la date et l'heure de la signature et la signification de la signature (revue, approbation, responsabilité, paternité), incluses dans toute forme lisible par l'humain.	Lorsque le contrôle de déclarabilité ou de soumission (runtime_controls[2], runtime_controls[3]) renvoie require_approval, le verdict rendu dans Decision Desk par l'approbateur nommé est capturé comme manifestation de signature au sens de la Part 11 — nom imprimé, horodatage et meaning=approval — et scellé dans le Lineage Record aux côtés de l'action qu'il a autorisée.	Source
Règlement européen sur l'IA (règlement (UE) 2024/1689)	Article 14(4)(d)-(e) — Contrôle humain (passer outre/inverser ; arrêt dans un état sûr)	Les personnes chargées du contrôle doivent pouvoir décider de ne pas utiliser, d'ignorer, de passer outre ou d'inverser le résultat d'un système d'IA, et d'intervenir ou de l'interrompre au moyen d'une procédure d'« arrêt » l'amenant dans un état sûr. Cité au titre d'un alignement de gouvernance transversal — et NON comme une affirmation selon laquelle le traitement des cas de PV relève du haut risque au sens de l'annexe III (l'annexe III n'énumère pas la pharmacovigilance ; les régimes contraignants ici sont les GVP/ICH/Part 11).	Chaque résultat require_approval / block (runtime_controls[1]-[3]) correspond exactement à cet arrêt dans un état sûr : l'exécution de l'agent est mise en attente, sans être mise en échec, et un humain nommément désigné peut approuver, refuser (passer outre/inverser) ou réacheminer l'action dans Decision Desk avant toute écriture irréversible.	Source
EU AI Act (règlement (UE) 2024/1689)	Article 12(1) — Tenue de registres (enregistrement automatique des événements)	Les systèmes d'IA doivent permettre techniquement l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système. Cité au titre d'un alignement transversal que le traçabilité KLA satisfait ; le régime de journalisation contraignant pour la PV est 21 CFR 11.10(e).	KLA capture les preuves par défaut — chaque appel d'outil, décision de politique et verdict humain est consigné automatiquement dans le registre en ajout seul tout au long de la durée de vie de l'agent (runtime_controls[0]-[3]), ce qui satisfait à la fois l'exigence de journalisation de l'article 12 et l'exigence plus stricte de piste d'audit de la Part 11.	Source

Prove the control held

Audit-evidence checklist

Provenance de la réception : le canal d'origine (spontané / littérature / sollicité / numérique), la date de premier contact/réception utilisée pour fixer le Jour 0, et le rapprochement avec l'heure d'ingestion dans le système
Le résultat de détection des quatre critères minimaux (présent/manquant pour chaque élément) au point de contrôle de validité
Le verdict de gravité pour chaque critère ICH E2D, avec le passage du narratif ayant déclenché toute escalade au titre d'un critère implicite
La décision sur le caractère attendu avec l'identifiant exact de version de l'étiquetage/du RCP (SmPC) et tout indicateur d'incertitude du modèle (prouvant que la règle par défaut uncertain=unexpected a bien été appliquée)
La version MedDRA, le(s) LLT sélectionné(s) et le texte verbatim du notificateur à partir duquel ils ont été codés
La voie réglementaire attribuée (déclaration accélérée à 15 jours vs non grave à 90 jours) et l'échéance calculée
Chaque décision de politique avec sa version signée du pack de politiques et ses codes de motif (allow / warn / require_approval / block)
Chaque verdict humain sous forme de manifestation de signature au titre du 21 CFR 11.50 : nom imprimé, date/heure, signification (revue/approbation), lié à l'action qu'il a autorisée
La charge utile E2B(R3) transmise (ou son hachage) avec les éléments C.1.4 (date de première réception) et E.i.3.2 (gravité), ainsi que l'accusé de réception de la passerelle / l'identifiant de message
Le Lineage Record en ajout seul avec une racine de Merkle que l'auditeur recalcule de façon indépendante (GET /v1/lineage/{id}/verify), exporté sous forme de Sealed Evidence Bundle / Control Pack mis en correspondance avec les clauses GVP / Part 11

A concrete intercept

Reference scenario: Un cas issu de la littérature que l'agent veut clôturer automatiquement comme non grave est retenu pour la QPPV

1
Réception : l'agent ingère un rapport de cas publié ; un auteur identifiable (notificateur), un patient unique, un produit suspect et une réaction sont présents, de sorte que les quatre critères minimaux ICH E2D sont remplis et qu'un ICSR valide existe.
2
Évaluation : le narratif indique que le patient « a été admis pendant deux jours et est sorti avec une amélioration » ; l'agent code l'événement comme non grave (aucun mot-clé explicite de gravité) et, incertain quant au caractère attendu, penche pour « attendu », s'orientant vers une clôture automatique en tant que cas non grave à 90 jours.
3
Interception : avant que le résultat assess_case ne soit écrit, le point de contrôle du Govern in Place SDK soumet une Decision Request à POST /v1/decisions.evaluate. La politique PV.SERIOUS.IMPLICIT_CRITERION correspond (le narratif signale une hospitalisation alors que l'agent a codé non grave) et PV.EXPECTED.UNCERTAIN_DEFAULT correspond (« attendu » choisi sous une incertitude signalée).
4
Résultat : la précédence aboutit à block sur la décision de caractère attendu et à require_approval sur la gravité ; l'exécution se met en pause (le run est retenu, il n'est pas en échec) et KLA ouvre une Escalation.
5
Routage : l'Escalation arrive dans Decision Desk devant le médecin de pharmacovigilance désigné, qui voit le narratif verbatim, le codage de l'agent, les deux codes motif, la version de l'étiquetage utilisée et un lien vers le Lineage Record. Ce médecin recode l'événement comme grave (hospitalisation), fixe le caractère attendu à inattendu conformément à ICH E2D §2.4 et approuve le parcours corrigé grave-inattendu — en enregistrant une signature 21 CFR 11.50 (nom, horodatage, meaning=approval).
6
Reprise et scellement : l'approbation reprend l'exécution exactement là où elle s'était arrêtée (idempotency_key garantit une soumission unique) ; le cas suit désormais le parcours accéléré de 15 jours avec le Jour 0 fixé à la date de première réception de la littérature, et la trace complète de la réception à la décision — raisonnement de l'agent, les deux codes motif, la correction et la signature du médecin — est scellée dans le Lineage Record en ajout seul et exportée sous forme de Control Pack mis en correspondance avec le GVP Module VI et la Part 11.

What most teams get wrong

The non-obvious insight

Le contrôle qui menace le plus le délai est l'évaluation de la gravité et du caractère attendu, et non l'étape de soumission — et un agent LLM y échoue de manière systématique, dans un sens qui inverse la réglementation. ICH E2D §2.4 indique que lorsque le caractère attendu est incertain, il faut retenir par défaut « inattendu » (dans le sens de la déclarabilité), mais un modèle de langage en situation d'incertitude retient par défaut le résultat statistiquement le plus fréquent, « attendu ». L'erreur de l'agent n'est donc pas un bruit aléatoire que l'on pourrait lisser avec davantage de cas de test ; c'est un biais directionnel qui joue toujours contre la déclarabilité, et il frappe au moment précis qui décide si le délai de 15 jours s'ouvre un jour.

Why it matters: Les équipes placent instinctivement la barrière la plus lourde sur l'étape irréversible de soumission, mais à ce stade le dommage — un cas grave mal étiqueté comme non grave et attendu — est déjà acquis, et une soumission propre de la mauvaise classification paraît parfaitement conforme. La gouvernance doit mordre plus tôt, au moment de l'évaluation, et elle doit encoder la valeur par défaut réglementaire sous forme de règle de politique stricte (bloquer « attendu » sous une incertitude signalée) précisément parce que l'a priori du modèle va dans le mauvais sens. Cela recadre aussi le 21 CFR Part 11 : le même Lineage Record qui prouve la piste d'audit est ce qui permet à un inspecteur de voir la décision initiale erronée de l'agent et la correction documentée de l'humain — la correction devient une preuve de contrôle, et non un défaut caché.

En vertu à la fois d'ICH E2D §4.3 et de 21 CFR 314.80(c)(1)(i), un effet indésirable médicamenteux grave et inattendu doit être déclaré au plus tard 15 jours calendaires après la réception initiale — et le GVP Module VI de l'EMA fixe le Jour 0 au moment où tout membre du personnel de l'entreprise, y compris un représentant commercial ou un sous-traitant, reçoit pour la première fois les critères minimaux, et non au moment où le service de pharmacovigilance enregistre le cas. L'implication pertinente pour la gouvernance : un agent de traitement des cas qui date le Jour 0 à partir de l'ingestion dans le système est structurellement en retard avant même de traiter un seul champ, parce que l'horloge réglementaire tourne depuis qu'une personne a entendu le signalement plusieurs jours plus tôt. (source)

Q&A

Frequently asked questions

Gouverner un agent de traitement des cas de PV signifie-t-il que l'EU AI Act le classe comme à haut risque ?

Non — et cette surévaluation est une erreur fréquente. L'annexe III de l'EU AI Act ne mentionne pas la pharmacovigilance ; le traitement des cas de PV n'est donc pas automatiquement classé à haut risque au titre de l'annexe III (l'IA des dispositifs médicaux relève d'une voie distincte d'évaluation de la conformité au titre de l'annexe I). Les régimes contraignants pour ce flux de travail sont les GVP, l'ICH E2D/E2B(R3) et le 21 CFR Part 11 / GxP. KLA s'aligne néanmoins sur les principes transversaux de contrôle humain (Art. 14) et de journalisation (Art. 12) de l'AI Act parce qu'ils relèvent d'une bonne gouvernance, mais les obligations opposables que les contrôles satisfont sont celles de la pharmacovigilance.

Pourquoi la piste d'audit du 21 CFR Part 11 correspond-elle si naturellement au traçabilité KLA ?

Le point 11.10(e) de la Part 11 exige une piste d'audit sécurisée, générée par ordinateur et horodatée, qui enregistre de manière indépendante qui a créé, modifié ou supprimé un enregistrement et quand, qui ne masque jamais les données antérieures et qui est conservée au moins aussi longtemps que l'enregistrement. KLA capture par défaut chaque contrôle de sécurité, chaque appel d'outil et chaque verdict humain, et les hache dans un registre ImmuDB en ajout seul qui produit des preuves de Merkle. C'est, presque ligne pour ligne, une piste d'audit Part 11 — et comme l'auditeur recalcule lui-même les preuves, l'intégrité tient sans avoir à faire confiance au fournisseur, ce qu'exige aussi l'obligation de validation du point 11.10(a) visant à « discerner les enregistrements invalides ou altérés ».

Comment KLA empêche-t-il l'agent de manquer le délai accéléré de 15 jours ?

Deux contrôles agissent ensemble. Le contrôle de déclarabilité/délai bloque tout Jour 0 dérivé de l'heure d'ingestion système et impose la réconciliation avec la date de première réception la plus ancienne (conformément au GVP Module VI VI.B.7), de sorte que le délai démarre là où le régulateur dit qu'il démarre. Il confirme ensuite par require_approval la voie accélérée de 15 jours calendaires dès qu'un cas est grave et inattendu, et avertit ou escalade lorsque le temps restant passe sous la marge de SLA. L'échéance, sa date source et la réconciliation sont scellées dans le Lineage Record à titre de preuve.

L'agent peut-il clôturer automatiquement un cas non déclarable sans intervention humaine ?

Uniquement dans le cadre d'une politique strictement délimitée. KLA bloque la clôture automatique d'un cas grave comme non déclarable et bloque la clôture définitive d'un cas comme « ICSR non valide » lorsqu'un critère de gravité ou un produit suspect est présent — les deux acheminent une Escalation en maker-checker vers une personne qualifiée nommément désignée. Les cas réellement non valides ou clairement non déclarables peuvent être clôturés sous allow, avec le verdict et la justification enregistrés, mais l'outil close_case est lié dans la Release de l'agent et n'est exposé qu'une fois franchies les étapes de contrôle amont de validité et de déclarabilité, de sorte que l'agent ne peut pas statuer sur un cas pour lequel il n'a aucune autorité.

Qui approuve réellement une décision de PV mise en attente, et comment cela est-il consigné en vue d'une inspection ?

Le routage est déclaré dans la politique : une Escalation arrive donc devant le responsable nommément désigné de ce risque — généralement un réviseur du traitement des cas de PV, un réviseur médical / médecin de sécurité pour les décisions d'évaluation, ou la personne qualifiée responsable de la pharmacovigilance pour une déclarabilité contestée. Cette personne approuve, refuse ou réachemine dans Decision Desk. Chaque verdict est consigné comme manifestation de signature au sens du 21 CFR 11.50 — nom imprimé, date et heure, et signification (revue/approbation) — lié à l'action exacte qu'il a autorisée et scellé dans le Lineage Record, ce qui fournit une réponse défendable à la question de l'inspecteur « qui a approuvé ceci, sur quelle base et quand ».

Comment KLA empêche-t-il les soumissions E2B(R3) malformées ou portant un mauvais point de départ du délai ?

Le contrôle d'écriture terminale est la dernière barrière avant la transmission irréversible. Il bloque toute soumission non conforme au sous-ensemble ICH E2B(R3) de l'ISO/HL7 27953-2 ou omettant des éléments obligatoires tels que C.1.4 (date de première réception du rapport depuis la source — le point de départ du délai) ou E.i.3.2 (critères de gravité au niveau de l'événement). Il bloque également la soumission d'un cas dont la gravité, le caractère inattendu ou la déclarabilité n'a pas été signé par un humain lorsque la politique l'exigeait, et porte une idempotency_key afin qu'un message approuvé soit transmis exactement une fois. La charge utile ou son hachage, avec C.1.4 et E.i.3.2, est scellé dans l'enregistrement de preuve.

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