QPPV.COM

GVP Module VI: Electronic ICSR Submission and EudraVigilance

Explains the operational controls required to move an ICSR from a completed safety case to a valid electronic regulatory submission through the EU EudraVigilance environment.

Audio Lesson 16 min
Knowledge Assessment Test your understanding of this article. Take the assessment →

GVP Module VI: Electronic ICSR Submission and EudraVigilance

Introduction

Electronic submission is a critical final stage in the individual case safety report lifecycle.

A pharmacovigilance organisation may correctly identify, assess and process an ICSR, but the regulatory reporting obligation is not fulfilled merely because the case exists in the safety database. The required electronic message must be generated, validated, transmitted, acknowledged and, where necessary, corrected and resubmitted.

The practical lifecycle is:

Completed ICSR
      ↓
Reportability assessment
      ↓
Electronic message generation
      ↓
Technical validation
      ↓
Transmission
      ↓
Acknowledgement
      ↓
Accepted / rejected / warning
      ↓
Correction and resubmission where required
      ↓
Reconciliation

This article focuses on the operational controls around that lifecycle and the relationship with EudraVigilance.

1. Why Electronic Reporting Is a Pharmacovigilance Control

Electronic reporting is sometimes treated as an IT activity.

That is too narrow.

The electronic submission process determines whether the safety information held by the MAH is successfully transferred into the regulatory pharmacovigilance environment within the applicable requirements.

It therefore involves:

The process must be governed as a pharmacovigilance control with appropriate technical support.

2. EudraVigilance in the ICSR Lifecycle

EudraVigilance is the EU system supporting the collection and analysis of suspected adverse reactions associated with medicines authorised or being studied in the European Economic Area, subject to the applicable framework.

For an MAH, electronic ICSR reporting requires interaction with the applicable EudraVigilance reporting environment and technical requirements.

The operational process should therefore distinguish between:

Safety database
      ↓
Electronic ICSR message
      ↓
EudraVigilance transmission
      ↓
Regulatory processing

The safety database remains the system in which the organisation manages its case, while the electronic transmission is the controlled regulatory communication of that information.

3. The ICSR Message

An electronic ICSR is a structured representation of the case.

The message contains coded and structured information corresponding to the relevant case data.

This means that data quality upstream directly affects the quality of the regulatory submission.

A technically valid message can still contain clinically or operationally incorrect information if the underlying case was processed incorrectly.

4. Standards and Data Structures

Electronic ICSR reporting uses internationally harmonised standards and implementation requirements.

The relevant standards provide a common structure for exchanging individual case safety information.

Operational teams should therefore understand the relationship between:

The exact technical requirements can change and should be checked against the current applicable documentation.

5. Before Message Generation

Before an electronic ICSR message is generated, the organisation should have completed the applicable case-processing activities.

These may include:

The electronic message should be the controlled output of the case-processing process, not a substitute for it.

6. Reportability Assessment

Not every case in the safety database will necessarily be submitted through every regulatory pathway.

The organisation should have controlled rules for determining:

These rules should reflect the current applicable regulatory framework.

7. Message Generation

The safety database or reporting system converts the case into the appropriate electronic representation.

Controls should ensure that the message reflects the current approved case data.

Potential problems include:

Automated generation reduces transcription risk but does not eliminate the need for quality controls.

8. Technical Validation

Electronic messages are subject to technical validation before or during transmission.

Validation can identify structural or data-format problems such as:

Technical validation is essential, but it should not be confused with medical or regulatory review.

9. Business Versus Technical Quality

A message can pass technical validation and still be wrong.

For example, a technically valid message could contain an incorrect seriousness classification or an incorrectly coded reaction if those values were entered incorrectly upstream.

This distinction is important:

Technical validity
       ≠
Clinical correctness
       ≠
Regulatory compliance

A mature reporting process controls all three dimensions.

10. Transmission

Transmission is the actual electronic delivery of the ICSR message to the applicable regulatory environment.

The organisation should maintain evidence that the message was transmitted and should monitor the resulting acknowledgement.

