GVP Module VI: Electronic Submission and EudraVigilance Interfaces

Introduction

Electronic submission of individual case safety reports is not simply a technical exercise performed after case processing. It is part of the regulated pharmacovigilance process.

For a marketing authorisation holder (MAH), an ICSR must move through a controlled chain:

Safety information
       ↓
Case assessment
       ↓
Valid ICSR
       ↓
Submission decision
       ↓
ICSR data and coding
       ↓
Electronic transmission
       ↓
EudraVigilance validation
       ↓
Acknowledgement
       ↓
Reconciliation and monitoring

A failure at any stage can affect the completeness, timeliness, accuracy or traceability of pharmacovigilance reporting.

The European Medicines Agency (EMA) describes EudraVigilance as the EU system supporting electronic exchange of ICSRs between MAHs, national competent authorities, EMA and clinical-trial sponsors. Electronic reporting is obligatory for MAHs and clinical-trial sponsors within the applicable framework. citeturn0search1turn0search2

1. Electronic Submission Is a Regulatory Requirement

GVP Module VI states that electronic submission of valid ICSRs by MAHs and competent authorities is mandatory for the applicable medicinal products under EU legislation. Failure to comply with the electronic-submission requirement constitutes non-compliance with EU legislation. citeturn0search20

The practical consequence is important: the organisation should treat the electronic reporting interface as a controlled pharmacovigilance process, not merely as an IT connection.

The PV system should be capable of demonstrating that:

• cases eligible for submission were identified;
• applicable timelines were calculated correctly;
• the required data were represented accurately;
• the message was transmitted successfully;
• the acknowledgement was received and interpreted;
• errors were investigated and corrected;
• and submission status was reconciled.

2. Where Post-Authorisation ICSRs Are Collected

EudraVigilance contains separate modules for different safety-reporting contexts.

The EudraVigilance Post-Authorisation Module (EVPM) collects ICSRs related to medicinal products authorised in the EEA. EMA identifies the ICSR types collected in EVPM as including spontaneous reports, reports from study with study type individual patient use or other studies, other, and not available to sender/unknown. citeturn0search0

The EudraVigilance Clinical Trial Module (EVCTM) is dedicated to SUSARs from clinical trials. citeturn0search0turn0search23

This distinction should remain visible in PV procedures and training. A clinical-trial SUSAR should not simply be treated as an ordinary post-authorisation EVPM case because the medicinal product is already authorised.

3. The EudraVigilance Gateway

The EudraVigilance Gateway provides secure electronic data interchange between organisations and EudraVigilance.

EMA describes the gateway as supporting encrypted and digitally signed safety and acknowledgement messages and providing confidentiality, integrity verification and non-repudiation of origin and receipt. citeturn0search0

The organisation may operate its own compliant technical solution or use an appropriate service provider. The technical transmission arrangement does not remove the MAH's responsibility for the accuracy and timeliness of the safety submission.

4. EVWEB

EMA also provides the EudraVigilance web reporting application (EVWEB).

EVWEB allows registered users to create, send and view ICSRs and safety and acknowledgement messages and to perform queries. EMA provides training specifically covering creation, validation and submission of ICSRs through EVWEB. citeturn0search0turn0search5

EVWEB is therefore not merely a viewing portal. It can provide a reporting route for organisations using the applicable web-based functionality.

5. Gateway Versus Web-Based Reporting

The organisation should document which transmission model it uses and ensure that its procedures, testing and business-continuity arrangements correspond to that model.

A large MAH with a validated safety database may use a local gateway solution for automated transmission. An organisation with a different infrastructure may use the available web-based mechanisms.

The regulatory objective is not ownership of a particular software product. The objective is compliant, secure and reliable electronic exchange.

EMA states that it does not mandate a particular software product for electronic ICSR reporting, but the software used must comply with the applicable standards and testing requirements. citeturn0search2

6. ICH E2B(R3) and the ISO ICSR Standard

EudraVigilance uses the international ICSR data standard and ICH E2B(R3)-based implementation framework.

The data model is not simply a technical XML representation. It determines how clinically and administratively important information is communicated between organisations and regulators.

Examples include:

• patient information;
• reporter information;
• medicinal-product information;
• reaction/event information;
• seriousness;
• dates;
• narrative;
• assessment information;
• source information;
• and follow-up information.

The organisation should therefore maintain appropriate control over both the clinical content and the technical transformation of the case into the electronic message.

7. Validation Before Transmission

An electronic message must satisfy the applicable business and technical rules before it can be successfully processed.

