An AI agent can read a call note, pull the four minimum criteria out of a discharge letter, and draft an individual case safety report (ICSR) in minutes. The design question is what the agent may finish on its own. Seriousness, expectedness, coding, the day the clock started and the decision to submit all carry regulatory weight, and an error in any of them can stay hidden until an inspector compares the source documents with the safety database. This article walks one synthetic case through a governed review: the source documents, the case the agent prepares, the checks that run before anything is written, the safety reviewer's decision, and the record that remains. It is a worked design based on our published pharmacovigilance blueprint. KLA has no pharmaceutical customer, and nothing here describes a deployment.
The rules the design has to respect
The EU rules for individual case reports sit in GVP Module VI, Revision 2, which EMA lists as in effect since 22 November 2017 on its GVP page. Four points shape any agent design.
Validity. Section VI.B.2 requires four minimum criteria before a report qualifies as an ICSR: an identifiable reporter, a single identifiable patient, at least one suspected medicinal product and at least one suspected adverse reaction. A report that lacks one of them is incomplete; the organisation must follow it up with due diligence and still record it for safety evaluation.
Day zero. Section VI.B.7 starts the clock when the minimum criteria reach "any personnel of the marketing authorisation holder, including medical representatives and contractors". Timelines run in calendar days, weekends and public holidays included. Under Articles 107(3) and 107a(4) of Directive 2001/83/EC, serious valid ICSRs go to EudraVigilance within 15 days and non-serious ones within 90 days (section VI.C.3).
Seriousness. Section VI.A.1.6 takes the ICH E2A definition: death, life-threatening, inpatient hospitalisation or prolonged hospitalisation, persistent or significant disability or incapacity, or a congenital anomaly, plus important medical events judged serious. Section VI.B.2 adds that seriousness "should not be downgraded from serious to non-serious if the notified recipient disagrees with the seriousness reported by the primary source".
Responsibility for the AI. EMA's reflection paper on AI in the medicinal product lifecycle (9 September 2024) expects AI to support "adverse event report management and signal detection" in line with GVP, and states that "it remains the responsibility of the MAH to validate, monitor and document model performance and include AI/ML operations in the pharmacovigilance system". The EMA–FDA cluster on AI in pharmacovigilance (version 2, 2 March 2026) lists case processing, literature screening, de-duplication and ICSR completeness checks among its use cases, and "large language models and agentic AI" among its topics. CIOMS published the report of its Working Group XIV on AI in pharmacovigilance on 4 December 2025; read it alongside GVP for terminology and principles.
Where we drew the boundary, and why
We first wrote these boundaries when we designed a guided demo of literature monitoring for a European pharmaceutical company in spring 2026. The design brief put human oversight at the centre: the qualified person responsible for pharmacovigilance (QPPV) and the safety physicians keep the regulated decisions, and the system makes their oversight explicit in policy, enforced in routing and visible in the record.
We grouped the work into cohorts by risk. In the low-risk cohorts the agent may run approved searches, retrieve documents, request translations and build a case shell. For a candidate valid case it may draft the case facts and propose MedDRA terms, seriousness, causality and expectedness for a reviewer. A medical reviewer sees every case that is serious, unexpected, a suspected duplicate or ambiguous to code. The list of hard stops stayed short:
- No downgrade of reporter-assessed seriousness by the agent (GVP Module VI, VI.B.2).
- No final MedDRA coding by the agent on the hard-stop cohorts.
- No final expectedness decision by the agent.
- No final duplicate merge by the agent where material fields diverge.
- No submission, authority communication or partner communication from the agent. In the design, these tools are absent from the agent's toolset.
The synthetic case: source documents
Everything in this case is invented: the company, the product "Examplazole 20 mg", the people and the times. The clock positions use day numbers so the arithmetic is easy to follow.
| Document | Received by | When | Content that matters |
|---|---|---|---|
| Medical information call note | Medical information line (company contractor) | Day 0, Friday 18:40 | A community pharmacist reports that a 67-year-old woman was "kept in overnight" with low sodium nine days after starting Examplazole 20 mg. Reporter name, qualification and country recorded. |
| Forwarded email to the safety mailbox | Drug safety team | Day 3, Monday 08:15 | The same call note, forwarded after the weekend. |
| Discharge letter | Drug safety team, from the pharmacist | Day 4 | Admitted overnight, serum sodium 124 mmol/L, Examplazole stopped, sodium normal at discharge. |
| Product label (SmPC) version 7 | Label repository | Current version on Day 0 | Hyponatraemia is not listed. |
What the agent prepares
The agent reads the three case documents and the label. Each extracted field keeps a pointer to the document and passage it came from, so the reviewer can check a value against its source in one step. In KLA, Document Intake attaches the documents, approved fields and their provenance to the Process run.
The agent's draft case: all four minimum criteria present; seriousness proposed as serious on the hospitalisation criterion, citing "kept in overnight" and the admission in the discharge letter; MedDRA lowest level term proposed as "Hyponatraemia"; expectedness proposed as unexpected against SmPC version 7; causality left for the reviewer. Its first proposal for day zero was Day 3, the time the email reached the safety mailbox.
The checks that run before anything is written
Each proposed write goes through a policy checkpoint before it reaches the safety database. The checkpoint returns one of four outcomes: allow, warn, require_approval or block. For this case, four checks fired.
| Proposed action | Rule | Outcome | What happened |
|---|---|---|---|
| Mark the case valid | Four minimum criteria present, each with a source reference | allow | Case marked valid; the source references are stored with the decision. |
| Set day zero to Day 3 | Day zero is the earliest receipt by any personnel, including contractors (VI.B.7) | warn | The agent reconciled against the call log and changed day zero to Day 0. The deadline moved from Day 18 to Day 15. |
| Change seriousness to non-serious after the discharge letter | No downgrade of reporter-assessed seriousness (VI.B.2) | block | Seriousness stays serious. The agent noted the normal sodium at discharge in the narrative. |
| Submit the ICSR | Submission of a serious case needs a named safety reviewer | require_approval | A Decision Request opened in Decision Desk for the safety reviewer on duty, with the deadline shown. |
The safety reviewer decides
The safety reviewer opens the Decision Request on Day 4. The request shows the draft case, each field's source passage, the four policy results and the time left on the clock. The reviewer confirms serious on the hospitalisation criterion and confirms unexpected against SmPC version 7. The reviewer keeps the lowest level term "Hyponatraemia", assesses causality as possibly related, edits one sentence of the narrative and records the reason. Then the reviewer approves submission.
A rejection has the same weight in the record. Had the reviewer judged the case invalid or the coding wrong, the run would end without a submission, and the record would hold the reviewer's reason. A case that needs follow-up goes back to the case-processing queue with the open questions attached.
Submission and the record that remains
After approval, the run resumes at the paused step. The submission tool calls the company's safety database, which builds the E2B(R3) message and sends it to EudraVigilance. The agent never holds that tool. The safety database and its gateway connection remain the company's validated systems; the governed run records what was asked of them and what came back.
| Field | Recorded value |
|---|---|
| Source documents | Call note, forwarded email, discharge letter, SmPC version 7, each with a content hash |
| Extracted fields | Reporter, patient, product, reaction, dates, each linked to its source passage |
| Agent proposals | Validity, seriousness, MedDRA term, expectedness, day zero (first and corrected value) |
| Policy results | Policy version, rule, outcome and reason for each of the four checks |
| Human decision | Reviewer identity and role, time, decision, causality assessment, narrative edit and reason |
| Submission | Tool call, request time, safety-database case reference and acknowledgment status |
| Clock | Day zero, deadline, submission day |
| Integrity | Lineage Record identifier; the run can be exported as a Sealed Evidence Bundle |
What this design does not cover
It does not validate anything. Computerised system validation, model performance monitoring and the quality system remain the marketing authorisation holder's work, as the EMA reflection paper states. A governed run adds a complete record per case to that work.
It does not settle classification under the AI Act. Pharmacovigilance case processing is not among the use cases listed in Annex III, so for most marketing authorisation holders the binding rules for this workflow come from pharmacovigilance law. Check the classification of your own system.
It does not cover signal management, periodic reports or literature search design. Those need their own boundaries, and the blueprint covers only intake and case processing.
Frequently Asked Questions
Can an AI agent submit an ICSR to EudraVigilance on its own?
The marketing authorisation holder stays responsible for every report it submits. In the design described here, the agent has no submission tool; a named safety reviewer approves the submission, and the company's safety database sends it.
When does day zero start for an adverse-event report?
GVP Module VI, section VI.B.7: when the minimum criteria reach the national or regional pharmacovigilance centre of a competent authority or any personnel of the marketing authorisation holder, including medical representatives and contractors. Timelines are calendar days.
Which pharmacovigilance decisions should stay with a human reviewer?
In our design: any downgrade of reporter-assessed seriousness, final MedDRA coding on serious, unexpected or ambiguous cases, final expectedness, duplicate merges where material fields diverge, and every submission or communication to authorities and partners.
Does a runtime control plane make an AI tool GxP-validated?
No. Validation of the system and monitoring of model performance remain the marketing authorisation holder's responsibility. A control plane enforces the review boundary and records each decision, which gives the validation and inspection work its case-level evidence.
Has KLA deployed this at a pharmaceutical company?
No. This is a worked design based on our published pharmacovigilance blueprint and a synthetic case. KLA has no pharmaceutical customer.
Key Takeaways
In pharmacovigilance, the agent's useful work is preparation: reading sources, extracting the minimum criteria with their provenance, drafting the case and proposing the medical assessments. The regulated decisions stay with a named reviewer, and the clock is computed from the earliest receipt by anyone working for the company. A governed design writes those rules down as policy, holds the agent at each boundary, and keeps one record per case that an inspector can follow from source document to submission. Read the pharmacovigilance blueprint for the full set of controls, see how to prove what an agent read before it acted, and see KLA for pharma.
Sources: EMA, Guideline on good pharmacovigilance practices Module VI Rev 2 (EMA/873138/2011 Rev 2); EMA, Reflection paper on the use of AI in the medicinal product lifecycle (EMA/CHMP/CVMP/83833/2023); EMA and US FDA, Guiding principles for the cluster teleconferences on AI in pharmacovigilance (EMA/422032/2023, version 2); CIOMS Working Group XIV. The case is synthetic. KLA is not affiliated with, endorsed by or certified by EMA, the FDA or CIOMS.