|
5 min de lecture
|

Connectathon CMS HL7 FHIR 2026 : résultats sur la réduction du fardeau administratif et PDex

Résumer cet article avec :
ChatGPTPerplexityClaudeGrok

Le 7e Connectathon annuel CMS HL7 FHIR s'est déroulé 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 de réaliser des tests concrets : les équipes de mise en œuvre confrontent de véritables flux de travail FHIR les uns aux autres, résolvent ensemble les problèmes rencontrés et prennent de l'avance sur les exigences à venir en matière d'interopérabilité imposées par CMS et ONC.

Cette année, nous avons participé à deux volets — Burden Reduction et PDex Payer-to-Payer — en testant nos mises en œuvre directement contre d'autres systèmes d'assureurs et de fournisseurs. Voici un résumé du déroulement de chacun.

Volet Burden Reduction

Dans le volet Burden Reduction de Da Vinci (CRD, DTR et PAS — la pile d'autorisation préalable électronique), nous étions du côté de l'assureur : notre serveur hébergeait les hooks CDS, les questionnaires DTR et les opérations PAS, et des fournisseurs de DSE ont testé leurs mises en œuvre côté prestataire contre celui-ci. Sur deux jours, nous avons mené des sessions avec Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health et Altera Digital Health. Merci à tous pour la qualité des tests préparés. Le scénario partagé portait sur une autorisation préalable d'oxygénothérapie à domicile : un hook order-sign de CRD renvoie une carte « autorisation préalable requise » assortie d'une action système d'information sur la couverture pointant vers un questionnaire DTR, le clinicien remplit le formulaire prérempli, et le paquet résultant est transmis à PAS Claim/$submit, où il est adjugé en quelques secondes. Au-delà de ce chemin nominal, nous avons exercé les quatre hooks CRD, $questionnaire-package de DTR, $inquire de PAS, $submit-attachment de CDex, ainsi que les flux de mise à jour et d'annulation de réclamation. La chaîne complète — de la carte CRD au formulaire DTR jusqu'à la soumission PAS — s'est exécutée de bout en bout avec de véritables systèmes DSE comme pilotes. Dans plusieurs exécutions, des identifiants générés dans notre réponse CRD nous sont revenus à l'intérieur de la soumission PAS du partenaire. C'est une bonne preuve que les pièces s'emboîtent, et cela a demandé un véritable effort d'ingénierie des deux côtés.

Comme pour PDex, les tests contre de véritables systèmes nous ont fourni une liste concrète et priorisée d'améliorations, dont la plupart ont été corrigées et redéployées pendant l'événement lui-même. Un contenu qui échouait lors d'une session matinale réussissait souvent à la reprise l'après-midi même. Voici quelques exemples : un même code HCPCS peut arriver sous plusieurs graphies d'URI, aussi avons-nous appris à la correspondance de politiques à les canoniser plutôt qu'à dépendre de la version utilisée par le DSE. Nous avons ajusté la rigueur de la validation, de sorte que les divergences inoffensives de chaînes d'affichage et de références déclenchent désormais des avertissements plutôt que des blocages, tandis que les soumissions véritablement incomplètes reçoivent toujours une réponse d'erreur claire. Nous avons également modifié les assertions de couverture pour en faire des décisions définitives et corrigé des problèmes de préremplissage des questionnaires qui ne se manifestaient qu'à l'ouverture de vrais formulaires par de vrais clients DTR.

L'échange a été bidirectionnel ici aussi. Nous avons transmis à nos partenaires des notes sur l'auto-contenance des paquets PAS (les ressources référencées qui doivent être incluses dans le paquet de soumission) et sur la signalisation du lancement DTR dans CRD 2.1, où l'action système d'information sur la couverture a remplacé l'ancien modèle de lien par carte, ainsi que quelques observations sur les données de test. Deux problèmes que nous avons tracés en aval de notre propre code ont été signalés en amont à notre fournisseur de plateforme FHIR.

Volet PDex Payer-to-Payer

Dans le volet Payer Data Exchange (PDex) Payer-to-Payer de Da Vinci, nous avons testé notre mise en œuvre contre trois autres systèmes : InterSystems, Hike Health et CareEvolution. Merci aux participants d'avoir testé notre solution. L'objectif était d'exercer le flux complet d'assureur à assureur de bout en bout — correspondance des membres via $bulk-member-match, suivie de l'exportation de données en masse via $davinci-data-export.

Les tests contre de véritables systèmes ont fait ressortir une liste concrète et priorisée d'améliorations de la part des équipes qui s'intégraient à nous. La majorité des retours se regroupaient autour de quelques thèmes : aligner notre CapabilityStatement avec la manière dont l'IG s'attend à ce que les opérations PDex soient déclarées, assouplir quelques vérifications strictes de validation et de corps de requête qui gênaient les partenaires, resserrer nos filtres d'exportation en masse, et rendre le routage basé sur le consentement des membres correspondants plus facile à comprendre lorsqu'un membre se retrouve contraint. Aucun de ces points n'est de nature structurelle ; ce sont les détails d'interopérabilité qui n'apparaissent que lors de tests contre de véritables systèmes, et nous les traitons actuellement.

Nous avons également transmis quelques observations à nos partenaires de test : par exemple, certaines mises en œuvre n'effectuaient aucune validation de référence ou FHIR durant l'événement, et l'une d'elles présentait une divergence entre les décomptes de correspondances synchrones et asynchrones. Cet échange bidirectionnel est précisément l'intérêt d'un connectathon : chaque équipe repart avec un carnet de travail plus clair et plus actionnable.

Essayez par vous-même

Vous souhaitez tester notre mise en œuvre de la même façon que l'ont fait nos partenaires au connectathon ? Nous pouvons vous préparer les mêmes scénarios que ceux que nous avons exécutés durant l'événement : correspondance des membres et exportation en masse du côté PDex, et le flux CRD, DTR et PAS du côté Burden Reduction. Communiquez avec nous et nous vous aiderons à démarrer.

Et si vous développez un échange assureur-à-assureur ou une autorisation préalable électronique sur FHIR et souhaitez simplement comparer vos approches, nous serions ravis d'échanger avec vous également.

Partager cet article
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.