NABIDH Integration Checklist: 40 Readiness Items for Dubai Healthcare Facilities

NABIDH, the Dubai Health Authority's health information exchange, connects licensed providers across the emirate so that a patient's record follows them between facilities. DHA expects licensed facilities to participate, and most clinic and hospital platforms sold in Dubai now offer a NABIDH connection. What the sales conversation rarely covers is that the connection is the easy part. The hard part is having data worth sending: the right patient, correctly identified, with coded diagnoses, formulary medications and structured results, captured consistently by clinicians who understand why.

This checklist covers that facility-side work. It is organised into eight areas, with a note on who typically owns each item and what you should expect the software vendor to provide. Requirements and specifications evolve; use this to prepare for a structured discovery with your vendor and DHA, not as a substitute for the authority's current guidance. For the background on what NABIDH is and why it matters, read the NABIDH compliance guide first.

1. Governance and scope

1. Name an accountable owner for NABIDH at the facility: usually the medical director or a senior manager, not IT. Owner: leadership.
2. Confirm your licence scope with DHA: which facility, which locations, which services are in scope. Owner: licensing lead.
3. List every system that holds clinical data: the EMR, laboratory, radiology, pharmacy, any legacy system, any paper. Owner: operations.
4. Decide the system of record for each data type. If lab results live in two places, choose one. Owner: medical director with IT.
5. Document the vendor's responsibilities and yours in writing before work starts: connection, mapping, testing, certification, ongoing maintenance when specifications change. Owner: leadership; vendor provides the split.

2. Patient identity

6. Emirates ID captured at registration for every patient, read from the card rather than typed. Owner: front desk; vendor provides the reader integration.
7. Duplicate patient records identified and merged before connection. Two records for one patient means two fragments in the exchange. Owner: operations with the vendor's duplicate report.
8. Demographic completeness checked: name as on Emirates ID, date of birth, gender, nationality, contact details. Owner: front desk.
9. A process for patients without Emirates ID (visitors, newborns) agreed and configured. Owner: front desk with vendor.

3. Clinical data quality

10. Diagnoses coded at the point of care in ICD-10, selected by the clinician in the note, not assigned afterwards by a coder. Owner: clinicians; vendor provides coding in the encounter.
11. Procedures coded in CPT from the order. Owner: clinicians; vendor.
12. Medications selected from a formulary with coded identifiers, not typed as free text. Owner: clinicians; vendor provides the formulary.
13. Allergies recorded as structured entries with reaction and severity, and reconciled at each visit. Owner: nursing and clinicians.
14. Laboratory results stored as discrete values with units and reference ranges, not as scanned reports. Owner: laboratory; vendor provides the interface.
15. Radiology reports stored as structured documents with DICOM images where applicable. Owner: radiology; vendor.
16. Vital signs recorded as discrete values at triage. Owner: nursing.
17. Encounter types and specialties mapped to the exchange's expected categories. Owner: vendor with medical director.
18. A data-quality audit run on the last three months: percentage of encounters with a coded diagnosis, medications from formulary, allergies reviewed. Fix the workflow before connecting, not after. Owner: medical director; vendor provides the report.

4. Technical connection

19. Confirm the platform's NABIDH status and ask at which Dubai facilities it is live today. Owner: leadership; vendor.
20. Confirm the messaging standards the connection uses (HL7-based, with FHIR according to scope) and that your version of the platform supports them. Owner: vendor.
21. Network and security requirements for the connection reviewed with IT or the hosting provider. Owner: IT; vendor.
22. Downtime and queuing behaviour understood: what happens to messages when the connection is unavailable, and how they are resent. Owner: vendor to explain; IT to accept.
23. Error handling and monitoring: who sees rejected messages, and who fixes them. Owner: operations; vendor provides the monitoring view.

5. Consent and privacy

24. Patient information about NABIDH prepared for the front desk and displayed in the facility, in Arabic and English. Owner: leadership.
25. Consent handling configured according to DHA's current requirements, including how a patient's choices are recorded and respected. Owner: leadership; vendor configures.
26. Role-based access reviewed so that exchange data received from other providers is visible only to those who need it. Owner: IT with medical director.
27. Audit logging confirmed for every access to exchange data, and someone assigned to review it. Owner: compliance; vendor provides the log.
28. Privacy policies and staff confidentiality agreements updated to reflect participation. Owner: HR and compliance.

6. Testing

29. A test plan with real scenarios: new patient, returning patient, correction of an error, a result arriving after the visit, a cancelled encounter. Owner: operations with vendor.
30. Test in the exchange's test environment before production, with the vendor confirming what was received. Owner: vendor; facility witnesses.
31. Verify what the exchange receives against what the clinician documented, for a sample of encounters. Owner: medical director.
32. Test the inbound view: can the clinician see the patient's history from other providers at the point of care? Owner: clinicians.
33. Keep the evidence: test cases, results and sign-offs, for your own governance and for the authority. Owner: compliance.

7. Training

34. Front desk trained on Emirates ID capture, patient information about the exchange, and consent recording. Owner: operations.
35. Clinicians trained on coding in the encounter, formulary prescribing, structured allergies, and viewing exchange data. Owner: medical director.
36. Someone trained on the error queue: what a rejected message means and how to fix it. Owner: operations; vendor trains.

8. Go-live and ongoing

37. Go-live date agreed with the vendor and, where required, the authority, with a support plan for the first week. Owner: leadership.
38. Weekly data-quality review for the first three months: coded diagnosis rate, message error rate, duplicate patients created. Owner: medical director.
39. A named contact at the vendor for exchange issues, and an agreed response time. Owner: vendor.
40. A process for specification changes: who tells you when DHA updates a requirement, who implements it, and whether it is included in your contract. Owner: leadership; vendor.

What to expect from your software vendor

Of the forty items above, roughly half are the facility's alone. For the rest, a capable vendor provides the tooling and does the technical work: the Emirates ID integration, coding and formulary inside the encounter, discrete results, the connection itself, the monitoring view, the test environment and the training on the error queue. Ask your vendor to go through this list with you and mark each item as theirs, yours or shared. If they will not, that is the answer.

MEDAS E-Clinic and HIMS support NABIDH integration workflows with Emirates ID registration, ICD-10 and CPT coding in the encounter, formulary prescribing, discrete laboratory and radiology results, HL7 interoperability and audit logging as standard. The facility-specific integration and certification scope is confirmed during scoping, and the division of responsibility is written into the implementation plan.

Frequently asked questions

Is NABIDH mandatory for Dubai clinics?

DHA expects licensed facilities to participate in NABIDH. The specific requirements and timelines that apply to your licence should be confirmed with DHA's current guidance; this checklist prepares the facility for that conversation.

How long does NABIDH integration take?

The technical connection is usually the shortest part. The facility-side work, particularly data quality and duplicate resolution, determines the timeline. Facilities that have coded diagnoses and formulary prescribing already in place move fastest.

Does MEDAS manage the NABIDH connection?

MEDAS manages the technical connection, mapping, test environment and monitoring for E-Clinic and HIMS, and trains the facility on the error queue. The facility owns identity, data quality, consent and governance, and the split is documented in the implementation plan.

What is the most common reason NABIDH projects stall?

Data quality. Free-text diagnoses, typed medication names and duplicate patient records cannot be exchanged, and fixing them after connection is slower than fixing the workflow before it. Items 10 to 18 above are where to start.