← Sandbox

UAE Compliance Checklist

Worked example · not legal advice

UAE Legal Compliance Checklist

For the PHI De-Identification Sandbox, against:

Read this before anything else

This is not legal advice, and it does not certify anything as compliant. This checklist exists to demonstrate, concretely, how this sandbox's de-identification and masking design maps onto UAE law — it is a worked example, not a compliance certificate, and no real patient data should be processed on the strength of it.

uaelegislation.gov.ae blocks automated access (every direct fetch returns HTTP 403), so the first version of this document was built from public secondary legal sources. The project owner subsequently supplied the official PDF text of both laws directly, and this version is rebuilt against that primary text — every citation below is a specific article, quoted or closely paraphrased from docs/legal/, not a secondary source's summary of one. Where the primary text corrected something the secondary-source version got wrong, that correction is called out explicitly rather than silently fixed, because the mistake itself is informative: a superficial reading of secondary sources merged two distinct legal provisions, and the merge would have led toward the wrong action.

  • 🟢 Confirmed — verified against the primary statutory text in docs/legal/.
  • 🟡 Reported — stated only by a secondary source; the primary text is silent on it (usually because it's deferred to an Executive Regulation or a separate Cabinet decision not yet reviewed).
  • 🔴 Unverified / gap — checked against the primary text and genuinely absent. Not a research gap — the statute itself doesn't say.

Every 🔴 item, and every 🟢 one with real money or criminal liability attached, still needs sign-off from UAE-licensed data protection / health-law counsel before this system ever touches a real patient's data. Primary statutory text answers "what does the law say"; it does not answer "how will a regulator apply it to this specific product," which is what counsel is for. Treat that as a hard gate, the same way CLAUDE.md's Golden Rule 3 treats the redactor itself: defense-in-depth, never a guarantee.

One correction to the original request that changes the shape of this whole document: the request was for a checklist against "1209, 1972, and UAE PDPL LAWS" as if those were three things. They're two. Legislation 1972 is the PDPL (Federal Decree-Law No. 45 of 2021) — there is no separate third law. This is written as a two-law checklist.

The headline finding

🟢 The PDPL explicitly excludes health data from its own scope where sector-specific legislation already covers it — and it does. PDPL Article 2(2)(e), verbatim: "Provisions of this Decree by Law shall not apply to... Personal Health Data that has legislation regulating its protection and processing." Federal Law No. 2/2019 is exactly that legislation. So for this project, the two laws are not parallel obligations to satisfy independently. Federal Law No. 2/2019 is the controlling law for anything this tool touches. The PDPL becomes relevant only for personal data this system might handle that isn't health data — e.g., an operator's login, an audit-log entry naming a human reviewer, in a future multi-user deployment.

This redirects where compliance effort should go: not "satisfy PDPL's consent/DPO/breach-notification machinery for patient data," but "satisfy the Health Data Law's rules" — data localization (Article 13), a 25-year retention floor (Article 20), and written patient approval before circulating patient information (Article 16) — which read as simpler on paper and are harder to satisfy with the current architecture (see B.1 below).

Section A — Does this even apply today?

# Item Status
A.1 The sandbox processes synthetic / public-sample data only — never real PHI (CLAUDE.md Golden Rule 1; enforced in code by src/ingest.py's provenance guard, which refuses MIMIC/i2b2/n2c2/eICU by filename). 🟢 On this basis, Federal Law 2/2019 does not yet apply operationally — no real patient health data is processed.
A.2 Whether a public-sample dataset (e.g., mtsamples — real US clinical transcriptions with synthetic identifiers injected) could itself be construed as "health data" under UAE law regardless of the patients' nationality or location. 🔴 Unverified. The Health Data Law's Article 1 definition of "Health Information" is content-based (health data "processed... characterised by the health feature") with no nationality or location qualifier. Ask counsel before treating mtsamples-derived output as automatically out of scope.
A.3 This checklist is the working content of the "governance promotion gate" CLAUDE.md already names as the boundary between prototype and real-PHI use. Keep it versioned alongside that gate's approval packet, not as a one-off document. —

Section B — Federal Law No. 2 of 2019 (the controlling law)

# Requirement Confidence Current sandbox state Action before real PHI
B.1 Data localization — Article (13). "It is not permissible to store, process, generate or transform the health data and information outside State — which are related to the health services provided inside State — except in the case where a resolution is issued from the Health Authority in coordination with the Ministry." 🟢 primary text The gateway (src/gateway.py) routes every model call through OpenRouter, which routes to US-hosted providers — including for today's synthetic-data calls. Vault and reports sit on whatever machine runs the app, jurisdiction unspecified. The single biggest architecture change needed. Before real PHI: point the gateway at a UAE-region model endpoint (e.g., Azure OpenAI in a UAE region, or a self-hosted model), not OpenRouter's default routing. Host the vault and reports on UAE-based infrastructure. CLAUDE.md's prototype→production table already says "Azure OpenAI via Private Link" — it needs "UAE region" made explicit, because Private Link controls the network path, not the physical location of the compute.
B.2 The Article (13) exception is narrow: a Health-Authority resolution issued in coordination with the Ministry — full stop. 🟢 primary text — correction from the prior version No transfer mechanism exists today beyond "don't use real data." The prior version of this checklist wrongly listed five exceptions here (research, judicial request, insurance verification, public-health emergency, health-authority inspection) as if they excused cross-border storage/processing under Article (13). They don't — those five are Article (16)'s exceptions, and Article (16) governs something else entirely: circulating/disclosing patient information without written consent, not where the data is stored. Do not rely on "this is de-identified research" as an excuse to send data to a non-UAE model — that reasoning has no support in Article (13)'s text. The only lawful path is a Health-Authority resolution, obtained in writing, before relying on it.
B.3 Whether de-identified output still counts as "health data." 🔴 checked against primary text — genuinely absent, not just unresearched This tool deliberately preserves clinical content — vitals, diagnosis, treatment, labs — while removing only identity, because that's the entire value proposition (HIPAA Safe Harbor exits "PHI" status this way). Article (1)'s definition of "Health Information" is content-based ("processed... characterised by the health feature... related to... the beneficiary from the health services") with no identity-based exemption anywhere in the 31 articles — confirmed by reading the full text, not inferred from its absence in a secondary source. Do not assume a Safe-Harbor-redacted note is unregulated data in a UAE context. Get explicit written confirmation from counsel or the health authority before representing it that way to anyone — a partner, a regulator, or this project's own board.
B.4 Retention — Article (20)(1)(A). "The keeping period shall not be less than (25) twenty-five years from the last date of the health procedure of the person concerned." 🟢 primary text No retention policy exists; the pipeline treats files as ephemeral, and src/vault.py's forget() deletes a document's mapping outright. Once real data is involved, forget() must not be used to delete the operative health record before the 25-year floor — early deletion may itself violate the law. Before production, split the concept into two distinct actions: "revoke re-identification capability" (burn the pseudonym key, keep the record) vs. "delete the record" (governed by the 25-year floor, not by this tool).
B.5 Definition of health data — Article (1). "Health Information": processed health data with meaning, characterised by the health feature, related to health/insurance establishments or the beneficiary of health services. 🟢 primary text — This is a content-type definition, not an identifier list. It directly informs B.3: content this tool is designed to preserve (labs, diagnosis) sits inside this definition even after every identifier is stripped.
B.6 Confidentiality and consent — Article (16). Whoever circulates patient information must keep it confidential and not use it except for health purposes without written approval from the patient, except: (1) insurance/funding-authority verification of financial entitlements; (2) scientific/clinical research where patient identity is not disclosed, observing research ethics; (3) preventive/curative public-health measures, or protecting the patient/others' health and safety; (4) competent judicial authority request; (5) Health Authority request for monitoring, inspection, or public health. 🟢 primary text — note the bar is written approval, not merely "explicit consent" No consent-capture mechanism exists (no real patient exists to consent). Before production: require documented, written patient consent, or a confirmed Article (16) exception, as a precondition to the LLM contextual pass and the AI-analysis feature being invoked on any real-patient note. If relying on exception (2) — the closest fit for the AI-analysis use case — note it requires patient identity to not be disclosed and observance of research ethics/rules; this governs disclosure, and is separate from the Article (13) storage question in B.1/B.2.
B.7 Security obligations — Article (4). Confidentiality (no unpermitted circulation); validity/credibility (protection from unauthorised damage, amendment, alteration, deletion, addition); availability to authorised parties. 🟢 primary text HTTPS in transit ✓. Vault encrypted at rest (Fernet/AES-128-CBC) ✓ — but key management is a known weak point (0600 file next to the data, no KMS/HSM, no separation of duties — already flagged in docs/SHOWCASE.md §7). No staff training (Article 19 is a Health Authority obligation, not this tool's) or audit cadence exists yet. Before production: real key management (KMS/HSM), and a scheduled compliance-audit cadence.
B.8 Free zones are explicitly in scope — Article (2). "This Law shall apply to all methods and uses of the information and communication technology in the areas of health in State, including the free zones." 🟢 primary text — new finding, wasn't in the prior version — Contrast with the PDPL (C.1 below), which excludes free-zone entities with their own data-protection law. Operating this system from DIFC or ADGM does not exempt it from the Health Data Law the way it might exempt general personal data from the PDPL. Don't assume a free-zone entity structure is an escape hatch here.
B.9 Emirates ID linkage — Article (21). The Health Authority and Relevant Entity must prove the [Emirates] ID number in all health transactions, records and files, except emergencies or other Ministerial-resolution-specified cases. 🟢 primary text — new finding Not applicable — synthetic notes have no real Emirates ID. If this system is ever wired into a real health-record workflow, records need Emirates ID linkage per this Article. Worth flagging to whoever designs the production data model; not something the redaction pipeline itself needs to solve.
B.10 Penalties — two separate tracks, not one figure. Article (24): violating Article (13) specifically (unauthorised cross-border storage/processing) — a penalty of AED 500,000 to AED 700,000. Article (25): broader disciplinary sanctions the Health Authority may impose on establishments violating the Law/its Executive Regulation/applying resolutions generally — written notice, written warning, a penalty of AED 1,000 to AED 1,000,000, licence suspension (up to 6 months), or licence cancellation. 🟢 primary text — correction from the prior version, which conflated these into one vague "up to AED 1,000,000" figure — The prior "up to AED 1M" statement wasn't wrong, but it hid that there are two different tracks with two different triggers, and that the specific penalty for the localization violation this project is most exposed to (B.1/B.2) is the AED 500k–700k Article (24) track, not the milder-sounding disciplinary ladder. Confirm current amounts with counsel — these are the amounts stated in the primary text as enacted in 2019; verify no amendment has changed them since.
B.11 Central-system authorization — Article (14). No person may use the Ministry's central health-data-exchange system without Health Authority/Relevant Entity authorization. 🟢 primary text Not applicable — this sandbox is not connected to the Ministry's central system. Only becomes relevant if this tool is ever integrated with MOHAP's central system directly; a standalone de-identification tool used by a provider is not, on this reading, itself "the central system." Confirm with counsel if integration is ever planned.
B.12 Licensing for health-IT / cloud / AI service providers generally (as distinct from B.11's central-system-specific authorization). 🔴 checked against primary text — genuinely absent — The 31 articles contain no general health-IT/cloud/AI vendor licensing regime — only central-system authorization (B.11) and health-advertising licensing (Article 17, not relevant here). Broader facility/vendor licensing likely lives in emirate-level regulation (DoH Abu Dhabi, DHA Dubai) outside this federal ICT law's text. Confirm with the relevant emirate health authority before deployment — absence from this statute doesn't mean absence everywhere.

Section C — PDPL / Federal Decree-Law No. 45 of 2021 (relevant only outside the health-data carve-out)

# Requirement Confidence Relevance here
C.1 Scope exclusions — Article (2)(2). Government data; governmental entities processing personal data; data held by security/judicial authorities; personal-use processing; health data governed by sector legislation (2)(e); banking/credit data with own legislation; free-zone entities with their own data-protection law (DIFC, ADGM). 🟢 primary text Confirms the headline finding, now to the exact clause. If this org is based in or operates from DIFC or ADGM, that free zone's law governs instead of PDPL for non-health data — confirm which regime actually applies before going further down this section. Note the asymmetry with B.8: the health law explicitly includes free zones; the PDPL explicitly excludes them.
C.2 Sensitive personal data — Article (1). Includes data revealing "health and physical, psychological, mental, genetic or sexual condition, including information related to the provision of healthcare services... which reveals his/her health status." 🟢 primary text Health data is named as sensitive here even though its regulation is deferred to Section B. Useful as an interpretive baseline for how seriously the sector law is meant to be enforced, not as a directly binding rule for this tool.
C.3 Consent standard — Article (6). Controller bears the burden of proving consent; consent must be clear, simple, unambiguous, easily accessible (written or electronic); withdrawal must be easy and doesn't retroactively invalidate prior processing. 🟢 primary text Applies to any non-health personal data this system might handle — e.g., an operator account in a future multi-user build. Not applicable to patient health data itself (carved out to Section B, where the bar is Article 16's higher written approval standard).
C.4 Right to object to automated decision-making — Article (18). Data Subject may object to decisions from automated processing/profiling with legal or adverse effect, subject to narrow exceptions; the Controller must include a human element in reviewing such decisions at the Data Subject's request (Article 18(4)). 🟢 primary text This system's "human review stays in the pipeline" posture (CLAUDE.md Golden Rule 3) satisfies Article 18(4) by design, precisely — worth stating this alignment explicitly in any compliance filing rather than leaving it implicit, even though health data itself sits outside PDPL's scope.
C.5 Cross-border transfer — Articles (22)–(23). To an "adequate" jurisdiction (its own data-protection legislation + enforcement authority, or a bilateral/multilateral agreement with the UAE) with Bureau approval (Art 22); otherwise via a DbL-equivalent contract, explicit consent (not contradicting UAE public/security interest), legal-claim necessity, contract necessity, international judicial cooperation, or public interest (Art 23). 🟢 primary text If any non-health personal data is ever sent to OpenRouter/US providers, confirm current adequacy status for the US under Article 22, or rely on one of Article 23's mechanisms (an SCC-equivalent contract or explicit consent are the most realistic fits).
C.6 DPO appointment — Article (10). Required where processing poses high risk (new tech / data volume), involves systematic/comprehensive assessment of sensitive data (including profiling/automated processing), or large-volume sensitive-data processing. 🟢 primary text Health data is carved out, but if the organization's overall processing (this tool plus everything else it runs) amounts to large-scale sensitive-data processing in aggregate, a DPO may still be warranted. Needs a formal applicability assessment, not a guess.
C.7 Breach notification — Article (9). Controller notifies the Bureau "at the time it becomes aware" of a breach, with required accompanying detail (nature, DPO contact, effects, corrective measures, documentation); must also notify the Data Subject if privacy/confidentiality/security is prejudiced. Exact timing/manner is left to the Executive Regulations (Article 28) — not stated in the Decree by Law itself. 🟢 primary text for the obligation; 🟡 for the exact timeline (deferred, not yet reviewed) Build the incident-response runbook now, before real PHI exists to breach. Note a genuine strength: the gateway's metadata-only logging (reports/gateway_log.jsonl) means a leaked log carries no PHI — this materially limits breach blast radius and is worth stating affirmatively in any compliance filing.
C.8 Penalties — Article (26). Amounts are not stated in the Decree by Law itself — deferred entirely to a separate Council of Ministers decision, distinct from the general Executive Regulations under Article (28). Two different follow-on instruments to track down, not one. 🟢 for the deferral mechanism (confirmed in primary text); 🔴 for the actual figures Verify both instruments' current status directly with the UAE Data Office before relying on any figure quoted elsewhere.
C.9 Pseudonymisation is a named, defined mechanism — Article (1), (7)(2), (20)(1)(a). Defined in Article 1 as processing such that data "cannot be associated/attributed to the Data Subject without additional information... kept independently and securely" — and named explicitly as a required-consideration security measure in Articles 7(2) and 20(1)(a) (alongside encryption). 🟢 primary text — new finding, and a genuine strength worth citing precisely src/vault.py's design — numbered tokens ([NAME_1]) with a separately-stored, encrypted key/mapping — matches this statutory definition of Pseudonymisation almost exactly. Even though health data sits outside PDPL's scope, this is a defensible, citable alignment: the vault isn't just "encryption," it's the specific mechanism this law names and requires consideration of. Worth stating in any compliance filing, with the article citation.
C.10 DPIA — Article (21). Required before processing using high-risk new technology, especially systematic/automated assessment (including profiling) with legal/serious impact, or large-volume sensitive-data processing. Must cover: description/purpose, necessity/proportionality, risk evaluation, mitigation measures. 🟢 primary text CLAUDE.md's own language — "the governance promotion gate (DPIA + approval)" — already mirrors this Article's structure. That wasn't a coincidence worth losing: the project's internal gate concept is effectively modelled on PDPL Article 21, even though the article itself doesn't bind health data. Keep that alignment when this checklist (Section A.3) becomes the promotion gate's working document.

Section D — Architecture actions (tie back to this repo)

  • Route any real-data model calls through a UAE-region endpoint (Azure OpenAI UAE North/Central, or self-hosted) — not OpenRouter's default routing. (B.1)
  • Host the vault and reports on UAE-based infrastructure once real data is involved. (B.1)
  • Extend the gateway's data-class gate: keep "real" refused by default (as it is today — src/gateway.py's assert_transmittable), and add an explicit real_uae_approved class gated on confirmed UAE-region routing, rather than ever relaxing today's blanket refusal. (B.1, B.2)
  • Get written confirmation on the B.3 question before ever describing redacted output as "no longer regulated" in a UAE context.
  • Do not rely on "this is de-identified" as an Article (13) cross-border-storage exception — that reasoning has no textual support; the only exception is a written Health-Authority resolution. (B.2)
  • Split Vault.forget() into "revoke re-identification" vs. "delete the record" before it is ever used against real data. (B.4)
  • Build a written-consent (or confirmed Article 16 exception) precondition gating the LLM contextual pass and AI-analysis features. (B.6)
  • Move vault key management to a KMS/HSM with separation of duties before production. (B.7 — already flagged in docs/SHOWCASE.md §7)
  • Retain UAE-licensed data protection / health-law counsel to close every 🔴 above, confirm the current Cabinet Decision penalty schedules for both laws (Article 26 PDPL, and any amendment to Articles 24/25 of the health law), and confirm licensing requirements for deployment inside a real healthcare provider. (B.12)
  • Do not represent this tool as "UAE-law compliant" to the board, a partner, or a regulator until counsel signs off — same posture as CLAUDE.md Golden Rule 3 toward the redactor itself.

Section E — Strengths already in place, worth carrying into the compliance file

  • The gateway's default-deny data-class gate (refuses anything not synthetic/public_sample/operational, checked before the API-key check) is exactly the right control shape to extend for UAE localization — it needs a new class added, not a new mechanism built.
  • Metadata-only gateway logging limits breach blast radius by construction — directly supports B.7 and C.7.
  • The vault's pseudonymisation design matches PDPL's own Article 1/7(2)/20(1)(a) definition of the mechanism, precisely — a citable alignment, not just a generic "we encrypt things" claim. (C.9)
  • The synthetic-only prototype scope means zero current exposure — everything above is about the promotion gate, not today's operation.
  • Human-review-stays-in-the-loop is a design decision, not an afterthought, and it satisfies PDPL Article 18(4)'s human-element requirement by construction, even though health data sits outside PDPL's scope. (C.4)
  • CLAUDE.md's own "DPIA + approval" promotion-gate language already mirrors PDPL Article 21's DPIA structure. (C.10)

What this demonstrates, and what it doesn't

This checklist — like the rest of the sandbox — is built to demonstrate the mechanics of redaction and masking against a real, cited legal backdrop, not to certify this system, or any system, as legally compliant. A working example of "here is how a de-identification and masking pipeline maps onto a specific jurisdiction's law, article by article" is the useful artifact; "this tool is UAE-compliant" is a claim only counsel and the relevant regulator can make, and neither this document nor the software it describes makes it.

Sources

Primary sources (authoritative for every citation above):

Referenced but not independently fetched/verified — still open:

  • Federal Law 2/2019's Executive Regulation (Article 29) — reported elsewhere as Cabinet Decision No. 32/2020; not reviewed here.
  • PDPL's Executive Regulations (Article 28) and its separate administrative-penalties decision (Article 26) — not reviewed here; both were due within 6 months of the Decree by Law's 20 September 2021 promulgation, so both should exist by now — confirm current text and status with the UAE Data Office.