GVP Module VI: ICSR Data Quality, Follow-Up and Reconciliation

Introduction

The quality of an individual case safety report is not determined only by whether a case was created and submitted on time.

A reliable pharmacovigilance system must maintain the integrity of the case throughout its lifecycle.

That means ensuring that information is:

• accurate;
• complete to the extent reasonably possible;
• internally consistent;
• traceable to its source;
• appropriately updated after follow-up;
• correctly transmitted;
• and reconciled across relevant systems and organisational interfaces.

A useful lifecycle model is:

Initial information
      ↓
Case creation
      ↓
Assessment and processing
      ↓
Quality control
      ↓
Regulatory submission
      ↓
Follow-up
      ↓
Case update
      ↓
Resubmission where required
      ↓
Reconciliation

Data quality is therefore a lifecycle property rather than a single quality-control checkpoint.

1. What Is ICSR Data Quality?

ICSR data quality includes more than the absence of typographical errors.

Important dimensions include:

A case can therefore be technically complete while still being clinically inaccurate.

2. Source Data

The source report is the foundation of the ICSR.

Processors should preserve the meaning of the original information rather than introducing unsupported interpretations.

Source information may arrive through:

• spontaneous reports;
• literature;
• regulatory authorities;
• partners;
• medical information;
• product-quality channels;
• digital sources;
• or other pharmacovigilance pathways.

Each source can create different data-quality challenges.

3. Data Entry

Data entry should accurately translate source information into the safety database.

Controls should address:

• patient information;
• medicinal product information;
• adverse reactions;
• dates;
• seriousness;
• reporter information;
• clinical narrative;
• and relevant special situations.

Where the source does not provide information, the processor should not invent it merely to make the record appear complete.

4. Medical Assessment

Medical assessment contributes directly to ICSR quality.

The reviewer may need to assess:

• clinical chronology;
• seriousness;
• causality;
• expectedness where applicable;
• outcome;
• and the significance of follow-up information.

The assessment should be based on available evidence and documented according to the organisation's procedures.

5. Coding Quality

Coding translates clinical information into standardised terminology.

Incorrect coding can affect:

• case retrieval;
• signal detection;
• aggregate analysis;
• and regulatory reporting.

The narrative and coded terms should therefore be sufficiently aligned to represent the underlying clinical information accurately.

6. Narrative Quality

The narrative should provide a coherent clinical account.

A good narrative allows a reviewer to understand:

Who was exposed?
      ↓
To what?
      ↓
Why?
      ↓
What happened?
      ↓
When did it happen?
      ↓
What was done?
      ↓
What was the outcome?

The narrative should not contain unsupported assumptions or contradictions with structured fields.

7. Follow-Up as a Quality Process

Follow-up is an important mechanism for improving case quality after the initial report.

New information may clarify:

• patient characteristics;
• exposure;
• reaction;
• seriousness;
• outcome;
• laboratory findings;
• concomitant medicines;
• or the reporter's assessment.

The case should be reassessed when material new information becomes available.

8. Prioritising Follow-Up

Follow-up should be proportionate to the clinical and regulatory significance of the case.

Higher-priority follow-up may be appropriate where information could materially affect:

• seriousness;
• reportability;
• clinical interpretation;
• patient outcome;
• or the understanding of an important safety concern.

The organisation should have defined criteria for prioritisation.

9. Documenting Follow-Up Attempts

Where follow-up is attempted, the organisation should maintain appropriate evidence of the attempt and its outcome.

This can include:

• date;
• method of contact;
• information requested;
• response received;
• and resulting case action.

The absence of a response should not be confused with the absence of an attempt.

10. Updating the Case

New information should be incorporated into the appropriate case version.

The update should preserve the relationship between the original report and subsequent information.

The organisation should be able to reconstruct the evolution of the case over time.

11. Quality Control

Quality control should be designed around meaningful pharmacovigilance risks.

Depending on the process, QC can examine:

• case validity;
• seriousness;
• product identification;
• coding;
• narrative;
• duplicate assessment;
• follow-up;
• regulatory timelines;
• and submission data.

The next chunk will cover reconciliation across systems, data-quality metrics, deviations, CAPA, inspection considerations and practical examples.

12. Reconciliation Across Systems

Reconciliation is the controlled comparison of relevant records between systems, processes or sources to identify discrepancies.

