Pharmacovigilance

adverse-event case processing

Governing a Pharmacovigilance Adverse-Event Intake & Case-Processing Agent

13 min · Updated 2026-06-02

Answer

You govern a pharmacovigilance case-processing agent by intercepting its high-stakes decisions before they commit — case validity, seriousness/expectedness, MedDRA coding, the Day-0 clock, and any ICSR submission or auto-close — with a policy gate that returns allow, warn, require_approval, or block, routes reportability and auto-close calls to a named qualified person via a maker-checker Escalation, and seals a cryptographically verifiable Lineage Record that doubles as the 21 CFR Part 11 audit trail. KLA does not build your PV agent; it governs the agent you built and produces the GVP/ICH/Part 11 evidence on every run.

KLA is the independent, framework-neutral runtime governance and assurance layer for this workflow. KLA governs the agent you already built — in LangGraph, CrewAI, Agentforce, Microsoft Copilot, or in-house — 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 workflow

The job & where the agent takes high-stakes action

A pharmacovigilance (PV) case-processing agent ingests adverse-event reports from spontaneous, literature, solicited, and digital channels, then drives a regulated case through to a regulatory decision. Its high-stakes decision points are: (1) case validity — deciding whether the four ICH E2D minimum criteria (identifiable reporter, identifiable patient, an adverse reaction, a suspect product) are met, which determines whether a valid ICSR even exists; (2) MedDRA coding — selecting Lowest Level Terms (LLT) per ICH M1 for reactions, indications, and medical history; (3) seriousness assessment — classifying the event against the six ICH E2D serious criteria (death, life-threatening, hospitalisation/prolongation, persistent/significant disability, congenital anomaly, medically important); (4) expectedness — comparing the reaction against the local label/SmPC; (5) causality and reportability — deciding the case is reportable and which regulatory clock applies; (6) the regulatory clock — fixing Day 0, the date any company personnel first received a case meeting minimum + expedited criteria; and (7) the terminal write — drafting and submitting an ICSR as an E2B(R3) message, or auto-closing a case as non-valid/non-reportable. Decision points 5, 6, and 7 are where the agent can trigger a regulatory submission, miss a deadline, or silently close a reportable case in the safety database (the system of record).

Stakes

Why it's high-stakes

A serious-and-unexpected adverse drug reaction must be reported as soon as possible and no later than 15 calendar days from initial receipt under both ICH E2D §4.3 and 21 CFR 314.80(c)(1)(i); the EMA GVP Module VI clock starts on Day 0, the moment any company personnel — including a sales representative or contractor — receives the minimum criteria, not when the safety department logs it. If the agent miscodes a serious event as non-serious, judges an uncertain reaction 'expected', or auto-closes a case that should have been reportable, the 15-day clock either never starts or expires unmet. The failure is invisible until an inspection: there is no submission to find, no alert, just a case that quietly closed. Late or missed expedited reports are a primary finding in EMA and FDA pharmacovigilance inspections and can trigger regulatory action against the marketing authorisation. The patient-safety consequence — a real signal of harm never reaching the regulator — compounds the compliance exposure.

What goes wrong

Failure modes specific to this agent

Silent seriousness downgrade closes the expedited clock before it starts

The agent reads a free-text narrative ('patient was kept in overnight for observation and recovered') and codes the event as non-serious because no explicit serious keyword appears, missing that inpatient hospitalisation is itself an ICH E2D serious criterion. Because seriousness is the trigger for the expedited 15-day clock, a non-serious classification means the agent never opens the expedited pathway — the case routes to the 90-day non-serious lane or is closed, and Day 0 is effectively abandoned.

Why it's hard to catch: There is no error and no alert — the agent produced a syntactically valid, internally consistent case with a defensible-looking rationale. QA test sets are built from already-coded historical cases, so they reward matching the label, not detecting an implicit serious criterion buried in narrative. The miss only surfaces when an inspector reconciles source documents against the safety database months later, by which point the deadline is long expired and the omission is a documented breach rather than a near-miss.

