Pharmacovigilance

Bearbeitung von Fällen unerwünschter Ereignisse

Steuerung eines Pharmakovigilanz-Agenten für die Aufnahme unerwünschter Ereignisse und die Fallbearbeitung

13 min · Updated 2026-06-02

Answer

Sie steuern einen Pharmakovigilanz-Agenten für die Fallbearbeitung, indem Sie seine hochriskanten Entscheidungen abfangen, bevor sie umgesetzt werden: Fallgültigkeit, Schweregrad und Erwartbarkeit, MedDRA-Kodierung, die Tag-0-Uhr sowie jede ICSR-Einreichung oder automatische Schließung. Ein Richtlinienkontrollpunkt gibt allow, warn, require_approval oder block zurück, leitet Entscheidungen zur Meldepflicht und zum automatischen Abschluss über eine Vier-Augen-Eskalation an eine benannte qualifizierte Person weiter und versiegelt einen kryptografisch überprüfbaren Lineage Record, der zugleich als Prüfpfad nach 21 CFR Part 11 dient. KLA erstellt Ihren PV-Agenten nicht. KLA steuert den von Ihnen erstellten Agenten und erzeugt bei jedem Durchlauf die GVP-, ICH- und Part-11-Nachweise.

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

Ein Agent für die Pharmakovigilanz (PV) nimmt Meldungen über unerwünschte Ereignisse aus spontanen, schriftlichen, angeforderten und digitalen Kanälen auf und führt einen regulierten Fall einer regulatorischen Entscheidung zu. Seine wichtigsten Entscheidungspunkte sind: (1) Fallgültigkeit — ob die vier ICH-E2D-Mindestkriterien (identifizierbarer Melder, identifizierbarer Patient, eine Nebenwirkung und ein verdächtiges Produkt) erfüllt sind und damit ein gültiger ICSR vorliegt; (2) MedDRA-Kodierung — Auswahl der Lowest Level Terms (LLT) nach ICH M1 für Reaktionen, Indikationen und Krankengeschichte; (3) Beurteilung der Schwere — Klassifizierung des Ereignisses anhand der sechs ICH-E2D-Schwerekriterien (Tod, lebensbedrohlich, Krankenhausaufenthalt oder -verlängerung, anhaltende oder erhebliche Behinderung, angeborene Anomalie, medizinisch wichtig); (4) Erwartbarkeit — Vergleich der Reaktion mit der lokalen Kennzeichnung bzw. SmPC; (5) Kausalität und Meldepflicht — ob ein Fall meldepflichtig ist und welche regulatorische Frist gilt; (6) die regulatorische Uhr — Festlegung von Tag 0, dem Datum, an dem Beschäftigte des Unternehmens erstmals einen Fall erhalten haben, der die Mindest- und beschleunigten Kriterien erfüllt; und (7) das endgültige Schreiben — Erstellen und Senden eines ICSR als E2B(R3)-Nachricht oder automatisches Schließen eines Falls als ungültig oder nicht meldepflichtig. An den Entscheidungspunkten 5, 6 und 7 kann der Agent eine behördliche Einreichung auslösen, eine Frist versäumen oder einen meldepflichtigen Fall in der Sicherheitsdatenbank, dem System of Record, stillschweigend schließen.

Stakes

Why it's high-stakes

Eine schwerwiegende und unerwartete unerwünschte Arzneimittelwirkung muss so bald wie möglich und spätestens 15 Kalendertage nach dem ersten Erhalt gemäß ICH E2D §4.3 und 21 CFR 314.80(c)(1)(i) gemeldet werden. Die Uhr des EMA-GVP-Moduls VI beginnt an Tag 0, sobald Beschäftigte des Unternehmens — einschließlich Vertriebsmitarbeitern oder Auftragnehmern — die Mindestkriterien erhalten, und nicht erst, wenn die Sicherheitsabteilung den Fall erfasst. Wenn der Agent ein schwerwiegendes Ereignis fälschlich als nicht schwerwiegend einstuft, eine unsichere Reaktion als "erwartet" bewertet oder einen meldepflichtigen Fall automatisch schließt, beginnt die 15-Tage-Uhr entweder nie oder sie läuft ohne Erfüllung ab. Der Fehler bleibt bis zu einer Inspektion unsichtbar: Es gibt keine Einreichung, keine Warnung, nur einen stillschweigend geschlossenen Fall. Verspätete oder versäumte beschleunigte Meldungen sind ein zentraler Befund von Pharmakovigilanz-Inspektionen durch EMA und FDA und können regulatorische Maßnahmen gegen die Marktzulassung auslösen. Für die Patientensicherheit bedeutet das, dass ein echtes Schadenssignal die Regulierungsbehörde nie erreicht; das erhöht das Compliance-Risiko.

What goes wrong

Failure modes specific to this agent

Stille Ernsthaftigkeitsherabstufung schließt die beschleunigte Uhr, bevor sie beginnt

Der Agent liest eine Freitexterzählung vor („Der Patient wurde über Nacht zur Beobachtung festgehalten und erholte sich“) und kodiert das Ereignis als nicht schwerwiegend, da kein explizites Schlüsselwort „schwerwiegend“ vorkommt, wobei er übersieht, dass der stationäre Krankenhausaufenthalt selbst ein schwerwiegendes ICH-E2D-Kriterium ist. Da der Schweregrad der Auslöser für die beschleunigte 15-Tage-Frist ist, bedeutet eine Einstufung als nicht schwerwiegend, dass der Agent niemals den beschleunigten Weg öffnet – der Fall wird auf die 90-Tage-Spur für nicht schwerwiegende Fälle weitergeleitet oder geschlossen, und Tag 0 wird effektiv aufgegeben.

