GVP Module VI: Duplicate ICSR Identification and Management

Introduction

The same clinical event can reach a pharmacovigilance organisation through more than one reporting pathway.

A patient may be reported by a healthcare professional and later by a patient. The same case may appear in scientific literature and in a report received directly by the MAH. A national competent authority may transmit information that overlaps with an existing MAH case.

If these reports are treated as independent patients, the safety database can overstate the number of cases and distort downstream safety assessment.

Duplicate management is therefore a fundamental ICSR data-quality control.

The basic process is:

Potential duplicate identified
          ↓
Compare available information
          ↓
Potential match?
      ↙          ↘
    No            Yes
    ↓              ↓
New case       Confirm relationship
                  ↓
             Link / merge / update
                  ↓
             Preserve history

1. What Is a Duplicate ICSR?

A duplicate ICSR occurs when information relating to the same individual clinical event is received more than once and is represented by more than one case record.

The existence of similar product and event information does not automatically prove duplication.

The assessment should consider the totality of the available information.

2. Why Duplicates Matter

Duplicates can affect:

• case counts;
• frequency calculations;
• signal detection;
• aggregate reporting;
• benefit-risk assessment;
• regulatory submissions;
• and workload.

A duplicate-management failure can therefore become a broader pharmacovigilance-system problem rather than merely a database-cleanliness issue.

3. Common Sources of Duplicates

Potential duplicates can arise from:

• spontaneous reports;
• patients and healthcare professionals reporting the same event;
• literature;
• national competent authorities;
• business partners;
• product-quality complaints;
• medical information;
• clinical programmes;
• digital sources;
• and follow-up communications.

The more reporting channels an organisation operates, the more important controlled duplicate detection becomes.

4. Initial Duplicate Screening

Potential duplicate detection can use a combination of structured and clinical information.

Useful comparison fields can include:

• patient characteristics;
• age;
• sex;
• product;
• indication;
• adverse reaction;
• onset date;
• treatment dates;
• reporter;
• healthcare setting;
• and narrative chronology.

No single field should normally be treated as conclusive in isolation.

5. Patient Characteristics

Patient characteristics can provide strong duplicate clues.

For example, two reports describing a patient of the same age with the same rare clinical event after exposure to the same product may warrant detailed comparison.

Common characteristics should increase suspicion but should not automatically establish duplication.

6. Clinical Chronology

The sequence of events is often one of the most useful duplicate indicators.

A matching chronology may include:

Product exposure
      ↓
Symptom onset
      ↓
Hospitalisation
      ↓
Diagnostic finding
      ↓
Treatment
      ↓
Outcome

Two reports with the same unusual sequence may represent the same underlying patient even when the wording differs substantially.

7. Reporter Information

Reporter information can help identify duplicates but should not be treated as a requirement for proving duplication.

The same patient may be reported by different people.

Conversely, the same reporter can submit follow-up information that should not be interpreted as a new patient merely because it arrived as a separate communication.

8. Narrative Comparison

Narratives can contain information that is not represented in structured fields.

Clinical chronology, unusual investigations, treatment details and outcomes can be particularly useful when assessing potential duplicates.

Duplicate assessment should therefore not rely exclusively on automated field matching.

9. Automated Duplicate Detection

Safety databases can identify potential duplicates using configurable rules or algorithms.

Automation can improve efficiency by identifying records that share important characteristics.

However, automated matching generally identifies potential duplicates. Human or appropriately controlled review may still be needed to determine whether the records represent the same clinical event.

10. False Positives

A duplicate-detection system can identify cases that appear similar but are genuinely different.

For example, the same product may cause similar reactions in two different patients.

The organisation should therefore avoid merging cases solely because product and event terms match.

11. False Negatives

The more serious risk can be failure to identify a true duplicate.

This can occur when:

• patient identifiers differ;
• dates are incomplete;
• terminology differs;
• one report contains substantially more detail;
• or the reports originate from different systems.

Duplicate controls should therefore combine automated screening with appropriate clinical assessment.

12. Duplicate Assessment as a Lifecycle Activity

Duplicate assessment should not occur only when a case is first created.

A case that appears unique initially may later be recognised as a duplicate when:

• an NCA case becomes available;
• a literature publication is identified;
• follow-up information is received;
• or another reporting channel provides additional information.

The process should therefore support reassessment throughout the case lifecycle.

The next chunk will cover confirmed duplicates, master cases, follow-up handling, EudraVigilance duplicates, merging/linking decisions and quality controls.

13. What Makes Two Reports Potential Duplicates?

Duplicate assessment compares information across reports to determine whether they may describe the same patient and clinical event.

Potentially useful comparison points include:

• patient characteristics;
• medicinal product;
• adverse reaction;
• dates;
• clinical setting;
• reporter information;
• source;
• and chronology.

No single field should necessarily be treated as decisive in every case.

14. Potential Duplicate Versus Confirmed Duplicate

A potential duplicate is a report requiring assessment.

A confirmed duplicate is a report for which the available evidence supports the conclusion that it describes the same underlying case as another report.

This distinction is important because over-aggressive duplicate matching can cause genuinely independent cases to be lost.

15. Duplicate Sources

Duplicates can arise because the same event is reported through different channels.

For example:

Patient
  ├── reports to MAH
  ├── reports to NCA
  └── discussed in literature

Healthcare professional
  └── reports independently

The resulting records may represent one clinical event even though their sources are different.

16. EudraVigilance Duplicates

EudraVigilance can contain cases originating from different organisations and reporting pathways.

An MAH may therefore encounter an EV case that appears to correspond to a case already held internally.

The organisation should assess the relationship rather than creating a new internal case solely because the EV case has a different identifier.

17. Literature Duplicates

A published case may describe a patient previously reported to the MAH or another regulatory authority.

The publication may add substantial clinical detail.

The correct action may therefore be to update an existing case rather than create a separate case.

The literature source should remain traceable.

18. Partner and Affiliate Duplicates

Global organisations can receive the same case through affiliates, licensing partners or other contractual arrangements.

The safety system should support duplicate detection across these organisational boundaries.

Agreements should define responsibilities for identifying and communicating potential duplicates.

19. Duplicate Algorithms

Safety databases can use automated matching algorithms to identify potential duplicates.

Matching may use combinations of:

• patient characteristics;
• event terms;
• product;
• dates;
• and source information.

Automated matching is useful for prioritisation but should not be treated as infallible.

20. False Positives

A false-positive duplicate occurs when two genuinely different cases are incorrectly treated as the same case.

This can be particularly harmful because it can reduce the apparent number of independent safety reports.

Human review and appropriate safeguards are therefore important when automated matching is used.

21. False Negatives

A false-negative duplicate occurs when two reports describing the same event are not recognised as related.

This can inflate case counts and distort signal detection, aggregate analyses and safety assessments.

Duplicate detection should therefore be monitored in both directions.

22. Master Case Management

Once two reports are confirmed as duplicates, the organisation should follow its controlled process for determining the appropriate master or surviving case.

The decision should preserve relevant information from both sources rather than simply deleting one report and losing source information.

23. Merging Cases

Where the safety system supports merging, the organisation should ensure that the resulting case retains the clinically relevant information and source history.

The process should preserve auditability so that an inspector can understand what happened to the original reports.

24. Linking Cases

In some circumstances, linking records may be more appropriate than fully merging them.

The exact approach depends on the safety system, reporting framework and relationship between the records.

The objective is to avoid duplicate counting while preserving the integrity and traceability of the underlying information.

25. Follow-Up After Duplicate Identification

A duplicate assessment can itself generate new information.

For example, one source may contain a laboratory result absent from the other case.

The organisation should assess whether the information should be incorporated into the surviving case and whether any regulatory follow-up action is required.

26. Duplicate Assessment Is Not a One-Time Event

A case that appears unique at initial processing may later be identified as a duplicate after:

• follow-up;
• literature monitoring;
• EudraVigilance monitoring;
• partner reconciliation;
• or regulatory communication.

Duplicate detection should therefore operate throughout the case lifecycle.

27. Quality Control

QC should assess whether duplicate procedures are being applied consistently.

Potential QC checks include:

• whether relevant duplicate searches were performed;
• whether potential matches were appropriately assessed;
• whether decisions were documented;
• whether information from duplicate sources was retained;
• and whether the surviving case was updated appropriately.

