Every safety team automates case processing eventually. The question is when. The answer is rarely a single event; it is a set of signs that build up until the team is spending most of its time keeping up rather than thinking.
Below are five of the most common signs, what each one costs you, and what to measure so that the decision to automate rests on your own data. First, a reminder of the fixed points that every case processing operation has to meet.
The fixed points
Whatever your volumes or tools, a few requirements do not change.
- Validity. Under EU GVP Module VI (section VI.B.2), a valid case needs four minimum criteria: an identifiable reporter, a single identifiable patient, at least one suspected product and at least one suspected adverse reaction.
- Day zero. The clock starts on the first day a marketing authorisation holder knows about a valid case (section VI.B.7).
- Deadlines. In the EU, Directive 2001/83/EC, Article 107(3), requires serious suspected adverse reactions within 15 days and non-serious EU reactions within 90 days. In the US, 21 CFR 314.80 requires a 15-day alert report for serious and unexpected adverse drug experiences, no later than 15 calendar days from initial receipt.
- Traceability. Under 21 CFR 11.10(e), electronic record systems need secure, computer-generated, time-stamped audit trails that record operator entries and actions, without obscuring what was recorded before.
The CIOMS Working Group XIV report on AI in pharmacovigilance lists the areas where AI is already used in case processing: duplicate detection, coding of adverse events and products, extraction of information from narratives, and triage of incoming reports for human review. Those are exactly the steps where the five signs below tend to appear.
1. Experts are doing data entry
If qualified safety scientists spend most of their day copying information from emails, PDFs and forms into the safety database, you are paying for expertise and using it for transcription. It also means the people best placed to spot a safety concern are the ones with the least time to look.
What automation changes: source documents are read and the case fields are pre-filled, each value linked back to where it came from. The expert reviews and confirms rather than types.
What to measure: the share of handling time spent on data entry, from a short time study of a sample of cases.
2. Volume spikes put deadlines at risk
A product launch, a patient support programme, a media story or a partner sending a backlog can multiply intake overnight. The 15-day clock does not stretch to match. If late or near-late submissions follow every spike, your capacity depends too heavily on how many people you can add, and how quickly.
What automation changes: intake, validity checks and duplicate checks run at the speed cases arrive, and cases are ranked by seriousness and deadline so the most urgent reach a reviewer first.
What to measure: on-time submission rate by month, set against intake volume by month. If the two move together, you have found the pattern.
3. The same case is handled again and again
When intake, data entry, coding, review, quality control and submission happen in different tools, each hand-off is a chance to re-key information, wait in a queue or lose context. The case is touched many times, and each touch adds time without adding judgement.
What automation changes: one case record moves through the whole process. People step in at defined review gates, set by your SOPs, rather than at every hand-off.
What to measure: the number of hand-offs per case and the time cases spend waiting between steps, from your tracker or safety database timestamps.
4. Coding is inconsistent
MedDRA is a large, detailed terminology, and two careful coders can choose different terms for the same verbatim text. ICH publishes the MedDRA Term Selection: Points to Consider document precisely to promote accurate and consistent term selection. Inconsistent coding does not stay in the case: it flows into signal detection, where similar events may be split across terms, and into periodic reports.
What automation changes: the system suggests terms based on your coding conventions and past decisions, shows why, and flags anything unusual for a coder to confirm. Every coder starts from the same suggestion.
What to measure: agreement between coders on a sample of the same verbatim terms, and the number of coding corrections found at QC.
5. Inspection preparation takes weeks
An inspector may pick any case and ask how it was handled: who received it, when the clock started, why it was classed as serious or not, who coded it, who reviewed it and when it was submitted. If answering means searching mailboxes, shared drives and spreadsheets, your traceability depends on people remembering, not on systems recording.
What automation changes: every action, human or automated, is recorded in one time-stamped audit trail, with the source of each value and the model version behind each suggestion.
What to measure: the time it takes to reconstruct the full history of a randomly chosen case.
A quick self-assessment
| Sign | You will notice | Measure first |
|---|---|---|
| Experts doing data entry | Senior staff typing, not reviewing | Share of handling time on data entry |
| Volume spikes | Late or near-late cases after peaks | On-time rate against monthly intake |
| Repeated handling | Cases waiting between teams and tools | Hand-offs and waiting time per case |
| Inconsistent coding | Corrections at QC, split terms in signals | Coder agreement on a shared sample |
| Slow inspection preparation | Weeks spent rebuilding case histories | Time to reconstruct one case |
If two or more of these sound familiar, it is worth building a baseline now. If four or five do, your team is very likely spending expert time on work a platform should be doing.
What should not be automated
Automation should take on the work that follows rules and patterns. It should not take over medical judgement. Company causality assessment, the final decision on seriousness and expectedness where there is doubt, and the medical sense of a narrative belong with qualified people. The CIOMS report’s principle of human oversight is a useful test: for every step, decide whether the human is in the loop (making the decision with machine support) or on the loop (checking what the machine returns), and write that into your SOPs.
Before you start
- Collect the baselines above. Even rough numbers are better than none.
- Review your SOPs. Automation makes your procedures explicit. Gaps between what the SOP says and what people actually do will surface quickly.
- Agree the review gates. Decide with QA where a person must confirm, and where a person samples.
- Plan validation from day one. Validation evidence is far easier to produce as the system is configured than afterwards.
Sources
- EMA, Guideline on good pharmacovigilance practices (GVP) Module VI, Rev 2
- Directive 2001/83/EC, Title IX, Chapter 3 (Article 107)
- 21 CFR 314.80, Postmarketing reporting of adverse drug experiences
- 21 CFR 11.10, Controls for closed systems
- RAPS, “ICH releases updated MedDRA guidance” (MedDRA Term Selection: Points to Consider)
- CIOMS Working Group XIV, Artificial Intelligence in Pharmacovigilance (report published 4 December 2025)
- Sagittal, “AI in PV: what the CIOMS WG XIV report means in practice” (list of the seven principles)