Expectedness mis-call against the wrong label snapshot or default-to-expected reasoning

ICH E2D §2.4 requires that when the holder is uncertain whether a reaction is expected, it must be treated as unexpected (fail-safe toward reportability). An LLM agent reasons probabilistically and will, under uncertainty, often pick the more common 'expected' outcome — the opposite of the regulatory default — or compare the reaction against a stale or wrong-region label version, flipping a reportable serious-unexpected case into a non-reportable serious-expected one.

Why it's hard to catch: The reasoning looks competent: the agent cites a real label term and a plausible match. Nothing in the output signals that it resolved uncertainty in the wrong direction or used yesterday's SmPC. Expectedness is a judgment with no ground-truth key, so accuracy testing cannot score it; and because the regulatory default (uncertain = unexpected) is the inverse of the model's statistical prior, the error is systematic rather than random, so spot-checking a few correct cases gives false confidence.

MedDRA mis-coding at the wrong level or wrong version shifts seriousness and signal

The agent selects a MedDRA term at the Preferred Term level when the LLT was required (per GVP Module VI / ICH M1), picks a clinically adjacent but wrong LLT, or codes against a superseded MedDRA version after an MSSO version switch. A reaction coded to a benign LLT instead of the medically important one can drop out of the seriousness assessment and out of aggregate signal detection entirely.

Why it's hard to catch: The coded term is a valid MedDRA entry, so schema validation and E2B(R3) gateway acceptance pass cleanly — the message is well-formed and gets acknowledged. The clinical wrongness is only visible to a trained coder comparing the term to the verbatim reporter text. At the aggregate level the mis-code silently biases signal detection: the affected cases never cluster under the correct term, so the safety signal is suppressed rather than flagged.

Day-0 drift: the agent dates the clock from system ingestion, not first receipt

The agent timestamps Day 0 from when the case entered the safety database (or when it processed the email), but GVP Module VI and ICH E2D define Day 0 as the date any company personnel first received the minimum criteria — often days earlier, when a sales rep, medical info line, or contractor first heard it. The agent's later date silently consumes part of the 15-day window, and the E2B(R3) C.1.4 'date first received from source' element is populated with the wrong origin.

