EudraVigilance Reporting: A Practical Guide to ICSR Submission

EudraVigilance reporting is often described as the electronic transmission of an Individual Case Safety Report (ICSR), but regulatory compliance begins earlier and ends later than the transmission itself. The organisation first has to recognise reportable safety information, establish the regulatory clock, create and medically review a valid case, encode it correctly in ICH E2B(R3), transmit it through an authorised route, receive and interpret the acknowledgement, and manage clinically relevant follow-up.

A successful reporting system therefore links case intake → validity → regulatory classification → due date → E2B(R3) data → transmission → acknowledgement → follow-up → compliance evidence.

Regulatory Framework

The principal EU post-authorisation ICSR framework is established by Directive 2001/83/EC, Regulation (EC) No 726/2004, Commission Implementing Regulation (EU) No 520/2012 and GVP Module VI. The technical exchange uses the ISO ICSR standard based on ICH E2B(R3), which became mandatory for EudraVigilance users on 30 June 2022.

GVP Module VI remains the principal operational guidance for collection, management and submission of suspected adverse-reaction reports. EMA also notes that GVP is being updated following amendments to Implementing Regulation 520/2012 and implementation of ICH E2D(R1); organisations should therefore apply the current EMA implementation guidance where it affects existing GVP text rather than relying on an old procedure in isolation.

What Makes an ICSR Valid?

For reporting purposes, the basic minimum information for a valid ICSR is:

• one or more identifiable reporters;
• one identifiable patient;
• one or more suspected adverse reactions; and
• one or more suspected medicinal products.

"Identifiable" does not necessarily mean that a full name is known. The available information must be sufficient to support the conclusion that a real patient and reporter exist and to avoid treating obviously duplicate or unverifiable information as independent cases.

A report that does not initially satisfy the minimum validity criteria can still be important. The organisation should retain the information as appropriate and attempt follow-up when further information could establish validity or materially contribute to safety evaluation.

The Regulatory Clock

The reporting clock is anchored to the date on which the organisation first receives information that meets the applicable criteria, not to the date on which a case processor happens to enter the report into the safety database.

This makes intake governance critical. Safety information received by an affiliate, medical-information function, vendor, partner or other contracted channel can start the regulatory clock according to the applicable awareness rules. Internal routing delays do not reset that clock.

15-Day and 90-Day Reporting

For post-authorisation ICSRs that fall within EU reporting obligations, GVP Module VI states the general rules:

• serious valid ICSRs are submitted within 15 days from receipt; and
• non-serious valid ICSRs are submitted within 90 days from receipt.

The reporting modality also depends on where the reaction occurred and the type of case. GVP Module VI specifies that EEA and non-EEA serious ICSRs and EEA non-serious ICSRs meeting the applicable criteria are submitted to EudraVigilance; non-serious non-EEA ICSRs are not submitted to EV under the general post-authorisation rule.

These are regulatory timeframes. Companies may use shorter internal targets to create operational buffer, but those internal targets should not be described as EMA legal deadlines.

Initial and Follow-Up Reports

An initial ICSR contains the information available when the case first becomes reportable. Pharmacovigilance does not stop after initial submission. New information may clarify diagnosis, seriousness, outcome, dose, timing, dechallenge, rechallenge, laboratory results, concomitant medicines or alternative explanations.

A follow-up report should transmit relevant new information using the correct case identifiers and sequence so that EudraVigilance can associate the update with the existing case history.

The reporting timeframe for significant follow-up information is determined according to the applicable GVP Module VI rules. Operational procedures should avoid holding important new information merely to accumulate a larger update package.

ICH E2B(R3) and the EU ICSR Implementation Guide

E2B(R3) defines the structured electronic representation of an ICSR. It provides data elements and message conventions that allow different safety systems to exchange the same case without relying on a human-readable form as the primary regulatory message.

The EMA European Union ICSR implementation guide translates ICH E2B(R3) into EU technical requirements and business rules. Organisations should therefore distinguish three layers:

1. the regulatory obligation to submit the case;
2. the ICH standard that defines the message structure; and
3. EU implementation rules governing how the message is populated and processed in EudraVigilance.

A local database can contain all clinically important information and still produce a non-compliant message if the mapping to E2B(R3) or EU business rules is incorrect.

