QPPV.COM

GVP Module VI: Collection, Management and Submission of Reports of Suspected Adverse Reactions to Medicinal Products

A detailed practical guide to GVP Module VI and the end-to-end management of suspected adverse reaction reports in the EU pharmacovigilance system.

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

GVP Module VI: Collection, Management and Submission of Reports of Suspected Adverse Reactions to Medicinal Products

Introduction

Individual case safety reports (ICSRs) are one of the fundamental sources of pharmacovigilance information.

GVP Module VI provides detailed guidance on the collection, management and submission of reports of suspected adverse reactions to medicinal products. It covers a large operational area, from identification and intake of a potential report through validation, case processing, follow-up, duplicate detection, data quality and regulatory submission.

Because the module is extensive and operationally important, this article is deliberately divided into multiple chunks. The article will follow the lifecycle of an ICSR rather than attempting to compress all requirements into a short summary.

The basic lifecycle can be represented as:

Potential safety information
          ↓
Case identification
          ↓
Validation
          ↓
Initial data capture
          ↓
Medical assessment / processing
          ↓
Follow-up
          ↓
Duplicate assessment
          ↓
Quality control
          ↓
Regulatory submission
          ↓
Database / downstream use

The stages are interconnected. A weakness early in the process can affect the quality and timeliness of the final safety information.

1. Why Module VI Is Operationally Important

ICSR processing is often one of the most highly controlled activities in a pharmacovigilance system because it combines patient-safety considerations, data quality, medical assessment, regulatory timelines and extensive system controls.

An organisation can have a sophisticated safety database and still have a weak ICSR process if cases are not identified promptly, minimum information is misunderstood, follow-up is inadequate or regulatory submissions are not controlled.

Conversely, a well-designed process should allow the organisation to demonstrate:

2. What Is an Individual Case Safety Report?

An ICSR is a report containing information describing a suspected adverse reaction associated with a medicinal product in an individual patient.

The important concept is suspected adverse reaction.

Pharmacovigilance case processing does not require the organisation to establish causality with scientific certainty before a report can enter the safety system.

The purpose of the ICSR process is to capture and evaluate relevant safety information so that it can contribute to ongoing pharmacovigilance.

3. Sources of Individual Case Information

Potential individual cases can arise from many sources.

Examples include:

The source does not by itself determine whether information is a valid ICSR. The content of the report must be assessed against the applicable requirements.

4. The Four Minimum Elements

A fundamental concept in ICSR management is the minimum information needed for a valid individual case safety report.

In practical terms, the report needs information concerning:

  1. an identifiable reporter;
  2. an identifiable patient;
  3. a suspected adverse reaction or event;
  4. and a suspected medicinal product.

These elements should be assessed carefully.

A report should not be rejected merely because it is incomplete in areas beyond these minimum elements. Additional information may be obtained through follow-up and may substantially improve the clinical value of the case.

5. Identifiable Patient

The patient needs to be identifiable in the sense required by the applicable pharmacovigilance framework.

This does not mean that the organisation necessarily needs the patient's name.

Other information may support identification, such as an age, age group, sex, patient number or other appropriate identifying information, depending on the circumstances.

The objective is to establish that the report concerns an individual patient rather than an entirely hypothetical or non-individualised statement.

6. Identifiable Reporter

The report should contain sufficient information to establish that there is an identifiable source of the information.

The reporter may be a healthcare professional, patient, consumer or another appropriate source.

The quality and clinical value of the report may depend substantially on the reporter's qualifications and available contact information, but lack of complete contact details does not automatically make every report invalid if the applicable minimum criteria are otherwise met.

7. Suspected Medicinal Product

The medicinal product suspected in relation to the event needs to be identifiable.

Where possible, product information should be captured precisely, including relevant identifiers such as:

Accurate product identification is particularly important where products with similar names or multiple manufacturers exist.

8. Suspected Adverse Reaction

The report must contain information describing a suspected adverse reaction or other relevant event meeting the applicable criteria.

The initial description may be vague, incomplete or expressed in lay terminology.

Case processing therefore involves clinical interpretation and appropriate coding rather than simply copying the original reporter's wording into the database.

The original information should nevertheless remain traceable so that the coded representation can be understood in context.

