01
Executive thesis
Healthcare analytics carries a risk that ordinary website analytics does not: the fact that a person visited a particular page can itself reveal information about their health. A session on a fertility page, an oncology page or a mental health page is not neutral browsing data. Combined with an identifier, it becomes information about a specific person’s health status.
The Saudi Personal Data Protection Law defines health data as personal data related to an individual’s health status or the health services received. Google Analytics policies separately prohibit sending data that Google can recognise as personally identifiable or that reveals sensitive information. These two constraints operate independently, and satisfying one does not satisfy the other.
The failures are almost never deliberate. They are the accumulated by-product of a URL structure written for convenience, a form built without thinking about what the analytics tag captures, an event named after the thing the user did, and a session-recording tool switched on to see how the booking flow performs.
The decision this article supports is where to look. Most organizations have not audited their data flows and cannot say what is currently being sent.
02
What the official sources state
| Source | What the official text states | Where to verify |
|---|---|---|
| SDAIA, PDPL | Health data is defined as personal data related to an individual’s health status or the health services received | PDPL official English text |
| SDAIA, implementing regulations | Appropriate organizational, technical and administrative measures are required to protect health data | Implementing regulations |
| Google Analytics | Sending data that Google could recognise as personally identifiable, or that reveals sensitive information, is prohibited | Google Analytics policy |
| Google Analytics | Users must confirm that enhanced measurement does not collect personally identifiable information | Enhanced measurement guidance |
The Arabic legal text governs. Platform terms are contractual obligations enforced separately from law, and breaching them carries its own consequences including data deletion or account action.
03
Why healthcare analytics has elevated risk
Three properties distinguish it.
Page context is itself sensitive. In retail, knowing someone viewed a product reveals a preference. In healthcare, knowing someone viewed a specific condition page can reveal a health concern. The URL alone can be the disclosure.
Identifiers arrive through side doors. Nobody deliberately sends a patient’s name to analytics. It arrives because the booking confirmation page includes the name in the URL, or because a form field value gets captured by an automatically configured event, or because a session recording captured the screen with the field filled in.
The data leaves your control. Once transmitted to a third-party platform, the data is subject to that platform’s processing, retention and location. Recovering it is difficult, and in some configurations impossible without deleting an entire property.
The consequence is that healthcare analytics needs to be designed rather than enabled. Default configurations are built for general commerce, not for a context where the page name is health information.
04
What may become identifiable or sensitive data
Six categories to look for, in rough order of how often they appear.
Direct identifiers in URLs. Names, national ID numbers, medical record numbers, email addresses or phone numbers appearing in query strings or path segments, usually on confirmation or portal pages.
Health context in URLs. Page paths naming a condition, procedure or specialty, transmitted with a persistent identifier that can be linked across sessions.
Form field values. Captured deliberately through custom events, or inadvertently through automatic event configuration that reads input values.
Event and parameter names. An event named after a specific service, such as a booking event carrying the treatment type, transmits the health context into the analytics dataset by design.
Session recordings and heatmaps. These tools capture screen content by default. Without field masking, they record whatever the patient typed, including free-text symptom descriptions.
Audience and remarketing lists. A list built from visitors to a condition page is, in effect, a list of people associated with that condition. This is the one most likely to be built by marketing without any technical involvement, and it engages both privacy obligations and platform restrictions on health-based targeting.
05
Common leakage points
| Location | How the leak happens | What to check |
|---|---|---|
| Booking confirmation page | Patient name or reference passed in the query string | Full URL as transmitted to analytics |
| Portal or account URLs | Record number or ID in the path | URL patterns for authenticated pages |
| Search results pages | Patient’s own search terms in the query string, often symptoms | Internal site search parameter handling |
| Form submissions | Automatic event capture reading input values | Event parameters on form interaction events |
| Chat and messaging widgets | Free-text messages captured by third-party tools | Vendor data flow and retention terms |
| Session recording | Unmasked form fields and page content | Masking configuration, field by field |
| Server-side or offline uploads | Contact details uploaded to advertising platforms | What is uploaded, hashed or otherwise |
| Error pages and logs | Query strings preserved in error tracking | Error tracking configuration |
Internal site search deserves particular attention. A patient typing their symptoms into a site search box is producing exactly the kind of free-text health information that should never leave the organization, and site search tracking is enabled by default in most analytics configurations.
06
The Data-Minimization Map
The method inverts the usual approach. Rather than asking what could be collected, start from decisions.
Step 1. List the decisions. What decisions does the organization actually make using web data? Typically a small number: where to invest by service line, where the booking flow fails, which content produces enquiries.
Step 2. Derive the minimum data. For each decision, identify the least data that would support it. Most decisions need aggregate counts by page group and event, not individual-level detail.
Step 3. Inventory what is currently collected. Every tag, tool, event, parameter and audience. Include tools nobody owns any more.
Step 4. Compare. The gap between what supports a decision and what is collected is the reduction target. In most healthcare implementations this gap is large.
Step 5. Classify the remainder. For everything that survives, classify as: safe, sensitive-by-context or identifiable. Anything in the last two categories needs a control or removal.
Step 6. Apply controls. Redaction of identifiers before transmission, aggregation of condition-level pages into groups, masking in recording tools, removal of health-based audiences, or removal of the collection entirely.
The principle that resolves most arguments: a consent mechanism does not make every transfer appropriate. Consent may establish a lawful basis for a purpose, and it does not make it acceptable to send a patient’s name and diagnosis to a third-party advertising platform. The question is whether the transfer is necessary for a decision, not whether someone clicked accept.
07
Vendor, access and retention controls
Four controls beyond the data itself.
Vendor assessment. What each tool receives, where it processes, how long it retains and whether the contractual terms permit healthcare use. Tools added by a marketing team without review are the most common source of unassessed flows.
Access control. Who can view the analytics data and who can create audiences. Audience creation in particular should be a controlled action in a healthcare context.
Retention. Shorter retention reduces exposure. Default retention settings are usually longer than any decision requires.
Change control. New tags and tools should require privacy sign-off before deployment. Most leakage is introduced by a change, and change is continuous.
08
A healthcare tracking audit example
The following audit is illustrative. The findings are constructed to demonstrate the method. They are not measured, not sampled and not a DEMA benchmark.
Method. Load key pages in a browser with network inspection, submit a test booking with dummy data, then examine every outbound request: destination, payload, parameters. Repeat on mobile and in Arabic. Separately, review audience definitions in every advertising account.
Constructed findings.
| Finding | Category | Severity | Remediation |
|---|---|---|---|
| Booking confirmation URL contains the patient name | Direct identifier | High | Move to a static confirmation URL, strip parameters before transmission |
| Site search terms transmitted, including symptom text | Sensitive by context | High | Disable site search tracking or redact free text |
| Session recording capturing unmasked form fields | Direct identifier | High | Mask all inputs, verify by re-recording |
| Remarketing audience built from oncology page visitors | Health-based audience | High | Remove the audience, review all others |
| Booking event carries treatment type as a parameter | Sensitive by context | Medium | Aggregate to service group rather than specific treatment |
| Chat widget retaining transcripts with an unassessed vendor | Unassessed flow | Medium | Vendor assessment, retention limits or replacement |
| Analytics retention set to the maximum | Retention | Low | Reduce to the period a decision requires |
Reading it. The four high-severity findings share a cause: nobody examined what leaves the browser. Each was introduced by a reasonable person doing a reasonable thing, and none would be visible in a consent audit or a cookie policy review.
Decision implication. The remediation order is by severity of exposure, not by ease. Direct identifiers first, health-based audiences next, since the latter can usually be removed immediately at no cost to measurement.
Limitations. A browser-based audit finds client-side flows. Server-side transmissions, offline uploads and backend integrations require separate review with engineering, and are often where the more significant flows live.
09
Remediation priorities and governance
Fix now
- Inspect what the booking confirmation and portal URLs transmit, and strip identifiers
- Disable or redact site search tracking
- Mask all form fields in any session recording or heatmap tool
- Remove audiences built from condition, treatment or specialty page visits
- List every tag and tool currently deployed, including unowned ones
Build next
- Complete the decisions-to-data inventory and remove collection that supports no decision
- Assess every vendor for what it receives, where it processes and how long it retains
- Reduce retention to the shortest period supporting your decisions
- Require privacy sign-off for any new tag, tool or audience
Measure continuously
- Number of unassessed data flows, targeting zero
- Time between a tag deployment and privacy review
- Findings from a periodic re-audit, since configurations drift
- Proportion of collected fields traceable to a named decision
Attribution ambitions frequently drive the collection that creates this exposure, which is why the limits of attribution matter here. See Why Last-Click Attribution Misleads Healthcare Marketing Teams, and the wider triage process in Healthcare Marketing Compliance in Saudi Arabia: A Practical Operating Map.
10
Legal and technical limitations
What this article is. A description of technical failure modes in healthcare analytics, with an audit method and a data-minimisation process.
What it is not. It is not legal advice, not a compliance certification and not a determination that any configuration is lawful. It does not address every applicable obligation and does not cover backend clinical systems, which carry separate and more stringent requirements.
Method limitations. A client-side audit does not reveal server-side flows, offline uploads or backend integrations. Findings age quickly, since tags and tools change continuously. Testing in one language and on one device produces incomplete results.
Source limitations. The official Arabic legal text governs. Platform policies change without notice and must be re-verified. Compliance with a platform policy is not compliance with law, and the reverse also holds.
Where review is required. Implementation decisions require qualified privacy counsel and technical security review. Any flow involving clinical systems requires clinical information governance involvement.
Planned research. DEMA has scoped a healthcare analytics privacy audit in Saudi Arabia. It is not complete, and this article contains no findings from it.
Sources.
11
Do you know what your website sends?
Almost no healthcare organization can answer that from memory, and consent reviews do not reveal it. A Healthcare Growth Diagnosis inspects your live data flows across both languages and both device types, and reports what is leaving the browser. Legal determinations remain with your privacy counsel.
Request a Healthcare Growth Diagnosis