Why it's hard to catch: Es gibt keinen Fehler und keine Warnung – der Agent hat einen syntaktisch gültigen, intern konsistenten Fall mit einer vertretbaren Begründung erstellt. QA-Testsätze basieren auf bereits codierten historischen Fällen, sodass sie die Übereinstimmung mit der Bezeichnung belohnen und kein implizites schwerwiegendes Kriterium erkennen, das in der Erzählung verborgen ist. Das Versäumnis kommt erst ans Licht, wenn ein Inspektor Monate später die Quelldokumente mit der Sicherheitsdatenbank abgleicht. Zu diesem Zeitpunkt ist die Frist längst abgelaufen und das Versäumnis ist eher ein dokumentierter Verstoß als ein Beinahe-Unfall.

Erwartungsfehler aufgrund des falschen Label-Snapshots oder der Standard-Erwartungs-Argumentation

ICH E2D §2.4 verlangt, dass, wenn der Inhaber unsicher ist, ob eine Reaktion zu erwarten ist, diese als unerwartet behandelt werden muss (ausfallsicher in Bezug auf die Meldebarkeit). Ein LLM-Agent argumentiert probabilistisch und wählt unter Unsicherheit häufig das häufigere „erwartete“ Ergebnis – das Gegenteil der behördlichen Vorgabe – oder vergleicht die Reaktion mit einer veralteten oder falschregionalen Etikettenversion und wandelt so einen meldepflichtigen, schwerwiegenden, unerwarteten Fall in einen nicht meldepflichtigen, schwerwiegenden, erwarteten Fall um.

Why it's hard to catch: Die Begründung sieht kompetent aus: Der Agent nennt einen echten Markenbegriff und eine plausible Übereinstimmung. Nichts in der Ausgabe deutet darauf hin, dass die Unsicherheit in die falsche Richtung gelöst oder die SmPC von gestern verwendet wurde. Die Erwartungsfähigkeit ist ein Urteil ohne Schlüssel zur Wahrheitsfindung, daher kann sie durch Genauigkeitstests nicht bewertet werden. Und da der regulatorische Standardwert (unsicher = unerwartet) das Gegenteil des statistischen Prior-Werts des Modells ist, ist der Fehler eher systematisch als zufällig, so dass die Stichprobenprüfung einiger korrekter Fälle zu falscher Sicherheit führt.

Eine Fehlkodierung von MedDRA auf der falschen Ebene oder in der falschen Version verschiebt die Ernsthaftigkeit und das Signal

Der Agent wählt einen MedDRA-Begriff auf der Ebene „Bevorzugter Begriff“ aus, wenn die LLT erforderlich war (gemäß GVP-Modul VI/ICH M1), wählt eine klinisch benachbarte, aber falsche LLT aus oder kodiert nach einem MSSO-Versionswechsel gegen eine ersetzte MedDRA-Version. Eine Reaktion, die auf ein gutartiges LLT statt auf ein medizinisch wichtiges kodiert ist, kann bei der Schweregradbeurteilung und bei der aggregierten Signalerkennung vollständig wegfallen.

Why it's hard to catch: Der codierte Begriff ist ein gültiger MedDRA-Eintrag, sodass die Schemavalidierung und die E2B(R3)-Gateway-Akzeptanz einwandfrei verlaufen – die Nachricht ist wohlgeformt und wird bestätigt. Die klinische Unrichtigkeit ist nur für einen geschulten Programmierer sichtbar, der den Begriff mit dem wörtlichen Reportertext vergleicht. Auf aggregierter Ebene beeinträchtigt der Fehlcode stillschweigend die Signalerkennung: Die betroffenen Fälle gruppieren sich nie unter dem richtigen Begriff, sodass das Sicherheitssignal eher unterdrückt als gekennzeichnet wird.

Day-0-Differenz: Der Agent datiert die Uhr von der Systemaufnahme, nicht vom ersten Empfang

Der Agent stempelt Tag 0 ab dem Zeitpunkt, an dem der Fall in die Sicherheitsdatenbank aufgenommen wurde (oder die E-Mail verarbeitete), aber GVP-Modul VI und ICH E2D definieren Tag 0 als das Datum, an dem ein Mitarbeiter des Unternehmens die Mindestkriterien zum ersten Mal erhalten hat – oft Tage früher, als ein Vertriebsmitarbeiter, eine medizinische Info-Hotline oder ein Auftragnehmer es zum ersten Mal hörten. Das spätere Datum des Agenten verbraucht stillschweigend einen Teil des 15-Tage-Fensters, und das E2B(R3) C.1.4-Element „Erstmals von der Quelle empfangenes Datum“ wird mit dem falschen Ursprung gefüllt.

