CONCEPTFOUNDATIONAL4 citations

ICSR and Spontaneous Reporting Data

Pharmacovigilance data made of individual case safety reports submitted by manufacturers, clinicians, patients, literature sources, and regulators to systems such as FAERS, VigiBase, and EudraVigilance; useful for safety signal generation and case review, but lacking a population denominator for incidence or comparative risk.

Data Sourceicsrindividual-case-safety-reportspontaneous-reportingpharmacovigilancefaersvigibaseeudravigilancemeddra

On this page

Methods reference only. Use primary source citations and local policy before applying this in a study protocol, regulatory submission, payer dossier, or clinical decision.

In plain language

ICSR data are safety reports, not a population study. They are useful because patients, clinicians, companies, and regulators can report suspected adverse events quickly, including rare or unexpected events. They are risky to overinterpret because nobody knows how many exposed patients did not report, duplicates are common, and publicity or label changes can create spikes in reporting that do not reflect true incidence.

When to use it

—Use this concept when the question is whether FAERS/VigiBase/EudraVigilance data are fit for a task.

—Generate and refine signals before commissioning a quantified risk evaluation.

—Search and prioritize cases, then move selected cases to detailed case-report adjudication.

Watch out for

—The data source alone is not an analysis method; disproportionality or clinical review must be specified.

—Cannot provide denominator-based absolute or comparative risk.

—Usually less clinically rich than a full published or chart-reviewed case report.

Individual Case Safety Reports (ICSRs)

are structured reports of suspected adverse events after exposure to a drug, biologic, vaccine, or device. In spontaneous reporting systems, the report is submitted because someone suspected a product-event relationship, not because the person was sampled from a known denominator. Systems such as FDA FAERS, WHO VigiBase, and EudraVigilance store ICSRs with patient demographics, suspect and concomitant products, reported events coded to MedDRA, seriousness, reporter type, dates, narrative elements, and follow-up versions. The unit is the report or case, not a clean patient-time record.

Core conceptual distinction

ICSR data are not claims, EHR, registry, or trial data. There is no source population, no complete exposure denominator, no reliable unexposed group, and no guarantee that non-reporting means non-occurrence. The data are built for pharmacovigilance triage: detecting unexpected patterns, reviewing case narratives, prioritizing signals, and supporting benefit-risk evaluation alongside other evidence. A count of 500 reports does not mean 500 incident cases in a population, and a larger count for Drug A than Drug B does not mean Drug A has higher risk. It may mean Drug A has more users, more publicity, a newer label warning, stimulated reporting, duplicate follow-up reports, or a reporter community more likely to submit cases.

The estimand is therefore a reporting phenomenon. Disproportionality analysis estimates whether a drug-event pair is reported more often than expected relative to the rest of the reporting database. Clinical case review assesses whether individual reports contain temporal, biologic, dechallenge, rechallenge, and alternative-cause evidence. Neither directly estimates incidence or causal effect without external denominators and designed follow-up.

Pros, cons, and trade-offs

vs claims/EHR denominator-based studies: ICSR systems are fast, broad, and can capture rare, unexpected, serious, or poorly coded events that claims algorithms may miss. Cost: no denominator, high reporting bias, duplicates, missing clinical detail, and weak confounding control. Prefer ICSRs for signal generation and case characterization; prefer claims/EHR cohorts for quantified risk.
vs registries: Product or disease registries can impose scheduled follow-up and collect denominators, but are slower and narrower. ICSR data cover many products and countries but with uncontrolled reporting. Prefer registries when the question is incidence, pregnancy outcome rate, or long-term follow-up.
vs literature case reports: Published case reports often provide rich narratives and timelines, while ICSR extracts provide scale and standard coded fields. Literature reports are publication-biased; ICSR databases are reporting-biased. Use them together when adjudicating a serious or novel signal.
vs social media or patient forums: Social sources may detect patient concerns early, but ICSRs have regulatory reporting structures, seriousness fields, product coding, and follow-up workflows. Prefer ICSRs for regulated pharmacovigilance triage.

When NOT to use - and when it is actively misleading

