ICH E2D(R1): What Changed in Post-Approval Pharmacovigilance

ICH E2D(R1) is the first major revision of the ICH guideline on post-approval safety data since the original E2D was adopted in 2003. The revision does more than update terminology. It reorganises the logic used to classify post-approval safety information, brings modern sources such as social media, apps, patient support programmes and structured digital listening into the framework, distinguishes different forms of non-interventional data collection, and gives more explicit guidance on when information becomes an ICSR, when the reporting clock starts and how solicited cases should be handled.

For EU pharmacovigilance professionals, the practical importance is immediate. EMA brought ICH E2D(R1) into effect in the EU on 18 March 2026 and allowed a six-month transition period up to 18 September 2026 for implementation of the revised definitions and guidance. That transition has now ended. At the same time, the published GVP Module VI remains Revision 2 from 2017. EMA therefore instructs users to apply the new ICH E2D(R1) guidance and definitions where they affect GVP, together with the EU implementation strategy and the current GVP requirements that remain applicable.

Purpose and Scope

ICH E2D(R1) addresses the management and reporting of post-approval individual case safety information. It is not a complete pharmacovigilance system standard and it does not replace regional law. Its role is to harmonise definitions, case-management principles and reporting concepts to the extent possible across ICH regions, while recognising that regional authorities may impose different reporting requirements.

The guideline therefore sits between several related frameworks:

• ICH E2A provides core concepts for clinical safety data management, particularly in the pre-approval setting;
• ICH E2B(R3) defines the electronic ICSR data structure and transmission specifications;
• ICH E2C(R2) addresses periodic benefit-risk evaluation and aggregate safety reporting;
• ICH E19 is relevant to selective safety data collection in certain studies;
• ICH M14 is relevant to pharmacoepidemiological studies using real-world data;
• and, in the EU, GVP Module VI and applicable EU legislation determine the regional requirements for collection, management and submission of suspected adverse reactions.

This division matters operationally. E2D(R1) can tell an MAH how a report should be conceptualised as spontaneous or solicited and how a digital source should be classified, while the EU framework determines which cases must actually be submitted, to whom and under which regional rules.

The correct sequence is therefore:

ICH harmonised concept
        ↓
Regional / local requirement
        ↓
Company procedure
        ↓
Operational case decision
        ↓
Evidence and audit trail

A company procedure should not collapse these layers into one another. A recommendation in ICH guidance should not be described as though it were a statutory obligation unless the regional framework makes it one.

Why the 2003 Guideline Needed Revision

The original E2D was written before many current safety-information channels became routine. A framework centred on spontaneous reports, literature and relatively conventional post-marketing sources had to be applied to activities that later became common but were not well described in the original text.

Examples include:

• company websites and mobile applications;
• social media and public online communities;
• social-listening activities;
• patient support programmes;
• market research programmes;
• structured digital data collection;
• real-world-data studies using primary data collection;
• studies using secondary healthcare data;
• and increasingly complex vendor-operated programmes.

The difficulty was not simply technological. The same digital platform can produce very different regulatory situations depending on why the MAH is accessing it and how the information is generated.

A patient who voluntarily posts an adverse reaction on an MAH-controlled product website is not in the same situation as an MAH that deliberately performs a structured social-listening exercise across public posts. Both involve digital information, but the first may be a spontaneous report while the second can constitute an organised data collection system.

E2D(R1) therefore moves away from classifying information mainly by the superficial channel through which it arrived. It focuses instead on the design of the activity, responsibility for the source, whether collection is organised, and whether the information meets ICSR criteria.

The EU Regulatory Position in 2026

The regulatory status needs to be understood precisely.

ICH adopted the final E2D(R1) guideline at Step 4 on 15 September 2025. EMA subsequently implemented the Step 5 guideline in the EU with an effective date of 18 March 2026. EMA's implementation strategy allowed an additional transition period until 18 September 2026 so that MAHs could update processes, particularly for the revised patient support programme definition and for documentation of organised data collection systems that are not conducted according to a protocol.

EMA has also stated that GVP modules affected by ICH E2D(R1) will be revised. Until that revision is completed, EMA's current position is that the E2D(R1) guidance and definitions should be applied insofar as they affect GVP, together with the EU implementation strategy and the existing GVP requirements that remain applicable.

This creates a transitional-document environment even though the operational transition date has passed:

The last point is important. Process classification and electronic coding are related but not identical. An organisation should not postpone correct E2D(R1) source classification merely because a new E2B(R3) value has not yet been implemented in a regional transmission system.

The Main Conceptual Change

The most useful way to understand E2D(R1) is to separate four questions that were often blurred together in older operational models:

1. What activity generated the information?
2. What source did the information come from?
3. Is the resulting report spontaneous or solicited?
4. Does the information meet the regional criteria for ICSR reporting?

The classification sequence can be represented as:

Activity design
     ↓
Source and responsibility
     ↓
ODCS or non-ODCS?
     ↓
Solicited or spontaneous?
     ↓
Minimum ICSR criteria met?
     ↓
Regional reporting requirement?
     ↓
E2B coding and submission

This is more robust than rules such as “all digital reports are spontaneous” or “anything received through a programme is solicited”. Those shortcuts fail because E2D(R1) explicitly recognises that one channel can support several different activity types.

What Changed: A High-Level Map

ICH's own Step 4 presentation identifies extensive updates across the guideline. The most consequential changes for operational pharmacovigilance are summarised below.

The remainder of this article develops these changes in the sequence in which they affect an operational pharmacovigilance system: first source classification, then case assessment and reporting, then implementation and governance.

Source Architecture: From Channel Labels to Activity Design

