CMS-0057-F Explained: The Prior Auth Rule for Practices

SUMMARIZE WITH

IN THIS ARTICLE

CMS-0057-F is a federal rule that sets prior authorization deadlines, denial reasons, and electronic standards for specific health plans. It binds payers, not practices.

Your practice does not have to build an API or change how it submits, though MIPS-eligible clinicians report a yes/no attestation starting in the CY 2027 performance period, but the rule changes what you should expect from the payers it covers, with the first requirements in effect since January 1, 2026.

This post breaks down who the rule actually covers, what changes and when, and what it's reasonable to start checking on now.

‍

KEY TAKEAWAYS

CMS-0057-F binds specific payer types: Medicare Advantage, Medicaid and CHIP (fee-for-service and managed care), and ACA Marketplace plans sold through the federal exchange. It does not bind employer-sponsored group health plans or Original Medicare.
Most operational changes (decision timeframes, denial reasons, public reporting) have a January 1, 2026 compliance date.
The API-building requirements (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs) are not due until January 1, 2027.
Practices should start asking their EHR vendor and top payers about this now, even though the compliance burden sits mainly with payers.

‍

Why CMS Created This Rule

Prior authorization has become one of the most consistent sources of administrative burden in outpatient medicine. A request can sit with a payer for days or weeks with no clear timeframe attached, and when it's denied, practices are often left guessing at the actual reason, which makes resubmitting a slower, more error-prone process than it needs to be.

CMS-0057-F is the agency's response to that pattern, building on an earlier 2020 rule (CMS-9115-F) that required payers to give patients electronic access to their own health data. This 2024 rule extends that same electronic-access logic to prior authorization itself: specific deadlines for a decision, a specific reason when the answer is no, and eventually, a standardized electronic way to submit and track requests instead of a payer-by-payer mix of portals, fax lines, and phone calls.

‍

Who CMS-0057-F Covers, and Who It Doesn't

CMS-0057-F applies to a specific list of payer types, which CMS calls "impacted payers":

Medicare Advantage (MA) organizations
State Medicaid and CHIP fee-for-service programs
Medicaid managed care plans
CHIP managed care entities
Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (the federal ACA marketplace)

Here is the part worth checking carefully: employer-sponsored group health plans are not on that list. If a patient's coverage comes through a self-funded or fully-insured employer plan rather than Medicare Advantage, Medicaid, CHIP, or a federal marketplace plan, that payer is not required to comply with CMS-0057-F.

The same goes for Original (traditional) Medicare Part A/B, which isn't an "impacted payer" under this rule either, since it isn't administered the way Medicare Advantage is.

In practice, this means a single practice's payer mix will likely include a blend of payers that are bound by this rule and payers that aren't. The denial-reason requirement applies to the first group. The decision timeframes apply to the first group except QHP issuers on the federal exchange.

This split matters more than it might first appear. A multi-specialty practice with a typical payer mix, a few Medicare Advantage plans, a state Medicaid managed care plan, and a handful of large employer-sponsored commercial plans, could easily have half its prior authorization volume bound by this rule's new timeframes and half still operating under whatever timeline that specific commercial payer chooses to run.

Treating every payer the same after 2026 would mean missing exactly the distinction the rule creates.

‍

CMS-0057-F Dates: 2026 vs. 2027

CMS split this rule's requirements into two compliance dates. The split matters because it separates faster operational changes from the longer API-building work.

Requirement	Compliance Date	What It Means
Prior authorization decision timeframes	January 1, 2026	Impacted payers (excluding QHP issuers on the federal exchange) must decide expedited requests within 72 hours and standard requests within 7 calendar days
Specific denial reasons	January 1, 2026	Impacted payers must give a specific reason for a denial, regardless of how the request was submitted.
Public reporting of prior auth metrics	January 1, 2026 (first metrics were due by March 31, 2026)	Impacted payers must publicly post certain prior authorization metrics annually on their own website
Patient Access API usage reporting	January 1, 2026	Impacted payers must report annual metrics to CMS about how their existing Patient Access API is being used
Patient Access API (adding prior auth data)	January 1, 2027	Prior authorization information (excluding drug prior auths) must be added to the existing Patient Access API
Provider Access API (new)	January 1, 2027	Impacted payers must build and maintain an API sharing claims, encounter, and prior auth data with in-network providers who have a treatment relationship with the patient
Payer-to-Payer API (new)	January 1, 2027	Impacted payers must build an API to share patient data with a patient's new payer when they switch plans, covering up to 5 years of history
Prior Authorization API (new)	January 1, 2027	Impacted payers must build an API that can process a prior auth request and communicate approval, denial with a specific reason, or a request for more information
Electronic Prior Authorization measure (MIPS)	CY 2027 performance period for eligible clinicians; CY 2027 EHR reporting period for eligible hospitals and CAHs	A new attestation measure under MIPS Promoting Interoperability; clinicians and hospitals attest whether they requested at least one prior auth electronically via a Prior Authorization API