Why it's hard to catch: Every downstream calculation is arithmetically correct against the wrong start date, so the case looks on-time on every internal dashboard. The discrepancy only exists in the gap between the source document's contact date and the system's ingestion date — data the agent often never sees and testing never injects. An inspector who pulls the original intake channel record finds a Day 0 that predates the system's by a week, retroactively making 'on-time' submissions late.

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
Case validity — does a valid ICSR exist (four ICH E2D / GVP Module VI minimum criteria)?	Govern in Place: a KLA SDK checkpoint wraps the agent's commit_case_validity step and submits a Decision Request to POST /v1/decisions.evaluate before the agent marks the case valid/invalid or routes it onward. (Run through KLA gates the same step centrally via the Executions API.)	PV.VALIDITY.MIN_CRITERIA_INCOMPLETE — warn if any of the four minimum criteria (identifiable reporter, identifiable patient, adverse reaction, suspect product) is absent, attaching the due-diligence follow-up obligation PV.VALIDITY.AUTOCLOSE_AS_INVALID — block any attempt to terminally close a case as 'not a valid ICSR' when a serious criterion or suspect product is present, with remediation: route to qualified person PV.VALIDITY.FOLLOWUP_REQUIRED — warn and tag for follow-up rather than close when criteria are partially met	block / require_approval routes a maker-checker Escalation to the named PV case-processing reviewer (and, for auto-close of a potentially valid case, the Qualified Person for Pharmacovigilance / safety physician on call) in Decision Desk, who approves, denies, or re-routes.	which of the four minimum criteria were detected vs missing the policy pack version and reason codes returned the agent's validity rationale and source fields Lineage Record id linking intake channel to this decision
Seriousness, expectedness & MedDRA coding — the medical assessment that sets the regulatory pathway	Govern in Place SDK checkpoint on the agent's assess_case step submits a Decision Request to POST /v1/decisions.evaluate before the seriousness/expectedness/coding result is written to the case.	PV.SERIOUS.IMPLICIT_CRITERION — require_approval when narrative signals an ICH E2D serious criterion (hospitalisation, life-threatening, disability, congenital anomaly, death, medically important) but the agent coded the case non-serious PV.EXPECTED.UNCERTAIN_DEFAULT — block a 'expected / non-reportable' classification taken under model-flagged uncertainty; ICH E2D §2.4 requires defaulting to unexpected, with remediation: treat as unexpected pending QPPV sign-off PV.EXPECTED.LABEL_VERSION_STALE — warn if the label/SmPC snapshot used is not the current effective version for the case region PV.MEDDRA.LEVEL_OR_VERSION — warn if a reaction is coded above LLT level or against a non-current MedDRA version per the bound MSSO recommendation	require_approval / block opens an Escalation routed to the named medical reviewer / safety physician (maker-checker over the agent's medical assessment); the QPPV is the re-route target for contested expectedness calls.	seriousness criteria evaluated and the per-criterion verdict expectedness decision, label version id, and any uncertainty flag MedDRA version, selected LLT, and verbatim reporter text reason codes and human verdict on the Escalation
Reportability & the regulatory clock — fixing Day 0 and the 15-day vs 90-day pathway	Govern in Place SDK checkpoint on the agent's determine_reportability step submits a Decision Request to POST /v1/decisions.evaluate before the case is assigned a clock and routed to submission or closure.	PV.CLOCK.DAY0_SOURCE — block a Day 0 derived from system-ingestion timestamp; require the earliest first-receipt date from any company personnel per GVP Module VI VI.B.7, with remediation: reconcile against intake-channel contact date PV.CLOCK.SERIOUS_UNEXPECTED_15D — require_approval to confirm the 15-calendar-day expedited pathway whenever serious + unexpected is true PV.REPORTABILITY.AUTOCLOSE_NONREPORTABLE — block auto-close of a serious case as non-reportable; route to qualified human PV.CLOCK.DEADLINE_AT_RISK — warn / escalate when remaining time to the 15-day deadline falls below the SLA buffer	require_approval opens a maker-checker Escalation to the named reportability reviewer / Qualified Person for Pharmacovigilance; on approval, execution resumes exactly where it paused (idempotency_key ensures the submission runs once); on deny, the run terminates without writing.	computed Day 0, its source date, and the reconciliation result the pathway assigned (15-day expedited vs 90-day non-serious) and deadline approver identity, signature meaning, timestamp policy pack version and reason codes
Terminal write — submit the ICSR as an E2B(R3) message, or auto-close the case in the system of record	Govern in Place SDK checkpoint wraps the submit_e2b / close_case tool call; the Decision Request to POST /v1/decisions.evaluate is the last gate before the irreversible write to the gateway or the safety database.	PV.E2B.SCHEMA_AND_SUBSET — block a submission that does not conform to the E2B(R3) ICH sub-set of ISO/HL7 27953-2 (malformed or missing mandatory elements such as C.1.4 date-first-received or E.i.3.2 seriousness) PV.E2B.UNSIGNED_ASSESSMENT — block submission of any case whose seriousness/expectedness/reportability was not human-signed where policy required it PV.CLOSE.WITHOUT_VERDICT — block auto-close of a case lacking a recorded reportability verdict and (where required) a human sign-off PV.E2B.IDEMPOTENCY — allow with an idempotency_key so an approved submission transmits exactly once	block outcomes hold the write and open an Escalation to the named submission reviewer / QPPV; no ICSR transmits and no case closes until the Escalation resolves to approve.	the exact E2B(R3) payload (or its hash) including C.1.4 and E.i.3.2 elements the gateway acknowledgement / message id the full Lineage Record from intake to transmission with all policy decisions and human verdicts attached the Sealed Evidence Bundle / Control Pack covering this case

Least-privilege execution & data boundaries

