GVP Module VI: Other Organised Data Collection Systems and Solicited Sources

Introduction

Pharmacovigilance information is not obtained only through spontaneous reports. Medicinal products may be monitored through organised programmes and other systems in which information is actively collected from defined sources or populations.

These arrangements can generate safety information that requires assessment under the individual case safety report framework. They can also generate information that is important for signal detection, aggregate evaluation or risk management without constituting an individual case.

The central question is therefore not simply whether information was "solicited". The organisation must understand how the information was generated, why it was collected, what the source actually reported and which regulatory framework applies.

This distinction is particularly important following the introduction of ICH E2D(R1) into the EU framework. The revised guidance provides a more explicit framework for post-authorisation safety information from organised data-collection systems (ODCS), while preserving the need to distinguish the source of information from the subsequent ICSR assessment.

1. What Is an Organised Data-Collection System?

An organised data-collection system is a system in which information is actively collected according to a defined programme, protocol or process rather than being received solely as an unsolicited spontaneous report.

Examples can include:

• market research programmes;
• patient or disease registries;
• non-interventional studies;
• disease-management programmes;
• other structured patient programmes;
• and certain digital or technology-enabled data-collection arrangements.

The name of a programme is not sufficient to determine its regulatory classification. The organisation should examine its design and purpose.

2. Why Classification Matters

The classification of the source affects how the organisation interprets the information, determines the applicable reporting pathway and establishes responsibilities for collection, follow-up and quality control.

A useful conceptual sequence is:

How was the information generated?
             ↓
What type of source is it?
             ↓
Is the information solicited / organised?
             ↓
Does it contain an individual case?
             ↓
Does the case meet the validity criteria?
             ↓
What reporting and follow-up requirements apply?

The source classification should therefore precede, rather than replace, the individual case assessment.

3. Solicited Information Is Not Automatically a Valid ICSR

A programme may actively collect safety information without every record becoming an ICSR.

For example, a registry may collect thousands of clinical outcomes. Some may represent adverse reactions attributable to a medicinal product; others may represent disease progression, unrelated events or outcomes that do not contain the information required for an individual case.

The organisation should therefore distinguish:

organised/solicited source → safety information → ICSR validity assessment.

This is the same fundamental principle applied to other ICSR sources: the origin of the information does not eliminate the need to establish whether the minimum criteria are met.

4. Market Research

Market research can generate safety-relevant information, but its design is important.

A market-research programme that merely asks healthcare professionals or patients about their experience with a medicine may generate information that requires safety assessment. The organisation should determine whether the programme constitutes an organised data-collection system and whether adverse reactions are being actively solicited.

Example

A structured interview asks physicians whether they have observed adverse reactions with Product X during routine use.

The information is not spontaneous in the ordinary sense because the safety information was actively sought through a structured programme.

If an individual patient and suspected adverse reaction are subsequently described, the organisation must perform the appropriate ICSR assessment.

5. Registries

Registries are structured systems that collect information about patients sharing a disease, exposure, treatment or other defined characteristic.

A registry may be primarily designed for clinical or epidemiological purposes rather than pharmacovigilance.

Its existence therefore does not automatically mean that every recorded outcome is an ICSR.

The organisation should assess:

• the registry's purpose;
• inclusion criteria;
• data-collection methods;
• medicinal-product exposure information;
• adverse-event collection;
• patient-level information;
• and the relationship between the registry and the MAH's PV system.

6. Non-Interventional Studies

Non-interventional studies can generate important safety information, but their regulatory classification and reporting requirements depend on the study design and applicable legal framework.

A study should not be classified solely according to a commercial label such as "real-world evidence programme" or "observational study".

The organisation should document the actual study design and determine the applicable pharmacovigilance requirements.

7. Post-Authorisation Studies

Post-authorisation studies can be imposed or non-imposed and can have different designs and objectives.

Where a study collects individual safety information, the organisation should define how safety information enters the PV system, how cases are assessed, how duplicates are controlled and how study and PV responsibilities interact.

The study's regulatory status does not by itself determine whether every outcome is an ICSR.

