Pharmacovigilant by Default: Rethinking PSP Architecture

Patient support program pharmacovigilance is the practice of capturing, classifying, and reporting adverse events that surface through a PSP — and whether that capture happens at all is largely a function of how the program's software is built, not just its written procedures.

In 2012, a routine UK inspection of a top-10 pharma company found roughly 80,000 safety reports that had never been evaluated to determine whether they were reportable adverse reactions. Around 15,000 of them were reports of patient deaths. The reports were not lost, hacked, or hidden. They were sitting inside a patient support program, correctly recorded by people doing their jobs, in a system that was never designed to treat a patient conversation as a pharmacovigilance event.

Zelthy is an AI-native platform-as-a-service for pharmaceutical operations, used to build and run patient support programs with adverse event capture, day-zero timestamping, immutable audit lineage, and structured handoff to the safety database built into the application layer — deployed across 12+ countries for top-10 global pharma companies and more than 1M patient journeys.

This guide is for PV and safety leads, PSP program owners, and the pharma IT teams who build or buy the software underneath them. It covers what regulators actually require of a PSP, what the enforcement record shows about where AE capture breaks, why the standard control set is structurally weak, and how to design a PSP application so that pharmacovigilance is a property of the system rather than a task assigned to a coordinator.

Pharmacovigilance is one of the highest-stakes obligations in life sciences

Post-marketing safety reporting is not a documentation exercise. It is a licence condition with criminal and financial consequences attached.

In the US, 21 CFR 314.80 requires an application holder to submit each serious and unexpected adverse drug experience within 15 calendar days of initial receipt, and to promptly investigate every event that is the subject of a 15-day Alert report. Failure to comply with section 505(k) of the FD&C Act is a prohibited act under section 301(e). Not a deviation. A prohibited act.

The largest healthcare fraud settlement in US history includes a count of exactly this kind. In 2012 GlaxoSmithKline agreed to plead guilty and pay $3 billion, with one of the three criminal counts being failure to report safety data on Avandia to the FDA. The criminal component alone was $1 billion.

In the EU, the Penalties Regulation (EC) No 658/2007 allows the European Commission to fine a marketing authorisation holder up to 5% of its EU turnover in the preceding year for breaching pharmacovigilance obligations attached to a centrally authorised product. For a large MAH that ceiling runs to hundreds of millions of euros.

But the fine is the least interesting part of the cost, and focusing on it misleads people about the real exposure. The 2012 inspection described at the top of this post triggered the first-ever infringement procedure under the Penalties Regulation. It ran for five years. It involved a re-inspection, a first EMA investigation report in 2014, a return of the file from the Commission to EMA in 2015, a second inquiry, a final report in 2016, and a PRAC review of whether the benefit-risk balance of 19 centrally authorised products had been affected. The Commission closed the case in December 2017 without issuing a statement of objections, satisfied with the remedial actions taken.

No fine. Five years of regulatory scrutiny, a company-wide remediation program, and a public record. That is the realistic downside for a well-resourced MAH: not a penalty line item, but years of supervised rebuilding — and, in the interim, a benefit-risk file that regulators could not fully assess.

Underlying all of this is a baseline that has not moved in twenty years. A systematic review of 37 studies across 12 countries found a median under-reporting rate of 94% for adverse drug reactions to spontaneous reporting systems, with an interquartile range of 82–98%. For serious or severe reactions specifically, the median stayed around 85–95%. Under-reporting is not an edge case in pharmacovigilance. It is the default state of any system that relies on a human deciding to report.

Why patient support programs are the highest-risk PV surface in pharma

A PSP is, in regulatory terms, not a marketing activity. It is a data collection system.

GVP Module VI (Rev 2), section VI.C.2.2.11, defines a patient support programme as an organised system through which a marketing authorisation holder receives and collects information about the use of its products — including disease management programmes, compliance information gathering, and reimbursement schemes. Section VI.B.1.2 classifies reports derived from organised data collection systems as solicited, alongside clinical trials, registries, and named patient use programmes. Solicited reports are handled as study reports and require a causality assessment.