For ICSRs, reconciliation can occur between:

• case-management and reporting systems;
• affiliate and global safety databases;
• internal cases and regulatory submissions;
• literature-monitoring records and case records;
• product-quality systems and pharmacovigilance systems;
• and vendor records and MAH records.

The objective is not merely to make two databases contain identical numbers. It is to demonstrate that safety information has moved through the intended process without unexplained loss, duplication or alteration.

13. Case Reconciliation

A basic reconciliation can compare cases expected to be present with cases actually present.

Source population
      ↓
Expected PV cases
      ↕
Cases received
      ↕
Cases entered
      ↕
Cases submitted

Differences should be investigated according to defined procedures.

14. Regulatory Submission Reconciliation

Submission reconciliation should establish whether reportable cases were transmitted and what happened after transmission.

The organisation should be able to identify:

• submitted cases;
• transmission dates;
• acknowledgements;
• rejected messages;
• corrected submissions;
• and unresolved discrepancies.

This control is particularly important when transmission is performed through external systems or vendors.

15. Reconciliation With Literature Monitoring

Where literature monitoring identifies potential ICSRs, the literature workflow should be reconcilable with the safety database.

The organisation should be able to determine whether a publication resulted in:

• a new case;
• an update to an existing case;
• a duplicate determination;
• or a documented decision not to create an ICSR.

The disposition should be traceable.

16. Reconciliation With Product Quality

Product-quality complaints can contain adverse-event information.

A controlled reconciliation or interface review can identify cases where relevant safety information entered the quality system but did not reach pharmacovigilance.

The same principle applies in the opposite direction when a pharmacovigilance case contains information relevant to product quality.

17. Data Discrepancies

A discrepancy is not automatically an error.

For example, two systems may legitimately use different identifiers or represent the same date differently.

The investigation should therefore determine:

1. whether a genuine discrepancy exists;
2. why it occurred;
3. whether it affects safety or regulatory compliance;
4. whether correction is required;
5. and whether a systemic action is necessary.

18. Root-Cause Analysis

Repeated discrepancies should trigger investigation of the underlying process.

Potential causes include:

• interface failures;
• mapping errors;
• incorrect system configuration;
• manual transcription;
• inadequate training;
• unclear procedures;
• vendor performance;
• or uncontrolled process changes.

Correcting individual records without addressing a recurring root cause can leave the underlying risk unchanged.

19. Deviations

A material departure from an approved procedure or required process should be assessed through the organisation's deviation or quality-event system.

The assessment should consider the potential impact on:

• patient safety;
• regulatory reporting;
• data integrity;
• other cases;
• and the pharmacovigilance system as a whole.

20. CAPA

Corrective and preventive action should be proportionate to the identified root cause and risk.

Examples can include:

• procedure revision;
• system configuration changes;
• additional validation;
• targeted training;
• interface correction;
• enhanced reconciliation;
• or increased oversight.

A CAPA should address the cause rather than simply instructing personnel to be more careful.

21. Data-Quality Metrics

Useful ICSR data-quality metrics can include:

• duplicate rate;
• missing-data rate for critical fields;
• coding correction rate;
• narrative QC findings;
• late-processing rate;
• follow-up completion rate;
• rejected-submission rate;
• reconciliation discrepancies;
• and recurring deviation categories.

Metrics should be interpreted in context and trended over time.

22. Quality Trends

A single error may have limited significance.

A repeated pattern can indicate a systemic control weakness.

For example, repeated errors in seriousness classification may indicate a training or procedure problem, while repeated incorrect product coding may indicate a system-mapping problem.

Trend review should therefore look beyond individual case errors.

23. Data Quality and Signal Detection

ICSR data quality directly affects downstream signal management.

Errors in coding, duplicates, missing clinical information or inconsistent case classification can distort the evidence base used for signal detection.

Data quality should therefore be considered part of the overall benefit-risk information chain.

24. Data Quality and Aggregate Reporting

Aggregate safety evaluations depend on reliable individual-case data.

Poor case quality can affect counts, distributions, clinical interpretation and trend analysis.

The organisation should therefore understand how individual case-quality problems propagate into aggregate outputs.

25. Follow-Up After Case Submission

A submitted ICSR can continue to evolve.

Follow-up information may require:

• case amendment;
• new assessment;
• updated narrative;
• changed coding;
• changed seriousness or outcome;
• and, where applicable, a follow-up regulatory submission.

The original submission should remain traceable.

26. Case Lifecycle Control

A mature case lifecycle can be represented as:

Receive
  ↓
Validate
  ↓
Create
  ↓
Process
  ↓
QC
  ↓
Submit
  ↓
Monitor acknowledgement
  ↓
Follow up
  ↓
Update
  ↓
Resubmit if required
  ↓
Reconcile

Each transition should have defined ownership and appropriate controls.

27. Practical Example: Reconciliation Finds a Missing Case

A monthly reconciliation identifies that one case present in the affiliate system does not appear in the global safety database.

The investigation finds that the interface transmission failed.

The case should be assessed for its regulatory impact, processed appropriately and the interface failure investigated as a potential systemic issue.

The correction should not end the investigation if other cases could have been affected.

28. Practical Example: Coding Discrepancy

A source report describes a specific clinical event, but the coded reaction term in the database does not accurately represent it.

QC identifies the discrepancy.

The case is corrected, but the organisation should also determine whether the same coding issue could affect other cases processed using the same instructions or configuration.

29. Practical Example: Follow-Up Changes Seriousness

An initial case is processed as non-serious. Follow-up later confirms hospitalisation related to the suspected reaction.

The case assessment must be updated and the organisation should determine whether a regulatory follow-up submission is required.

The change should be traceable to the follow-up information that triggered it.

30. Practical Example: Vendor Reconciliation Failure

A vendor reports that all cases were transmitted successfully, but an MAH reconciliation identifies several missing acknowledgements.

The discrepancy should be investigated against the vendor's transmission records, the regulatory response and the MAH database.

The outcome should determine whether cases were actually accepted and whether any reporting deadlines were affected.

The next chunk will cover inspection findings, governance, audit strategy, practical end-to-end scenarios, final principles, References and the Regulatory Note.

31. Inspection Considerations

ICSR data quality is frequently demonstrated through the ability to reconstruct the history of a case.

An inspector may select a case and ask:

• When was the case received?
• What was the source?
• How was validity established?
• What assessments were performed?
• What quality checks were completed?
• When was the case submitted?
• What acknowledgement was received?
• What follow-up occurred?
• What changed after follow-up?
• Was the updated information submitted where required?
• How was the final status reconciled?

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

32. Inspection Risk: Incomplete Audit Trail

A database may contain the current case but lack sufficient evidence of how the case reached its current state.

For example, an inspector may see that seriousness is currently recorded as serious but be unable to determine when or why it changed.

A mature system should preserve appropriate history and the source of material changes.

33. Inspection Risk: Reconciliation Without Investigation

An organisation may perform monthly reconciliation but simply record that discrepancies were "resolved".

That does not demonstrate effective control.

Material discrepancies should have documented investigation, impact assessment and appropriate corrective action.

Where recurring discrepancies occur, the organisation should consider whether a systemic CAPA or process change is warranted.

34. Inspection Risk: Follow-Up Not Reflected in Reporting

A case may receive clinically important follow-up information after the initial submission.

If the internal case is updated but the regulatory submission is not appropriately managed, the system may contain a more current record than the regulator has received.

The organisation therefore needs a controlled link between case updates and regulatory resubmission requirements.

35. Audit Strategy

An effective audit of ICSR data quality should examine the complete lifecycle rather than only a sample of database fields.

A risk-based sample can include:

• initial cases;
• serious cases;
• follow-up cases;
• cases with major data changes;
• literature cases;
• cases from partners or affiliates;
• rejected submissions;
• and cases affected by system or interface changes.

The audit should compare source information, database information and regulatory output.

36. Source-to-Submission Review

One particularly useful audit technique is a source-to-submission comparison.

Original source
      ↓
Internal case
      ↓
QC-approved case
      ↓
Electronic ICSR
      ↓
Regulatory acknowledgement

The reviewer can then determine whether important information was preserved, incorrectly transformed or lost at any stage.

37. Governance

ICSR data quality should have defined ownership within the pharmacovigilance quality system.

Responsibilities should cover:

• case processing;
• medical review;
• quality control;
• follow-up;
• submission;
• reconciliation;
• system ownership;
• vendor oversight;
• deviation management;
• and CAPA.