Validation should identify problems such as missing mandatory elements, invalid codes, inconsistent dates or other structural and business-rule failures.

The PV organisation should distinguish:

Case processing error
        vs
Message/data validation error
        vs
Transmission/communication failure

These are different failure modes and should have appropriate investigation and escalation procedures.

8. Acknowledgements Are Part of the Process

The submission process does not end when the message leaves the MAH's system.

EMA describes an acknowledgement message as confirming receipt and the outcome of validation of a safety message, completing the electronic data interchange process. citeturn0search0

The organisation should therefore have controls to receive, interpret and retain acknowledgements.

A case should not simply be marked "submitted" because an internal application generated an XML file.

9. Submission Failure and Recovery

A failed transmission requires a controlled response.

The organisation should determine:

1. what failed;
2. when the failure occurred;
3. whether the regulatory reporting deadline is affected;
4. whether the message must be corrected and resent;
5. whether a duplicate or new transmission identifier is required;
6. who owns the recovery action;
7. and how completion is demonstrated.

GVP Module VI refers specifically to responsibilities associated with communication failure and compliance with ICSR submission requirements. citeturn0search20

10. Testing and Major System Changes

EMA requires testing for organisations that electronically report ICSRs for the first time and for organisations introducing a major change to their local safety/PV database that could affect electronic ICSR reporting. citeturn0search2

This creates an important interface between pharmacovigilance system change control and EudraVigilance technical compliance.

A major safety-database upgrade should therefore trigger an assessment of whether EudraVigilance transmission testing is required.

11. Security and Access

Electronic safety reporting involves sensitive patient and reporter information.

EudraVigilance organisation and user registration supports controlled access and the principles of data integrity, accountability and availability. citeturn0search0

The MAH should maintain appropriate controls over:

• user access;
• credentials;
• certificates and keys where applicable;
• roles and permissions;
• service-provider access;
• audit trails;
• and business continuity.

The next chunk will examine acknowledgements and error handling in greater depth, NCA rerouting, ICSR downloads, data-quality controls, reporting reconciliation, technical change control and practical failure scenarios.

11. Acknowledgements Are Part of the Submission Process

An electronic safety-message workflow does not end when the sender transmits an XML message.

The EudraVigilance gateway returns an acknowledgement that confirms receipt and provides the outcome of validation. EMA describes this acknowledgement as completing the electronic data-interchange process. citeturn0search0

Operationally, the PV organisation should therefore treat the following as one controlled process:

Case approved for submission
        ↓
E2B(R3) message generated
        ↓
Message transmitted
        ↓
EudraVigilance acknowledgement
        ↓
Validation outcome assessed
        ↓
Accepted / rejected / requiring correction
        ↓
PV records reconciled

A transmission log showing that a message left the organisation is not, by itself, evidence that the ICSR was successfully accepted.

12. Accepted and Rejected Messages

The organisation should have a controlled process for interpreting acknowledgement outcomes and acting on validation errors.

Where an ICSR is rejected, the organisation should determine:

• why the message failed;
• whether the underlying case data need correction;
• whether the XML generation or mapping is defective;
• whether the same case must be resubmitted;
• whether the original regulatory deadline is affected;
• and how the correction and resubmission are documented.

The objective is not merely to achieve a technically valid XML file. The objective is to ensure that the correct regulatory information reaches EudraVigilance within the applicable timeframe.

13. NCA Rerouting

EudraVigilance also supports automatic rerouting of applicable ICSRs to the relevant national competent authority.

Since the simplified reporting arrangements introduced in 2017, MAHs submit applicable ICSRs to EudraVigilance rather than routinely submitting the same cases directly to NCAs. EudraVigilance performs the applicable rerouting according to defined rules. citeturn0search0turn0search6

This is important when designing reconciliation controls. The MAH should distinguish its submission to EudraVigilance from the downstream routing of the case within the network.

14. ICSR Download for MAHs

The direction of information flow is not only from the MAH to EudraVigilance.

MAHs also have access to the EudraVigilance ICSR Download functionality for cases concerning substances for which they hold an EEA marketing authorisation. EMA states that, following simplified reporting, MAHs no longer receive ICSRs directly from NCAs; the download functionality provides access to these cases through EudraVigilance. citeturn0search0

This creates an important post-submission operational responsibility: receiving and processing relevant cases from EudraVigilance is part of the MAH PV process.

The downloaded information may require assessment for:

• new cases;
• follow-up information;
• duplicates;
• cases already held by the MAH;
• new seriousness or outcome information;
• and information potentially relevant to signal detection or aggregate safety evaluation.

15. Download Is Not the Same as Case Creation

An ICSR downloaded from EudraVigilance should not simply be imported as a new case without appropriate duplicate and case-management controls.

The same patient and event may already exist in the MAH's database because information was received through another source.

The organisation therefore needs a controlled process for comparing downloaded cases with existing records and determining whether the information represents:

• a new case;
• follow-up to an existing case;
• a duplicate;
• or information that does not require creation of a new ICSR.

16. Reconciliation Between Submission and Database

A mature electronic reporting process should reconcile at least three states:

PV case database
      ↕
Submission repository
      ↕
EudraVigilance acknowledgement

The reconciliation should make it possible to identify cases that were:

• approved but not transmitted;
• transmitted but not acknowledged;
• acknowledged with validation failure;
• accepted but not correctly recorded internally;
• or corrected and resubmitted without adequate linkage to the original transaction.

The precise controls will depend on the organisation's systems, but the underlying requirement is traceability.

17. Gateway Failure at the Sender

EMA provides specific business-continuity arrangements for EudraVigilance system failures.

If a sender's gateway fails but valid safety messages can still be generated, EMA states that organisations should primarily use EVWEB or EVPOST as alternative submission routes. Organisations do not need to notify EMA unless they cannot comply with the applicable 7-, 15- or 90-day reporting timelines. citeturn0search1

This is an important practical distinction: a gateway failure does not automatically justify waiting for the gateway to recover.

The business-continuity procedure should identify the available alternative and the decision criteria for invoking it.

18. Prolonged EudraVigilance Availability Problems

EMA also provides specific arrangements for prolonged unavailability of the EudraVigilance gateway or EVWEB where reporting compliance could be affected.

For prolonged gateway unavailability, reports can be submitted when the gateway becomes available again, with the compliance calculation handled according to EMA's published outage provisions. Similar provisions apply to prolonged EVWEB unavailability. citeturn0search1

The organisation should therefore maintain evidence of:

• when the failure was detected;
• what alternative was considered;
• why the selected continuity route was appropriate;
• when the report was transmitted;
• and any communication with EMA where required.

19. Technical Change Management

Changes to the PV database, E2B mapping, gateway software, certificates, message-generation component or related infrastructure can affect electronic reporting.

EMA's electronic-reporting requirements include testing arrangements for new organisations and major changes. EMA currently states that major changes to a gateway and/or local safety/PV database require specified testing steps, while organisations using vendor software should establish whether the relevant version and configuration have already been vendor tested. citeturn0search1

Change control should therefore assess regulatory reporting impact before implementation.

20. Business Continuity Is a PV Control

Electronic reporting should be treated as a critical pharmacovigilance process rather than an ordinary IT service.

The continuity plan should address at least:

• gateway outage;
• PV database outage;
• E2B generation failure;
• certificate or authentication problems;
• network failure;
• vendor service interruption;
• EVWEB availability problems;
• staff unavailability;
• and reconciliation after recovery.

EMA explicitly links EudraVigilance system-failure arrangements to GVP Module I requirements for critical PV processes and business continuity. citeturn0search1

21. Inspection Perspective

An inspector may ask for evidence that the organisation can demonstrate the complete electronic reporting chain.

Examples include:

• case approval record;
• generated E2B(R3) message;
• transmission log;
• acknowledgement;
• validation-error handling;
• resubmission record;
• reconciliation report;
• downloaded EV cases;
• duplicate assessment;
• business-continuity records;
• system-validation evidence;
• and change-control documentation.

The important inspection question is not simply "Can your system submit an ICSR?" It is whether the organisation can demonstrate controlled, timely and traceable submission under normal and abnormal conditions.

22. Common Failure: Monitoring Transmission but Not Acceptance

A system may show a successful network transmission while the receiving system has rejected the safety message during validation.

If the organisation monitors only the outbound transmission log, the failed submission may remain undetected.

The acknowledgement must therefore be incorporated into the operational control loop.

23. Common Failure: Treating Every Download as a New Case

Automatic creation of cases from every downloaded ICSR can create duplicates and obscure the relationship between incoming information and existing cases.

Download processing should include duplicate assessment and controlled handling of follow-up information.

24. Common Failure: No Tested Continuity Route

A written business-continuity procedure is not sufficient if staff have never demonstrated that they can use the alternative route.

