CMS-0057-F in 2026
Health Interoperability
7 Min Read

CMS-0057-F in 2026: Where you should be and what comes next

Mat Osmanski - avatar

Subscribe to our newsletter

Subscribe

The first hard deadlines under CMS-0057-F have passed. As of January 1, 2026, payers were required to meet new PA decision timeframes: 72 hours for expedited requests, 7 calendar days for standard. As of March 31, 2026, they had to post PA metrics publicly and submit Patient Access API usage data to CMS.

Those dates drew a line. What was a planning exercise is now an operational reality, and the next deadline, January 1, 2027, is less than nine months away. Whether that’s enough time depends entirely on where you’re starting from.

Most payers right now fall into one of three camps. Knowing which one you’re in determines what you should be doing for the rest of 2026.

You’ve met the January and March deadlines

Good. But don’t mistake that for being on track for 2027.

The January 2027 requirement isn’t “have FHIR endpoints running.” It’s five APIs in production, each with specific IG conformance requirements, and a whole operational layer underneath them.

Identity resolution, consent management, member opt-in/opt-out workflows, provider attribution, terminology governance, data quality, bulk export compliance: all of it has to work before the APIs can function reliably at scale.

These aren’t FHIR problems. They’re data infrastructure problems that FHIR surfaces. The payers who discover this in Q4 are going to have a rough few months.

You haven’t committed to a vendor yet

According to a 2025 WEDI survey, the majority of payer respondents hadn’t even started preparing for the API requirements. If that’s you, the window is narrowing but it’s not closed.

Implementation typically takes 12 to 18 months end to end. An accelerated timeline from here is possible, but it requires the right partner who can move quickly without cutting corners on IG conformance, and a sequenced approach to the work rather than trying to build everything in parallel.

The economics make a strong case for moving. CAQH’s 2024 Index puts the cost of a manual PA transaction at $3.41 versus $0.05 electronic, with $449M in potential annual savings across the industry from full PA automation.

Organizations that invest in this properly will see that return. Those that treat it as a compliance checkbox will pay for it twice: once to comply, and again when they need to rebuild.

You started, but it’s not working

This is more common than most payers will admit. We work with organizations across all stages of this, and the same problems keep coming up.

Solutions that only support two or three of the five required APIs. FHIR conversion breaking down because of upstream data quality the vendor’s pipeline can’t handle. Prior Auth workflows that only function with a narrow set of in-network EHRs. Reporting that requires someone to manually intervene every month.

If this sounds familiar, the honest question is whether you’re dealing with fixable problems or architectural ones. A misconfigured endpoint is a sprint. A pipeline that was never built for IG conformance is a different conversation, and the sooner you have it the better.

The five APIs going live are: Patient Access (enhanced with prior authorization data), Provider Access, Payer-to-Payer Data Exchange, Provider Directory (migrated to US Core 6.1.0 and Plan-Net 1.2.0), and Prior Authorization API (with CRD, DTR, and PAS strongly recommended as the practical path to meeting the requirement).

Prior Authorization is the most operationally demanding. What the rule requires is a Prior Authorization API that can identify covered items and their documentation requirements, support electronic submission and response, and return structured decisions within the required timeframes. CRD, DTR, and PAS are the Da Vinci IGs that CMS strongly encourages for implementation, and while not strictly required, they’re the practical path to getting there.

One thing that consistently catches payers off guard is delegated vendor complexity. Most payers have somewhere between five and fifteen delegated vendors covering areas like vision, dental, behavioral health, and long-term care.

Each one is a separate integration conversation for Prior Auth, and some of them aren’t even FHIR-aware yet. Getting your vendor map in order now is one of the highest-leverage things you can do.

It’s also worth noting: you don’t necessarily need to rip out your existing infrastructure to get there. FHIR can be layered onto your current stack. The key is building with enough flexibility that you’re not back in this position when digital quality measures, value-based care requirements, and future IG versions arrive. And they will.

Q2 is the window to lock in your vendor if you haven’t, get the build moving, and pilot with one or two real provider systems. Real integration testing, not synthetic data. Issues you find now are manageable. The same issues in Q4 are not.

Q3 is for scaling that testing across your real provider network, validating decision timeframes against actual PA volumes, and running internal mock audits against CMS’s reporting criteria.

Q4 is production hardening, full provider rollout, and member and provider education. One thing teams consistently underestimate: provider onboarding is a change management challenge, not just a technical one. Providers need to understand how the new workflows fit into their day, not just that the endpoints are live.

Nine months is tight. Whether it’s enough depends on where you’re starting from and how quickly you can move. The real danger isn’t a missed deadline. It’s spending the next nine months building toward one and finding out in Q4 that the foundation was wrong.

If you want to go deeper on any of this, we’ve put together two resources specifically for payers working through CMS-0057-F. Our CMS-0057-F Strategic Pack covers implementation sequencing, vendor evaluation, and a readiness framework. The Electronic Prior Authorization Pack goes deeper on the PAS/CRD/DTR layer if that’s your focus.

If you’d like to talk through where you are and what it would take to close the gaps before January, reach out and we’re happy to get into it.

Mat Osmanski - avatar

By Mat Osmanski

Mat leads Firely’s consulting practice, overseeing and mentoring the consulting team as they help clients successfully implement Firely’s FHIR-based products. In this role, he builds and maintains the consultancy framework, continuously optimizing team workflows and processes to ensure high-quality, scalable delivery. Mat works closely with Firely’s board to define and refine consulting strategy, while also fostering strong client relationships. He supports product implementations through project management, integration design, product configuration, custom plugin development and deployment best practices. Mat also contributes to product development by recommending new offerings and enhancements to existing solutions.

Recommendations for you

Explore more topics

Post a comment

Your email address will not be published. Required fields are marked *