Why it's hard to catch: Jede nachgelagerte Berechnung ist anhand des falschen Startdatums rechnerisch korrekt, sodass der Fall auf jedem internen Dashboard pünktlich angezeigt wird. Die Diskrepanz besteht nur in der Lücke zwischen dem Kontaktdatum des Quelldokuments und dem Aufnahmedatum des Systems – Daten, die der Agent oft nie sieht und die Tests nie injizieren. Ein Inspektor, der den ursprünglichen Datensatz des Einlasskanals abruft, findet einen Tag 0, der eine Woche vor dem Tag des Systems liegt, wodurch rückwirkend „pünktliche“ Einreichungen verspätet erfolgen.

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
Fallgültigkeit – existiert ein gültiger ICSR (vier ICH E2D / GVP Modul VI-Mindestkriterien)?	Govern in Place: Ein KLA SDK-Prüfpunkt umschließt den commit_case_validity-Schritt des Agenten und übermittelt einen Decision Request an POST /v1/decisions.evaluate, bevor der Agent den Fall als gültig/ungültig markiert oder ihn weiterleitet. (Durch KLA-Gates denselben Schritt zentral über Executions API ausführen.)	PV.VALIDITY.MIN_CRITERIA_INCOMPLETE – warnt, wenn eines der vier Mindestkriterien (identifizierbarer Melder, identifizierbarer Patient, Nebenwirkung, verdächtiges Produkt) nicht erfüllt ist, und fügt die Sorgfaltspflicht zur Nachverfolgung hinzu PV.VALIDITY.AUTOCLOSE_AS_INVALID – blockiert jeden Versuch, einen Fall endgültig als „kein gültiger ICSR“ zu schließen, wenn ein schwerwiegendes Kriterium oder ein verdächtiges Produkt vorliegt, mit Abhilfe: Weiterleitung an eine qualifizierte Person PV.VALIDITY.FOLLOWUP_REQUIRED – Warnung und Markierung zur Nachverfolgung statt zum Schließen, wenn die Kriterien teilweise erfüllt sind	Block / require_approval leitet eine Vier-Augen-Prüfung Eskalation an den benannten PV-Fallbearbeitungsprüfer (und für den automatischen Abschluss eines potenziell gültigen Falles an die qualifizierte Person für Pharmakovigilanz/Sicherheitsarzt auf Abruf) in Decision Desk weiter, der genehmigt, ablehnt oder umleitet.	Welche der vier Mindestkriterien wurden erkannt bzw. fehlten? Die Version des Richtlinienpakets und die zurückgegebenen Ursachencodes die Gültigkeitsgründe und Quellfelder des Agenten Lineage Record ID, die den Einlasskanal mit dieser Entscheidung verknüpft
Ernsthaftigkeit, Erwartungswert und MedDRA-Kodierung – die medizinische Beurteilung, die den regulatorischen Weg festlegt	Der SDK-Prüfpunkt Govern in Place im assess_case-Schritt des Agenten übermittelt einen Decision Request an POST /v1/decisions.evaluate, bevor das Ergebnis für Schwere/Erwartung/Kodierung in den Fall geschrieben wird.	PV.SERIOUS.IMPLICIT_CRITERION – require_approval wenn die Erzählung auf ein schwerwiegendes ICH E2D-Kriterium hinweist (Krankenhausaufenthalt, lebensbedrohlich, Behinderung, angeborene Anomalie, Tod, medizinisch wichtig), der Agent den Fall jedoch als nicht schwerwiegend kodiert hat PV.EXPECTED.UNCERTAIN_DEFAULT – blockiert eine „erwartete/nicht meldepflichtige“ Klassifizierung, die unter modellbedingter Unsicherheit vorgenommen wird; ICH E2D §2.4 erfordert die Standardeinstellung „Unerwartet“ mit Abhilfe: „Als unerwartet behandeln“, bis die QPPV-Genehmigung vorliegt PV.EXPECTED.LABEL_VERSION_STALE – warnt, wenn der verwendete Label-/SmPC-Snapshot nicht die aktuell gültige Version für die Fallregion ist PV.MEDDRA.LEVEL_OR_VERSION – Warnung, wenn eine Reaktion über dem LLT-Level oder gegen eine nicht aktuelle MedDRA-Version gemäß der gebundenen MSSO-Empfehlung kodiert ist	require_approval / Block öffnet eine Eskalation, die an den benannten medizinischen Gutachter/Sicherheitsarzt weitergeleitet wird (Vier-Augen-Prüfung über die medizinische Beurteilung des Agenten); Der QPPV ist das Umleitungsziel für umstrittene Erwartungsanrufe.	Bewertung der Ernsthaftigkeitskriterien und Urteil pro Kriterium Erwartungsentscheidung, Etikettenversions-ID und etwaige Unsicherheitsmarkierungen MedDRA-Version, ausgewählte LLT und wörtlicher Reportertext Ursachencodes und menschliches Urteil über die Eskalation
Meldefähigkeit und die regulatorische Uhr – Festlegung von Tag 0 und des 15-Tage- vs. 90-Tage-Pfads	Der Govern in Place SDK-Prüfpunkt im determine_reportability-Schritt des Agenten sendet einen Decision Request an POST /v1/decisions.evaluate, bevor dem Fall eine Uhr zugewiesen und zur Übermittlung oder zum Abschluss weitergeleitet wird.	PV.CLOCK.DAY0_SOURCE – blockiert einen Tag 0, der vom Zeitstempel der Systemaufnahme abgeleitet wird; Gemäß GVP-Modul VI VI.B.7 das früheste Datum des ersten Erhalts aller Mitarbeiter des Unternehmens verlangen, mit Abhilfe: Abgleich mit dem Kontaktdatum im Aufnahmekanal PV.CLOCK.SERIOUS_UNEXPECTED_15D – require_approval zur Bestätigung des 15-Kalendertage-beschleunigten Weges, wenn „schwerwiegend“ + „unerwartet“ zutrifft PV.REPORTABILITY.AUTOCLOSE_NONREPORTABLE – automatisches Schließen eines schwerwiegenden Falles als nicht meldepflichtig blockieren; Weg zum qualifizierten Menschen PV.CLOCK.DEADLINE_AT_RISK – Warnung/Eskalation, wenn die verbleibende Zeit bis zur 15-Tage-Frist unter den SLA-Puffer fällt	require_approval öffnet eine Vier-Augen-Prüfung-Eskalation an den benannten Meldefähigkeitsprüfer/qualifizierten Sachverständigen für Pharmakovigilanz; bei Genehmigung wird die Ausführung genau dort fortgesetzt, wo sie angehalten wurde (idempotency_key stellt sicher, dass die Übermittlung einmal ausgeführt wird); Bei Ablehnung wird der Lauf ohne Schreiben beendet.	berechnete Tag 0, sein Quelldatum und das Abgleichsergebnis der zugewiesene Weg (15 Tage beschleunigt vs. 90 Tage nicht schwerwiegend) und die Frist Identität des Genehmigers, Bedeutung der Signatur, Zeitstempel Richtlinienpaketversion und Ursachencodes
Terminal-Schreiben – Senden Sie den ICSR als E2B(R3)-Nachricht oder schließen Sie den Fall automatisch im Aufzeichnungssystem	Govern in Place SDK-Prüfpunkt umschließt den Toolaufruf submit_e2b / close_case; Decision Request bis POST /v1/decisions.evaluate ist das letzte Tor vor dem irreversiblen Schreiben in das Gateway oder die Sicherheitsdatenbank.	PV.E2B.SCHEMA_AND_SUBSET – blockiert eine Übermittlung, die nicht dem E2B(R3) ICH-Subset von ISO/HL7 27953-2 entspricht (fehlerhaft formatierte oder fehlende obligatorische Elemente wie C.1.4 Datum des ersten Empfangs oder E.i.3.2 Ernsthaftigkeit) PV.E2B.UNSIGNED_ASSESSMENT – Blockieren Sie die Einreichung aller Fälle, deren Schwere/Erwartung/Meldebarkeit nicht von Menschen unterzeichnet wurde, wenn die Richtlinien dies vorschreiben PV.CLOSE.WITHOUT_VERDICT – blockiert den automatischen Abschluss eines Falls ohne aufgezeichnetes Urteil zur Meldebarkeit und (falls erforderlich) ohne menschliche Freigabe PV.E2B.IDEMPOTENCY – mit einem idempotency_key zulassen, sodass eine genehmigte Übermittlung genau einmal übermittelt wird	Blockergebnisse halten den Schreibvorgang zurück und eröffnen eine Eskalation an den benannten Einreichungsprüfer/QPPV; Es werden keine ICSR-Übermittlungen durchgeführt und kein Fall abgeschlossen, bis die Eskalation eine Genehmigung beschließt.	die genaue E2B(R3)-Nutzlast (oder deren Hash) einschließlich C.1.4- und E.i.3.2-Elementen die Gateway-Bestätigung/Nachrichten-ID das vollständige Lineage Record von der Aufnahme bis zur Übertragung mit allen politischen Entscheidungen und menschlichen Urteilen im Anhang das Sealed Evidence Bundle / Control Pack, das diesen Fall abdeckt