Case validity — does a valid ICSR exist (four ICH E2D / GVP Module VI minimum criteria)?: The agent's Release binds only the safety-database read and case-tag tools in the Tool Catalog; it has no submit_e2b or close_case tool at the validity stage, so it cannot terminally dispose of a case here even if its reasoning errs.
Seriousness, expectedness & MedDRA coding — the medical assessment that sets the regulatory pathway: The Release binds a pinned MedDRA dictionary version and the current label repository as the only coding data sources via Data Boundaries; the agent cannot reach an arbitrary or cached label, and coding tools are read-only against the pinned dictionary.
Reportability & the regulatory clock — fixing Day 0 and the 15-day vs 90-day pathway: The reportability step has no network-submission tool bound; only after a human approves does the Release surface the gated submit step. The human's sign-off is captured as a 21 CFR 11.50 electronic-signature manifestation (printed name, date/time, meaning = approval).
Terminal write — submit the ICSR as an E2B(R3) message, or auto-close the case in the system of record: submit_e2b and close_case are the most tightly scoped tools in the Tool Catalog, bound only in the agent's active Release and surfaced only after the upstream gates passed; Data Boundaries keep the gateway transmission within the approved region.

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 — Submission of ICSRs (day zero / clock start) and VI.B.7.1 (15-day serious; 90-day non-serious)	The submission clock starts (Day 0) the moment the minimum criteria are brought to the attention of ANY company personnel — including medical representatives and contractors — not when the safety department logs it; serious valid ICSRs must be submitted no later than 15 calendar days after that receipt (initial and follow-up), non-serious within 90 days.	The reportability/clock control (runtime_controls[2]) blocks a Day 0 derived from system-ingestion time (PV.CLOCK.DAY0_SOURCE), forces reconciliation to the earliest first-receipt date, and require_approval-confirms the 15-day pathway whenever serious+unexpected; the deadline and its computation are sealed into the Lineage Record.	Source
EMA GVP Module VI (Rev 2) — EMA/873138/2011 Rev 2	VI.B.2 — ICSRs validation (four minimum criteria)	Only valid ICSRs may be submitted; validation requires four minimum criteria (identifiable reporter, one identifiable patient, suspected substance/product, suspected adverse reaction). Missing any element means the case is incomplete and does not qualify for submission.	The case-validity control (runtime_controls[0]) warns when any of the four criteria is missing (PV.VALIDITY.MIN_CRITERIA_INCOMPLETE) and blocks terminal auto-close as 'invalid' when a serious criterion or suspect product is present, routing to a qualified human rather than letting the agent dispose of the case.	Source
ICH E2D (Post-Approval Safety Data Management) + FDA 21 CFR 314.80	ICH E2D §2.3 (serious), §4.3 (15-day clock / Day 0); 21 CFR 314.80(c)(1)(i) (15-day Alert reports)	A case is serious if it results in death, is life-threatening, requires/prolongs hospitalisation, causes persistent/significant disability, is a congenital anomaly, or is a medically important event — and seriousness triggers the expedited clock. Serious-and-unexpected reactions must be reported as soon as possible but no later than 15 calendar days from initial receipt (the US analog in 314.80 is identical).	The medical-assessment control (runtime_controls[1]) require_approval-routes any case where narrative signals a serious criterion the agent coded non-serious (PV.SERIOUS.IMPLICIT_CRITERION); the clock control (runtime_controls[2]) confirms the 15-day pathway for serious+unexpected, so the trigger and the deadline are enforced together rather than assumed.	Source
EMA GVP Module VI (Rev 2) — Content/format of electronic ICSRs (MedDRA / ICH M1)	VI.C — Adverse reactions coded with ICH M1 (MedDRA) at LLT level	Adverse reactions in ICSRs must be coded using MedDRA (ICH M1) at the Lowest Level Term level, following the MedDRA Term Selection: Points to Consider guide and MSSO version recommendations.	The coding control (runtime_controls[1], PV.MEDDRA.LEVEL_OR_VERSION) warns when a reaction is coded above LLT or against a non-current MedDRA version, and Data Boundaries pin the agent to a single dictionary version so it cannot code against a stale or arbitrary MedDRA build.	Source
ICH E2B(R3) — Electronic transmission of ICSRs (EMA/CHMP/ICH/287/1995)	Message standard (ISO/HL7 27953-2 'ICH sub-set'); E.i.3.2 (seriousness at event level); C.1.4 (date report first received from source)	Electronic ICSR transmission must conform to the E2B(R3) message standard (an ICH sub-set of ISO/HL7 27953-2), carry seriousness as discrete per-event criteria tied to the E2A/E2D definitions, and populate C.1.4 with the date the four minimum criteria were first met — the regulatory-clock origin.	The terminal-write control (runtime_controls[3], PV.E2B.SCHEMA_AND_SUBSET) blocks a submission that does not conform to the ICH sub-set or omits mandatory C.1.4 / E.i.3.2 elements, and the exact payload (or its hash) including those elements is sealed into the Lineage Record.	Source
FDA 21 CFR Part 11 (Electronic Records; Electronic Signatures)	11.10 (controls for closed systems; (a) validation; (e) secure, computer-generated, time-stamped audit trails)	Closed systems that create, modify or transmit electronic records must ensure authenticity, integrity and non-repudiation, be validated to discern invalid or altered records, and keep secure, computer-generated, time-stamped audit trails that independently record who changed a record and when, never obscuring prior data, retained at least as long as the record and available for agency review.	KLA's Evidence-by-Default ledger (captured across all runtime_controls, sealed at runtime_controls[3]) hashes every safety check, tool call and human verdict into an append-only ImmuDB ledger producing Merkle proofs — a secure, computer-generated, time-stamped, tamper-evident audit trail an auditor verifies independently via the Sealed Evidence Bundle without trusting KLA.	Source
FDA 21 CFR Part 11 (Electronic Records; Electronic Signatures)	11.50 — Signature manifestations	Signed electronic records must show the signer's printed name, the date/time of signing, and the meaning of the signature (review, approval, responsibility, authorship), included in any human-readable form.	When the reportability or submission control (runtime_controls[2], runtime_controls[3]) returns require_approval, the named approver's Decision Desk verdict is captured as a Part 11 signature manifestation — printed name, timestamp, and meaning=approval — and sealed into the Lineage Record alongside the action it authorised.	Source
EU AI Act (Regulation (EU) 2024/1689)	Article 14(4)(d)-(e) — Human oversight (override/reverse; stop to a safe state)	Oversight persons must be able to decide not to use, disregard, override or reverse an AI system's output, and to intervene or interrupt it via a 'stop' procedure bringing it to a safe state. Cited as cross-cutting governance alignment — NOT a claim that PV case processing is Annex III high-risk (Annex III does not enumerate pharmacovigilance; the binding regimes here are GVP/ICH/Part 11).	Every require_approval / block outcome (runtime_controls[1]-[3]) is exactly this stop-to-safe-state: the agent's run is held, not failed, and a named human can approve, deny (override/reverse), or re-route the action in Decision Desk before any irreversible write.	Source
EU AI Act (Regulation (EU) 2024/1689)	Article 12(1) — Record-keeping (automatic event logging)	AI systems should technically allow automatic recording of events (logs) over the system lifetime. Cited as cross-cutting alignment that KLA lineage satisfies; the binding logging regime for PV is 21 CFR 11.10(e).	KLA captures evidence by default — every tool call, policy decision and human verdict is logged automatically into the append-only ledger across the agent lifetime (runtime_controls[0]-[3]), satisfying Article 12 logging and the stricter Part 11 audit-trail requirement at once.	Source

