GVP Module VI: Data Quality, Case Processing Controls and Reconciliation

Introduction

Individual case safety report processing is often described as a sequence of operational tasks: intake, triage, data entry, medical review, quality control and submission. A mature pharmacovigilance system must treat the sequence as a controlled information process rather than as a collection of independent activities.

The quality of an ICSR depends on the information captured from the source, the assessments applied during processing, the integrity of the database representation, the correctness of the regulatory message and the organisation's ability to demonstrate what happened to the case.

GVP Module VI places these activities within the broader requirements for collection, management and submission of reports of suspected adverse reactions. The practical challenge is to translate those requirements into controls that prevent errors, detect them when they occur and provide evidence of effective implementation.

1. What Does ICSR Data Quality Mean?

ICSR data quality has several dimensions.

A case may be:

• complete — relevant available information has been captured;
• accurate — the database reflects the source information correctly;
• consistent — related fields and assessments do not contradict one another without explanation;
• timely — information is processed and submitted within the applicable requirements;
• traceable — the organisation can reconstruct the history of the case;
• clinically meaningful — medical information has been appropriately assessed and represented;
• regulatorily usable — the transmitted information can support pharmacovigilance activities.

These dimensions overlap but are not interchangeable.

A case can be complete but incorrectly coded. It can be accurate but submitted late. It can be technically valid but clinically incomplete.

2. The End-to-End Control Model

A useful model is:

Source information
      ↓
Intake and triage
      ↓
Validity assessment
      ↓
Case creation
      ↓
Medical assessment
      ↓
Data entry / coding
      ↓
Quality control
      ↓
Submission decision
      ↓
E2B(R3) transmission
      ↓
Acknowledgement
      ↓
Reconciliation
      ↓
Follow-up / amendment / closure

Each transition creates a potential control point.

3. Source Fidelity

The first data-quality control is fidelity to the original source.

The case record should preserve the clinically relevant information actually provided by the reporter. A processor should not silently convert uncertainty into certainty simply because the database requires a structured value.

For example, if the reporter states that a patient "may have had a seizure," the processor should not automatically record a confirmed seizure without an appropriate basis.

Similarly, an unknown date should not be transformed into an invented date merely to complete a database field.

4. Minimum Criteria and Data Quality

The minimum criteria for a valid ICSR should be distinguished from the broader information needed for a high-quality case.

A report may satisfy the minimum criteria and therefore require expedited processing while still containing substantial missing clinical information.

The correct response to a valid but incomplete case is generally follow-up and controlled case management, not treating the case as invalid merely because additional information would be desirable.

5. Case Intake Controls

Intake controls should establish when information enters the pharmacovigilance process and who is responsible for the next action.

A controlled intake process should address, as applicable:

• receipt date;
• source;
• medicinal product;
• patient information;
• reporter information;
• suspected reaction or event;
• seriousness information;
• duplicate indicators;
• and the date on which the organisation became aware of the report.

The organisation should define how different channels such as email, telephone, web forms, literature, organised programmes and EudraVigilance downloads enter the controlled process.

6. Triage Is a Control, Not Merely a Queue

Triage determines which cases require immediate action and which can follow the normal workflow.

It should identify, as appropriate:

• potentially serious cases;
• cases approaching reporting deadlines;
• cases requiring medical escalation;
• potential duplicates;
• special situations;
• product-related issues requiring other functions;
• and information requiring urgent regulatory attention.

Triage rules should be documented and periodically assessed for effectiveness.

7. Data Entry and Source Documents

The organisation should maintain appropriate traceability between the source and the electronic case.

The level of source documentation required depends on the applicable process and data-protection requirements, but the principle is consistent: an auditor or inspector should be able to understand how important case information was obtained and represented.

8. Coding Controls

Coding can materially change the usefulness of safety data.

Important coding domains may include:

• adverse reactions;
• medicinal products;
• indications;
• medical history;
• laboratory findings;
• and other structured safety information.

The organisation should use controlled terminology and defined coding conventions appropriate to its systems and regulatory requirements.

9. Medical Assessment

Medical review should not be reduced to selecting a causality category from a drop-down list.

The reviewer should consider the available clinical evidence, chronology, alternative explanations, concomitant medicines, underlying disease and other relevant information.