Least-privilege execution & data boundaries

Fallgültigkeit – existiert ein gültiger ICSR (vier ICH E2D / GVP Modul VI-Mindestkriterien)?: Das Release des Agenten bindet nur die Sicherheitsdatenbank-Lese- und Fall-Tag-Tools im Tool Catalog; In der Gültigkeitsphase verfügt es über kein submit_e2b- oder close_case-Tool, daher kann es einen Fall hier nicht endgültig beseitigen, selbst wenn seine Argumentation fehlerhaft ist.
Ernsthaftigkeit, Erwartungswert und MedDRA-Kodierung – die medizinische Beurteilung, die den regulatorischen Weg festlegt: Die Veröffentlichung bindet eine angeheftete MedDRA-Wörterbuchversion und das aktuelle Etiketten-Repository als einzige Codierungsdatenquellen über Data Boundaries; Der Agent kann keine beliebige oder zwischengespeicherte Bezeichnung erreichen und Codierungstools sind für das angeheftete Wörterbuch schreibgeschützt.
Meldefähigkeit und die regulatorische Uhr – Festlegung von Tag 0 und des 15-Tage- vs. 90-Tage-Pfads: Der Meldepflichtschritt ist an kein Netzwerk-Übermittlungstool gebunden. Erst nachdem ein Mensch zustimmt, wird durch die Freigabe der geschlossene Übermittlungsschritt angezeigt. Die Freigabe durch den Menschen wird als elektronische Signatur gemäß 21 CFR 11.50 erfasst (gedruckter Name, Datum/Uhrzeit, Bedeutung = Genehmigung).
Terminal-Schreiben – Senden Sie den ICSR als E2B(R3)-Nachricht oder schließen Sie den Fall automatisch im Aufzeichnungssystem: submit_e2b und close_case sind die Tools mit dem engsten Umfang im Tool Catalog, die nur im aktiven Release des Agenten gebunden sind und erst nach dem Passieren der Upstream-Gates aufgetaucht sind; Data Boundaries hält die Gateway-Übertragung innerhalb der genehmigten Region.

Mapped to regulation

Regulatory mapping

