Adverse Event Intake vs. Full Pharmacovigilance: What Is the Difference?

Adverse event intake and pharmacovigilance are not the same thing. Intake is a specific, bounded function within the broader PV system. If you are designing or evaluating your safety program and using these terms interchangeably, you are likely either overbuilding in one area or leaving a material gap in another.

This distinction matters especially for small biotech IND sponsors who are building their first pharmacovigilance infrastructure. Understanding what each function covers, what it requires, and where they connect will help you design a program that is proportionate to your stage, compliant with FDA expectations, and defensible under inspection.

What Is Full Pharmacovigilance?

Pharmacovigilance, as defined by ICH E2E and reflected in FDA regulatory expectations, is the science and activities relating to the detection, assessment, understanding, and prevention of adverse effects or any other drug-related problem. It is a system, not a task.

A full pharmacovigilance system for an IND sponsor includes all of the following:

• A written Pharmacovigilance Plan aligned with the study protocol and Investigator Brochure
• Defined processes for receipt, triage, and processing of Individual Case Safety Reports from all sources, including clinical sites, spontaneous reports, literature, and company-initiated sources
• Medical review and causality assessment for each case
• MedDRA coding of adverse event terms
• Expectedness assessment against the current Investigator Brochure or reference safety information
• Regulatory submission of expedited reports to the FDA within 7-day or 15-day timelines under 21 CFR 312.32
• Aggregate safety analysis and signal detection across the accumulating case dataset
• Development Safety Update Report (DSUR) preparation and submission
• SOPs governing every step of the case lifecycle from receipt through submission and reconciliation
• Qualified Person for Pharmacovigilance oversight or equivalent safety physician accountability
• A validated system of record for case management, typically a pharmacovigilance database

This is a significant operational infrastructure. For large sponsors and MAHs running multiple marketed products, it requires dedicated safety teams, enterprise pharmacovigilance databases like Veeva Vault Safety or Oracle Argus, and extensive process documentation. For small biotechs at the IND stage, the scope is narrower but the structural requirements are the same.

What Is Adverse Event Intake?

Adverse event intake is specifically the front end of the pharmacovigilance system. It covers the structured receipt, initial triage, and minimum data capture of a potential adverse event report from the moment of first contact through the point at which a valid case is confirmed and handed off to case processing.

Intake includes:

• Receiving a report through whatever channel it arrives, including site phone call, email, patient-reported form, or CRO transmission
• Capturing minimum valid case criteria: an identifiable patient, an identifiable reporter, a suspect product, and an adverse event
• Collecting structured data elements required for ICSR preparation, including reporter qualification, patient demographics, event details, product information, and seriousness criteria
• Assigning a clock-start date (Day 0) based on the date of first receipt of information meeting minimum valid case criteria
• Generating an initial triage determination on seriousness, expectedness, and applicable reporting timeline
• Creating a case record in the system of record and initiating the case processing workflow

Intake does not include medical review, final causality assessment, MedDRA coding, aggregate signal analysis, or regulatory submission. Those are downstream case processing and PV system functions.

Side by Side: Where Each Function Lives

Here is how the two functions map against the full ICSR lifecycle:

Why This Distinction Matters for Program Design

Most small biotech IND sponsors do not run their pharmacovigilance in-house. They outsource the full PV function to a CRO, a pharmacovigilance service provider, or a part-time contracted safety physician. That is a completely appropriate model for an early-phase program with limited case volume.

What many of those same sponsors fail to design properly is the intake layer, which sits between the clinical site and the outsourced PV function. They assume the CRO handles it. Sometimes the CRO does handle intake, but often there is a gap: the site calls the sponsor, the sponsor logs a note in an email thread or spreadsheet, and that unstructured record eventually makes its way to the CRO days later with missing data elements.

When intake is poorly designed, even a fully capable outsourced PV function cannot save you from downstream problems. The data quality issues, clock-start disputes, and missing fields created at intake will follow the case through the entire lifecycle and can result in late submissions, incomplete ICSRs, and inspection findings.

Right-Sizing Your Safety Infrastructure

The right model for most small biotech IND sponsors is a clear division of responsibility:

• Structured intake handled in-house or via a purpose-built intake platform, ensuring all incoming reports are captured in a validated system with complete minimum data elements, documented clock-start dates, and an initial triage record.
• Full PV case processing and submission handled by your outsourced safety partner, who receives structured, complete case data from your intake system rather than reconstructing case details from unstructured emails and partial CRF notes.

This model works because it puts the right work in the right place. Your internal team or intake platform captures what only you can capture at the moment of first contact. Your outsourced safety team applies the medical expertise and submission infrastructure they are set up to provide. The handoff between the two is clean, documented, and auditable.

It also scales appropriately. If your program grows and case volume increases, the intake layer can expand without requiring you to rebuild the entire PV infrastructure. If you eventually bring PV in-house, the structured intake data you have been accumulating gives you a clean foundation to build from.

The Connection to E2B(R3) Compliance

The ICH E2B(R3) mandatory submission deadline reinforces why this distinction matters. E2B(R3) requires structured, validated data elements across dozens of fields in the ICSR XML. The quality of your E2B(R3) submission is directly determined by the quality of your intake data.

If your intake process is capturing the right fields at the time of first report receipt, including reporter qualification, patient demographics, event onset date, seriousness criteria, and product information, your outsourced safety team or submission platform can build a complete, compliant ICSR without significant rework. If your intake process is a free-text email chain, your safety team is rebuilding the case from scratch on a compressed regulatory timeline.

A structured intake layer that feeds into your broader PV system is not a luxury. Under E2B(R3), it is foundational to your ability to submit compliant ICSRs on time.