Prove the control held

Audit-evidence checklist

Intake provenance: the original channel (spontaneous / literature / solicited / digital), the first-receipt contact date used to fix Day 0, and the reconciliation against system-ingestion time
The four minimum-criteria detection result (present/missing per element) at the validity gate
Seriousness verdict per ICH E2D criterion, with the narrative span that triggered any implicit-criterion escalation
Expectedness decision with the exact label/SmPC version id and any model-uncertainty flag (proving the uncertain=unexpected default held)
MedDRA version, selected LLT(s), and the verbatim reporter text they were coded from
The assigned regulatory pathway (15-day expedited vs 90-day non-serious) and the computed deadline
Every policy decision with its signed policy-pack version and reason codes (allow / warn / require_approval / block)
Each human verdict as a 21 CFR 11.50 signature manifestation: printed name, date/time, meaning (review/approval), bound to the action it authorised
The transmitted E2B(R3) payload (or its hash) with C.1.4 date-first-received and E.i.3.2 seriousness elements, plus the gateway acknowledgement / message id
The append-only Lineage Record with a Merkle root the auditor recomputes independently (GET /v1/lineage/{id}/verify), exported as a Sealed Evidence Bundle / Control Pack mapped to GVP / Part 11 clauses

A concrete intercept

Reference scenario: A literature-sourced case the agent wants to auto-close as non-serious is held for the QPPV

