Sponsor Data Access in PSPs: What Aggregate Reporting Should and Should Not Show

Sponsor Data Access in PSPs: What Aggregate Reporting Should and Should Not Show

Pharmaceutical sponsors who fund patient support programs have legitimate and important information needs. They need to know whether the program is reaching patients, whether coordinators are following protocol, and whether the program is functioning as a pharmacovigilance instrument. At the same time, the data processed in a Saudi PSP includes sensitive personal health data about identifiable patients — data whose protection is both a legal requirement under PDPL and an ethical obligation to the patients the program is designed to support.

Navigating between these two legitimate interests — sponsor oversight and patient data protection — is one of the most consequential governance decisions in PSP design. Getting it wrong in either direction creates problems: too much sponsor access to individual patient data creates PDPL liability; too little sponsor access to aggregate program data prevents effective program governance.

This article defines what aggregate sponsor reporting should include, what it should not include, and how the line between aggregate and individual data is maintained in well-governed Saudi PSPs.

---

Key Takeaways

• Saudi PSP sponsor reporting should give sponsors complete visibility into aggregate program performance — including pharmacovigilance compliance — without providing access to individually identifiable patient data.
• The correct reporting model is aggregate by design, not individual data with names removed: pseudonymized individual records are still personal data under PDPL.
• Sponsors are entitled to see their own patients' AE records as part of pharmacovigilance obligations — but AE reporting operates under a different legal basis and different access rules than general program reporting.
• Keywords are unvalidated editorial hypotheses (H); no search volume claims are made.

---

The Core Principle: Aggregate by Design

The standard reporting model in most Saudi PSP platforms provides sponsors with access to dashboards that display aggregate metrics — enrollment counts, retention rates, interaction volumes. This is appropriate and necessary.

The compliance problem arises when sponsors request — and platforms provide — access to records that allow sponsors to identify individual patients. This occurs more commonly than it should, usually through one of three mechanisms:

Pseudonymized patient-level exports: A data export where patient names and national IDs are removed but which retains enough quasi-identifying information (HCP name, facility, diagnosis, enrollment date, interaction history) that re-identification is possible. Under PDPL, pseudonymized data remains personal data if re-identification is possible. [HOLD — expert review: specific PDPL treatment of pseudonymized data requires legal professional review]

Case-level AE reporting to commercial teams: AE records transmitted to the sponsor are appropriately shared with the safety team, which uses them in the safety database under separate legal basis and access controls. When AE records are also shared with the commercial team or brand team as part of program reporting, this represents a data use that may exceed the purpose for which the data was collected. [HOLD — expert review: specific AE data sharing obligations and limitations require PV professional and legal review]

HCP-level patient counts that are functionally individual data: A report showing that a specific named HCP has three enrolled patients, one of whom has been inactive for 60 days, is not aggregate data in any meaningful sense — it is a dataset that allows inference about individual patients.

---

What Aggregate Sponsor Reporting Should Include

Program Performance Metrics

Sponsors are entitled to full visibility into how their program is performing at the population level. Standard aggregate reporting should include:

• Enrollment rate (enrolled / referred), reported for the program as a whole and by geography/region
• Activation rate and time-to-activation
• Monthly and longitudinal retention rates with defined denominators
• Lapse rates by cohort (enrollment cohort, therapy line, or other program-defined segments — not by individual HCP or facility where patient volumes are small)
• Contact volume and completion rates

Pharmacovigilance Compliance Metrics

Sponsors are not only entitled to see PV compliance metrics — they have a legal obligation to monitor them. Aggregate PV metrics should include:

• AE capture rate (AE prompt completion / total meaningful interactions)
• Serious AE escalation timeliness (escalations within SDEA timeframe / total serious AEs)
• AE minimum dataset completeness
• Reconciliation schedule adherence

These metrics do not require individual patient data to be generated — they are counts and rates calculated from the underlying interaction data, reported at the program level.

Coordinator Protocol Adherence

Sponsors are entitled to verify that coordinators are following the program protocol. At the aggregate level, this includes:

• Interaction completion rates by step (what proportion of interactions reach the AE documentation step)
• Protocol deviation rates (interactions flagged for protocol non-compliance)
• Training certification status (what proportion of active coordinators have current training certificates)

This information is properly reported at the aggregate level — not as individual coordinator performance records, which are the operator's HR data.

---

What Aggregate Sponsor Reporting Should Not Include

Individually Identifiable Patient Data

Sponsor dashboards and reports should not include data that allows individual patients to be identified. This includes:

• Patient names, national IDs, phone numbers, or addresses
• Records that combine quasi-identifying fields in ways that allow re-identification (e.g., rare disease diagnosis + facility + age + treatment start date)
• Interaction logs at the individual patient level (as opposed to aggregate interaction counts and rates)
• Patient-level HCP assignments where the combination of fields allows patient inference

Individual HCP Performance Data That Functions as Patient Data

A report showing HCP-level patient data at volumes below a de-identification threshold (typically 5–10 patients, though the appropriate threshold depends on the specific data elements) is functionally individual data because it allows patient inference. HCP-level program data should be reported in aggregates that protect individual patients. [VERIFY WITH BRAND — specific de-identification thresholds require legal and privacy professional guidance]

Individual AE Records in Commercial Reporting Channels

AE records must flow to the sponsor's safety team under the SDEA. They must not flow to the commercial team, brand team, or marketing function through general program reporting. If the brand team needs to understand PV compliance — which they should — they should see aggregate PV metrics (AE capture rate, escalation timeliness), not individual case summaries. [HOLD — expert review: specific AE data routing requirements require PV professional and legal review]

---

How the Line Is Maintained in Practice

Role-Based Access Controls

The most practical mechanism for maintaining the aggregate/individual data line is role-based access control in the reporting platform:

• Sponsor commercial and brand teams: access to aggregate program performance metrics and aggregate PV compliance metrics
• Sponsor safety contact: access to individual AE case records under SDEA terms
• Sponsor medical affairs: access to aggregate clinical and therapy support metrics
• Platform audit: access to full interaction logs, restricted to audit purposes and inaccessible through standard reporting

Minimum Patient Count Rules

Aggregate reporting cells with patient counts below a defined threshold should be suppressed or flagged. This prevents individual identification through small-cell analysis. The specific threshold should be defined in the DPA and reflected in the platform's reporting configuration. [VERIFY WITH BRAND — specific small-cell suppression thresholds require privacy professional guidance]

Audit Trail for Data Access

All sponsor data access to the PSP platform should be logged — which user accessed what data, when, and from what access channel. These logs support both PDPL compliance monitoring and program governance.

---

Special Case: Pharmacovigilance Data Access

AE data access operates under different rules than general program reporting, and these rules must be explicitly documented in the SDEA.

Sponsors have both a legal obligation and an operational need to access AE data reported through their PSP — this data must be incorporated into the sponsor's global safety database and reported to SFDA as required. The access framework for AE data is therefore defined by pharmacovigilance law, not only by PDPL. [HOLD — expert review: specific AE data access obligations require PV professional and legal review]

The governance principle: AE data flows to the safety team under a separate legal basis from general program data. The safety team has access to individual AE case records; the commercial and brand teams do not. This division is a compliance requirement, not a preference.

---

FAQ

Can sponsors require the platform to give them access to individual patient records? Sponsors, as PDPL data controllers, determine the purposes and means of data processing. However, requiring a platform to process personal data beyond the purposes for which patients consented creates liability for the sponsor as data controller. Access to individually identifiable patient records for general program oversight purposes is not a purpose patients in a Saudi PSP typically consent to, and therefore cannot be provided under consent as the legal basis. [HOLD — expert review: specific sponsor data access rights under PDPL require legal professional review]

How does aggregate reporting work when the program has very small patient numbers — such as a rare disease program? Small patient populations present a genuine challenge for aggregate reporting because any aggregate statistic over a small number becomes potentially identifying. For programs with fewer than 20–30 active patients, reporting design requires specific privacy professional input — standard de-identification thresholds designed for large populations may be insufficient. [VERIFY WITH BRAND — rare disease reporting design requires legal and privacy professional guidance]

What reporting should a sponsor receive when a program is first launching? During program launch (typically the first 90 days), aggregate reporting should cover the same metrics as a mature program — but with the understanding that early-stage numbers may be too small for all metrics to be meaningful. Reports should state sample sizes for rates, and rates calculated on fewer than 10 observations should be flagged as provisional. [VERIFY WITH BRAND — specific launch-phase reporting practices require commercial and medical affairs validation]

Who owns the right to request a data audit of the PSP platform? The sponsor, as data controller, has the right to audit the platform's data processing practices. This right should be specified in the DPA, with defined audit procedures, frequency, scope, and cost allocation. [HOLD — expert review: specific audit rights under PDPL require legal professional review]

---

Published: 2026-11-05 · Author: CareSync Team · This article provides general guidance on sponsor data access principles in patient support programs in Saudi Arabia. It does not constitute legal advice. All data access and reporting practices should be designed with qualified legal and privacy professionals and reviewed against current PDPL implementing regulations.

---

Review your PSP sponsor data access framework with CareSync. Request a data governance consultation →