Testing should be proportionate to the criticality of the process and should demonstrate that the organisation can continue reporting when the primary technical route is unavailable.

The next chunk will address detailed E2B(R3) data-quality controls, nullification and amendment, case identifiers, reconciliation metrics, vendor oversight, difficult transmission scenarios, inspection findings, References and Regulatory Note.

25. E2B(R3) Data Quality Is a Pharmacovigilance Control

Electronic submission is not only an interface problem. The information transmitted must accurately represent the underlying safety case.

A technically valid message can still contain poor-quality pharmacovigilance data. Controls should therefore operate at several levels:

1. clinical and regulatory assessment of the case;
2. controlled entry and terminology;
3. database validation;
4. E2B(R3) mapping;
5. message validation;
6. EudraVigilance acknowledgement;
7. post-submission reconciliation.

The objective is data that are both technically acceptable and clinically/regulatorily meaningful.

26. Mandatory Data Versus Clinically Important Data

Not every clinically useful item is necessarily a mandatory E2B field, and the absence of a mandatory technical field is not equivalent to the absence of a clinical fact.

The organisation should therefore avoid reducing ICSR quality to a checklist of XML fields.

Quality control should ask whether the submitted message accurately communicates the information required for the regulatory purpose of the ICSR.

27. Controlled Terminology and Coding

Medicinal products, adverse reactions and other coded elements should use the applicable controlled terminology and coding conventions.

Coding errors can affect downstream pharmacovigilance activities even when the message passes technical validation.

For example, an incorrectly coded medicinal product may affect:

• case retrieval;
• duplicate detection;
• signal detection;
• aggregate analysis;
• and regulatory assessment.

28. Case Identifiers and Traceability

The organisation should maintain a reliable relationship between its internal case identifier and the identifiers associated with the electronic reporting transaction.

This is essential when a case is:

• initially submitted;
• amended;
• followed up;
• transferred between systems;
• downloaded from EudraVigilance;
• or corrected after an error.

A reviewer should be able to reconstruct the history without relying on informal knowledge of individual processors.

29. Follow-Up Messages

A follow-up transmission should be linked correctly to the previously submitted case and should communicate the newly available information without unintentionally destroying the existing case history.

The organisation should control the distinction between:

• new information;
• correction of previously transmitted information;
• administrative changes;
• and situations requiring a different regulatory message type.

The applicable current E2B(R3) implementation guidance should be used for the technical construction of each message.

30. Amendments and Corrections

An error discovered after transmission requires controlled assessment.

The organisation should determine whether the issue requires a corrected follow-up message, another permitted E2B operation, or a different corrective action under the applicable technical specifications.

The database should preserve the audit trail showing what was originally submitted, what was subsequently identified as incorrect and what corrective action was taken.

31. Nullification

Nullification is not simply deletion of a case from the sender's database.

Where a previously transmitted report must be nullified, the organisation should apply the applicable E2B(R3) and EudraVigilance rules and maintain evidence supporting the decision.

Examples can include cases that were subsequently determined to be duplicates or reports that were transmitted in error, but the exact regulatory treatment depends on the circumstances.

32. Duplicate Cases and Electronic Reporting

Duplicate management and electronic submission are closely connected.

If two cases describing the same patient and event have both been submitted, the organisation may need to correct the electronic safety-data record in addition to correcting its internal database.

A mature process therefore links duplicate assessment with the electronic reporting workflow rather than treating them as independent activities.

33. Reconciliation Metrics

A useful reconciliation framework can monitor, for example:

Metrics should be used to identify process weakness rather than merely to produce a dashboard.

34. Vendor Oversight

Where an external vendor operates the gateway, safety database, E2B translator or related service, the MAH should retain appropriate oversight of the critical PV process.

Oversight should address, as appropriate:

• service availability;
• change management;
• validation/testing;
• incident management;
• data integrity;
• security;
• business continuity;
• transmission performance;
• acknowledgement monitoring;
• and inspection support.

A vendor SLA that measures uptime but does not measure successful regulatory submission may provide an incomplete picture of performance.

35. Difficult Scenario: Message Sent but Rejected

A case is approved on Monday and an E2B message is transmitted. The gateway records successful transmission, but the EudraVigilance acknowledgement reports a validation failure.

The organisation should not treat the Monday transmission as the end of the reporting process.

The exception should enter the controlled error-resolution process, the cause should be corrected and the case should be resubmitted as required.

The organisation should also assess whether the failure has implications for the applicable reporting deadline and whether other cases may have the same defect.

