Malaffi, NABIDH and Riayati: What UAE Hospitals Need From Their HIS Integration

TL;DR

• The UAE does not have one health information exchange. It has several: Malaffi (Abu Dhabi), NABIDH (Dubai) and Riayati (the federal platform run by the Ministry of Health and Prevention, MoHAP). They have been linked to one another, but each facility still connects to the exchange of the emirate that licenses it.
• Your hospital information system (HIS) has to be able to send clean, coded clinical data in the standards the exchange asks for. For Dubai, DHA's published standards recommend HL7 v2 and expect FHIR and IHE support as well.
• Federal Law No. 2 of 2019 on ICT in health fields restricts storing or moving health data outside the UAE, with a list of exemptions. That shapes where your HIS, backups and analytics tools can run.
• The expensive mistakes are rarely in the interface engine. They are in patient identity matching, terminology mapping, and discovering late that a vendor's cloud sits outside the country.
• Treat each exchange connection as its own scoped project with its own authority sign-off, not a tick-box on a vendor's feature sheet.

Why this question comes up in every UAE hospital project

If you are buying, replacing or extending a hospital system in the UAE, someone on the steering committee will ask: "Is it Malaffi-ready? NABIDH-ready? Riayati-ready?" The honest answer is that "ready" means three different things, owned by three different bodies, with different onboarding processes and different timelines.

This article is for hospital CIOs, medical directors, operations heads and group IT leads who need to turn that question into a requirements list. It covers what each exchange is, what the published standards say, where the data-residency law bites, and a practical checklist you can put in front of a vendor or an in-house team.

A note on sources. We have used official government and regulator pages wherever we could, and law-firm summaries for the data-transfer rules. Where a technical detail is only available to licensed facilities during onboarding (and not published openly), we say so rather than guess. Always confirm against the current official documents before you commit to a design.

The three exchanges at a glance

Malaffi (Abu Dhabi)

Malaffi is the Abu Dhabi health information exchange, operated by Abu Dhabi Health Data Services under the Department of Health (DoH). In October 2021 the Department of Health announced that all public and private hospitals in the emirate were connected to the platform, along with a large share of clinics and medical centres: its announcement cited 59 hospitals, 1,100 clinics and medical centres and 1,539 healthcare facilities in total. (DoH Abu Dhabi)

The practical consequence is simple. If your facility is licensed by DoH, connection to Malaffi is part of operating, not an optional integration.

NABIDH (Dubai)

NABIDH is Dubai's exchange, run under the Dubai Health Authority (DHA). DHA's published standards apply to DHA-licensed health facilities in the public and private sectors, and they state that facilities integrating with or accessing the exchange must follow DHA regulations and UAE law. (DHA interoperability standard) If you operate in Dubai, the same principle applies as in Abu Dhabi: the connection is a condition of doing business, so your HIS has to support it.

Riayati (federal)

Riayati is the national platform operated by MoHAP. MoHAP describes it as the unified medical record, with the Ministry, DoH, Emirates Health Services (which serves the Northern Emirates and uses the "Wareed" system) and DHA (through NABIDH) all participating. (MoHAP) As of the October 2023 announcement by the Abu Dhabi Media Office, Riayati held 2.7 billion medical records for 11.6 million patients from more than 3,850 medical facilities. (Abu Dhabi Media Office)

How they connect to each other

The authorities have announced integrations between the platforms. In October 2023, MoHAP and DoH announced a phase that lets Malaffi clinical users access patient information recorded during a patient's visits to facilities in the Northern Emirates, building on an earlier integration of Malaffi, Riayati and NABIDH. A further stated phase would let users reach Malaffi and NABIDH data through Riayati nationwide. (Abu Dhabi Media Office)

What does this mean for a hospital buyer? The exchanges are being joined at the platform level, so you do not build point-to-point links between them. But you should not assume that a connection to one gives you a connection to the others. Your licence determines which exchange you must feed. Plan for the one that applies to you, and ask the authority what the cross-exchange arrangements mean for your facility.

