Pharmacovigilance & adverse event detection

Marketing-authorisation holders must collect, assess and report suspected adverse reactions for every product they sell, mostly from unstructured text in many languages. AI reads incoming reports and literature, extracts the four minimum criteria and the clinical details, proposes MedDRA codes and seriousness, flags duplicates and helps statisticians find signals. The safety physician stays accountable; the gain is less manual data entry and faster, more consistent case processing.

Problem & value

• Today: safety teams (in-house or at CROs) receive reports by email, phone, web form, partners and literature. Staff retype them into a safety database (Argus, ArisGlobal, Veeva), code terms in MedDRA, check duplicates, assess seriousness and decide on expedited reporting. Literature screening of thousands of records for a few relevant cases is a large recurring workload. Reporting clocks are legal deadlines (e.g. 15 days for serious cases, 90 days for non-serious) under EU rules [1][2].
• AI value: automated intake and triage, pre-populated ICSRs, coding suggestions, translation of non-English reports, literature pre-screening, quicker detection of safety signals. Vendors and industry working groups report meaningful efficiency gains in intake and coding, but published figures vary strongly by setting and are not comparable; measure your own baseline [3].
• Regulator side: EMA operates EudraVigilance, which receives ICSRs from the EU and signal management uses statistical disproportionality; national agencies (BfArM, PEI) and the WHO Programme for International Drug Monitoring (VigiBase, Uppsala Monitoring Centre) run similar tools [4][5].

Variants

• MAH / pharma safety department: ICSR intake, coding, narrative drafting, aggregate reports (PSUR/PBRER).
• CRO / PV service provider: multi-client case processing at volume, with per-client rules.
• Medical-device vigilance (MDR): incident and trend reporting under MDR; similar NLP, different forms.
• Hospital / regional PV centre: detecting adverse drug events in EHR notes and lab values (triggers).
• Regulator / public sector: signal screening on spontaneous-report databases.
• Social media and patient forums: mining for product mentions; high noise and GDPR sensitivity, often restricted to aggregated listening rather than case creation.

How it works

1. intake (email / form / scan / literature feed / partner E2B)
2. OCR + language detection + translation
3. case validity check (4 criteria: identifiable reporter, patient, suspect product, event)
4. information extraction (patient, drugs, doses, dates, events, outcome, history)
5. MedDRA coding of events/indications + WHODrug coding of products
6. duplicate detection against existing cases
7. seriousness / expectedness (vs. SmPC) / causality suggestion + narrative draft
8. human review and medical assessment (mandatory)
9. E2B(R3) submission to EudraVigilance / authorities
10. signal detection on the aggregate database

• Extraction: LLM with structured output, or a fine-tuned encoder NER model for entities such as drug, dose, event, onset; both are checked against dictionaries.
• Coding: retrieval over MedDRA terms (embeddings plus reranker), then an LLM or classifier picks the Lowest Level Term; coding stays suggestion-only until validated.
• Signal detection: classical disproportionality (PRR, ROR, empirical-Bayes methods) remains the backbone; ML adds clustering and case-series triage.
• Human-in-the-loop: a trained safety professional confirms every case; a qualified person responsible for pharmacovigilance (QPPV) owns the system.

Data preparation

Input data are individual case safety reports (E2B, e-mail, fax, call-centre notes, PDFs), literature, and in some setups social media. They live in the safety database, shared mailboxes, DMS and paper or scanned forms. Typical gaps: scanned or faxed reports without OCR, duplicates of the same case from several reporters, free text in several languages, missing MedDRA codes, inconsistent product names and no gold standard for what counts as a valid case.

Preparation steps: (1) inventory intake channels and owners (PREP-001, PREP-004); (2) digitise and OCR paper and fax intake (PREP-006); (3) convert mail archives and legacy formats (PREP-007); (4) build a product, substance and abbreviation glossary (PREP-015) and a category scheme for seriousness and causality (PREP-019); (5) harvest labels from already processed cases (PREP-020); (6) create a test set with experienced safety physicians (PREP-018); (7) pseudonymise training and test copies (PREP-022). Tools: OCR engines, Paperless-ngx for intake archives, the safety vendor's import tools.