E2D(R1) formalises a source architecture that is more useful than classifying reports by the name of the department, programme or technology through which they arrive. The underlying question is whether the MAH is receiving an unsolicited report or is operating, sponsoring or deliberately conducting an organised activity that collects data in a planned manner.

This distinction is central because solicited reports are defined as reports derived from organised data collection systems. For ICSR reporting they are classified as “report from study” in the ICH E2B framework and require a causality assessment. By contrast, spontaneous reports arise outside an ODCS and, for reporting purposes, carry an implied suspicion of causal association.

Organised Data Collection Systems

E2D(R1) defines an organised data collection system (ODCS) as an activity that gathers data relevant to an MAH's medicinal product or a medical disease area in a planned manner, thereby enabling review to be performed.

That definition is deliberately broader than “study”. It can include:

• clinical trials;
• non-interventional studies;
• registries;
• patient support programmes;
• market research programmes;
• structured digital listening;
• sentiment-analysis activities;
• and other planned reviews of digital-platform data.

The practical implication is that an MAH should assess the activity, not merely the system in which data are stored. A public social-media platform is not itself an ODCS. A planned MAH activity that systematically gathers and reviews information from that platform may be.

For ODCS activities not conducted according to a protocol, E2D(R1) expects documentation describing at least the objective, data source, dataset to be collected or reviewed, review method and process for managing AEs/ADRs or other observations. The EU implementation strategy converts this into a concrete implementation expectation for MAHs and places the documentation under QPPV oversight.

QPPV.com addresses the operational detail separately in GVP Module VI: Other Organised Data Collection Systems and Solicited Sources.

Patient Support Programmes

The revised definition of a patient support programme (PSP) is one of the most operationally important changes.

Under E2D(R1), a PSP is an MAH-initiated ODCS in which patients enrol to support use of the MAH's medicinal product or management of their medical condition, and which includes a mechanism for two-way communication between the MAH, or a third party acting on its behalf, and patients or healthcare professionals.

A programme meets the PSP definition when it solicits medical information about medicine use or is designed so that receipt of such medical information is reasonably foreseeable. Examples include adherence support, disease-management activities and some reimbursement or educational programmes.

This definition excludes some one-way service arrangements that historically may have been treated as PSPs. A stand-alone home-delivery service or voucher programme does not become a PSP merely because it is sponsored by an MAH, provided it does not request medical information and is not part of a broader combined programme that meets the PSP criteria.

That distinction changes case classification:

• an ADR from a qualifying PSP is managed as solicited and requires appropriate causality assessment;
• an ADR from a one-way MAH activity that is not an ODCS and not part of a combined PSP is managed as spontaneous.

A combined programme requires assessment as a whole. If a delivery service is integrated with a nurse-support activity that meets the PSP criteria, E2D(R1) treats the combined programme as a PSP and the safety information arising from the programme accordingly.

The detailed operational implications are covered in GVP Module VI: Patient Support Programmes and Solicited Reports.

Market Research Programmes

E2D(R1) also provides an explicit definition for market research programmes (MRPs). These are ODCSs used for planned collection of healthcare-professional or consumer insights by or on behalf of an MAH for marketing or business-development purposes.

The commercial purpose of the programme does not remove its pharmacovigilance implications. If an MRP generates AEs/ADRs that meet applicable reporting requirements, the cases are managed as solicited reports and should receive an appropriate causality assessment.

This creates an important governance interface. Market-research teams and vendors need procedures that identify safety information without converting ordinary market-research data into uncontrolled case-processing activity. The safety pathway should be designed before the research begins rather than reconstructed after an adverse event is encountered.

Digital Platforms

E2D(R1) replaces the older concept of “internet” reporting with a broader definition of digital platform. This includes social media, websites, internet forums, chat rooms, mobile health technologies and software applications.

The decisive distinction is whether the digital platform is under the responsibility of the MAH.

Platforms Under MAH Responsibility

A platform is under MAH responsibility when it is owned, controlled or operated by, or on behalf of, the MAH. E2D(R1) states that such platforms should be regularly screened for AEs/ADRs at a frequency that allows applicable reporting timelines to be met.

The presence of a report on an MAH-controlled platform does not by itself determine whether it is spontaneous or solicited.

For example:

• a patient independently posts an adverse reaction on an MAH product website → potentially spontaneous;
• an MAH uses the same platform to run a structured programme that deliberately gathers safety information → potentially solicited because it arises from an ODCS.

The technology is the same. The activity design is different.

E2D(R1) also gives a specific time-clock rule: for MAH-responsible digital platforms, Day Zero begins when sufficient information to establish the minimum ICSR criteria has been posted on the platform, subject to regional requirements. This means screening frequency must be designed around regulatory timeliness rather than convenience.

Platforms Not Under MAH Responsibility

E2D(R1) states that MAHs are not expected to screen or review external digital platforms generally for AEs/ADRs.

That does not mean information found externally is irrelevant. Two situations should be distinguished.

First, an MAH may deliberately access an external digital platform as part of a planned review, such as social listening or sentiment analysis. If that activity is organised data collection, it should be treated as an ODCS and documented accordingly. The MAH is expected to review the defined dataset specified by the activity, not to expand the search indefinitely beyond that scope.

Second, an MAH employee may encounter an AE/ADR on an external platform outside any ODCS—for example while researching a separate business question. If the information meets applicable regional reporting requirements, E2D(R1) treats the resulting case as spontaneous.

This distinction is one of the clearest examples of the revised logic:

Same external platform
        ↓
Planned structured review? ── Yes ──> ODCS → solicited framework
        │
        No
        ↓
Incidental awareness of report → spontaneous framework