Three structural features make PSPs uniquely exposed.

The volume is large and growing. One recent industry estimate cited by DIA puts roughly 2,000 active patient assistance programs across about 500 companies in the US alone. Each one is a channel through which a company speaks directly to patients about their experience taking its product.

Contact is deliberate. As the DIA analysis puts it, these programs invariably surface safety information precisely because the company is talking to the patient about the product. A PSP does not passively wait for reports. It calls patients, schedules deliveries, chases refills, asks how they are getting on. Every one of those interactions is a solicitation, whether or not anyone designed it that way.

The classification itself is contested. There is no clear regulatory guidance in any jurisdiction on exactly what qualifies a PSP's reports as solicited. The MHRA Inspectorate has published the most useful public direction, splitting programmes into three categories: those with active solicitation (reports are solicited, causality assessed); those without active solicitation but with established AE reporting mechanisms (solicited or spontaneous depending on structure); and those where reporting is incidental in the margins (spontaneous, with implied causality).

That leaves companies choosing between two bad outcomes. Treat every PSP-sourced AE as spontaneous, and you generate a large expedited reporting volume — each case defaulting to "related" — much of which reflects the underlying disease rather than the drug. Treat them as solicited, and an inspector may find the programme was not designed in a way that demonstrates solicited collection, and cite you for the expedited reports you did not file.

Notice what determines which side of that line a programme falls on: whether contact was planned, whether structured data collection tools were used, how interactions were documented. Those are all properties of the software the programme runs on. The classification question is an architecture question wearing a regulatory costume.

What recent enforcement shows about where PSP adverse event capture breaks

The most instructive public document on this subject is a March 2026 FDA warning letter issued to a top-10 pharma company's US headquarters following a Bioresearch Monitoring inspection of its post-marketing adverse drug experience compliance. It is worth reading in full, because every single deficiency cited is a workflow design failure rather than a diligence failure. Four are directly transferable to any PSP.

1. Causality-based exclusion encoded into procedure. The company's written procedure excluded reports from the definition of adverse reaction where the reporter stated they believed the event was unrelated to the product. FDA's definition covers any adverse event associated with drug use, "whether or not considered drug-related." The cited example: a consumer disabled by a stroke while taking liraglutide, who said the stroke was unrelated — so the case was rejected and never reported. A serious, unexpected event, closed by a rule that a reasonable person had written into a document and a system had faithfully executed.
2. Vendor intake invalidating cases that were actually valid. Call-centre contractors invalidated 15-day Alert reports for missing patient identifiers. FDA found the identifiers present in the source documents. In one case a consumer had reported a death; the case was invalidated for a missing identifier that was sitting in the source record. The company had already changed call-centre vendors once over this exact issue, opened a deviation, completed CAPAs — and the invalidations continued. Changing the vendor did not fix it, because the failure was in the interface between the source record and the case intake form, not in the vendor.
3. Cases stalled in a workflow state. The company's procedure specified that most serious reactions enter medical review by day 9 and complete it by day 10 after the awareness date. Cases sat in medical review well beyond that. A consumer report of suicidal ideation received on 9 December entered review on 16 December, was not medically reviewed until 3 February — after FDA identified it during the inspection — and was submitted on 5 February. The procedure defined a timeline. Nothing in the system enforced it, and nothing made the breach visible while it was happening.
4. Follow-up gated on consent. The procedure did not require follow-up on reported AEs where the reporter was a non-healthcare professional and consent had not been obtained. PADE regulations impose no such consent requirement. A non-HCP reported a patient death; the case was closed without investigation or submission because consent had not been captured. A blocking condition in the workflow prevented the legally required action.

FDA's closing point is the one every PSP owner should internalise: the application holder remains responsible for PADE compliance including when a vendor is contracted to fulfil those responsibilities. The agency explicitly criticised the absence of detail on how vendors acting on the company's behalf would correctly receive, review, and process AE information.

You cannot delegate the obligation. You can only delegate the execution — which means the only durable control is the system the vendor executes inside.

How PSPs typically approach pharmacovigilance today

