GVP Module VI: Patient Support Programmes and Solicited Reports

Introduction

Patient Support Programmes (PSPs) are an important source of post-authorisation safety information. They can generate information through structured interactions between patients, healthcare professionals, a marketing authorisation holder (MAH) and organisations acting on the MAH's behalf.

PSPs are also an area where pharmacovigilance teams can make fundamental classification errors. A report received through a PSP is not automatically a valid ICSR, and the fact that information is collected through a programme does not mean that every event should be treated in exactly the same way.

The regulatory assessment needs to distinguish:

Organised data collection
        ↓
Was information actively/solicitedly collected?
        ↓
What safety information was obtained?
        ↓
Does it describe a suspected adverse reaction?
        ↓
Does it satisfy ICSR validity criteria?
        ↓
What reporting pathway applies?

1. The Current Regulatory Context

The current EU framework is in transition because ICH E2D(R1) became effective in the EU on 18 March 2026. EMA's EU implementation strategy states that the revised guideline applies during a transition period through 18 September 2026, while the current GVP Module VI remains the applicable regional framework during that transition. citeturn0search40turn0search1

This is particularly important for PSPs because ICH E2D(R1) introduces an updated PSP definition and clarifies the broader concept of organised data collection systems (ODCSs). EMA's implementation strategy specifically provides practical instructions for MAHs and inspectors on this transition. citeturn0search40

2. What Is a Patient Support Programme?

The current ICH E2D(R1) framework defines PSPs as organised data collection systems initiated by an MAH in which patients enrol to support their use of the MAH's medicinal product or management of their medical condition, with a mechanism for two-way communication between the MAH or its third party and patients or healthcare professionals. citeturn0search40

This definition is more specific than simply describing any programme involving patients as a PSP.

The organisation should therefore establish what the programme actually does, who initiated it, who participates and how communication occurs.

3. Organised Data Collection Systems

PSPs are one type of organised data collection system.

Other ODCSs can include structured programmes or activities designed to collect post-authorisation safety information through defined interactions or data-collection methods.

ICH E2D(R1) specifically updates the framework for newer sources such as PSPs, market research programmes, digital platforms and non-interventional studies. citeturn0search1turn0search39

The classification of the source matters because solicited reports have different characteristics from spontaneous reports.

4. Solicited Reports

Under ICH E2D(R1), solicited reports are reports derived from organised data collection systems. For reporting purposes, solicited ICSRs are classified as reports from studies and require a causality assessment. citeturn0search39

The current GVP Module VI likewise states that safety reports originating from patient support and market research programmes should be considered solicited reports and that valid cases suspected to be related to the concerned medicinal product should be managed through the solicited-report mechanisms. citeturn0search35

5. Solicited Does Not Mean Automatically Reportable

A crucial distinction is:

Solicited source ≠ automatically valid ICSR.

The programme may collect many types of information, including events that are not suspected adverse reactions.

The organisation must assess the information obtained and determine whether it satisfies the applicable requirements for an ICSR.

6. Adverse Event Versus Adverse Reaction

A PSP may actively collect adverse events.

The pharmacovigilance assessment then asks whether the information represents a suspected adverse reaction and whether the applicable reporting criteria are met.

This distinction prevents the automatic conversion of every event captured by a PSP into a reportable ICSR.

7. Programme Design Matters

The pharmacovigilance implications should be considered when a PSP is designed or materially changed.

Relevant questions include:

• What information is collected?
• Is adverse-event information actively sought?
• Who asks the questions?
• Who records the information?
• Is there two-way communication?
• Who operates the programme?
• Is a third party involved?
• How is safety information transferred to the MAH?
• What follow-up is possible?

These questions should be addressed before the programme begins rather than retrospectively after a safety issue is identified.

8. MAH Responsibility

An MAH remains responsible for having appropriate mechanisms to manage safety information arising from its programmes, including where operational activities are performed by a third party.

The GVP framework explicitly places responsibility on the MAH for management and submission of valid reports received through solicited sources. citeturn0search35

Outsourcing data collection therefore does not remove the need for appropriate MAH oversight.

9. Third-Party PSP Operators