A dedicated QPPV.com article on adverse events from social media, apps and digital platforms can build on this framework without repeating the broader E2D(R1) architecture.

Non-Interventional Studies

E2D(R1) introduces a much clearer distinction between primary data collection and secondary use of data in non-interventional studies.

Primary Data Collection

Primary data are collected specifically for the current study, directly from participants, caregivers, healthcare professionals or others involved in care. Examples include case-report forms, laboratory measurements, electronic patient-reported outcomes and mobile-health technologies.

For MAH-conducted non-interventional studies with primary data collection, E2D(R1) expects review of the information received for AEs/ADRs or other observations, subject to regional requirements and any justified selective approach permitted under ICH E19.

AEs/ADRs collected through primary data collection are handled as solicited reports, with causality assessment relevant to reporting.

Secondary Use of Data

Secondary use means analysing data that already exist and were originally collected for another purpose. Examples include claims databases, electronic medical records, administrative datasets, disease registries and mortality databases.

E2D(R1) states that AEs/ADRs identified through secondary use of data should not be reported as ICSRs unless regional or local requirements specify otherwise.

This is a fundamental distinction because it prevents automated conversion of every coded outcome in a real-world-data study into an individual case. Population-level evidence and ICSR evidence are different safety outputs.

The distinction also creates a natural connection with ICH M14. E2D(R1) governs the case-reporting implications of the data source, while M14 addresses the design and analysis of pharmacoepidemiological studies using real-world data.

Literature, Regulatory Authorities and Other Sources

The revision retains literature as a major ICSR source but gives more explicit guidance on how to handle it.

Literature

E2D(R1) clarifies that literature can contain:

• spontaneous observations;
• cases arising from an organised study;
• population-level findings that do not qualify as ICSRs;
• duplicate information;
• or follow-up information for an existing case.

A literature case based on spontaneous clinical observation is classified as a spontaneous report. A literature case arising from a study is classified as a report from study.

The revised guideline also provides more explicit direction on product attribution when the exact brand is not identified, on duplicate detection, on the role of the first or corresponding author as primary source and on Day Zero for literature cases.

The operational lesson is that literature screening is not simply “article found → case created”. The publication must first be understood as a source of evidence and then decomposed into the appropriate safety outputs.

Regulatory Authority Sources

E2D(R1) adds clearer guidance for cases obtained from regulatory authorities and from publicly available national or regional AE/ADR databases. The MAH should preserve the authority case identifier where available and avoid unnecessary resubmission to the same authority unless new information or regional requirements justify it.

Other Non-Medical Sources

Information from lay press, other media and litigation can also generate reportable safety information. Where such information meets regional ICSR requirements, E2D(R1) generally places it in the spontaneous-report framework.

The broad principle across all these sources is consistent: the origin of the information, the way it was obtained and the regional reporting rule must be evaluated separately.

What Counts as an ICSR Under E2D(R1)

E2D(R1) introduces an explicit definition of an individual case safety report (ICSR) and brings the minimum criteria into the main post-approval guideline.

An ICSR is a description of an AE/ADR or other observation in an individual patient at a specific point in time. For regulatory submission, the guideline identifies minimum information that includes:

• at least one AE/ADR or, where applicable, another reportable observation;
• at least one suspect or interacting medicinal product;
• an identifiable patient;
• and an identifiable reporter.

The regional framework still determines which ICSRs actually have to be submitted. The minimum criteria therefore establish whether the information can constitute an ICSR; they do not by themselves determine the regional submission obligation.

This distinction is particularly important for cases that arrive incomplete. A report that is missing a minimum criterion does not yet qualify for ICSR reporting under the E2D(R1) framework, but due diligence should be exercised to obtain the missing information. The original information and the chronology of subsequent follow-up should remain traceable.

E2D(R1) also recognises special situations in which regional requirements may modify the ordinary pattern—for example, some medication-error near misses may be reportable without an identifiable patient. Such exceptions should be controlled by the applicable regional rule rather than generalised into the standard validity process.

Spontaneous and Solicited Reports

The revision makes the relationship between report type and causality more explicit.

Spontaneous Reports

For regulatory reporting purposes, a spontaneous AE report implies suspicion of a causal relationship. The reporter does not need to state formally that the medicinal product caused the event. This preserves the established pharmacovigilance principle that spontaneous reporting represents suspected adverse reactions rather than proven causation.

Stimulated reports remain spontaneous. Public safety communications, media attention or litigation can increase the number of reports received, but stimulation does not convert the reports into solicited cases unless they are gathered as part of an ODCS.

Solicited Reports

Solicited reports are derived from ODCSs and are classified as report from study in the ICH E2B framework.

A crucial operational difference is that solicited reports require a causality assessment. E2D(R1) states that solicited reports should be submitted when a causal relationship between the medicinal product and adverse event is at least a reasonable possibility, as assessed by either the reporter or the MAH, subject to the applicable regional requirements.

This prevents a common error: treating every event recorded in a structured programme as a reportable adverse reaction merely because it was collected systematically.

ODCS record
   ↓
AE identified
   ↓
Valid individual information?
   ↓
Causality assessment
   ↓
Regional reporting criteria met?
   ↓
ICSR submission as applicable

What Should Be Reported

E2D(R1) deliberately avoids pretending that one international rule can replace regional reporting requirements. It describes the harmonised framework, then repeatedly directs MAHs to the regional or local requirements for the final submission decision.

For AEs/ADRs, the guideline states that serious and unexpected cases are subject to expedited reporting, while treatment of serious expected and non-serious cases can vary by region.

It also introduces two important concepts that extend beyond conventional adverse-reaction case processing: important safety findings and other observations.

