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 CMS and ONC interoperability requirements coming into force.
For health plans, those requirements run on a specific clock. CMS-0057-F puts the Prior Authorization API and the Payer-to-Payer API into effect on January 1, 2027.
We brought Payerbox, our FHIR compliance platform for health plans, to two tracks: Burden Reduction and PDex, testing directly against other payer and vendor systems. Here is what we ran, what broke, and what we changed.
Burden Reduction Track
In the Da Vinci Burden Reduction track (CRD, DTR, and PAS: the electronic prior authorization stack) Payerbox was on the payer side. Our server hosted the CDS Hooks services, DTR questionnaires, and PAS operations, and EHR vendors tested their provider-side implementations against it. Over two days we ran sessions with six EHR vendors: Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health, and Altera Digital Health. Thanks to all six teams for coming prepared.
The shared scenario was a Home Oxygen Therapy prior authorization. A CRD order-sign hook returns a "prior authorization required" card carrying a coverage-information system action that points at a DTR questionnaire, the clinician completes the prepopulated form, and the resulting bundle goes to PAS Claim/$submit, which returns a ClaimResponse within seconds. The utilization management decision follows, and the EHR picks it up through $inquire.
Beyond that happy path we exercised the four CRD hooks Payerbox implements (order-sign, order-select, order-dispatch, and appointment-book), 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.
What we fixed
Live EHR clients produced a prioritized defect list. One class of fix shipped mid-event, on day two: we loosened validation strictness so that harmless display-string and reference mismatches warn instead of block, while genuinely incomplete submissions still get a clean error response. A payload that failed in a morning session passed on replay the same afternoon.
The rest landed over the three days that followed:
- Claim cancel end to end, so a cancelled prior authorization is visible through
$inquire. - Coverage assertions changed to definite decisions rather than conditional ones.
- Questionnaire prepopulation: seven questionnaires never prefilled because their launch contexts were unbound, which only surfaced when real DTR clients opened real forms.
- CRD hook requests carrying
fhirServer: nullwere rejected where an absent key passed; explicit nulls are now treated as absent. - PAS bundle closure: resources left over from an earlier CRD exchange no longer count as payer-known references, so
$submitcorrectly rejects a bundle that is not self-contained.
What we sent back
We gave 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 replaces the older card-link pattern, plus several smaller test-data observations.
PDex Track
In the Da Vinci Payer Data Exchange (PDex) track we tested Payerbox against three other systems: InterSystems, Hike Health, and CareEvolution. Thanks to all three teams for testing against us. The goal was the full payer-to-payer flow end to end: member matching via $bulk-member-match, followed by bulk data export via $davinci-data-export.
The teams integrating against us produced a prioritized list of their own. Most of it 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
- making consent-based routing of matched members easier to read when a member ends up constrained
None of it is structural. These are the interoperability details that only surface against live counterparties. Each is tracked as its own issue and none is closed as we publish, which is the honest state of a track we entered to find exactly this.
We fed observations back as well: some implementations performed no reference or FHIR validation during the event, and one showed a mismatch between synchronous and asynchronous matching counts.
Provider Access
The same track covers Provider Access, another of the four CMS-0057-F APIs, and our session with InterSystems spanned both. Provider Access reuses most of the payer-to-payer machinery: $provider-member-match resolves the members attributed to a requesting provider, and the same $davinci-data-export delivers their claims, clinical, and prior authorization data. Worth being explicit about the shape, because it is the part payers most often have to redesign for: this is a bulk export over an attributed group, not an on-demand per-patient lookup. The defect list above came from the payer-to-payer scenarios.
What this means for payers
CMS-0057-F comes with no exam. There is no authorized testing body and no required test suite the way there is for ONC-certified EHRs, and conformance tooling like Touchstone exists but is not mandated. So nothing certifies that a Prior Authorization or Payer-to-Payer API works. The only evidence is that it has been run against counterparties you do not control.
That is what a connectathon buys, and it is why the defect lists above are the useful part of this post. Every item on them came from a partner's payload, not from our own test suite: an unbound launch context that left a questionnaire blank, a bundle that looked self-contained until a real EHR sent it, a null where our schema expected an absent key. None of it is reachable by testing against yourself.
So when you assess readiness, yours or a vendor's, that is the question worth asking before January 2027: which live counterparties has this been through, and what broke when it met them.
Try It Yourself
Want to test against Payerbox the same way our connectathon partners did? We can set you up with the scenarios we ran during the event: member matching and bulk export on the PDex side, CRD, DTR, and PAS on the Burden Reduction side. Request access and we will get you started.
If you are building payer-to-payer exchange or electronic prior authorization on FHIR and simply want to compare notes, get in touch. We would like to hear from you.
