CMS-0057-F provider operations checklist for 2026 and 2027

CMS-0057-F is often discussed as a payer rule. That is accurate, and it is also why provider teams keep deferring the work. The API obligations do sit with impacted payers, so nothing in the rule requires a physician practice to build an interface.

What changes for providers is the information and response pattern they will be expected to consume. Most of the readiness work has nothing to do with an interface and everything to do with whether the practice can currently say when a request was sent, when the payer accepted it, and why it was denied.

Quick answer

CMS-0057-F regulates specified payers, not provider practices directly, but it changes the information and response patterns provider teams should be ready to use. For non-drug items and services, operational provisions generally begin in 2026, including faster decision timeframes for certain impacted payers, specific denial reasons, and public payer metrics. API requirements generally begin in 2027. Those APIs are intended to expose coverage requirements, accept prior authorization requests and supporting documentation, and return structured responses.

Providers should not wait for an interface launch to clean up their workflow. Standardize receipt timestamps, request states, denial-reason capture, documentation ownership, escalation rules, and payer-specific exceptions now. Inventory which plans and services are actually in scope, because requirements vary and the final rule excludes drug prior authorizations. Keep clinical urgency, medical necessity, and appeal decisions with qualified people. Treat the separate 2026 CMS drug prior authorization rule as a proposal unless and until CMS finalizes it, and confirm current requirements with official CMS material and counsel.

What CMS-0057-F does, and what it does not do

CMS issued the Interoperability and Prior Authorization Final Rule, CMS-0057-F, in January 2024. The rule applies to specified payer types and includes both operational provisions and interoperability requirements. The impacted payer categories include Medicare Advantage organizations, state Medicaid and Children's Health Insurance Program fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the Federally Facilitated Exchanges. The exact applicability and compliance date can differ by provision and payer type.

The CMS final-rule page should be the source of truth. A provider checklist is an operational interpretation, not legal advice. Three boundaries matter:

1. The rule governs impacted payers. It does not impose the payer API build requirement on a physician practice.
2. The finalized prior authorization provisions exclude drugs. Medical items and services are the focus of the prior authorization changes in CMS-0057-F.
3. Not every provision starts at the same time. Operational changes generally begin in 2026, while API development and enhancement requirements generally begin in 2027.

The broader CMS prior authorization rule guide explains the policy at a high level. This article focuses on what a provider operations team should change inside its own process.

Separate the 2026 work from the 2027 work

Combining all deadlines into one FHIR readiness initiative causes teams to miss the immediate operational work. Use two workstreams.

2026: decision timeframes and denial reasons

CMS requires impacted payers other than QHP issuers on the Federally Facilitated Exchanges to send decisions within 72 hours for expedited requests and seven calendar days for standard requests for the affected non-drug items and services. CMS also requires impacted payers to provide a specific reason when a request is denied, regardless of whether the request was submitted by portal, fax, email, mail, phone, or another method. Review the exact scope and exceptions in the CMS fact sheet.

These are payer decision deadlines, not a guarantee that every provider submission is complete, accepted, or clinically decided at first touch. A practice needs timestamps for:

• Request assembled
• Request sent
• Payer receipt or acceptance confirmed
• Additional information requested
• Additional information sent
• Decision received
• Denial reason received
• Resubmission or appeal initiated, when authorized

Without those events, the team cannot distinguish payer turnaround from its own preparation time or from a rejected transmission.

2027: API-enabled exchange

The Prior Authorization API is designed to let an impacted payer publish covered items and services, identify documentation requirements, support a request and response, and communicate approval, denial, a request for more information, and authorization end information. CMS requires FHIR Release 4.0.1 and other standards for the relevant APIs and recommends several Da Vinci implementation guides.

An API does not automatically create a safe operational workflow. CMS states in its Prior Authorization API FAQ that some responses may be real time while other requests will still need evaluation by clinical reviewers. Providers should preserve qualified review for urgency, clinical evidence, medical necessity, and disputed decisions.

For more technical context, see the FHIR prior authorization provider guide. Do not assume that a recommended implementation guide, an available EHR interface, and a deployed payer connection are the same thing. Each must be verified in the organization's environment.

The provider operations readiness checklist

1. Build an applicability matrix

Create a living table by payer, line of business, service, submission channel, and rule provision. Do not label an entire insurer in scope based only on its corporate name. A single payer organization may administer products subject to different requirements. Your matrix should record:

• Payer and plan or product
• Patient population and line of business
• Item or service
• Whether prior authorization is required
• Current requirement source and effective date
• Accepted submission channel
• Standard and expedited handling instructions
• Contact and escalation path
• Last date verified

Assign an owner for updates. Payer rules change, and stale requirement tables create avoidable rework.

2. Define a complete-submission standard

Start the operational clock from a consistently documented event. Staff beginning work is not the same as a payer receiving a complete request. Define what evidence proves submission and acceptance for each channel.

Build a minimum data contract for each high-volume service. It may include patient and coverage identifiers, ordering clinician, requested item or service, applicable diagnosis, supporting records, and payer-specific forms. Clinical teams must approve clinical documentation requirements. Automation can check presence and format, but it should not invent evidence or decide that the record proves medical necessity.

