Digital PSP Enrolment and Consent in Saudi Arabia: Getting PDPL and Safety Reporting Right From Day One
How pharma teams design PSP enrolment, PDPL consent and adverse-event routing in Saudi Arabia.
Key takeaways
- Health data requires explicit consent under the PDPL, and patients must be permitted to withdraw consent at any time without undue delay.
- Consent purposes—including programme participation, safety follow-up, research, and communication channels—must be stored independently rather than bundled into a single tick box.
- Marketing authorisation holders must establish adverse-event routing to report safety cases collected through support programmes to the SFDA within required timelines.
Reviewed by the CareSync Medical Team · Last reviewed
On this page
Digital Patient Support Programme (PSP) enrolment is the moment a patient joins a pharma-funded support programme, receives information about how their data will be used, gives consent and becomes visible to the programme team. In Saudi Arabia it is also the moment a programme either builds trust or creates compliance debt: health data is sensitive under the PDPL, and anything a patient reports about side effects can become a safety case for the marketing authorisation holder.
Because enrolment sets the rules for everything that follows, it deserves more design effort than any other step in the programme.
Key takeaways
- Health data needs explicit consent. Law-firm analyses of the PDPL state that processing sensitive data requires the explicit consent of data subjects, and health data is classed as sensitive.
- Patients can withdraw. Data subjects may withdraw consent at any time, and the Implementing Regulations require a controller to stop processing without undue delay when they do.
- The grace period is over. Organisations had until 14 September 2024, so full compliance has been mandatory since then.
- Safety information is a regulatory matter. Marketing authorisation holders must submit local individual case safety reports to the SFDA, and the EU framework, a common reference point, treats reports collected through patient support programmes as solicited reports.
- Separate the purposes. Programme participation, safety follow-up, research and marketing should never sit behind one tick box.
What should happen at digital enrolment?
| Step | What the patient sees or does | What the programme records | Why it matters |
|---|---|---|---|
| 1. Referral and eligibility | Invited by their treating clinician; eligibility confirmed | Referral source, eligibility basis | Keeps the programme clinician-led and non-promotional |
| 2. Plain-language notice | Short Arabic or English notice on what data is collected, why, who sees it and how long it is kept | Notice version shown | Transparency is the foundation of valid consent |
| 3. Explicit consent for health data | A separate, unticked choice to take part and share health information | Time, version, channel, language | Explicit consent is required for sensitive data |
| 4. Safety-reporting notice | Clear statement that reported side effects may be passed to the manufacturer and regulator | Acknowledgement | Prepares the patient and protects the programme |
| 5. Optional choices | Separate options for research use and for contact channels | Each choice stored independently | Avoids bundled, invalid consent |
| 6. Withdrawal route | Simple way to withdraw at any time | Withdrawal date and effect | Withdrawal must be honoured without undue delay |
The implication: a good enrolment flow produces an audit trail, not just a signed form.
How should adverse events be handled inside a PSP?
Nurse educators and coordinators often hear about side effects, missed doses or product complaints before the treating physician does. Each of these can be reportable.
| What happens | What the programme should do | Owner |
|---|---|---|
| A patient mentions a possible side effect in a call or message | Capture it verbatim, flag it and route it the same day | Programme coordinator |
| A product complaint or lack of effect is reported | Log and route to pharmacovigilance | Programme coordinator |
| A serious event is suspected | Escalate immediately to a clinician and the pharmacovigilance team | Clinical lead |
| A case reaches the marketing authorisation holder | Assess and report to the SFDA within required timelines | Pharmacovigilance / local QPPV |
One regulatory resource summarising SFDA guidance lists 15 days for serious or unexpected cases and 90 days for expected non-serious cases. Treat that as a pointer, and confirm current timelines in the SFDA's own pharmacovigilance guidelines.
Pharmacovigilance and data protection obligations remain with the marketing authorisation holder and the data controller. Align every programme with SFDA requirements, the PDPL and your internal compliance teams.
A five-step plan for pharma teams
- Map every data point. List what the programme collects, why, who accesses it and how long it is kept.
- Write the notice and consent in plain Arabic and English. Test them with real patients before launch.
- Split consent by purpose. Participation, safety follow-up, research and communication channels each get their own choice.
- Build the adverse-event pathway before go-live. Agree what is captured, who is alerted and how fast, then test it with scenarios.
- Log everything. Store consent version, timestamp, language and withdrawals, and review the log with compliance each quarter.
How CareSync PSP Connect helps
CareSync PSP Connect is the deployment of CareSync's white-label health-tech ecosystem built for pharma Patient Support Programmes. It is designed to support consent capture with version and timestamp, separate consent choices, a simple withdrawal route and adverse-event flagging that routes to the programme's pharmacovigilance process with an audit trail. Programmes run through the treating provider's own branded channel, with clear separation from promotion. Responsibility for compliance stays with the marketing authorisation holder and the provider; CareSync provides the tooling.
Frequently asked questions
Do PSPs need explicit consent in Saudi Arabia? Health data is sensitive under the PDPL, and processing sensitive data generally requires explicit consent unless a specific legal exception applies. Confirm the basis for your programme with qualified counsel.
Can patients withdraw consent from a PSP? Yes. The PDPL gives data subjects the right to withdraw consent at any time, and the controller must stop processing without undue delay.
Who is the data controller in a provider-embedded PSP? It depends on the programme design and contracts, and should be defined in writing between the pharma company, the provider and the platform vendor.
Are adverse events reported in a PSP reportable to the SFDA? Yes in principle: safety information that reaches the marketing authorisation holder must be handled under pharmacovigilance rules. Programmes need a defined capture and escalation pathway.
Should one consent cover everything? No. Bundled consent is weak. Keep participation, safety follow-up, research use and communication channels separate.
How should consent be recorded? With the notice version shown, a timestamp, language, channel and a record of any change or withdrawal, so it can be evidenced later.
Can PSP data support real-world evidence? It can, when patients have given a separate, informed consent for research use and the programme was designed for it from the start.
Does consent need to be in Arabic? Patients should receive notices and consent requests in a language they fully understand. Offering Arabic and English is the practical standard in Saudi Arabia.
What should a patient support programme consent form include in Saudi Arabia? Who the data controller is, the purposes, the categories of health data collected, who receives it, how long it is kept, the right to withdraw, a safety-reporting notice and separate optional choices for research and contact channels. Have counsel confirm the wording for your programme.
Do I need separate consent to contact patients on WhatsApp or SMS? Treat the contact channel as its own choice, recorded separately from consent to take part, so a patient can accept the programme without accepting every channel. Confirm channel rules with counsel and keep content non-promotional.
How long can a PSP keep patient data? Only as long as needed for the purposes stated in the notice and for legal obligations. Define retention up front, and agree with pharmacovigilance how long safety records must be kept, since that can differ from other programme data.
What is a solicited adverse event report in a PSP? A report that arises from an organised data-collection programme such as a patient support programme, rather than from a spontaneous message. One summary of SFDA guidance notes that solicited reports are classified as study reports and should undergo causality assessment before reporting. Confirm the current rule with the SFDA.
Trust starts at the first screen
A patient who understands what they are agreeing to is more likely to stay engaged and more likely to report problems honestly. A programme that records consent properly and routes safety information reliably protects patients, the pharma company and its provider partners.
Designing a PSP for Saudi Arabia? Book a CareSync demo at CareSync.
About CareSync
Prepared by the CareSync Medical Team. This article is educational, not medical advice or a substitute for clinical, legal or regulatory review. Research findings are source-specific, not measured CareSync outcomes.
Sources
- Herbert Smith Freehills Kramer. Saudi Arabia's Personal Data Protection Law: what you need to know, 2023.
- Akin Gump. Kingdom of Saudi Arabia's new PDPL and Implementing Regulations.
- Security Scientist. 12 questions and answers about the PDPL.
- European Medicines Agency. Management of safety data from patient support programmes and market research programmes.
- PharmaKnowl. ICSR submission to the SFDA (secondary source).