Important Safety Findings

Some safety evidence matters urgently even though it does not qualify as an ICSR.

E2D(R1) introduces a specific section for important safety findings: findings that may change the known benefit-risk balance or affect public health but do not themselves constitute individual cases. Examples can include significant findings from epidemiological, clinical, animal or in-vitro evidence.

The guideline states that such findings should be communicated to regulatory authorities as soon as possible in accordance with regional or local requirements.

This is conceptually important because it prevents the ICSR database from becoming the only route by which an organisation recognises urgent safety information.

A mature PV system therefore needs at least two connected pathways:

Individual patient information ──> ICSR pathway
              │
              └──────────────┐
                             ↓
Population / experimental safety finding
                             ↓
Signal / emerging issue / regulatory escalation pathway

The exact EU route depends on the nature of the issue and the applicable GVP framework. E2D(R1) does not replace EU emerging-safety-issue requirements.

Other Observations

E2D(R1) defines other observations to include occurrences associated with medicinal-product use that may exist with or without an AE/ADR. The guideline specifically addresses:

• lack of efficacy or lack of effect;
• overdose;
• abuse;
• misuse;
• medication error;
• occupational exposure;
• exposure associated with pregnancy or breastfeeding;
• and off-label use.

The important change is not that these situations were unknown before 2025. The change is that E2D(R1) brings them into a clearer common conceptual structure.

Where an observation occurs without an AE/ADR, ICSR reporting depends on regional or local requirements or specific regulatory conditions. Where an associated AE/ADR exists, the ordinary ICSR reporting framework applies.

This helps separate two questions that are often confused:

1. Should the information be recorded and followed up for pharmacovigilance purposes?
2. Must it be submitted as an ICSR?

The answer to the first may be yes while the answer to the second depends on the regional rule.

Unexpectedness and Listedness

E2D(R1) retains an important terminology distinction that is operationally useful.

For ICSR reporting, the relevant concept is expectedness against the regional or local product labelling. The guideline notes that the term unlisted is not the ICSR-reporting term; listedness relates instead to the Company Core Safety Information and aggregate reporting concepts under ICH E2C.

This means an organisation should not casually use “listed” and “expected” as synonyms across all safety processes.

The detailed relationship between local labels, the Company Core Data Sheet, Company Core Safety Information and reference safety information is sufficiently important to warrant separate treatment. The key E2D(R1) point is that regional ICSR expectedness and global listedness are different regulatory constructs.

Day Zero and Reporting Timeframes

E2D(R1) makes Day Zero more explicit and gives source-specific examples.

The general rule is that the regulatory reporting clock begins when any personnel of the MAH, including service providers or contractual partners acting on its behalf, obtain sufficient information to determine that the minimum criteria for reporting are met, unless regional or local requirements specify otherwise.

For an expedited ICSR, E2D(R1) uses the standard of submission as soon as possible and no later than 15 calendar days after Day Zero, while recognising that regional rules determine which cases are expedited and which other timelines apply.

The following distinctions are operationally important:

These rules show why “date entered into the safety database” is an inadequate definition of Day Zero. The clock is linked to regulatory awareness, not to the convenience of internal processing.

They also show why contracts and training matter. If a vendor receives a valid report on Monday but the safety department first sees it on Thursday, the organisation cannot automatically treat Thursday as Day Zero merely because that is when the central PV team became aware.

A dedicated article on Day Zero should explore partner, vendor, literature, reconciliation and digital scenarios in more depth.

Good Case Management Practices

The revision significantly develops the section on case quality. The aim is not only submission compliance but preservation of an authentic, medically interpretable and non-duplicative safety record.

Patient and Reporter Identifiability

E2D(R1) explains identifiability in terms of evidence that a real patient and reporter exist.

For a patient, information such as age, age category, sex, initials, date of birth, name or patient identifier can contribute to identifiability. For a reporter, details such as name, initials, contact information, qualification or organisational affiliation may establish that a real source exists.

The digital setting introduces a specific challenge. A social-media username or handle alone is not necessarily sufficient to establish that a real patient or reporter exists. Where permissible and feasible, follow-up can be used to obtain qualifying information.

This prevents two opposite errors:

• rejecting genuine digital cases merely because conventional identifiers are absent;
• or treating every online account name as proof of an identifiable person.

Narratives

E2D(R1) strengthens the role of the narrative as a stand-alone medical story.

The narrative should summarise relevant patient characteristics, treatment details, medical history, concurrent conditions, clinical course, outcomes, investigations and information relevant to causality. The presentation should follow the chronology of the patient's experience rather than merely reproducing the sequence in which fragments were received.

The primary-source description should remain distinguishable from MAH interpretation. Inferences and imputations should be avoided in the transmitted report, although clearly identified MAH evaluations may be appropriate or required in relevant E2B fields.

This provides a strong regulatory basis for treating narrative quality as a medical and data-integrity issue rather than a writing-style preference.

Clinical Evaluation and Follow-Up

Clinical review should consider seriousness, diagnostic support, alternative causes, temporal relationship, outcome and what additional information is needed.

Follow-up should be purposeful. E2D(R1) recommends prioritisation, with serious unexpected cases receiving the highest priority, while also recognising other high-value cases such as events under enhanced monitoring.

All follow-up attempts should be documented. This matters because an inspector should be able to distinguish:

• information that was unavailable;
• information that was not sought;
• and information that was sought but could not be obtained.

Duplicate Management

Duplicate management is now a dedicated element of the E2D(R1) good-case-management framework.

The need extends across sources. The same patient and event may be reported by a consumer, healthcare professional, partner, literature publication, regulatory authority or organised programme.

