QPPV.COM

Adverse Events from Social Media, Apps and Digital Platforms

Explains how pharmacovigilance responsibilities differ between MAH-controlled and external digital platforms, when digital reports are spontaneous or solicited, how validity and Day Zero are determined, and how monitoring, follow-up, duplicates, vendors and evidence should be controlled.

Take test

Adverse Events from Social Media, Apps and Digital Platforms

Digital platforms have become ordinary sources of post-authorisation safety information. A patient may describe an adverse reaction in a product-support app, comment on an MAH social-media post, send a message through a chatbot, post in a public forum, or discuss treatment in a community that an MAH later reviews as part of a social-listening activity.

The pharmacovigilance challenge is not simply that the information is online. The regulatory treatment depends on who is responsible for the platform, why the MAH is accessing the data, how the information was generated, whether the minimum ICSR criteria are met, and whether the activity is spontaneous reporting or organised data collection.

ICH E2D(R1) provides the modern framework. It distinguishes digital platforms under MAH responsibility from those outside MAH responsibility and makes clear that the same platform can produce either spontaneous or solicited reports depending on the context.

This article applies that framework operationally to social media, websites, mobile applications, internet forums, chat rooms, messaging tools, digital-health technologies and other software-enabled channels.

Purpose and Scope

This article addresses post-authorisation pharmacovigilance for digital platforms.

Its scope includes:

The article does not treat every online mention of a medicine as an ICSR. Instead, it explains the sequence needed to determine whether digital information enters the pharmacovigilance system and, if so, how it should be classified and managed.

The central sequence is:

Digital information → platform responsibility → context of access → spontaneous or ODCS? → minimum ICSR criteria → source-specific Day Zero → follow-up / duplicate assessment → regional reporting decision → documentation and audit trail

This sequence is more reliable than using a single rule such as “all social-media cases are spontaneous” or “all information collected digitally is solicited”.

Regulatory Framework

ICH E2D(R1)

ICH E2D(R1), adopted at Step 4 in September 2025 and implemented in the EU from 18 March 2026, defines a digital platform as software and technology used to enable transmission of information between users.

The guideline gives examples including:

It then makes the key distinction between:

  1. digital platforms under the responsibility of the MAH;
  2. digital platforms not under the responsibility of the MAH.

That distinction affects:

EU GVP

Current GVP Module VI remains relevant while EMA revises affected GVP modules to integrate ICH E2D(R1).

EMA states that, in the interim, the guidance and definitions in E2D(R1) should be applied where they affect GVP, together with the E2D(R1) EU implementation strategy.

The current GVP framework already expects MAHs to monitor digital media under their management or responsibility at a frequency that allows valid ICSRs to be reported within the applicable timeframe.

E2D(R1) refines and modernises that framework by defining the activity-based distinction more explicitly.

This distinction should remain visible.

EU pharmacovigilance legislation provides the binding legal reporting framework. GVP provides the principal EU operational guidance. ICH E2D(R1) provides harmonised guidance on post-approval ICSR management.

Operational recommendations—such as monitoring methods, evidence-retention practices or review workflows—should not be presented as statutory requirements unless the legal or regional framework explicitly makes them so.

The First Question: Is the Platform Under MAH Responsibility?

This is the most important initial classification.

E2D(R1) says a digital platform is under MAH responsibility when it is owned, controlled or operated by, or on behalf of, the MAH.

Examples can include:

The question is not merely who paid for the platform.

E2D(R1) specifically states that a donation or financial contribution to an organisation does not necessarily make the MAH responsible for the platform, provided the MAH does not control its content or communications.

The practical test is therefore based on control and operation, not branding alone.

Platform Responsibility Is Not the Same as Case Type

A frequent error is to assume:

company-owned platform = solicited case.

That is incorrect.

E2D(R1) makes clear that a spontaneous report can arise on an MAH-controlled platform.

For example, if a patient independently posts:

“I started Product X last week and developed a severe rash.”

on an MAH product page, that report may be spontaneous if it was not generated through an organised collection activity.

By contrast, if the MAH deliberately runs a structured online programme that asks participants questions designed to collect health information, cases arising through that activity may be solicited because the activity is an ODCS.

The same technical platform can therefore support:

The platform itself does not determine the case type.

A Better Classification Model

Digital PV works best when classification follows the activity, not the technology.

A useful model is:

Question Why it matters
Who owns or controls the platform? Determines whether routine screening responsibility applies
Why is the MAH accessing the information? Distinguishes ordinary platform surveillance from organised data collection
Was information actively solicited? Helps determine spontaneous vs solicited framework
Was the activity planned and documented? Can indicate ODCS status
Does the report meet minimum ICSR criteria? Determines whether it can become a reportable case
What source-specific Day Zero rule applies? Determines the regulatory clock
Does regional law require submission? Determines final reporting action