Reporting Routes: EVWEB, Gateway and EV Post

EudraVigilance supports different electronic reporting routes. The choice affects technical implementation but does not change the underlying pharmacovigilance obligation.

EVWEB

EVWEB is EMA's web application for creating, sending and viewing ICSRs, safety messages and acknowledgement messages. It is suitable for organisations that report directly through the web interface and can also form part of a contingency arrangement where appropriately configured.

EVWEB reduces the need for a locally operated automated gateway, but it still requires controlled users, training, correct case entry, review of acknowledgements and evidence that the report was accepted.

Gateway reporting

Gateway reporting allows an organisation's local pharmacovigilance system to exchange E2B(R3) messages with EMA through a system-to-system connection. It is suitable for automated or high-volume reporting but introduces additional dependencies: message generation, mapping, certificates, connectivity, queue monitoring, acknowledgements and technical change control.

A gateway does not make reporting compliant automatically. If a mapping error systematically omits a required field, automation can reproduce the same defect at scale.

EV Post

EMA also supports EV Post functionality for transmission in defined configurations. Organisations should use the current EMA electronic-reporting guidance and registration model to determine which transmission profile is appropriate.

The reporting route should be documented sufficiently for the organisation to know who owns case completion, message generation, transmission, acknowledgement review and technical exception handling.

Testing Before Production Use

New gateways, major technical changes and certain service-provider configurations require testing in the external compliance environment, XCOMP, according to EMA's current electronic-reporting process. EMA distinguishes development/validation testing performed by the organisation from formal quality-assurance testing with EMA.

Vendor-tested software can reduce duplication, but the organisation should confirm that the tested version and configuration correspond to what it actually uses. Customisation, interfaces and local configuration may require additional assurance.

For EVWEB users, the registration and training route differs from gateway quality-assurance testing. The current EMA registration manual and electronic-reporting page should therefore be treated as the controlling procedural sources rather than a legacy generic "gateway certification" concept.

Acknowledgements: Evidence of Message Processing

After submission, EudraVigilance returns acknowledgement information that tells the sender how the message was processed. This is an essential control point.

A robust process distinguishes:

• successful receipt and acceptance;
• rejection because a business or technical rule was not satisfied;
• warnings or validation information that may require review; and
• missing acknowledgements that require investigation.

The operational objective is to know the final regulatory state of each submitted case. A message present in an outbound queue but lacking a positive processing outcome should not be assumed to have entered the regulatory database successfully.

Rejected messages

A rejection should trigger controlled investigation. The organisation should determine whether the problem lies in case data, terminology, product information, local mapping, message structure, configuration or another cause, correct the problem and retransmit within the applicable regulatory timeframe where possible.

Recurring rejection patterns should be trended because they can reveal a systemic defect rather than isolated user error.

Missing acknowledgements

EMA's current electronic-reporting guidance specifically instructs organisations to raise technical support requests when expected acknowledgements are missing during testing. In production, organisations likewise need a defined method for detecting and investigating missing responses rather than leaving messages in an indeterminate state.

Corrections, Amendments and Nullification

Not every correction to an ICSR should be handled in the same way.

A follow-up adds new clinically or administratively relevant information to a valid case. An amendment/correction changes previously transmitted information while preserving the case as a valid report. A nullification is used only where the previously accepted ICSR should no longer exist as a valid case in the regulatory database, for example where it is later established that the report was erroneous or duplicated in a way requiring nullification under the applicable ICSR rules.

Nullification should therefore not be used as a convenient way to erase an undesirable or poor-quality report. The reason should be documented and consistent with the EU ICSR implementation guide and E2B(R3) conventions.

Duplicate Management

Duplicate reports can arise when the same case reaches regulators and MAHs through different routes: a healthcare professional may report to both an authority and a company, literature may duplicate a spontaneous report, or partners may transmit the same information independently.

GVP Module VI Addendum I addresses duplicate detection and management. The aim is to preserve the most complete case history without inflating case counts or losing provenance.

Duplicate management matters beyond case administration. Unresolved duplicates can influence signal detection and aggregate analyses, while incorrect merging can remove genuinely distinct cases.

Reconciliation

Reconciliation tests whether expected information has moved completely between systems or organisations. Depending on architecture, this may involve comparing local submission records with acknowledgements, vendor records with the MAH database, partner exchanges, or other expected data flows.

