Patient Support Programmes and Adverse Events: What ICH E2D(R1) Changes for Your Reporting

Most pharmacovigilance teams know where adverse events come from in theory: healthcare professionals, patients, the literature, studies and regulators. In practice, a growing share of safety information reaches a company through channels that were never designed as safety channels at all. A nurse who phones patients to support adherence. A disease management app with a chat function. A market research survey. A social listening exercise run by the brand team. Each of these can generate a report of a suspected adverse reaction, and each of them is often run by a commercial or patient services team that has never spoken to pharmacovigilance.

The revised ICH E2D(R1) guideline, which the EU brought into effect in 2026, tackles this directly. It redefines patient support programmes, introduces the concept of organised data collection systems, and changes how some reports should be classified. The EU transition period has now ended, which means the new definitions are expected to be in use. This guide explains what changed, how to classify the programmes your company runs, and what documentation you now need. If you are searching for ICH E2D(R1) implementation, patient support programme adverse event reporting, solicited versus spontaneous reports, or organised data collection system documentation, this is written for you.

The Dates That Matter

The EMA published an EU implementation strategy for ICH E2D(R1) in February 2026 after adoption by the Pharmacovigilance Risk Assessment Committee. Its key dates are:

  • The revised guideline was adopted by the ICH Management Committee and the CHMP in September 2025
  • It came into effect in the EU on 18 March 2026
  • A further six month transition period was allowed, up to 18 September 2026
  • After that date the definitions and guidance in the ICH guideline apply
  • The revision of GVP Module VI has been included in the PRAC work plan for 2026, in order to integrate the new text. Until then, the implementation strategy document tells marketing authorisation holders how to apply it

If your processes were not updated by 18 September, now is the time to close the gap.

What the Revision Is Trying to Fix

The purpose of the revision, as the EMA explains, is to clarify how safety data from solicited sources should be managed. Those sources include social media, market research programmes and patient support programmes, which differ in how they are designed and in how much they contribute to the quality of post-approval safety information. Before the revision, EU guidance treated all adverse reactions from patient support programmes as solicited, whatever the programme looked like. That blunt rule swept in activities that had little to do with collecting medical information.

The New Definition of a Patient Support Programme

Under ICH E2D(R1), a patient support programme is an organised data collection system started by a marketing authorisation holder, in which patients enrol to support their use of the product or the management of their condition, and which includes a mechanism for two-way communication between the company, or a third party acting for it, and patients or healthcare professionals. Examples include adherence support, disease management, and certain reimbursement and educational programmes.

A programme meets the definition if either of two conditions is true:

  • It solicits medical information about the patient’s use of the medicine
  • Its design means the company, or a third party acting for it, would foreseeably receive medical information about the patient’s use of the medicine, for example when a healthcare professional interacts with a patient to administer medication or give medical advice

Two features of this wording deserve attention. The second condition is about foreseeability, so a programme can be a patient support programme even if nobody intends to collect safety information. And the definition covers third parties acting on your behalf, which brings in hubs, call centres and nurse providers.

What Is Not a Patient Support Programme

The guideline excludes certain activities, and this is where the practical change lies. Programmes started by the company that do not meet the criteria are not patient support programmes as long as the company does not request medical information about the patient’s use of the product. The examples given are delivery of a product to a patient’s home and provision of vouchers or coupons. The definition also excludes clinical trials, non-interventional studies with scientific intent such as post-authorisation safety studies, all forms of compassionate use, and named patient supply.

Reports arising from one-way activities, which are not part of an organised data collection system or a combined multi-activity programme, should be managed as spontaneous reports rather than solicited reports. That has real consequences for how reports are classified, assessed and submitted.

A Classification Guide for Common Programmes

The table below turns the definitions into a practical guide. It is a starting point for your own assessment, not a substitute for it, because the design of each programme matters.

  • Adherence support with nurse or pharmacist calls to enrolled patients: two-way, medical information foreseeably received. Treat as a patient support programme, with reports managed as solicited
  • Disease management app with a chat or helpline function: two-way, medical information likely to be shared. Treat as a patient support programme
  • Educational or reimbursement programme where a healthcare professional interacts with the patient about treatment: likely a patient support programme if medical information is solicited or foreseeably received
  • Home delivery of medicine with no request for medical information: not a patient support programme. Reports are spontaneous
  • Vouchers or coupons: not a patient support programme. Reports are spontaneous
  • Combined programme that includes delivery plus a nurse helpline: assess as a multi-activity programme, since the two-way element brings the programme within the definition
  • Market research programme: an organised data collection system, subject to the documentation requirements below
  • Social listening or digital listening, where the company monitors and analyses user posts: an organised data collection system
  • Post-authorisation safety study, clinical trial, compassionate use or named patient supply: excluded from the patient support programme definition and managed under their own rules

If a programme sits between categories, document the reasoning. An inspector will want to see why you classified it as you did.

Organised Data Collection Systems and the New Documentation