8. Disease-Management and Structured Patient Programmes

Programmes that support treatment adherence, disease management or patient follow-up may collect information about symptoms, outcomes, treatment changes and adverse events.

The organisation should determine whether the programme meets the characteristics of an organised data-collection system and establish appropriate PV interfaces.

This assessment is related to, but distinct from, the dedicated PSP article in this series. PSPs are addressed separately because their operational and regulatory characteristics warrant detailed treatment.

9. Digital and Technology-Enabled Data Collection

Digital platforms can collect safety information through structured questionnaires, patient portals, applications, online programmes and other technology-enabled interactions.

The fact that information is collected electronically does not itself determine whether it is spontaneous or solicited.

The relevant question is how the information was generated and whether the platform actively solicited the safety information as part of an organised programme.

10. Study Information Versus Individual Cases

A study can generate population-level safety findings without generating an ICSR for every participant.

For example, an observational study may identify an increased incidence of an adverse outcome in a treated population. That finding may be important for signal detection or benefit-risk evaluation without providing individual cases that meet the ICSR criteria.

Conversely, the same study may contain individual patient narratives that do meet those criteria.

The organisation should therefore maintain separate processes for:

• study-level safety evaluation; and
• individual case identification and processing.

11. The Importance of the Actual Data-Collection Design

Two programmes with similar names can have different regulatory characteristics.

For example:

Programme A
Passive registry → routine clinical information

Programme B
Structured questionnaire → actively asks about adverse reactions

The names "registry" and "patient programme" do not resolve the classification. The design and operation of the programme do.

The next chunk will examine how to classify these sources under the current framework, determine whether information is solicited, assess individual cases, manage follow-up and duplicates, and distinguish study-level safety findings from ICSRs.

12. Current ICH E2D(R1) Classification

ICH E2D(R1) defines solicited reports as reports derived from organised data-collection systems (ODCS). For ICSR reporting, solicited ICSRs are classified as report from study in the ICH E2B format and require a causality assessment. The EU implementation of E2D(R1) took effect on 18 March 2026. citeturn0search0turn0search26

This does not mean that every record generated by an organised system is automatically an ICSR. The individual information still has to be assessed against the applicable ICSR criteria and regional reporting requirements.

13. The Source and the ICSR Are Different Concepts

Three questions should be kept separate:

1. Where did the information originate?
2. How was it collected?
3. Does the information constitute a valid ICSR?

For example, a patient may tell a researcher during a structured market-research interview that Product X caused nausea. The information was actively solicited, so it is not a spontaneous report. If the minimum ICSR criteria are met, the resulting ICSR is handled as a solicited/report-from-study case.

The same principle applies to other ODCSs, subject to the applicable regional requirements and the specific characteristics of the programme.

14. A Non-Interventional Study Requires More Careful Classification

A non-interventional study may collect primary data directly from patients or healthcare professionals, or it may use existing data that were originally collected for another purpose.

These designs should not be treated as interchangeable.

ICH E2D(R1) specifically addresses non-interventional studies with primary data collection and those involving secondary use of data. The organisation should therefore document which type of study it is dealing with and establish the applicable safety-data process accordingly. citeturn0search0

Example: primary data collection

A prospective observational study asks participating physicians at scheduled visits whether patients experienced adverse reactions during treatment.

The safety information is actively collected within an organised study. A report that meets the ICSR criteria is therefore a solicited/report-from-study case.

Example: secondary use of data

A database study analyses existing electronic health records without contacting patients to solicit adverse events.

The study-level findings may be important pharmacovigilance evidence, but an individual ICSR should not automatically be manufactured from every coded outcome. The organisation must apply the specific requirements governing the study and the data source.

15. Market Research: The Questionnaire Matters

Consider two programmes.

Programme A: A market-research interviewer asks: "Have you experienced any side effects with Product X?"

Programme B: An interviewer asks only about treatment satisfaction and does not seek adverse events, but the respondent voluntarily mentions that Product X caused a rash.

