Pharmacovigilance Case Agent Blueprint
A drug-safety team's morning does not start with data. It starts with a queue of unlike things: a patient's email written in plain, worried language; a clinician's three-line note; a call-centre transcript; a paragraph lifted from a journal abstract. Somewhere in that queue are the reports the law cares about, on clocks the law sets. Most automation pitched at this team starts with summarising the queue. This blueprint starts one step earlier, with the question a safety physician asks before anything else: is this actually a case?
This open blueprint, the Pharmacovigilance Case Agent, runs on Amazon Bedrock AgentCore and works the stretch of pharmacovigilance between intake and medical review. Reports arrive; a validity gate in code decides which ones are cases; the agent assembles the valid ones into evidence-backed case files, codes their events, computes their seriousness and their reporting clocks, and stops — at a gate where two named human reviewers, a medical reviewer and a safety reviewer who are never the same person, must each accept the record. What it produces is an approved, exportable case file. It submits nothing, to any regulator or any safety database, ever.
Four things make it a case
Pharmacovigilance has a minimum definition of a valid case, and it is not a judgement call: an identifiable patient, an identifiable reporter, a suspect product, and an adverse event. All four, or it is not a case. The gate here is a deterministic function over exactly those criteria, and it is strict in the small ways that matter — a field filled with "unknown" or "n/a" identifies nobody, and never counts.
A report that fails does not vanish and does not sneak in. It becomes a follow-up task that names the missing criterion. In the blueprint's sample intake, six reports arrive and four become cases; one is held for want of an identifiable reporter, one for want of an identifiable patient, and each hold is a task someone can act on. This sounds like bookkeeping until you consider the alternative failure: a report that should never have been a case quietly entering the counts, the clocks and the signal statistics of a safety database. In this design, that door is closed by a function, not by vigilance.
Summaries that cite, or do not ship
For a valid case, the agent assembles the summary a reviewer will read — and every statement in it carries a citation to the specific evidence item and field it came from: the source, the received date, the reporter's qualification, the event as the reporter phrased it, its onset, its outcome. Before the summary may be stored, a resolver checks each citation. One statement whose citation does not resolve — a field renamed, a value paraphrased into a claim the evidence does not make — and the whole summary is refused, not just the sentence. The reviewer never sees a draft that is mostly sourced.
The evidence underneath is built to survive scrutiny: each item is hashed together with its predecessor, per case, so the chain verifies mechanically and an altered payload fails verification outright. Reports that look like duplicates are handled with the same restraint: an exact mechanical match on patient, product, event and onset is flagged, the pair is linked and routed to a named human queue — and the two cases stay two cases. Merging is a human decision, recorded as a link. It is never something the system does quietly at 3 a.m.
A verbatim is not a code
Reporters describe events in their own words; safety databases speak in dictionary terms. Between the two sits coding, and coding is treated here as a decision with a paper trail, not a lookup the model improvises. The reported phrase is matched against a versioned dictionary artefact by stated rules. An exact match codes cleanly and stores the decision — case, dictionary version, the verbatim, the term chosen, the rule that fired. Anything less than a clean match — no entry, or several plausible ones — goes to a coding-review queue, where a named human coder resolves it by choosing a term that exists in the dictionary. Later re-coding never supersedes a human's decision.
One honesty note belongs here rather than in the fine print: the dictionary that ships with the blueprint is an extract built for the repository, standing in for the licensed medical dictionary a production programme codes against. The mechanics around it — versioning, provenance, the human queue — are the point of the blueprint; the word list itself is a deployment's licensed artefact.
Seriousness is a checklist, the clock is arithmetic
Whether a case is serious is assessed against the six standard seriousness criteria — death, life-threatening, hospitalisation, disability, congenital anomaly, other medically important condition — evaluated in code over the case's evidence, with each criterion shown as fired or not. Expectedness is judged separately, against the product's reference safety information. From the case's first day, its seriousness and its expectedness, a versioned clock pack computes the reporting obligation: a seven-day expedited clock for a serious, unexpected case where death or life-threatening fired; fifteen days for other serious, unexpected cases; periodic reporting otherwise.
The value of doing this in code is that the board never flatters you. A case whose evidence fires no criterion and cannot yet be assessed reads as cannot assess — a state that demands work — and never gets rounded down to non-serious. And the clock board shows what it shows: in the blueprint's sample board, one seven-day case sits a day past its deadline, marked breached, next to the cases still within theirs. A safety operation does not need a dashboard that hides that row. It needs the row, the date arithmetic behind it, and the name of the queue it belongs to.
Two reviewers, then the door closes
Assembly ends at a gate with two locks. A medical reviewer and a safety reviewer — two named people, enforced as never the same person — must each accept the assembled record before the case counts as reviewed. Around the gate, the AgentCore policy layer does the quieter work: access to case material passes through policy checks that minimise what any caller can pull, because a case file is patient information and the blast radius of a curious integration is a design question, not an afterthought.
Then the system stops, by design. The output is the approved case file, exportable for the sponsor's own safety operation to take the final step through its own channels. Nothing in the blueprint transmits a case to a regulator or writes to a safety database of record. The last mile of pharmacovigilance is a regulated act with a named accountable owner, and an agent blueprint has no business performing it.
Built on AgentCore, honest about the seams
The agent runs behind the real AgentCore Runtime contract — the SDK's application entrypoint, its invocation and health endpoints, the container shape the service expects — rather than a diagram of it. The surrounding AgentCore services are mapped the way a deployment would grow into them: Memory, Gateway, Policy, Identity and Evaluations appear as ports, live where the platform is wired and as labelled local doubles where it is not yet. The model profile follows the same rule: an offline deterministic profile assembles summaries from stored evidence for development and evaluation, and the Bedrock profile refuses loudly until an AWS account is configured. There is no silent fallback anywhere in the system, because in a safety pipeline a quiet fallback is just an unreported failure wearing a success costume.
Work with us
If your safety team's reviewers are spending their judgement on assembly — chasing missing reporters, re-typing verbatim terms, recomputing clocks by hand — the assembly is buildable: a validity gate in code, cited summaries, coding with a human queue, clocks as arithmetic. Bring the problem through Trida AI's intake and we will scope what a case agent inside your pharmacovigilance operation should, and should not, be allowed to touch.
Get the Code on GitHub: github.com/tridaai/blueprint-agentcore-pharmacovigilance