Two emirates, two platforms
Health insurance claims in the UAE are not exchanged through one national platform. Abu Dhabi uses Shafafiya, run by the Department of Health. Dubai uses eClaimLink and the DHPO transaction gateway, run by the Dubai Health Authority. Both are separate from the health information exchanges, Malaffi and NABIDH, which carry clinical data, not claims.
The two platforms share a family resemblance. They exchange structured XML, use coded diagnoses and services, and return remittance information. They remain separate systems with their own rules, credentials and circulars, so a group with facilities in both emirates builds and operates two integrations.
Shafafiya in Abu Dhabi
Shafafiya's web services technical definition, version 3.5, describes a post office. A sender uploads a transaction file, and the receiver collects it. The post office communicates only through web services, and there is no web page or DOH software for uploading or downloading files.
| Service | What it does |
|---|---|
| UploadTransaction | Uploads a transaction file, and returns an identifier or an error report from the rule validation |
| GetNewTransactions and DownloadTransactionFile | Lists and downloads files that are waiting for you |
| SetTransactionDownloaded | Marks a file as received so it is not delivered again |
| SearchTransactions | Finds transactions by direction, type, status and file name |
| Prior authorisation services | Checks for and downloads new prior request and prior authorisation transactions |
| DRG services | Adds a diagnosis related group to an electronic claim and returns its details |
| Prescription, history and reconciliation services | Checks approved trade drugs, reads a person's insurance history and reconciles claim counts |
The transaction types are claim submission, person register, remittance advice, prior request and prior authorisation. A file is validated against Shafafiya's rules when it is uploaded, and the errors come back as a report your system has to read.
DHPO and eClaimLink in Dubai
eClaimLink is the Dubai Health Authority's electronic claims programme. The DHPO is the gateway through which the transactions pass, and its XML schema documents the transaction types, including prior authorisation. Providers reach the system through a portal and through web services, and the electronic prescription initiative has run through the same programme since 2013.
The Dubai Health Authority also publishes the code lists that facilities use for claims and that NABIDH reuses: ICD-10-CM for diagnoses, CPT for procedures and CDT for dental, IR-DRG, and the Dubai Drug Code for medicines.
How the two compare
| Aspect | Shafafiya, Abu Dhabi | DHPO and eClaimLink, Dubai |
|---|---|---|
| Operator | Department of Health | Dubai Health Authority |
| Format | XML transactions | XML transactions with a published schema |
| Access | Web services only | Portal and web services |
| Transactions | Claim submission, person register, remittance advice, prior request, prior authorisation | Claims, prior authorisation, remittance and electronic prescriptions |
| Validation | Rules applied at upload, with an error report | Rules and code lists published in circulars and the schema |
| Drug codes | Approved trade drugs, checked through a service | The Dubai Drug Code |
What a hospital system has to support
- Charges that carry the service, diagnosis and medicine codes each platform requires, kept in one place.
- A claim record with a lifecycle: draft, ready, submitted, answered and reconciled.
- An XML builder per platform, versioned, because the schemas and circulars change.
- Upload and collection as separate steps, each with its own log and retry.
- Reading validation errors and rejections, and routing them to the people who can fix the charge.
- Prior authorisation requested from the clinical workflow, with the approval stored against the service.
- Remittance applied to each claim line, with the denial reason stored.
- Separate credentials, test and production environments for each facility licence.
Design points that prevent rejections
- Fix the charge, not the file. Most rejections come from the code or the authorisation behind a charge. Correct them at the source so the next claim is right too.
- One claim model, two outputs. Keep a single internal claim record and generate each platform's XML from it, so a group does not keep two versions of the truth.
- Reconcile counts. Compare what you submitted with what the platform shows, and investigate differences the same day.
- Version the schema. Record which schema and circular version produced each file.
- Keep a downtime path. Know what happens to a claim that cannot be sent, and who is told.
How Ventrecs approaches e-claims
The Ventrecs insurance module holds the claim lifecycle that these platforms depend on: payers and plans, coverage with a priority, pre-authorisation with its approval number and validity, one draft claim per encounter and coverage, the payer's response applied to each line, and an invoice for what was accepted. Claims export as CSV for portal upload and as a FHIR R4 Claim.
The country e-claim formats are not built into that module. They belong in an interface adapter for each jurisdiction, so Ventrecs scopes a Shafafiya or DHPO adapter per project, with a durable outbox, retry and a transaction log, and tests it in the operator's environment before go-live. We do not claim that Ventrecs is approved by either platform.
Sources
- Shafafiya web services technical definition, version 3.5, Department of Health
- Shafafiya, Department of Health Abu Dhabi
- eClaimLink, Dubai Health Authority
- DHPO XML schema: Prior.Authorization
Frequently asked questions
Is there one UAE platform for claims?
No. Abu Dhabi uses Shafafiya and Dubai uses eClaimLink with the DHPO gateway. A group with facilities in both emirates integrates with both.
What format do they use?
Both exchange structured XML transactions: claims, prior requests and authorisations, and remittance advice. Each publishes its own schema and rules.
How does Shafafiya work technically?
As a post office. A sender uploads a transaction file through a web service, the platform validates it and returns errors, and the receiver downloads it. There is no web page for uploading files.
Does Ventrecs include the UAE claim formats?
They are not built into the insurance module. A Shafafiya or DHPO adapter is scoped per project, with the facility, and tested in the operator's environment before go-live.
Related Ventrecs pages
- Insurance and claims Payers, plans, pre-authorisation, eligibility checks and claims.
- Integrations How Ventrecs scopes, tests and supports each connection.
- Ventrecs Connect The governed integration hub: monitoring, retries and reconciliation.
- Solutions by provider type Medical centres, laboratories, imaging centres, pharmacy groups and hospital networks.
Planning a deployment?
Tell us which emirates you operate in and how your claims run today. We can map the transactions, the codes and the owners before an e-claims adapter is scoped.
More insights
- Healthcare interoperability in the UAE: a map of Malaffi, NABIDH, Riayati, Shafafiya and DHPO Interoperability in the UAE is shaped by more than one authority. Start by mapping which platform does what, and who owns it.
- NPHIES integration guide: how FHIR R4 messaging works for Saudi providers and software vendors NPHIES connects Saudi healthcare providers and insurers through FHIR R4 messages. This is how the exchange works and what a hospital system has to be ready for.
- Healthcare integration readiness: scope every interface before go-live Most delays in a healthcare deployment come from interfaces nobody scoped. Use this guide to agree each connection, its owner and how it is tested before go-live.