28. Reconciliation

Duplicate management should connect with reconciliation activities.

For example, an organisation can compare cases received from an affiliate, partner or NCA with cases already present in the global database.

This can identify both duplicates and missing cases.

29. Vendor Oversight

If duplicate screening is outsourced, the MAH should define the vendor's responsibilities and maintain appropriate oversight.

Oversight can include:

• qualification;
• performance metrics;
• sample review;
• quality control;
• deviation management;
• audit;
• and escalation.

The MAH should remain able to explain how duplicate decisions affecting its safety database are made.

30. The Next Layer: Complex Duplicate Scenarios

Some duplicate assessments are straightforward. Others require detailed comparison of chronology, source information and clinical details.

The final chunk will address complex scenarios, inspection findings, governance, metrics, practical examples, final principles, References + Regulatory Note.

31. Complex Duplicate Scenario: Different Reporters

Two reports describe a patient who received the same medicinal product and developed the same reaction. One report came from a healthcare professional and another from the patient.

The different reporter types do not establish that the reports describe different patients.

The organisation should compare the available clinical information and determine whether the reports represent one event or separate events.

32. Complex Duplicate Scenario: Different Event Dates

Two reports appear similar but contain different dates of reaction onset.

The difference should be investigated rather than used as an automatic exclusion criterion. Dates may refer to different stages of the same clinical episode, or one source may contain an error.

The chronology should be reconstructed from the available evidence.

33. Complex Duplicate Scenario: Literature and Spontaneous Report

A published case appears to describe a patient previously reported spontaneously.

The publication may contain additional laboratory results, treatment information or outcome data.

The appropriate action may be to update the existing case rather than create a second case. The publication should remain linked or otherwise traceable as an additional source.

34. Complex Duplicate Scenario: EudraVigilance and Internal Case

An NCA-originated case retrieved from EudraVigilance appears to match an MAH case.

The organisation should compare the available patient, product, event and chronology information and document the duplicate assessment.

If confirmed, the appropriate internal case should retain the relevant information and source history.

35. Complex Duplicate Scenario: Two Similar but Different Patients

Two cases involve patients of the same age group, the same medicinal product and the same reaction, but their clinical histories and treatment settings demonstrate that they are different individuals.

Similarity is not duplication.

The organisation should avoid merging cases solely because several fields are identical.

36. Duplicate Assessment After Follow-Up

A follow-up communication can reveal that a previously unique case is actually related to another case.

The duplicate assessment should therefore be repeated when material new information becomes available.

The case lifecycle should support reassessment rather than treating the original duplicate decision as permanently fixed.

37. Inspection Considerations

An inspector may ask:

• How are potential duplicates identified?
• Which fields are used by automated matching?
• How are borderline matches reviewed?
• How are false positives controlled?
• How are false negatives identified?
• How are confirmed duplicates managed?
• How is source information preserved?
• How are duplicate decisions documented?
• How are duplicates identified after follow-up or reconciliation?

The organisation should be able to demonstrate the complete decision path.

38. Inspection Risk: Duplicate Suppression Without Review

A system that automatically suppresses apparently similar reports without appropriate human assessment can create a significant data-quality risk.

Automated matching should generally support prioritisation and review rather than replace appropriate pharmacovigilance judgement where the applicable process requires assessment.

39. Inspection Risk: Loss of Source Information

Merging or deleting records can inadvertently remove information about where a case originated.

The organisation should preserve appropriate source and audit information so that the history of the case remains reconstructable.

40. Inspection Risk: Inconsistent Duplicate Decisions

If similar cases are routinely handled differently by different affiliates, vendors or processing teams, the organisation may have a systemic training, procedure or governance weakness.

Trend analysis of duplicate decisions can identify such inconsistencies.

41. Duplicate Management Metrics

Useful metrics can include:

• potential duplicate volume;
• confirmed duplicate rate;
• false-positive rate;
• duplicate findings after initial QC;
• duplicate findings during reconciliation;
• duplicate findings from audits;
• and cases reopened because of later duplicate identification.

Metrics should be interpreted in context rather than treated as simple performance scores.

42. Governance