A generated message sitting in an internal queue is not equivalent to a successful regulatory submission.

11. Acknowledgements

Electronic systems may return different types of responses following transmission.

The organisation should have defined processes for interpreting these responses and determining what action is required.

At a minimum, the process should distinguish between:

The next chunk will examine acknowledgement handling, rejected messages, resubmission, timelines, EudraVigilance roles and operational reconciliation.

12. Acknowledgement Handling

An electronic reporting process is incomplete until the organisation has appropriately evaluated the response to its transmission.

The response should be linked to the submitted case and retained as evidence of what happened to the message.

A useful operational model is:

Submission
   ↓
Acknowledgement received
   ↓
Interpret response
   ↓
Accepted? ── Yes → Complete submission record
   │
   No
   ↓
Investigate
   ↓
Correct
   ↓
Resubmit where required

The exact acknowledgement categories and technical handling depend on the applicable EudraVigilance requirements.

13. Rejected Messages

A rejected message requires prompt attention.

The organisation should determine:

A rejected electronic message should not simply remain in an error queue until someone notices it.

14. Resubmission

Where a submission needs correction and resubmission, the process should preserve the relationship between the original transmission and the corrected submission.

The organisation should be able to reconstruct:

This is particularly important where the reporting deadline is short.

15. Error Ownership

Technical errors can cross organisational boundaries.

For example, a safety database vendor may generate the message, an MAH team may approve it, and another service provider may operate the transmission interface.

The organisation should nevertheless maintain clear ownership of the overall process.

A useful responsibility model distinguishes:

Activity Typical owner
Case assessment Pharmacovigilance
Message generation Safety-system process
Technical validation System / reporting process
Transmission Reporting interface
Error investigation Defined operational owner
Regulatory escalation Appropriate PV/regulatory function
Overall oversight MAH / PV governance

The exact allocation varies by organisation.

16. Submission Timelines

The applicable reporting timeline is determined by the regulatory framework and characteristics of the report.

The organisation should not rely on manual calculation for every case when the safety system can calculate and monitor deadlines automatically.

However, automated calculation should be validated and supported by appropriate procedural controls.

17. Receipt Date Versus Submission Date

The reporting clock depends on the applicable rules governing receipt of the report.

This makes intake controls directly relevant to electronic reporting.

A case cannot be submitted on time if the organisation does not know when the report entered its pharmacovigilance system.

The end-to-end control therefore begins before the electronic message is generated.

18. Initial and Follow-Up Reports

An initial report and a follow-up report are not interchangeable.

A follow-up may contain material new information requiring an updated electronic report according to the applicable requirements.

The reporting system should preserve the relationship between the original and subsequent submissions.

19. Case Version Control

The electronic submission process should use the appropriate case version.

If the safety database contains multiple versions, the organisation should have controls preventing accidental transmission of an obsolete version.

Version control should support reconstruction of:

Case version 1
      ↓
Initial submission
      ↓
New information
      ↓
Case version 2
      ↓
Follow-up submission

20. EudraVigilance Roles

The EudraVigilance environment involves different types of stakeholders and reporting relationships.

An organisation should understand which role applies to its activities and which reporting obligations arise from that role.

Relevant operational responsibilities can include:

Current EMA and EudraVigilance documentation should be consulted for the precise technical and organisational requirements.

21. Technical Specifications Change

Electronic reporting standards are not static.

Implementation guidance, validation rules, controlled terminologies and technical requirements can change.

Change management should therefore assess the impact of regulatory and technical updates on:

22. Testing Before Production Changes

A change to an electronic reporting interface should be tested before being relied upon for production reporting.

Testing should be proportionate to the change and may include:

Testing should demonstrate that the complete process remains functional, not simply that a single message can be generated.

23. Business Continuity

Electronic reporting systems can become unavailable.

The organisation should have documented contingency arrangements for significant interruptions affecting ICSR processing or submission.

The contingency process should address:

The contingency plan should be tested periodically where appropriate.

24. Reconciliation of Submitted Cases

Reconciliation confirms that cases expected to be submitted were actually transmitted and that their regulatory processing status is understood.

