Clinical Document Extraction for Pharmacovigilance Intake

A pharmacovigilance team does not receive adverse events as tidy records. It receives a forwarded email from a sales representative, a PDF of a journal article, a partner's line listing, a nurse's note from a patient support programme and a call transcript that someone exported after the fact. Every one of those has to become a structured case before anyone can assess it, and the statutory reporting period does not wait for the case to be tidied up.

The volume is not small. The European Medicines Agency's 2025 Annual Report on EudraVigilance records around 1.77 million individual case safety reports collected and managed in 2025, a 0.5% increase on the year before, with 31,253,245 reports held in total by 31 December 2025. EU reporting volume is roughly flat, so in our view the pressure on a safety team is not a surge. It is the steady conversion work behind every one of those reports: source documents read, checked, de-duplicated and followed up every working day.

This guide covers the document side of case intake: what a model can usefully draft from a source document, where duplicates and follow-ups make extraction harder than a demo suggests, and how to test it without moving safety data out of the building. It deliberately cedes two neighbouring frames. Capturing a reaction live on a phone line, including the four minimum criteria and when the clock starts on a call, belongs to our guide to adverse event capture on medicines information lines. The 15 and 90 day submission deadlines and the severity picture from MHRA inspections belong to AI for pharma in the UK: where it pays in 2026.

This guide is shipped by the team behind Dilr Mira, private clinical small language models that turn documents into source-grounded JSON drafts on your own hardware. Or see DATS, our five-stage AI consulting system.

What is document extraction for pharmacovigilance case intake?

Document extraction for pharmacovigilance case intake is the step that turns an unstructured source document, such as an email, a literature article, a partner listing or a call transcript, into a structured draft of the fields a safety case needs. The draft names the reporter, patient, product and reaction as the source states them, with each value traceable to its text. A trained safety professional then codes, assesses and submits the case.

That definition is deliberately narrow. Extraction does not decide whether something is an adverse reaction, it does not assess causality, and it does not choose seriousness. Those are pharmacovigilance judgements that the marketing authorisation holder remains responsible for. What extraction removes is the retyping: the minutes a case processor spends reading a four page article to find the one paragraph describing a patient, then copying dates, doses and outcomes into a safety database by hand.

The distinction matters because the two halves fail differently. A judgement error is visible to a reviewer who knows the medicine. A transcription error, such as a dose copied from the wrong table row or an onset date taken from the publication date, looks plausible and can travel into the submitted report if no one checks it against the source. The second kind is what a well built extraction step should reduce, and it is also what a badly built one silently multiplies. Our clinical document extraction guide explains the general method; this post applies it to the safety desk.

Which source documents reach a safety team, and why are they hard to structure?

A safety team's intake arrives from several streams at once: spontaneous reports through medical information and product complaints, the medical literature, solicited sources such as patient support and market research programmes, and safety data exchanged with licensing partners. Each stream has its own document shape, and an extraction step has to cope with every one that is in scope.

The MHRA uses the same streams to categorise its inspection findings. Its GPvP inspection metrics report for April 2021 to March 2022, the latest edition listed on GOV.UK, files findings under collection and collation of adverse reactions with four subtopics: spontaneous sources such as medical information and product quality complaints, literature searching, solicited sources including patient support or market research programmes, and safety data exchange agreements. That is a useful checklist for scoping an extraction pilot, because each subtopic produces a different document type.

Literature articles are the hardest. A case report can sit inside a case series, the patient can be described across the abstract, the methods and a table, and several products may be mentioned with only one suspected. Under regulation 188 of the Human Medicines Regulations 2012, a holder must monitor medical literature for reports of suspected adverse reactions to its product, subject to a carve-out for certain authorisation types where the substance and the publication are both monitored. For substances with many authorisations in the European Economic Area, the EMA runs a medical literature monitoring service; its own annual report says the service created over 58,000 individual cases and transmitted more than 101,000 reports in its first ten years. That service exists for EEA holders and EudraVigilance. In our reading, a Great Britain holder reporting to the MHRA should not assume it covers its own duty.