Duplicate management should have defined ownership within the pharmacovigilance quality system.

Governance should address:

• duplicate definitions;
• system configuration;
• search parameters;
• review responsibilities;
• escalation;
• vendor controls;
• reconciliation;
• training;
• and periodic quality review.

43. Training

Training should use realistic examples because duplicate assessment often depends on clinical chronology rather than simple field matching.

Processors should understand that:

• identical products do not mean identical cases;
• different reporters do not necessarily mean different patients;
• different dates do not automatically exclude duplication;
• and a literature publication can represent an existing case.

44. What Good Looks Like

A mature duplicate-management process:

• identifies potential duplicates early;
• uses appropriate automated support;
• applies human assessment where required;
• considers the full clinical chronology;
• preserves source information;
• manages confirmed duplicates consistently;
• reassesses cases when new information appears;
• reconciles relevant external sources;
• monitors performance;
• and remains inspection-ready.

45. Practical Example: Same Patient, Two Sources

A patient reports an adverse reaction directly to the MAH. Two weeks later, the patient's physician submits a report describing the same reaction and treatment course.

The organisation identifies the likely match, compares the clinical chronology and confirms that both reports concern the same patient.

The information from the second source is incorporated into the surviving case, with both sources retained appropriately.

46. Practical Example: Similar Patients

Two patients of similar age receive the same product and develop the same reaction within the same month.

The cases contain different medical histories and treatment locations.

The cases should remain separate because the available evidence indicates two individuals.

47. Practical Example: Duplicate Identified During Audit

An audit identifies two internal cases that appear to represent the same patient.

The organisation should correct the records according to its controlled process, assess whether other cases may have been affected and determine whether a systemic root cause exists.

The audit finding should not be closed merely because the two records were merged.

48. Final Principles

1. Duplicate assessment is a clinical and data-quality assessment, not merely a database search.
2. Different sources can describe the same underlying case.
3. Similar cases are not necessarily duplicates.
4. Potential duplicates require appropriate assessment before confirmation.
5. Automated matching should be validated and monitored.
6. False positives can suppress genuine independent cases.
7. False negatives can inflate counts and distort safety analysis.
8. Confirmed duplicates should be managed without losing relevant source information.
9. Literature and EudraVigilance sources are important duplicate-detection pathways.
10. Duplicate assessment should continue throughout the case lifecycle.
11. Follow-up and reconciliation can reveal previously unrecognised duplicates.
12. Duplicate management should be governed, measured and inspection-ready.

Key Takeaways

• The objective is to avoid both duplicate counting and inappropriate case suppression.
• Clinical chronology is often more informative than simple field matching.
• A case can acquire duplicate status later as new information becomes available.
• EudraVigilance, literature, affiliates and partners are important sources for duplicate identification.
• Source traceability must survive duplicate management.
• Good duplicate management protects the quality of both individual cases and downstream signal and aggregate analyses.

References

1. European Medicines Agency. Good Pharmacovigilance Practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products. Primary EU guidance for ICSR processing and duplicate management.
2. European Medicines Agency. EudraVigilance guidance and electronic reporting requirements. Relevant to duplicate cases and exchange of ICSR information within EudraVigilance.
3. European Medicines Agency. GVP Module IX — Signal management. Relevant to the downstream impact of duplicate cases on signal evaluation.
4. European Parliament and Council. Directive 2001/83/EC, as amended. EU legal framework for medicinal products for human use and pharmacovigilance.
5. European Parliament and Council. Regulation (EC) No 726/2004, as amended. Union framework for authorisation and supervision of medicinal products and relevant pharmacovigilance obligations.
6. International Council for Harmonisation. ICH E2D — Post-Approval Safety Data Management: Definitions and Standards for Individual Case Safety Reports. Relevant to ICSR concepts and case management.

Regulatory Note

This article is an educational and practical explanation of duplicate ICSR management under the EU pharmacovigilance framework. It does not replace the current GVP Module VI, applicable EU legislation, EudraVigilance requirements or organisation-specific procedures.

The exact technical handling of duplicates can depend on the safety database, EudraVigilance functionality and current regulatory requirements. Current EMA and applicable technical documentation should be verified before changing a live process.

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