The objective is not merely to delete duplicates. It is to identify related reports, consolidate information appropriately and preserve enough source traceability to reconstruct how the case evolved.

Contractual Agreements

E2D(R1) continues to recognise the importance of agreements where third parties perform activities that can generate safety information.

The practical implication is broader in the revised source environment. Contracts may need to govern:

• digital-platform operations;
• PSPs and MRPs;
• study data collection;
• literature screening;
• contact centres;
• technology vendors;
• and other service providers that can become the first point of MAH awareness.

A contract that says only “report adverse events promptly” is often too abstract to control complex source classification. Effective agreements should align the operational source, transfer process, responsibilities and applicable timelines with the MAH's PV system.

E2B(R3) Alignment: Classification and Transmission Are Not the Same Thing

E2D(R1) changes the conceptual classification of solicited reports, but an ICSR still has to be transmitted through the technical structure defined by ICH E2B(R3).

The revised alignment is built around two data elements:

• C.1.3 — Type of Report
• C.5.4 — Study Type Where Reaction(s) / Event(s) Were Observed

ICH has clarified that C.1.3 value “2 = Report from study” is used not only for formal studies but also for other solicited sources described in E2D(R1).

ICH has also added source-specific values to C.5.4:

• 4 = Patient Support Program
• 5 = Market Research Program
• 6 = Organised Data Collection System with source data from a digital platform

The purpose is not merely technical. More specific source coding allows regulators and MAHs to stratify case data by source during signal detection and analysis.

The C.5.4 hierarchy also matters. If an ICSR arose from a PSP conducted on a digital platform, the PSP value is used rather than the generic digital-platform ODCS value. The digital-platform value is intended for situations in which none of the more specific study/source types applies.

Prospective Transition

ICH's E2B(R3) information paper states that the new C.5.4 values should be used prospectively once implemented in the relevant region.

Previously submitted ICSRs do not need to be resubmitted merely to replace the older value. However, when a follow-up or amendment is submitted after regional implementation, the new value should be used as appropriate.

This is a useful example of a broader data-governance principle:

Historical submitted record
        ↓
Do not rewrite merely for new taxonomy

New / follow-up transmission
        ↓
Apply current regional coding rules

EU EudraVigilance Position

The EU implementation strategy explicitly separates implementation of E2D(R1) from implementation of the new E2B(R3) C.5.4 values in EudraVigilance.

As of this article's review date, 1 October 2026, EMA continues to state that EU implementation of the new C.5.4 values will be addressed separately through EudraVigilance change management.

For PSP cases, the EU implementation strategy therefore instructs MAHs to continue using the existing C.5.4 value “3 = Other studies” until the new PSP value is implemented in EudraVigilance. One-way non-ODCS service activities that are managed as spontaneous reports instead use the spontaneous report type in C.1.3.

The operational lesson is important: classification logic should follow E2D(R1), while transmission coding must follow the technical values currently accepted by the regional system.

A safety database should therefore distinguish the company's internal source classification from the outbound regional mapping. Otherwise, a temporary regional coding limitation can corrupt the underlying safety taxonomy.

EU Implementation After the 2026 Transition

The EU implementation strategy focuses particularly on two areas: the revised PSP definition and ODCS documentation.

New PSPs

For new programmes, EMA's implementation strategy states that MAHs should have implemented the revised PSP definition no later than 18 September 2026.

From that point, the programme design should determine whether the activity is:

• a qualifying PSP producing solicited reports;
• a one-way service activity outside an ODCS producing spontaneous reports where applicable;
• or part of another organised framework that needs separate classification.

This assessment should occur before launch, not after cases begin to arrive.

Ongoing PSPs Started Before 18 September 2026

EMA gives a specific transition approach for programmes that were already operating before 18 September 2026.

For those ongoing programmes, implementation of the new PSP definition may be performed voluntarily. Where an MAH changes a previously solicited one-way service activity to the spontaneous framework, the change should be clearly documented in the ODCS documentation. Once the switch is made, new and follow-up ADRs from the affected programme should be handled consistently under the new classification.

This is a grandfathering nuance that should not be lost in a simplified statement such as “all old PSPs had to be reclassified on 18 September”. The correct control is to understand when the programme began, how it was historically classified, whether the MAH has implemented the revised definition and what documentation supports the decision.

ODCS Documentation

The ODCS requirement is more direct.

For each new MAH ODCS activity not conducted according to a protocol, the EU implementation strategy states that the E2D(R1) documentation should have been in place no later than 18 September 2026 and should describe at least:

1. the objective of the activity;
2. the source or sources of data;
3. the dataset to be collected or reviewed, including the look-back period and/or duration;
4. the review method;
5. the process for collecting and managing AEs/ADRs or other observations.

For ongoing MAH ODCS activities not conducted according to a protocol, the EU implementation strategy likewise states that documentation should have been in place no later than 18 September 2026 and should describe at least:

1. the objectives;
2. the data sources;
3. the process for collecting and managing AEs/ADRs or other observations.

EMA states that this documentation should be maintained with QPPV oversight and made available to national competent authorities and EMA upon request.

This is more than a paperwork exercise. The document is the evidence that the MAH has consciously defined:

Why the activity exists
        ↓
What data will be examined
        ↓
How the review will be performed
        ↓
Where safety information enters PV
        ↓
Who can reconstruct the decision later

What an MAH Should Have Changed Operationally

E2D(R1) affects several parts of the pharmacovigilance system simultaneously. Treating it as a case-processing SOP update alone is unlikely to be sufficient.

Source Inventory

The organisation should maintain an inventory of activities capable of generating post-approval safety information, including:

• MAH-controlled websites and apps;
• social-media accounts;
• social-listening activities;
• PSPs;
• MRPs;
• registries;
• non-interventional studies;
• medical-information channels;
• call centres;
• product-support services;
• literature vendors;
• partners;
• and external data platforms accessed in a planned manner.

For each activity, the inventory should identify the owner, data source, whether it is an ODCS, report type, transfer route, applicable agreement and reconciliation mechanism.

Programme Design Review

PV review should occur when an activity is designed or materially changed.

The review should ask:

• Is medical information actively solicited?
• Is receipt of medical information foreseeable?
• Is there two-way communication?
• Is the activity conducted in a planned manner?
• Is a protocol required?
• If no protocol exists, is ODCS documentation required?
• Can AEs/ADRs or other observations arise?
• Who receives them first?
• What is the applicable Day Zero logic?
• Is causality assessment required because reports are solicited?
• How will duplicates and follow-up be managed?

This prevents PV classification from being inferred retrospectively from the commercial name of the programme.

SOP and Work-Instruction Alignment

Procedures should use the revised terminology consistently.

High-risk areas for inconsistency include:

• spontaneous versus solicited classification;
• definitions of PSP and MRP;
• external versus MAH-responsible digital platforms;
• Day Zero;
• primary versus secondary non-interventional data;
• management of other observations;
• source-specific causality assessment;
• and E2B source mapping.

A procedure can be internally consistent yet still fail if dependent functions use a different definition. Training and controlled terminology therefore matter across PV, medical information, market research, patient services, digital teams, clinical/epidemiology groups and vendors.

Safety Database Configuration

The database does not necessarily need a complete redesign, but the data model should be capable of preserving:

• source;
• report type;
• ODCS status;
• programme type;
• regional E2B mapping;
• causality assessment;
• Day Zero;
• and links to the originating activity.

If a single overloaded field is used for all these concepts, later signal analysis and inspection reconstruction become difficult.

Reconciliation

The broader source environment increases the importance of reconciliation.

For example, a PSP vendor may send a case file to PV while a related product complaint or medical-information enquiry enters through another system. The organisation should be able to determine whether the records represent one case, multiple cases or follow-up information.

Reconciliation is therefore not merely a monthly count comparison. It is a control over completeness and traceability across safety-information interfaces.

QPPV Oversight

The EU implementation strategy explicitly connects ODCS documentation to QPPV oversight.

This should not be interpreted as requiring the QPPV personally to approve every operational questionnaire or individual case. The governance objective is that the QPPV has sufficient visibility over the pharmacovigilance system to understand where organised safety information is generated, how it is controlled and whether material gaps exist.

A practical QPPV oversight model can include:

• visibility of the ODCS inventory;
• escalation of new high-risk or ambiguous programmes;
• periodic review of programme classification;
• metrics for late transfers or reconciliation discrepancies;
• oversight of material vendor failures;
• evidence that required ODCS documentation exists;
• confirmation that major procedural changes were implemented;
• and access to inspection-ready supporting records.

The standard is effective oversight, not accumulation of signatures.

Vendor and Partner Interfaces

E2D(R1) repeatedly recognises third parties acting on behalf of the MAH.

This means the pharmacovigilance clock can begin before information reaches the central safety team. A PSP operator, market-research agency, literature vendor or digital-platform service provider may be the first MAH agent to obtain sufficient information.

Contracts and safety-data exchange arrangements should therefore define, as applicable:

• what constitutes safety information;
• how source classification is determined;
• transfer timelines;
• handling of incomplete reports;
• follow-up responsibilities;
• causality assessment responsibilities;
• duplicate checks;
• regional data requirements;
• reconciliation;
• training;
• change notification;
• audit/inspection access;
• and escalation of system failures.

A generic “notify PV within one business day” clause may be operationally useful, but it does not replace the need to define which activity is being performed and how regulatory awareness is established.

Inspection Perspective

An inspector evaluating E2D(R1) implementation can test whether the organisation's process works end to end.

Useful inspection questions include:

• Which current activities meet the ODCS definition?
• How were PSPs existing before September 2026 handled?
• What evidence supports classification of one-way service programmes?
• Where are ODCS documents stored and who maintains them?
• Can the QPPV demonstrate oversight of the ODCS population?
• How are MAH-controlled digital platforms screened?
• How was screening frequency linked to reporting timelines?
• How are external social-listening activities scoped?
• How does the organisation distinguish primary from secondary non-interventional data?
• How are solicited cases routed for causality assessment?
• How is Day Zero determined for literature and digital cases?
• What mapping is used when the regional E2B system has not implemented the newest ICH value?
• How are duplicate cases from multiple channels reconciled?
• Can programme changes be traced through change control and retraining?

The strongest evidence is contemporaneous: programme assessments, approved documentation, data-flow maps, training records, contracts, reconciliation logs, sample case traces, system configuration records and governance minutes.

Illustrative Failure Modes

The following are hypothetical failure modes, not reported inspection findings.

“Everything Online Is Spontaneous”

A company treats every social-media case as spontaneous, including cases generated by a planned social-listening ODCS.

The failure is conceptual: report type depends on how the information was obtained, not simply on the fact that it appeared online.

“Everything in a PSP Is Solicited Forever”

An old programme consists only of home delivery and one-way logistics, but remains classified as a PSP because that was the historic company label.

The risk is that the commercial programme name substitutes for the E2D(R1) design-based assessment.

Secondary Data Converted Into Thousands of ICSRs

A retrospective database study identifies coded adverse outcomes and automatically creates ICSRs for every record.

The failure is the loss of distinction between secondary-use real-world data and individual case reporting.

Database Coding Drives Regulatory Classification