The second major change is the introduction of organised data collection systems. The guideline defines these as activities that gather data relevant to the product or disease area in a planned manner, enabling review. They include clinical trials, non-interventional studies, patient support programmes and market research programmes. The EMA’s examples go further: a company using a patient forum on a digital platform to assess perceptions of safety, a sentiment analysis of social media posts about the product, and social listening are all organised data collection systems. Routine spontaneous reporting operations are excluded.

For activities of this kind that are not run to a protocol, the company must have documentation in place. Under the EU strategy, each new activity not conducted according to a protocol needed documentation describing at least:

  • The objectives of the activity
  • The sources of the data
  • The dataset that will be collected or received and reviewed, including the look-back period or duration
  • The method for reviewing the dataset
  • The process for collecting and managing any adverse events or reactions identified

For ongoing activities, the minimum was narrower: objectives, data sources, and the process for collection and management of adverse events. In both cases, the documentation is to be maintained with oversight by the QPPV and made available to national competent authorities and the Agency on request. Note that the strategy applies to activities conducted within or outside the EU, in line with the marketing authorisation holder’s responsibilities.

What Changes for Existing Programmes

The EU strategy takes a practical approach to programmes already running before 18 September 2026. The new definition may be adopted voluntarily for those. If a company wants to reclassify reports from one-way activities, such as delivery services or voucher schemes, from solicited to spontaneous, it can do so provided the change is clearly documented in the new organised data collection system documentation. Once the change is made, all new and follow-up reports from that programme are managed as spontaneous.

This option gives companies a chance to simplify, but it needs care. Reclassifying without documentation, or without telling the people who handle cases, creates inconsistency in the safety database.

The Data Standard Detail

There is also a technical point for safety database teams. A new value for the study type element in the electronic reporting format, identifying a patient support programme, has been introduced, along with values for market research programmes and for organised data collection with source data from a digital platform. The EU strategy says this is independent of the ICH E2D(R1) implementation, and that the new values will be introduced in EudraVigilance later through its change management process. In the meantime, reports from patient support programmes continue to use the existing value for other studies. For adverse reactions from one-way activities, the report type element should be populated as a spontaneous report. Your safety database configuration and your case processing conventions should reflect this.

Where Companies Go Wrong

  • Programmes are launched by commercial or patient services teams without any involvement from pharmacovigilance
  • Third party hubs and call centres are not covered by pharmacovigilance agreements, or contracts say nothing about forwarding safety information within a day
  • The foreseeability test is ignored, with teams arguing that because the programme was not designed to collect safety data it cannot be a patient support programme
  • All programmes are classified identically, or on the basis of their name rather than their design
  • Social listening and market research are run without any documentation or QPPV oversight
  • Staff handling solicited reports are not trained to perform the causality assessment that solicited reports require
  • Safety database settings are not updated to match the new classification

A Practical Implementation Plan

  • Build an inventory of every programme and activity that touches patients, healthcare professionals or online data, including those run by affiliates, distributors and agencies
  • For each, apply the definitions, record the classification and the reasoning, and have the QPPV or delegate approve it
  • Prepare the organised data collection system documentation for each relevant activity, with the QPPV overseeing it
  • Review every contract with hubs, agencies and vendors so that safety information is forwarded promptly and training is in place
  • Update SOPs, work instructions and database configuration so that solicited and spontaneous reports are handled as intended
  • Train both pharmacovigilance staff and the commercial teams who run the programmes
  • Set up a simple approval step so that no new programme launches without a pharmacovigilance review
  • Check how other regulators in your markets apply the new guideline, because local implementation can differ

What an Inspector Is Likely to Ask

Expect questions such as: how do you know about every programme your company or its agents run, how do you decide whether it is a patient support programme, where is the documentation for your market research and social listening activities, how do agents send you safety information, and how do you know none have been missed? If the answer to the last question is that you rely on the commercial team telling you, expect a finding.

Bringing Your Programmes and Procedures Into Line

The difficulty with this change is rarely the guideline itself. It is finding every programme, getting commercial teams to engage, and updating procedures and contracts across several vendors. Quality and Vigilance Ltd supports marketing authorisation holders with exactly this kind of cross-functional work, as part of its pharmacovigilance consulting and audit and inspection support. A fresh, independent look usually finds programmes that the pharmacovigilance team never knew existed. The support typically includes:

  • Discovery of patient support, market research and digital listening activities across affiliates, agencies and vendors
  • Classification of each programme against the ICH E2D(R1) definitions, with documented reasoning
  • Drafting of organised data collection system documentation for QPPV oversight
  • Review and update of pharmacovigilance agreements, SOPs, safety database conventions and training
  • Mock inspection questions and evidence preparation on the handling of solicited and spontaneous reports

Get in touch with Quality and Vigilance Ltd today to bring your patient programmes and pharmacovigilance procedures into line with ICH E2D(R1).

Newsletter Signup

Subscribe to our newsletter for the latest insights