NABIDH, Dubai's health information exchange: what DHA's standards ask of software

The short answer

NABIDH is the Dubai Health Authority’s health information exchange, connecting public and private healthcare facilities in Dubai.¹ DHA’s interoperability standard applies to all DHA-licensed health facilities, recommends HL7 v2 for submitting and accessing data, and says systems should also support FHIR and IHE profiles.¹ DHA’s consent standard requires recorded patient consent for access to health information through other systems, with a break-the-glass exception for emergencies³, and the NABIDH audit policy keeps audit logs for three years and reviews them at least quarterly.² This post summarises DHA’s published documents; check DHA for the latest versions before you build.

What NABIDH is

DHA defines NABIDH as “a health information exchange platform by the Dubai Health Authority that connects public and private healthcare facilities in Dubai to securely exchange trusted health information”.¹ Practically, that means a facility’s HIS sends admissions, results, documents and other records to the exchange, and clinicians at other facilities can see them, subject to consent and access rules.

Three DHA documents matter most for software teams:

The audit policy dates from 2020; DHA has since issued newer standards that may update parts of the original NABIDH policy set. Treat the newest DHA document on a topic as authoritative.

Interfaces: HL7 v2 first, FHIR and IHE too

The interoperability standard is direct: HL7 v2 is the recommended standard for accessing and submitting data, and health information systems should also support FHIR and IHE messaging.¹

It also lists IHE profiles a facility can use, including patient identity (PIX, PDQ, and their FHIR-based mobile versions PIXm and PDQm), document sharing (XDS.b, XDS-SD for scanned documents, XDS-I.b for imaging) and cross-community access and patient discovery (XCA, XCPD).¹

That v2-first stance matches most of the world: in a 2023 US survey, 96% of health information exchanges reported receiving HL7 v2 ADT messages.⁴ If your product speaks only FHIR, plan a v2 interface or an integration engine. HL7’s official v2-to-FHIR mappings help in either direction.⁵ Our v2-to-FHIR pipeline post covers the stages.

Consent, opt-out and break the glass

DHA’s 2025 consent standard says consent is required to access PHI through other health information systems, and that entities must record the patient’s consent, refusal, withdrawal or re-opt-in, with dates, on paper or electronically.³

Break the glass is defined as letting health professionals access PHI without the patient’s consent when necessary to lessen or prevent a serious threat to the patient’s health, such as an emergency.³ The standard also has sections on opting out, access by external parties such as vendors and consultants, monitoring access, sensitive and VIP information, and audit.³

For software, consent is data. Your system needs to store the consent state with its date, respect it on every query, and record when someone broke the glass and why.

Audit logs

The NABIDH audit policy is unusually specific. NABIDH records all activities related to access, creation, modification, disclosure and deletion of electronic PHI, and facility nodes log events such as login, logoff, access and denial.²

The audit repository must be able to answer five questions: which users accessed a patient’s information over a period; which patients a user accessed; all break-glass events; access by users not listed as a provider for that patient; and requests for sensitive information.² Those five queries are a good test for any logging design, in Dubai or elsewhere.

What this means for AI tools

None of these documents mention AI agents, but their rules apply to any software that reads or writes through a facility’s systems:

• An AI tool’s access is access. If it reads records through the HIS or the exchange, the audit log should show it as a distinct user or system, not hidden behind a clinician’s account.
• Consent still applies. An AI tool querying NABIDH data needs the same consent check as a clinician’s query.³
• Break-glass isn’t for software. The definition is about health professionals in emergencies.³ An automated tool shouldn’t trigger it.
• The five audit questions should include the tool. “Which patients did this AI tool access last quarter?” should be answerable from the logs.²

Our post on audit record fields for AI actions covers what else to capture when the actor is software.

A checklist for vendors

1. Support HL7 v2 for data submission; add FHIR R4 and the IHE profiles your customers need.¹
2. Store consent state with dates, including refusal, withdrawal and re-opt-in.³
3. Log access, creation, modification, disclosure and deletion, plus login, logoff and denials.²
4. Keep audit logs three years and support quarterly review.²
5. Make the five audit queries possible without custom work.
6. Give each automated tool its own identity in the logs.
7. Check DHA’s site for the newest version of each standard.

Questions people ask

Is connecting to NABIDH required?

DHA’s interoperability standard applies to all DHA-licensed health facilities.¹ Check DHA’s current licensing rules for the specific obligation and timelines that apply to you.

Does NABIDH use FHIR?

FHIR R4 is listed among the standards, and systems should support it alongside HL7 v2, which is the recommended standard for submitting data.¹

How long are NABIDH audit logs kept?

Three years, under the 2020 audit policy.²

For a comparison with the emirate next door, see our Malaffi post. Health systems can see how agent actions get recorded on our healthcare page and in the provenance spec. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.