Framework	Article / section	Obligation (plain language)	How a KLA runtime control satisfies it	Source
EMA GVP Modul VI (Rev 2) – EMA/873138/2011 Rev 2	VI.B.7 – Einreichung von ICSRs (Tag Null / Beginn der Uhr) und VI.B.7.1 (15 Tage schwerwiegend; 90 Tage nicht schwerwiegend)	Die Einreichungsfrist beginnt (Tag 0), sobald die Mindestkriterien den Mitarbeitern des Unternehmens – einschließlich medizinischer Vertreter und Auftragnehmer – zur Kenntnis gebracht werden, und nicht, wenn die Sicherheitsabteilung sie protokolliert; schwerwiegende gültige ICSRs müssen spätestens 15 Kalendertage nach Erhalt eingereicht werden (Erst- und Folgeuntersuchung), nicht schwerwiegende innerhalb von 90 Tagen.	Die Meldefähigkeit/Uhrsteuerung (runtime_controls[2]) blockiert einen Tag 0, der von der Systemaufnahmezeit (PV.CLOCK.DAY0_SOURCE) abgeleitet wird, erzwingt den Abgleich mit dem frühesten Ersteingangsdatum und require_approval-bestätigt den 15-Tage-Pfad, wenn schwerwiegende + unerwartete Ereignisse auftreten; Die Frist und ihre Berechnung sind im Lineage Record verankert.	Source
EMA GVP Modul VI (Rev 2) – EMA/873138/2011 Rev 2	VI.B.2 – ICSR-Validierung (vier Mindestkriterien)	Es dürfen nur gültige ICSRs eingereicht werden; Für die Validierung sind vier Mindestkriterien erforderlich (identifizierbarer Melder, ein identifizierbarer Patient, vermutete Substanz/Produkt, vermutete Nebenwirkung). Fehlt ein Element, ist der Fall unvollständig und kann nicht eingereicht werden.	Die Fallgültigkeitskontrolle (runtime_controls[0]) warnt, wenn eines der vier Kriterien fehlt (PV.VALIDITY.MIN_CRITERIA_INCOMPLETE) und blockiert das automatische Schließen des Terminals als „ungültig“, wenn ein schwerwiegendes Kriterium oder ein verdächtiges Produkt vorhanden ist, und leitet es an einen qualifizierten Mitarbeiter weiter, anstatt den Fall dem Agenten entsorgen zu lassen.	Source
ICH E2D (Post-Approval Safety Data Management) + FDA 21 CFR 314.80	ICH E2D §2.3 (schwerwiegend), §4.3 (15-Tage-Uhr / Tag 0); 21 CFR 314.80(c)(1)(i) (15-Tage-Alarmberichte)	Ein Fall ist schwerwiegend, wenn er zum Tod führt, lebensbedrohlich ist, einen Krankenhausaufenthalt erfordert/verlängert, eine dauerhafte/erhebliche Behinderung verursacht, eine angeborene Anomalie ist oder ein medizinisch wichtiges Ereignis darstellt – und der Schweregrad die beschleunigte Uhr auslöst. Schwerwiegende und unerwartete Reaktionen müssen so schnell wie möglich, spätestens jedoch 15 Kalendertage nach dem ersten Erhalt gemeldet werden (das US-Analogon in 314.80 ist identisch).	Die medizinische Beurteilungskontrolle (runtime_controls[1]) require_approval leitet jeden Fall weiter, in dem die Erzählung ein schwerwiegendes Kriterium signalisiert, das der Agent als nicht schwerwiegend codiert hat (PV.SERIOUS.IMPLICIT_CRITERION); Die Uhrensteuerung (runtime_controls[2]) bestätigt den 15-Tage-Pfad für schwerwiegende und unerwartete Ereignisse, sodass der Auslöser und die Frist gemeinsam erzwungen und nicht angenommen werden.	Source
EMA GVP Modul VI (Rev 2) – Inhalt/Format elektronischer ICSRs (MedDRA / ICH M1)	VI.C – Mit ICH M1 (MedDRA) auf LLT-Ebene kodierte Nebenwirkungen	Nebenwirkungen in ICSRs müssen mithilfe von MedDRA (ICH M1) auf der Ebene der untersten Begriffsebene gemäß dem Leitfaden „MedDRA-Begriffsauswahl: Zu berücksichtigende Punkte“ und den Empfehlungen der MSSO-Version kodiert werden.	Die Codierungssteuerung (runtime_controls[1], PV.MEDDRA.LEVEL_OR_VERSION) warnt, wenn eine Reaktion über LLT oder gegen eine nicht aktuelle MedDRA-Version codiert wird, und Data Boundaries heftet den Agenten an eine einzelne Wörterbuchversion, sodass er nicht gegen einen veralteten oder willkürlichen MedDRA-Build codieren kann.	Source
ICH E2B(R3) – Elektronische Übermittlung von ICSRs (EMA/CHMP/ICH/287/1995)	Nachrichtenstandard (ISO/HL7 27953-2 „ICH-Untergruppe“); E.i.3.2 (Schweregrad auf Ereignisebene); C.1.4 (Datum des ersten Berichts aus der Quelle)	Die elektronische ICSR-Übertragung muss dem E2B(R3)-Nachrichtenstandard (einem ICH-Untersatz von ISO/HL7 27953-2) entsprechen, die Ernsthaftigkeit als diskrete Kriterien pro Ereignis aufweisen, die an die E2A/E2D-Definitionen gebunden sind, und C.1.4 mit dem Datum füllen, an dem die vier Mindestkriterien erstmals erfüllt wurden – dem Ursprung der regulatorischen Uhr.	Die Terminal-Schreibsteuerung (runtime_controls[3], PV.E2B.SCHEMA_AND_SUBSET) blockiert eine Übermittlung, die nicht der ICH-Untergruppe entspricht oder obligatorische C.1.4-/E.i.3.2-Elemente auslässt, und die genaue Nutzlast (oder ihr Hash) einschließlich dieser Elemente wird im Lineage Record versiegelt.	Source
FDA 21 CFR Part 11 (Elektronische Aufzeichnungen; Elektronische Signaturen)	11.10 (Kontrollen für geschlossene Systeme; (a) Validierung; (e) sichere, computergenerierte, mit Zeitstempel versehene Prüfprotokolle)	Geschlossene Systeme, die elektronische Aufzeichnungen erstellen, ändern oder übertragen, müssen Authentizität, Integrität und Nichtabstreitbarkeit gewährleisten, validiert sein, um ungültige oder geänderte Aufzeichnungen zu erkennen, und sichere, computergenerierte, mit Zeitstempeln versehene Prüfprotokolle führen, die unabhängig aufzeichnen, wer einen Datensatz wann geändert hat, ohne frühere Daten zu verdecken, und die mindestens so lange aufbewahrt werden, wie die Aufzeichnung und für die behördliche Überprüfung verfügbar sind.	Das Evidence-by-Default-Ledger von KLA (erfasst über alle runtime_controls, versiegelt bei runtime_controls[3]) speichert jede Sicherheitsüberprüfung, jeden Tool-Aufruf und jedes menschliche Urteil in einem Nur-Anhang-ImmuDB-Ledger, das Merkle-Beweise erstellt – einen sicheren, computergenerierten, zeitgestempelten, manipulationssicheren Audit-Trail, den ein Prüfer unabhängig über überprüft Sealed Evidence Bundle, ohne KLA zu vertrauen.	Source
FDA 21 CFR Part 11 (Elektronische Aufzeichnungen; Elektronische Signaturen)	11.50 – Unterschriftenmanifestationen	Unterzeichnete elektronische Aufzeichnungen müssen den gedruckten Namen des Unterzeichners, das Datum/die Uhrzeit der Unterzeichnung und die Bedeutung der Unterschrift (Überprüfung, Genehmigung, Verantwortung, Urheberschaft) in einer für Menschen lesbaren Form enthalten.	Wenn die Meldebarkeits- oder Einreichungskontrolle (runtime_controls[2], runtime_controls[3]) require_approval zurückgibt, wird das Decision Desk-Urteil des benannten Genehmigers als Teil-11-Signaturmanifestation – gedruckter Name, Zeitstempel und Bedeutung = Genehmigung – erfasst und zusammen mit der von ihm autorisierten Aktion im Lineage Record versiegelt.	Source
EU AI Act (Verordnung (EU) 2024/1689)	Artikel 14(4)(d)-(e) – Menschliche Aufsicht (Übersteuerung/Rückwärtsgang; Anhalten in einen sicheren Zustand)	Aufsichtspersonen müssen in der Lage sein, zu entscheiden, die Ausgabe eines KI-Systems nicht zu nutzen, zu ignorieren, außer Kraft zu setzen oder umzukehren, und über ein „Stopp“-Verfahren einzugreifen oder es zu unterbrechen, um es in einen sicheren Zustand zu bringen. Wird als übergreifende Governance-Anpassung angeführt – KEINE Behauptung, dass die Bearbeitung von PV-Fällen ein hohes Risiko in Anhang III darstellt (Anhang III führt die Pharmakovigilanz nicht auf; die verbindlichen Regelungen sind hier GVP/ICH/Teil 11).	Jedes require_approval/Blockergebnis (runtime_controls[1]-[3]) ist genau dieser Stop-to-Safe-Zustand: Die Ausführung des Agenten wird angehalten, nicht fehlgeschlagen, und ein benannter Mensch kann die Aktion in Decision Desk genehmigen, ablehnen (überschreiben/umkehren) oder umleiten, bevor ein irreversibler Schreibvorgang erfolgt.	Source
EU AI Act (Verordnung (EU) 2024/1689)	Artikel 12 Absatz 1 – Aufzeichnungen (automatische Ereignisprotokollierung)	KI-Systeme sollten technisch gesehen eine automatische Aufzeichnung von Ereignissen (Protokolle) über die Systemlebensdauer hinweg ermöglichen. Wird als übergreifende Ausrichtung zitiert, die die Abstammungslinie KLA erfüllt; Das verbindliche Protokollierungsregime für PV ist 21 CFR 11.10(e).	KLA erfasst standardmäßig Beweise – jeder Tool-Aufruf, jede Richtlinienentscheidung und jedes menschliche Urteil wird während der gesamten Agentenlebensdauer (runtime_controls[0]-[3]) automatisch im Nur-Anhänge-Ledger protokolliert, wodurch die Protokollierung nach Artikel 12 und die strengeren Audit-Trail-Anforderungen nach Teil 11 gleichzeitig erfüllt werden.	Source

