Le 7e Connectathon annuel CMS HL7 FHIR s'est tenu du 14 au 16 juillet 2026 : un événement virtuel gratuit organisé par les Centers for Medicare & Medicaid Services (CMS) en collaboration avec HL7 International. Son objectif est le test pratique : les développeurs confrontent de véritables flux de travail FHIR les uns aux autres, résolvent ensemble les points de friction et prennent de l'avance sur les exigences d'interopérabilité de CMS et ONC qui entrent en vigueur prochainement.
Pour les régimes d'assurance santé, ces exigences suivent un calendrier précis. CMS-0057-F fait entrer en vigueur l'API d'autorisation préalable et l'API Payer-to-Payer le 1er janvier 2027.
Nous avons présenté Payerbox, notre plateforme de conformité FHIR pour les régimes d'assurance santé, dans deux volets : la réduction du fardeau et PDex, en effectuant des tests directement contre d'autres systèmes de payeurs et de fournisseurs. Voici ce que nous avons exécuté, ce qui a échoué et ce que nous avons modifié.
Volet Réduction du fardeau
Dans le volet Da Vinci Burden Reduction (CRD, DTR, et PAS : la pile d'autorisation préalable électronique), Payerbox jouait le rôle du payeur. Notre serveur hébergeait les services CDS Hooks, les questionnaires DTR et les opérations PAS, et les fournisseurs de DSE testaient leurs implémentations côté prestataire contre celui-ci. En deux jours, nous avons tenu des séances avec six fournisseurs de DSE : Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health et Altera Digital Health. Merci aux six équipes d'être venues bien préparées.
Le scénario commun portait sur une autorisation préalable pour une oxygénothérapie à domicile. Un hook CRD order-sign retourne une carte « autorisation préalable requise » accompagnée d'une action système coverage-information pointant vers un questionnaire DTR ; le clinicien remplit le formulaire prérempli, et le paquet résultant est transmis à Claim/$submit de PAS, qui retourne une ClaimResponse en quelques secondes. La décision de gestion de l'utilisation suit, et le DSE la récupère via $inquire.
Au-delà de ce parcours idéal, nous avons exercé les quatre hooks CRD qu'implémente Payerbox (order-sign, order-select, order-dispatch et appointment-book), $questionnaire-package de DTR, $inquire de PAS, $submit-attachment de CDex, ainsi que les flux de mise à jour et d'annulation de demande. La chaîne complète — de la carte CRD au formulaire DTR jusqu'à la soumission PAS — a fonctionné de bout en bout avec de véritables systèmes DSE la pilotant. Dans plusieurs exécutions, des identifiants générés dans notre réponse CRD nous ont été renvoyés à l'intérieur de la soumission PAS du partenaire. C'est une bonne preuve que les composants s'interconnectent, et cela a demandé un véritable effort d'ingénierie des deux côtés.
Ce que nous avons corrigé
Les clients DSE en direct ont produit une liste de défauts priorisée. Une catégorie de correctifs a été déployée en cours d'événement, le deuxième jour : nous avons assoupli la rigueur de validation de sorte que les discordances inoffensives dans les chaînes d'affichage et les références génèrent des avertissements plutôt que des blocages, tandis que les soumissions véritablement incomplètes reçoivent toujours une réponse d'erreur claire. Un contenu qui avait échoué lors d'une séance matinale a réussi lors d'une reprise le même après-midi.
Le reste a été résolu au cours des trois jours suivants :
- Annulation de demande de bout en bout, afin qu'une autorisation préalable annulée soit visible via
$inquire. - Les assertions de couverture ont été modifiées pour passer de décisions conditionnelles à des décisions définitives.
- Préremplissage des questionnaires : sept questionnaires ne se préremplissaient jamais en raison de contextes de lancement non liés, ce qui n'est apparu qu'au moment où de véritables clients DTR ont ouvert de vrais formulaires.
- Les requêtes de hook CRD portant
fhirServer: nullétaient rejetées là où une clé absente aurait été acceptée ; les nulls explicites sont désormais traités comme des clés absentes. - Fermeture du paquet PAS : les ressources résiduelles d'un échange CRD antérieur ne sont plus comptées comme des références connues du payeur, de sorte que
$submitrejette correctement un paquet qui n'est pas auto-contenu.
Ce que nous avons transmis aux partenaires
Nous avons fourni aux partenaires des notes sur l'auto-contenance du paquet PAS (quelles ressources référencées doivent voyager à l'intérieur du paquet de soumission) et sur la signalisation du lancement DTR dans CRD 2.1, où l'action système coverage-information remplace l'ancien modèle de lien par carte, ainsi que plusieurs observations de moindre importance sur les données de test.
Volet PDex
Dans le volet Da Vinci Payer Data Exchange (PDex), nous avons testé Payerbox contre trois autres systèmes : InterSystems, Hike Health et CareEvolution. Merci aux trois équipes d'avoir effectué des tests contre nous. L'objectif était le flux complet de payer à payer de bout en bout : l'appariement des membres via $bulk-member-match, suivi de l'exportation de données en masse via $davinci-data-export.
Les équipes qui s'intégraient contre nous ont produit leur propre liste priorisée. La plupart des points se regroupaient autour de quelques thèmes :
- aligner notre CapabilityStatement avec la façon dont l'IG s'attend à ce que les opérations PDex soient déclarées
- assouplir quelques contrôles stricts de validation et de corps de requête qui posaient problème aux partenaires
- resserrer nos filtres d'exportation en masse
- faciliter la lecture du routage basé sur le consentement des membres appariés lorsqu'un membre se retrouve contraint
Rien de structural. Ce sont les détails d'interopérabilité qui ne surgissent qu'au contact de contreparties en direct. Chacun est suivi comme un problème distinct et aucun n'est clos au moment de la publication, ce qui reflète honnêtement l'état d'un volet auquel nous avons participé précisément pour trouver ces éléments.
Nous avons également transmis des observations en retour : certaines implémentations n'effectuaient aucune validation de référence ou FHIR durant l'événement, et l'une d'elles présentait une discordance entre les décomptes d'appariement synchrone et asynchrone.
Accès aux prestataires
Le même volet couvre l'accès aux prestataires, l'une des quatre API de CMS-0057-F, et notre séance avec InterSystems englobait les deux. L'accès aux prestataires réutilise la majeure partie de la mécanique payer à payer : $provider-member-match résout les membres attribués à un prestataire demandeur, et le même $davinci-data-export livre leurs données de demandes de remboursement, cliniques et d'autorisation préalable. Il vaut la peine d'être explicite sur la forme, car c'est là que les payeurs doivent le plus souvent revoir leur conception : il s'agit d'une exportation en masse sur un groupe attribué, et non d'une consultation par patient à la demande. La liste de défauts ci-dessus provient des scénarios payer à payer.
Ce que cela signifie pour les payeurs
CMS-0057-F ne comporte pas d'examen. Il n'existe pas d'organisme de test accrédité ni de suite de tests obligatoire comme c'est le cas pour les DSE certifiés par ONC, et des outils de conformité comme Touchstone existent mais ne sont pas obligatoires. Rien ne certifie donc qu'une API d'autorisation préalable ou Payer-to-Payer fonctionne. La seule preuve, c'est qu'elle a été exécutée contre des contreparties que vous ne contrôlez pas.
C'est ce qu'apporte un connectathon, et c'est pourquoi les listes de défauts ci-dessus constituent la partie utile de cet article. Chaque élément provient du contenu d'un partenaire, et non de notre propre suite de tests : un contexte de lancement non lié qui laissait un questionnaire vide, un paquet qui semblait auto-contenu jusqu'à ce qu'un vrai DSE l'envoie, un null là où notre schéma attendait une clé absente. Rien de tout cela n'est détectable en testant contre soi-même.
Ainsi, lorsque vous évaluez la préparation — la vôtre ou celle d'un fournisseur — c'est la question qui vaut la peine d'être posée avant janvier 2027 : contre quelles contreparties en direct cela a-t-il été mis à l'épreuve, et qu'est-ce qui a échoué quand elles l'ont rencontré ?
Essayez par vous-même
Vous souhaitez tester contre Payerbox de la même façon que nos partenaires de connectathon l'ont fait ? Nous pouvons vous configurer les scénarios que nous avons exécutés durant l'événement : appariement des membres et exportation en masse du côté PDex, CRD, DTR et PAS du côté Réduction du fardeau. Demandez l'accès et nous vous aiderons à démarrer.
Si vous construisez un échange payer à payer ou une autorisation préalable électronique sur FHIR et souhaitez simplement comparer vos expériences, communiquez avec nous. Nous aimerions avoir de vos nouvelles.
