eClaimLink · Dubaï
Des demandes de Dubaï, construites selon le schéma DHPO et téléversées en entier.
La poste de santé de Dubaï échange des transactions XML via un téléversement SOAP, pas un formulaire web. The Clinic assemble Claim.Submission et Prior.Request à partir de la consultation, vérifie d'abord le codage et enregistre exactement ce qu'eClaimLink a répondu.
- Claim.Submission XML
- Pré-approbation Prior.Request
- DHA CodingSets vérifiés
- Résultat de téléversement enregistré
Ce qu'est eClaimLink
Le canal obligatoire de Dubaï entre prestataires et payeurs.
eClaimLink est le cadre de télédéclaration des demandes de la Dubai Health Authority, et le DHPO — la poste de santé de Dubaï — est l'échange vers lequel chaque établissement participant téléverse. Ce n'est ni une API REST ni un portail où coller des chiffres : les transactions sont des documents XML, téléversés en entier avec votre identifiant d'établissement via le service UploadTransaction du DHPO.
The Clinic construit ces documents. Un Claim.Submission porte un en-tête avec vos identifiants d'expéditeur et de destinataire et le fanion de disposition de l'environnement visé, puis une demande par consultation avec son numéro de membre, sa consultation, ses diagnostics et ses actes valorisés. Un Prior.Request reprend la même forme pour une approbation dont vous avez besoin avant de traiter.
Puisque la transaction est un fichier plutôt qu'une conversation, le travail utile se passe avant le téléversement — et c'est exactement là que se placent les contrôles de codage.
Claim.Submission
Une transaction DHPO assemblée depuis la consultation, pas depuis un tableur.
Les diagnostics sont émis en ICD-10-CM avec le premier marqué Principal et les autres Secondaire. Chaque ligne facturable devient une Activity portant le type d'activité DHPO de son système de codage — CPT, HCPCS, médicament, CDT dentaire, service, DRG ou scientifique — avec sa quantité, son montant net, sa date de prestation et la licence du clinicien issues de votre configuration de rail. Le fanion de disposition de la transaction suit l'environnement, si bien qu'un téléversement de test ne peut être pris pour un téléversement de production.
- Diagnostics ICD-10-CM, Principal et Secondaire, directement depuis le dossier
- Les actes portent le type d'activité DHPO correct pour leur système de codage
- La numérotation des actes suit la ligne de demande conservée, si bien qu'une ligne abandonnée ne renumérote jamais les autres
- Les fanions de disposition TEST et PRODUCTION suivent l'environnement configuré
Le codage
Un code sans correspondance arrête la transaction. Elle ne part pas.
Le codage de Dubaï fait autorité : les DHA CodingSets décident quel code appartient à quel type d'activité. La plateforme fait correspondre vos codes internes d'actes et de diagnostics via un service de terminologie partagé avant qu'une seule ligne de XML ne soit écrite, et un code sans correspondance lève une erreur au lieu d'être envoyé au hasard. C'est la différence entre un rejet que vous trouvez à la construction et un que vous trouvez des semaines plus tard sur un rapport de validation.
- Codes internes mis en correspondance via un service de terminologie partagé par juridiction
- Type d'activité dérivé du système de codage, jamais supposé
- Un code sans correspondance est une erreur de construction bruyante, pas une transmission silencieuse
- Les cartes amorcées sont étendues avec vos propres DHA CodingSets à l'inscription
Résultat du téléversement
Ce que le DHPO a dit, enregistré selon ce que cela signifie.
La transaction est encodée en base64 et téléversée via le service SOAP du DHPO avec votre identifiant d'établissement. La réponse est un code de résultat, et la plateforme le lit plutôt que de supposer le succès : zéro est accepté, un est accepté avec avertissements, moins un est un échec d'authentification et moins deux est un échec de validation dont le rapport revient joint. Un code négatif est enregistré comme un rejet — la transaction corrigée peut donc être soumise à nouveau au lieu d'être bloquée derrière un dépôt qui n'a jamais eu lieu.
- Codes de résultat de téléversement lus et classés, jamais déduits d'un 2xx
- Un échec de validation conserve le rapport propre du DHPO avec la tentative
- Un rejet laisse la demande resoumissible ; une livraison inconnue, non
- Une réponse que la passerelle ne peut interpréter est une livraison inconnue, pas un succès
Couverture eClaimLink dans la passerelle
- 2
- transactions DHPO construites
- 7
- types d'actes mis en correspondance
- 30 s
- fenêtre de réponse au téléversement
- 0
- codes de résultat devinés
Avant votre premier téléversement
Ce qu'un établissement de Dubaï doit configurer.
L'accès au DHPO est délivré par établissement, et la plateforme construit mais ne transmet pas tant qu'elle n'a pas ces éléments. Tous se trouvent dans Paramètres → Intégrations → Rails d'assurance.
- 01
Juridiction
Définissez la juridiction de la clinique sur Émirats arabes unis dans les Paramètres régionaux. C'est ce qui achemine ses demandes vers eClaimLink plutôt que vers un autre rail.
- 02
Identifiant d'établissement
Le nom d'utilisateur et le mot de passe DHPO délivrés à votre établissement. Sans les deux, les transactions sont construites et validées localement et rien n'est téléversé — la passerelle signale cet état plutôt que de prétendre envoyer.
- 03
Point de terminaison et environnement
Bac à sable et production sont des configurations séparées. L'environnement décide aussi du fanion de disposition de la transaction, si bien qu'un fichier de test est étiqueté comme tel à l'intérieur du XML lui-même.
- 04
Identifiants d'établissement et de payeur
Votre identifiant d'expéditeur DHPO et l'identifiant de destinataire du payeur auprès duquel vous déposez. Ils apparaissent dans l'en-tête de la transaction et sur chaque demande qu'elle contient.
- 05
Licence du clinicien
La licence DHA du clinicien consignée sur chaque Activity. Si elle manque, l'identifiant de prestataire est utilisé en repli et la substitution est signalée en avertissement plutôt que masquée.
- 06
Emirates ID
Les demandes portent actuellement le repli de carte inconnue DHA pour l'Emirates ID, et chaque soumission le dit dans ses avertissements. Prévoyez de fournir l'Emirates ID du patient pendant l'inscription pour que ce point soit réglé avant la mise en production.
Les limites, dites honnêtement
Ce que le rail eClaimLink ne fait pas encore.
La passerelle de Dubaï dépose des demandes et des requêtes préalables. Voici les quatre choses qu'elle ne fait pas, et il vaut mieux le lire ici que le découvrir à l'inscription.
Pas de vérification d'admissibilité
Un Prior.Request de type Eligibility n'est pas implémenté. La couverture est confirmée comme votre établissement le fait aujourd'hui ; la plateforme ne demande pas encore au DHPO.
Pas de téléchargement des avis de remboursement
La récupération et l'analyse des Remittance.Advice ne sont pas construites, si bien que les paiements sont rapprochés depuis vos propres enregistrements plutôt que tirés du DHPO. NPHIES et OHIP ont tous deux un chemin d'avis de remboursement ; Dubaï pas encore.
Pas d'interrogation du statut des demandes
Il n'existe pas d'interrogation de statut auprès du DHPO. Ce que vous savez d'une transaction, c'est son résultat de téléversement et tout rapport de validation qui y est joint.
Par lots, pas en temps réel
Le DHPO est un échange par téléversement. Une transaction est acceptée pour traitement plutôt que décidée sur le moment, donc il n'y a pas de réponse de payeur par ligne à la soumission comme sur NPHIES.
Questions eClaimLink
Ce que les établissements de Dubaï demandent avant de s'inscrire.
The Clinic soumet-il des demandes à eClaimLink ?
Il construit un Claim.Submission DHPO depuis la consultation et le téléverse via le service UploadTransaction du DHPO avec votre identifiant d'établissement. Tant que cet identifiant n'est pas configuré, la transaction est toujours construite et validée — vous voyez exactement ce qui serait envoyé — mais rien n'est transmis, et l'enregistrement le dit.
Quelle est la différence entre eClaimLink et le DHPO ?
eClaimLink est le cadre de télédéclaration de la Dubai Health Authority ; la poste de santé de Dubaï est le point de terminaison d'échange qui reçoit les transactions. En pratique, un établissement s'inscrit auprès d'eClaimLink puis téléverse vers le DHPO, avec qui dialogue la passerelle.
Peut-on demander une approbation préalable avant de traiter ?
Oui. Une transaction Prior.Request est construite avec la même consultation, les mêmes diagnostics et les mêmes actes valorisés qu'une demande, si bien que l'approbation demandée et la demande déposée ensuite décrivent le même traitement plutôt que deux versions saisies indépendamment.
Que se passe-t-il si un code n'a pas de correspondance DHA ?
La construction s'arrête et nomme le code. Deviner un type d'activité produirait une transaction qui se téléverse proprement et est rejetée des jours plus tard sur un rapport de validation, donc un code sans correspondance est traité comme une erreur à l'endroit où quelqu'un peut encore la corriger.
Comment sait-on qu'une demande est réellement arrivée au DHPO ?
Par son code de résultat, conservé avec la tentative. Zéro et un sont acceptés ; moins un et moins deux signifient que le DHPO a refusé le téléversement, et la demande reste resoumissible. Une réponse que la passerelle ne peut pas du tout lire est enregistrée comme livraison inconnue — jamais comme un succès.
A-t-on encore besoin de NABIDH si l'on dépose via eClaimLink ?
Ils répondent à des obligations différentes. eClaimLink porte l'argent ; NABIDH porte le dossier clinique. Un établissement de Dubaï a généralement besoin des deux, et la plateforme publie l'ensemble d'événements NABIDH HL7 v2.5 aux côtés de ses dépôts de demandes eClaimLink.
En lien
Le reste de la surface d'interopérabilité.
- Standards et échanges
FHIR R4, NABIDH sur HL7 v2.5 et imagerie DICOMweb en un seul endroit.
- NPHIES (Arabie saoudite)
Admissibilité, pré-autorisation, demandes de remboursement et avis de remboursement sur FHIR R4.
- OHIP (Ontario MCEDT)
Comment une clinique ontarienne construit et soumet un lot de demandes MCEDT.
Prêt à essayer The Clinic
Voyez-le piloter votre clinique en 30 minutes.
Réservez une démo personnalisée. Nous utiliserons les véritables flux de travail de votre clinique — pas une visite générique.
Aucune carte bancaire. Aucune diapositive. 30 minutes.