Prove the control held

Audit-evidence checklist

Herkunft der Aufnahme: der ursprüngliche Kanal (spontan/literarisch/erbeten/digital), das Datum des Erstkontakts, das zur Festlegung von Tag 0 verwendet wird, und der Abgleich mit der Systemaufnahmezeit
Das Erkennungsergebnis mit vier Mindestkriterien (vorhanden/fehlend pro Element) am Gültigkeitstor
Beurteilung der Schwere gemäß ICH E2D-Kriterium, mit der Erzählspanne, die jede Eskalation impliziter Kriterien auslöste
Erwartungsentscheidung mit der genauen Label-/SmPC-Versions-ID und einem etwaigen Modellunsicherheits-Flag (was beweist, dass der unsichere = unerwartete Standardwert eingehalten wird)
MedDRA-Version, ausgewählte LLT(s) und der wörtliche Reportertext, aus dem sie codiert wurden
Der zugewiesene regulatorische Weg (15 Tage beschleunigt vs. 90 Tage nicht schwerwiegend) und die berechnete Frist
Jede Richtlinienentscheidung mit ihrer signierten Richtlinienpaketversion und den Ursachencodes (zulassen / warnen / require_approval / blockieren)
Jedes menschliche Urteil als 21 CFR 11.50-Signaturmanifestation: gedruckter Name, Datum/Uhrzeit, Bedeutung (Überprüfung/Genehmigung), gebunden an die Handlung, die es autorisiert hat
Die übertragene E2B(R3)-Nutzlast (oder ihr Hash) mit den Elementen C.1.4 Datum des ersten Empfangs und E.i.3.2 Ernsthaftigkeit sowie der Gateway-Bestätigung/Nachrichten-ID
Das nur anhängende Lineage Record mit einer Merkle-Wurzel, das der Prüfer unabhängig neu berechnet (GET /v1/lineage/{id}/verify), exportiert als Sealed Evidence Bundle / Control Pack, zugeordnet zu GVP / Teil 11-Klauseln

A concrete intercept

Reference scenario: Ein aus der Literatur stammender Fall, den der Agent automatisch als nicht schwerwiegend schließen möchte, wird für das QPPV gehalten