What the NABIDH standards actually say

Dubai is the one of the three where the regulator has published detailed technical standards, so it is a useful lens even if you are building for Abu Dhabi or the Northern Emirates, because it shows what regulators in the region expect.

DHA's Standards for Interoperability and Data Exchange says that HL7 v2 is the recommended standard for accessing and submitting data. It also says that HIS platforms should support FHIR and IHE profiles. The standard lists HL7 v2.x, HL7 v3, HL7 CDA R2 and HL7 FHIR R4, and it names IHE profiles including PIX, PDQ, XDS.b, XCA and XCPD, with FHIR-based counterparts such as PDQm and PIXm. (DHA interoperability standard)

DHA's Technical and Operational Standards document (an earlier version, dated September 2020) lists the HL7 v2 message types a facility is expected to support. Those include a long run of ADT (admit, discharge, transfer) events, ORM^O01 for orders, ORU^R01 for results, RDE^O11 for pharmacy encoded orders, VXU^V04 for vaccination records and several MDM document messages. (DHA technical standards) It also lists IHE profiles such as ATNA, BPPC, PIX, PDQ, XDS and XCA.

Two things stand out for a buyer.

First, HL7 v2 is not going away. Even though FHIR gets the headlines, the Dubai standard still leans on HL7 v2 as the workhorse. A HIS that is "FHIR-only" is not obviously a fit. A HIS that handles both and can translate between them is much safer. If your legacy estate is v2-heavy and you want to modernise, our guide to HL7 v2 to FHIR R4 migration covers the sequencing questions.

Second, the message list is long. Supporting ADT^A01 is easy. Supporting the full set of admit, transfer, update, merge and cancel events, and getting each one right when a patient is moved between wards or a record is corrected, is where interface projects slip. Each event has to reflect what actually happened in the hospital, in the right order.

One caution. The documents we reviewed did not name the clinical code sets (such as ICD-10, SNOMED CT or LOINC) directly. DHA points to a separate coding and terminology standard. Get that document, and the equivalent from DoH and MoHAP, before you design your data model.

What a hospital system must be able to do

Strip away the acronyms and a hospital that wants to participate in a health information exchange needs its HIS to do six things well.

1. Identify patients reliably

Every exchange depends on matching "this patient" in your system to "the same patient" in someone else's. In the UAE, the Emirates ID is the obvious anchor for residents, but visitors, newborns, unidentified emergency patients and people with name variations are where matching breaks. Your HIS needs a master patient index with clear rules for temporary identities, merges and un-merges, and a way to push corrections out to the exchange when a merge happens. A wrong merge sends one patient's allergies onto another patient's record. That is a patient-safety incident, not an IT defect.

2. Send events in real time, in the right order

Exchanges are only useful when the data is current. Admissions, discharges, results and prescriptions should leave your HIS as events, soon after they happen, not in an overnight batch. Build for retries, ordering and idempotency: if a message is delivered twice, or two arrive out of sequence, the exchange record must not end up wrong.

3. Capture structured, coded clinical data

Free-text notes do not travel well. Diagnoses, procedures, allergies, medications and lab results need structured fields with the right terminology behind them. This is where a lot of the effort in an HIS replacement goes, because clinicians have to change how they document. A system that makes structured entry slower than free text will lose that argument on the ward.

4. Handle consent and access properly

The exchanges set rules for who can see what, and when a patient can restrict access. Your system should record consent where the authority requires it, and should log who accessed which record and why. We did not find the consent mechanics in the openly published standards we reviewed, so confirm them with the authority during onboarding.

5. Stay inside the data-residency rules

More on this below, because it affects hosting decisions across the whole stack.

6. Prove it works, repeatedly

Onboarding to an exchange typically involves testing against the authority's environment before go-live. We have not verified the exact stages for each exchange, because they are shared with licensed facilities. Budget time for test cycles, defect fixes and re-tests, and plan for the fact that a regulator's test window may not match your project plan.

Data residency: the part vendors skip