The industry's standard control set is well documented. The MHRA Inspectorate lists what "appropriate measures" usually means in practice: contractual language with third parties on collecting and forwarding safety information; training of company staff and third parties on PV concepts and data collection tools; periodic or end-of-programme reconciliation of safety data; and quality assurance activities including audit and source data verification.

DIA's guidance to companies lands in the same place: contracts, training, QA and reconciliation, and a formal document defining the nature of interactions with patients. A 2017 industry survey found considerable variability across companies in exactly these dimensions — vendor oversight, applicable SOPs, training, and contractual language.

Every one of these controls is sound. Every one of them is also a compensating control that sits outside the application where the work happens.

Reconciliation deserves particular scrutiny, because it is the control most companies lean on hardest. Reconciliation is detection, not prevention. If a reconciliation run finds a reportable case in a call note from six weeks ago, the regulatory clock started six weeks ago — at initial receipt by anyone acting on behalf of the MAH — and it expired five weeks ago. The reconciliation did not save the case. It documented the breach.

Where the misses actually happen

Across programmes, the same five structural gaps recur.

Free text is where the ambiguous cases live. The AE form produces clean data because it is used for the unambiguous cases — the ones where the patient says "side effect," or the event is severe enough that no judgment is required. Everything requiring interpretation ends up in a call disposition note, a chat transcript, or a nurse's summary. Given the 94% baseline under-reporting rate, the ambiguous cases are not a minority of the safety-relevant signal. They are most of it.

Day zero is reconstructed rather than recorded. Most PSP applications timestamp the case when it enters the safety workflow, not when the information first reached the programme. That means the compliance clock is computed retrospectively, usually during reconciliation, and often by inference from a call log. A company that cannot state its day zero for last month's cases without opening a spreadsheet does not know its compliance posture.

Channel proliferation outpaces the AE workflow. A modern PSP touches patients through a nurse hotline, a mobile app, WhatsApp or SMS, an IVR system, a delivery partner, a specialty pharmacy, and a field team. The AE form typically exists on one or two of those. The rest of the channels generate the same class of information with none of the same handling.

The vendor boundary is a data boundary. When intake is outsourced, the source record lives in the vendor's system and a subset of it is transcribed into a case. Every transcription is an opportunity for a valid case to be invalidated — as the warning letter above shows, with the missing patient identifier that was present in the source document the whole time.

Reconciliation runs on a monthly cadence against a 15-day obligation. The arithmetic here does not need elaboration.

Engineering pharmacovigilance by default: five architectural principles

The reframe is straightforward. Stop building an AE module. Make the application pharmacovigilant the way it is multi-tenant, or encrypted at rest, or auditable — a property of the architecture that everything built on top inherits. Nobody ships "a tenancy feature."

Here is what that means concretely in the PSP applications built on Zelthy:

Every patient-facing surface is a capture surface, and nothing blocks

Call dispositions, chat threads, nurse notes, refill gaps, IVR transcripts, the free-text reason a patient gives for skipping a dose, the delivery exception — all of it enters the same safety-relevant record store, with the same structure and the same retention. The coordinator's obligation is to record faithfully. The system's obligation is to route.

Critically, the application never asks a human "Is this an adverse event? Yes or No." That question moves the hardest classification decision in the workflow to the least-equipped person at the worst possible moment, and then audits them for it. Classification happens downstream, by people qualified to do it, on a complete record.

Day zero is a timestamp, not a decision

First receipt is captured at the atomic level — on the utterance, not on the case — the moment information reaches anyone acting on behalf of the MAH. Elapsed time against the 15-day obligation is a live object in the application, visible on the record and on the control tower, not a number derived later. State transitions carry enforced timers, so a case cannot sit in medical review past its procedural deadline without escalating. The failure mode in the warning letter above — a suicidal-ideation report stuck in review for seven weeks — is a state machine without a clock.

Lineage over correction