Do not calculate incidence, prevalence, absolute risk, or reporting rate per exposed patient unless an external denominator is introduced and its limitations are explicit.
Do not compare raw report counts across products as comparative safety. Counts are driven by utilization, age on market, notoriety, litigation, media attention, manufacturer reporting practices, geography, and label changes.
Do not treat a disproportionality signal as proof of causality. A signal of disproportionate reporting is a screening result that requires clinical review and usually a designed study.
Do not ignore duplicate case versions. FAERS and other systems can contain initial and follow-up reports, multiple reporters, literature duplicates, and manufacturer/regulator transmissions of the same underlying case.
Do not pool spontaneous, solicited, literature, registry, and patient-support-program reports without stratification or source flags. Reporting mechanisms differ enough to change the analysis.

Data-source operational depth

FAERS/FDA public extracts: FAERS quarterly data are relational extracts, not analysis-ready patient records. Analysts must deduplicate by case/version logic, normalize product names and active ingredients, handle suspect versus concomitant roles, map MedDRA preferred terms or SMQs, and preserve report dates and event dates separately. Public extracts are de-identified and may omit narrative detail needed for causality assessment.
VigiBase/WHO-UMC: VigiBase has global breadth and mature duplicate detection workflows, but access, variables, and permissible outputs are governed by WHO-UMC and national center rules. Cross-country reporting culture and regulatory requirements can dominate product-event patterns.
EudraVigilance/EMA: EudraVigilance supports EU pharmacovigilance and uses ICH E2B-compatible ICSR structures. Public analysis requires attention to European reporting rules, null-flavor handling, and medicinal-product coding.
Claims/EHR linkage: Linking ICSR-derived signals to claims or EHR is usually indirect: use the signal to define a case definition, risk window, comparator, and target-trial or self-controlled design. Do not join reports to claims as if they were outcome records unless a formal linkage exists.

Worked example

A reviewer sees 240 FAERS reports mentioning Drug X and pancreatitis in a quarterly extract. After deduplication, 170 unique case IDs remain. Of those, 90 list Drug X as primary suspect, 35 as secondary suspect, and 45 only as concomitant. Time-to-onset is missing in 70 cases. Twenty reports are from a patient-support program, and 15 are literature reports that may overlap with manufacturer submissions. A disproportionality screen flags the pair. The correct conclusion is not "Drug X causes pancreatitis at a high rate." The correct conclusion is: "Drug X-pancreatitis is a signal of disproportionate reporting after deduplication, concentrated in primary-suspect reports, with incomplete timing and mixed report sources; clinical review should assess alternative causes and dechallenge/rechallenge, and a denominator-based cohort or self-controlled study is needed to quantify risk."

Worked example

Scenario

A safety analyst reviews Drug X and pancreatitis reports from a spontaneous-reporting database. The raw report count looks large, but deduplication, product role, report source, and missing timing materially change interpretation.

Dataset

Simplified ICSR review counts for Drug X and pancreatitis.

review_step	count	interpretation
raw_reports_mentioning_drug_x_and_pancreatitis	240	includes follow-up versions and possible duplicates
unique_cases_after_deduplication	170	case-level review denominator
primary_suspect_drug_x	90	strongest product-role subset for review
secondary_suspect_drug_x	35	still relevant but weaker attribution
concomitant_only_drug_x	45	poor evidence that Drug X was suspected
missing_time_to_onset	70	limits causality assessment and latency review

Steps

1Deduplicate initial and follow-up reports before counting cases.

2Separate primary suspect, secondary suspect, interacting, and concomitant product roles.

3Stratify by report source, such as spontaneous, solicited, literature, and patient-support program.

4Review time-to-onset, dechallenge, rechallenge, alternative causes, and seriousness fields.

5Use disproportionality as a screening tool, then move to denominator-based data if risk quantification is needed.

Result

The database supports a signal-review statement, not an incidence estimate or causal risk ratio.

Trade-offs

vs. Signal Detection (Disproportionality Analysis)

Pros of this

—Names the underlying data substrate and its cleaning, coding, and interpretation issues.

vs. Risk Evaluation Study (Post-Authorization Safety / Active Surveillance)

Pros of this

—Faster and broader for unexpected signals.

vs. Case Report

Pros of this

—Scales across many cases and products with standardized fields.

Citations

FOUNDATIONAL / METHODS

APPLIED EXAMPLES

[4]Bate A, Evans SJW. Quantitative signal detection using spontaneous ADR reporting. Pharmacoepidemiology and Drug Safety. 2009;18(6):427-436.