Where the evidence is insufficient, the uncertainty should be preserved rather than replaced by an unsupported conclusion.

10. Quality Control

Quality control should be designed according to risk.

A mature QC system does not merely repeat every processor's work line by line. It identifies critical attributes and controls the areas where an error could materially affect patient safety, regulatory compliance or the reliability of safety analysis.

The organisation should define:

• which cases require enhanced review;
• which data elements are critical;
• which errors require immediate correction;
• how QC findings are recorded;
• and how recurring errors enter the quality-management system.

11. Reconciliation

Reconciliation compares two or more systems or records to identify discrepancies that require investigation.

Examples include reconciliation between:

• safety databases and source systems;
• case-processing systems and EudraVigilance submissions;
• clinical or organised-study systems and PV databases;
• vendor systems and the MAH database;
• and EudraVigilance downloads and internally held cases.

Reconciliation should have a defined purpose, frequency, population, responsibility and exception-management process.

12. Reconciliation Is Not the Same as Data Comparison

A spreadsheet that lists two populations side by side is not necessarily an effective reconciliation control.

An effective reconciliation should establish:

1. what populations are being compared;
2. what constitutes a match;
3. what constitutes an exception;
4. who investigates the exception;
5. how the investigation is documented;
6. when corrective action is required;
7. and how unresolved exceptions are escalated.

The next chunk will develop these controls further, including reconciliation design, critical data elements, quality metrics, vendor interfaces, case-processing deviations and difficult practical examples.

13. Critical Data Elements

Not every field in an ICSR has the same regulatory and clinical importance. Organisations should identify data elements for which an error could materially affect case validity, reporting, medical assessment, duplicate detection or downstream safety evaluation.

Examples may include:

• patient identifiers and demographics;
• reporter identity and qualification;
• medicinal product and active substance;
• reaction/event terms;
• seriousness;
• dates relevant to the case chronology;
• outcome;
• causality assessment where applicable;
• country of occurrence;
• source and receipt information;
• and information required for electronic submission.

The precise critical-data set should reflect the organisation's processes, systems and applicable regulatory requirements rather than being copied mechanically from another company.

14. Completeness Versus Accuracy

A common quality-management error is to treat completeness as synonymous with quality.

Consider two cases:

Case A: The database contains every available field, but the product was coded incorrectly.

Case B: The product is correctly identified, but the reporter did not provide the patient's age.

Case A has greater apparent completeness but may have the more consequential data-quality defect.

Quality controls should therefore distinguish missing information from incorrect information.

15. Reconciliation Design

A reconciliation should begin with a defined question.

For example:

Have all ICSRs received from a particular source during the defined period entered the central PV system, and have all cases requiring regulatory submission been transmitted and appropriately acknowledged?

The reconciliation population, matching criteria and exception rules should be defined before the comparison is performed.

A reconciliation that is redesigned after exceptions are found can unintentionally conceal the very problem it was intended to identify.

16. Source-to-PV Reconciliation

Where safety information originates in another operational system, reconciliation should establish that relevant information reached pharmacovigilance.

Potential source systems include:

• patient-support programmes;
• clinical or non-interventional studies;
• medical information systems;
• product complaints;
• scientific-information services;
• digital reporting channels;
• and vendors operating safety-relevant processes.

The purpose is not necessarily to force every source record into the PV database. It is to demonstrate that the defined criteria for safety-information escalation operate effectively.

17. PV Database-to-EudraVigilance Reconciliation

The electronic-submission article in this series describes the technical reporting lifecycle in greater detail. G11 focuses on the control objective: ensuring that cases requiring transmission have a corresponding regulatory reporting outcome and that exceptions are investigated.

Potential reconciliation attributes include:

• internal case number;
• worldwide unique case identification;
• transmission date;
• message type;
• acknowledgement status;
• validation result;
• and corrective-action status.

The exact fields and process should follow the current EudraVigilance technical requirements.

18. Reconciliation Exceptions

An exception should not disappear simply because it cannot be immediately resolved.

A controlled exception process should record:

• the discrepancy;
• date detected;
• responsible investigator;
• assessment;
• corrective action;
• escalation where necessary;
• and closure rationale.

Ageing exceptions should be visible to management according to their risk.

19. Reconciliation Frequency

There is no universal frequency that is appropriate for every reconciliation.

Frequency should reflect factors such as:

• reporting volume;
• reporting timelines;
• source criticality;
• system interfaces;
• known failure modes;
• vendor performance;
• and the potential impact of an undetected discrepancy.

A monthly reconciliation may be reasonable for one low-volume interface but inappropriate for a process in which an unresolved discrepancy could cause a time-critical reporting failure.

The rationale for the selected frequency should be documented.

20. Quality Metrics

Metrics should describe whether controls are working, not merely how much work was performed.

Useful measures can include:

• percentage of cases processed within defined internal timelines;
• proportion of cases requiring rework;
• critical QC error rate;
• overdue follow-up rate;
• reconciliation exception rate;
• aged reconciliation exceptions;
• transmission rejection rate;
• and recurring error categories.

Metrics should be interpreted with context. A low error rate can be misleading if QC does not reliably detect errors.

21. Error Trending

Repeated errors should be analysed for patterns.

For example, if multiple cases from one source repeatedly contain incorrect seriousness assessments, the response should not necessarily be another round of individual case correction.

The organisation should investigate whether the underlying problem is:

• unclear instructions;
• inadequate training;
• poor source forms;
• system configuration;
• vendor performance;
• workload;
• or an ineffective QC control.

Where appropriate, recurring errors should enter the pharmacovigilance quality system.

22. Deviations and Case-Processing Errors

An error should be assessed according to its actual impact.

A typographical error that is corrected before submission is not necessarily equivalent to an incorrect seriousness assessment transmitted to EudraVigilance.

The organisation should have defined criteria for determining when a case-processing error constitutes a deviation, requires escalation, affects reporting compliance or warrants broader corrective action.

23. Rework as a Quality Signal

High volumes of rework can indicate a weak process even when final cases appear correct.

For example, repeated QC correction of the same field can indicate that the data-entry interface or source documentation is poorly designed.

A mature quality system therefore analyses why the correction was required, not only whether the correction was eventually made.

24. Vendor Reconciliation

Where a vendor processes cases or operates an interface, reconciliation should not rely solely on the vendor's own statement that all work was completed.

The MAH should have appropriate independent or controlled oversight evidence, proportionate to the risk.

Potential controls include:

• agreed data-transfer reports;
• case-count reconciliation;
• acknowledgement reconciliation;
• exception reports;
• quality metrics;
• periodic review;
• audit rights;
• and escalation procedures.

25. Difficult Scenario: One Source Record, Two Cases

A vendor sends two records for what appears to be one patient and event. The PV database creates two cases before the discrepancy is identified.

The issue is not simply a duplicate case. The organisation should determine why the source-to-PV control permitted the duplication and whether other records from the same source may be affected.

This is an example of why reconciliation and duplicate management should feed into broader quality analysis.

26. Difficult Scenario: Missing Follow-Up Information

A serious case remains clinically incomplete after an initial follow-up attempt.

The case should not automatically be removed from quality metrics because the reporter did not respond. The organisation should record the attempt and assess whether additional follow-up is warranted according to the follow-up process.

Detailed follow-up methodology—including how cases are selected, prioritised, contacted and followed up—is addressed separately in G19 — GVP Module VI: Follow-Up of Individual Case Safety Reports.

27. Difficult Scenario: Reconciliation Finds a Late Submission

A reconciliation identifies a case that should have been transmitted earlier but was not.

The organisation should address both the individual case and the systemic question: why did existing controls fail to identify the missed submission?

Depending on the circumstances, the investigation may need to examine intake, triage, case processing, submission monitoring, system interfaces, vendor performance and management oversight.

28. Inspection Perspective

An inspector is likely to be interested not only in the final case but in whether the organisation's controls reliably produce correct cases.

Evidence can include:

• SOPs and work instructions;
• QC records;
• reconciliation procedures and outputs;
• exception logs;
• metrics and trends;
• deviation investigations;
• CAPA records;
• vendor oversight records;
• system validation and change-control documentation;
• and examples demonstrating that identified errors led to appropriate action.

The strongest evidence demonstrates a closed control loop:

Error detected
    ↓
Impact assessed
    ↓
Case corrected
    ↓
Root cause considered
    ↓
Systemic impact assessed
    ↓
Corrective action
    ↓
Effectiveness checked

The next chunk will address advanced control design, follow-up boundaries, data integrity, inspection scenarios, common deficiencies and the final References + Regulatory Note.

