--- { "title": "Connectathon CMS HL7 FHIR 2026 : résultats sur la réduction du fardeau administratif et PDex", "description": "Health Samurai a participé à deux volets du 7e Connectathon annuel CMS HL7 FHIR : la réduction du fardeau administratif et PDex Assureur-à-Assureur. Voici ce que nous avons testé et ce que nous avons appris.", "date": "2026-07-28", "author": "Health Samurai Team", "reading-time": "5 min read", "tags": ["Integrations", "Compliance"], "utm-campaign": "events", "utm-content": "connectathon-2026" } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- 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.