eClaimLink · Dubai
Dubai claims, built to the DHPO schema and uploaded whole.
The Dubai Health Post Office speaks XML transactions over a SOAP upload, not a web form. The Clinic assembles Claim.Submission and Prior.Request from the encounter, checks the coding first, and records exactly what eClaimLink answered.
- Claim.Submission XML
- Prior.Request pre-approval
- DHA CodingSets checked
- Upload result recorded
What eClaimLink is
Dubai's mandated channel between providers and payers.
eClaimLink is the Dubai Health Authority's e-claims framework, and the DHPO — the Dubai Health Post Office — is the exchange every participating facility uploads to. It is not a REST API and not a portal you paste numbers into: transactions are XML documents, uploaded whole against your facility login through the DHPO's UploadTransaction service.
The Clinic builds those documents. A Claim.Submission carries a header with your sender and receiver identifiers and the disposition flag for the environment you are pointed at, then one claim per encounter with its member ID, encounter, diagnoses and priced activities. A Prior.Request carries the same shape for an approval you need before treating.
Because the transaction is a file rather than a conversation, the useful work happens before the upload — which is exactly where the coding checks sit.
Claim.Submission
A DHPO transaction assembled from the encounter, not from a spreadsheet.
Diagnoses are emitted as ICD-10-CM with the first marked Principal and the rest Secondary. Each billable line becomes an Activity carrying the DHPO activity type for its coding system — CPT, HCPCS, drug, dental CDT, service, DRG or scientific — with its quantity, net amount, service date and the clinician licence from your rail configuration. The transaction's disposition flag follows the environment, so a test upload cannot be mistaken for a production one.
- ICD-10-CM diagnoses, Principal and Secondary, straight from the chart
- Activities carry the correct DHPO activity type for their coding system
- Activity numbering follows the persisted claim line, so a dropped line never renumbers the rest
- TEST and PRODUCTION disposition flags follow the configured environment
Coding
An unmapped code stops the transaction. It does not travel.
Dubai coding is authoritative: the DHA CodingSets decide which code belongs to which activity type. The platform maps your internal procedure and diagnosis codes through a shared terminology service before a single line of XML is written, and a code with no mapping raises an error instead of being sent as a guess. That is the difference between a rejection you find at build time and one you find weeks later on a validation report.
- Internal codes mapped through a shared terminology service per jurisdiction
- Activity type derived from the coding system, never assumed
- An unmapped code is a loud build error, not a silent transmission
- Seed maps are extended with your own DHA CodingSets at enrolment
Upload result
What the DHPO said, recorded as what it means.
The transaction is base64-encoded and uploaded through the DHPO SOAP service with your facility login. The answer is a result code, and the platform reads it rather than assuming success: zero is accepted, one is accepted with warnings, minus one is a failed login and minus two is a validation failure whose report comes back attached. A negative code is recorded as a rejection — so the corrected transaction can be resubmitted rather than being blocked behind a filing that never happened.
- Upload result codes read and classified, never inferred from a 2xx
- A validation failure keeps the DHPO's own report against the attempt
- A rejection leaves the claim resubmittable; an unknown delivery does not
- A response the gateway cannot interpret is unknown delivery, not success
eClaimLink coverage in the gateway
- 2
- DHPO transactions built
- 7
- activity types mapped
- 30s
- upload response window
- 0
- guessed result codes
Before your first upload
What a Dubai facility has to configure.
DHPO access is issued per facility, and the platform builds but does not transmit until it has these. All of them live in Settings → Integrations → Insurance rails.
- 01
Jurisdiction
Set the clinic's jurisdiction to the United Arab Emirates in Regional Settings. That is what routes its claims to eClaimLink rather than to another rail.
- 02
Facility login
The DHPO username and password issued to your facility. Without both, transactions are built and validated locally and nothing is uploaded — the gateway reports that state rather than pretending to send.
- 03
Endpoint and environment
Sandbox and production are separate configurations. The environment also decides the transaction's disposition flag, so a test file is labelled as one inside the XML itself.
- 04
Facility and payer identifiers
Your DHPO sender identifier and the receiver identifier of the payer you are filing to. They appear in the transaction header and on every claim in it.
- 05
Clinician licence
The DHA clinician licence recorded against each Activity. If it is missing, the provider identifier is used as a fallback and the substitution is reported as a warning rather than hidden.
- 06
Emirates ID
Claims currently carry the DHA unknown-card fallback for the Emirates ID, and every submission says so in its warnings. Plan for supplying the patient's Emirates ID during enrolment so this is resolved before you go live.
The honest edges
What the eClaimLink rail does not do yet.
The Dubai gateway files claims and prior requests. These four things it does not do, and it is better to read that here than to discover it at enrolment.
No eligibility check
A Prior.Request of type Eligibility is not implemented. Coverage is confirmed the way your facility confirms it today; the platform does not yet ask the DHPO.
No remittance download
Remittance.Advice retrieval and parsing is not built, so payments are reconciled from your own records rather than pulled from the DHPO. NPHIES and OHIP both have a remittance path; Dubai does not yet.
No claim status inquiry
There is no status poll against the DHPO. What you know about a transaction is its upload result and any validation report attached to it.
Batch, not real time
The DHPO is an upload exchange. A transaction is accepted for processing rather than adjudicated in the moment, so there is no per-line payer answer at submission the way there is on NPHIES.
eClaimLink questions
What Dubai facilities ask before they enrol.
Does The Clinic submit claims to eClaimLink?
It builds a DHPO Claim.Submission from the encounter and uploads it through the DHPO's UploadTransaction service using your facility login. Until that login is configured the transaction is still built and validated — you can see exactly what would be sent — but nothing is transmitted, and the record says so.
What is the difference between eClaimLink and the DHPO?
eClaimLink is the Dubai Health Authority's e-claims framework; the Dubai Health Post Office is the exchange endpoint that receives the transactions. In practice a facility enrols with eClaimLink and then uploads to the DHPO, which is what the gateway talks to.
Can we request prior approval before treating?
Yes. A Prior.Request transaction is built with the same encounter, diagnoses and priced activities as a claim, so the approval you asked for and the claim you file afterwards describe the same treatment rather than two independently typed versions of it.
What happens if a code has no DHA mapping?
The build stops and names the code. Guessing an activity type would produce a transaction that uploads cleanly and is rejected days later on a validation report, so an unmapped code is treated as an error at the point where someone can still fix it.
How do we know a claim actually reached the DHPO?
By its result code, which is stored with the attempt. Zero and one are accepted; minus one and minus two mean the DHPO refused the upload, and the claim is left resubmittable. A response the gateway cannot read at all is recorded as unknown delivery — never as a success.
Do we still need NABIDH if we file through eClaimLink?
They answer different mandates. eClaimLink carries the money; NABIDH carries the clinical record. A Dubai facility typically needs both, and the platform publishes the NABIDH HL7 v2.5 event set alongside its eClaimLink claim filing.
Related
The rest of the interoperability surface.
- Standards and exchanges
FHIR R4, NABIDH over HL7 v2.5, and DICOMweb imaging in one place.
- NPHIES (Saudi Arabia)
Eligibility, pre-authorisation, claims and remittance on FHIR R4.
- OHIP (Ontario MCEDT)
How an Ontario clinic builds and submits an MCEDT claims batch.
Ready to try The Clinic
See it run your clinic in 30 minutes.
Book a personalized demo. We'll use your clinic's real workflows — not a generic walkthrough.
No credit card. No slides. 30 minutes.