Every safety-relevant record is immutable and versioned, with full who-saw-what-and-when lineage, on the Zango framework's built-in audit trail. If a case can be edited without lineage, it is not a pharmacovigilance record; it is a spreadsheet with better typography. This is also what makes the vendor boundary survivable: when the source record and the case share an audit trail inside one multi-tenant system, an inspector can trace a submission back to the sentence a patient said, and so can you.

Reconciliation should return nothing

The handoff to the safety database is structured and machine-to-machine — E2B(R3) ICSR transmission rather than monthly line listings and human matching. Reconciliation still runs, but its purpose inverts: every hit is a defect report filed against the architecture, not a case saved. A programme whose reconciliation consistently returns zero has a working system. A programme whose reconciliation consistently returns cases has a broken one, regardless of how diligently those cases are then processed.

AI flags; it never decides

AI agents run continuously across free text and voice transcripts to surface potential safety signals — a nausea mentioned in a note titled "hydration advice," a hospitalisation referenced in a rescheduling request, a symptom described in the patient's own words rather than in MedDRA terms.

Three non-negotiable design rules apply:

• Tune for recall, accept false positives. A false positive costs a triage minute. A false negative costs a signal, and potentially a 15-day breach.
• Never auto-suppress. The model can promote a record for review. It cannot close one. Given a regulatory definition that requires reporting regardless of suspected causality, any model empowered to filter is a model empowered to recreate the exact deficiency FDA cited above.
• Every flag cites its source. The trigger sentence, the channel, the timestamp, the speaker. Without traceability the safety team cannot defend a flag in an inspection, and will stop trusting the system by month three.

Because Zelthy is modular and built on the open-source Zango framework, these controls are configured into an existing PSP module rather than rebuilt per programme — and customers retain code ownership, which matters when a validated safety-relevant system has to outlive a vendor relationship.

Centralised PV dashboards on the PSP control tower

Most PSP control towers report on enrolment, adherence, refills, and turnaround times. Safety appears, if at all, as a monthly count of AE forms submitted — a number that measures form usage, not safety performance.

A PV view built into the control tower should answer, at any moment and without a data pull:

Clock status across all open cases. Every case with a live day-zero timestamp and time remaining against its regulatory deadline, sorted by exposure. Not days since case creation. Days since first receipt.

Time-in-state by workflow stage. Where cases are accumulating, and which stage is slowest. This is the view that would have surfaced a case sitting in medical review for seven weeks on the day it went past 10.

The AI-flagged review queue with source context. Each flag shown alongside the sentence, channel, and timestamp that triggered it, so a reviewer can judge in seconds and the decision is documented.

Capture by channel and by vendor. AE-suspect volume per 1,000 interactions, broken out by hotline, chat, app, IVR, field, and by each third party running any part of the programme. Channels that produce implausibly low rates are not clean channels. They are unmonitored ones.

Reconciliation delta. The count of cases found by reconciliation that the live pipeline missed, trended over time, with a target of zero. Treated as a defect metric, not a productivity metric.

Submission status and inspection-ready export. Transmission state for every ICSR sent to the safety database, and a one-click export of the full lineage for any case — source record, timestamps, state transitions, reviewer decisions.

What this doesn't solve

Better capture is not the same as better science, and it would be dishonest to imply otherwise.

A published analysis of AE reports from a set of manufacturer-initiated PSPs for one cardiovascular product found that those reports contributed no updates to the core data sheet — no new validated safety signals. PSPs generate a high volume of AE reports; that volume does not automatically translate into signal. Anyone selling capture as a route to pharmacovigilance insight is overselling.

The honest case for capture is compliance and completeness, not signal yield. You capture because the obligation is absolute, because the 15-day clock is unforgiving, and because a benefit-risk file assembled from partial data is not a benefit-risk file.

Three further limits are worth stating plainly. First, the solicited-versus-spontaneous classification is a regulatory and legal judgment about programme design; software can generate the evidence an inspector needs, but it cannot make the determination. Second, better capture increases expedited reporting volume, and if the programme is not designed and documented to support solicited classification, that volume lands as a real operational cost. Third, none of this replaces the safety database, the QPPV, or medical review. The platform's job is to ensure that everything reportable arrives at those functions intact, timestamped, and traceable — nothing more.

