Telemedicine app development Dubai: two licences, not one

Telemedicine app development Dubai work fails the same test twice: the team builds a product that assumes one licence, and the Dubai Health Authority's standards describe two. A telehealth platform licence covers the technology that connects a clinic to a patient. Only a DHA-licensed health facility may deliver the care, and the platform is expressly forbidden from doing it.

That distinction is the whole post. Everything below is read from version 4 of the DHA Standards for Telehealth Services, document code DHA/HRS/HPSD/ST-14, issued on 26 September 2025, effective from 26 November 2025, with a scheduled revision date of 26 September 2030. We have not delivered a telehealth platform in the UAE. This is a close reading of the published rules, not a report of our own delivery, and we would rather say so than imply otherwise.

One practical note before the substance: as of 8 October 2026 that 94-page version 4 document is served from a URL path containing 012023. The path tells you nothing. Open the PDF and read the issue and effective dates in the page header of every page, because a 2023-looking link is currently the live 2025 standard.

What the platform licence actually permits

Standard Three is unusually blunt about it. Clause 7.8 limits the role of a telehealth platform to providing "a DHA-approved technological tool that connects licensed health facilities to patients", and then lists what a platform is "strictly prohibited" from doing.

• Clause 7.8.1: platforms "are not authorized to deliver direct clinical services to patients".
• Clause 7.8.2: the platform licence "does not grant the authority to operate as a healthcare provider".
• Clause 7.8.3: a platform is "not permitted to recruit or contact healthcare professionals for the purpose of delivering clinical services through the platform".

Read 7.8.3 slowly if your product plan has a two-sided marketplace in it. The supply-side growth motion that makes a consumer health app work elsewhere — sign up doctors, match them to demand — is the one activity the standard names and forbids. The clinicians come through a licensed facility, or they do not come.

That does not make the platform unregulated. Clause 7.6.2 requires every telehealth platform intended for internal or commercial use to be "assessed and approved by DHA through health facility licensing section prior to in-house implementation or go-to-market implementation". Approval before launch, not after. Clause 7.6.3 requires legal representation in Dubai holding a commercial or trade licence, 7.6.4 an assigned Business Technical Director, and 7.6.5 technical support with a defined escalation matrix covering response and resolution for both physicians and patients. Communication channels must be approved by the TDRA (7.6.6), and the platform itself must hold HIPAA and ISO 27001 certification, with HITRUST or SOC 2 required of some applicants (7.6.7).

Then clause 7.7, which is the one that reaches your roadmap: "Any changes to the telehealth platform's core functions, data management practices, or ownership must be reported and approved by DHA." Core functions and ownership. A regulator that must approve a change to your core functions is a regulator in your release process, and one that must approve a change of ownership is a regulator in your cap table.

Telemedicine app development Dubai: who holds which obligation

The standard's scope statement (2.1) is "telehealth services in DHA licensed health facilities", and 7.1 says the provision of telehealth "shall only be offered through a DHA licensed telehealth facility". The platform sits beside that, as one of four licence categories in 7.2.1: standalone telehealth centre, telehealth added to an existing facility, added booth, and telehealth platforms.

Obligation	Telehealth platform licence	DHA-licensed facility
Delivering care to a patient	Prohibited (7.8.1)	The only lawful route (7.1)
Approval before go-live	DHA assessment before in-house or go-to-market use (7.6.2)	Facility licensure under a telehealth category (7.2.1)
Engaging clinicians	May not recruit or contact them (7.8.3)	Employs and privileges them (8.2.1, 8.2.2)
Consent, records, 25-year retention	Builds the mechanism	Holds the duty (10.1, 11.6, 11.10)
Telehealth accreditation	Required, no window stated (5.2.1)	Within 24 months of licensure or renewal (5.2.2)
Ownership and function changes	Reported to and approved by DHA (7.7)	Facility licensing rules apply

The pattern is consistent: the facility owns the clinical duty, the platform owns the technical conditions under which that duty can be discharged, and DHA holds both to account separately. A vendor that reads its contract as "we supply software, compliance is the client's problem" has misread 7.6.2 and 7.7.

The 24-month accreditation clock, and whose clock it is

Clause 5.2.1 states that "accreditation is required for all telehealth services, both facilities and platforms". Clause 5.2.2 then gives the window, and gives it to one party only: DHA-licensed health facilities providing telehealth "shall obtain telehealth accreditation within a grace period of 24 months from the date of initial licensure or from the date of license renewal for existing facilities". The standard names Quality and Accreditation Institute, Emirates International Accreditation Center, Joint Commission International, URAC and NCQA as examples of accrediting bodies (5.3).

We read 5.2.1 and 5.2.2 together as requiring platform accreditation without stating a grace period for platforms, which is not the same as exempting them. That is our reading of the text, not a DHA statement, and it is worth a written question to the Health Regulation Sector before a contract fixes who pays for it. If your client's facility renewed its licence last month, you have a date: the accreditation evidence has to exist within 24 months of it, and an accreditation body will ask for audit logs, incident records and documented policies your software has to have been producing from day one. Retro-fitting that is the expensive version.

What a clinic is actually asking you to build

Once the licensing boundary is clear, the scope of the custom software build stops being a feature list and becomes a list of evidence the facility must be able to produce.

• Nabidh and EHR integration. The IT infrastructure "must have the capability to integrate with healthcare provider electronic health records (EHR) system", and the health records system "shall integrate with Nabidh" (7.9.1.e). Facilities must also follow the DHA Guidelines for Electronic Medical Record in Health Facilities (11.3).
• An encounter record with named fields. Clause 11.6 requires each telehealth encounter to document the type of service and the technologies or platforms used; the name, professional licence number and role of every professional involved; the date, time and geographic locations of the originating and, where applicable, receiving site; and confirmation that consent, confidentiality and data security requirements were met. Those are schema decisions, and geographic location of both sites is the one teams forget.
• Twenty-five years of retention. Telehealth information, communication and technology data must be retained securely "for a minimum period of twenty-five (25) years from the date of the last health encounter" (11.10). At that horizon, retention is a disaster-recovery and durability question long before it is a storage-cost question.
• Auditable consent. Electronic consent is acceptable provided the requirements for manual consent and patient identification are met and "the obtained consent can be audited" (10.1.1). Identification needs at least three identifiers from full name, date of birth, Emirates ID number, health record number or personal contact number (10.2.1).
• Enforced exclusions. Telehealth excludes emergency cases needing immediate life-threatening intervention and the prescribing of narcotic, controlled or semi-controlled medication (4.2). Those are product rules — a prescribing flow that can emit a controlled substance is a defect, not a configuration choice.
• A public service page that is part of the product. Clause 8.4.1 lists what must be publicly available online: the catalogue of services, the limitations of telehealth especially for emergencies, the licensure and qualifications of privileged physicians, response timeframes, complaint filing, and all service fees, payment options and the refund policy.

Hosting is the short part here, because it is a post of its own. Data centres must be at least Tier 3 certified, data must sit with a cloud service provider certified by the Dubai Electronic Security Centre inside the UAE, and storing, developing or transferring health data outside the country is not permitted except in the cases in Article 2 of Ministerial Decision No. 51 of 2021 (7.6.7, and 8.2.5.d for the facility's equivalent duty). If you are weighing which workloads can leave the region at all, our note on what actually stays local in UAE deployments covers the same ground for AI services.

Version 4 also added consent for Ambient AI tools, and clause 5.4 subjects telehealth providers using AI, "including but not limited to Ambient AI", to requirements aligned with DHA's artificial intelligence policy. If you are putting a scribe or a triage model in the call, that is a consent surface and a documented policy, which is the same discipline the Dubai agentic AI mandate asks of private-sector systems.

Where DHA's own documents disagree

Two disagreements are worth knowing before you build reporting.

On frequency: clause 19.1 of the standard says key performance indicators "shall be captured by Telehealth providers and reported to HRS each quarter", and 19.2 points to a separate guideline. That guideline — Guidelines for Reporting Telehealth KPIs, version 3, code DHA/HRS/HPSD/GU-15, issued 3 July 2025 and effective 3 January 2026 — lists among its key updates that "reporting frequency is updated to annual", with submission between 5 and 14 January covering the full year. The standard was issued in September 2025 and still says quarterly. Build the pipeline so the facility can submit annually in that January window and still produce quarterly cuts on request; that is cheap if you design for it and painful if you do not.

On licence categories: the DHA Telehealth Policy, code DHA/HRS/HPSD/HP-20, issue 1, effective 22 August 2021, lists the licensable areas as call centre, telebooth and add-on services, while requiring that platforms be licensed. The 2025 standard's list (7.2.1) is different: standalone telehealth centre, add-on, added booth and telehealth platforms. The policy carries a stated revision date of 16 August 2026, which has now passed, and the version published at DHA's URL is still issue 1 as of 8 October 2026. Where two primary documents differ, the later and more specific one is the safer build target, and the category your client is actually licensed under is a question for their licence certificate rather than for either PDF.

What the facility must instrument for those KPIs is concrete: percentage of teleconsultations referred to in-person care, urgent and emergency referrals, new mental health and new telehealth encounters, share of outpatient visits delivered through telehealth, medication and antibiotic prescribing rates, and patient and provider satisfaction. The background data goes further — the share of calls from outside Dubai split by other emirates, international callers and medical tourists, distribution by ICD-10 disease area, insurance coverage, Emirati share and four age bands. If your encounter model has no ICD-10 field and no caller-origin field, those numbers cannot be produced at year end.

Where this does not apply

The strongest argument against all of this, and we have heard versions of it, is that licensing is the client's problem: a software vendor ships a white-label platform, the clinic holds the licence, and the regulator never looks at the vendor. It is a reasonable instinct and it is wrong under this standard. Clause 7.6.2 puts DHA assessment in front of your go-to-market, 7.6.4 puts a named Business Technical Director on your org chart, 7.6.5 puts response and resolution commitments in your support contract, and 7.7 puts DHA inside changes to your core functions and your ownership. You can decline to hold the platform licence yourself — but then someone must, and the contract should say who, in writing, before the first sprint.

The standard also binds only where DHA binds. Its scope is telehealth in DHA-licensed facilities, and 5.1.2 tells providers continuing care to patients outside the Emirate of Dubai to comply with the regulatory requirements of the respective jurisdiction. A product scoped to another emirate is answering to another regulator, and nothing above transfers automatically. The same applies if what you are building is not telehealth under this document at all: platforms used for in-person, face-to-face consultation are excluded by 4.2.3, so a scheduling or intake tool for a physical clinic is a different conversation.

Before you price the work, settle three things on paper with the clinic: which party applies for and holds the telehealth platform approval under 7.6.2, when their facility's 24-month accreditation window started, and who submits the KPI return in January. Those answers change the scope more than any feature in the backlog. If you want to see how we work and what we do and do not claim in this market, our Dubai engineering practice page is the honest version: no UAE healthcare delivery behind us, and a reading of the rules we are willing to show you.