A PSP may be operated wholly or partly by a vendor.

The pharmacovigilance system should establish:

• contractual responsibilities;
• safety-information escalation procedures;
• transmission timelines;
• case-quality requirements;
• follow-up responsibilities;
• reconciliation;
• training;
• oversight metrics;
• and audit rights where appropriate.

The operational model should allow the MAH to demonstrate that safety information is identified and transferred without avoidable delay.

10. Initial Case Assessment

When PSP information enters the pharmacovigilance system, the organisation should assess it using the applicable ICSR criteria.

The PSP source does not replace the need to establish:

• an identifiable patient;
• an identifiable reporter or source as applicable;
• a suspected medicinal product;
• and a suspected adverse reaction.

The next chunk will cover PSP case classification, causality, follow-up, vendors, duplicates, serious cases and practical PSP scenarios.

11. A PSP Is an Organised Data-Collection System

A Patient Support Programme should not be assessed only by its name. The organisation should understand how the programme operates, what information it collects, why it collects it and how safety information enters the pharmacovigilance system.

This is particularly important under the current ICH E2D(R1) framework, which places greater emphasis on organised data-collection systems and their characteristics.

12. Solicited Does Not Mean Automatically Valid

A report originating from a PSP is a solicited source, but that does not eliminate the need to assess whether the information constitutes a valid ICSR.

The organisation should still establish the applicable minimum criteria and assess whether a suspected adverse reaction has been reported.

The following distinction is therefore important:

PSP source
   ↓
Solicited information
   ↓
ICSR validity assessment
   ↓
Valid ICSR or non-valid safety information

13. Adverse Event Versus Adverse Reaction

PSPs may collect broad information about adverse events, symptoms, treatment experiences and other outcomes.

The PV process should distinguish the information actually collected from the regulatory determination that an adverse reaction has been reported.

The organisation should not assume that every programme-collected event is necessarily a suspected adverse reaction.

14. Reporter Identification

PSPs can involve several people or organisations:

• patient;
• caregiver;
• healthcare professional;
• PSP nurse;
• call-centre employee;
• vendor personnel;
• or another programme participant.

The organisation should have a controlled approach to determining the relevant reporter and preserving the source information.

15. PSP Vendors

A PSP may be operated by a third-party service provider, but outsourcing the activity does not remove the MAH's responsibility for appropriate pharmacovigilance oversight.

The contractual and operational model should define:

• safety-information recognition;
• escalation timelines;
• case transfer;
• follow-up responsibilities;
• data quality requirements;
• reconciliation;
• training;
• audit/oversight;
• and inspection support.

16. Safety Information Escalation

The PSP should have a clear mechanism for recognising potentially reportable safety information and transferring it to the responsible PV function.

The organisation should not rely on individual programme personnel to decide informally whether information is important enough to reach PV.

17. Serious Cases

Serious cases identified through a PSP require appropriate escalation and processing under the applicable requirements.

The PSP procedure should therefore define how serious information is recognised, how rapidly it is transferred, who performs the medical assessment and how follow-up is coordinated.

18. Follow-Up

PSP information can be particularly useful for follow-up because the programme may maintain an ongoing relationship with the patient or healthcare professional.

Follow-up should be controlled and should not result in repeated unsolicited requests for information that have no reasonable clinical purpose.

The PV organisation should define what additional information is required and how the source interaction is documented.

19. Duplicate Management

The same patient and event may appear through several channels:

PSP
 ├── patient report
 ├── HCP report
 └── PSP vendor

Other PV channels
 ├── spontaneous report
 ├── literature
 └── study source

The organisation should have controls to identify and reconcile potential duplicates rather than creating multiple independent cases from different programme interactions.

20. PSP and Existing Spontaneous Cases

A PSP may obtain additional information about a patient whose case already exists in the PV database.

The information should be assessed as potential follow-up to the existing case where appropriate rather than automatically creating a new case.

This requires effective interfaces between PSP operations, vendors and the central PV system.

21. PSP and Medical Review

The need for medical review should be determined by the organisation's controlled criteria and the clinical complexity of the information.

Particular attention may be warranted for serious, medically complex, unusual or potentially signal-relevant cases.

