EudraVigilance Reporting: A Practical Guide to ICSR Submission

Introduction

EudraVigilance reporting is one of the most visible and heavily regulated pharmacovigilance activities performed by Marketing Authorisation Holders (MAHs).

Every day, thousands of Individual Case Safety Reports (ICSRs) are transmitted to EudraVigilance by pharmaceutical companies, regulators and other stakeholders.

While the technical process of transmitting a report may appear straightforward, maintaining compliance requires much more than simply pressing a submit button.

Organisations must ensure:

• Accurate case processing
• Appropriate coding
• Timely submissions
• Successful transmission
• Successful acceptance
• Ongoing reconciliation
• Effective oversight

Failures at any stage can result in regulatory non-compliance and inspection findings.

What is an ICSR?

An Individual Case Safety Report (ICSR) documents a suspected adverse reaction associated with a medicinal product.

A valid case generally requires:

• An identifiable patient
• An identifiable reporter
• A suspect medicinal product
• A suspected adverse reaction

Without these minimum criteria a report may not be considered valid for regulatory reporting purposes.

For an overview of EudraVigilance itself see:

[[what-is-eudravigilance]]

Regulatory Reporting Requirements

Within the European Union, MAHs are required to submit suspected adverse reactions to EudraVigilance in accordance with applicable legislation and guidance (including GVP Module VI and implementing regulations). Reporting obligations may apply to:

• Serious adverse reactions
• Non-serious adverse reactions
• Follow-up information
• Literature cases
• Solicited reports

Requirements vary depending on the nature of the report and applicable regulations; MAHs must ensure that internal procedures translate regulatory requirements into operational deadlines and controls.

E2B(R3): The Foundation of Electronic Reporting

Modern EudraVigilance reporting relies on the ICH E2B(R3) standard.

E2B(R3) defines:

• Data structures
• Message formats
• Validation rules
• Mandatory fields

The standard allows safety information to be exchanged consistently between companies and regulators. Organisations should maintain up-to-date mapping specifications between local safety systems and E2B(R3), and evidence of system validation to support inspection readiness.

EVWEB

EVWEB is the EMA web-based reporting platform.

It enables authorised users to:

• Create reports manually
• Submit reports
• Review acknowledgements
• Manage reporting activities

EVWEB is commonly used by:

• Smaller MAHs
• Organisations with lower reporting volumes
• Users requiring manual submission capability

Because EVWEB is browser-based, it generally requires less technical infrastructure than gateway reporting. SOPs should specify when EVWEB is used as fallback or primary channel, who is authorised, and how evidence of submission is stored.

Gateway Reporting

Many larger organisations use automated gateway connections.

Gateway reporting allows:

• Direct system-to-system communication
• Automated report submission
• High-volume processing
• Reduced manual intervention

The process typically involves:

1. Case processing
2. E2B(R3) generation
3. Gateway transmission
4. Validation
5. Acknowledgement receipt

Gateway reporting improves efficiency but introduces additional technical governance requirements such as supplier qualification, secure certificates, system validation and periodic connectivity testing.

EVWEB Versus Gateway Reporting

Neither method is inherently superior. The appropriate approach depends on organisational requirements and reporting volume. Importantly, governance, audit trails and documented evidence must be equivalent irrespective of the chosen channel.

Understanding Acknowledgements

One of the most common misunderstandings in pharmacovigilance reporting is the assumption that successful submission automatically means successful reporting.

In reality, submission is only one stage of the process.

After transmission, EudraVigilance validates the report and returns acknowledgement messages indicating whether:

• The report was accepted (positive acknowledgement)
• The report was rejected (error)
• Warnings were generated
• Further action (e.g., resubmission, amendment, nullification) is required

Organisations must capture and act on acknowledgement messages as a core part of their submission lifecycle.

Why Acknowledgements Matter

A rejected report may never enter the regulatory database.

Failure to monitor acknowledgements can therefore result in:

• Missed reporting timelines
• Incomplete submissions
• Compliance failures
• Inspection findings

Organisations should maintain procedures describing how acknowledgements are reviewed and escalated, preserve acknowledgement messages as evidence, and reconcile acknowledgement status with internal case records.

Common Reasons for Rejection

Common validation issues include:

• Missing mandatory fields required by E2B(R3)
• Invalid coding (e.g., MedDRA terms, ATC, country codes)
• Product information errors (incorrect VIPPS/MAH identifiers)
• Structural E2B(R3) issues (schema validation errors)
• Duplicate submissions
• Invalid date or format values

