ICSR Processing Workflow: Intake to Submission

Individual case safety report (ICSR) processing is the internal workflow a pharmacovigilance department or its outsourced partner runs on every incoming report of a suspected adverse reaction — from the moment a case is first heard about to the moment it is submitted to a regulator and closed. This guide walks through that workflow end to end: intake, triage, duplicate detection, data entry and coding, causality assessment, medical review, quality control, submission, and follow-up. It deliberately covers the process a case moves through, not a single regulator’s rulebook for it.

How this differs from GVP Module VI and EudraVigilance reporting

Two closely related CASRAI guides cover adjacent ground, and it’s worth being precise about the boundary before going further:

• GVP Module VI is the EU regulatory text that defines what a valid ICSR is, how solicited and spontaneous reports are distinguished, and the 15-day/90-day EudraVigilance reporting clocks. It’s a rulebook: what the case must contain and when it’s legally due.
• EudraVigilance reporting covers the mechanics of one specific submission destination: organisation registration, EVWEB versus gateway transmission, and the E2B(R3) message format a case is submitted in.
• This guide covers the operational workflow a case-processing team actually runs to get from “a report just arrived” to “a compliant case is submitted and closed” — the sequence of work applies whichever regulator a given case is ultimately reported to (EudraVigilance, FDA FAERS, PMDA, Health Canada, or a licensing partner under a safety data exchange agreement), and the roles, checks, and quality controls involved are broadly the same across all of them even though the destination-specific deadlines and formats differ.

Read this guide for the workflow and the people/quality-control model behind it; read the other two for EU-specific validity rules and submission mechanics respectively.

Step 1: Case receipt and intake channels

A case can arrive through a wide range of channels, and part of intake is simply recognising that a piece of incoming information might qualify as a reportable case at all:

• Direct spontaneous contact — a patient, caregiver, or healthcare professional calling a company’s medical information line, emailing, or using a web-based reporting form.
• Solicited programmes — patient support programmes, market-research surveys, and post-authorisation safety studies, which generate a structured but higher volume of reports that still need individual case handling.
• Literature — published case reports and studies identified through a documented literature-screening process.
• Digital and social media — company-owned or sponsored digital channels, which most pharmacovigilance SOPs now explicitly include in scope for adverse-event monitoring.
• Partners and licensees — cases exchanged under a safety data exchange agreement (SDEA) with a co-marketing or licensing partner, on an agreed transmission schedule and format.
• Clinical trial sites — investigator-reported events flowing through the trial’s own safety reporting chain, which converge with post-authorisation intake once a product is also marketed.

Every intake channel needs a single point of entry into the case-processing system so that nothing arriving through an unusual route (a comment on a company social account, a case forwarded by a distributor) gets missed simply because it didn’t come through the expected front door.

Step 2: Triage and validity determination

Triage is the first substantive decision point: does this piece of information actually constitute a case, and if so, how urgent is it? Triage checks a report against the standard minimum criteria for a valid ICSR — an identifiable reporter, an identifiable patient, at least one suspect product, and at least one suspected adverse reaction (see GVP Module VI for the EU’s specific articulation of these four elements) — and simultaneously makes a first-pass seriousness call, because seriousness is what determines which reporting clock applies once the case is validated. A report missing one of the four elements isn’t discarded; it’s flagged for follow-up to close the gap, with the follow-up attempt itself documented as part of the case record.

Step 3: Duplicate detection and case linkage

The same real-world adverse event routinely reaches a company through more than one channel — a patient calls the company directly, and the same event later surfaces in a published case report or a partner’s SDEA transmission. Before a case is worked further, it’s searched against the existing case database for a likely duplicate (matching patient, product, and event characteristics). A genuine duplicate is linked to the original case rather than processed and submitted as a second, independent one, since double-counting the same event distorts aggregate signal-detection statistics downstream. This check sits early in the workflow specifically so effort isn’t spent fully processing a case that turns out to already exist.

Step 4: Data entry and coding

Once a case is confirmed as new, its content is entered into the safety database in structured form — patient and reporter details, product and dosing information, and a narrative description of the event. The verbatim terms a reporter used (“felt queasy,” “throwing up”) are then coded to standardised terminology rather than left as free text:

• Adverse event terms are coded to MedDRA, typically at the Lowest Level Term (LLT), which maps to exactly one Preferred Term (PT) for aggregate reporting and signal detection.
• Product terms for the suspect and concomitant medications are coded to a standardised drug dictionary (WHODrug, maintained by the Uppsala Monitoring Centre, is the most widely used).

Coding consistency matters more than it might first appear: two coders describing the same clinical event with different PTs splits what should be one signal into two smaller, less visible ones in aggregate analysis, which is exactly why coding conventions and coder training are a recurring inspection focus (see MedDRA Coding for Trial Safety Data for a deeper look at coding practice itself).

Step 5: Causality assessment

Causality assessment asks how likely it is that the suspect product actually caused the reported event, as opposed to the event being coincidental, explained by the underlying condition, or attributable to a concomitant medication. For solicited reports especially — where the reporting mechanism itself invites reporting regardless of suspected relatedness — a causality judgment has to be made rather than assumed. Two structured algorithms are in common use: the WHO-UMC system (six categories: Certain, Probable/Likely, Possible, Unlikely, Conditional/Unclassified, Unassessable/Unclassifiable) and the Naranjo Adverse Drug Reaction Probability Scale (a ten-item weighted questionnaire scoring -4 to +13, banded into definite/probable/possible/doubtful). Published inter-rater reliability studies on both scales report only fair-to-moderate agreement between independent assessors, and one head-to-head comparison found the two systems classified the same 399 cases very differently (WHO-UMC: 53.3% “Certain”; Naranjo: 96.74% “Probable”) — a reminder that causality assessment is a structured judgment call, not a deterministic calculation, and that a documented rationale matters as much as the resulting category.

