Governed AI Agents for Pharmacovigilance

Pharmacovigilance is a discipline built on traceability. Every adverse event report must be captured, assessed, coded, and where required reported to regulators within fixed timelines, and every step must be reconstructable at inspection. Case volumes keep rising, and AI agents are well suited to the heavy lifting: reading source documents, extracting case data, suggesting coding, assembling reports.

The question is how to use agents without loosening control. An agent that can draft a case can also mis-code a reaction, miss a seriousness criterion or submit something it should not. Drug-safety teams need agents that work from shared definitions, act only within explicit policy, and leave an evidence trail an inspector can follow.

This guide describes that stack with TrustGraph, using open standards throughout:

1. Domain-standard ontologies and terminologies to give safety data a formal, shared meaning
2. A safety operating graph that extends them with the organization's products, procedures and responsibilities
3. SHACL to express case-handling policy as machine-checkable rules, evaluated before an agent acts
4. PROV-O to record every decision, with its evidence and policy version, as queryable provenance

1. Start from domain standards

Pharmacovigilance already has well-established vocabularies. A safety graph can draw on:

• MedDRA, the medical terminology used to code adverse events, indications and medical history
• ISO IDMP and the Pistoia Alliance IDMP ontology, for identifying medicinal products, substances and their characteristics
• The Ontology of Adverse Events (OAE), an OBO ontology describing adverse events and their relationships
• SNOMED CT for clinical concepts, where licensed
• The ICH E2B(R3) standard, which defines the structure of individual case safety reports (ICSRs)

TrustGraph imports OWL and Turtle ontologies, so these standards become the typed backbone of the graph: a suspect product, a reaction, a patient and a reporter each land as exactly those things, with defined relationships between them.

2. Extend them into a safety operating graph

Standards describe the domain. Your organization also needs a graph of how it runs safety: its products and their reference safety information, its case-handling procedures, its responsibilities and approvals, and its reporting obligations. You extend the standards with your own concepts rather than forking them:

# Illustrative. pv: is your organization's safety namespace.
pv:SafetyCase          a owl:Class ;
    rdfs:label "Safety case" ;
    rdfs:comment "An individual case being processed, linked to its ICSR data." .

pv:ProposedSubmission  a owl:Class ;
    rdfs:label "Proposed submission" ;
    rdfs:comment "A regulatory submission an agent proposes, pending policy evaluation." .

pv:MedicalReviewer     a owl:Class ;
    rdfs:label "Medical reviewer" ;
    rdfs:comment "A qualified person authorized to assess and approve cases." .

pv:expectedness        a owl:ObjectProperty ;
    rdfs:label "Expectedness" ;
    rdfs:comment "Whether a reaction is listed in the product's reference safety information." .

TrustGraph populates the graph from source material such as case narratives, literature, call-centre notes, product labels and SOPs. Its ontology-guided extraction (Ontology RAG) produces facts that conform to these ontologies, each linked back to the document it came from.

3. Express case-handling policy as SHACL

Policy that today lives in SOPs and reviewer judgement becomes explicit, versioned SHACL that TrustGraph evaluates before an agent acts.

Case validity. A case is generally considered valid when it has the four minimum criteria: an identifiable patient, an identifiable reporter, a suspect product and an adverse event. A shape makes that checkable:

# Illustrative shape: the minimum criteria for a valid case.
pv:ValidCaseShape a sh:NodeShape ;
    sh:targetClass pv:SafetyCase ;
    sh:property [ sh:path pv:patient ;        sh:minCount 1 ;
                  sh:message "No identifiable patient: request follow-up." ] ;
    sh:property [ sh:path pv:reporter ;       sh:minCount 1 ;
                  sh:message "No identifiable reporter: request follow-up." ] ;
    sh:property [ sh:path pv:suspectProduct ; sh:minCount 1 ;
                  sh:message "No suspect product identified." ] ;
    sh:property [ sh:path pv:adverseEvent ;   sh:minCount 1 ;
                  sh:message "No adverse event identified." ] .

Review before submission. Serious cases carry regulatory and patient-safety consequences, so policy can require a qualified reviewer's approval before an agent may submit anything:

# Illustrative shape: serious cases need a medical reviewer's approval.
pv:SeriousCaseSubmissionShape a sh:NodeShape ;
    sh:targetClass pv:ProposedSubmission ;
    sh:sparql [
        a sh:SPARQLConstraint ;
        sh:message "Serious case requires medical reviewer approval before submission." ;
        sh:select """
            SELECT $this WHERE {
                $this pv:forCase ?case .
                ?case pv:seriousness ?criterion .
                FILTER NOT EXISTS { $this pv:approvedBy ?r . ?r a pv:MedicalReviewer . }
            }
        """ ] .

SHACL Advanced Features (SHACL-AF) rules can derive further facts the policy depends on, for example flagging a reaction as unexpected when it is absent from the product's reference safety information, so that expedited-handling rules apply automatically.

Each evaluation maps onto TrustGraph's three decisions:

Agents take on intake, extraction and assembly. Policy guarantees that medical judgement and regulatory submissions stay with qualified people.

4. Record every decision with PROV-O

Inspection readiness depends on being able to show exactly what happened to each case. TrustGraph records every decision as W3C PROV-O provenance: the case, the source documents, the extracted and coded facts, the agent, the reviewer, the policy version and the outcome.

# Illustrative decision record.
pv:evaluation-2219 a prov:Activity ;
    prov:used pv:case-2219, pv:narrative-2219, pv:policy-v7 ;
    prov:wasAssociatedWith pv:intake-agent ;
    prov:startedAtTime "2026-10-13T14:02:51Z"^^xsd:dateTime .

pv:decision-2219 a prov:Entity, pv:PolicyDecision ;
    prov:wasGeneratedBy pv:evaluation-2219 ;
    pv:outcome pv:Pause ;
    pv:reason "Serious case requires medical reviewer approval before submission." .

Because these records are linked data, they are queryable: every case paused for missing reporter details this month, which submissions were approved by which reviewer, which decisions relied on version 7 of the case-handling policy. A case history can be reproduced, not reconstructed.

What this gives a drug-safety organization

• Consistent meaning. Standard ontologies and terminologies mean agents, reviewers and systems agree on what a product, a reaction or a seriousness criterion is.
• Agents within guardrails that matter. Policy constrains what agents do, not just what they say, and keeps medical and regulatory decisions with qualified people.
• Policy as an artifact. Case-handling rules are explicit SHACL, versioned and testable, rather than implicit in SOPs and prompts.
• Inspection-ready traceability. PROV-O records answer who, what, when, why, under which procedure and from which source for every decision.
• Control of your data. Open standards and an open-source platform, deployable on-prem or in your cloud, with self-hosted inference for open-weight models where data cannot leave your environment.

The policies in this guide are illustrative examples of the approach, not regulatory guidance. Validity, seriousness, expectedness and reporting rules should be defined by your safety and regulatory teams in line with applicable regulations.

Frequently asked questions

Which ontologies and terminologies apply to pharmacovigilance?

Common building blocks include MedDRA for coding adverse events and medical history, the ISO IDMP standards and the Pistoia Alliance IDMP ontology for medicinal product identification, the Ontology of Adverse Events (OAE) from the OBO community, and SNOMED CT for clinical concepts, alongside the ICH E2B(R3) standard for individual case safety reports. TrustGraph imports OWL and Turtle ontologies, so these can be combined and extended into an organization's own safety graph.

How does SHACL enforce policy on pharmacovigilance agents?

SHACL shapes describe what a valid, complete and correctly routed case looks like, for example that a case has the four minimum validity criteria, or that a serious case must be reviewed by a qualified person before submission. Evaluated before an agent acts, a violation denies the action, a missing element or required review pauses it, and a conforming action is allowed.

Does this replace human safety reviewers?

No. The aim is to let agents take on intake, coding and assembly work while policy guarantees that medical judgement and regulatory submissions stay with qualified people. Policies can require a named reviewer's approval before any action that carries regulatory or patient-safety consequences.

Why use PROV-O for pharmacovigilance traceability?

PROV-O is the W3C standard for provenance. Recording each agent decision as PROV-O captures the case, the source documents, the coding, the policy version and the people and agents involved as queryable linked data, which supports audits, inspections and reproducible case histories.

Next steps

• Read What is an ontology? and What is determinism for AI? for the concepts behind this stack.
• See Explainable AI with a Context Graph for how answers trace back to sources.
• Walk through ontology-guided extraction step by step in the Ontology RAG tutorial.