36. Difficult Scenario: Gateway Unavailable Near a Deadline

A serious ICSR is ready for submission, but the primary gateway is unavailable shortly before the reporting deadline.

The organisation should apply its validated business-continuity process and the current EMA outage arrangements rather than waiting passively for restoration.

The decision, alternative route and eventual transmission should be documented.

37. Difficult Scenario: E2B Mapping Change

A vendor releases a new version of its E2B mapping component.

The organisation should assess the change before implementation because apparently minor mapping changes can alter the regulatory meaning or technical validity of transmitted cases.

The change-control assessment should identify required testing, affected message types, impacted fields and post-implementation monitoring.

38. Difficult Scenario: Incoming EV Case Already Exists Internally

An ICSR downloaded from EudraVigilance describes a patient already known to the MAH through another source.

The organisation should perform duplicate assessment before creating a new independent case.

If it is follow-up to an existing case, the information should be incorporated according to the controlled process and any resulting regulatory reporting implications assessed.

39. Inspection Perspective: Demonstrating End-to-End Control

A strong inspection package should allow an inspector to trace a case through the complete lifecycle:

Source
  ↓
PV assessment
  ↓
Case database
  ↓
Submission decision
  ↓
E2B(R3) message
  ↓
Transmission
  ↓
EV acknowledgement
  ↓
Error resolution / acceptance
  ↓
Reconciliation
  ↓
Follow-up / amendment / nullification if required

The evidence should be contemporaneous and attributable.

40. Common Inspection Failure Modes

Potential weaknesses include:

• treating successful transmission as successful submission;
• failure to monitor rejected messages;
• inadequate reconciliation;
• inability to reconstruct the case transmission history;
• uncontrolled E2B mapping changes;
• inadequate business-continuity testing;
• weak vendor oversight;
• duplicate handling that is disconnected from electronic reporting;
• and incomplete assessment of downloaded EudraVigilance cases.

These are control failures because they can affect whether the right safety information reaches the regulatory system accurately and on time.

41. Practical Governance Model

A mature electronic-reporting process should have clear ownership across PV operations, medical review, regulatory PV, safety systems and IT/vendor functions.

The QPPV does not need to operate the gateway personally. The QPPV should, however, have appropriate oversight of the effectiveness of the pharmacovigilance system and its critical interfaces.

The governance model should make clear who owns:

• case approval;
• submission decision;
• message generation;
• transmission monitoring;
• acknowledgement monitoring;
• error resolution;
• reconciliation;
• business continuity;
• system changes;
• and vendor oversight.

Key Takeaways

• An ICSR is not successfully submitted merely because an electronic message left the sender.
• EudraVigilance acknowledgement and validation outcome are part of the submission control loop.
• E2B(R3) technical validity does not guarantee clinical or regulatory data quality.
• Case identifiers and transaction history must remain traceable.
• Amendments, follow-up and nullification require controlled handling.
• Incoming EudraVigilance cases require assessment and duplicate control.
• Business continuity must cover both technical failure and regulatory reporting deadlines.
• Major electronic-reporting changes require appropriate testing and change control.
• Vendors can operate critical infrastructure without removing the MAH's need for effective oversight.
• Inspection readiness means demonstrating end-to-end control with contemporaneous evidence.

References

1. European Medicines Agency. EudraVigilance — system overview and electronic reporting guidance.
2. European Medicines Agency. EudraVigilance: electronic reporting and data-processing guidance for marketing authorisation holders and sponsors.
3. European Medicines Agency. EudraVigilance Gateway and EVWEB business-continuity arrangements.
4. European Medicines Agency. EudraVigilance ICSR Implementation Guide and applicable current technical documentation.
5. International Council for Harmonisation. ICH E2B(R3) — Electronic Transmission of Individual Case Safety Reports (ICSRs).
6. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended.
7. European Medicines Agency. Good Pharmacovigilance Practices, Module I and Module VI.

Regulatory Note

This article explains electronic ICSR submission and EudraVigilance interfaces from an EU pharmacovigilance perspective. It is an educational resource and does not replace the current EudraVigilance technical documentation, E2B(R3) implementation specifications, GVP, applicable EU legislation or EMA business-continuity instructions.

Technical requirements can change independently of the underlying GVP principles. Before implementing or modifying an electronic reporting process, the organisation should verify the current EMA technical specifications, validation rules, reporting requirements and system-status arrangements.

The examples are illustrative and are not presented as descriptions of specific regulatory inspection cases unless a source is explicitly identified.