Inbound emails and forwarded notes are short but messy. They can mix the reporter's words with a colleague's summary, omit the patient's age or sex, and describe two products in the same sentence. Partner listings are structured but in someone else's structure, so the work is mapping rather than reading. Transcripts from medicines information or patient support calls are long and conversational. Capture on the call itself is covered by the guide linked in the introduction; once a transcript exists as a document, it becomes an extraction input like any other.

What should a case draft hold before a safety reviewer sees it?

A case draft should hold every field a reviewer needs to code and assess the case, each grounded in the source text, plus an explicit marker for anything the source does not say. With Dilr Mira the fields come from a schema your team defines, and we would design it so absent values stay absent. A draft that guesses a missing onset date is worse than one that flags the gap.

The fields themselves come from your safety database and from the transmission standard, not from the model. The EMA states on its EudraVigilance electronic reporting page that EudraVigilance no longer accepts reports in the older ICH E2B(R2) format and that reports should use the ISO ICSR and ICH E2B(R3) format. That standard governs how a finished case is transmitted. It is a sensible reference for naming your draft fields, so that what the extraction step produces maps cleanly onto what your database later submits, but the transmission itself stays with the safety system that is validated to produce it. That page sets the EMA's requirement for EudraVigilance; a holder reporting to the MHRA should confirm the format its own submission route uses with its regulatory team and safety system supplier.

We would start a first pilot with five groups of fields:

The last row is easy to leave out, and in our view it matters most. Which date starts the reporting period belongs to the holder's process, not the model, but a draft that records which document arrived when, and which version of a case each value came from, makes that date auditable rather than reconstructed.

Why do duplicates and follow-ups make extraction harder than it looks?

Duplicates and follow-ups make extraction harder because a safety case is a history, not a single document. The same patient can arrive through a literature article, a partner listing and a medicines information call, and a later email can change an outcome or a dose. Under UK law the holder must collect follow-up information and collaborate in detecting duplicate reports, so an extraction step that treats each document as a fresh case creates work.

Regulation 188 is specific about both duties. Paragraph (1)(d) requires the holder to collect follow-up information on reports it has submitted and send it to the licensing authority as an update to the original report. Paragraph (1)(e) requires the holder to collaborate with the licensing authority in the detection of duplicates of suspected adverse reaction reports. Earlier in the same paragraph sits the provision that, in our reading, most directly governs an extraction pipeline. The holder must:

"establish procedures in order to obtain accurate and verifiable data for the scientific evaluation of suspected adverse reaction reports"

Human Medicines Regulations 2012, regulation 188(1)(c)

Verifiable is the word that matters for a model. A value a reviewer cannot trace back to a sentence in the source is not verifiable data, however plausible it looks. That is why every field in a draft should carry its source span, and why a model that paraphrases rather than copies is the wrong tool for this job.

The scale of duplicate handling at the regulator end shows why it cannot be an afterthought. Table 5 of the EMA report counts the duplicate couples the agency itself assessed in EudraVigilance over three years.

The same table records 106,666 master reports generated from duplicated data in 2025, against 52,661 in 2024. The report attributes part of that jump to a change in the agency's weighing algorithm and to clearing smaller clusters of duplicates from Health Canada data, so it should not be read as duplicates doubling in the wild. What it does show is that duplicate detection is a standing, high volume activity at the EU regulator. UK holders carry their own duty under regulation 188(1)(e) to collaborate with the MHRA on duplicates.

For an extraction pilot, the lesson is to extract the identifiers that make matching possible, such as reporter, patient descriptors, product, event wording, dates and any reference numbers in the source, and to leave the matching decision to the safety system and its staff. A draft that silently merges two reports is a defect. A draft that surfaces a likely match for a person to confirm is useful. The same logic underpins our AI operating model work, which decides which steps a model drafts and which a named person signs off.

Where do case-processing errors show up in an MHRA inspection?

Case-processing errors show up in an MHRA inspection under the management of adverse drug reactions, which the inspectorate breaks into data entry, coding, assessment, follow-up and reporting. In the 2021 to 2022 metrics, findings in that area were dominated by case processing. Dilr Mira's role in that picture is narrow: a draft can reduce transcription errors at data entry, but coding, assessment and reporting remain inspected human work.