Federal Law No. 2 of 2019 regulates the use of ICT in health fields. According to law-firm summaries, its central rule is that health data cannot be stored, processed, generated or transferred outside the UAE unless a health authority or the Ministry approves it, and that data must be retained for at least 25 years from the last health procedure. (Al Tamimi)

A ministerial resolution issued in 2021 set out exemptions. As summarised by Al Tamimi & Company, the default is that health data may not be stored or transferred outside the UAE, with ten categories of exception, including overseas treatment, overseas laboratories, scientific research, insurance and claims management, telemedicine, and personal medical devices and wearables. Several exemptions come with conditions such as written consent, encryption and, in some cases, keeping a copy in the UAE. (Al Tamimi) We are relying on a law-firm summary here, not the resolution text, so ask your legal counsel to confirm which exemptions, if any, apply to you.

What does this mean in practice for a hospital IT team?

• Where does the HIS run? If a vendor's standard SaaS runs in a region outside the UAE, you may have a problem on day one.
• Where do the backups go? Disaster recovery in another country is a common design for resilience, and it is exactly the kind of design the law restricts.
• Where does analytics run? A cloud data warehouse or an AI tool in a foreign region is a transfer, whatever the marketing page says.
• Who can support the system? Remote support by engineers outside the UAE can count as access to the data. Agree how that is handled.
• What happens to logs and monitoring data? Application logs often contain patient identifiers.

Ask your vendor to put the answers in writing, by component. Our overview of cloud infrastructure and backup and disaster recovery work covers how we approach in-country hosting questions in general.

A buyer's checklist for HIS and exchange integration

Use this when you speak to vendors, or when you scope an in-house build.

Standards and interfaces

• Which HL7 v2 message types and versions does the product support out of the box, and which need custom work?
• Does it expose FHIR R4 APIs for the resources the authority names? Which ones?
• Which IHE profiles (PIX, PDQ, XDS, XCA and so on) does it support?
• Is there an interface engine, and who operates and monitors it?

Data quality

• How does the system manage terminology and code-set updates?
• What validation runs before a message leaves the HIS?
• How are rejected messages surfaced, and who fixes them?

Patient identity

• How are temporary and duplicate patients handled?
• What happens to the exchange record when two patients are merged?

Security and access

• How is access to exchange data audited?
• How are user roles aligned with the authority's access rules?
• See our notes on security and identity management.

Hosting and law

• Where is every component hosted, including backups, logs, analytics and support tooling?
• Which, if any, of the legal exemptions does the design rely on?

Delivery

• Who owns the relationship with the authority during onboarding?
• What are the test and certification stages, and who pays for re-tests?
• What is the support model after go-live when the authority changes a specification?

Common mistakes we see in HIE projects

Treating the exchange as a final-phase task. Teams build the HIS first and bolt the exchange on at the end. Then they find that the data model cannot supply what the exchange needs. Bring the interface requirements into design on day one.

Buying "compliant" and not asking what it means. A brochure line saying "NABIDH compliant" or "Malaffi integrated" tells you little. Ask what it covers, which version, for which message types, and ask to see it working in a facility similar to yours.

Ignoring the data owner on the ward. Clinical staff decide whether structured data is entered properly. If they are not involved in design and training, your exchange feed will be full of blanks and defaults.

Underestimating legacy systems. Many hospitals run a patchwork of departmental systems for laboratory, radiology, pharmacy and billing. Each is a source of data the exchange wants. Middleware often has to normalise them first. Our piece on healthcare data integration through custom middleware goes through that pattern, and the article on EHR interoperability beyond FHIR explains why standard messages alone do not remove the meaning problems between systems.

Forgetting about change. Authorities update standards. DHA's interoperability document, for instance, is a controlled document with issue and revision dates. Your contract should say who absorbs the cost of keeping up.

Build, buy or extend?

There are three realistic routes.

Buy a packaged HIS that already connects to your exchange. This is often the fastest route if the product has a working, current connection in a similar facility. Verify it, don't assume it.