This sequence should be reflected in SOPs, vendor instructions and system design.

MAH-Controlled Websites

A company website is the simplest example of a platform under MAH responsibility.

Potential safety information may appear through:

E2D(R1) states that platforms under MAH responsibility should be regularly screened for AEs/ADRs at a frequency that permits reporting within the required timeframe.

That principle has two consequences.

First, the organisation should know which areas of its digital estate can receive user-generated content.

Second, the monitoring frequency should be designed around regulatory timeliness rather than convenience.

An unmonitored contact form hidden deep within a website is still capable of generating a report.

Social-Media Pages Operated by the MAH

The same logic applies to:

The platform provider is external, but the specific MAH account or page may still be under MAH responsibility if the MAH controls or operates it.

The MAH should therefore know:

Inactive does not necessarily mean irrelevant if users can still post messages.

Digital Platform Inventory

A recommended operational control is a maintained inventory of digital channels under MAH responsibility.

For each platform or account, the inventory can include:

This is recommended practice rather than a specific statutory format.

Its value is that the pharmacovigilance system can demonstrate that all relevant controlled digital channels are known and assigned.

New Digital Channels Should Trigger PV Review

Digital platforms are often launched by functions outside PV.

Examples include:

A governance control should therefore ensure that new public-facing digital functionality is assessed before launch.

Useful questions include:

This review prevents pharmacovigilance obligations from being discovered only after the first adverse event appears.

Platforms Not Under MAH Responsibility

ICH E2D(R1) states that MAHs are not expected to screen or review digital platforms that are not under their responsibility for AEs/ADRs.

This is an important boundary.

It means that an MAH does not have a general obligation under E2D(R1) to continuously scan:

That limitation is operationally necessary. The open internet is effectively unbounded.

However, the absence of a general monitoring duty does not mean that safety information encountered externally can be ignored.

Two different situations must be separated:

  1. planned review of external digital data;
  2. incidental awareness outside a planned review.

Planned Review of External Platforms

If an MAH deliberately accesses data from an external digital platform in a planned manner consistent with organised data collection, E2D(R1) says the activity should be considered an organised data collection system (ODCS).

Examples include:

The critical point is intentionality and structure.

A team that simply notices occasional public posts is not doing the same thing as a team that has defined:

The latter is organised data collection.

Social Listening as an ODCS

The EU E2D(R1) implementation strategy specifically gives social listening or digital listening as an example of an ODCS where an MAH monitors and analyses user communications on a social-media site.

This has several consequences.

The activity should be documented as an ODCS when applicable.

For an ODCS not conducted according to a protocol, the documentation should describe, as applicable:

This changes how safety information identified through the activity is classified.

If an AE/ADR identified from the digital ODCS meets reporting requirements, it is handled as a solicited report, including the causality assessment applicable to solicited information.

Do Not Expand the Search Beyond the Defined Dataset

E2D(R1) also provides an important limit.

When accessing an external digital platform in the context of an ODCS, the MAH is not expected to search for AEs/ADRs beyond the planned review of the dataset defined in the ODCS documentation.

This prevents a structured activity from becoming an undefined obligation to search the entire platform.

For example, if an ODCS is defined to assess posts containing a specific product name over a three-month period in selected public communities, the MAH should perform the planned review competently.

It is not expected under E2D(R1) to expand spontaneously into:

The documented scope matters.

Day Zero in an External Digital ODCS

The Day Zero rule for an external platform ODCS is different from the rule for an MAH-controlled platform.

For an MAH-controlled platform, Day Zero can begin when sufficient information was posted.

For an external platform being reviewed as part of an ODCS, E2D(R1) states that Day Zero starts when the MAH, or a third party acting on its behalf, identifies the AE/ADR during review and has sufficient information to determine that reporting criteria are met.

Day Zero is not necessarily the date the external dataset was accessed.

Example:

Event Date
Dataset collected 1 October
Analyst begins review 3 October
Relevant post encountered 5 October
Post contains sufficient ICSR information 5 October
Case transferred to PV 6 October

Under the E2D(R1) digital-ODCS rule, 5 October is the relevant Day Zero if that is when the case was first identified and reporting criteria were met.

This distinction is explained more fully in Day Zero in Pharmacovigilance: When Does the Reporting Clock Start?.

Incidental Awareness on an External Platform

An MAH employee may encounter a safety report while using an external platform for another purpose.

E2D(R1) gives a business-question example: an employee views a website to find information relevant to another business issue and sees an AE/ADR mentioned.

