Pharmacovigilance has an unusually clean split between work that is clerical and work that is judgement, and the split maps almost exactly onto where AI is useful and where it is not. Reading a PDF and transferring patient age, product, dose and event into structured fields is clerical. Deciding whether a drug caused an event, and whether that event is listed in the product information in force, is judgement with regulatory accountability attached.
Most confusion about AI in this field comes from vendors and buyers talking about the two halves as if they were one thing. This guide separates them, explains why the boundary is a design property rather than a policy preference, and sets out how to evaluate what a vendor is actually offering.
Scope, and a disclosure
We build a pharmacovigilance platform with AI-assisted features, so weigh our perspective accordingly — this guide is written to be useful even if you never evaluate us. It is not regulatory advice. Regulatory expectations around AI in regulated processes are evolving and differ by jurisdiction, so confirm current requirements applicable to you with your qualified PV personnel and QA function rather than relying on any vendor's summary.
These are the tasks where the value is real and measurable. What they have in common: the output can be checked against a source, the cost of an error caught in review is low, and the work scales linearly with case volume — which is precisely the work that consumes qualified people's time.
Extraction from unstructured sources
Pulling patient, product, event, lab and reporter data out of PDFs, emails and free-text narratives. Verifiable against the source document, high volume, and pure transcription — the strongest single use case.
MedDRA coding proposals
Suggesting terms for reported verbatim text, handling synonyms, misspellings and phrasing variation. A proposal a coder accepts or overrides, not a decision.
Literature screening and triage
Reducing a thousand search hits to a reviewable few by relevance, and flagging candidate ICSRs for confirmation. High volume, low individual stakes, human confirmation at the end.
Duplicate candidate detection
Scoring an inbound report against the existing case population where fields are partial and inconsistently formatted — exactly the fuzzy matching problem rules alone handle badly.
Narrative drafting
Producing a first-draft narrative from structured case data for a reviewer to edit. Saves composition time; the reviewer still owns the content.
Routing and prioritisation support
Classifying inbound reports to route them. Note that the routing decision itself is better served by deterministic rules — see below.
The determinations below share three properties that make autonomous AI unsuitable: they carry regulatory accountability that must rest with a person, they require reasoning that has to be explainable years later, and being wrong is not a correctable data-entry error but a compliance event.
| Determination | Why it must stay human |
|---|---|
| Causality assessment | Requires weighing temporality, alternative explanations, dechallenge and rechallenge, and clinical plausibility — and the assessor is accountable for the conclusion |
| Expectedness / listedness | Depends on comparing the event against a specific version of the reference safety information in force on a specific date; the consequence is expedited reportability |
| Seriousness sign-off | Includes the "other medically important" criterion, which is an explicit clinical judgement with no mechanical definition |
| Case validity | Borderline patient and reporter identifiability calls determine whether a regulated case exists at all |
| Duplicate merge decisions | Merging is effectively irreversible and can silently destroy new information — the failure nobody notices |
| Release to submission | The point at which your organisation asserts a regulatory position to an authority |
| Benefit-risk conclusions | The interpretive core of a periodic report; the reasoning, not just the conclusion, is what is assessed |
The question that exposes a weak AI implementation
Ask a vendor: "Can the system be configured so that AI sets causality, or closes a serious case, without a person?" The answer you want is that it structurally cannot — not "we recommend against configuring it that way". A guardrail that depends on configuration discipline is a guardrail that will eventually be turned off by someone under deadline pressure.
"Human oversight" is the easiest claim in the category to make and the hardest to evidence. In a GxP context it needs to be structural, and there are four mechanisms that make it so.
- **AI proposes, a person disposes.** The AI output has no effect on the regulated record until a qualified user accepts it. Nothing reaches submission on a model's authority.
- **Per-field confidence, not per-case confidence.** A single confidence score for a whole case is close to useless operationally. Per-field scoring is what lets you route only the uncertain items to review instead of re-reading everything or trusting everything.
- **Evidence presented alongside the output.** A reviewer should see the extracted value next to its source context, so they verify against the document rather than assessing whether the AI looks confident.
- **The audit trail records the whole chain.** What was proposed, what confidence was assigned, what the reviewer changed, who approved it, and when — so the decision chain is reconstructable by someone who was not there.
The principle, stated plainly
AI assists intake and data entry. Qualified personnel review, edit, and approve AI-generated content before a case proceeds; regulated judgments remain with the client's PV personnel.
An under-discussed point: not everything that could be automated should be automated with a model. Some outcomes must be repeatable and explainable, and for those a configurable rules engine is the better instrument — not because models are unreliable, but because "the same inputs always produce the same output, and here is the rule" is a requirement in itself.
| Task | Better instrument | Why |
|---|---|---|
| Extraction from a PDF | AI | Unstructured, endlessly variable input; verifiable output |
| Reportability determination | Rules | Must be repeatable, explainable and change-controlled; encodes regulatory interpretation you own |
| Day 0 and deadline calculation | Rules | A deterministic derivation with compliance consequences |
| Which authority receives which format | Rules | Configuration you approve, not inference |
| Coding proposal | AI | Language variation is the problem; a coder confirms |
| Literature relevance screening | AI | Volume reduction with human confirmation at the end |
| Duplicate scoring | Both | Deterministic rules for near-exact matches, fuzzy matching for the rest — surfaced as candidates |
See the reporting rules engine for how deterministic rules resolve obligations, and AI MedDRA coding for where inference genuinely helps.
Straight-through or touchless processing — a case moving through the workflow with reduced manual intervention — is a reasonable capability and a genuine efficiency gain. It becomes a risk when its scope is implicit rather than decided.
- Scope it to defined, low-risk case types — typically listed, non-serious events on established products, never serious or fatal cases
- Set the confidence thresholds yourself, per product and case type, and document the rationale
- Keep human review as the default rather than the exception, so the automated path is the carve-out
- Monitor it: sample automated cases and track the error rate found, with a trigger that narrows scope if it drifts
- Be able to explain the scope decision at an inspection as a documented risk assessment, not a vendor default you inherited
This is the concern that stops many teams, and the human-in-the-loop design is what makes it tractable. If AI output only ever enters the regulated record through a review-and-approval gate you already qualify, then the control you are qualifying is the gate — the same control that governs manual data entry.
- Establish which steps are AI-assisted and document them in your process description — an inspector should not have to discover this
- Confirm AI-assisted steps are captured in the audit trail to the same standard as manual ones
- Qualify the review gates and the confidence-routing configuration, since those are the controls doing the work
- Treat threshold and scope changes as change-controlled configuration changes with a documented approval
- Keep deterministic outcomes (reportability, deadlines, routing) rule-based so they can be tested by expected-result cases
- Include AI-assisted paths explicitly in your performance qualification, including a low-confidence case being caught and corrected
Validation is environment-specific
PVgenix is validation-ready and audit-ready: it ships with a complete IQ/OQ/PQ documentation package to support client-led validation. 'Validated' is a state achieved only after qualification is executed in a specific client environment.
Every safety platform now says it has AI, which makes the claim itself uninformative. These questions separate implementations that hold up from demos that look good. Ask them of every vendor, including us.
| Ask | What a good answer looks like |
|---|---|
| Which specific steps are AI-assisted, and which are rules-based? | A precise list, with reportability and deadlines on the rules side |
| Is confidence scored per field or per case? | Per field, with automatic routing of low-confidence items to review |
| Can AI ever set causality, expectedness or seriousness sign-off? | No — structurally, not by recommendation |
| What does the audit trail record about an AI-assisted step? | Proposal, confidence, reviewer change, approver, timestamp |
| How is straight-through processing scoped and controlled? | Client-configured per case type, with human review as the default and monitoring in place |
| Show me a low-confidence extraction being caught and corrected — live. | Done in the demo, on a real screen, in a minute |
| Is the extracted value shown alongside its source context? | Yes — the reviewer verifies against the document, not against the model |
| How do we test AI-assisted steps during qualification? | A concrete approach, including expected-result cases through the review gate |
| What happens when the model is updated? | A change-control and notification process, with re-testing expectations stated |
For how PVgenix answers each of these, see AI pharmacovigilance software and the extraction and review console on AI case intake.
Two honest caveats worth holding onto when a business case is being built.
- Extraction accuracy varies by source quality, document type and field. A clean structured form and a scanned handwritten fax are not the same problem, and any single headline accuracy figure hides that variance — which is exactly why per-field confidence scoring matters more than an accuracy claim.
- Review effort does not go to zero. It is redirected: from typing everything to verifying the uncertain and assessing the clinical picture. The gain is real, but a business case built on eliminating review will not survive contact with a serious case.
The short version
Use AI for extraction, coding proposals, literature screening, duplicate candidates and narrative drafts — the clerical, verifiable, high-volume work. Use deterministic rules for reportability, deadlines and routing, where repeatability is the requirement. Keep causality, expectedness, seriousness sign-off and release with qualified people, enforced structurally rather than by policy. Score confidence per field, present evidence alongside output, and log the whole chain.
Next in this cluster: AI versus manual ICSR processing for where the time and money actually go, and AI MedDRA coding explained for the mechanics of the single most-automated step.
Frequently asked questions
Common questions
Effectively, in a specific set of tasks: extracting case data from unstructured sources such as PDFs, emails and narratives; proposing MedDRA terms for reported verbatim text; screening literature search results for relevance and flagging candidate ICSRs; scoring duplicate candidates where fields are partial and inconsistent; and drafting narratives from structured case data. What these share is that the output is verifiable against a source, the volume is high, and a human confirms before anything affects the regulated record.
No. These are regulated judgements with accountability attached to a person, they require reasoning that must remain explainable years later, and being wrong is a compliance event rather than a correctable data-entry error. Causality, expectedness or listedness, seriousness sign-off, case validity, duplicate merge decisions, release to submission and benefit-risk conclusions should all remain with qualified personnel — and ideally the system should make that structurally impossible to configure otherwise.
Four concrete mechanisms rather than a policy statement: AI output has no effect on the regulated record until a qualified user accepts it; confidence is scored per field so uncertain items are routed to review rather than the whole case being trusted or re-read; the extracted value is presented alongside its source context so the reviewer verifies against the document; and the audit trail records what was proposed, the confidence assigned, what the reviewer changed, who approved it and when — so the chain is reconstructable by someone who was not present.
By rules. Reportability, Day 0 and deadline calculation, and destination and format routing all need to be repeatable, explainable and change-controlled, because they encode regulatory interpretation that you own and must be able to defend. A configurable rules engine gives you "the same inputs always produce the same output, and here is the rule", which is a requirement in itself. AI is the better instrument where the input is unstructured and endlessly variable, such as extraction from documents.
Not necessarily, and the human-in-the-loop design is what keeps it tractable. If AI output only enters the regulated record through a review-and-approval gate you already qualify, the control being qualified is the gate — the same control that governs manual data entry. Practically: document which steps are AI-assisted, confirm they are audit-trailed to the same standard as manual steps, qualify the review gates and confidence-routing configuration, treat threshold changes as change-controlled, and include an AI-assisted path in performance qualification. Qualification remains environment-specific and client-led.
Ask where the human sits and what the audit trail records. Specifically: which steps are AI-assisted versus rules-based; whether confidence is per field or per case; whether AI can ever set causality, expectedness or seriousness sign-off (the answer should be no, structurally); what the audit trail captures about an AI-assisted step; how straight-through processing is scoped and who controls the thresholds; and what happens when the model is updated. Then ask to see a low-confidence extraction caught and corrected live in the demo — that single request separates working implementations from good slides.
It varies materially by source quality, document type and individual field — a clean structured web form and a scanned handwritten fax are not the same problem. Any single headline accuracy figure conceals that variance, which is why per-field confidence scoring is more useful than an accuracy claim: it routes the uncertain items to a person instead of asking you to trust an average. Expect review effort to be redirected rather than eliminated.