What is NABIDH (DHA): Meaning and integration with medical clinic software

Key takeaways

NABIDH stands for Network and Analysis Backbone for Integrated Dubai Health, the Dubai Health Authority’s health information exchange.

Connecting is a condition of holding a DHA license, so it applies to every licensed practice in Dubai whatever its size.

Your software sends coded HL7 messages while staff work, which makes NABIDH continuous reporting rather than a one-time certification.

Every message passes three separate validation layers, and the acknowledgment code that comes back tells you which one refused it.

Abu Dhabi practices report to Malaffi and northern emirates practices to Riayati, so check which exchange your license points to.

NABIDH is the Dubai Health Authority’s health information exchange. It gives each patient in Dubai a single medical record that follows them between practices. Connecting to it is a condition of holding a DHA license. The acronym stands for Network and Analysis Backbone for Integrated Dubai Health.

The platform is well past pilot scale. By the end of June 2025 it held 10.41 million medical records, according to the DHA. Those came from 1,888 licensed facilities, 53,659 healthcare professionals and 91 separate medical record systems.

The mechanics are worth getting straight early, because they change how you plan for it. NABIDH is not a portal your front desk logs into and retypes notes into at the end of the day. Your practice management software sends the data on your behalf, as structured messages, while your team works.

So the software you choose does most of the complying. Pabau is a DHA NABIDH-approved medical clinic software. Our NABIDH integration is built against the DHA’s NABIDH HL7 v2.5.1 specification. It generates the messages as registrations, visits and clinical notes happen.

This guide covers what NABIDH is, who it binds, what it wants from you, and how a practice gets connected.

What is NABIDH and what does it do?

NABIDH is a platform that connects public and private healthcare facilities in Dubai so they can exchange trusted health information. That wording is the DHA’s own, from its interoperability standards.

In practice it does three jobs. It collects clinical data from every connected facility and normalizes it into one longitudinal record per patient. That record is served back through two portals — a clinician portal for treating staff, and a patient portal for the patient. It is the shared, cross-provider layer that separates an electronic health record from a chart held in one building.

So a patient who had bloods drawn in Jumeirah last month arrives at your practice with that result already attached to them. You stop reordering tests that already exist, and the DHA gets a picture of Dubai’s health data it can plan against.

A note on the NABIDH full form

You will see NABIDH expanded two ways online. The DHA’s own announcements use Network and Analysis Backbone for Integrated Dubai Health, so that is the one to quote. The variant “National Backbone for Integrated Dubai Health” circulates widely but is not the authority’s wording.

Who has to connect to NABIDH

Every DHA-licensed health facility. The interoperability standard states its scope in exactly those words, and it draws no line by size, specialty or patient volume.

A solo skin clinic is in scope on the same terms as a hospital group, and so is a single-site hair restoration practice.

The authority to require it comes from Local Law No. 6 of 2018 concerning the Dubai Health Authority. Local Law No. 14 of 2021 amended it. Together they give the DHA its regulatory, licensing and health informatics remit. Dubai’s Health Data Law No. 11 of 2018 and Federal Law No. 2 of 2019 govern how the data itself is handled.

Read those together and the shape of the obligation is clear. NABIDH is not a separate certification you buy. It is attached to the license you already hold. Practices tend to meet it during a licensing renewal rather than a software project. That timing is worth remembering when you shortlist UAE practice software.

NABIDH, Malaffi or Riayati — Which one applies to you

The UAE runs three health information exchanges, and the one you report to follows your regulator, not your postcode. Practices with sites in more than one emirate report to more than one platform.

The three are linked. UAE health authorities announced that Riayati, Malaffi and NABIDH now exchange data with each other through the National Unified Medical Record. Reporting into one still means reporting into one, though — the link between them is not a substitute for your own connection.

What your practice has to send

Patient demographics anchored on the Emirates ID, plus the clinical record built around them — encounters, diagnoses, medications, results, procedures, allergies, immunizations and documents. Your facility license ID and the treating clinician’s Sheryan ID ride along with the clinical content.

The demanding part is not the list. It is that NABIDH wants the data coded rather than typed. The DHA publishes 36 code tables for its inbound messages. They constrain fields you might not expect: marital status, religion, patient class, admission type and hospital service. Diagnosis classification, abnormal flags, route of administration, specimen type and document type are coded too.

Each of those has a value set your software has to map onto. A free-text entry in a field the DHA expects to be coded is one of the ordinary reasons a submission bounces. Your team never sees that failure unless the software surfaces it.

Which NABIDH message your practice sends and when

Message-level detail is what decides whether compliance costs your team any time, so it is worth a section of its own. NABIDH does not receive a single daily upload. It receives a specific message type for each specific event, triggered as that event happens.

The DHA’s HL7 API documentation names six message types for HL7 v2.5 submissions. Mapped onto an ordinary working day in a Dubai practice, they look like this.

Two consequences follow. First, a practice that only registers patients and sees them still reports constantly, because registration and check-in are themselves reportable events. Second, the volume of messages you send scales with how busy you are, not with how much paperwork you decide to do.

Documents get a route of their own. Alongside HL7, NABIDH accepts C-CDA v2.1 documents through two named transactions. ITI-41 provides and registers a document, and ITI-44 adds or updates a patient. That is how a scanned referral letter or a signed consent form reaches the record.

What happens after your software hits send

A NABIDH message is validated three times before it lands on a patient’s record, and each layer refuses it for a different reason. Knowing which layer said no is what turns a vague “our integration is broken” into a fixable ticket.

NABIDH answers every submission with an acknowledgment code. CA means the message committed. CE and CR are both refusals — a content error and an outright reject.

That code is your evidence trail, so ask any software vendor a blunt question about it. Where do I see the acknowledgment for a given message, and what happens to one that comes back CE? A system that swallows those quietly will report a clean queue while the DHA has none of your data.

The standards NABIDH holds your software to

Two documents matter. The HL7 API documentation governs what you send today: HL7 v2.5 messages and C-CDA v2.1 documents, against the segments and code tables the DHA specifies.

The second is newer and points forward. Version 2 of the DHA’s Standards for Interoperability and Data Exchange took effect on July 2, 2025. It names HL7 v2 as the recommended standard for submitting data. Health information systems are also asked to support HL7 FHIR R4 and the Integrating the Healthcare Enterprise profiles.

Those profiles are worth knowing by name, because a vendor’s roadmap will mention them. PIX and PDQ handle patient identifiers and demographic queries. XDS.b shares granular clinical data, XDS-SD carries scanned documents, and XDS-I.b registers radiology images. XCA and XCPD reach data held by other systems, and PDQm, PIXm and MHD do the mobile-friendly equivalents over FHIR.

Sitting above all of it is a stack of NABIDH policies your practice is also bound by:

• Health data protection and confidentiality
• Consent and access control
• Identity management
• Authentication and authorization
• Incident management and breach notification
• Health information audit
• Artificial intelligence in healthcare

How a Dubai practice connects to NABIDH, step by step

The route runs through the DHA, but the work sits mostly with your software vendor. Six stages, in order.

1. Confirm your system speaks NABIDH’s HL7. A system that was never built against the DHA specification needs a vendor release or a middleware layer before it can be tested at all.
2. Apply through the NABIDH provider portal. You register with your license details and your system information, and the DHA assigns your facility to an integration batch.
3. Collect your identifiers. A NABIDH medical record code, your seven-digit Sheryan facility license ID, the NABIDH endpoint and an application key. You also need each practitioner’s eight-digit Sheryan clinician ID.
4. Map practitioners and services. Every clinician’s Sheryan ID has to reach the visit message, and each service needs its DHA specialty code so visits carry the right hospital-service value.
5. Pass system integration testing. Your vendor sends test messages into the DHA sandbox covering registration, encounters, prescriptions and results. Integration teams working in this market report that a first clean pass is uncommon.
6. Go live, then watch the log. The DHA issues production credentials and activates your facility. From then on the job is monitoring delivery and clearing failures.

Stage six is the one that gets underestimated. Testing is a project with an end date, and reporting is not. A practice that treats go-live as the finish line accumulates failed messages nobody reads.

Consent, opt-out and break-the-glass access

A patient’s health information is shared with connected facilities unless that patient opts out. The DHA’s Subject of Care Rights policy sets the default that way, and it puts several obligations on your practice rather than on the platform.

Each patient has to be told about NABIDH at their first visit after your facility joins. That makes patient onboarding the natural home for the notice.

The information you give them covers how their data may be used, who can see it, the retention period, and how to contact NABIDH. It has to be available somewhere they will meet it, such as your reception area or your website.

Opt-out runs through you, not around you. Patients follow the procedure their healthcare facility provides, and your team may process the request for them. They can opt back in later, and they can opt out of specific facilities rather than the whole exchange.

Patients hold three further rights worth briefing your front desk on. They can ask for a report of electronic disclosures, naming the date and both parties for each one. They get notified when their record is opened under break-glass emergency access. And they can upload documents themselves for treatment received outside Dubai and the UAE.

How Pabau connects your practice to NABIDH

Practice management software like Pabau brings scheduling, clinical records, payments and marketing into one system, so the data NABIDH wants is already in one place. The connector then reports it without asking your team to enter it twice.

Setup is three steps rather than an integration project. You enter your DHA identifiers and they are stored encrypted. Those are the NABIDH medical record code, the Sheryan facility license ID, the endpoint and the application key. You map each practitioner’s Sheryan ID and tag services with their DHA specialty code. Then your team works normally.

From there, registrations and demographic updates go out as ADT messages by default. Visits, problems, allergies, prescriptions, lab results, documents, letters and patient merges are each message types you can switch on. Each is mapped to the HL7 v2.5.1 format the specification asks for.

Two details matter more than they sound. Pabau validates Emirates ID formats, UAE phone numbers, and seven-digit facility and eight-digit clinician IDs before a message leaves. A mistyped ID gets caught at the desk instead of at the DHA.

Every message is also logged with its delivery status, and failures retry automatically. So when you need to evidence your reporting, the record is there. The local cases are handled too, from newborn and emergency Emirates IDs to resident and tourist defaults and VIP confidentiality flags.

Report to NABIDH without the second job

Pabau generates the HL7 v2.5.1 messages the DHA specification requires as your team registers patients, records visits and writes notes. Emirates IDs and license numbers are validated before sending, and every message is logged with its delivery status.

Book a demo

Conclusion

NABIDH is best understood as a reporting obligation attached to your license, not a system you use. That reframing changes what you should be evaluating. Ask whether a vendor generates the right message from the right event. Then ask where you can see what came back.

The trade-off worth remembering is where the work lands. Software that reports automatically moves the effort to setup, where identifiers and mappings have to be right once. Software that does not moves it onto your front desk, permanently, and hides the failures.

If you are choosing a system for a Dubai practice, ask for the delivery log and the acknowledgment handling in the demo. Do it before the feature tour. Book a demo to see how Pabau keeps a Dubai practice reporting to NABIDH as a by-product of an ordinary working day.

Continue your research

Not sure how an EHR differs from what you have now? EHR meaning: what electronic health records are and how they work explains the record types NABIDH is built to exchange between.

Shopping for a system for a UAE practice? Top 7 medical spa software in the UAE compares the platforms aesthetic practices in the region shortlist most often.

Confused about where practice management ends and EMR begins? Practice management system vs EMR sets out which functions live where, and why the split matters at procurement.

Running more than one site? Best clinic management software for multi-location practices covers the reporting and access questions that multiply with each new location.

Wondering how AI notes fit a regulated market? AI clinical documentation: how it works and why it matters looks at documentation that has to satisfy a regulator as well as a clinician.

Frequently asked questions