The first programme is clearly actively soliciting safety information. The second requires assessment of the actual circumstances under the current framework; the fact that a safety statement was volunteered does not, by itself, settle every classification question.

The organisation should document the programme design and apply the applicable E2D(R1)/regional criteria rather than classifying a source from the word "market research" alone.

16. Registry: One Registry Can Produce Different Safety Outputs

A disease registry may contain:

• treatment exposure;
• diagnoses;
• laboratory values;
• outcomes;
• hospitalisations;
• and mortality.

A registry-level analysis may demonstrate an association between treatment and an outcome. That is a population-level safety finding.

Separately, the registry may contain a narrative describing an individual patient's suspected adverse reaction. That information should undergo individual case assessment.

The two outputs should not be conflated.

17. Post-Authorisation Study: Study Result Versus Case

A post-authorisation study may identify an increased rate of an event compared with a comparator population. That finding may contribute to signal evaluation or benefit-risk assessment without requiring an ICSR for every participant.

Conversely, a study may deliberately collect individual adverse reactions and generate valid solicited ICSRs.

The study protocol, data-collection method and applicable regulatory requirements determine the appropriate pathway.

18. Disease-Management Programme

A disease-management programme may collect treatment adherence, symptoms, clinical outcomes and safety information over time.

The programme should have a defined interface with pharmacovigilance so that potentially reportable information is recognised and transferred without relying on informal judgement by programme personnel.

Where the programme is a PSP, the dedicated G15 article should be used for the detailed PSP framework rather than duplicating it here.

19. Digital Organised Data Collection

A digital platform may contain structured questions such as:

"Did you experience any adverse effects after starting the medicine?"

If this is part of an organised programme designed to collect safety information, the information may fall within the ODCS/solicited framework.

By contrast, an unsolicited adverse-reaction comment posted on a platform that is not operating as an ODCS may be managed under the spontaneous-report framework, subject to the applicable requirements. ICH E2D(R1) expressly distinguishes digital platforms operated as ODCSs from other digital sources. citeturn0search26

20. Causality in Solicited Reports

For solicited ICSRs, causality assessment is an important part of the reporting framework. ICH E2D(R1) specifies that solicited ICSRs classified as reports from study should have a causality assessment. citeturn0search26

This is an important difference from simply assuming that every event recorded in an organised programme is an adverse reaction.

The organisation should retain the source information and the basis for the causality assessment.

21. Follow-Up

Follow-up requirements depend on the nature of the source and the information available.

For an organised programme, follow-up should be integrated into the programme's operating procedures. The process should specify:

• who contacts the source;
• what information is sought;
• when follow-up is required;
• how unsuccessful attempts are documented;
• and how new information is transferred to the PV system.

Follow-up should be clinically purposeful and proportionate.

22. Duplicate Management

ODCSs create particular duplicate risks because the same patient may appear in several data streams.

For example:

Registry
   ↓
Study database
   ↓
PV database
   ↓
Separate HCP spontaneous report

The organisation should have controls to determine whether these records describe the same patient and event.

GVP Module VI Addendum I provides the dedicated EU framework for duplicate management and should be applied where relevant. EMA currently lists Addendum I as part of the GVP framework. citeturn0search1

23. Evidence of Effective Control

For an inspection, a procedure stating that ODCS information is reviewed is not sufficient by itself.

Useful evidence may include:

• programme classification assessment;
• protocol or programme description;
• data-flow diagram;
• safety-data exchange agreement;
• training records;
• screening criteria;
• case-identification records;
• causality assessments;
• reconciliation records;
• follow-up records;
• duplicate assessments;
• quality-control results;
• and evidence that changes to the programme triggered reassessment of the PV process.

The next chunk will address difficult classification scenarios, programme changes, outsourcing and vendor oversight, inspection failure modes, practical decision examples, References and Regulatory Note.

24. A Practical Classification Sequence

When a new programme is presented to the pharmacovigilance function, a useful assessment begins with the programme itself rather than with the database field that will eventually be populated.

Step 1 — Understand the programme