1
Intake: the agent ingests a published case report; an identifiable author (reporter), a single patient, a suspect product, and a reaction are present, so the four ICH E2D minimum criteria are met and a valid ICSR exists.
2
Assessment: the narrative says the patient 'was admitted for two days and discharged improved'; the agent codes the event non-serious (no explicit serious keyword) and, uncertain about expectedness, leans 'expected', heading toward auto-close as a 90-day non-serious case.
3
Intercept: before the assess_case result is written, the Govern in Place SDK checkpoint submits a Decision Request to POST /v1/decisions.evaluate. Policy PV.SERIOUS.IMPLICIT_CRITERION matches (narrative signals hospitalisation while the agent coded non-serious) and PV.EXPECTED.UNCERTAIN_DEFAULT matches (expected chosen under flagged uncertainty).
4
Outcome: precedence resolves to block on the expectedness call and require_approval on seriousness; execution pauses (the run is held, not failed) and KLA opens an Escalation.
5
Routing: the Escalation lands in Decision Desk in front of the named safety physician, who sees the verbatim narrative, the agent's coding, the two reason codes, the label version used, and a link to the Lineage Record. They re-code the event serious (hospitalisation), set expectedness to unexpected per ICH E2D §2.4, and approve the corrected serious-unexpected pathway — recording a 21 CFR 11.50 signature (name, timestamp, meaning=approval).
6
Resume & seal: approval resumes execution exactly where it paused (idempotency_key guarantees a single submission); the case now flows to the 15-day expedited pathway with Day 0 fixed at the literature first-receipt date, and the full intake-to-decision trace — agent reasoning, both reason codes, the physician's correction and signature — is sealed into the append-only Lineage Record and exported as a Control Pack mapped to GVP Module VI and Part 11.

What most teams get wrong

The non-obvious insight

The control that most threatens the deadline is the seriousness/expectedness assessment, not the submission step — and an LLM agent fails it in a systematic, regulation-inverting direction. ICH E2D §2.4 says that when expectedness is uncertain you must default to unexpected (toward reportability), but a language model under uncertainty defaults to the statistically more common 'expected' outcome. So the agent's error is not random noise you can average away with more test cases; it is a directional bias that always cuts against reportability, and it strikes at the exact moment that decides whether the 15-day clock ever opens.

Why it matters: Teams instinctively put the heaviest gate on the irreversible submit step, but by then the damage — a serious case mislabelled non-serious-and-expected — is already baked in, and a clean submission of the wrong classification looks perfectly compliant. The governance has to bite earlier, at the assessment, and it has to encode the regulatory default as a hard policy rule (block 'expected' under flagged uncertainty) precisely because the model's prior runs the wrong way. This also reframes 21 CFR Part 11: the same Lineage Record that proves the audit trail is what lets an inspector see the agent's original wrong call and the human's documented correction — the correction becomes evidence of control, not a hidden defect.