The next chunk will cover PSP governance, reconciliation, inspection evidence, current E2D(R1) implementation considerations, practical scenarios and common failures.

22. Governance of PSP Pharmacovigilance

The pharmacovigilance arrangements for a PSP should be defined before the programme begins collecting safety information.

The governance model should identify the interfaces between the programme owner, the MAH pharmacovigilance function and any third-party provider. Responsibilities should be sufficiently clear to demonstrate who recognises safety information, who performs the ICSR assessment, who performs follow-up and who ensures regulatory submission when required.

23. Reconciliation

Where PSP safety information is transferred through a vendor or another operational system, reconciliation should provide assurance that relevant information reaches the PV system and that material discrepancies are identified and investigated.

The reconciliation approach should be proportionate to the programme and should be supported by documented procedures and evidence of execution.

24. Documentation of Organised Data Collection Systems

ICH E2D(R1) introduces additional documentation considerations for organised data collection systems that are not conducted according to a protocol. The EMA EU implementation strategy provides transitional instructions for MAHs and inspectors while GVP Module VI is being revised.

As of 24 August 2026, the revised ICH E2D(R1) guideline is in its EU transition period, which runs until 18 September 2026. The current GVP Module VI remains applicable alongside the EU implementation strategy during this period.

The article should therefore not treat the future revised GVP Module VI as already effective.

25. E2D(R1) and the New PSP Definition

The revised ICH definition describes PSPs as organised data collection systems initiated by an MAH in which patients enrol to support use of the MAH's medicinal product or management of their medical condition and which include two-way communication between the MAH, or a third party acting on its behalf, and patients or healthcare professionals.

This definition matters operationally because not every programme that an organisation previously labelled a PSP will necessarily fall within the revised definition.

MAHs should therefore assess their existing programmes against the current E2D(R1) definition rather than relying solely on historical programme names.

26. Technical Classification and EudraVigilance

E2D(R1) also introduces concepts relevant to classification of solicited reports in the ICSR data model.

EMA has indicated that new E2B(R3) values for the study-type field will support classification of reports from PSPs, market research programmes and certain organised data-collection systems. The implementation of those new values in EudraVigilance is being handled separately through the system change-management process.

Therefore, the existence of a revised E2D(R1) concept should not be interpreted as meaning that every corresponding EudraVigilance technical value is already available for use.

27. Practical Scenario: PSP Nurse Reports a Reaction

A PSP nurse reports that an enrolled patient developed a rash after starting the MAH's product.

The organisation should preserve the source information, assess whether the four minimum ICSR criteria are satisfied, determine the applicable solicited-source classification and process the case according to the applicable reporting requirements.

The nurse's role in the PSP does not remove the need to establish the relevant source and patient information.

28. Practical Scenario: PSP Records an Event but No Patient Is Identifiable

A PSP database contains an aggregated statement that several participants experienced nausea, but the information cannot be linked to an identifiable individual patient.

The organisation should not manufacture individual cases from an aggregate statement. The information may remain relevant to safety surveillance, but the ICSR validity assessment must be based on the information actually available.

29. Practical Scenario: PSP Information Is Follow-Up to an Existing Case

A patient already has an ICSR in the MAH safety database. A subsequent PSP interaction provides the outcome and additional clinical details.

The information should be evaluated as potential follow-up to the existing case and reconciled with the existing record rather than automatically creating a new case.

30. Practical Scenario: Serious Reaction Identified by a Vendor

A PSP vendor receives information suggesting a serious adverse reaction.

The vendor's procedure should provide a defined escalation route to the MAH PV function. The MAH should be able to demonstrate that the transfer, assessment and subsequent processing operate within the applicable regulatory timelines.

31. Practical Scenario: PSP Programme Changes Over Time

A programme may begin as a service focused on adherence or patient education and later expand its activities to include structured collection of safety information.

Changes in programme design can affect its regulatory classification and PV controls. The MAH should reassess the programme when material changes occur rather than assuming that its original classification remains appropriate indefinitely.

32. Inspection Perspective

For PSPs, an inspector may examine the complete chain:

Programme design
      ↓
Safety-information collection
      ↓
