NPHIES · Arabie saoudite
Des demandes de remboursement qui quittent le dossier en parlant déjà NPHIES.
Le rail national saoudien est intégré au dossier plutôt que plaqué dessus. Admissibilité, pré-autorisation, soumission des demandes et avis de remboursement sont tous assemblés en bundles FHIR R4 à partir de la consultation que votre clinicien a déjà documentée.
- Bundles FHIR R4
- Admissibilité et pré-autorisation
- Décision ligne par ligne
- Import des avis de remboursement
Ce qu'est NPHIES
L'échange national par où passe chaque demande saoudienne.
NPHIES est la plateforme nationale saoudienne d'échange d'assurance maladie. Prestataires et payeurs s'y retrouvent pour confirmer la couverture d'un patient, demander une approbation avant un acte coûteux, déposer la demande ensuite et régler ce qui est dû. Elle repose sur FHIR R4 : chaque message est un bundle de ressources standard plutôt qu'un format de fichier propriétaire.
Cela compte pour une clinique parce que cela supprime la couche de traduction. The Clinic construit un CoverageEligibilityRequest, un Claim avec use=preauthorization ou un Claim avec use=claim directement à partir des données patient, couverture et consultation déjà dans le dossier — les mêmes ressources Patient et Coverage, portant l'identifiant national sous le système d'identifiants NPHIES, dans un seul bundle.
Rien n'est ressaisi dans un portail de payeur et rien n'est exporté vers un tableur entre les deux. Le rail est résolu par clinique à partir de la juridiction définie dans les paramètres régionaux : une clinique saoudienne obtient NPHIES automatiquement et une clinique ailleurs ne le voit jamais.
Admissibilité et pré-autorisation
Confirmez la couverture et obtenez l'approbation avant que le fauteuil ne soit occupé.
Une demande d'admissibilité est assemblée en bundle CoverageEligibilityRequest — validation de l'objet et prestations — aux côtés des ressources Patient et Coverage qu'elle référence, avec la pièce d'identité nationale du patient portée sous le système d'identifiants NPHIES. La pré-autorisation réutilise le même générateur : c'est un Claim FHIR avec use défini à preauthorization, si bien qu'une demande d'approbation et la demande qui la suit ne peuvent jamais diverger.
- CoverageEligibilityRequest construit depuis le dossier patient, sans resaisie
- La pré-autorisation est un Claim avec use=preauthorization, partageant le générateur de demandes
- Pièce d'identité nationale portée sous le système d'identifiants NPHIES
- Des contrôles de structure s'exécutent sur un bundle d'exemple avant la mise en production
Soumission des demandes
Une réponse de payeur exploitable, ligne par ligne.
Les demandes partent en bundles Claim FHIR R4 avec articles valorisés. Quand NPHIES répond par un ClaimResponse, sa décision par article est mise en attente contre votre demande — autorisé, payable, part du patient, code et motif de refus pour chaque ligne. Cette décision mise en attente est traitée comme un avis sur l'argent, jamais comme un dépôt : le règlement n'a lieu qu'à l'arrivée de l'avis de remboursement.
- Articles Claim FHIR valorisés construits depuis les lignes de facture
- Détail par ligne — autorisé, payable, part du patient, refus — mis en attente
- Une demande refusée revient en portant les motifs propres du payeur
- Une ligne sans code d'acte ne peut être valorisée — elle est nommée dans un avertissement, jamais abandonnée en silence
Preuve de livraison
Un dépassement de délai n'est pas un échec, et ce n'est jamais une seconde demande.
Chaque transmission est classée plutôt que devinée. Un 2xx portant un ClaimResponse lisible est un dépôt. Un OperationOutcome est un refus, avec les motifs du payeur joints. Un 5xx, ou une requête qui dépasse la fenêtre de trente secondes, n'est ni l'un ni l'autre : le payeur a peut-être stocké la demande avant de ne pas répondre, donc la tentative est enregistrée comme livraison inconnue et la resoumission est bloquée jusqu'à ce qu'une personne confirme auprès du payeur.
- Transmise, rejetée, livraison inconnue et construite seule sont quatre issues différentes
- La livraison inconnue bloque une nouvelle tentative : une demande ne peut être déposée deux fois
- Le bundle exact envoyé est conservé comme preuve à côté de la réponse
- Les transmissions de bac à sable sont résolues comme telles et ne ressemblent jamais à de vrais dépôts
Couverture NPHIES dans la passerelle
- FHIR R4
- format de message
- 4
- types de transactions construits
- 30 s
- fenêtre de réponse du payeur
- 0
- nouvelles tentatives à l'aveugle après un dépassement
Avant votre première demande réelle
Ce qu'une clinique saoudienne doit configurer.
Le rail est du code ; l'inscription est la vôtre. Voici les champs dont la plateforme a besoin avant de pouvoir construire et envoyer un vrai message NPHIES, tous à saisir dans Paramètres → Intégrations → Rails d'assurance.
- 01
Juridiction
Définissez la juridiction de la clinique sur Arabie saoudite dans les Paramètres régionaux. Elle est requise à la création de la clinique et c'est elle qui sélectionne NPHIES comme rail de demandes pour tout ce que la clinique dépose.
- 02
Point de terminaison et environnement
Chaque configuration de rail appartient à un seul environnement. Pointez d'abord la configuration de bac à sable vers votre point de terminaison de test NPHIES ; la production est une ligne séparée avec son propre point de terminaison et ses propres identifiants.
- 03
Identifiants API
La clé porteur que NPHIES délivre à votre organisation. Les identifiants de rail sont chiffrés par clinique, ne sont jamais placés dans un fichier d'environnement et ne sont jamais renvoyés au navigateur.
- 04
Identifiant de prestataire
Votre identifiant d'organisation NPHIES. Il est référencé comme prestataire sur chaque demande d'admissibilité, pré-autorisation et demande de remboursement que la clinique construit.
- 05
Identifiants de payeurs
Les assureurs avec lesquels vous êtes sous contrat. Le premier payeur configuré est référencé comme assureur sur une requête quand la demande elle-même n'en nomme pas.
- 06
Contrôle de disponibilité
Exécutez le rapport de disponibilité du rail avant la mise en production. Il construit un bundle d'exemple d'admissibilité, de pré-autorisation et de demande et vérifie que chacun porte les ressources et références requises — un écart est signalé, jamais masqué.
Les limites, dites honnêtement
Ce que le rail NPHIES ne fait pas encore.
Le nommer coûte moins cher que de le découvrir pendant l'inscription. Ce sont de vraies lacunes de la passerelle actuelle, pas du futur habillé en présent.
Les réponses d'admissibilité ne sont pas décomposées
La requête est construite, validée et transmise, et la réponse du payeur est conservée en entier avec le contrôle. Le détail des prestations n'est pas encore ventilé pour vous en champs de couverture structurés.
Pas d'interrogation du statut des demandes
Il n'existe pas d'interrogation pour demander à NPHIES où en est une demande déposée. Le statut vous parvient par la réponse du payeur à la soumission et par l'avis de remboursement.
Les cartes de terminologie sont amorcées, pas complètes
Le codage est vérifié avant qu'un message soit construit, et un code sans correspondance est levé bruyamment plutôt que transmis. Attendez-vous à étendre les cartes de codes avec votre propre catalogue pendant l'inscription.
Le bac à sable d'abord, toujours
Les identifiants de production sont une configuration séparée. Rien dans une transmission de bac à sable n'est présenté comme un dépôt réel, et elle ne règle jamais d'argent.
Questions NPHIES
Ce que les cliniques demandent avant de s'inscrire.
The Clinic est-il intégré à NPHIES ?
La passerelle NPHIES est intégrée à la plateforme : elle construit les bundles FHIR R4 d'admissibilité, de pré-autorisation et de demande à partir du dossier de la clinique et les envoie au point de terminaison que vous configurez. Ce qu'elle ne peut pas faire, c'est vous inscrire — le point de terminaison, la clé API et votre identifiant de prestataire viennent de NPHIES, et tant qu'ils ne sont pas saisis, la plateforme construit et valide les messages sans les transmettre.
Quelles transactions NPHIES la plateforme peut-elle envoyer ?
Les demandes d'admissibilité de couverture, les demandes de pré-autorisation (un Claim FHIR avec use=preauthorization) et les soumissions de demandes (un Claim avec use=claim). L'avis de remboursement circule dans l'autre sens : un bundle PaymentReconciliation avec ses ressources ClaimResponse est analysé en détail de paiement, d'ajustement et de refus par ligne et importé contre les demandes d'origine.
Que se passe-t-il si NPHIES ne répond pas ?
La requête a une fenêtre de trente secondes. Si elle expire, ou si le payeur renvoie un 5xx, la livraison est réellement inconnue — la demande a peut-être été stockée avant l'échec. Cette tentative est enregistrée comme livraison inconnue et bloque la resoumission jusqu'à ce que quelqu'un confirme auprès du payeur, car une relance à l'aveugle, c'est ainsi qu'une clinique dépose deux fois la même demande.
Une réponse de payeur crédite-t-elle le grand livre ?
Non. Un ClaimResponse renvoyé à la soumission est mis en attente comme décision par ligne — un avis sur l'argent. L'argent ne bouge que par le chemin de l'avis de remboursement, quand le paiement arrive réellement, pour qu'une réponse qui change ensuite ne laisse pas un dépôt fantôme derrière elle.
Où les identifiants NPHIES sont-ils stockés ?
Chiffrés, par clinique, contre la configuration de rail de cette clinique. Ils sont saisis dans Paramètres → Intégrations → Rails d'assurance, ne sont jamais placés dans un fichier d'environnement, et le rapport de disponibilité nomme quelles clés d'identifiants sont définies sans renvoyer leurs valeurs.
Une seule plateforme peut-elle servir des cliniques en Arabie saoudite et ailleurs ?
Oui. Le rail est résolu par clinique selon sa juridiction : une filiale saoudienne dépose via NPHIES, une filiale de Dubaï via eClaimLink et une filiale ontarienne construit un lot OHIP — avec des identifiants séparés et aucune visibilité inter-locataires.
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.
- eClaimLink (DHPO Dubaï)
Comment un établissement de Dubaï dépose un Claim.Submission via le DHPO.
- 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.