The MAH is expected to review the safety information and manage it according to the applicable regional requirements.

If the report meets reporting requirements, it is managed as a spontaneous report, because it was not obtained through an ODCS.

This is an important distinction:

external platform + planned structured review → ODCS → solicited framework

external platform + incidental awareness outside ODCS → spontaneous framework

The same website can therefore generate different report types depending on the activity that produced the awareness.

Employee Personal Social-Media Use

A difficult practical situation arises when an MAH employee encounters a possible adverse event on a personal social-media account.

E2D(R1) establishes the general principle that information encountered outside an ODCS can still require management when the MAH becomes aware of it.

Operational procedures should therefore define reasonable expectations for employees.

Recommended practice is usually to focus training on:

The procedure should avoid creating an unrealistic expectation that every employee must actively monitor their personal online activity for adverse events.

The distinction is between incidental awareness and active surveillance.

Digital Identifiability

The minimum ICSR criteria still apply to digital reports.

A digital post may mention:

The difficult question is whether a real patient and reporter can be considered identifiable.

ICH E2D(R1) states that a digital username or handle alone is not necessarily sufficient to establish identifiability.

The purpose of identifiability is to establish that the patient and reporter are real persons, not necessarily to obtain their full legal identity.

Depending on the case, useful identifying information can include:

The exact assessment should follow applicable regional requirements and the circumstances of the report.

Usernames, Handles and Pseudonyms

A username such as "@Runner1978" may or may not establish a real identifiable reporter.

A platform profile could contain additional evidence such as:

However, pharmacovigilance teams should not turn case validation into online investigation beyond what is appropriate and lawful.

The correct approach is usually to assess the information actually available and, where feasible and permissible, attempt follow-up.

The case record should document why the reporter and patient were or were not considered identifiable.

One Person Can Be Both Patient and Reporter

Digital reports are often first-person.

For example:

“I took Product X last night and woke up with facial swelling.”

The patient and reporter can be the same person.

The report does not need two separate individuals to satisfy the patient and reporter criteria.

The assessment should determine whether:

Third-Person Posts

A user may post:

“My mother developed severe dizziness after starting Product X.”

This creates a different identifiability problem.

The reporter may be identifiable through the user account, while the patient is another person.

Follow-up may be needed to establish enough information about the patient and event.

The organisation should also consider privacy constraints when asking a reporter to provide information about someone else.

Screenshots and Source Preservation

Digital information can change quickly.

Posts may be:

A recommended operational practice is to preserve contemporaneous evidence of the source where lawful and technically feasible.

This may include:

This is not a universal legal requirement in one prescribed format.

The control objective is traceability: the organisation should be able to reconstruct what information was available when the case was assessed.

Edited Posts

Suppose a patient posts:

“Product X made me dizzy.”

and later edits the post to add:

“I was admitted to hospital overnight.”

The original and edited versions may represent:

If the platform or moderation system provides edit history, the chronology should be preserved.

If the later information changes seriousness, a new follow-up reporting clock may apply.

The case should not simply overwrite the earlier source text.

Deleted Posts

If a valid case is captured and the user later deletes the post, deletion does not erase the fact that the MAH previously received or had access to the information.

The case should continue to be managed based on the information available at the time.

Follow-up may become impossible, and that limitation should be documented.

If the post disappears before the MAH detects it on a platform not under its responsibility, the MAH cannot act on information it never became aware of.

That distinction reinforces why monitoring frequency matters only for channels for which the MAH actually has responsibility.

Private Messages and Direct Messages

Direct messages can generate the same pharmacovigilance obligations as public comments.

They may contain more detailed personal and medical information and can therefore create additional privacy and access-control issues.

Operational controls should ensure that:

If a vendor operates the inbox, the vendor's awareness can be relevant to Day Zero when acting on behalf of the MAH.

Follow-Up Through the Platform

A digital platform can sometimes support direct follow-up.

Examples include:

Follow-up should be proportionate and should respect:

The objective is to obtain clinically useful information, not to pursue a reluctant user.

The organisation should document:

Mobile Apps and Patient Portals

Mobile applications can combine several functions that have different pharmacovigilance consequences.

A single app may contain:

The correct classification depends on the function through which the information was generated.

A patient who independently sends a free-text message describing an adverse reaction through an MAH app may generate a spontaneous report.

If the same app is used as part of a structured patient-support programme or another ODCS that actively collects medical information, cases arising through that organised function may be solicited.

The organisation should therefore avoid assigning one pharmacovigilance classification to the entire app merely because it has one product name and one technical platform.

Functional Mapping of an App

A useful implementation method is to map each user-facing feature.