Effort share is moderate, often a quarter to a third of the project, because the safety database already holds structured, coded history. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (marketing-authorisation holders, CROs): Path A, because validated safety-database suites with AI intake exist and the process is regulated and standard.
• Developer: Path B, because extraction, MedDRA coding and triage can be built quickly on cloud LLM APIs with structured output.
• Public (regulators, public institutes): Path C on sovereign infrastructure, because case data are sensitive and procurement rules favour control and auditability.

Path A — Buy (recommended)

• Safety platforms with embedded AI: Oracle Argus Safety and Oracle Life Sciences Safety One, ArisGlobal LifeSphere (with its NavaX/AI intake features), Veeva Vault Safety (incl. intake automation), IQVIA Vigilance Platform and Technology-Enabled Services, Genpact, Accenture and other PV outsourcers, Lorenz (Germany/EU, e.g. Lorenz Pharmacovigilance products), Sarjen, Ennov (France, EU). Verify current AI feature sets with each vendor; they change quickly.
• Literature monitoring: Embase/Elsevier, Clarivate, and PV-specific screening tools from the safety vendors.
• Choose A when: you already run a validated safety database; the vendor module slots into a validated GxP environment and avoids your own computer-system-validation burden.

Path B — Build on cloud APIs

• Extraction and narratives: frontier LLM APIs (Claude, Gemini, GPT) or Mistral (EU) in an EU region under a data processing agreement, with structured JSON outputs; Azure OpenAI or Amazon Bedrock EU regions for enterprise contracts.
• Document intake: Azure AI Document Intelligence, Google Document AI, AWS Textract for scanned forms.
• Dictionaries: MedDRA (licensed via MSSO/ICH) and WHODrug (UMC) are licensed, so retrieval indices are built inside your tenant.
• Integration: push drafts into the safety database through its API or E2B import, never directly to the authority.
• Choose B when: you need custom intake for unusual sources (patient programmes, local languages) on top of an existing safety database.

Path C — Self-host (open source)

• Models: open-weight LLMs such as Llama, Qwen, Mistral and Gemma families for extraction; biomedical encoders (BioBERT, PubMedBERT, BioLORD) for NER and term retrieval; translation with NLLB or an LLM.
• Stack: vLLM or Ollama serving, an OpenSearch/pgvector index of MedDRA, n8n or Camunda for workflows. OHDSI tools (OMOP CDM, HADES, and open disproportionality methods) for signal work on EHR/claims data [6].
• Hardware: HW3 for 30-120B models handling long case narratives; HW2 suffices for NER and coding only.
• When: patient-level data must not leave the premises, or at hospital and regulator scale.

Path D — Custom training

Fine-tune a NER and coding model on your own historical coded ICSRs (typically thousands of cases, reviewer corrections as continuing training data). Worth it for high volume, non-English sources or when dictionary coding accuracy is business-critical. Requires careful holdout evaluation by drug class and language.

State of the art (2026)

• LLM-based intake is in production at large MAHs and CROs, mostly as "draft and verify": extraction of case elements is strong on clean text; accuracy falls for handwritten forms, multi-drug narratives, temporal reasoning (onset vs. exposure dates) and negation ("no rash").
• MedDRA coding with retrieval-plus-LLM approaches is competitive with trained coders on common terms and weaker on rare or ambiguous terms; coders review suggestions.
• Guidance: the EMA reflection paper on AI in the medicinal-product lifecycle asks for risk-based validation, human oversight and traceability; CIOMS Working Group XIV addresses AI in pharmacovigilance, covering human-in-the-loop, explainability and validation [7][8].
• Signal detection: disproportionality plus ML on EHR and real-world data is growing; causal claims from spontaneous data remain unsafe without medical review.
• Limits: hallucinated dates or doses, under-reporting bias in source data, unreliable causality suggestions, and reporter bias in social media. A missed serious case is a compliance finding, so recall on seriousness matters more than precision.

Shared resources & combinations

• Same stack (ocr-docparse + llm-general + text-classifier): DOC-014 document parsing, HLTH-005 coding automation, HLTH-028 terminology mapping (MedDRA, SNOMED CT, FHIR).
• Upstream/downstream: HLTH-009 trial matching (shared safety data), HLTH-017 regulatory writing (PSUR, RMP), HLTH-029 GMP deviation and CAPA (quality complaints that are also adverse events), HLTH-004 for clinician-facing interaction checks, ANOM-007 for the anomaly-detection toolkit.
• Shared infrastructure: one GxP-validated LLM gateway and MedDRA retrieval index can serve several pharma use cases.