Extend your current HIS with an integration layer. If your clinical system is sound but lacks exchange connectivity, a middleware layer can translate and route messages. This keeps clinical workflows stable, but you take on responsibility for the layer.

Build custom. This gives control over workflows and data model, at the cost of owning the whole delivery and the regulator engagement. It is usually worth considering only where the facility's care model is unusual or you are building something other vendors do not offer. The cost trade-offs are covered in our guide to custom versus off-the-shelf EHR systems.

Whichever route you take, insist on a plan for exchange connectivity before you sign.

Where Syslabs fits

Syslabs builds custom software for healthcare, including interoperability and integration work. Our hospital information system, HIMS, launches on 20 December 2026. It is India-first for its first year, and it is designed around FHIR and HL7 interoperability, multi-currency and VAT handling, and in-country hosting. You can read more on the hospital information system page.

To be clear about what that means for UAE readers: HIMS is not something we are presenting as already connected to Malaffi, NABIDH or Riayati. Any UAE exchange connection would be a separately scoped project, agreed with the relevant authority's onboarding process, and scoped on a consultation. If you want a straight conversation about what your facility would need, our team can help with the architecture, the middleware and the data-residency questions. See our international clients page for how we work with teams outside India.

Conclusion

The question "is your HIS Malaffi, NABIDH and Riayati ready?" hides a longer list of questions about standards, data quality, patient identity, hosting and who owns the regulator relationship. The hospitals that do this well treat the exchange as part of the architecture from the first workshop, ask for evidence rather than brochure claims, and get the data-residency answers in writing before contracts are signed.

If you are planning a new HIS, a replacement, or an integration layer for the UAE, start with the checklist above and take it to your vendors. And if you would like a second opinion on scope, architecture or hosting, we are happy to talk it through.

Book a consultation: https://www.syslabs.in/book/meeting. The booking page shows the available slots in your own time zone, and pricing is scoped on a consultation once we understand your facility.

References

• Department of Health – Abu Dhabi (14 October 2021). 100 percent of Abu Dhabi based hospitals connected to Malaffi. https://www.doh.gov.ae/en/news/100-percent-of-Abu-Dhabi-based-Hospitals-Connected-to-Malaffi
• Dubai Health Authority. Standards for Interoperability and Data Exchange (NABIDH Policies & Standards). https://www.dha.gov.ae/uploads/102022/NABIDH%20Policies%20&%20Standards%20-%20Interoperability%20and%20Data%20Exchange%20Standards2022100429.pdf
• Dubai Health Authority. NABIDH Policies and Standards – Technical and Operational Standards (v1.0, September 2020). https://www.dha.gov.ae/uploads/102022/NABIDH%20Policies%20&%20Standards%20-%20Technical%20and%20Operational%20Standards20221049100.pdf
• Ministry of Health and Prevention. Ministry of Health and Prevention, local health authorities consolidate their medical data in Riayati platform. https://mohap.gov.ae/en/w/ministry-of-health-and-prevention-local-health-authorities-consolidate-their-medical-data-in-riayati-platform
• Abu Dhabi Media Office (30 October 2023). Ministry of Health and Prevention and Department of Health Abu Dhabi partnership facilitates access to patient records across Abu Dhabi and other emirates. https://www.mediaoffice.abudhabi/en/health/ministry-of-health-and-prevention-and-department-of-health-abu-dhabi-partnership-facilitates-access-to-patient-records-across-abu-dhabi-and-other-emirates/
• Al Tamimi & Company (November 2019). The Federal Law regulating the Use of Information and Communication Technology in the UAE Healthcare Sector. https://www.tamimi.com/law-update-articles/the-federal-law-regulating-the-use-of-information-and-communication-technology-in-the-uae-healthcare-sector
• Al Tamimi & Company (January 2022). Setting Healthy Boundaries: regulated exemptions to restrictions on the transfer of health data outside of the UAE. https://www.tamimi.com/law-update-articles/setting-healthy-boundaries-regulated-exemptions-to-restrictions-on-the-transfer-the-health-data-outside-of-the-uae/