App function Potential PV relevance
Static education page Usually no user-generated case information
Contact-us form Can generate spontaneous reports
Free-text chat Can generate spontaneous reports or programme data depending on context
Symptom questionnaire May form part of an ODCS
Medication reminder Usually not a safety source by itself
Patient-support nurse messaging May form part of a PSP
Adherence survey May form part of organised collection
Device-generated measurements May become relevant within a study or monitoring activity
User review/comment feature Can generate spontaneous reports

This functional analysis should be completed before launch and revisited when the application changes.

A software update can create a new pharmacovigilance source without anyone describing it as a “PV change”.

For example, adding a comments field to a previously static app introduces a new route for free-text safety information.

Chatbots and Conversational Interfaces

Chatbots create a particularly important control problem because they can receive safety information continuously while no human is watching.

A user may type:

“Since starting Product X I have been vomiting and fainted yesterday.”

If the chatbot is part of a digital platform under MAH responsibility, the case should be assessed under the same digital-platform framework as other user communications.

The fact that an automated system received the information does not mean the pharmacovigilance clock can wait until a human reads it during office hours.

The organisation should understand:

Rule-Based Versus AI-Assisted Triage

Automation may help identify messages that potentially contain:

This can reduce manual review burden, but automated detection should be treated as a control mechanism, not as a regulatory redefinition of awareness.

If the relevant source-specific rule says Day Zero begins when sufficient information was posted on an MAH-responsible platform, the organisation should not define Day Zero as “when the classifier flagged the message”.

A classifier can miss a report.

The PV system therefore needs evidence that the monitoring design is sufficiently reliable to support the required reporting timelines.

Recommended controls can include:

These are recommended risk controls. E2D(R1) does not prescribe one AI-validation methodology.

Generative AI and User-Facing Assistants

A generative assistant can create additional complexity because it may:

The source record should preserve the user's actual information, not only an AI-generated summary.

If the model incorrectly paraphrases “rash” as “anaphylaxis”, the derived text should not silently replace the primary-source statement.

A robust architecture preserves:

  1. original user message;
  2. timestamp;
  3. AI-generated interpretation where used;
  4. any subsequent user clarification;
  5. human review;
  6. final case-processing decision.

The distinction between source information and machine-generated interpretation should remain traceable.

Translation of Digital Reports

Digital platforms may receive reports in many languages.

Translation can be performed by:

The pharmacovigilance objective is preservation of meaning.

Important safety details such as:

can be distorted by poor translation.

Recommended practice is to retain the original language source and document the translated version used for processing.

Where machine translation is used, risk-based quality controls are appropriate, particularly for serious or medically complex cases.

Translation itself does not create a new Day Zero when the report was already valid before translation.

Voice, Video and Audio Messages

Digital platforms increasingly accept:

These can contain valid safety information even when no text is present.

The organisation should decide:

A transcription is a derived record.

The original source should remain available where retention is lawful and required by the applicable process.

Images and Attachments

A user may upload:

Attachments can provide clinically important follow-up information.

They can also contain extensive personal data unrelated to pharmacovigilance.

The workflow should therefore balance:

A moderator should not casually download sensitive attachments to unmanaged personal devices.

Validity: Start With the Minimum Criteria

Digital reports should not be subjected to a separate “internet validity” standard.

The same core ICSR questions apply:

The challenge is that digital content often contains these elements indirectly.

For example:

“This drug gave me hives after my third injection.”

may identify:

The case processor may still need to determine whether the account reasonably establishes a real person and whether the product is sufficiently identifiable.

Context Can Supply Information

The meaning of a post can depend on its digital context.

A user writes:

“Same thing happened to me — severe nausea for two days.”

under an MAH post specifically discussing Product X.

The product may not be named inside the user's comment, but the context may contribute to the product assessment.

The case processor should preserve enough of the surrounding context to explain how the product was identified.

This is another reason that copying only the isolated comment text can be insufficient.

Emojis, Slang and Informal Language

Digital reports may use:

A statement such as:

“This med knocked me out 😵 for hours”

requires interpretation before coding.

The case narrative should preserve the reporter's meaning while medical coding uses the appropriate terminology.

The organisation should avoid over-interpreting ambiguous content.

Where the clinical meaning is uncertain and follow-up is possible, clarification is preferable to unsupported inference.

Hashtags and Product Identification

Hashtags, account context or campaign pages can help identify a medicine, but they should be evaluated carefully.

A post using a disease hashtag does not necessarily establish exposure to a specific product.

A post on a product-specific page may provide stronger context.

The case record should document how product identification was determined rather than relying on an unexplained database value.

Seriousness in Digital Reports

Users may describe seriousness without using regulatory terminology.