9. Initial Receipt and the Clock

One of the most important operational concepts is the relationship between receipt of information and regulatory timelines.

Organisations need a defined process for determining when relevant information is considered received by the pharmacovigilance system and when the applicable reporting clock begins.

This requires clear interfaces between:

A delay at the intake interface can become a regulatory reporting delay even when the downstream case-processing team works efficiently.

10. Intake Channels Must Be Controlled

A mature ICSR system does not rely on one central mailbox alone.

The organisation should understand where safety information can enter the company and how those channels connect to pharmacovigilance.

Potential channels can include:

Healthcare professional
Patient / consumer
Affiliate
Partner
Medical information
Literature
Regulatory authority
Study programme
Digital source
       ↓
Intake / identification
       ↓
Pharmacovigilance system

Each interface should have defined responsibilities and escalation mechanisms.

11. Triage

Triage determines what happens to newly received safety information.

The process should support rapid identification of potentially reportable cases and prioritisation according to applicable requirements.

Triage can include assessment of:

Triage should be designed to avoid both missed cases and unnecessary delays.

12. Case Creation

Once information meets the applicable criteria for case entry, the organisation should create or update the appropriate case record.

The case record should preserve traceability to the source information.

Important controls include:

The database should support reconstruction of what happened and when.

13. Seriousness

Seriousness is a regulatory classification and should not be confused with clinical severity.

An event can be clinically severe without meeting a regulatory seriousness criterion, and an event may meet a seriousness criterion even when its clinical presentation is not intuitively severe.

The applicable seriousness criteria therefore need to be applied consistently and documented appropriately.

14. Expectedness

Expectedness is another distinct assessment.

Whether an event is expected depends on the applicable reference safety information and regulatory framework.

Expectedness should not simply be inferred from whether the event seems medically plausible or whether it has previously been observed.

The relevant reference information and applicable reporting rules should be identified and maintained under controlled processes.

15. Causality

Causality assessment considers the relationship between the medicinal product and the reported event.

Different sources and regulatory contexts may use different causality approaches.

The assessment should be medically appropriate and consistent with the organisation's procedures and applicable requirements.

Importantly, absence of a convincing causal relationship does not necessarily mean that the report should be discarded. The case may still contain relevant pharmacovigilance information.

16. The Importance of the Initial Case

The initial case should be processed using the information available at the time.

It is generally inappropriate to delay case handling indefinitely while waiting for a complete clinical history.

The process should instead establish:

Initial information
      ↓
Valid case?
      ↓
Process within timeline
      ↓
Identify missing information
      ↓
Follow up where appropriate
      ↓
Update the case

This principle is central to maintaining both regulatory compliance and useful safety information.

The next chunk will cover case data fields, medical coding, follow-up, duplicate management and case narratives in greater depth.

17. Case Data Capture

Once a case has been identified as reportable or otherwise appropriate for entry into the pharmacovigilance system, the available information should be captured accurately and consistently.

The database should distinguish between information actually provided by the source and information derived through subsequent medical assessment or coding.

Important data domains can include:

The exact fields depend on the safety database and applicable standards, but the underlying principle is traceability.

18. Source Data and Data Interpretation

Case processors frequently have to transform unstructured source information into structured database fields.

That transformation should not introduce unsupported assumptions.

For example, if a reporter states that a patient was "about 70", the processor should not invent an exact date of birth. Similarly, if the source says that a patient stopped treatment but does not state why, the database should not automatically classify the discontinuation as an adverse reaction.

The source should remain the foundation of the case.

19. Medical Coding

Coding converts clinical information into standardised terminology so that cases can be analysed consistently.

Coding can involve:

Coding should accurately represent the source information and should not artificially increase or reduce the clinical meaning of the report.

Where medical judgement is required, appropriate qualified personnel and controlled procedures should be used.

20. Narrative Construction

The case narrative should provide a coherent clinical account of the relevant information.

A useful narrative should allow a reviewer to understand:

The narrative should not simply repeat every field in the database.

Its purpose is to provide an intelligible clinical story supported by the source data.

21. Follow-Up

Follow-up is an important component of case management because the initial report may contain only limited information.

Follow-up may seek information such as:

The decision to seek follow-up should be based on the potential value of the information and applicable procedures.

