Healthcare

CMS-0057-F in 2026: The Prior Authorization Changes That Actually Matter

The CMS prior authorization rule is not new. The deadlines are. Here is what changed for 2026 and 2027, and the workflow a practice should fix before adding more software.

Nexlane Solutions22 October 202610 min read

CMS-0057-F is often described as a payer rule. That is technically correct. It is also why many practices ignore it until a denial lands.

The rule requires impacted payers to make prior authorization decisions faster, explain denials more specifically, report metrics and expose prior authorization data through APIs. Those obligations land on payers. The operational consequences land on the practice that has to submit the request, chase the status, assemble the documentation and appeal the denial.

As of 22 October 2026, CMS's rule page still points to the same two dates that matter:

Operational provisions generally began 1 January 2026.
API requirements generally begin 1 January 2027, with exact dates varying by payer type.[1]

If your practice still tracks authorizations in a spreadsheet, a shared inbox and a payer portal login, the next 12 months are the time to fix the workflow — not just buy another tool.

What the rule actually requires

This is a summary, not legal advice. Read the CMS fact sheet and the final rule for the official requirements.

| Requirement | What it means in practice | Date | |---|---|---| | Decision timeframes | Impacted payers must decide expedited (urgent) requests within 72 hours and standard (non-urgent) requests within seven calendar days | Operational provisions generally from 2026 | | Specific denial reason | Impacted payers must give a specific reason for a denied prior authorization, regardless of how the request was sent | Beginning 2026 | | Prior authorization metrics | Impacted payers must publicly report certain prior authorization metrics annually; the initial set was due by 31 March 2026 | From 2026 | | APIs | Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, with prior authorization data added to the Patient Access API | Generally from 2027 | | MIPS measure | A new Electronic Prior Authorization measure for eligible clinicians and hospitals | CY 2027 performance period |

The rule has exclusions. For example, some provisions do not apply to prior authorization decisions for drugs, and the decision timeframes exclude Qualified Health Plan issuers on the Federally Facilitated Exchanges. Do not read a summary table as a complete compliance checklist.[2]

Why practices still feel the burden

The rule changes the payer's clock. It does not automatically change the practice's workflow.

A typical authorization still involves:

A clinician orders a service.
Staff check whether the payer requires authorization.
Staff look up the payer's rules, which may differ by plan, code, site of service and urgency.
Staff assemble clinical documentation from the EHR, fax, portal or a scanned packet.
Staff submit through a portal, fax or clearinghouse.
Staff wait, call and check status.
The request is approved, pended, denied or partially approved.
If denied, staff interpret the reason and decide whether to appeal, resubmit or change the order.
If approved, staff track the authorization's expiration and units.
The claim is submitted and may still be denied for a different reason.

The bottleneck is not one step. It is the handoffs between steps, and the lack of a single record that shows what was requested, what was sent, what the payer said and what happens next.

A faster payer decision does not fix a packet that was incomplete on day one. A specific denial reason does not fix a team that cannot classify or route it. An API does not fix a workflow that has no owner.

Fix the workflow before you buy the tool

The most useful readiness exercise is a process map with names, timestamps and failure modes. Do it before evaluating software.

Step 1: Build a payer and plan matrix

For each payer and plan that matters, record:

Which services require authorization
Which portal or channel is used
Typical turnaround
Common missing documents
Common denial reasons
Whether electronic prior authorization is supported
Who owns the relationship

Do not rely on a generic list from a vendor. Payer rules change. Assign an owner and a review cadence.

Step 2: Map the order-to-auth path

For one high-volume service, walk the actual path:

Where does the order enter?
Who checks eligibility?
Where is the payer rule stored?
Who assembles the packet?
What is the submission channel?
Where is the status recorded?
Who follows up?
How is the approval stored?
How is the expiration tracked?

Use timestamps, not opinions. “Usually same day” is not a measurement.

Step 3: Define a single authorization record

If the request lives in three places, you do not have a record. You have a search problem.

At minimum, the record should include:

| Field | Why it matters | |---|---| | request_id | One identifier across portal, EHR and internal tracking | | payer and plan | Rules and contacts differ by plan | | patient_reference | Link to the EHR; do not copy PHI into unauthorised tools | | ordering_provider | Needed for follow-up and peer-to-peer | | code and description | CPT/HCPCS or the relevant service code | | date_of_service | Drives urgency and expiration | | urgency | Expedited vs standard | | status | Draft, submitted, pended, approved, denied, expired, appealed | | submitted_at | Starts the clock | | decision_due_at | 72 hours or seven calendar days, depending on urgency | | payer_reason | Specific denial reason or pend reason | | documents | What was sent, with version and timestamp | | next_action and owner | Prevents the record from going stale |

This record is the foundation for reporting, automation and audit. Without it, every automation is a faster way to create chaos.

Step 4: Standardise the documentation packet

For each high-volume service, define:

Required clinical elements
Required attachments
Ordering provider signature requirements
Site-of-service details
Prior treatment history
Conservatism requirements, if applicable
Payer-specific forms

Then build a checklist that a human can complete and a system can validate. The goal is not to write a perfect AI prompt. The goal is to stop submitting incomplete packets.

Step 5: Make status visible

A status field is not enough. You need an ageing view:

Submitted today
Due within 24 hours
Overdue
Pended, waiting on us
Pended, waiting on payer
Approved, expiring in 14 days
Denied, appeal window open

This is where most spreadsheet workflows fail. The spreadsheet can hold the data, but it cannot enforce the follow-up.

Where automation actually helps

Automation is most useful when it removes repetitive work around a deterministic process. It is least useful when it hides an undefined process behind a chat interface.

A sensible sequence:

1. Deterministic checks first

Does this code require authorization for this payer and plan?
Is the order complete?
Are the required documents present?
Is the request expedited or standard?
Is the authorization expiring?

These are rules, not language tasks. Put them in a rules engine or workflow, not a prompt.

2. AI for extraction and drafting

AI can help with:

Reading a fax or PDF and extracting fields for human review
Summarising clinical notes into a draft packet
Comparing a payer's denial reason to an internal reason taxonomy
Drafting an appeal letter for human review
Drafting a status update for the patient or scheduling team

Every one of these outputs needs a review step. The model is drafting, not deciding.

3. Human approval for high-risk actions

Require approval before:

Submitting a request
Sending clinical documentation
Filing an appeal
Changing a code or order
Contacting a payer on the patient's behalf
Closing a case as “no action needed”

The approval should be recorded with who approved, when, what they saw and what changed.

4. Logging and rollback

Log the input, the model output, the human edit, the final submission and the payer response. If a run goes wrong, you need to know which cases were affected. A workflow without an audit trail is not ready for production.

What to measure

Do not start with “time saved.” Start with the process.

| Metric | Definition | Why it matters | |---|---|---| | Submission turnaround | Order to first submission | Shows intake and packet delays | | First-pass approval rate | Approved without rework / total submitted | Shows packet quality | | Days to decision | Submission to payer decision | Shows whether the 72-hour/7-day clocks are working | | Rework rate | Requests returned for missing or incorrect information | Shows documentation gaps | | Expiring authorisations | Approved auths expiring in the next 14 days | Prevents avoidable denials | | Denial reason mix | Count by payer reason category | Shows where to fix the process | | Appeal overturn rate | Overturned / appealed | Shows appeal quality | | Human touches per case | Number of staff actions | Shows automation opportunity |

Do not compare your numbers to a vendor's benchmark. Compare them to your own baseline, measured the same way.

A 90-day readiness plan

Days 1–30: inventory

Pick two high-volume services.
Build the payer/plan matrix for the top five payers.
Map the current workflow with timestamps.
Count rework and denials by reason.
Identify the one field that is missing most often.
Assign an owner for prior authorization operations.

Days 31–60: pilot

Create the single authorization record.
Standardise the packet for one service.
Add an ageing view and a daily huddle.
Automate one low-risk step: document extraction, status reminder or appeal draft.
Keep every high-risk action behind human approval.
Measure the baseline again.

Days 61–90: decide

Compare first-pass approval, turnaround and rework.
Decide whether to expand, change the workflow or stop.
Document the operating procedure.
Review vendor contracts and data-processing terms if you used an AI tool.
Check whether your EHR or clearinghouse supports the relevant prior authorization APIs.

The output is not a “transformation.” It is a controlled process with a baseline, a test and an owner.

Compliance guardrails

This section is not legal advice. Work with your compliance officer or counsel.

Use “HIPAA-aware workflows,” not “HIPAA certified.” There is no single HIPAA certification for a workflow. Describe the safeguards: access control, minimum necessary, audit logging, encryption, retention and business associate agreements.
Sign a BAA before sending PHI to a vendor. Confirm the vendor's role and the permitted use.
Keep PHI out of unapproved AI tools. A consumer chatbot is not a business associate.
Limit tool permissions. The agent should not have broad database access or the ability to submit without review.
Log access and changes. You need to know who saw what and who changed a request.
Retain records according to policy. Do not let a workflow delete audit data because the UI made it easy.
Test with de-identified or synthetic data first. Do not use production PHI for a prompt experiment.
Have a rollback plan. If the automation fails, the team must be able to return to the manual process immediately.

What not to do

Do not buy an “AI prior authorization” tool before you map the workflow. You will automate the wrong step.
Do not assume the API removes the portal. Payer APIs will roll out unevenly. Portals and fax will coexist for years.
Do not auto-submit clinical documentation. A human should review the packet and the final send.
Do not treat the denial reason as free text. Build a taxonomy so you can see patterns.
Do not ignore drug exclusions. The rule's scope is specific. Read the fact sheet.
Do not promise patients a decision time. The rule sets payer timeframes; it does not guarantee the outcome or the exact date for every request.
Do not claim compliance you cannot evidence. Document what you do, not what a badge says.

The bottom line

CMS-0057-F is a payer rule with a practice workflow problem. The practices that handle it well will not be the ones with the most AI. They will be the ones with a single authorization record, a standard packet, a visible status, an owner and an audit trail.

If you want help mapping the workflow before automating it, our prior authorization practice starts with the process, not the tool. If the broader revenue cycle is the issue, our RCM team can connect authorization, coding, billing and denial management. For appeal workflow design, see denial management.

Sources

Sources checked 24 October 2026. This article is educational and not legal or compliance advice. Verify the current rule text and your payer contracts before changing a workflow.

All blogs

Written by Nexlane Solutions. Spotted a mistake? Tell us.