Examples include:

These statements require medical assessment against the applicable seriousness criteria.

The case should not be downgraded because the reporter did not use words such as “hospitalisation” or “life-threatening”.

Conversely, dramatic language does not automatically establish a seriousness criterion without sufficient supporting context.

Follow-Up Priorities

Digital follow-up should be risk based.

Priority may be higher when the report involves:

The platform may allow rapid follow-up, but the reporter may also disappear immediately.

Documented unsuccessful follow-up is still useful evidence that due diligence was attempted where appropriate.

Duplicate Risk Is High in Digital Channels

The same case can appear through several routes:

Digital amplification also creates reposts, screenshots and quotations of the same original content.

A robust duplicate process should consider:

The objective is to avoid both:

Reposts and Shared Content

A user may repost another person's story.

The reposting user is not necessarily the patient or original reporter.

The pharmacovigilance assessment should identify whether the post contains:

A copied story should not automatically create a new independent ICSR.

However, if the reposting user adds their own experience, that additional information may represent a separate case.

Influencers and Sponsored Content

MAHs may work with influencers, patient advocates or content creators.

The pharmacovigilance implications depend on the relationship and degree of MAH control.

If a creator is acting on behalf of the MAH or operating within a company-controlled campaign, the associated channels and comments may fall within the MAH's responsibility and should be assessed accordingly.

A simple commercial relationship should not be assumed automatically to create control over every independent communication by the creator.

The contractual and operational facts matter.

Before launch, the MAH should establish:

Platform Closure and Archived Campaigns

Campaigns end, but digital pages often remain accessible.

A page may be:

PV responsibility should follow actual functionality, not the marketing status label.

When a platform is retired, closure controls should confirm whether:

Monitoring Frequency

Neither E2D(R1) nor current GVP establishes one universal monitoring interval for every digital platform.

The governing principle is that platforms under MAH responsibility should be screened frequently enough to allow identification and reporting of cases within the applicable regulatory timeframe.

That means monitoring frequency should be risk- and channel-based.

Relevant factors include:

A high-volume patient-support app may require a different operating model from a low-volume corporate page that rarely receives user comments.

The important point is that the chosen frequency must be defensible against the reporting clock.

Monitoring Is Not the Same as Social Listening

This distinction should be explicit in procedures.

Routine screening of an MAH-responsible platform is part of ordinary pharmacovigilance surveillance for spontaneous reports.

Social listening or another planned analysis of external digital data can constitute an ODCS.

These activities may use similar technology, but their regulatory character is different.

For example:

Calling both activities “social listening” can create classification errors.

The operational name used by marketing or analytics teams should therefore not substitute for a pharmacovigilance assessment.

Monitoring Scope

For a platform under MAH responsibility, the organisation should know which areas require screening.

Potential areas include:

A monitoring plan that covers only public comments while private messages remain unchecked may be incomplete if users can send safety information privately.

The platform inventory should therefore map functions, not only account names.

Moderation Tools and Hidden Content

Modern platforms may automatically place content into:

Potential safety information can therefore be technically received without appearing in the main user interface.

The MAH should understand the platform's moderation behaviour.

Recommended controls include periodic review of:

This is a systems-control issue rather than a requirement to inspect every technical log indiscriminately.

The focus should be on routes through which user-generated safety information could reasonably be lost.

Vendor-Operated Moderation

Agencies frequently operate digital channels on behalf of MAHs.

Examples include:

Where the vendor operates the platform on behalf of the MAH, the MAH remains responsible for ensuring that safety information is recognised and transferred appropriately.

A pharmacovigilance agreement or equivalent controlled arrangement should define, as applicable:

A vendor service-level agreement should support regulatory compliance; it should not redefine the regulatory clock.

Vendor Training

Digital moderators are not case processors, but they need enough training to recognise content that may require PV transfer.

Training should cover more than the phrase “adverse event”.

Users may describe safety information as:

Training should therefore include:

The purpose is recognition and transfer, not medical adjudication by the moderator.

Reconciliation

Reconciliation is particularly useful when a digital vendor maintains its own moderation or support system.

The MAH may compare:

Reconciliation can identify:

The frequency should be proportionate to the activity and its risk.

A monthly reconciliation cannot compensate for a process that allows serious cases to wait a month before transfer. Reconciliation is a completeness control, not a primary intake mechanism.

Change Control

Digital platforms change continuously.

Changes that can affect PV include:

A formal PV reassessment should occur when a change materially affects the ability to receive, detect, retain or transfer safety information.

The organisation should not rely on the assumption that “the platform already passed PV review last year”.

Platform API Changes

Some organisations use APIs to collect comments or messages automatically.