Vendor / operational transfer
      ↓
PV intake
      ↓
Validity assessment
      ↓
Medical assessment / follow-up
      ↓
Submission
      ↓
Reconciliation and oversight

Evidence may include contracts, procedures, training records, programme documentation, transfer logs, reconciliation records, quality-control results, case records and vendor oversight documentation.

EMA's EU implementation strategy for E2D(R1) is explicitly intended to support MAHs as well as national competent authorities and inspectors. This makes documentation of the organised data-collection system particularly important during the transition.

33. Common PSP Failures

Treating every PSP record as an ICSR

A programme record is not automatically a valid ICSR.

Treating every PSP event as a spontaneous report

The nature of the organised data-collection system matters for classification.

Relying on the vendor without MAH oversight

Outsourcing operational work does not remove the need for appropriate MAH governance and oversight.

Losing follow-up information

PSP interactions can contain important follow-up information that should reach the appropriate existing case.

Poor reconciliation

Weak interfaces can result in missing, delayed or duplicated safety information.

Failing to reassess the programme after design changes

A change in the way a programme operates can change its regulatory characteristics and therefore its PV controls.

34. Final Principles

1. A PSP is a specific type of organised data-collection system under the revised ICH E2D(R1) framework.
2. A solicited source does not automatically produce a valid ICSR.
3. The four minimum ICSR criteria remain central to case validity.
4. PSP safety information should be transferred through controlled PV interfaces.
5. Vendor activities require appropriate MAH oversight.
6. Follow-up and duplicate management are important PSP controls.
7. Programme design and classification should be reassessed when the programme changes materially.
8. During the EU E2D(R1) transition, MAHs should follow the EMA implementation strategy and current applicable GVP requirements rather than prematurely applying future GVP revisions.
9. Technical EudraVigilance implementation of new E2D(R1) classifications should be distinguished from the conceptual regulatory changes.
10. Inspection readiness requires evidence across the complete PSP-to-PV process.

Key Takeaways

The pharmacovigilance challenge presented by a PSP is not simply deciding whether a report is "solicited". The organisation must understand the programme, classify the source correctly, determine whether individual information satisfies the ICSR criteria, maintain effective interfaces with vendors and PV systems, perform appropriate follow-up and demonstrate oversight.

The 2026 EU implementation of ICH E2D(R1) makes this an active regulatory transition area. Until the revised GVP Module VI is adopted, MAHs should apply the current GVP Module VI together with the EMA E2D(R1) EU implementation strategy and other current supporting material.

References

1. European Medicines Agency. EU implementation strategy of ICH E2D(R1) Guideline — Post-approval safety data: Definitions and standards for management and reporting of individual case safety reports. EMA/11141/2026.
2. International Council for Harmonisation. ICH E2D(R1): Post-Approval Safety Data — Definitions and Standards for Management and Reporting of Individual Case Safety Reports. EU implementation effective 18 March 2026.
3. European Medicines Agency. ICH E2D post-approval safety data management — scientific guideline, including EU implementation information and supporting materials.
4. European Medicines Agency. GVP Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products, current applicable revision during the E2D(R1) transition.
5. European Medicines Agency. GVP Annex IV — ICH pharmacovigilance guidelines, as applicable.
6. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended.
7. European Medicines Agency. Pharmacovigilance inspection procedures: human, including Union procedures for preparation, conduct, reporting and follow-up of inspections.

Regulatory Note

ICH E2D(R1) entered into effect in the EU on 18 March 2026. EMA has provided a six-month transition period for MAHs, ending 18 September 2026, while GVP Module VI is being revised. EMA has indicated that the GVP Module VI revision is expected to integrate E2D(R1); therefore, this article deliberately distinguishes the current GVP text from the interim E2D(R1) implementation strategy.

The regulatory treatment of an individual PSP, its classification as an organised data-collection system, and the reporting of information arising from it should be assessed against the current applicable requirements and the actual design of the programme. This article is educational and does not replace the current legislation, GVP, E2D(R1) implementation material or organisation-specific procedures.

The practical scenarios are illustrative and are not presented as actual regulatory inspection cases unless an authoritative source is explicitly identified.