The QPPV should have appropriate visibility of significant systemic weaknesses affecting the integrity or timeliness of safety information.

38. Vendor Oversight

Where case processing, data entry, literature monitoring, reconciliation or regulatory submission is outsourced, the MAH should retain appropriate oversight.

Useful controls include:

• defined responsibilities;
• service-level measures;
• quality metrics;
• sample review;
• reconciliation;
• deviation reporting;
• audit;
• and CAPA.

A vendor's statement that its records are complete is not a substitute for independent oversight.

39. Change Control

Changes to safety databases, interfaces, controlled terminology, workflows or reporting systems can affect ICSR data quality.

Change control should assess potential impact on:

• existing cases;
• new case processing;
• data migration;
• coding;
• electronic reporting;
• reconciliation;
• and historical traceability.

Testing should be proportionate to the risk and should include realistic pharmacovigilance scenarios.

40. What Good Looks Like

A mature ICSR data-quality system has:

• accurate source capture;
• clinically coherent narratives;
• appropriate coding;
• controlled medical assessment;
• risk-based follow-up;
• documented QC;
• effective reconciliation;
• case-version control;
• submission monitoring;
• meaningful metrics;
• root-cause investigation;
• appropriate CAPA;
• vendor oversight;
• and complete lifecycle traceability.

The key outcome is not a database with zero errors. It is a controlled system that detects important errors, corrects them, understands their causes and prevents recurrence where necessary.

41. Final Principles

1. ICSR quality is a lifecycle property, not a single QC event.
2. Source information should be represented accurately without inventing missing information.
3. Clinical assessment and coding should remain evidence-based and internally consistent.
4. Follow-up can materially change the clinical and regulatory significance of a case.
5. Reconciliation should identify unexplained differences between relevant systems and processes.
6. A discrepancy should be investigated before being classified as an error or dismissed as harmless.
7. Repeated discrepancies can indicate systemic weaknesses requiring root-cause analysis.
8. Regulatory submission status should remain linked to the current case lifecycle.
9. Outsourcing does not remove the MAH's responsibility for appropriate oversight.
10. System and process changes should be assessed for their potential effect on data integrity.
11. Metrics should identify trends rather than simply count errors.
12. Inspection readiness requires reconstruction of the case from source through regulatory outcome.

Key Takeaways

• High-quality ICSRs are accurate, clinically coherent, appropriately complete, timely and traceable.
• Follow-up is an important mechanism for improving case quality and may change regulatory reporting requirements.
• Reconciliation is a substantive pharmacovigilance control, not merely an administrative exercise.
• Data discrepancies should be investigated for patient-safety and regulatory impact.
• Repeated errors should lead to root-cause analysis rather than repeated correction of individual cases.
• Case quality affects downstream signal detection, aggregate analysis and regulatory decision-making.
• A mature system can reconstruct the complete lifecycle of an ICSR and demonstrate why important decisions were made.

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 ICSR collection, management, follow-up and submission requirements.
2. European Medicines Agency. GVP Module I — Pharmacovigilance systems and their quality systems. Relevant to quality-system governance, responsibilities, procedures, quality controls and oversight.
3. European Medicines Agency. GVP Module II — Pharmacovigilance system master file (PSMF). Relevant to documentation and evidence of the pharmacovigilance system and its operation.
4. European Medicines Agency. GVP Module IX — Signal management. Relevant to the effect of ICSR data quality on signal detection and evaluation.
5. European Medicines Agency. EudraVigilance guidance and electronic reporting requirements. Relevant to regulatory submission, acknowledgements and reconciliation of electronic ICSRs.
6. International Council for Harmonisation. ICH E2B(R3) — Individual Case Safety Reports. Relevant to structured electronic ICSR data and data-quality principles.
7. European Parliament and Council. Directive 2001/83/EC, as amended. EU legal framework for medicinal products for human use and pharmacovigilance.
8. 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 ICSR data quality, follow-up and reconciliation under the EU pharmacovigilance framework. It does not replace the current GVP guidance, applicable EU legislation, EudraVigilance technical requirements or organisation-specific procedures.

The precise requirements for follow-up, reconciliation, submission and data retention depend on the applicable regulatory framework and current technical requirements. Before applying this article to a live pharmacovigilance process, verify the current EMA guidance, applicable legislation, EudraVigilance documentation and effective dates.

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