Implementation considerations

Most companies face three options, and the trade-offs are fairly stark.

Custom build. Full control of the architecture, and full ownership of validation, audit trail implementation, E2B transmission, multi-country configuration, and every future regulatory change. Timelines typically run 9–18 months before a first programme goes live, and PV controls are usually the last thing built rather than the first.

Enterprise SaaS suites. Mature safety databases and established PV modules, but the PSP-facing layer is generally configured to the vendor's model rather than the programme's, per-module commercial terms are high, and customisation of the capture layer — where the misses actually happen — is limited. Code ownership is not on the table.

Platform approach. Pre-built PSP modules with the safety controls already embedded, configured per programme, deployed in weeks rather than quarters, with the underlying code owned by the customer. This is where Zelthy sits: a HIPAA- and GDPR-compliant, FHIR-interoperable PaaS on which programmes are built and run by the pharma company or its partners.

Whichever route you take, three requirements should be non-negotiable in the specification: atomic day-zero timestamping at first receipt; immutable lineage from source utterance to submitted ICSR; and structured E2B transmission to the safety database. If a vendor cannot demonstrate all three in a live system, reconciliation will remain your primary safety control — and reconciliation is detection, not prevention.

Frequently asked questions

Are adverse events from a patient support program solicited or spontaneous?

Under EMA GVP Module VI, reports derived from organised data collection systems — which include patient support and disease management programmes — are solicited, and require a causality assessment. The MHRA has clarified that programmes without active solicitation may still produce spontaneous reports, depending on structure. The determining factors are whether contact is planned and whether structured data collection tools are used, which makes the classification substantially a function of how the programme's software is designed.

What is the deadline for reporting an adverse event from a PSP?

For serious and unexpected adverse drug experiences, 21 CFR 314.80 requires submission to FDA within 15 calendar days of initial receipt of the information by the applicant. Initial receipt means when the information reached anyone acting on the marketing authorisation holder's behalf, including a contracted call centre — not when the safety team opened the case.

Can a pharma company delegate PSP adverse event reporting to a vendor?

Execution can be delegated; the obligation cannot. FDA has stated explicitly that the application holder remains responsible for PADE compliance including when a vendor is contracted to fulfil those responsibilities, and has cited companies for inadequate detail on how vendors acting on their behalf receive, review, and process AE information.

What software do pharma companies use for PSP pharmacovigilance?

Most run a safety database such as Argus for case management, and a separate PSP application for programme operations, with periodic reconciliation between the two. The gap sits in the PSP application, which is typically not designed as a pharmacovigilance system. Platforms such as Zelthy address this by building AE capture, day-zero timestamping, audit lineage, and E2B handoff into the PSP application layer itself.

How do you measure whether PSP adverse event capture is working?

Three metrics: reconciliation delta (cases found later that the live pipeline missed — target zero), day-zero-to-submission distribution against the 15-day obligation, and AE-suspect rate per 1,000 interactions by channel and vendor. A channel reporting implausibly few events is usually unmonitored rather than clean.

Does AI improve adverse event detection in patient support programs?

It improves detection recall across free-text and voice channels where structured forms are not used. It should be configured to flag for human review, never to close cases, and every flag should trace to its source sentence. Given that regulations require reporting regardless of suspected causality, any model permitted to filter cases reintroduces the precise failure mode regulators have cited.

The takeaway

Nobody in this industry under-reports on purpose. The enforcement record shows something more uncomfortable: procedures that were written, approved, trained on, and followed — and that lost reportable events anyway, because the loss was designed into the workflow rather than caused by anyone in it. Contracts, training, and reconciliation are all necessary. None of them is where the failure occurs, and none of them can fix a capture layer that assumes a coordinator will interrupt an act of care to perform an act of compliance.

If you are building or reviewing a patient support programme, start with three questions: where does day zero get stamped, what happens to a nausea mention typed into a note about hydration advice, and what did your last reconciliation catch. The third answer is a measure of your architecture, not your safety team.

Talk to us about your patient support programme →