Obtain the protocol, questionnaire, registry description, data-flow diagram, contractual documents and other material needed to understand how information is generated.

Step 2 — Determine whether safety information is actively solicited

Ask whether the programme actively seeks adverse events or adverse reactions, or whether safety information is merely capable of being volunteered during another activity.

Step 3 — Identify the relevant source

Determine whether the information comes from a study, registry, market-research activity, disease-management programme, digital ODCS or another defined organised system.

Step 4 — Assess the individual information

Determine whether an identifiable patient, reporter, suspected medicinal product and suspected adverse reaction are present, applying the current applicable criteria.

Step 5 — Determine the reporting pathway

Only after the preceding assessment should the organisation determine the applicable ICSR and regulatory reporting pathway.

25. Scenario: A Registry Reports Only a Population Signal

A registry analysis finds that patients receiving Product X have a higher incidence of hepatic events than an external comparator population. No individual patient narratives are available.

This is important safety information, but the analysis should not be converted automatically into individual ICSRs.

The finding may instead enter signal management, aggregate safety evaluation or risk-management processes according to the applicable framework.

26. Scenario: The Same Registry Contains an Individual Narrative

The registry additionally contains a detailed record for one patient who developed a suspected adverse reaction after Product X exposure.

That individual information should be assessed separately against the ICSR criteria.

The existence of the population-level analysis does not prevent an individual case from being generated where the criteria are met.

27. Scenario: Market Research Actively Solicits Adverse Reactions

A questionnaire asks respondents specifically whether they experienced adverse reactions after using Product X and requests patient-level details.

This is fundamentally different from an unsolicited report received through a spontaneous channel. If an individual case is identified and the applicable criteria are satisfied, it should be processed according to the solicited/report-from-study framework under current E2D(R1).

The organisation should retain evidence of how the questionnaire was designed because the collection method is part of the classification rationale.

28. Scenario: Market Research That Does Not Solicit Safety

A market-research interview asks only about prescribing preferences. During the interview, a physician spontaneously mentions that a particular patient developed a rash with Product X.

The classification should be based on the actual circumstances and applicable current guidance, not simply on the fact that the conversation occurred within a market-research project.

This is precisely why programme classification should be documented at the design level and not inferred from the commercial name of the activity.

29. Scenario: Secondary Data Study

An MAH analyses an existing healthcare database and identifies an increased incidence of myocardial infarction among exposed patients.

The finding may be important evidence for pharmacovigilance, but the organisation should not automatically create an ICSR for every coded event in the database.

The study's design, data source and applicable regulatory framework determine how the information should be handled.

30. Scenario: Digital Platform

A patient-support website includes a structured questionnaire asking patients to report adverse reactions. The questionnaire is part of a defined programme.

The organised nature of the collection is relevant to classification.

Conversely, an unrelated public website contains an unsolicited comment from a patient describing an adverse reaction. The mere fact that the information was found online does not make it an organised data-collection system.

31. Scenario: Programme Changes Mid-Lifecycle

A programme initially collects only treatment adherence information. Six months later, the sponsor adds a structured adverse-event questionnaire.

That change can materially alter the pharmacovigilance characteristics of the programme.

The PV function should therefore reassess:

• source classification;
• case-identification procedures;
• reporting timelines;
• data transfer;
• follow-up;
• training;
• vendor agreements;
• and reconciliation.

A change-control process should prevent the revised programme from operating for months under an obsolete PV assessment.

32. Scenario: Vendor Collects the Information

An MAH contracts a service provider to operate an organised programme. The vendor receives patient information and identifies potential adverse reactions.

Delegating the operational activity does not remove the need for the MAH to maintain appropriate oversight of the pharmacovigilance process.

The contractual framework should clearly establish safety-information escalation, timelines, training, data quality, reconciliation, inspection access and oversight.

33. Scenario: One Patient Appears in Several Systems

A patient may appear in a registry, a post-authorisation study, a PSP and a spontaneous report.

The organisation should use appropriate duplicate controls to determine whether the records represent the same patient and event.

