--- { "title": "2026 CMS HL7 FHIR Connectathon: Burden Reduction and PDex Results", "description": "Health Samurai took part in two tracks at the 7th Annual CMS HL7 FHIR Connectathon: Burden Reduction and PDex Payer-to-Payer. Here is what we tested and what we learned.", "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. --- The **7th Annual CMS HL7 FHIR Connectathon** ran July 14–16, 2026, a free, virtual event organized by the Centers for Medicare & Medicaid Services (CMS) together with HL7 International. Its purpose is hands-on testing: implementers put real FHIR workflows against each other, work through the rough edges together, and get ahead of the upcoming CMS and ONC interoperability requirements. We joined two tracks this year, **Burden Reduction** and **PDex Payer-to-Payer**, testing our implementations directly against other payer and vendor systems. Below is a summary of how each went. ## Burden Reduction Track In the Da Vinci **Burden Reduction** track (CRD, DTR, and PAS - the electronic prior authorization stack) we were on the payer side: our server hosted the CDS hooks, DTR questionnaires, and PAS operations, and EHR vendors tested their provider-side implementations against it. Over two days we ran sessions with **Epic**, **MEDITECH**, **Darena Health**, **MEDHOST**, **Oracle Health**, and **Altera Digital Health**. Thank you all for the well-prepared testing. The shared scenario was a Home Oxygen Therapy prior authorization: a CRD `order-sign` hook returns a "prior authorization required" card with a coverage-information system action pointing at a DTR questionnaire, the clinician completes the prepopulated form, and the resulting bundle goes to PAS `Claim/$submit`, where it gets adjudicated within seconds. Beyond that happy path we exercised all four CRD hooks, DTR `$questionnaire-package`, PAS `$inquire`, CDex `$submit-attachment`, and the claim update and cancel flows. The full chain, from CRD card to DTR form to PAS submission, ran end to end with real EHR systems driving it. In several runs, identifiers minted in our CRD response came back to us inside the partner's PAS submission. That is good proof that the pieces connect, and it took real engineering effort on both sides. As with PDex, testing against real systems gave us a concrete, prioritized list of improvements, and we fixed and redeployed most of them during the event itself. A payload that failed in a morning session often passed on replay the same afternoon. Some examples: the same HCPCS code can arrive under several URI spellings, so we taught policy matching to canonicalize them instead of depending on which one the EHR uses. We tuned validation strictness, so harmless display-string and reference mismatches now warn instead of block, while genuinely incomplete submissions still get a clean error response. We also changed coverage assertions to definite decisions and fixed questionnaire prepopulation issues that only came up when real DTR clients opened real forms. The exchange went both ways here too. We sent partners notes on PAS bundle self-containment (which referenced resources must travel inside the submission bundle) and on DTR launch signaling in CRD 2.1, where the coverage-information system action replaced the older card-link pattern, plus a few smaller test-data observations. Two issues we traced below our own code and reported upstream to our FHIR platform vendor. ## PDex Payer-to-Payer Track In the Da Vinci **Payer Data Exchange (PDex)** Payer-to-Payer track, we tested our implementation against three other systems: **InterSystems**, **Hike Health**, and **CareEvolution**. Thank you participants for testing our solution. The goal was to exercise the full payer-to-payer flow end to end - member matching via `$bulk-member-match`, followed by bulk data export via `$davinci-data-export`. Testing against real systems surfaced a concrete, prioritized list of improvements from the teams integrating against us. Most of the feedback clustered around a few themes - aligning our CapabilityStatement with how the IG expects PDex operations to be declared, loosening a couple of strict validation and request-body checks that got in partners' way, tightening our bulk-export filters, and making the consent-based routing of matched members easier to understand when a member ends up constrained. None of them are structural; they are the kind of interoperability details that only show up when you test against real systems, and we are working through them now. We also fed a few observations back to our testing partners, for example, some implementations performed no reference or FHIR validation during the event, and one showed a mismatch between synchronous and asynchronous matching counts. That two-way exchange is the point of a connectathon: every team leaves with a clearer, more actionable backlog. ## Try It Yourself Want to test against our implementation the same way our connectathon partners did? We can set you up with the same scenarios we ran during the event: member matching and bulk export on the PDex side, and the CRD, DTR, and PAS flow on the Burden Reduction side. Reach out to us and we will get you started. And if you are building payer-to-payer exchange or electronic prior authorization on FHIR and simply want to compare notes, we would love to hear from you too.