An external platform can change:

A monitoring service can therefore fail silently.

Recommended technical controls include:

The compliance question is whether relevant user content remained visible to the MAH within the required timeframe.

Evidence Retention and Audit Trail

Digital PV requires enough evidence to reconstruct the source and the processing decision.

Depending on the platform and applicable privacy constraints, useful evidence can include:

Not every case needs every element.

The evidence retained should be sufficient to support:

The organisation should avoid collecting excessive unrelated personal information merely because it is technically available.

Data Protection and Pharmacovigilance

Digital pharmacovigilance often involves personal data, including health information.

PV obligations and data-protection obligations therefore need coordinated implementation.

The article does not provide legal advice on GDPR or national privacy law, but several operational principles are important:

A publicly visible post may still contain personal data.

The fact that information is public does not eliminate governance obligations.

Contacting Users for Follow-Up

Follow-up should be feasible, proportionate and lawful.

Potential methods include:

Public follow-up questions should be designed carefully because they can encourage disclosure of sensitive health information in public.

A safer practice may be to move detailed follow-up into a private or secure channel where possible.

If the user does not respond, the case should be processed with the information available and the unsuccessful follow-up attempt documented.

Blocking, Abuse and Harassment

A user may post both safety information and abusive content.

The MAH's moderation policy may permit:

PV processing should occur before relevant safety information is lost.

Recommended workflow:

  1. preserve the safety-relevant source information;
  2. transfer it to PV as appropriate;
  3. apply the moderation policy;
  4. document any effect on follow-up.

Pharmacovigilance does not require an organisation to tolerate harassment indefinitely, but the source information should not be destroyed before it can be assessed.

Misinformation and False Reports

Digital platforms can contain:

A report does not become genuine merely because it names a medicine and an event.

Identifiability and plausibility should therefore be assessed using the normal case framework.

However, case processors should be cautious about rejecting reports simply because the medical story seems improbable.

The question is whether the minimum criteria and applicable reporting requirements are met—not whether the MAH believes the event definitely occurred.

If there is evidence that the report is fabricated or generated by a non-human account, the assessment and rationale should be documented.

Bots and Synthetic Content

Automated accounts can repost or generate health-related text.

This is a modern identifiability challenge.

A purely automated account does not represent an identifiable human reporter simply because it has a username.

Where the platform or context indicates that content was machine-generated, the case processor should determine whether there is evidence of:

If those elements cannot be established, the content may not meet the minimum ICSR criteria.

The reasoning should be documented rather than inferred silently.

Employee Responses to Public Posts

MAH staff may be tempted to answer a user publicly.

A response can have several objectives:

The company should have approved response patterns that do not:

The internal case should be initiated based on information already available where applicable.

Safety Communication Versus Safety Intake

Digital platforms can serve two distinct PV functions:

  1. receiving safety information;
  2. communicating safety information.

GVP Module XV recognises social media and other online tools as potential safety-communication channels and emphasises the need to preserve accuracy.

These functions should be governed separately even when they use the same account.

For example, a public safety communication may trigger replies from patients describing their own events.

The communication team then becomes part of the intake pathway.

A surge in comments after a safety communication is not necessarily evidence of an increased event incidence. It may reflect stimulated reporting.

The pharmacovigilance system should distinguish reporting volume from epidemiological frequency.

High-Volume Events and Surge Management

A regulatory announcement, media story or viral post can generate a sudden increase in digital reports.

Preparedness should address:

A surge plan should not lower the minimum quality needed for case validity, but it may prioritise work according to clinical and regulatory significance.

Global Platforms and Local Requirements

A single MAH account may receive posts from users in many countries.

The organisation may need to determine:

The platform itself may not reliably indicate geography.

Location should not be guessed solely from language or profile appearance.

If country cannot be determined, the case should be handled according to the company's controlled global procedure and applicable regulatory rules.

E2B Source Coding

E2D(R1) and updated E2B(R3) specifications introduce more specific coding for some solicited digital sources.

When a digital-platform case arises in an ODCS and no more specific study type applies, the relevant E2B study-type value can identify a digital-platform ODCS.

If the activity is specifically a PSP or MRP, the more specific PSP or MRP classification takes precedence.

Regional technical implementation can lag behind the conceptual E2D(R1) framework.

The organisation should therefore separate:

The conceptual classification should not be distorted merely because a receiving regulatory system has not yet implemented a newer code value.

Practical Implementation Framework

A digital pharmacovigilance process should connect platform governance, safety intake and regulatory case processing rather than treating them as separate activities.

A useful implementation sequence is:

Step 1 — Inventory the Digital Estate

Identify all channels that can receive user-generated information.

