Written and maintained by CASRAI Editorial Board
Last updated
EudraVigilance is the European Medicines Agency’s (EMA) central data-processing platform for managing and analysing information on suspected adverse reactions to medicines authorised or being investigated in clinical trials in the European Economic Area (EEA). For a marketing authorisation holder (MAH) or clinical trial sponsor, “reporting to EudraVigilance” is a specific, mechanical obligation: register the right organisation and users, choose a submission channel, format each case as an Individual Case Safety Report (ICSR) in the correct electronic standard, and hit the applicable deadline. This guide covers those mechanics — registration, EVWEB versus gateway submission, the E2B(R3) ICSR format, and the reporting timelines — rather than the broader pharmacovigilance process. For the end-to-end AE/SAE/SUSAR workflow a clinical trial safety team runs, see Pharmacovigilance in Clinical Research; this page picks up specifically at the point where a validated case has to go into EudraVigilance itself.
Who has to register, and for what
Registration in EudraVigilance is organisation-based, not case-based. Before anyone can submit a single ICSR, the reporting organisation itself must be registered in EMA’s identity and access systems, and that registration determines what the organisation is subsequently allowed to submit and see.
- Marketing authorisation holders (MAHs) register as the entity legally responsible for post-authorisation safety reporting on their products. MAH registration is tied to the organisation’s record in EMA’s Organisation Management Service (OMS), which is the same organisation-identity layer that underlies Article 57(2) product-information submissions and the Pharmacovigilance System Master File (PSMF) location record.
- Clinical trial sponsors register separately to submit SUSARs arising from interventional trials conducted under EU Regulation (EU) No 536/2014, distinct from an MAH’s post-authorisation reporting obligation for an already-marketed product.
- National competent authorities (NCAs) register with a different access profile, since they both receive nationally-reported cases and query the pooled EudraVigilance database.
Within a registered organisation, individual users are granted EudraVigilance accounts with specific roles — typically an ICSR sender role for whoever actually transmits cases, plus read/query access for signal-detection and compliance staff. The organisation’s Qualified Person Responsible for Pharmacovigilance (QPPV) does not personally submit every case, but sits at the centre of the registration: the QPPV (or a named deputy) is the accountable contact EMA associates with the organisation’s EudraVigilance access and with the PSMF that describes how the organisation’s reporting actually works. A gap between who is registered to submit and who is accountable under GVP Module I for the pharmacovigilance system as a whole is a common audit finding — registration should be kept current as staff and CRO/vendor relationships change, not set up once and forgotten.
EVWEB versus gateway/web service submission
EMA offers two distinct technical routes into EudraVigilance, and choosing between them is mostly a question of reporting volume and existing safety-database infrastructure, not a matter of which route is “more compliant” — both routes ultimately produce the same E2B(R3) ICSR message and are subject to the same validation rules on arrival.
- EVWEB is EMA’s browser-based ICSR entry and submission tool. A registered user logs in and completes the case directly in a web form structured around the E2B(R3) data elements, with no local safety-database software or system-to-system integration required. It suits organisations with a low, occasional case volume — a small MAH, an academic sponsor running a handful of trials, or a site that needs a manual fallback channel when an automated feed is down — where building and maintaining a gateway connection would be disproportionate to the volume of cases it would carry.
- Gateway (or web service) submission is automated, system-to-system XML message exchange: the organisation’s own safety database (an Argus, ArisGlobal, or similar case-management system) generates a compliant E2B(R3) XML message and transmits it directly to EudraVigilance without manual re-entry. This is the standard route for MAHs and larger sponsors handling meaningful case volumes, where manual entry would be both slower and a source of transcription error against the safety database’s own case record.
Either way, since 30 June 2022, electronic ICSR reporting via one of these two routes has been mandatory for MAHs and clinical trial sponsors reporting into EudraVigilance — there is no longer a paper or ad hoc email fallback built into the regulatory expectation.
E2B(R3): the format both routes submit into
Every ICSR submitted to EudraVigilance, whether typed into EVWEB or generated by a gateway feed, has to conform to the same underlying data standard: ICH E2B, currently in its (R3) revision, implemented in the EU via the ISO ICSR standard (ISO/HL7 27953-2:2011). E2B(R3) defines the structured data elements a case must carry — patient and reporter information, suspect and concomitant products, reaction terms coded to MedDRA, narrative, and causality assessment — as a single machine-readable XML message rather than free-text correspondence. This is what makes EudraVigilance a genuinely queryable safety database rather than a document archive: because every case arrives in the same structured format regardless of submission route, EMA and national regulators can run aggregate signal-detection analysis across the full case pool rather than reading individual reports.
A case that fails E2B(R3) structural validation on arrival — a missing mandatory element, an invalid code value — is rejected back to the sender rather than silently accepted with gaps, so the practical effect for a reporting organisation is that case quality has to be right before submission, not fixed after the fact.
Reporting timelines: two different clocks
“How fast does this need to go to EudraVigilance” has two different answers depending on which regulatory context the case sits in, and conflating them is a genuine source of missed deadlines:
- Post-authorisation ICSRs (a marketed product, reported to EudraVigilance under GVP Module VI): valid serious ICSRs are reported within 15 calendar days of the organisation becoming aware of the minimum information needed to make a valid case; valid non-serious ICSRs follow a 90-calendar-day timeline. Both clocks start from awareness, not from when the case is fully worked up — a case with the minimum four E2B validity elements (identifiable reporter, identifiable patient, at least one suspect medicinal product, at least one adverse reaction) starts the clock even if follow-up information is still being collected.
- Clinical trial SUSARs (a Suspected Unexpected Serious Adverse Reaction arising from an interventional trial under EU Regulation 536/2014): the timeline tightens to 7 calendar days for a SUSAR that is fatal or life-threatening, and 15 calendar days for any other SUSAR, again measured from sponsor awareness. See SUSAR for how a case qualifies as unexpected against the reference safety information in the first place — that determination happens before the reporting clock has any meaning.
A sponsor running a trial on an already-marketed product can end up owing both clocks on related but distinct case sets — the trial-specific SUSAR obligation under 536/2014, and the separate post-authorisation ICSR obligation for the same product’s ordinary marketed-use safety data — which is exactly the kind of dual-track reporting a PSMF and a well-run safety database are supposed to keep straight rather than leaving to case-by-case judgment calls.
Duplicate detection and Medical Literature Monitoring
Two EudraVigilance mechanics are worth understanding specifically because they change what a reporting organisation does and doesn’t need to do itself:
- Duplicate detection. The same adverse event is routinely reported into EudraVigilance more than once — by the patient or a healthcare professional directly to an NCA, and separately by the MAH once it becomes aware of the same case through its own vigilance channels. EudraVigilance runs automated duplicate-detection logic across incoming ICSRs (surfaced to users through the EudraVigilance Data Analysis System, EVDAS) to identify likely duplicate cases describing the same patient/event/product combination from different reporters, so that aggregate signal-detection statistics aren’t inflated by counting one real-world case multiple times. This doesn’t remove an individual reporter’s own obligation to report what it becomes aware of — a case isn’t exempt from an organisation’s reporting duty just because another party might also report it — but it does mean the database itself is built to reconcile overlapping submissions rather than simply summing them.
- Medical Literature Monitoring (MLM). Under GVP Module VI, EMA centrally screens a defined list of medical literature for a specified list of active substances and enters any qualifying ICSRs it finds directly into EudraVigilance on behalf of MAHs. For a product whose active substance sits on that monitored list, the MAH does not need to separately screen the specific journals EMA monitors for spontaneous case reports of that substance — a genuine, deliberate reduction in duplicated screening effort across the industry. It is not a blanket exemption from literature monitoring generally: MAHs still need their own literature-screening process for substances not on the monitored list, for local/regional literature outside EMA’s scope, and for safety-signal review more broadly, not just spontaneous ICSR capture.
Frequently asked questions
Do EVWEB and gateway submission produce different outcomes for the same case?
No — both routes submit the same underlying E2B(R3) ICSR message and are validated against the same rules on arrival. The choice is purely about how the message gets generated (manual web entry versus automated export from a safety database), not about compliance weight or database treatment once received.
Does registering for EudraVigilance require a QPPV?
For an MAH, yes in practical terms — the QPPV (or a named deputy) is the accountable contact tied to the organisation’s pharmacovigilance system, including its EudraVigilance registration and PSMF. See QPPV Role and Responsibilities for what the role does and doesn’t cover day to day.
Does Medical Literature Monitoring mean an MAH can stop checking the literature entirely?
No. EMA’s centralised monitoring covers a specific, defined list of substances and journals for spontaneous ICSR capture only — it reduces duplicated screening effort for those substances, it doesn’t replace an MAH’s broader literature-review obligations for signal detection and for substances outside the monitored list.
What happens if an ICSR fails E2B(R3) validation on submission?
It is rejected back to the sender rather than accepted with gaps filled in later. The reporting organisation has to correct and resubmit — which is why the regulatory reporting clock (7/15/90 days depending on case type) is best treated as a deadline for a validated, accepted submission, not merely a first attempt.
For the broader GxP and quality-system context this reporting obligation sits inside, see GxP Compliance and the Lab Compliance hub. For the clinical-trial-side process this feeds — how an AE gets identified, assessed for seriousness and expectedness, and escalated to the point where it becomes a reportable case — see Pharmacovigilance in Clinical Research, Adverse Event (AE), and SUSAR.