1
Aufnahme: Der Agent nimmt einen veröffentlichten Fallbericht auf; ein identifizierbarer Autor (Reporter), ein einzelner Patient, ein verdächtiges Produkt und eine Reaktion vorliegen, sodass die vier ICH E2D-Mindestkriterien erfüllt sind und ein gültiger ICSR vorliegt.
2
Beurteilung: In der Erzählung heißt es, dass der Patient „zwei Tage lang aufgenommen und mit einer Besserung entlassen wurde“; Der Agent kodiert das Ereignis als nicht schwerwiegend (kein explizites Schlüsselwort „schwerwiegend“) und tendiert, unsicher über die Erwartbarkeit, zu „erwartet“ und steuert auf die automatische Schließung als nicht schwerwiegender 90-Tage-Fall zu.
3
Abfangen: Bevor das assess_case-Ergebnis geschrieben wird, übermittelt der Govern in Place SDK-Prüfpunkt einen Decision Request über POST /v1/decisions.evaluate an die Richtlinie. Die Regeln PV.SERIOUS.IMPLICIT_CRITERION (die Erzählung signalisiert eine Hospitalisierung, während der Agent den Fall als nicht schwerwiegend codiert hat) und PV.EXPECTED.UNCERTAIN_DEFAULT (als erwartet eingestuft trotz markierter Unsicherheit) greifen.
4
Ergebnis: Die Priorität löst sich auf, den Erwartungsanruf zu blockieren und require_approval den Ernsthaftigkeitsaufruf; Die Ausführung wird angehalten (die Ausführung wird angehalten, nicht fehlgeschlagen) und KLA eröffnet eine Eskalation.
5
Weiterleitung: Die Eskalation landet in Decision Desk vor dem benannten Sicherheitsarzt, der die wörtliche Erzählung, die Codierung des Agenten, die beiden Ursachencodes, die verwendete Etikettenversion und einen Link zum Lineage Record sieht. Sie kodieren das Ereignis „schwerwiegend“ (Krankenhauseinweisung) neu, setzen die Erwartung gemäß ICH E2D §2.4 auf „unerwartet“ und genehmigen den korrigierten Pfad „schwerwiegend-unerwartet“ – indem sie eine 21 CFR 11.50-Signatur (Name, Zeitstempel, Bedeutung = Genehmigung) aufzeichnen.
6
Fortsetzen und versiegeln: Die Genehmigung setzt die Ausführung genau dort fort, wo sie unterbrochen wurde (idempotency_key garantiert eine einzelne Übermittlung); Der Fall geht nun zum 15-tägigen beschleunigten Weg über, wobei Tag 0 auf das Datum des ersten Erhalts der Literatur festgelegt ist, und die vollständige Verfolgung von der Aufnahme bis zur Entscheidung – Argumentation des Agenten, beide Ursachencodes, Korrektur und Unterschrift des Arztes – wird im Nur-Anhang Lineage Record versiegelt und als Control Pack exportiert, das dem GVP-Modul VI und Teil 11 zugeordnet ist.

What most teams get wrong

The non-obvious insight

Die Kontrolle, die die Einhaltung der Frist am meisten gefährdet, ist die Bewertung der Ernsthaftigkeit/Erwartung, nicht der Einreichungsschritt – und ein LLM-Agent scheitert daran in einer systematischen, die Vorschriften umkehrenden Richtung. In ICH E2D §2.4 heißt es, dass bei ungewisser Erwartungswahrscheinlichkeit standardmäßig das Unerwartete verwendet werden muss (hinsichtlich der Meldebarkeit), ein Sprachmodell unter Unsicherheit jedoch standardmäßig das statistisch häufigere „erwartete“ Ergebnis verwendet. Der Fehler des Agenten ist also kein zufälliges Rauschen, das Sie mit mehr Testfällen mitteln können; Es handelt sich um eine Richtungsvoreingenommenheit, die immer der Meldebarkeit schadet, und sie tritt genau in dem Moment ein, der darüber entscheidet, ob die 15-Tage-Uhr jemals geöffnet wird.

Why it matters: Die Teams setzen instinktiv das schwerste Tor auf den irreversiblen Einreichungsschritt, aber bis dahin ist der Schaden – ein schwerwiegender Fall, der fälschlicherweise als „nicht schwerwiegend und erwartet“ bezeichnet wurde – bereits verankert, und eine saubere Einreichung mit der falschen Klassifizierung sieht vollkommen konform aus. Die Governance muss bei der Bewertung früher zuschlagen und den regulatorischen Standard als harte politische Regel kodieren (Block „erwartet“ unter markierter Unsicherheit), gerade weil die Priorität des Modells in die falsche Richtung verläuft. Dadurch wird auch 21 CFR Teil 11 neu formuliert: Dasselbe Lineage Record, das den Prüfpfad beweist, ermöglicht es einem Inspektor, den ursprünglichen falschen Anruf des Agenten und die dokumentierte Korrektur des Menschen zu sehen – die Korrektur wird zum Beweis der Kontrolle und nicht zu einem versteckten Fehler.

Gemäß ICH E2D §4.3 und 21 CFR 314.80(c)(1)(i) muss eine schwerwiegende und unerwartete unerwünschte Arzneimittelwirkung spätestens 15 Kalendertage nach dem ersten Erhalt gemeldet werden – und das EMA GVP-Modul VI legt Tag 0 fest, wenn alle Mitarbeiter des Unternehmens, einschließlich eines Vertriebsmitarbeiters oder Auftragnehmers, zum ersten Mal die Mindestkriterien erhalten, und nicht, wenn die Sicherheitsabteilung den Fall protokolliert. Die Governance-relevante Implikation: Ein Fallbearbeitungsagent, der Tag 0 der Systemaufnahme datiert, kommt strukturell zu spät, bevor er ein einzelnes Feld verarbeitet, weil die regulatorische Uhr läuft, seit eine Person den Bericht Tage zuvor gehört hat. (source)

Q&A

Frequently asked questions

Bedeutet die Leitung eines PV-Fallbearbeitungsbeauftragten, dass der EU AI Act ihn als risikoreich einstuft?

