Your 837s, 835s and 834s are not going anywhere. Neither are the FHIR APIs CMS now requires of impacted payers.
Standards in motion
Payers now have more flexibility in how they design prior authorization workflows, but that choice comes with new compliance and integration considerations.
Impacted payers, meaning Medicare Advantage, state Medicaid and CHIP, Medicaid and CHIP managed care, and qualified health plans on the federal exchanges, must run Prior Authorization, Patient Access, Provider Access and Payer-to-Payer APIs.
Decisions inside 72 hours for expedited requests and 7 calendar days for standard ones, specific reasons on every denial, and public reporting of prior authorization metrics.
CMS will not enforce the X12 278 requirement against a payer running an all-FHIR Prior Authorization API. FHIR only, X12 only, or both are all permitted. For the first time FHIR can replace a mandated X12 transaction rather than sit beside it.
Also in motion: CMS-0053-F makes X12 275 with LOINC-coded attachments the claims attachment standard. The move from X12 5010 to 7030 is in rulemaking.
| Requirement | Date |
|---|---|
| CMS-0057-F operational rules in force | January 2026 |
| CMS-0057-F API compliance | 1 January 2027 |
| CMS-0053-F effective | May 2026 |
| CMS-0053-F compliance | May 2028 |
| X12 5010 to 7030 | In rulemaking |
Our EDI practice and our integration services run out of the same engineering group, so the recommendation is not shaped by the only standard we know.
Connect with ExpertsServices
Six areas, and most engagements start in one of them.
X12 transaction sets implemented across payer, provider and clearinghouse systems, and older EDI infrastructure moved off brittle point-to-point setups.
Data mapped between your systems and the X12 standard in both directions, by file or API, across core admin platforms, EHRs, practice management systems and clearinghouses.
XML, JSON, flat file and proprietary internal formats converted to compliant X12, and back.
Structural and syntactic validation, test data covering the scenarios a transaction actually meets, and regression coverage across trading partners.
Visibility over 837 files, claim and line item status, rejections, denial reasons and work in progress.
Mandatory segments, data types, field lengths and code sets checked against HIPAA and ANSI X12 before a file leaves your environment.
Transaction sets
Each one carries its own rules, failure modes and trading partner expectations.
| Transaction | What it carries | Direction |
|---|---|---|
| 837 | Claim submission, professional and institutional | Provider to payer |
| 835 | Electronic remittance advice | Payer to provider |
| 834 | Benefit enrolment and maintenance | Sponsor or exchange to payer |
| 270/271 | Eligibility inquiry and response | Provider to payer |
| 276/277 | Claim status request and response | Provider to payer |
| 278 | Services review and prior authorization | Provider to payer |
| 820 | Premium payment and remittance advice | Sponsor to payer |
| 275 | Claims attachments, LOINC-coded under CMS-0053-F | Provider to payer |
| 274 | Provider directory information | Between trading partners |
| 997/999 | Functional acknowledgement | Both directions |
How we keep it maintainable
The three areas where EDI work either becomes maintainable or becomes a permanent cost.
X12 sits between an internal data model built for something else and a trading partner who will not change theirs. We handle both directions, plus the parts that get under-scoped: partner onboarding, acknowledgement handling, retry logic and the error paths that only appear at production volume.
See healthcare interoperability solutions →Mandatory segments, data types, field lengths and code sets validated against the standard, with trading partner requirements beyond the standard treated as part of validation rather than a surprise in a rejection report. PHI handling covers encryption in transit and at rest, access control and audit logging.
Wider regulatory scope sits with our healthcare compliance consulting services →EDI defects are expensive because they surface late, in production, across a batch. Structural and syntactic validation, test data beyond the clean cases, and regression coverage so a change made for one payer does not break a transaction working for another.
Most of what we find in a first review sits in one of these three.
Talk to an EngineerWho we build for
834 enrolment, 835 remittance, 270/271 eligibility and 278 prior authorization, alongside the FHIR APIs CMS-0057-F requires of impacted payers. If you are one, the architecture decision above is already on your desk.
Connectivity across many payers, each with their own quirks and tolerance for error. Partner onboarding, mapping at volume, rejection analysis, and reporting that shows a degrading payer relationship before your clients do.
EDI capability inside a product you ship, which means maintainable by your team, documented, and stable across the standards changes coming this decade.
Claim submission, status tracking, remittance posting, and the integration that connects them to the systems your teams already use.
How we work
No proposal before anyone has looked at your transactions.
Which transactions, which partners, what is failing, what the deadline looks like from where you sit. Around 45 minutes.
Current flows, error and rejection rates, integration points, and where manual work has accumulated.
What we found, what we would do, in what order. Yours whether or not you engage us.
Starting with what is failing most expensively.
The failures are consistent, and rarely about the standard itself.
Mapping treated as a one-time task rather than a maintained asset, so the first partner change means a rebuild.
Test data that covers the clean cases and none of the ones that arrive.
Error handling scoped as a rejection report instead of a workflow, so somebody reads raw files at month end.
Format conversion solved once per partner rather than once, with cost growing per partner.
EDI and FHIR roadmaps owned by teams who are not talking, so the same data gets modelled twice, differently.
Talk to an engineer
Modernizing transactions, working toward the CMS-0057-F API requirements, or dealing with a partner connection that keeps breaking?
FAQ
Ask which transactions they have built, not which they list. Ask how they handle trading partner changes, since that is the recurring cost. Ask how they test. And ask where they stand on X12 and FHIR together, because a partner who knows only one will steer you toward it.
834 for enrolment, 835 for remittance, 270/271 for eligibility, 276/277 for claim status, 278 for prior authorization, 820 for premium payment. 275 grows in importance as claims attachments move to a HIPAA-adopted standard under CMS-0053-F.
For prior authorization, CMS has said it will not enforce the X12 278 requirement against a payer running an all-FHIR Prior Authorization API. FHIR only, X12 only or a combination are all permitted for that transaction. Every other HIPAA-mandated transaction remains X12, so most payers will run both for some time.
Yes, both directions, covering XML, JSON, flat files and proprietary internal formats.
Structural and syntactic validation against the standard, test data covering production scenarios rather than only clean cases, and regression coverage across partners.
Use of the adopted X12 standards for covered transactions, conformance to format and code set requirements, and PHI safeguards including encryption, access control and audit logging.
Core administration platforms, EHRs, practice management systems and clearinghouse connections. Specifics depend on what you run, which the first conversation covers.
Cookies help us deliver our services. By using our services, you agree to our use of cookies Privacy Policy.