Trend analysis of validation failures can help identify underlying process weaknesses and form the basis for corrective actions.

Follow-Up Reporting

Case information frequently evolves after initial submission.

Additional information may include:

• Outcome information
• Laboratory results
• Diagnostic confirmation
• Medical assessments

Follow-up reports ensure that regulators receive the most complete safety information available. Procedures should define prioritisation rules for clinically significant follow-ups and describe the linkage mechanism in E2B(R3) between initial and follow-up messages.

Nullifications and Amendments

Occasionally reports require correction.

Situations may include:

• Duplicate reports
• Administrative errors
• Invalid submissions

EudraVigilance provides mechanisms for:

• Amendments (corrections or updates to an accepted case)
• Corrections (resubmission of corrected message)
• Nullifications (withdrawal of a previously accepted report in specific circumstances)

Nullification and amendment processes must be documented, authorised and supported by evidence in the case file. Inspectors expect to see justification for nullifications and an audit trail demonstrating appropriate approvals.

Reporting Compliance Monitoring

Effective organisations monitor reporting performance continuously.

Typical metrics include:

• On-time reporting
• Late submissions
• Rejected reports
• Resubmission rates
• Acknowledgement review completion
• Time to resolution for rejected messages

Metrics help identify trends before they become regulatory issues and provide data for governance reporting to the QPPV and senior management.

Reconciliation Activities

Reconciliation verifies that submitted reports have been successfully transmitted, accepted and appropriately processed.

Reconciliation may compare:

• Internal databases
• Submission records
• EudraVigilance data
• Acknowledgement records

The objective is to identify discrepancies and ensure data integrity. Reconciliation processes should include frequency (e.g., weekly/monthly), responsible personnel, escalation paths, and evidence retention policies.

QPPV Oversight

The QPPV is not expected to submit individual reports personally.

However, regulators generally expect the QPPV to maintain oversight of reporting compliance.

This includes visibility of:

• Timeliness performance
• Significant deviations
• Reporting failures
• Escalations
• Compliance metrics

The QPPV should be informed of material issues that may affect regulatory compliance. Governance structures should clearly describe delegations, reporting lines and the mechanism by which the QPPV exercises oversight (e.g., dashboards, periodic reviews, exceptions reports).

Inspection Perspective

Reporting activities are routinely reviewed during pharmacovigilance inspections.

Inspectors commonly examine:

• Reporting procedures (SOPs)
• Timeliness metrics
• Acknowledgement management
• Reconciliation activities
• Deviation handling
• Governance arrangements
• Vendor oversight and supplier agreements
• Evidence of system validation and test submissions

Evidence demonstrating that the reporting process operates effectively is often as important as the process itself. Inspectors expect an audit trail showing who performed each step, when, and what corrective actions were initiated for failures.

Common Inspection Findings

Frequently observed deficiencies include:

• Late reporting
• Failure to review acknowledgements
• Missing reconciliation activities
• Inadequate deviation management
• Poor oversight of outsourced reporting activities
• Insufficient compliance monitoring
• Missing training records for users authorised to submit or review acknowledgements
• Weak change control or undocumented mapping changes between safety systems and E2B(R3)

Many findings arise because organisations focus on transmission while overlooking governance controls.

Inspection-Ready Procedural Checklist

The following checklist is intended to make the reporting function inspection-ready. Each item should have documentary evidence available (SOPs, records, logs, screenshots, signed approvals).

Operational controls (process and system evidence) - Written SOPs covering: - Case intake and triage - Case validation and coding - E2B(R3) message generation and mapping - Submission pathways (EVWEB and/or Gateway) - Acknowledgement handling, escalation and resubmission - Follow-up, amendment and nullification procedures - Reconciliation and metrics - Vendor oversight, responsibility matrices and third-party reporting arrangements - Role-based access control lists and authorisation logs for EVWEB and gateway accounts - Training records for all staff with reporting responsibilities (initial and periodic refreshers) - Evidence of system validation for safety database, E2B(R3) generator and gateway interfaces (validation summary report and traceability) - Test submission logs (connectivity test results and successful test acknowledgements) - Live submission logs and a retention policy for acknowledgement files (raw XML or message files) - Audit trails showing user, timestamp, action performed and reason for change for case edits - Reconciliation logs comparing internal case counts to submissions and EudraVigilance receipts - Deviation logs with impact assessments, root cause analyses and CAPA plans - Change control records for mapping changes, software releases or infrastructure changes - Supplier qualification files and periodic monitoring records for vendors handling submissions - Evidence for each nullification and amendment (business justification, approvals, and correspondence) - Metrics dashboards and QPPV governance reports showing trends and exceptions - Templates and checklists for resubmission and amendment workflows