The detail is in section 3.1 of the MHRA metrics report for April 2021 to March 2022, the latest edition published. Under the routine pharmacovigilance activities arm, 16 findings were recorded against the management of adverse drug reactions, and all but one of those related to case processing. The severity and topic picture across all inspections is set out in our UK pharma guide, so it is not repeated here.

Read carefully, those numbers argue for discipline more than automation. Data entry, coding and follow-up are the steps where such a finding would land. A model that speeds up data entry but leaves no record of what it drafted, what a person changed and why, would make that evidence harder to produce, not easier. The broader inspection picture, including which topics carry the most findings, is set out in our UK pharma AI guide.

Should adverse event source documents leave the company to be extracted?

Adverse event source documents contain health data about patients, so whether they leave the company is a data protection and quality decision before it is a technology one. Dilr Mira runs on the holder's own hardware, so the documents never leave the building. Cloud services can be acceptable too, but only after the holder's own data protection and vendor assessment says so.

There are credible options on both sides. Amazon Comprehend Medical is a HIPAA-eligible cloud service that extracts medical information, links it to ontologies such as ICD-10-CM, RxNorm and SNOMED CT, and names pharmacovigilance as a use case. For a team already running safety workloads in that cloud under an agreed assessment, that ontology linking is a real advantage. John Snow Labs offers healthcare models it lists as available on-premise, alongside what it describes as more than 3,000 small language models for de-identification, entity, relation and code extraction, which suits a team that wants a mature licensed product with coding built in.

Dilr Mira sits at the other end of that spectrum. Mira-Q2 is open on Hugging Face under Apache-2.0, runs on a CPU and takes about 2 GB on disk, according to the Dilr Mira models page. That makes an air-gapped evaluation practical on ordinary hardware, which is useful when the first question is simply whether extraction helps on your documents at all. Our Dilr Mira overview covers the architecture in more depth.

The practical rule we would apply: decide the data boundary first, then choose the tool that fits inside it. In our view, choosing the tool first and negotiating the boundary afterwards moves the discovery of that constraint into validation, which is the most expensive place to make it.

What can Mira-Q2 do with a pharmacovigilance document today?

Mira-Q2, the current release of Dilr Mira, takes a schema and a document and returns source-grounded JSON, gated by a verifier that checks schema validity, grounding and identifier leaks. It was trained on clinical document types such as discharge summaries, lab reports and medication lists. Pharmacovigilance sources are not on that list, so a safety team should treat Mira-Q2 as a method to test on its own files, not a shipped pharmacovigilance product.

The published scorecard is the honest starting point. Across 782 evaluated documents in four test sets, Mira-Q2 recorded zero identifier leaks. JSON validity was 100.0% on held-out documents from its training distribution, 94.7% on real physician documents that matched its schema and 85.8% on real physician documents across 39 specialties, and field-level F1 of 1.000 applies to the held-out training-distribution set only. The Mira-Q2 model card is explicit that the model learned its synthetic generator's patterns and struggles with document types it never saw, naming operative notes and physical exams. Our evaluation write-up explains each set.

For a safety team, that gradient is the useful number. In our view a literature case report or a forwarded email sits further from Mira-Q2's trained document types than a discharge summary, so we would treat the 85.8% figure on general physician prose as a more cautious prior than the 100% figure. Neither set tested safety documents, so your own pilot should measure it directly.

Three boundaries are worth stating plainly:

• No MedDRA coding. Mira-Q2's vocabulary is grounded in real ICD-10 codes, NLM drug names and curated lab reference ranges. It does not claim MedDRA coding, so reaction terms should be extracted verbatim and coded by your existing coding tool and staff.
• No transmission output. Mira-Q2 produces JSON drafts to your schema. It does not produce E2B(R3) messages; that stays with the validated safety database.
• Drafts only. Outputs are drafts for human review, never autonomous clinical or safety decisions, and the models page says so in the same terms.