No universal EMA rule requires every MAH to perform the same reconciliation at the same monthly or weekly frequency. The control should be designed around actual process risks and interfaces.

A useful reconciliation record should identify the population compared, discrepancies found, investigation, responsible owner and closure. Repeated discrepancies should lead to broader root-cause analysis rather than repeated manual correction.

System Failure and Business Continuity

EMA's current electronic-reporting page provides specific procedures for prolonged failure of the EudraVigilance gateway or web application.

Where an EMA gateway outage prevents timely reporting, EMA identifies the official outage period and provides compliance treatment for reports submitted promptly after service restoration. The current guidance states that reports submitted within two EMA business days after the gateway becomes available again can have compliance calculated against the first day of the EMA system failure. Similar provisions apply to prolonged EVWEB unavailability, with qualifying reports excluded from compliance monitoring when submitted within the stated restoration window.

These provisions apply to documented EMA system failures. They should not be used to excuse internal company outages. Organisations need their own business-continuity controls for local database, gateway, vendor, certificate or network failures.

Compliance Monitoring and Data Quality

A reporting system should be able to show not only that reports were sent, but that the population of reportable cases was complete, the regulatory clock was calculated correctly, messages were accepted and recurring quality problems were identified.

Useful oversight indicators can include:

• on-time submission of serious and non-serious reportable ICSRs;
• late cases and their root causes;
• rejected and unresolved messages;
• recurring E2B(R3) validation failures;
• missing acknowledgements;
• duplicate-management discrepancies;
• source-to-database intake delays; and
• material coding or medical-review corrections.

Internal alert thresholds, ageing bands and escalation targets are organisation-defined controls unless an authoritative regulatory source sets them. They should therefore be documented as internal expectations rather than presented as EMA requirements.

QPPV and Management Oversight

The QPPV is not expected to transmit individual ICSRs personally. The relevant requirement is effective oversight of the pharmacovigilance system and access to information necessary to fulfil QPPV responsibilities.

For ICSR reporting, meaningful QPPV oversight can include visibility of material compliance trends, significant late-reporting events, systemic data-quality problems, major vendor or system failures, recurring rejected messages and CAPAs that affect the reliability of regulatory reporting.

The exact dashboard, meeting frequency and escalation thresholds are organisational controls. What matters is that material reporting risks reach the appropriate decision-maker and that action is documented.

Outsourced Reporting

An MAH may outsource case processing, E2B message generation, gateway operation or other reporting activities. The regulatory responsibility does not disappear when execution is delegated.

A sound outsourced model defines:

• who receives the report and when the regulatory clock begins;
• who assesses validity and reportability;
• who owns message generation and technical submission;
• how acknowledgements and rejections are managed;
• how follow-up and duplicates are handled;
• how records are exchanged and retained;
• which performance information the MAH receives; and
• how significant failures are escalated.

The most useful oversight metric is often end-to-end performance from first receipt to accepted submission, rather than a vendor-only measure beginning after the case reaches the vendor.

Potential Failure Modes

The following are illustrative scenarios rather than reported inspection findings.

Submission is measured from database entry rather than first receipt

Cases transferred late from affiliates appear on time in the central database. The reporting KPI therefore masks actual regulatory lateness.

Gateway success is confused with case acceptance

The local transmission service records successful dispatch, but acknowledgement rejection is not linked back to the case. The organisation counts a report as submitted even though it did not enter EudraVigilance successfully.

Follow-up information is held for batching

Clinically important new information is accumulated until an internal monthly review rather than submitted according to the applicable follow-up rules. Operational convenience overrides the regulatory process.

Nullification is used to correct poor-quality cases

A valid but imperfect case is nullified and re-created instead of being amended appropriately, breaking case history and potentially affecting duplicate detection.

Business continuity is theoretical

The SOP names EVWEB as the fallback for gateway failure, but no current user has the required webtrader access or practical competency. The contingency route cannot be used when needed.

Vendor timeliness is green while MAH timeliness is red

The vendor processes every case within its SLA after receipt, but affiliate hand-off is delayed. Contract performance looks excellent while regulatory compliance deteriorates.

Inspection Considerations

An inspector can test EudraVigilance reporting by tracing real transactions through the system. Potential questions include:

• What was the first date the organisation became aware of this case?
• Why was the case considered valid and reportable?
• How was seriousness determined?
• What regulatory due date applied and how was it calculated?
• Which E2B(R3) message represented the case?
• Was the message accepted, and where is the acknowledgement?
• What happened when follow-up information arrived?
• How are rejected or missing acknowledgements detected?
• How are duplicates identified and managed?
• What controls verify completeness across affiliates, vendors and partners?
• What happened during the most recent reporting-system outage?
• How does the QPPV learn about material reporting failures?

These are illustrative questions. The actual inspection scope is governed by GVP Module III and the specific inspection mandate.

Practical ICSR Submission Checklist

Before a report is considered operationally complete, the process should be able to confirm that:

• the source and first-receipt date are retained;
• minimum validity criteria have been assessed;
• seriousness and applicable reporting modality are documented;
• the 15-day or 90-day clock, where applicable, is calculated from the correct start date;
• the case is coded and medically reviewed according to controlled procedures;
• the E2B(R3) message passes applicable EU business rules;
• the correct reporting route and organisation profile are used;
• acknowledgement status is captured;
• rejections or missing acknowledgements are resolved;
• significant follow-up is submitted according to applicable rules;
• duplicate, correction and nullification decisions preserve case history appropriately;
• reconciliation or other completeness controls cover relevant interfaces; and
• evidence is sufficient to reconstruct the full regulatory history of the ICSR.

Key Takeaways

EudraVigilance reporting is an end-to-end pharmacovigilance process, not a transmission event. Compliance begins when reportable information reaches the organisation and continues through validity assessment, correct regulatory timing, E2B(R3) message generation, successful processing and follow-up.

The general post-authorisation EU reporting timeframes remain 15 days for serious valid ICSRs and 90 days for non-serious valid ICSRs within their applicable reporting modalities. E2B(R3) is the mandatory technical standard used for EudraVigilance ICSR exchange, supplemented by the EU ICSR implementation guide and business rules.

EVWEB and Gateway are alternative reporting routes, each with different technical and registration requirements. Neither route removes the need for acknowledgement handling, data quality, business continuity and traceable governance.

References

1. European Medicines Agency. GVP Module VI – Collection, management and submission of reports of suspected adverse reactions to medicinal products (Rev. 2). EMA/873138/2011 Rev. 2. https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-good-pharmacovigilance-practices-gvp-module-vi-collection-management-submission-reports-suspected-adverse-reactions-medicinal-products-rev-2_en.pdf
2. European Medicines Agency. GVP Module VI Addendum I – Duplicate management of suspected adverse reaction reports. Available from the EMA GVP collection. https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices-gvp
3. European Medicines Agency. EudraVigilance: electronic reporting. Current reporting, testing, system-failure and compliance guidance. https://www.ema.europa.eu/en/human-regulatory-overview/research-development/pharmacovigilance-research-development/eudravigilance/eudravigilance-electronic-reporting
4. European Medicines Agency. European Union individual case safety report (ICSR) implementation guide, EMA/51938/2013 Rev. 2, with current EU business-rule material available from the electronic-reporting page.
5. European Medicines Agency. EudraVigilance system overview. https://www.ema.europa.eu/en/human-regulatory-overview/research-development/pharmacovigilance-research-development/eudravigilance/eudravigilance-system-overview
6. European Medicines Agency. EudraVigilance – EVWEB user manual, current version available from EMA electronic-reporting/training pages.
7. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0520-20260212
8. European Parliament and Council. Directive 2001/83/EC, as amended. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02001L0083
9. International Council for Harmonisation. ICH E2B(R3): Electronic Transmission of Individual Case Safety Reports and related implementation material. https://www.ich.org/

Regulatory Note

This article focuses on post-authorisation human ICSR reporting to EudraVigilance. Clinical-trial SUSAR reporting has a related but distinct legal framework and should not be inferred from the post-authorisation 15/90-day rules described here. GVP Module VI Rev. 2 remains an important operational source, but EMA is updating GVP following amendments to Implementing Regulation (EU) No 520/2012 and implementation of ICH E2D(R1); current EMA implementation instructions should therefore be checked where newer guidance affects existing text. Internal targets, reconciliation frequencies and escalation thresholds described as examples are recommended practice unless a specific regulatory requirement applies.