25. Critical Data Elements

Not all ICSR fields have the same safety or regulatory significance. A quality system should identify data elements for which an error could materially affect case validity, seriousness, reporting timeliness, regulatory assessment or safety analysis.

Examples may include:

• patient and reporter identifiers;
• medicinal product identity;
• suspected reaction;
• date of receipt and awareness;
• seriousness;
• outcome;
• relevant exposure information;
• causality assessment where applicable;
• and information required for electronic submission.

The exact critical-data set should be defined against the organisation's processes and applicable technical requirements rather than copied mechanically from another organisation.

26. Completeness Should Be Interpreted Carefully

A case should not be considered defective merely because information that would be useful is unavailable.

For example, a serious valid report may initially lack laboratory results, detailed medical history or complete treatment information. Those gaps should generate appropriate follow-up where useful; they do not necessarily invalidate the original report.

Conversely, a database can appear highly complete while containing values that are unsupported by the source.

The quality objective is therefore accurate and appropriately complete information, not maximum population of every field.

27. Reconciliation With EudraVigilance

For cases subject to electronic submission, reconciliation should provide assurance that the organisation's submitted population corresponds to the regulatory reporting population and that transmission outcomes have been appropriately handled.

The control should be capable of identifying, as applicable:

• cases expected to be submitted but absent from transmission records;
• messages transmitted but rejected;
• cases requiring follow-up transmission;
• unexpected duplicate submissions;
• and unresolved transmission exceptions.

The organisation should define the source of truth for each reconciliation attribute and retain evidence of investigation and resolution.

28. Reconciliation With Vendors and Study Systems

Where a vendor, clinical system, PSP, registry or other source system generates safety information, reconciliation should be designed around the actual information flow.

For example, if a vendor sends potential safety cases to the MAH, reconciliation should not merely compare the number of cases transferred. It should provide assurance that the population requiring transfer was identified and that exceptions were investigated.

29. Reconciliation Frequency

There is no single universally appropriate reconciliation frequency for every interface.

Frequency should reflect the risk, volume, reporting deadlines, system architecture and consequences of an undetected discrepancy.

A high-volume interface feeding expedited safety reporting may require substantially more frequent control than a low-volume interface with no time-critical reporting consequence.

The rationale should be documented and periodically reassessed.

30. Quality Metrics

Useful metrics can include:

Metrics should not be interpreted in isolation. A very low QC error rate may indicate excellent quality—or an ineffective QC process.

31. Trending Errors

Repeated errors should be analysed rather than corrected indefinitely at case level.

For example, if processors repeatedly misclassify seriousness because the procedure is ambiguous, retraining alone may not be sufficient. The underlying procedure, decision logic, training materials and quality controls should be examined.

This connects ICSR data quality with the broader pharmacovigilance quality system and CAPA process.

32. Case-Processing Deviations

A deviation from the approved case-processing procedure should be assessed according to its potential impact.

The organisation should determine whether the deviation affected:

• validity;
• reporting timeliness;
• clinical assessment;
• data integrity;
• regulatory submission;
• or downstream safety analysis.

Not every procedural deviation has the same significance, but repeated minor deviations may indicate a systemic weakness.

33. Difficult Scenario: Correct Case, Wrong Coding

A valid serious ICSR is processed and submitted on time, but the reaction is coded to an inappropriate medical concept.

The case may therefore be technically submitted on time while the safety information is distorted.

The organisation should assess the clinical and regulatory impact, correct the case as appropriate and determine whether other cases may have been affected by the same coding problem.

34. Difficult Scenario: Reconciliation Finds a Missing Case

A monthly reconciliation identifies a valid case present in the source system but absent from the PV database.

The investigation should establish where the process failed: source identification, transfer, intake, triage or case creation.

The organisation should then determine the impact on reporting timelines and assess whether other cases may have followed the same failed pathway.

35. Difficult Scenario: Rejected EudraVigilance Message

A case appears in the internal database as submitted, but the EudraVigilance acknowledgement shows that the message was rejected.

The case should not be treated as successfully submitted merely because the internal status says "sent".

The rejection should enter the controlled exception process, with correction and resubmission where required and an assessment of any reporting-timeline impact.

36. Difficult Scenario: Vendor Population Does Not Reconcile