An organisation continues to call PSP cases “other studies” conceptually because the regional E2B system has not implemented the new PSP code.

The failure is allowing a temporary transmission mapping to overwrite the underlying regulatory classification.

Vendor Receipt Is Ignored for Day Zero

A contracted programme operator receives a valid case but the company starts Day Zero only when the central PV mailbox receives the transfer.

The failure is treating internal receipt as regulatory awareness even though the vendor acts on behalf of the MAH.

ODCS Document Exists but Does Not Describe the Activity

A template is completed with generic statements such as “monitor safety” and “follow company SOPs” without defining the actual dataset, review method or AE-management route.

The document may exist, but it does not provide the evidence or operational control contemplated by E2D(R1).

Practical Implementation Framework

A useful implementation approach is to treat E2D(R1) as a source-to-case control framework, not as a document-update project.

Step 1 — Build the Source Inventory

Identify every channel and activity through which the MAH or an organisation acting on its behalf can obtain post-approval safety information.

Do not restrict the inventory to the safety department. Include relevant activities owned by medical information, commercial functions, patient services, market research, quality, clinical/epidemiology teams, digital teams, affiliates and vendors.

Step 2 — Classify the Activity

For each activity, determine:

1. whether information is collected in a planned manner;
2. whether it is an ODCS;
3. whether a protocol exists or is required;
4. whether separate ODCS documentation is required;
5. whether the activity meets the PSP or MRP definition;
6. whether a digital platform is under MAH responsibility;
7. whether reports are spontaneous or solicited;
8. and what regional reporting framework applies.

Classification should be documented before the activity begins where possible.

Step 3 — Define the Safety Data Flow

Map the route from first awareness to the safety database.

A useful data-flow record identifies:

Source
  ↓
First recipient
  ↓
Recognition of potential safety information
  ↓
Transfer to PV
  ↓
Validity / minimum-criteria assessment
  ↓
Report type and causality
  ↓
Day Zero
  ↓
Regional reporting decision
  ↓
Submission / follow-up / reconciliation

The map should show where a case can be delayed, duplicated or lost.

Step 4 — Align Day Zero Rules

Train each source-owning function on the Day Zero rule that applies to its activity.

This is particularly important for:

• MAH-controlled digital platforms;
• external digital ODCS activities;
• literature screening;
• vendors and partners;
• follow-up information;
• and programmes where the case becomes valid only after additional information is obtained.

The safety database should retain enough chronology to reconstruct why a particular date was selected.

Step 5 — Separate Classification From E2B Mapping

Maintain a controlled internal taxonomy that represents the actual E2D(R1) source and report type.

Then map that taxonomy to the E2B values currently accepted by the destination regulatory system.

This allows the organisation to change an outbound mapping without changing the underlying classification history.

Step 6 — Test With Real Cases

Implementation should be verified using representative end-to-end samples rather than only reviewing procedures.

Useful test cases include:

• spontaneous report on an MAH website;
• AE found during planned social listening;
• AE seen incidentally on an external site;
• PSP report;
• one-way delivery-service report;
• MRP report;
• primary-data non-interventional study case;
• secondary-data study outcome;
• literature case that becomes valid after follow-up;
• duplicate reports from two sources.

For each sample, verify source, report type, causality handling, Day Zero, E2B coding, submission decision and audit trail.

Step 7 — Monitor the System

Post-implementation monitoring can focus on indicators such as:

• late transfers from source functions;
• misclassified spontaneous/solicited cases;
• missing causality assessments for solicited cases;
• ODCS activities without documentation;
• unexplained Day Zero changes;
• reconciliation discrepancies;
• repeated duplicate creation;
• and programme changes that did not trigger PV reassessment.

Metrics are useful only if they lead to investigation and corrective action where appropriate.

Worked Classification Scenarios

The following examples are illustrative and should always be checked against current regional requirements.

Scenario 1 — Patient Posts on the MAH Product Website

A patient independently writes on the MAH's product website that they developed urticaria after taking the medicine. The post contains enough information to meet the ICSR minimum criteria.

The platform is under MAH responsibility, but the report was not generated through an organised collection activity.

Classification: spontaneous.

Day Zero: under the E2D(R1) digital-platform framework, when the sufficient minimum information was posted on the MAH-responsible platform, subject to regional requirements.

The company should not classify the report as solicited merely because the website is company owned.

Scenario 2 — Planned Social Listening

An MAH defines a three-month activity to collect and analyse posts from specified public forums for perceptions of treatment safety. During the planned review, the team identifies a valid case.

The activity is planned data collection and therefore fits the ODCS framework.

Classification: solicited/report from study.

Additional control: the activity should have the required ODCS documentation, and the case requires the causality assessment applicable to solicited reports.

Day Zero: when the reviewer identifies the AE/ADR and has sufficient information to establish the reporting criteria—not automatically the date the dataset was first accessed.

Scenario 3 — Incidental External Social-Media Awareness

An MAH employee is researching an unrelated business question and notices a valid adverse-reaction report on a public forum. The company was not systematically monitoring the site.

The information was not obtained through an ODCS.

Classification: spontaneous if it meets the applicable reporting requirements.

This example demonstrates why external platforms are not subject to a general screening obligation but safety information actually encountered cannot simply be ignored.

Scenario 4 — Stand-Alone Home Delivery

An MAH funds a service that delivers medicine to patients' homes. The service does not ask for medical information and has no two-way clinical support component.

Under the revised PSP definition, the service does not qualify as a PSP merely because patients are enrolled.

If an ADR is nevertheless reported through the service and the activity is not part of an ODCS or combined PSP, the case is handled under the spontaneous framework.