3. Replace binary status with an auditable state model

Pending is too broad to operate. Use statuses that reveal the next action.

Every status needs a timestamp, owner, aging rule, and allowed next states. Preserve the original response rather than overwriting it with the latest status.

4. Normalize denial reasons without discarding payer language

Beginning in 2026, the specific denial reason creates a better operational signal, but only if the practice captures it. Store the original reason, the source, date, payer reference, and any structured code. Then map it to an internal category for analysis.

Useful internal categories may include missing documentation, coverage criteria not met, service mismatch, network or benefit issue, duplicate request, invalid identifier, or other. Those labels should support routing, not replace the payer's wording. A denial involving medical necessity belongs with qualified clinical staff. A technical rejection may return to operations.

The prior authorization denial reasons guide covers prevention in more depth. Keep denial prevention distinct from formal appeal management.

5. Create expedited-request governance

Do not let software independently label a case urgent. Define who may request expedited handling, what policy applies, how the rationale is documented, and what occurs if the payer does not accept the expedited classification. The patient's condition and applicable plan rules matter.

Escalation rules should identify the responsible clinician, authorization lead, patient-contact owner, and after-hours pathway. Operational timers can surface a case. They should not replace clinical judgment.

6. Prepare the EHR and integration data contract

List the fields the future workflow must read and write. Include patient identity, coverage, order, requested service, status, payer reference, documentation request, response, validity period, and owner. Decide which system is authoritative for each field.

Use the ONC SAFER Guides to inform system management, patient identification, contingency planning, and clinician communication. Test for duplicate patients, stale coverage, partial failures, unavailable interfaces, and delayed write-back. A successful API response is not enough if staff cannot see or act on it in the established queue.

If your team is assessing EHR-connected orchestration, review prior authorization automation and EHR-integrated prior authorization as operational design references.

7. Set up payer-performance monitoring

CMS requires impacted payers to publish specified aggregated prior authorization metrics. The required measures include approval and denial percentages and average and median decision time for standard and expedited requests.

Public payer metrics can provide context, but compare them carefully with practice data. Payer figures aggregate items and services and may not match a specialty, geography, or patient mix. Internally, report preparation time, accepted-submission time, payer-decision time, rework rate, reason category, and patient scheduling impact separately.

A 90-day implementation sequence

Days 1 to 30: establish facts

• Name an executive sponsor and operational owner.
• Inventory payer products, high-volume services, and channels.
• Document current statuses and their inconsistent uses.
• Sample real cases and reconstruct timestamps.
• Confirm the policy source for expedited handling and clinical review.

Days 31 to 60: standardize the workflow

• Approve the state model and data dictionary.
• Define complete-submission evidence by channel.
• Build denial-reason categories while retaining source text.
• Set aging and escalation rules.
• Train staff on the distinction between technical rejections, administrative denials, and clinical review needs.

Days 61 to 90: test and govern

• Pilot one payer-service combination.
• Reconcile operational status to the EHR daily during the pilot.
• Test downtime, duplicate responses, corrected requests, and partial failures.
• Audit a sample for documentation accuracy and appropriate escalation.
• Decide what must be complete before expanding volume.

What about the 2026 drug prior authorization proposal?

In April 2026, CMS published a proposed rule that would extend interoperability and prior authorization policies to drugs and make other changes. As of this article's preparation date, that drug rule is a proposal, not a finalized extension of CMS-0057-F. The CMS proposed-rule fact sheet uses proposal language and lists proposed compliance dates.

Track it in a separate regulatory register. Do not tell staff, patients, or executives that the drug provisions are already final. Update policy only after reviewing the final rule, its effective dates, and its application to the relevant payer and benefit.

How to evaluate automation without overclaiming compliance

No software purchase makes a provider CMS-0057-F compliant, because the rule's API obligations sit with impacted payers and provider responsibilities extend beyond a tool. Evaluate whether the platform can support the practice's chosen controls. Ask vendors to demonstrate:

• Payer and service requirement provenance and update process
• Complete-request checks without fabricated clinical content
• Original denial response retention and structured categorization
• Receipt, request, response, and write-back timestamps
• Human review gates for urgency, medical necessity, and appeal choices
• EHR reconciliation and failure handling
• Audit logs, role-based access, and downtime procedures
• Production evidence for the specific payer and EHR connection proposed

Linear Health reports that its prior authorization workflows can be 10 times faster, with work moving from more than 30 minutes to under five minutes and a 98% first-pass figure. These are Linear Health figures, not guaranteed outcomes. Buyers should validate definitions, cohort, exclusions, and fit for their environment.

To review the controls against an actual service line, bring examples of a complete request, a technical rejection, a documentation request, and a denial that required clinical review.

Frequently asked questions

Sources: CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), CMS CMS-0057-F fact sheet, CMS Prior Authorization API frequently asked questions, CMS 2026 interoperability standards and prior authorization for drugs proposed rule fact sheet, ONC SAFER Guides.