A sophisticated PV system therefore needs interfaces between study, programme and central PV databases rather than isolated case-processing streams.

34. Inspection Perspective

An inspector examining an ODCS may reasonably ask:

• How was this programme classified?
• Who approved the PV assessment before launch?
• What evidence demonstrates whether safety information is solicited?
• How are potential ICSRs identified?
• How are study-level findings separated from individual cases?
• Who performs medical assessment and causality assessment?
• How is follow-up controlled?
• How are duplicates identified?
• How does the MAH oversee the vendor?
• What happens when the programme changes?

A strong system can answer these questions using contemporaneous records rather than reconstructing the rationale retrospectively.

35. Common Failure: Classifying by Programme Name

Calling an activity a "registry", "market research project", "digital programme" or "patient programme" does not by itself establish its pharmacovigilance classification.

The actual collection mechanism matters.

36. Common Failure: Treating Every Study Outcome as an ICSR

Population-level study results and individual case reports are different safety-data outputs.

Automatically converting every study outcome into an ICSR can create large volumes of low-value or artificial data while failing to preserve the distinction between individual and aggregate evidence.

37. Common Failure: Treating Solicited as Equivalent to Adverse Reaction

Solicitation describes how information was obtained. It does not mean that every reported event is necessarily an adverse reaction.

The organisation still needs an appropriate medical and regulatory assessment of the information.

38. Common Failure: Ignoring Programme Changes

A programme can evolve from a simple service activity into an active safety-data collection system.

Failure to reassess the PV implications of material changes can create gaps in case identification, reporting and oversight.

39. Common Failure: Outsourcing Without Effective Oversight

A vendor may perform the operational work while the MAH retains responsibility for ensuring an effective PV system.

A contract alone is not evidence of effective oversight. The organisation should be able to demonstrate monitoring, quality controls, issue management and escalation.

40. Practical Control Framework

A mature ODCS governance model should include:

1. documented classification before programme launch;
2. PV review of protocol/questionnaire design;
3. defined safety-information flows;
4. controlled validity and medical-assessment procedures;
5. appropriate causality assessment for solicited ICSRs;
6. defined follow-up processes;
7. duplicate management;
8. reconciliation with the central PV database;
9. vendor oversight where applicable;
10. change control;
11. periodic quality review;
12. inspection-ready evidence.

Key Takeaways

• Solicited information is generated through an organised data-collection system; it is not synonymous with a valid ICSR.
• The design and operation of the programme matter more than its commercial name.
• Study-level safety findings and individual case reports should remain conceptually distinct.
• Current ICH E2D(R1) classifies valid solicited ICSRs as reports from study in the ICH E2B reporting framework and requires a causality assessment.
• Primary-data and secondary-data non-interventional studies require careful classification.
• Digital information can be solicited or unsolicited depending on how it was generated.
• Material programme changes should trigger reassessment of the PV process.
• Outsourcing operational activities does not eliminate the need for effective MAH oversight.
• Duplicate management, reconciliation and contemporaneous documentation are important inspection evidence.

References

1. European Medicines Agency. Good Pharmacovigilance Practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products.
2. International Council for Harmonisation. ICH E2D(R1) — Post-Approval Safety Data: Definitions and Standards for Management and Reporting of Individual Case Safety Reports.
3. European Medicines Agency. EU implementation strategy for ICH E2D(R1).
4. European Medicines Agency. EudraVigilance and ICSR reporting guidance relevant to solicited reports and organised data-collection systems.
5. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended.
6. European Parliament and Council. Directive 2001/83/EC, as amended, where applicable.

Regulatory Note

This article explains organised data-collection systems and solicited safety information within the EU pharmacovigilance framework. It does not replace current GVP Module VI, ICH E2D(R1), applicable EU legislation, study-specific requirements or organisational procedures.

The EU implementation of ICH E2D(R1) is subject to the implementation arrangements and transition provisions published by EMA. Current regulatory and technical guidance should be checked before changing an operational PV process.

The examples in this article are illustrative and are not presented as descriptions of actual regulatory inspection cases unless a specific source is identified.