Include:

For each channel, determine who owns, controls or operates it.

Step 2 — Classify the Activity

Ask whether the activity is:

This classification determines whether resulting reports are spontaneous or solicited.

Step 3 — Define Monitoring and Escalation

For MAH-responsible platforms, define:

The frequency should allow cases to be managed within the applicable reporting timelines.

Step 4 — Define Source Preservation

Specify what the moderator or automated system should retain.

Depending on the channel, this can include:

The process should preserve evidence without collecting excessive unrelated personal data.

Step 5 — Map Day Zero

For each source type, define the applicable Day Zero rule.

The most important distinction is:

Activity Day Zero principle
MAH-responsible platform When sufficient ICSR information was posted
External digital ODCS When reviewer identifies the AE/ADR and sufficient information during review
Incidental external awareness General spontaneous-report awareness rule
Initially incomplete digital report When missing information needed for reporting is obtained
Medically relevant follow-up New follow-up clock from receipt of new information

Step 6 — Test the Workflow

Use representative test scenarios before launch.

Examples include:

The test should follow the full route from source to regulatory submission.

Step 7 — Monitor Effectiveness

Useful indicators can include:

Metrics should lead to investigation where they indicate a control problem.

Worked Scenario 1 — Public Comment on an MAH Page

A patient comments on an MAH product page:

“I started Product X three days ago and yesterday developed swelling of my lips and went to the emergency department.”

The page is controlled by the MAH.

The comment was posted at 22:00 on Saturday and reviewed Monday morning.

Assessment

Operational lesson

The monitoring model must accommodate weekend posting because the regulatory clock is not created by the moderator's work schedule.

Worked Scenario 2 — Social Listening Across Public Forums

The MAH defines a four-month programme to analyse patient discussions about tolerability of Product Y across three public forums.

The activity specifies search terms, platforms, timeframe and review method.

During review, an analyst identifies a post describing an adverse event with sufficient ICSR information.

Assessment

Operational lesson

Social listening is not simply “spontaneous internet monitoring”. Its planned nature can change the report classification.

Worked Scenario 3 — Employee Encounters an External Post

An employee researching a competitor product sees a user write:

“My father developed seizures after Product Z.”

There is no company social-listening programme and the website is not controlled by the MAH.

Assessment

Operational lesson

“No general duty to screen” does not mean “ignore safety information actually encountered”.

Worked Scenario 4 — Chatbot Report

A user sends the following to an MAH chatbot at 01:15:

“I took two doses by mistake and now I'm very dizzy.”

The chatbot records the message but only transfers flagged conversations to a human queue at 08:00.

Assessment

The platform is under MAH responsibility.

Potential issues include:

Operational lesson

Automation architecture must be designed around regulatory intake, not merely customer-support availability.

Worked Scenario 5 — Username Only

A public comment says:

“This drug gave me chest pain.”

The account name is a generic handle and no other information establishes that a real patient or reporter exists.

Assessment

The content is potential safety information but may not yet satisfy the minimum identifiability criteria.

Where feasible and permissible, follow-up can be attempted.

Operational lesson

Digital content should neither be rejected automatically nor accepted automatically. Identifiability requires evidence that real persons exist.

Worked Scenario 6 — Same Case by Public Comment and Direct Message

A patient posts publicly that Product X caused a rash, then sends a private message with additional details.

Assessment

The second communication may be follow-up to the same case rather than a new case.

Duplicate/follow-up assessment should consider:

Operational lesson

Channel count is not patient count.

Worked Scenario 7 — Influencer Campaign

An MAH contracts an influencer to publish educational content for a product campaign. The agreement gives the MAH approval rights over campaign content and requires the agency to moderate comments.

A follower posts a valid adverse reaction beneath the sponsored post.

Assessment

The actual contractual and operational control should be assessed to determine whether the relevant campaign channel is under MAH responsibility.

If the agency is operating the moderated campaign on the MAH's behalf, the PV pathway should have been defined before launch.

Operational lesson

The pharmacovigilance classification depends on control and operation, not simply whether a creator is called an “influencer”.

Inspection Perspective

An inspector evaluating digital pharmacovigilance could examine whether the organisation can identify and control its actual digital safety sources.

Useful inspection questions include:

The most persuasive evidence is contemporaneous operational evidence rather than a procedure alone.

Examples include:

Illustrative Failure Modes

The following are hypothetical scenarios, not actual inspection findings.

“We Do Not Monitor Social Media”

The company states that social media is outside its PV process even though it operates product pages that accept user comments and direct messages.

Why it fails: E2D(R1) distinguishes platforms under MAH responsibility and expects them to be regularly screened.

Every Digital Case Is Spontaneous