Effort, cost & KPIs

• Path A: quarters, driven by validation, data migration and vendor change control.
• Path B: 3-6 months for a validated add-on to an existing safety database.
• Path C/D: 6-12 months incl. computer-system validation and a dedicated ML team.
• Cost drivers: validation (GAMP 5 style), licensing (MedDRA, WHODrug), human review time, translation.
• KPIs: time to case entry, compliance with 15/90-day deadlines, recall of serious cases, field-level extraction accuracy, MedDRA coding agreement with coders, duplicate detection rate, literature screening recall and workload reduction, reviewer override rate.

People & change

Start with management and the head of drug safety (process owner and qualified person for pharmacovigilance), then legal and compliance for GVP and validation duties, IT and IT security for integration and hosting, and the data protection officer early. Case processors and medical reviewers are the end users; involve them in defining the test set and review rules.

Works council: depends. The tool processes cases, not employees, but throughput dashboards or per-person quality metrics make it suited to monitor performance and trigger §87(1) no. 6 BetrVG; §90(1) no. 3 requires information about planned AI-supported work processes. Agree on a works agreement that excludes individual performance evaluation from AI outputs (GUIDE-004).

Data protection: reports contain health data, so run a DPIA, sign AVV with vendors and document the legal basis (GUIDE-005).

AI literacy: support case processors with training on typical errors such as missed negations or wrong MedDRA terms (GUIDE-006). Pilot with one product or one intake channel, run in shadow mode next to manual processing, and keep medical review mandatory for seriousness and causality. Address fears of job loss by showing that volume growth is absorbed, not staff cut (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: a typical PV tool is not an Annex III use and is not itself a medical device, so minimal risk with the AI literacy duty (Art. 4) applies. Reclassify if the tool provides individual diagnostic or treatment decisions (medical device software under MDR, then high-risk under Art. 6(1)).
• GDPR: reports include health data (Art. 9); the legal basis is a legal obligation and public interest in public health (Art. 6(1)(c), 9(2)(i)); minimise identifiers, keep EU hosting, DPIA recommended, strict rules for social-media data.
• Pharmacovigilance law: Directive 2001/83/EC, Regulation (EU) 726/2004, Implementing Regulation 520/2012 and the EMA Good Pharmacovigilance Practices (GVP) modules, in particular Module VI (ICSR management) and Module IX (signals) [1][2]. Computerised systems fall under GxP and EU GMP Annex 11 expectations, audit trails and inspection readiness.
• Mitigations: documented validation with a representative test set, human sign-off on each case, drift monitoring, audit log of AI proposals versus final entries, vendor oversight in the PV system master file (PSMF).

Getting started

1. Baseline: case volume by source, languages, turnaround time, deadline compliance and coder disagreement.
2. Ask your safety-database vendor which AI modules are validated, and pilot those first.
3. Build a gold set of 300-500 historical cases (redacted) to benchmark extraction and coding.
4. Run in shadow mode: AI drafts, humans enter independently; compare field by field.
5. Agree with QPPV and QA on validation, SOP changes and inspection documentation before go-live.

Sources

1. EMA — Good pharmacovigilance practices (GVP), incl. Module VI — https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices
2. EMA — EudraVigilance — https://www.ema.europa.eu/en/human-regulatory-overview/research-development/pharmacovigilance-research-development/eudravigilance
3. CIOMS Working Group XIV — Artificial Intelligence in Pharmacovigilance — https://cioms.ch/working_groups/working-group-xiv/
4. Uppsala Monitoring Centre — VigiBase — https://who-umc.org/vigibase/
5. FDA — Adverse Event Monitoring System (AEMS, formerly FAERS) public dashboard — https://www.fda.gov/drugs/fda-adverse-event-monitoring-system-aems/fda-adverse-event-monitoring-system-aems-public-dashboard
6. OHDSI — Observational Health Data Sciences and Informatics — https://www.ohdsi.org/
7. EMA — Reflection paper on the use of AI in the medicinal product lifecycle — https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
8. ICH — E2B(R3) Individual case safety reports — https://www.ich.org/page/efficacy-guidelines
9. MedDRA — Medical Dictionary for Regulatory Activities — https://www.meddra.org/
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj