HL7 & FHIR Integration in the UAE

In the UAE, a healthcare facility's systems must do more than talk to each other. They also report to the regulator's health information exchange and submit claims through the emirate's e-claims platform. A clinic in Dubai feeds NABIDH and bills through eClaimLink; a hospital in Abu Dhabi feeds Malaffi and bills through Shafafiya; a provider in the northern emirates works with Riayati. A group operating in several emirates does all of this at once. HL7 and FHIR integration meets these obligations without re-keying: HL7 v2 messages and clinical documents to the exchanges, FHIR APIs for newer services, DICOM for imaging and XML transactions for claims. Superior Business Solutions (SBS) builds and supports these interfaces for hospitals, clinics, laboratories, imaging centres and pharmacies across the UAE, with more than 14 years of healthcare-IT and ERP delivery behind it.

Interfaces SBS builds for UAE providers

• Exchange feeds: registrations and encounters, lab and radiology results, clinical documents, allergies, problems, medications and immunisations, in the format each exchange specifies.
• E-claims: prior authorisation, claim submission, resubmission and remittance reconciliation through eClaimLink and Shafafiya (see medical billing in the UAE).
• Laboratory and imaging: HIS/EMR to LIS, RIS and PACS over HL7 v2 with DICOM modality worklist, and results forwarded to the exchange.
• Pharmacy and devices: e-prescriptions and dispensing in the regulator's formats; analysers and monitors feeding results and vitals into the record.
• Patient identity: Emirates ID, passport and facility record numbers reconciled across systems.
• ERP: revenue, receivables and consumables in Odoo or Microsoft Dynamics 365, ready for FTA e-invoicing as it phases in.

The UAE landscape, emirate by emirate

Malaffi (Abu Dhabi)

Malaffi is Abu Dhabi's health information exchange, operating under DoH oversight. DoH requires licensed facilities to onboard and report the data its policy defines, and recent circulars have continued to widen that scope, including referral data sent in line with Malaffi's HL7 specifications. Onboarding generally runs through registration with the programme, interface build to the specification, testing in Malaffi's environment and a go-live check. Abu Dhabi facilities must also comply with ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, which applies to any entity handling Abu Dhabi health information, so the integration engine, its accounts, logs and connections fall within audit scope.

NABIDH (Dubai)

NABIDH, the National Backbone for Integrated Dubai Health, is DHA's exchange, and DHA-licensed facilities are expected to connect through an EMR that meets its specifications. Onboarding is tied to the facility's licence record in DHA's Sheryan system, and its published specifications, covering HL7 v2 messages and C-CDA documents, define message structure, code tables (ICD-10-CM, CPT and DHA value sets) and acknowledgement handling. We map local codes and free-text fields to those tables before testing starts, because conformance testing is where poorly mapped interfaces stall.

Riayati (northern emirates)

Riayati is the National Unified Medical Record platform led by the Ministry of Health and Prevention, used across Emirates Health Services facilities and by private providers in the northern emirates. Riayati, Malaffi and NABIDH have been linked so that records can follow patients between emirates, which raises the bar on identity quality: a duplicate created in one emirate becomes visible in all three.

Integration patterns used in the UAE

HL7 v2 messages to the exchanges

The exchanges are fed mainly through HL7 v2 messages built to each one's published specification. The core set is familiar: ADT for registrations, admissions, transfers, discharges and merges; ORM for orders; ORU for laboratory and radiology results; MDM for documents such as discharge summaries; plus immunisation, allergy and problem data in the messages or segments each exchange defines. Every message earns an ACK or a NACK, and an interface that ignores NACKs falls out of compliance quietly.

IHE profiles for identity and documents

DHA's interoperability and data-exchange standards point facilities to IHE profiles alongside HL7 v2: PIX and PDQ for patient identity cross-referencing and demographic queries, and XDS-family profiles for registering and retrieving documents. Identity is harder here than in most markets: a large share of patients are expatriates, names are transliterated differently between systems, and an Emirates ID is not always available at the first visit. We design registration and merge rules so a corrected record propagates to every connected system and to the exchange.

FHIR for newer services

FHIR R4 is increasingly used for patient apps, portals and analytics, and newer national services are moving towards API-based exchange. We build and consume FHIR APIs where the counterpart supports them and keep HL7 v2 where an exchange specification still requires it; the integration engine translates between the two.

Claims are XML, not HL7

Claims follow a separate track. eClaimLink and Shafafiya exchange XML transactions (prior requests and authorisations, claim submissions and remittance advice) validated against the regulator's schemas and code sets, typically ICD-10-CM diagnoses, CPT procedures, HCPCS and regulator drug codes. In Dubai, the claims-management policy directive issued by the Dubai Health Insurance Corporation, effective November 2025, requires end-to-end electronic claims handling through eClaimLink with defined response times, giving claim interfaces a direct operational deadline.

Data residency, privacy and security

Federal Law No. 2 of 2019 on the use of ICT in health fields requires health data to be stored and processed inside the UAE unless an exemption applies, and it governs patient confidentiality. The federal Personal Data Protection Law (Decree-Law No. 45 of 2021) defers to health-specific legislation where it exists, so the ICT health law is the primary test for where your engine, message archive and backups may live. We host integration components in UAE data centres or UAE cloud regions, encrypt connections, keep audit logs in-country and, for Abu Dhabi, document controls against ADHICS. Our cybersecurity services in the UAE cover the wider programme.

Testing, go-live and monitoring

Every UAE integration follows the same discipline: an interface catalogue and gap analysis against the exchange and claims specifications; field-level mappings signed off with each vendor; build and unit testing on the engine; integrated testing, then the exchange's own onboarding tests; and a controlled cutover. After go-live we watch NACK rates, latency, queue depth and claim rejections, replay failed messages once the cause is fixed, and flag reporting gaps early. A dedicated support team that knows your interfaces handles incidents, with response times agreed up front.

What drives the cost

• How many emirates, exchanges and claims platforms you connect to.
• The number of source systems and message types, and any vendor interface fees.
• Engine licensing and UAE-based hosting.
• Mapping effort for local codes, free text and identifiers.
• Security scope, including ADHICS evidence in Abu Dhabi, and support hours.

How to choose an integration partner in the UAE

• Do they work from the current Malaffi, NABIDH and Riayati specifications and know the onboarding steps?
• Can they deliver clinical feeds and XML claims together, so one encounter drives both? See insurance and TPA management.
• Will they design identity and merge handling for an expatriate-heavy population?
• Can they host in the UAE and produce evidence for ADHICS and internal audits?
• Do they offer monitored support with replay and clear response times after go-live?

Frequently asked questions

Is connecting to Malaffi or NABIDH mandatory?

For licensed facilities in scope, yes: DoH requires Abu Dhabi facilities to onboard to Malaffi, and DHA-licensed facilities in Dubai are expected to connect to NABIDH, each under its own policies and timelines. Providers in the northern emirates work with Riayati under MOHAP and Emirates Health Services arrangements.

Which HL7 messages do Malaffi and NABIDH need?

The core is ADT for registrations and encounters, ORU for lab and radiology results, ORM for orders, and MDM or C-CDA for clinical documents, plus allergies, problems and immunisations as each exchange specifies. The exact list depends on your facility type and the current specification.

How much does Malaffi or NABIDH integration cost?

It depends on how many source systems feed the exchange, whether your HIS vendor charges interface fees, the mapping effort and the hosting model. SBS quotes against a defined interface catalogue after a short discovery.

How long does Malaffi or NABIDH onboarding take?

If your EMR already supports the exchange's specification, the work is mainly configuration, mapping and testing; if interfaces must be built, the project is longer. The exchange's own testing schedule is often the critical path, so SBS plans around it from the start.

Are eClaimLink and Shafafiya HL7 interfaces?

No. Both use XML transactions defined by the regulator for prior authorisation, claims and remittance. SBS integrates them alongside the HL7 clinical feeds so one encounter drives both.

Can the integration engine or health data be hosted outside the UAE?

Federal Law No. 2 of 2019 requires health data to be stored and processed inside the UAE unless an exemption applies, so SBS hosts engines, message archives and backups in the UAE. In Abu Dhabi, ADHICS controls also apply to the integration layer.