Nein – und dies zu überbewerten ist ein häufiger Fehler. EU AI Act In Anhang III wird die Pharmakovigilanz nicht aufgeführt, daher ist die Verarbeitung von PV-Fällen nicht automatisch ein Hochrisikofall in Anhang III (Medizinprodukte-KI ist ein separater Konformitätsbewertungspfad in Anhang I). Die verbindlichen Regelungen für diesen Workflow sind GVP, ICH E2D/E2B(R3) und 21 CFR Part 11 / GxP. KLA entspricht immer noch den übergreifenden Grundsätzen der menschlichen Aufsicht (Art. 14) und der Protokollierung (Art. 12) des KI-Gesetzes, da es sich dabei um eine gute Regierungsführung handelt, aber die durchsetzbaren Verpflichtungen, die die Kontrollen erfüllen, sind diejenigen der Pharmakovigilanz.

Warum passt der Audit-Trail nach 21 CFR Part 11 ideal zur KLA-Abstammung?

Teil 11.10(e) erfordert einen sicheren, computergenerierten Prüfpfad mit Zeitstempel, der unabhängig aufzeichnet, wer wann einen Datensatz erstellt, geändert oder gelöscht hat, frühere Daten niemals verdeckt und mindestens so lange wie der Datensatz aufbewahrt wird. KLA erfasst standardmäßig alle Sicherheitsüberprüfungen, Toolaufrufe und menschlichen Urteile und hasht sie in ein Nur-Anhang-ImmuDB-Ledger, das Merkle-Beweise erstellt. Das ist fast Zeile für Zeile ein Audit-Trail nach Teil 11 – und weil ein Prüfer die Beweise selbst neu berechnet, bleibt die Integrität bestehen, ohne dem Anbieter zu vertrauen, was auch die Validierungsanforderung von 11.10(a) „Erkennung ungültiger oder geänderter Datensätze“ erfordert.

Wie verhindert KLA, dass der Agent die beschleunigte 15-Tage-Uhrzeit verpasst?

Zwei Steuerungen arbeiten zusammen. Die Meldefähigkeit/Uhrzeitsteuerung blockiert einen Tag 0, der von der Systemaufnahmezeit abgeleitet wird, und erzwingt den Abgleich mit dem frühesten Ersteingangsdatum (gemäß GVP-Modul VI VI.B.7), sodass die Uhr dort beginnt, wo die Regulierungsbehörde sie angibt. Es bestätigt dann require_approval den beschleunigten 15-Kalendertage-Pfad, wenn ein Fall schwerwiegend und unerwartet ist, und warnt oder eskaliert, wenn die verbleibende Zeit unter den SLA-Puffer fällt. Die Frist, das Quelldatum und die Abstimmung werden als Beweismittel im Lineage Record versiegelt.

Kann der Agent einen nicht meldepflichtigen Fall ohne menschliche Hilfe automatisch schließen?

Nur innerhalb einer eng begrenzten Politik. KLA blockiert den automatischen Abschluss eines schwerwiegenden Falls als nicht meldepflichtig und blockiert den endgültigen Abschluss eines Falls als „kein gültiger ICSR“, wenn ein schwerwiegendes Kriterium oder ein verdächtiges Produkt vorliegt – beide leiten eine Vier-Augen-Prüfung-Eskalation an eine benannte qualifizierte Person weiter. Wirklich ungültige oder eindeutig nicht meldepflichtige Fälle können unter Genehmigung mit aufgezeichnetem Urteil und Begründung abgeschlossen werden, aber das close_case-Tool ist an die Freigabe des Agenten gebunden und wird erst angezeigt, nachdem die vorgelagerten Gültigkeits- und Meldepflicht-Gates durchlaufen wurden, sodass der Agent einen Fall nicht erledigen kann, zu dessen Beseitigung er keine Befugnis hat.

Wer genehmigt eigentlich eine zurückgehaltene PV-Entscheidung und wie wird diese für eine Inspektion erfasst?

Die Weiterleitung ist in der Richtlinie festgelegt, sodass eine Eskalation vor dem benannten Eigentümer dieses Risikos landet – typischerweise einem PV-Fallbearbeitungsprüfer, einem medizinischen Gutachter/Sicherheitsarzt für Beurteilungsanrufe oder der qualifizierten Person für Pharmakovigilanz für umstrittene Meldefähigkeit. Sie genehmigen, lehnen ab oder leiten in Decision Desk um. Jedes Urteil wird als 21 CFR 11.50-Unterschrift erfasst – gedruckter Name, Datum und Uhrzeit sowie die Bedeutung (Überprüfung/Genehmigung) – gebunden an die genaue Handlung, die es genehmigt hat, und im Lineage Record versiegelt, was eine vertretbare Antwort auf die Frage des Inspektors gibt: „Wer hat dies genehmigt, auf welcher Grundlage und wann?“.

Wie verhindert KLA E2B(R3)-Übermittlungen, die fehlerhaft sind oder den falschen Taktursprung haben?

Die Terminal-Schreibsteuerung ist das letzte Tor vor der irreversiblen Übertragung. Es blockiert jede Einreichung, die nicht dem E2B(R3) ICH-Untersatz von ISO/HL7 27953-2 entspricht oder obligatorische Elemente wie C.1.4 (Datum des ersten Empfangs des Berichts von der Quelle – der Ursprung der Uhr) oder E.i.3.2 (Schwerekriterien auf Ereignisebene) auslässt. Es blockiert auch die Übermittlung eines Falls, dessen Schwere/Erwartung/Meldebarkeit nicht von Menschen unterzeichnet wurde, wenn die Richtlinien dies vorschreiben, und trägt ein idempotency_key, sodass eine genehmigte Nachricht genau einmal übertragen wird. Die Nutzlast oder ihr Hash mit C.1.4 und E.i.3.2 wird im Beweisdatensatz versiegelt.

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