Pharmacovigilance is also not one of the research directions the models page lists, which are insurance claims, prior authorisation, KYC and onboarding, invoices and receipts, lab networks and legal intake. Applying the method to case intake is something we would scope and test inside a DATS engagement, the same way our KYC extraction guide treats banking documents. If a pilot goes well, an AI execution office can carry a proven placement into production inside your organisation.

What is the best way to pilot document extraction for case intake in 2026?

The best way to pilot document extraction for pharmacovigilance in 2026 is to test it on closed historic cases, where the correct answer already exists, before it touches a live case. Choose the tool by four criteria: where the data may go, how verifiable each field is, how the output maps onto your safety database, and whether coding is included. Dilr Mira fits an on-premise, verify-first pilot; other tools fit other priorities.

On those criteria, the honest verdict depends on the team. A holder whose safety data may be processed in a public cloud, and who wants ontology linking without building it, may be better served by Amazon Comprehend Medical. A holder who wants a mature licensed on-premise product with code extraction built in may prefer John Snow Labs. A holder who wants to prove, on its own hardware, whether extraction helps on its own documents before committing to anything is the case Mira-Q2 suits. Our comparison with general biomedical models explains what their headline numbers measure and why that differs from extraction.

The staged pilot we would run, built to survive an inspector's questions, looks like this:

1. Pick one stream. Literature articles or inbound emails, not both. Each has different failure modes.
2. Use closed cases. Take a few hundred historic cases where the safety database already holds the reviewed answer, and remove them from any live workflow.
3. Write the schema first. Name the fields from your safety database and the submission format it uses, and decide which may be blank.
4. Measure per field. Compare each extracted value with the reviewed record, and count wrong values separately from missing ones. A wrong value is the serious failure.
5. Record every change. Keep what the model drafted, what the reviewer changed and why. That record is the evidence an inspector would ask for.
6. Decide with numbers. Move to shadow use on live cases only if the per-field error rate on your own documents is one your qualified person responsible for pharmacovigilance (QPPV) and quality team will sign.

Our placement diagnostic, linked above, is the step before that sequence: a ranked roadmap of where AI belongs and where it does not, written before anything is built. For the wider industry view, see our posts on health insurance claims extraction and NHS discharge summary extraction, which apply the same draft-and-review boundary in other regulated document worlds.

Frequently asked questions

Does using an extraction model change who carries the reporting duty?

No. Under regulation 188 of the Human Medicines Regulations 2012 the reporting, follow-up and duplicate duties bind the holder of the marketing authorisation, not its software supplier. An extraction model such as Dilr Mira is a tool inside the holder's process. The holder still owns day zero, case validity, coding, assessment and submission, and its quality system has to show how the tool's output was checked.

That is also why the record of human review matters more than the model's headline accuracy. Our operating model service is where those responsibilities are written down.

Does the EMA literature monitoring service cover a UK holder?

The EMA's medical literature monitoring service monitors a number of substances and selected medical literature for holders reporting into EudraVigilance in the European Economic Area. A holder reporting to the MHRA for Great Britain should not assume the service discharges its own literature duty under regulation 188. Whether any carve-out applies depends on the authorisation type, so a safety team should confirm its position with its QPPV and regulatory affairs colleagues.

Literature can still suit a closed-case pilot, because articles are long and a reviewed historic case gives a ready answer key, but it is also the hardest stream, so measure it separately from emails or listings. Our clinical extraction guide covers how to set up that kind of test.

Can Dilr Mira code adverse reactions to MedDRA?

Dilr Mira does not claim MedDRA coding. Mira-Q2's published vocabulary grounding covers ICD-10 codes, NLM drug names and lab reference ranges, which is not the terminology a safety database uses for reactions. The sound pattern is for the model to extract the reporter's own words for each event, grounded in the source text, and for your existing coding tool and trained staff to assign the MedDRA term.

Keeping verbatim text alongside the coded term is good practice in any case, because it lets a reviewer check the coding decision against what the reporter actually said.

Want to test this on your own documents? See Dilr Mira models, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside regulated systems. Browse more industry deployment guides, or learn about Dilr.ai.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.