For an ongoing programme predating the EU transition, the organisation should also consider the specific EMA grandfathering approach and document any change from its historical classification.

Scenario 5 — Nurse Support Plus Delivery

A programme combines medicine delivery with nurse contacts in which patients receive administration support and medical advice.

The nurse component meets the criteria for a PSP. E2D(R1) treats the combined multi-activity programme as a PSP.

Classification: safety reports from the combined programme are handled as solicited PSP reports.

This shows why an activity cannot always be classified by isolating one operational component.

Scenario 6 — Retrospective Claims Study

An MAH conducts a retrospective study using an existing health-insurance claims database. The analysis identifies an increased frequency of a coded clinical outcome.

The study uses secondary data.

ICSR consequence under E2D(R1): identified AEs/ADRs are not reported as ICSRs unless regional or local requirements say otherwise.

The finding may still be highly important for signal evaluation, benefit-risk assessment, periodic reporting or regulatory communication.

What E2D(R1) Did Not Change

A revision of this scale can create the impression that the whole post-marketing case system has been replaced. It has not.

Several core pharmacovigilance principles remain:

• regional law determines the actual reporting obligation;
• individual case reporting is distinct from aggregate safety evaluation;
• valid case information must remain attributable and traceable;
• serious and unexpected cases remain central to expedited reporting;
• follow-up should improve clinically important information;
• duplicate cases should be identified and managed;
• third-party activities require appropriate contractual control;
• and the MAH remains responsible for an effective pharmacovigilance system even when work is outsourced.

The revision mainly gives these principles a framework better suited to modern data sources and operating models.

Implementation Checklist

Key Takeaways

• ICH E2D(R1) is a substantial revision of the 2003 post-approval safety-data guideline, not a terminology-only update.
• The revision is built around activity design, source responsibility and organised data collection, rather than simplistic channel labels.
• Solicited reports are those derived from ODCSs and are classified as reports from study in E2B; they require causality assessment.
• Digital information can be spontaneous or solicited depending on how the MAH obtains it.
• MAHs should screen digital platforms under their responsibility, but E2D(R1) does not create a general obligation to screen every external platform.
• Planned review of external digital data can itself constitute an ODCS.
• The revised PSP definition requires attention to two-way communication and foreseeable receipt of medical information; some one-way service activities fall outside the PSP definition.
• Primary-data and secondary-data non-interventional studies have materially different ICSR implications.
• E2D(R1) gives clearer Day Zero rules for ordinary, literature, digital and follow-up cases.
• “Other observations” and important safety findings reinforce that pharmacovigilance action is broader than ICSR submission.
• The E2B(R3) taxonomy has been updated internationally, but EU EudraVigilance implementation of the new source values is separate from implementation of E2D(R1).
• In the EU, the implementation date specified by EMA for ODCS documentation was 18 September 2026; that date has passed, and the documentation should be maintained under QPPV oversight in accordance with the EU implementation strategy.
• Existing GVP Module VI should still be applied where relevant while EMA completes its planned revision; E2D(R1) should be read together with the EU implementation strategy rather than in isolation.

References

1. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH E2D(R1): Post-Approval Safety Data: Definitions and Standards for Management and Reporting of Individual Case Safety Reports. Final Step 4 guideline, adopted 15 September 2025.
   https://database.ich.org/sites/default/files/ICH_E2D%28R1%29_Step4_FinalGuideline_2025_0819.pdf

2. European Medicines Agency. ICH E2D post-approval safety data management — scientific guideline. Includes the current EU effective version and implementation material.
   https://www.ema.europa.eu/en/ich-e2d-post-approval-safety-data-management-scientific-guideline

3. 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; adopted by PRAC 20 February 2026.
   https://www.ema.europa.eu/en/documents/scientific-guideline/eu-implementation-strategy-ich-e2dr1-guideline-post-approval-safety-data-definitions-standards-management-reporting-individual-case-safety-reports_en.pdf

4. European Medicines Agency. Good pharmacovigilance practices (GVP). Current GVP modules and EMA notice on planned revisions following ICH E2D(R1) and ICH M14.
   https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices-gvp

5. 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. EMA/873138/2011 Rev. 2.

6. International Council for Harmonisation. ICH E2B(R3) Information Paper Regarding Alignment with ICH E2D(R1) Guideline. Final version, adopted 16 December 2025.
   https://admin.ich.org/sites/default/files/inline-files/E2B%28R3%29_InfoPaper_MCApproved_20251216.pdf

7. International Council for Harmonisation. ICH E2D(R1) Step 4 Presentation. September 2025.
   https://database.ich.org/sites/default/files/ICH%20E2D%28R1%29_Step%204_Presentation_2025_0904.pdf

8. International Council for Harmonisation. ICH E2D(R1) Training Material. November 2025.
   https://database.ich.org/sites/default/files/ICH_E2D%28R1%29_TrainingMaterial_2025_1211.pdf

Regulatory Note

This article is an educational interpretation of the current ICH E2D(R1) and EU implementation framework as reviewed on 1 October 2026. It does not replace EU legislation, GVP, ICH guidance, EMA implementation instructions or competent-authority requirements.

ICH guidelines are harmonised regulatory guidance, not EU legislation in themselves. Binding obligations arise from the applicable legal framework, while GVP and EMA implementation material explain how the EU pharmacovigilance system is expected to operate.

The E2B(R3) and EudraVigilance technical implementation position can change independently of the underlying E2D(R1) concepts. Organisations should therefore verify the current EMA and EudraVigilance implementation information before changing production transmission mappings.

The worked scenarios and failure modes in this article are illustrative. They are not presented as actual inspection findings unless a specific regulatory source is cited.