Step 6: Medical review

Before a case is finalised, a medically qualified reviewer — typically a physician or other clinically trained safety professional — reviews the narrative, the coding, the causality assessment, and the seriousness and expectedness classification (whether the event is already described in the product’s reference safety information, which determines whether it’s expedited-reportable as unexpected). Medical review is where clinical judgment is applied to a case that has, up to this point, mostly been processed against structured rules: confirming the coded terms actually reflect the clinical picture described, that the causality assessment is defensible, and that nothing in the narrative suggests a special situation (pregnancy exposure, overdose, off-label use, lack of efficacy) that changes how the case should be classified.

Step 7: Quality control

Most mature ICSR processes run at least two layers of quality check before submission: a process-level QC confirming the case is complete, correctly coded, and internally consistent, and a second, often separate, clinical/medical-content QC re-checking the medical reviewer’s judgment calls on causality, seriousness, and expectedness. Running these as genuinely separate checks — not the same person checking their own work twice — is what catches the kind of error a single reviewer is structurally unlikely to catch in their own case: a coding-narrative mismatch, an inconsistent causality call across similar cases, or a missed special-situation flag.

Step 8: Submission and routing

A validated, QC’d case is then routed to wherever it’s actually due: the EU’s EudraVigilance database (see EudraVigilance Reporting for EVWEB versus gateway transmission and the E2B format), FDA’s FAERS, another national regulator, and/or a licensing partner under the SDEA that governs case exchange with them. A single case frequently has more than one legitimate destination — a serious case for a globally marketed product may be reportable to several regulators on several different clocks simultaneously — so routing logic has to track destination-specific obligations per product and market, not assume one submission closes the case everywhere it’s owed.

Step 9: Follow-up and case closure

A case is rarely complete on first submission. Meaningful new information — a hospital discharge summary, a lab result, an outcome update for a pregnancy-exposure case — triggers a follow-up report, which is processed through the same coding/causality/medical-review/QC sequence as the initial case and typically restarts the relevant reporting clock for that follow-up. A case is formally closed only once no further follow-up is expected or reasonably obtainable, with the closure decision itself documented, since “we stopped trying to follow up” and “the case is genuinely complete” need to be distinguishable in an audit.

Measuring the process: cycle time and quality metrics

Because reporting deadlines are measured in calendar days from the moment a company becomes aware of a case (“day zero”), case-processing teams typically track their own internal cycle time at each step (receipt to triage, triage to medical review, medical review to submission) against the applicable regulatory clock, building in margin rather than processing to the deadline itself. Common quality metrics alongside cycle time include on-time submission rate, QC pass rate at first review, and coding-consistency audits across a sample of cases coded by different staff. None of these are regulatory requirements in themselves, but a process that can’t demonstrate it reliably meets its own internal targets is a common finding in an inspection of the wider pharmacovigilance system.

In-house, outsourced, or hybrid processing

Case volume, therapeutic area complexity, and headcount economics all factor into whether an organisation processes ICSRs entirely in-house, outsources some or all of the workflow to a specialised pharmacovigilance CRO or business-process partner, or runs a hybrid split (for example, keeping medical review in-house while outsourcing intake and data entry). Whichever model is used, the underlying workflow above doesn’t change, and neither does accountability: outsourcing case-processing tasks does not transfer the marketing authorisation holder’s own regulatory responsibility for the accuracy and timeliness of what gets submitted, which is why a written agreement defining exactly which steps a vendor performs, and where oversight and final sign-off sit, is a standard part of any outsourcing arrangement in this space.

Frequently asked questions

What’s the difference between “ICSR processing” and “ICSR management”?

In practice the terms are used interchangeably. Where a distinction is drawn, “processing” tends to refer to the operational workflow covered on this page (intake through submission and closure), while “management” more often refers to the governing rules a regulator sets for that workflow, such as GVP Module VI‘s validity criteria and timelines.

Does every case go through causality assessment?

Every case needs a causality judgment recorded, but how it’s reached differs. A spontaneous report carries an inherent implication of causality from the reporter making the report in the first place; a solicited report (from a patient support programme or study, for example) needs an explicit structured assessment, since the collection method itself invites reporting regardless of suspected relatedness.

Who is qualified to perform medical review of an ICSR?

Typically a physician or another clinically trained pharmacovigilance professional with case-review experience. The specific qualification bar is set by an organisation’s own SOPs and its QPPV‘s oversight of the pharmacovigilance system, rather than by a single universal regulatory credential requirement.

Why does outsourcing case processing not remove regulatory responsibility?

Because the reporting obligation attaches to the marketing authorisation holder (or trial sponsor) as a legal entity, not to whichever staff or vendor happens to key in the data. A CRO or BPO partner can perform any or all of the operational steps above under a written agreement, but the company that holds the marketing authorisation remains accountable for the accuracy, completeness, and timeliness of what’s ultimately submitted under its name.

For the EU regulatory rulebook this workflow has to satisfy, see GVP Module VI: ICSR Collection, Validation, and Reporting Timelines. For the mechanics of the EudraVigilance submission destination specifically, see EudraVigilance Reporting. For the broader clinical-trial AE/SAE/SUSAR workflow this process connects to upstream, see Pharmacovigilance in Clinical Research. For the organisational backbone a pharmacovigilance system runs on, see the PSMF and the QPPV role.