22. Prioritising Follow-Up

Not every case requires the same intensity of follow-up.

Priority may be influenced by factors such as:

A risk-based approach can prevent resources being consumed by repeated requests that are unlikely to provide meaningful information.

23. Follow-Up Attempts

Follow-up should be appropriately documented.

The record should make it possible to understand:

Repeated unsuccessful attempts should not simply accumulate without a defined stopping rationale.

24. Duplicate Detection

Duplicate reports occur when information about the same patient and event is received through more than one source or channel.

Duplicate management is essential because failure to identify duplicates can distort:

Duplicate detection should therefore be an ongoing process rather than a one-time check at initial case entry.

25. Duplicate Assessment

Potential duplicates can be assessed using combinations of information such as:

No single field should necessarily be treated as definitive.

The assessment should consider the overall pattern of information.

26. Merging and Linking Duplicates

Where reports are determined to represent the same underlying case, the organisation should follow controlled procedures for linking, merging or otherwise managing the records.

The original source information and history should remain traceable.

Duplicate handling should not result in loss of meaningful information from one of the source reports.

27. Case Follow-Up Can Create New Information

A follow-up report is not necessarily a new case.

In many situations, additional information belongs to the existing case and should be incorporated into the case history.

The system should therefore distinguish between:

New patient/event
       versus
Additional information about existing patient/event

This distinction is essential for maintaining accurate case counts and regulatory reporting.

28. Case Versioning

When significant new information is received, the case may require an updated version or follow-up submission according to applicable requirements.

Version control should allow the organisation to reconstruct:

29. Data Quality

ICSR data quality has several dimensions.

Completeness

Are the relevant data available?

Accuracy

Does the database correctly represent the source?

Consistency

Are related fields logically compatible?

Timeliness

Was the information processed and submitted within applicable timelines?

Traceability

Can the organisation demonstrate where the information came from and what happened to it?

A case can therefore be complete but still inaccurate, or accurate but processed too late.

30. Quality Control

Quality control should be designed around the risks of the process.

Controls can include:

The organisation should understand what each control is intended to detect.

31. Reconciliation

Reconciliation can be particularly important where safety information passes between different systems or organisations.

Examples include reconciliation between:

A reconciliation process should define the population, frequency, responsibilities, discrepancy handling and escalation.

32. Case Processing and Data Integrity

The integrity of an ICSR record depends on controlled access, traceability and appropriate system controls.

Relevant controls can include:

These controls should support the reliability of safety information without unnecessarily obstructing legitimate case processing.

33. Medical Review

Medical review may be required at different stages of case management depending on the organisation's process and the nature of the case.

Medical assessment can contribute to:

The responsibilities and qualifications required should be defined within the pharmacovigilance quality system.

34. Case Closure

Case closure should occur only when the applicable processing activities have been completed or the case has reached an appropriate controlled status.

Closure should not prevent later reopening or updating when new information is received.

A mature system should distinguish between an operationally closed case and a case that can never receive additional information.

35. What Inspectors May Examine

An inspection may examine a sample of cases and reconstruct the complete lifecycle.

Questions can include:

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

36. A Practical Case Lifecycle

The complete lifecycle can therefore be represented as:

Receipt
  ↓
Validation
  ↓
Triage
  ↓
Case creation
  ↓
Data entry
  ↓
Medical assessment
  ↓
Coding / narrative
  ↓
Duplicate assessment
  ↓
Follow-up
  ↓
QC
  ↓
Regulatory submission
  ↓
Ongoing updates
  ↓
Closure / retention

The next chunk will address regulatory reporting, electronic submission, timelines, literature cases, special situations, partners and reconciliation in greater depth.

37. Regulatory Submission of ICSRs

Regulatory submission is the point at which the processed case becomes part of the regulatory safety-reporting system.

The organisation should have controlled processes for determining whether a case requires submission, to which authority or database it should be submitted, and within what timeline.

The submission process should connect the case record with the actual transmission evidence.

A useful chain is:

Case assessment
      ↓
Reportability decision
      ↓
Submission preparation
      ↓
Validation
      ↓
Electronic transmission
      ↓
Acknowledgement
      ↓
Error handling
      ↓
Reconciliation

38. Electronic Reporting