Under both ICH E2D §4.3 and 21 CFR 314.80(c)(1)(i), a serious-and-unexpected adverse drug reaction must be reported no later than 15 calendar days from initial receipt — and EMA GVP Module VI fixes Day 0 at the moment any company personnel, including a sales representative or contractor, first receives the minimum criteria, not when the safety department logs the case. The governance-relevant implication: a case-processing agent that dates Day 0 from system ingestion is structurally late before it processes a single field, because the regulatory clock has been running since a person heard the report days earlier. (source)

Q&A

Frequently asked questions

Does governing a PV case-processing agent mean the EU AI Act classifies it as high-risk?

No — and overclaiming this is a common error. EU AI Act Annex III does not enumerate pharmacovigilance, so PV case processing is not automatically Annex III high-risk (medical-device AI is a separate Annex I conformity-assessment track). The binding regimes for this workflow are GVP, ICH E2D/E2B(R3), and 21 CFR Part 11 / GxP. KLA still aligns to the AI Act's cross-cutting human-oversight (Art. 14) and logging (Art. 12) principles because they are good governance, but the enforceable obligations the controls satisfy are the pharmacovigilance ones.

Why is the 21 CFR Part 11 audit trail a natural fit for KLA lineage?

Part 11.10(e) requires a secure, computer-generated, time-stamped audit trail that independently records who created, modified or deleted a record and when, never obscures prior data, and is retained at least as long as the record. KLA captures every safety check, tool call and human verdict by default and hashes them into an append-only ImmuDB ledger that produces Merkle proofs. That is, almost line-for-line, a Part 11 audit trail — and because an auditor recomputes the proofs themselves, integrity holds without trusting the vendor, which 11.10(a)'s 'discern invalid or altered records' validation requirement also demands.

How does KLA keep the agent from missing the 15-day expedited clock?

Two controls work together. The reportability/clock control blocks a Day 0 derived from system-ingestion time and forces reconciliation to the earliest first-receipt date (per GVP Module VI VI.B.7), so the clock starts where the regulator says it starts. It then require_approval-confirms the 15-calendar-day expedited pathway whenever a case is serious and unexpected, and warns or escalates when the remaining time falls below the SLA buffer. The deadline, its source date, and the reconciliation are sealed into the Lineage Record as evidence.

Can the agent auto-close a non-reportable case without a human?

Only within tightly bounded policy. KLA blocks auto-close of a serious case as non-reportable and blocks terminal closure of a case as 'not a valid ICSR' when a serious criterion or suspect product is present — both route a maker-checker Escalation to a named qualified person. Genuinely non-valid or clearly non-reportable cases can close under allow with the verdict and rationale recorded, but the close_case tool is bound in the agent's Release and surfaced only after the upstream validity and reportability gates pass, so the agent cannot dispose of a case it has no authority to dispose of.

Who actually approves a held PV decision, and how is that captured for an inspection?

Routing is declared in policy, so an Escalation lands in front of the named owner of that risk — typically a PV case-processing reviewer, a medical reviewer / safety physician for assessment calls, or the Qualified Person for Pharmacovigilance for contested reportability. They approve, deny, or re-route in Decision Desk. Each verdict is captured as a 21 CFR 11.50 signature manifestation — printed name, date and time, and the meaning (review/approval) — bound to the exact action it authorised and sealed into the Lineage Record, giving a defensible answer to the inspector's question 'who approved this, on what basis, and when'.

How does KLA prevent E2B(R3) submissions that are malformed or carry the wrong clock origin?

The terminal-write control is the last gate before the irreversible transmission. It blocks any submission that does not conform to the E2B(R3) ICH sub-set of ISO/HL7 27953-2 or omits mandatory elements such as C.1.4 (date report first received from source — the clock origin) or E.i.3.2 (seriousness criteria at event level). It also blocks submission of a case whose seriousness/expectedness/reportability was not human-signed where policy required it, and carries an idempotency_key so an approved message transmits exactly once. The payload or its hash, with C.1.4 and E.i.3.2, is sealed into the evidence record.

Related blueprints & guides

Primary sources

Govern this workflow 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