A reconciliation can compare:

Cases requiring submission
          ↕
Cases transmitted
          ↕
Cases acknowledged
          ↕
Cases accepted / rejected

Discrepancies should be investigated rather than simply corrected in a spreadsheet.

25. Submission Reconciliation as a Quality Control

Reconciliation can identify failures such as:

The frequency and scope should be appropriate to the organisation's risk profile and reporting architecture.

26. Vendor Interfaces

Where electronic submission is outsourced, the MAH should understand the complete chain.

For example:

MAH safety database
       ↓
Case-processing vendor
       ↓
Transmission service
       ↓
EudraVigilance
       ↓
Acknowledgement
       ↓
Vendor / MAH monitoring

Each interface needs defined responsibilities and escalation.

27. Inspection Evidence

An inspector may select an ICSR and ask for evidence of its electronic submission.

The organisation should be able to show:

The evidence should be retrievable without reconstructing the history manually from disconnected systems.

28. Common Electronic Reporting Failures

Treating message generation as submission

The organisation assumes that creating the XML or other electronic message completes the obligation.

Ignoring rejected messages

Rejected messages remain in a queue without defined ownership.

Weak reconciliation

The organisation cannot demonstrate that all reportable cases reached the intended regulatory destination.

Obsolete configuration

The reporting system has not been updated after a technical or regulatory change.

Poor contingency planning

An outage causes an uncontrolled backlog.

Unclear vendor ownership

Multiple organisations are involved but no one owns the complete outcome.

The next chunk will cover practical EudraVigilance scenarios, inspection findings, governance, metrics, final principles, References and the Regulatory Note.

29. Practical Example: Accepted Submission

A serious ICSR is completed, quality controlled and transmitted electronically. The reporting system receives an acceptance acknowledgement and records the transmission status.

The case record should retain sufficient evidence to demonstrate:

The case is not simply marked "submitted" because an operator clicked a transmission button.

30. Practical Example: Rejected Submission

A report is transmitted but receives a rejection because the electronic message contains an invalid or inconsistent data element.

The operational response should include:

  1. identifying the rejection;
  2. determining the cause;
  3. assessing the regulatory impact;
  4. correcting the underlying case or configuration as appropriate;
  5. generating the corrected message;
  6. resubmitting where required;
  7. and documenting the outcome.

If the same rejection affects multiple cases, the issue should be escalated as a potential systemic problem.

31. Practical Example: System Outage

An outage prevents electronic submissions for a period of time.

A mature contingency process should identify affected cases, prioritise cases according to applicable timelines, maintain a controlled backlog and reconcile all affected submissions after recovery.

The organisation should also investigate whether the outage itself requires deviation management or other escalation.

32. Practical Example: Wrong Case Version

A follow-up report is received after the initial case has been submitted. During processing, an obsolete case version is accidentally selected for transmission.

The technical message may be perfectly valid even though the wrong clinical information was transmitted.

This illustrates why electronic reporting controls must include case-version management and not rely solely on technical validation.

33. Practical Example: Vendor Failure

A vendor generates and transmits messages on behalf of an MAH. Several acknowledgements are not correctly transferred back to the MAH monitoring system.

The MAH may initially believe that all submissions succeeded.

A reconciliation identifies the discrepancy.

The appropriate response should address both the affected cases and the underlying interface control.

34. Metrics for Electronic Reporting

Useful metrics can include:

Metrics should be trended rather than viewed only as isolated monthly numbers.

35. What an Inspector May Ask

An inspector may select a submitted ICSR and ask:

The organisation should be able to answer these questions from its controlled records.

36. Inspection Findings and Systemic Risk

Electronic-reporting findings can indicate broader pharmacovigilance weaknesses.

For example, repeated late submissions may result from an intake problem rather than a transmission problem.

Repeated rejected messages may indicate poor database configuration.

Missing acknowledgements may indicate an interface or reconciliation weakness.

The investigation should therefore follow the complete process rather than focusing only on the last visible error.

37. Audit of Electronic Reporting