EU pharmacovigilance reporting relies heavily on electronic transmission and standardised data structures.

The operational process therefore depends not only on case-processing procedures but also on reliable technical interfaces.

Controls should address, as applicable:

A case should not be considered successfully submitted merely because a message was generated.

39. Submission Acknowledgements and Errors

Electronic reporting systems can return acknowledgements, warnings or errors.

The organisation should have a controlled process for interpreting these responses and determining whether corrective action is required.

Rejected submissions are particularly important because the regulatory timeline may continue to be relevant while the technical problem is being resolved.

The system should therefore support rapid detection and escalation of failed transmissions.

40. Regulatory Timelines

ICSR reporting timelines depend on the applicable regulatory requirements and the characteristics of the report.

The organisation should maintain controlled rules for determining the relevant deadline.

Important inputs may include:

Timelines should be system-supported where possible and independently monitored through appropriate quality controls.

41. Timeline Monitoring

A timeline metric should measure the actual regulatory requirement rather than an arbitrary internal target.

Useful monitoring may include:

A high on-time percentage should not conceal a small number of serious failures.

42. Literature Cases

Published literature can contain information about individual patients and suspected adverse reactions.

Literature surveillance therefore has an important interface with ICSR management.

The organisation should have a controlled process for identifying potentially reportable cases and determining what information needs to be entered into the safety system.

The relationship between literature monitoring and ICSR processing should be clearly defined so that cases are not lost between the two processes.

43. Regulatory Authority Reports

Safety information may also be received from regulatory authorities.

Such information should be handled according to the applicable regulatory framework and relevant data-exchange arrangements.

Where authorities provide information that overlaps with a case already held by the MAH, duplicate management and reconciliation become important.

44. Partner and Licensee Cases

Pharmacovigilance responsibilities are frequently distributed across organisations.

Partners may provide cases under safety-data exchange agreements or other contractual arrangements.

The receiving organisation should have appropriate controls for:

A contractual obligation does not replace operational oversight.

45. Special Situations

Certain situations require careful assessment because the safety information may arise from circumstances other than an ordinary spontaneous report.

Examples can include:

The classification and handling of these situations should follow the applicable GVP guidance and relevant regulatory requirements.

46. Medication Errors

A medication error does not automatically have the same pharmacovigilance significance as an adverse reaction.

The organisation should assess the information according to the applicable requirements and determine whether an adverse reaction occurred or whether other reporting or follow-up obligations apply.

The source information should be preserved so that the context of the medication error can be understood.

47. Pregnancy and Breastfeeding Exposure

Pregnancy and breastfeeding exposures can require specialised handling because important information may arise even in the absence of an adverse reaction in the mother or child.

The pharmacovigilance process should identify such exposures and manage follow-up and outcome information according to the applicable requirements and procedures.

Because outcomes may occur much later than the initial report, controlled follow-up and case linkage can be particularly important.

48. Lack of Efficacy

Reports of lack of efficacy require context-specific assessment.

Not every statement that a product "did not work" has the same pharmacovigilance significance.

The organisation should assess the product, indication, clinical context and applicable regulatory requirements and determine whether the information should be managed as an ICSR or through another process.

49. Product Quality Complaints With Adverse Reactions

A product-quality complaint may contain an associated adverse reaction.

Such information can therefore require coordination between:

The interfaces should be designed so that a potentially reportable adverse reaction is not lost inside a product-quality workflow.

50. Cases From Digital Sources

Digital channels can create new sources of safety information.

The existence of a social-media post or online statement does not automatically establish that a valid ICSR exists.

The organisation should apply the applicable criteria to determine whether the information represents a reportable individual case and whether the source is identifiable.

Digital-channel monitoring should therefore be integrated with the broader safety-intake strategy rather than treated as an isolated technical activity.

51. Reconciliation Across the ICSR Lifecycle

Reconciliation should occur wherever cases move between systems or organisational units.

A useful model is:

Source
 ↓
Local system
 ↓
Global safety database
 ↓
Regulatory gateway
 ↓
Acknowledgement
 ↓
Regulatory database

Each interface can create opportunities for loss, duplication or corruption of information.

Reconciliation should therefore identify discrepancies and ensure they are investigated.

52. Outsourced Case Processing

Many MAHs use vendors for some or all ICSR activities.

Outsourcing does not remove the need for MAH oversight.

The organisation should understand:

Vendor performance should be assessed using meaningful evidence rather than contractual statements alone.

53. ICSR Metrics

Useful ICSR quality indicators can include:

Metrics should be analysed for trends and root causes.

A metric without an action threshold or governance response may provide little practical control.

54. ICSR Inspection Questions

An inspector may select a case and ask the organisation to reconstruct its complete history.

Typical questions may include:

  1. When did you first receive this information?
  2. Where did it enter the organisation?
  3. When was it identified by pharmacovigilance?
  4. How was validity determined?
  5. How was seriousness assessed?
  6. How was the product identified?
  7. Were duplicates considered?
  8. What follow-up was attempted?
  9. When was the case submitted?
  10. Was the submission accepted?
  11. What happened to any rejected transmission?
  12. What quality controls were applied?

The organisation should be able to answer these questions through its normal records and systems.

The next chunk will cover governance, quality management, inspection findings, practical case examples and the integrated end-to-end ICSR control model.

55. Governance of the ICSR Process

The ICSR process should be governed as an end-to-end pharmacovigilance process rather than as a series of independent operational tasks.

Governance should cover:

The organisation should be able to identify ownership at each interface.

56. The ICSR Process as a Control System

A useful way to assess the process is to consider five layers:

Layer Core question
Input Are potential cases identified?
Processing Are cases accurately assessed and managed?
Output Are required submissions made correctly and on time?
Control Are errors and failures detected?
Oversight Are trends and significant risks acted upon?

A strong process requires all five layers.

57. Deviations and Late Cases

When an ICSR is processed or submitted late, the organisation should assess the event through its quality-management process.

The assessment should consider:

A late case should therefore be treated as a potential signal about process performance, not merely as an isolated administrative event.

58. Root Cause of ICSR Failures

Common superficial explanations include:

"The processor made an error."

A meaningful investigation should ask whether the error resulted from:

The appropriate CAPA depends on the actual cause.

59. Vendor Oversight

Where case processing is outsourced, the MAH should maintain oversight of the vendor's performance.

Useful evidence can include:

A contractual service-level agreement is not itself evidence that the pharmacovigilance process is effective.

60. Management Information

ICSR metrics should be converted into management information where appropriate.

For example, a rise in late cases may be associated with a change in staffing, intake volume, vendor performance or system configuration.

The value comes from identifying the underlying trend and deciding whether action is needed.

61. QPPV Oversight

The QPPV should have appropriate visibility of material weaknesses affecting ICSR management.

This may include:

The QPPV does not need to review every individual case personally. Oversight should be proportionate to the nature and significance of the risk.

62. Practical Example: Missed Reporting Deadline

Imagine that several serious ICSRs are identified as submitted after the applicable regulatory deadline.

A weak response would be:

retrain the processors.

A stronger investigation would reconstruct the complete pathway:

Receipt
 ↓
Mailbox monitoring
 ↓
Triage
 ↓
Case creation
 ↓
Medical review
 ↓
QC
 ↓
Submission

The investigation might reveal that the cases were received through a shared mailbox that was not included in the out-of-hours monitoring process.

The appropriate CAPA would then address the intake control rather than only processor training.

63. Practical Example: Duplicate Cases

Suppose the same patient is reported by both a healthcare professional and a consumer.

If the reports are processed independently without adequate duplicate assessment, the safety database may contain two records representing one underlying clinical event.

The consequence is not limited to database cleanliness. Duplicate cases can affect signal detection, aggregate analyses and perceived reporting frequency.

Duplicate management is therefore a substantive pharmacovigilance control.

64. Practical Example: Product-Quality Interface

A product-quality complaint may contain an adverse reaction, but the complaint initially enters the quality system.

If the quality process does not reliably identify and transfer the safety information to pharmacovigilance, the case may be delayed or missed.

An effective interface should define:

65. Practical Example: Follow-Up Information

A case may initially be submitted with limited information and later receive a detailed medical report.

The follow-up should be linked to the existing case where appropriate, assessed for new safety information and processed within the applicable requirements.

The organisation should be able to reconstruct both the original case and the subsequent update.

66. Inspection Findings: What They Reveal

ICSR inspection findings often reveal weaknesses beyond individual data-entry errors.

Potential systemic themes include:

The most important question after a finding is therefore:

What does this tell us about the control system?

67. End-to-End ICSR Assurance

A mature ICSR process should be capable of demonstrating the following chain:

Potential safety information
          ↓
Controlled intake
          ↓
Prompt identification
          ↓
Validity assessment
          ↓
Accurate case creation
          ↓
Medical assessment
          ↓
Coding and narrative
          ↓
Duplicate management
          ↓
Follow-up
          ↓
Quality control
          ↓
Timely regulatory submission
          ↓
Acknowledgement / error management
          ↓
Reconciliation
          ↓
Ongoing updates
          ↓
Trend and quality oversight

Each transition is a potential control point.

Because Module VI is broad, several specialised subjects are better handled as dedicated articles rather than repeated in full here.

The QPPV knowledge base should therefore maintain separate, cross-referenced articles for topics such as:

The main Module VI article should remain the entry point and lifecycle overview.

This structure reduces duplication while allowing each technically important subject to be maintained independently when regulatory guidance changes.

69. Final Principles

  1. ICSR management begins with controlled identification of potential safety information.
  2. The minimum validity criteria should be applied consistently.
  3. Incomplete information does not necessarily mean that a valid case should be rejected.
  4. The regulatory clock and receipt process must be controlled.
  5. Source information should remain traceable through processing.
  6. Medical assessment, coding and narrative construction should preserve the meaning of the original report.
  7. Follow-up should be risk-based and appropriately documented.
  8. Duplicate management protects the integrity of safety analyses.
  9. Electronic submission requires control of both messages and acknowledgements.
  10. Special situations require appropriate assessment rather than automatic classification.
  11. Outsourcing does not remove MAH oversight responsibility.
  12. Reconciliation is an important control at system and organisational interfaces.
  13. Metrics should be used to identify trends and drive action.
  14. Significant ICSR weaknesses should feed into the quality system and appropriate QPPV oversight.
  15. The complete ICSR lifecycle should be traceable from initial receipt through submission and subsequent follow-up.

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 and applicable addenda should be consulted for detailed EU requirements.
  2. European Medicines Agency. GVP Module VI — Addendum I: Duplicate management of suspected adverse reaction reports. Relevant to duplicate identification and management.
  3. European Medicines Agency. GVP Module VI — Addendum II: ICSR masking of personal data. Relevant to protection of personal data in safety reporting.
  4. European Medicines Agency. EudraVigilance guidance and electronic reporting requirements. Relevant to electronic ICSR transmission and acknowledgement handling.
  5. International Council for Harmonisation. ICH E2A — Clinical Safety Data Management: Definitions and Standards for Expedited Reporting. Relevant to core concepts in expedited safety reporting.
  6. International Council for Harmonisation. ICH E2B(R3) — Individual Case Safety Reports. Relevant to electronic transmission and structured ICSR data.
  7. International Council for Harmonisation. ICH E2D — Post-Approval Safety Data Management: Definitions and Standards for Individual Case Safety Reports. Relevant to post-authorisation ICSR management.
  8. European Parliament and Council. Directive 2001/83/EC, as amended. EU legal framework for medicinal products for human use and pharmacovigilance.
  9. 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 GVP Module VI. It does not replace the current GVP guideline, applicable EU legislation, EudraVigilance requirements, ICH guidance or product-specific regulatory obligations.

GVP Module VI and its associated guidance may be revised. Before applying this article to a live case-processing or regulatory-reporting decision, verify the current EMA guidance, applicable legislation, reporting rules, technical requirements and effective dates.

Examples in this article illustrate process and control principles. They are not descriptions of specific regulatory inspection findings unless an authoritative source is explicitly identified.

Revision History

Related Articles

GVP Module VI Inspection Findings: Common ICSR Case-Processing Deficiencies

A practical inspection-focused guide to recurring weaknesses in individual case safety report processing and the evidence that demonstrates effective control.

GVP Module VI: Sources of Individual Case Safety Reports

A practical, source-based explanation of spontaneous, solicited and other ICSR sources, including source classification, primary-source identification and operational controls.

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.

Last reviewed: 2026-08-24