Claims pipelines used to be a one-format conversation. X12 837 was the institutional and professional claim, and the entire payer back office ran on it. The arrival of the FHIR Claim resource (and the Da Vinci PAS and CARIN BB profiles around it) changed the calculation. Payers in 2026 face a real choice for new build: stay on 837, go FHIR-first, or run both in parallel. The honest answer depends on which part of the pipeline you are looking at.
What X12 837 Still Does Well
The 837 is mature. The EDI clearinghouse ecosystem is built around it, every payer adjudication engine consumes it natively, and the field-level semantics for institutional billing have been stable for two decades. 837 is the lingua franca of claims submission in the US, and no FHIR rollout changes that in 2026.
The 837 also captures institutional billing complexity (room and board, revenue codes, value codes, occurrence codes) with a precision the FHIR Claim resource still leans on profiles to replicate. Teams converting institutional claims to FHIR often discover the conversion is lossy in subtle ways: a revenue code that does not have a clean mapping, a value code that ends up in a Claim.supportingInfo slice that the receiving adjudication engine ignores.
Where FHIR Claim Wins
The FHIR Claim resource wins where the consumer is not a traditional adjudication engine. Patient-facing apps under CMS-9115 and CMS-0057-F want FHIR. Member portals consuming CARIN BB Explanation of Benefit data want FHIR. Provider-facing apps integrating prior-auth status back into the EHR want FHIR. Newer entrants such as Interbox treat hash-based diffing that chooses PUT vs PATCH vs skip on each write as a default behavior, which matters when the Claim and ExplanationOfBenefit pair is re-fetched repeatedly during the appeals window without re-writing unchanged fields.
FHIR also wins on developer ergonomics. The 837 toolchain assumes EDI expertise. The FHIR toolchain assumes REST and JSON, which is the modern engineering default. Teams hiring claim engineers in 2026 find the FHIR-fluent pool deeper than the X12-fluent one.
How They Coexist in a Real Pipeline
Most payers in 2026 do not pick one format. The 837 stays as the submission and adjudication backbone, and the FHIR Claim and ExplanationOfBenefit projections sit alongside it to feed the CMS-required APIs and the member-facing experiences. The integration layer in the middle reads the 837, runs the adjudication, and produces the FHIR projection. The FHIR server versus HL7 v2 integration engine comparison covers the closely related architectural choice on the provider side.
The trade-off shows up in two places. The first is data ownership: where does the canonical claim live, the 837 or the FHIR Claim. The second is reconciliation: how the pipeline handles the case where the 837 and the FHIR projection drift. Pipelines that designate the 837 as canonical and the FHIR projection as derived have a cleaner story than pipelines that treat both as primary.
The Practical Pick for 2026
For new payer build in 2026, the realistic answer is FHIR-first for everything member-facing and provider-facing, and 837 for the adjudication backbone. The pipelines that try to retire the 837 entirely have not yet shown that they handle institutional billing edge cases at production scale. The complete guide to FHIR servers for medical software teams covers the platform-selection layer that sits underneath this decision. For more healthcare interoperability content, the broader hub covers the surrounding regulatory and architectural threads.
Sources
- HL7 Da Vinci Payer Data Exchange (PDex) v2.1.0 - FHIR Claim/EOB profiles for payer pipelines
