Using AI in a Dubai clinic: what DHA rules allow, and what they require

AI strategy & adoption

Clinic owners in Dubai ask us the same question every month: can we use AI for bookings, reminders, insurance pre-authorisation and doctors' notes without falling foul of the Dubai Health Authority (DHA)? The answer is yes, and the rules that shape the project are clearer than most people expect. Four requirements do most of the work: Arabic for anything the patient sees, a licensed clinician's signature on anything clinical, health data that stays inside the UAE, and audit logs you can produce when an inspector asks. This piece sets out what the documents actually say, picks the three uses worth starting with, and lists the questions to put to any vendor.

The rulebook is clearer than you think

There is no single "DHA AI licence" for private clinics. What exists is a small stack of documents that, read together, tell you exactly where the lines are. DHA takes AI seriously on its own side of the fence: it has a Chief Artificial Intelligence Officer, Fatima Al Khaja, and during Dubai AI Week in April 2025 it launched an AI training programme covering everything from an executive diploma with ESCP Business School to prompt-engineering training, while encouraging private healthcare facilities to participate. A month later it put AI-driven privacy monitoring, Imprivata's Patient Privacy Intelligence, inside the NABIDH platform itself, to detect unauthorised access to patient records in real time.

Here is the stack, and what each layer means for your project:

A note on scope, because it matters: the DHA AI Policy formally governs how DHA itself and its vendors use AI, not a licensing regime for private clinics. But it is the regulator's own standard, it is unusually specific, and it is what any vendor building for you will be measured against the day a private-sector equivalent is formalised. Treat it as your design brief.

Four rules that shape any clinic AI project

Rule 1: Arabic for anything the patient sees

The DHA AI Policy, Article 8.3, requires patient-facing AI interfaces to display information in Arabic, with support for text recognition and cultural context alignment. The Telehealth Standards go further for anything remotely clinical: physician credentials must be available in both Arabic and English (Appendix 5.2.5), and any information a patient needs before a virtual consultation must be provided in both languages (Appendix 5.2.6).

What this means in practice: your WhatsApp booking agent defaults to the patient's language, with proper Arabic (right-to-left rendering, formal register, correct transliteration of clinic names) as a first-class output, not a machine-translated afterthought. Test it with Arabic-speaking front-desk staff before any patient sees it. A 2026 Dubai practitioner guide makes the same point bluntly: patient-facing AI in Dubai requires Arabic support, and generic translation is where most implementations fail.

Rule 2: AI clinical text is a draft until a clinician signs it

Article 8.4 of the DHA AI Policy is unambiguous: any AI-generated clinical content must be clearly labelled, and reviewed and verified by a qualified licensed healthcare professional. Article 3.1 reinforces the point: AI is a supportive tool, and liability does not transfer to it.

This is the rule that makes the "AI doctor's notes" project safe if you design it correctly. The note the model drafts is a draft. It sits in a pending_signoff state, with the model name, prompt version and reviewer recorded. It does not sync to NABIDH, does not go to an insurer, and does not appear in the patient's file until a licensed clinician has opened it, corrected it and signed it. That workflow is not a burden; it is the regulatory argument for the use case.

Rule 3: health data does not leave the UAE

Two layers here. Article 8.7 of the DHA AI Policy requires that all AI inputs and outputs, including patient data, be stored and processed exclusively within UAE data centres. Above that sits Federal Law No. 2 of 2019: Article 13 bars health data related to services provided inside the UAE from being stored, processed, generated or transferred outside the country except by resolution of the health authority in coordination with the Ministry. Article 24 sets the penalty for breaching Article 13 at AED 500,000 to 700,000, and Article 20 sets minimum record retention at 25 years. The Telehealth Standards add the Dubai-specific layer: the telehealth platform must be capable of storing all patient records on Dubai-based servers (Appendix 7.1.6).

The practical consequence for your architecture: nothing carrying a patient name, Emirates ID, diagnosis or lab result goes to a hosted model endpoint outside the UAE. Not in the prompt, not in the logs, not in the vendor's training pipeline. Ask for region pinning at the API level, and ask what happens to prompts after processing.

Rule 4: log everything, and keep it for the auditor

The NABIDH Audit Policy requires audit logs to be retained for 3 years and reviewed at least quarterly to detect improper use of patient information, with external audits at least annually. The log must be able to answer specific questions: which users accessed a given patient's record, which patients' data a given user accessed, every break-glass event, and every access to data marked sensitive. DHA audits the NABIDH platform and its vendors annually, and since April 2025 the platform itself watches for anomalous access patterns with AI.

Your AI systems should sit inside the same logging discipline. Log the generation event (case ID, model, reviewer, sign-off state), the consent event, and every export.

Two governance notes round this out. Article 4.2 of the AI Policy is a "default deny": AI tools are denied by default until a compliance assessment is completed, so keep a one-page assessment on file for every tool you switch on, including the ones your doctors install themselves. And Article 8.2 requires explicit patient consent where patient data is shared for AI-driven diagnostics or telehealth, explaining how the AI will be used, its risks and its limitations. Your intake form gets a new paragraph.

The three uses worth starting with

Not every AI use case carries the same regulatory weight. Here are the three that pay for themselves fastest under these rules, in the order we recommend:

Start with reminders: lowest risk, and the numbers move immediately. Pre-authorisation is the strongest first pilot for a clinic with meaningful insurance volume: document-heavy, high-volume, financially significant, and it still allows human review before anything is submitted, which is how one Dubai healthcare vendor frames it in its published guidance on agentic AI for Dubai hospitals and clinics. Notes come third, once the audit trail and sign-off workflow are proven on lower-stakes work.

Worked example: pre-authorisation at a four-doctor clinic

Take a typical outpatient clinic: two GPs, two specialists, roughly 1,100 consultations a month. About 60 per cent of visits are insurance-covered, and on a typical outpatient mix (imaging, minor procedures, some referrals) around 160 cases a month need pre-authorisation.

1. Baseline. A revenue-cycle coordinator handles each pre-authorisation manually today: pulling the doctor's notes, attaching lab results, completing the insurer's form, checking the document list and chasing missing attachments. Assume 55 minutes of human work per request. That is 160 x 55 = roughly 147 hours a month, close to a full coordinator FTE.
2. With the agent. The agent assembles the packet: it reads the consult note and the requested procedure, checks that insurer's document requirements, verifies that the lab results and imaging reports are attached, and flags what is missing. The coordinator reviews and submits. Assume 15 minutes of human review per case, in the same range as the vendor scenario where preparation drops from up to 48 hours to around 15 minutes. That is 160 x 15 = 40 hours. About 107 hours a month released.
3. Value the time. Assume a coordinator at AED 12,000 a month, loaded at 1.4x for benefits and overhead, over roughly 170 working hours: about AED 100 an hour. 107 hours x AED 100 = AED 10,700 a month, or about AED 128,000 a year of recovered capacity.
4. Denials. Assume 12 per cent of submissions bounce today for documentation gaps: about 19 cases a month. If the agent's completeness checks cut that to 6 per cent, about 10, then 9 cases are saved. At 2.5 hours of rework each, that is another AED 2,250 a month. Each bounced case also delays a typical AED 1,200 reimbursement by about 30 days, so 9 cases is AED 10,800 of cash pulled forward.
5. Total. Around AED 13,000 a month in measurable time and rework, plus roughly AED 11,000 of reimbursement permanently one month earlier. A 2026 Dubai guide prices a focused single-workflow pilot in the market at roughly AED 150,000 to 300,000 for a proof of concept, so the measurable payback lands at 12 to 24 months, before you count the softer wins: patients who do not abandon procedures because approval took three days instead of a fortnight.
6. Layer on reminders. The same platform runs the reminders agent. At a 15 per cent no-show rate, 1,100 visits produce about 165 missed appointments a month. Recovering just 20 per cent of them, at an average AED 350 per visit, is 33 recovered visits: AED 11,550 a month, about AED 139,000 a year, from the lowest-risk use case on the list.

The agent never decides clinical necessity, never invents justification, and never submits anything. It gathers, sorts and checks; a human submits. That is what keeps it on the right side of Article 8.4.

An architecture that passes inspection

Two technical decisions carry most of the compliance load: where the model runs, and what you log.

Routing. Put a gateway in front of your models so that patient-identifiable traffic is pinned to UAE-hosted infrastructure and nothing else. Our FastLLM Proxy does exactly this: an OpenAI-compatible gateway with routing, budgets and access control in one place. The configuration principle, whatever gateway you use:

# Illustrative gateway policy: patient data never leaves the UAE zone
routes:
  - id: preauth-drafting
    match:
      header:
        x-data-class: phi          # set by the integration layer
    providers:
      - name: uae-selfhosted-llm
        endpoint: https://llm.clinic.internal/v1
        model: qwen2.5-14b-instruct  # UAE data centre, self-hosted
    fallback: reject                 # no external fallback for patient data, ever
    log: full                         # prompt + completion retained 3 years
    budget:
      monthly_usd: 400

  - id: marketing-copy
    match:
      header:
        x-data-class: public
    providers:
      - name: hosted-llm             # fine: no patient data on this route
    fallback: reject
    log: minimal

Audit records. Every AI generation tied to a patient case should produce a record an inspector can read:

{
  "event": "ai_generation",
  "workflow": "preauth_packet",
  "case_id": "OPD-2026-09127",
  "actor": "agent:preauth@clinic",
  "model": "uae-selfhosted/qwen2.5-14b",
  "output_status": "draft_pending_signoff",
  "reviewer": "revenue.cycle@clinic",
  "consent_ref": "CN-2026-04-118",
  "timestamp": "2026-10-26T08:14:22+04:00"
}

Add the two labels the rules ask for: AI-generated clinical content carries a visible "AI draft, pending clinician review" tag until it is signed, and consent is captured per Article 8.2 with an explanation of how the AI is used.

What to ask a vendor

Print this section and take it to your next vendor meeting:

1. Where, at the API level, is our data processed? Give us the region pinning, not the marketing page.
2. Do you train on our prompts or outputs? Where do they go after processing, and for how long?
3. Show us the Arabic output. Not a translation API demo: the actual booking and reminder flows, reviewed by native speakers, with right-to-left rendering in WhatsApp.
4. How does the sign-off workflow work? Can a draft reach a patient file, NABIDH or an insurer without a licensed clinician?
5. Export your audit logs in a format we can hand to an auditor: who accessed which record, when, and what changed.
6. What happens when you change the model or prompt version? Will you notify us, and can we pin versions?
7. Which of your deployments have been through a DHA or NABIDH-related audit? Can we speak to a reference?
8. Will you sign a data processing agreement with UAE data residency, a breach notification commitment, and alignment with our 25-year record retention obligations?

If a vendor cannot answer 1, 4 or 8 without checking with someone, they are not ready for a Dubai clinic.

What to do next

Pick one workflow, not four. For most clinics that is the reminders agent: low risk, quick to build, immediate numbers. In parallel, write the one-page compliance assessment per tool, add the AI paragraph to your intake consent, and set audit log retention to at least 3 years. Run a 4-week pilot with fixed baseline numbers (no-show rate, coordinator hours, denial rate), then expand to pre-authorisation and notes on the same platform and the same logs.

This is work we do with clinics in the UAE from our base in Dubai: our own team handles the consulting, the deployment and the support. If you want the architecture and the agents built on your infrastructure with these controls from day one, that is our AI engineering service. Start with one workflow, prove it, and let the audit trail you build there carry the next three.

https://www.azrty.com/blog/using-ai-in-a-dubai-clinic-what-dha-rules-allow-and-what-they-require

<a href="https://www.azrty.com/blog/using-ai-in-a-dubai-clinic-what-dha-rules-allow-and-what-they-require">Using AI in a Dubai clinic: what DHA rules allow, and what they require</a> (Azrty)