‍

Payers' first public prior authorization metrics were due March 31, 2026, so you can look for your payers' posted reports. The API deadline of January 1, 2027 is about 11 weeks away as of mid-October 2026.

‍

What Changes in Your Prior Auth Workflow

For prior authorizations submitted to an impacted payer, two things have changed in a way your front office will actually notice since January 1, 2026.

First, a denial should come with an actual reason, not just a denial code or a form letter. That reason has to be specific enough to act on, since part of CMS's stated intent is helping practices resubmit faster when a denial can be fixed.

Second, standard requests to those payers have an outside deadline of 7 calendar days, and expedited requests have a 72-hour outside deadline. Those deadlines are outer limits, and they give your practice a documented boundary to hold a payer to.

What stays the same in 2026: the electronic submission process. The Prior Authorization API that's meant to streamline submission and response isn't required until January 1, 2027. Through 2026, most practices will still be submitting the way they do today, just with a clearer timeframe and reason attached to the answer.

Once 2027 arrives, the shift is bigger. The Prior Authorization API is meant to let a request be submitted electronically and return a structured answer: approved (with the date or circumstance the authorization ends), denied (with the specific reason), or a request for more information, rather than a phone call or portal message days later.

The Provider Access API works alongside it, giving in-network providers a standing connection to a patient's claims, encounter, and prior authorization data, so a practice isn't re-requesting information it should already have access to. The Payer-to-Payer API solves a related but separate problem: when a patient switches plans, their new payer can pull up to five years of their prior authorization and claims history instead of starting from zero.

None of these three are live yet, but they are the part of this rule that most directly changes day-to-day prior authorization work once the 2027 date arrives.

‍

Practice Checklist: What to Start Checking Now

an infographic showing a 3-step practice checklist for cms-0057-f.

‍

Since the compliance burden sits with payers, your practice's job right now is mostly preparation.

Build a payer matrix. List your top payers by volume and mark which ones are impacted payers under this rule (Medicare Advantage, Medicaid/CHIP, or a federal marketplace QHP) versus which ones aren't (employer-sponsored plans, Original Medicare, and any commercial plan sold off-exchange). This tells you where the 2026 denial-reason and reporting rules apply. The 72-hour and 7-day clocks apply to every impacted payer except QHP issuers on the federal exchange.

Set up a tracking sheet. For your impacted payers, start logging actual decision turnaround against the 72-hour/7-day standard, and whether denials include a specific reason. This gives you real data if a payer isn't meeting the requirement, rather than a general impression.

Ask your EHR vendor about API readiness. The 2027 Prior Authorization API must use HL7 FHIR R4 (4.0.1). CMS lists the CRD (Coverage Requirements Discovery), DTR (Documentation Templates and Rules), and PAS (Prior Authorization Support) implementation guides as recommended.

Ask your vendor directly whether and when they plan to support these, since your ability to actually use a payer's new API in 2027 depends on your own EHR supporting the connection.

‍

Where a Dedicated Prior Auth Team Member Fits

Day-to-day prior authorization tracking still needs an owner, especially across a payer mix where some payers are bound by the new timeframes and some aren't.

A Prior Authorization Virtual Assistant can own that tracking directly: submitting requests, logging turnaround against the standard your payer mix actually owes you, and following up the moment a decision is overdue.

For the step-by-step workflow, see our prior authorization guide.

‍

Prepare for CMS-0057-F in 2027

‍

CMS-0057-F places its main requirements on payers, but the payers it binds have operated under real deadlines since January 1, 2026, and a faster electronic path is due in 2027. Knowing which of your payers that actually applies to is the part worth sorting out now, before the January 1, 2027 API deadline arrives.

Talk To Our Team about how MedVirtual's dedicated prior authorization virtual assistant can track your payer mix against these timeframes from Day One.

HIPAA-trained. Ready in 3 to 5 days. No long-term contract.

‍

Your Guide To Common Questions & Solutions

Share

Josh, MD is a medical professional and healthcare SEO specialist with over six years of experience in healthcare content strategy and digital growth. At Medvirtual, he leads content development focused on medical virtual assistants and healthcare outsourcing, ensuring every publication reflects clinical accuracy, operational insight, and industry best practices. His work bridges frontline medical knowledge with scalable staffing solutions that support healthcare providers, clinics, and practice owners.

Explore More