A structured social-listening programme is treated as spontaneous intake.

Why it fails: planned organised review of external digital data can constitute an ODCS, producing solicited reports.

Every Company App Case Is Solicited

A patient independently sends an unsolicited message through an MAH app and the case is classified as solicited merely because the app is company owned.

Why it fails: platform responsibility and report type are separate questions.

Monitoring Covers Comments but Not Direct Messages

The social-media SOP requires daily review of comments but no one has access to the direct-message inbox.

Why it fails: the real platform functionality is not fully mapped.

AI Filter Defines Awareness

A valid report is posted Monday but the classifier flags it Wednesday. The organisation records Wednesday as Day Zero.

Why it fails: the automation tool does not redefine the E2D(R1) source-specific clock for an MAH-responsible platform.

Deleted Posts Are Discarded From the Case

A valid source post is captured and later deleted by the user; the case is closed because the original content is no longer publicly visible.

Why it fails: later deletion does not erase prior awareness.

Social Listening Has No Defined Dataset

A vendor continuously searches “anything relevant” across the internet without documented scope.

Why it fails: organised data collection should have a defined objective, source, dataset/review scope and safety-management process.

Vendor Moderation Has No PV Agreement

An agency manages comments for three days before forwarding “important” items to the MAH.

Why it fails: the vendor may be the first party acting on behalf of the MAH to receive reportable information, and informal transfer criteria can create missed or late cases.

Screenshot Without Context

A case file contains only a cropped sentence reading “made me pass out” with no record of product page, user, timestamp or surrounding conversation.

Why it fails: the evidence is insufficient to reconstruct how product, reporter and chronology were assessed.

Practical Digital-PV Checklist

Before a digital channel goes live or changes materially, confirm:

Relationship With Other QPPV.com Articles

This article applies the broader source framework established in ICH E2D(R1): What Changed in Post-Approval Pharmacovigilance.

The source-specific timing rules are developed in Day Zero in Pharmacovigilance: When Does the Reporting Clock Start?.

Organised digital activities should also be read alongside GVP Module VI: Other Organised Data Collection Systems and Solicited Sources.

Where a digital programme meets the revised PSP definition, GVP Module VI: Patient Support Programmes and Solicited Reports provides the deeper programme-specific framework.

Key Takeaways

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. Current EU Step 5 implementation and supporting 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.
    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. 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.
    https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-good-pharmacovigilance-practices-gvp-module-vi-collection-management-submission-reports-suspected-adverse-reactions-medicinal-products-rev-2_en.pdf

  5. European Medicines Agency. Good pharmacovigilance practices (GVP). Current modules and EMA statement on planned revision of modules affected by ICH E2D(R1).
    https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices-gvp

  6. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module XV — Safety communication, Rev. 1. Includes social media and other online communication channels.
    https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-xv-safety-communication-rev-1_en.pdf

  7. International Council for Harmonisation. ICH E2B(R3) Information Paper Regarding Alignment with ICH E2D(R1) Guideline. Final version, adopted 16 December 2025.

Regulatory Note

This article reflects the ICH E2D(R1) and EU pharmacovigilance framework reviewed on 1 October 2026.

ICH E2D(R1) is harmonised guidance and repeatedly refers users to regional or local reporting requirements. In the EU, applicable legislation, current GVP and EMA's E2D(R1) implementation material should therefore be read together.

EMA has stated that GVP modules affected by E2D(R1) will be revised. Until those revisions are completed, the E2D(R1) guidance and definitions should be applied where they affect GVP, together with the EU implementation strategy.

Operational practices described as recommended controls—such as particular screenshot methods, monitoring metrics, automation tests or platform inventories—are not presented as universal legal requirements unless explicitly stated in the governing source.

The worked scenarios and failure modes are illustrative. They are not presented as actual inspection findings.

Revision History

Related Articles

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

Explains why ICH E2D was revised, what changed in E2D(R1), how the new source and report classifications affect ICSR management, and what MAHs and QPPVs should have implemented in the EU after the 2026 transition.

Day Zero in Pharmacovigilance: When Does the Reporting Clock Start?

Explains when the ICSR reporting clock starts, why Day Zero is not simply the database-entry date, how source-specific rules operate under ICH E2D(R1) and EU GVP, and how to control awareness dates across vendors, partners, literature, digital channels and follow-up.

How to Write an ICSR Case Narrative

Explains the regulatory purpose of the ICSR case narrative, what information belongs in it, how to organise chronology, distinguish reported facts from assessment, manage follow-up and contradictions, and produce a concise stand-alone medical story suitable for regulatory review.

Last reviewed: 2026-10-01

QPPV.com