A pharmacovigilance audit can assess the entire reporting chain.

A risk-based audit may review:

The objective is to establish whether the electronic reporting process provides reliable regulatory assurance.

38. Change Management

Changes to EudraVigilance requirements or associated technical standards should enter the organisation's controlled change-management process.

Impact assessment should consider:

A technical change that appears minor can have a significant impact if it affects a reporting-critical interface.

39. What Good Looks Like

A mature electronic ICSR reporting process has:

Most importantly, the organisation can demonstrate the complete path from the pharmacovigilance case to the regulatory outcome.

40. Relationship With the Main Module VI Article

This article should be read together with the main Module VI article, which describes the complete ICSR lifecycle.

Related dedicated articles should cover other technically significant Module VI subjects, including:

This separation allows detailed technical guidance to be maintained without making the principal Module VI article unnecessarily difficult to navigate.

41. Final Principles

  1. Electronic transmission is part of the pharmacovigilance control system.
  2. Generating an electronic message is not the same as completing a regulatory submission.
  3. Technical validation does not establish clinical correctness.
  4. Transmission status must be confirmed through appropriate acknowledgements.
  5. Rejected messages require defined ownership and prompt resolution.
  6. Case-version control is essential for follow-up reporting.
  7. Reconciliation should confirm that reportable cases reached the intended regulatory destination.
  8. Contingency arrangements should address reporting-critical outages.
  9. Technical and regulatory changes should be managed through controlled change management.
  10. Outsourcing does not remove the MAH's responsibility for appropriate oversight.
  11. Electronic-reporting metrics should identify trends and systemic weaknesses.
  12. Inspection readiness depends on complete, retrievable evidence of the submission lifecycle.

Key Takeaways

References

  1. European Medicines Agency. Good Pharmacovigilance Practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products. Current version should be consulted for the overarching ICSR reporting framework.
  2. European Medicines Agency. EudraVigilance — electronic reporting guidance and related technical documentation. Current technical documentation should be consulted for operational reporting requirements.
  3. European Medicines Agency. EudraVigilance system and organisation-related guidance. Relevant to access, reporting and operational responsibilities within the EU pharmacovigilance environment.
  4. International Council for Harmonisation. ICH E2B(R3) — Individual Case Safety Reports. Relevant to structured electronic ICSR transmission.
  5. International Council for Harmonisation. ICH E2D — Post-Approval Safety Data Management: Definitions and Standards for Individual Case Safety Reports. Relevant to post-authorisation ICSR reporting concepts.
  6. European Parliament and Council. Directive 2001/83/EC, as amended. EU legal framework for medicinal products for human use and pharmacovigilance.
  7. European Parliament and Council. Regulation (EC) No 726/2004, as amended. Union framework for authorisation and supervision of medicinal products and relevant pharmacovigilance obligations.

Regulatory Note

This article is an educational and practical explanation of electronic ICSR submission and EudraVigilance. It does not replace the current GVP Module VI guidance, EMA EudraVigilance guidance, applicable technical documentation, EU legislation or organisation-specific procedures.

EudraVigilance technical requirements and implementation documentation may change independently of broader GVP text. Before making a live reporting or system-configuration decision, verify the current EMA documentation, applicable reporting rules, technical specifications and effective dates.

The examples in this article are illustrative process examples and are not descriptions of specific regulatory inspection cases unless an authoritative source is explicitly identified.

Revision History

Related Articles

EudraVigilance Data for MAHs: ICSR Monitoring and Safety Use

Explains what MAHs need to monitor and retrieve from EudraVigilance, what the information is used for, and how mandatory regulatory activities differ from recommended or scientifically useful uses.

GVP Module VI Addendum II: Masking Personal Data in Individual Case Safety Reports

Explains the practical principles for protecting personal data in ICSRs while preserving the information needed for safe and effective pharmacovigilance.

GVP Module VI: Duplicate Management of Suspected Adverse Reaction Reports

Explains how to identify and manage duplicate individual case safety reports while preserving complete safety information and reliable pharmacovigilance analyses.

Last reviewed: 2026-08-24