Patient Follow-Up and PDPL Compliance in Saudi Arabia

A patient follow-up project needs a privacy design for the actual work it performs: capturing consultation information, preparing actions, moving requests between teams, contacting the right recipient and retaining evidence. Calling the system administrative does not remove the sensitivity of the information passing through it. A clinic appointment, a referral destination or a message history may reveal that a person received a health service.

This guide is for Saudi clinic managers, privacy leads and implementation owners planning that design. It uses the published Saudi Personal Data Protection Law and implementing regulation reviewed on 26 October 2026. The clinic should resolve the applicable legal and sector requirements for its specific deployment. The service discussion begins with clinic consultation follow-up services.

Start with purposes and data flows, not a vendor badge

Draw the real path from the consultation to the final administrative outcome. Include microphones or recording devices, transcription, model processing, the review interface, clinic systems, messaging providers, operational logs, backups and support access. A claim about one component does not explain what the others receive or retain.

For each step, write the purpose, data categories, people or organisations receiving them, location, retention and responsible owner. If the proposed system sends an entire transcript to prepare a short booking request, ask why that amount of information is necessary. The purpose should determine the data available to the step, rather than the convenience of an unrestricted integration.

Identify who determines each processing purpose and who acts on instructions. A clinic and a supplier may have different roles across activities. A supplier's proposed use of consultation material to improve its own model raises a separate purpose question; it should not be hidden inside a general description of technical support. Record the roles and resolve the terms before any real patient information enters the arrangement.

Treat health context as sensitive information

The PDPL includes health-related information within sensitive data. Its health-data provisions restrict access and processing to the staff and extent necessary for the relevant healthcare purposes. In practical design, a booking role should receive the information needed for booking, not automatic access to everything the clinician discussed.

Do not assume a list is non-sensitive because it omits diagnoses. A combination of names, a specialist clinic, attendance history and a recall reason may reveal health-service information. Removing names while retaining linkable identifiers is also different from irreversible anonymisation. Assess what can be inferred or reconnected in the actual environment.

Use synthetic information for public demonstrations and ordinary configuration exercises wherever it can answer the question. If a later evaluation genuinely needs identifiable information, establish its lawful purpose, approved setting, access and safeguards first. The fact that a dataset is small or used for a pilot does not make it outside the privacy design.

Distinguish treatment consent, processing basis and channel choice

Consent to a clinical procedure is not a universal authorisation for every data-processing operation. Equally, consent is not the only possible lawful basis for every healthcare activity. The privacy lead should document the basis for each precise purpose under the applicable law, including any conditions attached to it, instead of using one blanket checkbox for consultation capture, messaging, analytics and promotion.

Where consent is the relied-upon basis for sensitive-data processing, Article 11 of the implementing regulation requires explicit consent with the relevant conditions and evidence. Legitimate interests are not a general route for processing sensitive data. A new AI feature should not be described as already covered merely because the patient has an existing care relationship.

Explain the proposed processing in a form the patient can understand, including what is optional, who processes information and how the relevant rights can be exercised. Keep communication preferences and recipient authority current. A patient's choice of a phone channel does not establish that a different person using the device may receive the same content.

Questions to resolve for different follow-up processing purposes

Purpose	Privacy question	Operational evidence
Consultation capture	What is collected and on which documented basis?	Notice, basis assessment and capture configuration
Action preparation	Which source details are necessary for the proposal?	Approved input scope and processor instructions
Scheduling handover	Who may receive the required administrative information?	Role, destination and accepted request
Patient communication	Is this the correct authorised recipient and suitable channel?	Current contact, preference and disclosure checks
Quality evaluation	Can the question be answered with less identifiable data?	Evaluation purpose, access and retention decision
Commercial promotion	Does the proposed use involve sensitive data?	Separate purpose assessment before any campaign

Keep care-related recall separate from marketing

Article 26 of the law excludes sensitive data from marketing use. SDAIA's controller and processor guide states explicitly that obtaining consent does not permit processing sensitive data for marketing. This is a substantive boundary, not a wording problem that can be solved by renaming a promotion a patient recall.

A recall linked to a current, authorised care obligation has a different purpose from promoting a new service. Establish why the individual needs the care-related contact, who approved it, what information is necessary and how the communication will be handled. Do not let a revenue target create clinical eligibility or turn an old treatment list into a promotional audience.

Any separate general marketing proposal needs its own assessment of the data source, sensitivity, consent and applicable communication rules. A contact list drawn from clinic records should not automatically be assumed suitable. The dormant-patient follow-up guide explains how to examine outstanding care obligations before deciding whether contact is appropriate.

Complete the impact assessment before the processing design is fixed

Article 25 of the implementing regulation requires a documented impact assessment in specified circumstances, including processing sensitive data. For a follow-up system handling health information, make the assessment part of design rather than a document added after the workflow and suppliers have already been chosen.

Consider specific harms: a message reaching a shared phone, a referral going to a similarly named department, an administrator seeing unrelated clinical history, a transcript remaining in a support ticket or a changed action executing under an old approval. Describe the preventive measure, the evidence that it works and the person responsible for any remaining risk.

The assessment should influence the build. It may lead to excluding audio retention, narrowing fields, changing a messaging route, limiting support access or keeping a step manual. Record why a measure is suitable and how it will be checked. Do not treat a vendor questionnaire with every box marked yes as a substitute for analysing the clinic's actual processing.

Verify proxy authority before sharing follow-up

A family contact is not automatically the authorised recipient for every part of a patient's care. Establish the legal and operational basis for a representative to act, the information they may receive and whether any restriction applies to the particular communication. Use the clinic's approved process to verify identity and authority rather than inferring them from a surname or a shared number.

Keep the authority record separate from the convenient contact record. The person who arranges transport may not have the same access as a legal representative. A change in capacity, relationship or patient preference may require the arrangement to be reassessed. The pediatric clinic workflow guide explores these recipient and responsibility questions in a specific setting without assuming one universal family arrangement.

Test a request to change the recipient while messages are already queued. The update should reach the affected communication process, and somebody should assess whether the queued content remains appropriate. Recording a new phone number on one screen is not enough if a separate task still holds the previous recipient and its old disclosure assumptions.

Make processor obligations specific enough to operate

The contract and instructions should identify the work the processor may perform, relevant data, permitted duration, subprocessors, security arrangements, incident notification and return or destruction arrangements. The published regulation contains processor-selection and health-data requirements. The clinic needs an agreement that corresponds to the deployed workflow, not only a general confidentiality statement.

Ask who can access prompts, transcripts, task records and logs during support. Determine whether access is routine or exceptional, how it is authorised and what evidence remains afterwards. A statement that data is encrypted does not answer whether a supplier's staff can view it through an application or diagnostic tool.

Define what happens when a supplier changes a model service, support location or subprocessor. The clinic should have a way to evaluate the effect on approved processing before the change reaches patient information. Keep an accountable internal owner for the relationship; outsourcing a technical task does not eliminate the clinic's own responsibilities.

Assess hosting and international access across the complete chain

Map primary processing, storage, backups, monitoring, remote administration and subcontracted services. A Saudi hosting location for the main application does not by itself establish where all data is processed or accessed. Conversely, avoid a blanket statement that the PDPL requires every category of personal data to remain in the Kingdom in every circumstance.

Evaluate any relevant transfer or disclosure outside Saudi Arabia under the applicable transfer rules and healthcare-sector requirements. Record the actual arrangement and evidence supporting it. The proposed clinic-system integration should be assessed alongside those arrangements, including diagnostic data that leaves through logs rather than through the main business interface.

Use an evidence request that names the data and activity: where a transcript is processed, where an approval log is backed up and where a support engineer may access a record. Answers about the supplier's headquarters or a generic cloud region are insufficient when they do not describe the proposed processing chain.

Set retention by information type and applicable obligation

Separate temporary capture data, proposed tasks, rejected drafts, approved administrative records, clinical records and audit evidence. They need not share one retention period. Establish a schedule based on purpose, applicable record obligations, legal holds and the clinic's documented governance. Do not invent a universal number of years for every clinic follow-up artifact.

Test what the system's deletion action actually removes. A screen may disappear while an export, support attachment, backup or processor copy remains. Specify how deletion or restriction instructions travel through the relevant chain, and how legitimate retention exceptions are handled without retaining unrelated information by default.

Provide a workable rights process with appropriate identity verification, ownership and tracking. A correction to contact information should reach the systems that will use it. A withdrawal of consent should be evaluated against the processing based on that consent; it does not automatically erase every record that must lawfully be retained or stop a different operation based on another valid basis.

Prepare for a wrong-recipient incident before it happens

Use a fictional exercise: an approved administrative update is sent to an outdated shared number. Identify who stops further messages, who checks the extent of disclosure, who preserves the evidence and who assesses the notification obligations. Avoid sending additional sensitive content to the same number while trying to explain the mistake.

Article 24 of the implementing regulation requires notification to the competent authority within 72 hours of awareness for breaches meeting its stated harm or rights conditions. It also addresses notifying affected individuals without undue delay where the relevant conditions apply. The incident process should enable that assessment and response; do not postpone it until a supplier has produced a polished investigation report.

The security design guide covers technical containment and access controls, while the follow-up audit trail supports reconstruction. Privacy, clinical and operational owners should coordinate their decisions so the response addresses both information exposure and any unresolved care-related work.

Turn the privacy decision into launch evidence

Before launch, assemble a concise record of the approved purposes and bases, data-flow map, impact assessment, role permissions, processor arrangements, transfer analysis where relevant, retention decisions, patient information and incident process. Determine whether a data protection officer is required under the applicable criteria and assign clear privacy responsibilities in all cases.

Verify the evidence in the intended environment: a restricted role should not see unrelated context, a changed contact should affect queued communication, and an amended purpose should trigger the required review. Use the current published legal text and relevant sector requirements; proposed consultation amendments are not a substitute for the rules in force.

The public Echo demonstration asks for fictional information and describes simulated follow-through. Its statement that audio is not saved does not establish the handling of transcripts, prompts, logs or a future deployment. Book a walkthrough with a non-identifying workflow and data-flow question, then resolve the deployment-specific privacy evidence before using real patient information.