Documentary artifacts (what to show an inspector) - SOPs referenced above - Representative case files demonstrating lifecycle (intake → submission → acknowledgement → follow-up/amendment/nullification) - Recent acknowledgement files (accepted/warning/rejected) with documented action taken - Reconciliation reports for the prior 6–12 months - Deviation and CAPA files related to reporting failures - Validation summary and test reports for the reporting system - Signed vendor agreements and evidence of vendor monitoring activities - Training matrix and sample training certificates - Evidence of QPPV oversight (meeting minutes, escalation emails, quarterly reports)

Inspection relevance - Ensure that every checklist item has traceable evidence and that the evidence refers back to specific cases where applicable. Inspectors commonly select a sample of cases and expect to see the evidence trail for each selected case.

Timeline for the EudraVigilance Report Lifecycle

The following timeline table provides a practical, inspection-focused timeline for the life cycle of an ICSR from receipt through final disposition. Timelines are typical industry practice recommendations intended to ensure regulatory compliance; organisations must align internal targets to statutory reporting requirements and national regulations.

Note: The “Typical internal target” column reflects pragmatic internal service levels used by many MAHs and is not a substitute for statutory timelines. Organisations should set targets that provide an appropriate buffer to meet regulatory deadlines.

Example Validation Errors and Remediation Steps

Below are common validation errors encountered during EudraVigilance submission, example root causes, remediation steps, and inspection-relevant evidence to record. Use these as templates for SOPs and training.

1. Error: Missing mandatory element (e.g., patient age or sex)
2. Likely cause: Incomplete intake form or missing follow-up from reporter
3. Immediate remediation:
   • Search case file for any existing data; if none, contact reporter promptly for missing data (document attempts).
   • If reporter not accessible and element is mandatory for acceptance, assess whether report still meets regulatory criteria and document rationale.
4. Preventive actions:
   • Update intake forms to make mandatory fields clearly visible.
   • Train intake staff to capture minimum dataset.

5. Evidence to retain:

   • Contact attempts, updated case record, resubmitted XML and positive acknowledgement.

6. Error: Invalid MedDRA/PT or coding inconsistency

7. Likely cause: Out-of-date MedDRA dictionary or incorrect mapping in E2B(R3) generator
8. Immediate remediation:
   • Verify MedDRA version used; recode term using correct version and rationale.
   • Regenerate E2B(R3) and resubmit.
9. Preventive actions:
   • Maintain MedDRA dictionary update schedule and change control.
   • Validate mapping after dictionary upgrades.

10. Evidence to retain:

    • Coding change log, mapping change control, resubmission acknowledgement.

11. Error: Schema validation error (missing required E2B element, wrong data type)

12. Likely cause: E2B(R3) generator bug or recent mapping change not validated
13. Immediate remediation:
    • Capture raw error message; identify missing/invalid element.
    • Correct mapping or manually edit XML if permitted and regenerate.
    • Run local schema validation pre-submission in the future.
14. Preventive actions:
    • Strengthen unit testing and release controls for the E2B(R3) generator.

15. Evidence to retain:

    • Error message, root cause analysis, change control, corrected XML, successful acknowledgement.

16. Error: Invalid product identifier (e.g., MAH code, country-specific product code)

17. Likely cause: Outdated product master data or incorrect select list
18. Immediate remediation:
    • Validate product master file; correct code and update case.
    • If product code mismatch caused a rejection, resubmit corrected message.
19. Preventive actions:
    • Implement daily/weekly product master synchronisation with regulatory registries.

20. Evidence to retain:

    • Product master change log, corrected submission, reconciliation demonstrating correction.

21. Error: Duplicate case detected

22. Likely cause: Multiple reporters or duplicate submissions by different affiliates
23. Immediate remediation:
    • Determine whether the duplicate is genuine: compare narratives, dates, reporter details.
    • If duplicate, follow nullification procedure for the redundant message and retain justification.
    • If both messages contain unique data, consolidate via amendment and cross-reference.
24. Preventive actions:
    • Strengthen triage to identify potential duplicates before submission.

25. Evidence to retain:

    • Duplicate assessment, nullification request and approval, linkage between messages.

26. Error: Invalid date format (e.g., eventDate outside allowed range, future date)