A vendor reports that 100 safety records were transferred during a reporting period, while the MAH receives only 97 corresponding records.

The difference should not be closed simply by accepting the vendor's total.

The organisations should identify the three missing records, determine whether they were actually safety information requiring transfer, establish where the discrepancy occurred and assess any resulting regulatory impact.

37. Inspection Perspective

An inspector is likely to be interested not only in whether the organisation has a QC procedure, but whether the controls demonstrate effective operation.

Evidence may include:

• reconciliation procedures and rationale;
• completed reconciliation records;
• exception logs;
• QC findings;
• error trending;
• metrics and management review;
• deviation investigations;
• CAPA where appropriate;
• system validation/change-control records;
• vendor oversight records;
• and examples demonstrating that identified errors led to corrective action.

EMA inspection guidance identifies documentation of validated processes and qualification of systems as material inspection evidence, including where electronic activities are outsourced. citeturn0search0

38. The Difference Between Documented Control and Effective Control

A reconciliation procedure can exist while the organisation still has uncontrolled discrepancies.

A QC SOP can exist while critical errors repeatedly escape detection.

An electronic system can be validated while the operational process around it remains ineffective.

Inspection readiness therefore requires evidence that controls operate as intended and that the organisation learns from control failures.

39. Relationship With Follow-Up

Follow-up is one mechanism for improving the clinical information available in an ICSR, but it is not synonymous with data-quality control.

This article therefore treats follow-up as a lifecycle control only. The separate article GVP Module VI: Follow-Up of Individual Case Safety Reports will address how cases are selected for follow-up, prioritisation, timing, contact methods, targeted questionnaires, consent/privacy considerations and when further attempts should cease.

40. Practical Control Framework

An inspection-ready ICSR data-quality system should be able to demonstrate:

1. controlled intake;
2. valid-case assessment;
3. source fidelity;
4. defined critical data elements;
5. appropriate medical assessment;
6. controlled coding;
7. risk-based QC;
8. reconciliation of critical interfaces;
9. controlled exception management;
10. error trending;
11. effective change control;
12. appropriate vendor oversight;
13. management escalation of systemic problems;
14. and evidence that corrective action is effective.

Key Takeaways

• ICSR data quality encompasses completeness, accuracy, consistency, timeliness, traceability and clinical/regulatory usefulness.
• Validity and data quality are related but different concepts.
• Critical data elements should be identified according to risk and regulatory impact.
• Reconciliation must have a defined population, matching logic, exception process, owner and escalation route.
• Reconciliation frequency should be risk-based and justified.
• Metrics are useful only when interpreted in context and used to improve the process.
• Repeated case-level errors may indicate a systemic quality problem.
• A successful electronic transmission requires more than an internal "sent" status; validation outcomes and exceptions must be controlled.
• Outsourcing does not eliminate the need for effective MAH oversight.
• Inspection readiness depends on evidence that controls actually work, not merely on the existence of procedures.
• Detailed follow-up methodology belongs in the dedicated follow-up article.

References

1. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products (Rev. 2).
2. European Medicines Agency. GVP Module VI Addendum I — Duplicate management of suspected adverse reaction reports.
3. European Medicines Agency. GVP Module VI Addendum II — Masking of personal data in individual case safety reports submitted to EudraVigilance.
4. European Medicines Agency. EudraVigilance electronic reporting and ICSR implementation guidance.
5. International Council for Harmonisation. ICH E2B(R3) — Electronic Transmission of Individual Case Safety Reports.
6. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended.
7. European Medicines Agency. Coordination of pharmacovigilance inspections — inspection guidance and Q&A material.

Regulatory Note

This article provides an educational explanation of ICSR data quality, case-processing controls and reconciliation in the EU pharmacovigilance framework. It does not replace current GVP, EU legislation, EudraVigilance technical specifications, ICH implementation guidance or an organisation's approved procedures.

GVP Module VI and related technical guidance are subject to revision. EMA currently identifies Module VI as a module affected by the implementation of ICH E2D(R1) and by amendments to Commission Implementing Regulation (EU) No 520/2012. Current regulatory and technical documents should therefore be checked before implementing or materially changing a PV process. citeturn0search9turn0search3

The practical examples are illustrative and are not presented as descriptions of specific inspection cases unless an identified source is provided.