Quick answer: Most mismatches between NABIDH, Malaffi and Riayati start at registration, not in the exchanges. The same patient is entered with a different name spelling, a missing middle name or a hand-typed ID, so the records cannot be linked. The fix is to read the Emirates ID from the card, store names in fixed fields that match the legal document, and catch duplicates before any record is sent to an exchange.
The UAE now has three regulator-run health information exchanges, one for each licensing authority, and they have been linked together so a patient’s record can follow them across emirates. That is a significant achievement. It also creates a quieter problem: when three systems exchange millions of records, small inconsistencies in how a patient is identified, named, or coded can stop the data from lining up.
The scale of what’s being connected
The volumes involved explain why mismatches matter. As of mid-2025, NABIDH held 10.41 million unified patient records across 1,888 licensed Dubai facilities, with 53,659 clinicians connected through 91 integrated EMR systems. Malaffi had reached 3.5 billion clinical records covering 12.7 million unique patient profiles, with 3,072 connected facilities and more than 53,000 authorised users. On the federal side, patient records from roughly 3,000 facilities registered under Riayati were linked to both Malaffi and NABIDH, as announced by MOHAP at Arab Health.
The integration is also now two-way in practice. Malaffi’s clinical users can access records created in the Northern Emirates through Riayati, an extension of the earlier phase that gave Riayati users access to Malaffi data. A patient treated in Sharjah under Riayati now appears inside Malaffi as a Riayati record that Abu Dhabi providers can open directly.
When this many records move between this many systems, matching them to the right person is the foundation everything else depends on.
What a “data mismatch” actually means
A mismatch is any situation where the same patient, or the same clinical fact, is represented differently across systems. In practice it takes a few forms:
- Identity mismatches: the same person appears with different name spellings, a different date of birth, or a missing identifier, so the exchange cannot confidently link the records.
- Duplicate records: one patient ends up with two or more records inside a single facility’s system, which then propagate into the exchange.
- Demographic drift: nationality, gender, or contact details that differ between a patient’s registration at two facilities.
- Coding and terminology gaps: diagnoses, medications, or lab results recorded in formats that don’t translate cleanly between systems.
The first two are the most consequential, because a record that cannot be matched to its owner is effectively invisible to the clinician who needs it.
Why identity mismatches happen
Patient matching is a long-studied problem in health informatics, and the numbers are consistent across markets. The American Health Information Management Association (AHIMA) reports that the average healthcare organisation’s EHR carries an 8 to 12 percent duplicate record rate, and in larger multi-facility systems this can rise to 15 to 16 percent. A study of nearly 399,000 confirmed duplicate records found that the middle name field was the single biggest source of mismatches, accounting for 58.3 percent of them. Name fields are where small human variations accumulate.
The cost is not abstract. A Black Book Research survey found that hospitals without an enterprise master patient index had a 24 percent match rate when exchanging records externally, compared with 85 percent at hospitals that had one. Without an index, an average of 18 percent of patient records were duplicates, and the repeated care resulting from duplicates averaged $1,950 per inpatient stay and more than $800 per emergency department visit.
The UAE has an advantage here, since the Emirates ID is a national identifier that all three exchanges use for matching. But the regulators have been direct that the identifier only helps if it is captured properly. Abu Dhabi’s Department of Health states in its Health Information Exchange standards that poor capture of demographic information is affecting patient matching in Malaffi and increasing the likelihood of duplicate records in EMRs, laboratory systems, and therefore the exchange itself. The standard requires facilities to use an Emirates ID card reader integrated directly into their EMR and laboratory systems, so the ID number, all names, and date of birth populate consistently, rather than being typed by hand.
A companion standard addresses names specifically, noting that inconsistent name entry compromises patient safety by preventing clinicians from seeing a unified history, which can lead to medication errors or redundant procedures. It requires names to match the legal identity document exactly, in a multi-field format, with no titles or nicknames.
Some of the most instructive local examples come from edge cases. A quality improvement project in Abu Dhabi’s ambulatory healthcare services examined newborns registered under placeholder names such as “Baby of”, which creates a real risk of identification errors when several patients share the same label. A placeholder that works inside one clinic becomes a liability once that record is exchanged across a network. This is exactly the kind of gap a well-designed healthcare software platform should flag at registration instead of leaving it for the exchange to untangle later.
A cross-exchange scenario
Consider a patient registered at a Dubai clinic under NABIDH, with an Emirates ID captured by card reader and a clean demographic record. The patient is later referred to a facility in Abu Dhabi, which queries Malaffi. If the Abu Dhabi facility’s hospital software recorded the patient’s name with a slightly different spelling, or with a missing middle name, the exchange may fail to match the two records with confidence. The clinician sees an incomplete history, or none at all.
Now add a third step: a follow-up in Sharjah under Riayati. The same patient could appear as three partially matched profiles across three systems, each holding part of the clinical story.
None of this requires a technical failure. It only requires that each facility captured the patient’s identity slightly differently, which is what the DOH standards are designed to prevent.
How to resolve mismatches at the source
Resolution works best in layers, starting at registration and ending with ongoing monitoring.
- Capture identity from the document, not from memory. Integrating an Emirates ID card reader into the registration workflow populates the ID number, names, and date of birth directly from the chip, as DOH Abu Dhabi requires. For patients without an Emirates ID, such as tourists or new residents, the passport number becomes the fallback identifier.
- Enforce a consistent name structure. Using a fixed multi-field format (first, middle, family name) that mirrors the identity document removes the free-text variation that drives most mismatches. Titles, nicknames, and placeholders should be blocked at entry.
- Detect duplicates before they enter the exchange. A master patient index inside the facility’s system should flag likely duplicates at registration using fuzzy and probabilistic matching, which handle typos and spelling variants better than exact matching. One study of nearly 10 million matched record pairs found that probabilistic scoring identified about 0.85 percent of previously matched pairs as uncertain and another 0.41 percent as outright mismatches, equivalent to roughly 40,000 records linked to the wrong person. At exchange scale, even a fraction of a percent is a large absolute number.
- Reconcile exchange responses back into the local record. When an inbound query returns a record under a slightly different demographic profile, the receiving system needs a defined workflow: flag it, let an authorised user verify it, and then link or reject it, with an audit trail. A hospital management system that silently accepts or ignores partial matches leaves clinicians with either false confidence or false gaps.
- Monitor mismatch rates as a metric. Duplicate rates, failed-match counts, and exchange rejection messages should be tracked on a dashboard, by site, so the problem is managed as a measurable quality indicator rather than discovered after an incident.
- Align coding and terminology. Beyond identity, diagnoses, lab results, and medications need to map to the standards each exchange expects. Both NABIDH and Malaffi rely on structured messaging, with NABIDH expecting HL7 v2.5.1 messages for demographics, visits, and clinical data.
What your software needs to do
For a single clinic or a multi-site group, the practical question is whether the platform treats these requirements as built-in behaviour or as add-ons. The capabilities worth checking are:
- Native Emirates ID card reader integration at registration, with fields populated directly from the chip.
- Enforced name and date-of-birth structure that matches the legal document.
- Duplicate detection with probabilistic matching, before a record is sent to any exchange.
- A verification queue for ambiguous matches, with audit logging.
- Support for each authority’s messaging requirements, so one platform can report to NABIDH, Malaffi, and Riayati without three separate integrations.
This is where a purpose-built hospital software platform separates itself from a general-purpose one. For a group operating across emirates, the same principle applies at the enterprise level: a clinic management system that can’t hold one coherent patient identity across sites will pass inconsistencies straight into the exchanges, no matter how well the exchanges themselves are built.
Where Lifetrenz fits
Lifetrenz’s UAE platform, one of the best hospital management systems, is designed around this principle: resolve identity at the point of registration, so that what flows into NABIDH, Malaffi, and Riayati is already clean. Patient identity capture, name structuring, and duplicate detection are part of the registration workflow in the hospital management system itself, rather than separate clean-up steps downstream, and the same data model supports reporting to all three authorities, which matters most for healthcare groups with facilities in more than one emirate.
For those groups, the benefit is practical. When a patient moves between Dubai, Abu Dhabi, and the Northern Emirates, the clinician on the receiving end sees one consistent history instead of fragments, and the finance team sees fewer downstream problems caused by demographic inconsistencies.
Final words
NABIDH, Malaffi, and Riayati have done the hard work of connecting the UAE’s patient data at national scale. The mismatches that remain are mostly not failures of the exchanges. They come from how individual facilities capture identity at the front door. The regulators have already told providers how to prevent them: read the Emirates ID from the card, structure names to match the legal document, and stop duplicates before they propagate.
Providers who build those habits into registration, and choose software that enforces them by default, will spend less time reconciling records and more time acting on them.