27. Likely cause: Data entry error, timezone mismatch or system clock issue
28. Immediate remediation:
    • Correct date in case record; explain and document correction.
    • Regenerate and resubmit.
29. Preventive actions:
    • Implement client-side validation for date fields and system clock monitoring.

30. Evidence to retain:

    • Correction log, resubmitted XML, acknowledgement.

31. Error: Country code or country-specific authority mismatch

32. Likely cause: Incorrect country selection or change in MAH local affiliate
33. Immediate remediation:
    • Confirm country of occurrence/reporter, correct message and resubmit.
    • If necessary, route report to correct local affiliate if MAH responsibilities differ.
34. Preventive actions:
    • Provide clarifying guidance in SOPs on country selection and affiliate responsibilities.
35. Evidence to retain:
    • Country confirmation, corrected submission and acknowledgement.

For each remediation, document the time to detect, time to resolve, root cause, corrective actions, and preventive measures. This documentation is frequently requested during inspections.

Governance and Oversight

Strong governance ensures that operational practices align with regulatory obligations and that the QPPV can demonstrate oversight. Key governance components:

• Roles and responsibilities: Clearly defined responsibilities for intake, case processing, submission, acknowledgement review, reconciliation, and governance escalation. Role descriptions and RACI matrices should be documented and current.
• Policies and SOPs: Living procedural documents with version control, review schedules and training updates. SOPs must be practical and consistently followed.
• Change control: All changes to mappings, software, vendor arrangements, product masters, and dictionaries must pass through change control with testing and approvals.
• Vendor management: For outsourced submission or IT support, retain supplier qualification, regular performance reviews, audit reports and SLAs documenting turnaround times for remediation.
• Metrics and reporting: Routine KPI dashboards and trend analysis for timeliness, rejections, resubmissions and reconciliation discrepancies. Use these for quality improvement and to inform the QPPV.
• Escalation pathways: Clear, documented Escalation criteria (e.g., repeated rejections, systemic mapping errors, late submissions, high-profile ICSRs) with contact lists and timelines for response.
• CAPA and continual improvement: Root cause analysis for recurring issues, documented CAPAs with ownership and timelines, and evidence of effectivity checks.

Inspection relevance - Inspectors expect to see evidence that governance mechanisms are operational. This includes meeting minutes where issues are discussed, CAPA records and evidence that the QPPV is receiving and acting on meaningful oversight information.

Practical Implementation Details

Operationalise the elements above with pragmatic controls:

• Pre-submission validation: Implement a local E2B validator that mirrors the EudraVigilance ruleset (schema + business rules) to catch errors before submission.
• Daily acknowledgement monitoring: Automate retrieval and triage of acknowledgements into a queue with severity flags (Accepted, Warning, Rejected). Assign SLA-driven tasks for human review.
• Automated reconciliation: Schedule automated jobs to reconcile internal case IDs with submission logs and acknowledgement statuses. Flag any mismatches for investigation.
• Case linkage: Ensure initial and follow-up messages maintain a unique linkage field (initial case ID) in the E2B(R3) structure; include SOPs on how to construct and reference that ID.
• Resubmission templates: Prepare pre-approved resubmission templates for common error classes to accelerate remediation while maintaining appropriate review controls.
• Sandbox testing: Maintain a testing environment for gateway connectivity and perform scheduled test submissions, especially after upgrades to mapping or software.
• Audit trail practices: Configure systems to preserve immutable audit trails and back-up acknowledgement files for the retention period required by law.
• Evidence packs for inspection: Maintain a ready-to-present pack including SOPs, representative case files, reconciliation reports and CAPA evidence.

Key Takeaways

• EudraVigilance reporting is a core pharmacovigilance activity that requires technical capability, clear procedures and robust governance.
• Acknowledgement handling is critical: submission ≠ acceptance.
• Implement pre-submission validation, rapid acknowledgement review, and formal reconciliation to minimise regulatory risk.
• Maintain inspection-ready evidence: SOPs, case files, acknowledgement logs, validation reports, reconciliation and CAPA documentation.
• The QPPV must have visibility of the system performance and be able to demonstrate oversight with transparent governance.

References

1. Regulation (EC) No 726/2004.
2. Directive 2001/83/EC.
3. Commission Implementing Regulation (EU) No 520/2012.
4. EMA Good Pharmacovigilance Practices (GVP) Module VI.
5. EMA EudraVigilance Electronic Reporting Guidance.
6. EMA EVWEB User Documentation.
7. ICH E2B(R3) Implementation Guide.
8. ICH E2D Post-Approval Safety Data Management.