CMS-0057-F Prior Authorization APIs: What Healthcare Operators Should Build Before 2027

The Short Answer

CMS-0057-F does not eliminate prior authorization work. It changes where more of that work should happen. Healthcare operators still need systems that gather clinical evidence, route requests to the right payer, submit through APIs when available, use the payer's portal when APIs are incomplete, track decisions, handle denials, and keep humans in the loop for exceptions.

The practical architecture is not "wait for payer APIs." It is a hybrid prior authorization layer: FHIR APIs where they work, browser automation where portals remain necessary and the payer permits it, and a review queue where judgment still matters.

Why Prior Authorization Is Still A Business Problem

Prior authorization is not just paperwork. It is a revenue, scheduling, patient-experience, and staff-capacity problem.

AMA's 2025 prior authorization survey reported that 95% of physicians say prior authorization delays care, and 79% say it can at least sometimes lead to treatment abandonment. Healthcare Finance News also reported payer denials and prior authorization delays as top revenue-cycle concerns in 2026. In the HFMA/Guidehouse survey it cited, 78% of providers were using automation or AI to speed manual revenue-cycle processes, but only 2% had fully or mostly integrated those technologies across RCM operations.

That last number is the pain. Many organizations have pilots. Very few have a real system.

What CMS-0057-F Changes

CMS-0057-F is the CMS Interoperability and Prior Authorization final rule. It requires impacted payers to improve data sharing and reduce prior authorization burden through operational changes and FHIR-based APIs.

The simplified version:

• Some operational provisions generally begin January 1, 2026.
• API development and enhancement requirements generally begin January 1, 2027, depending on payer type.
• The Patient Access API must include certain prior authorization information.
• The Provider Access API must share claims, encounter, USCDI, and specified prior authorization information with in-network providers who have a treatment relationship.
• Prior authorization data is becoming more accessible, but it will not magically become a finished workflow.

The rule matters because it creates the plumbing for better automation. But plumbing is not the same thing as operations.

Why APIs Will Not Replace Workflow Software

Even if payer APIs work exactly as intended, healthcare operators still need to answer operational questions the API does not solve:

• Which patients need authorization before scheduling?
• Which payer rules apply to this visit, scan, procedure, or therapy?
• Which chart notes, diagnoses, orders, and prior treatments support medical necessity?
• Who reviews the packet before submission?
• What happens when the payer requires a portal step, phone call, fax, or document upload?
• How does staff know when a decision arrives?
• What gets escalated to a clinician?
• How are denials appealed?
• What proof is retained for audit or payer dispute?

The API is a transport layer. The business problem is the workflow around it.

The Hybrid Architecture

A practical prior authorization system has seven parts.

1. Trigger detection

The system identifies when a prior authorization may be required. Triggers can come from scheduling, orders, CPT codes, payer rules, benefit checks, referrals, or staff selection.

2. Evidence gathering

The system pulls the relevant chart notes, diagnosis history, order details, previous treatment attempts, imaging results, medication history, or therapy plan. This may require EHR APIs, FHIR resources, document OCR, or staff upload.

3. Payer routing

The system decides whether this payer and request type supports an API path, portal path, clearinghouse path, fax path, or manual path. This routing table becomes one of the most valuable operational assets in the practice.

4. Submission layer

If the payer supports the required API, the system submits through the API. If not, it uses the X12 278 through the clearinghouse, portal automation where the payer's terms allow it, or staff-assisted submission. For many operators, payer portals will remain part of the workflow for years.

5. Status monitoring

The system checks for approval, denial, pending review, missing documentation, or peer-to-peer requests. This can happen through APIs, permitted portal automation, email/fax intake, or manual updates.

6. Exception queue

Anything risky, unclear, denied, or clinically sensitive goes to a human queue. The queue should show what happened, what evidence was submitted, what the payer requested, and what the next action should be.

7. Audit trail

Every submission, status check, document upload, staff edit, clinician review, and payer decision should be logged. Without this, automation saves time but weakens control.

API First, Not API Only

The best posture is API first. Not API only.

If an API exists and works reliably, use it. It is cleaner, easier to monitor, and less brittle than browser automation. But if your payer mix still requires portal work, build that into the system instead of pretending it is an edge case, whether a permitted bot or a staff step does the work.

In healthcare, the edge case is often the workflow.

Check the payer's terms before automating a portal. Several large payers do not allow it. Availity announced in April 2022 that it was ending bot access to Availity Essentials and offers API connections to approved partners instead. The terms of use for the UnitedHealthcare provider portal and Optum prohibit using software to access or scrape their online services, and the Evernorth terms bar robots, scripts and scraping unless Evernorth approves in writing. A bot that breaks a portal's terms puts the practice's portal account at risk. Terms change, so read the current version for each payer; we last read these on 2026-09-29. This is engineering context, not legal advice.

This is why we recommend a payer connector pattern:

• A common internal prior authorization model
• One connector per payer or payer class
• API connector when supported
• Portal automation connector when needed and permitted by the payer
• Manual connector for phone, fax, or staff-entered updates
• A consistent work queue and audit log above all connectors

Your staff should not need to care which path a request used unless something breaks.

Where AI Helps

AI can help, but it should not run the workflow unsupervised.

Useful AI patterns include:

• Extracting medical-necessity evidence from chart notes
• Summarizing prior treatments
• Drafting payer-specific appeal language
• Classifying denial reasons
• Detecting missing documentation
• Suggesting the next action for staff

High-risk patterns include:

• Submitting clinical claims without review
• Inventing evidence
• Choosing diagnoses only to satisfy payer criteria
• Sending patient-facing explanations without approval
• Writing back to the EHR without a human sign-off

AI is useful when it reduces staff search time. It is dangerous when it hides judgment.

What To Build Before 2027

Healthcare operators should not wait until every payer endpoint is clean. The work to do now is mostly internal.

Build or define:

• A central prior authorization work queue
• A payer routing table
• Evidence packet templates by service line
• Human approval rules by risk level
• API and portal connector strategy
• Status monitoring and escalation rules
• Denial and appeal tracking
• Audit logging and reporting
• Metrics by payer, procedure, location, provider, and staff team

By the time APIs mature, you will already have the workflow. Then APIs become better pipes, not a last-minute transformation project.

Build vs Buy

Use a vendor product when your prior authorization workflow is standard, your payer mix is well-supported, and you do not need much control over routing, evidence collection, or EHR integration.

Build a custom layer when your business has specialty workflows, multiple locations, multiple EHR/PM systems, employer programs, high-value procedures, concierge models, out-of-network complexity, or a need to own the operational logic.

Do both when a vendor handles part of the transaction well, but your team still needs a custom work queue, reporting layer, payer logic, EHR middleware, or portal fallback.

That is common. The best system is often not a pure custom replacement. It is a custom operating layer around the tools that already work.

The Opexia View

Prior authorization automation is not a bot project. It is a product build.

The valuable software is the layer that understands your service lines, payer mix, staff roles, evidence requirements, exception patterns, and revenue risk. CMS-0057-F makes that layer more important, not less, because operators will need to coordinate APIs, portals, staff review, and payer changes inside one coherent workflow.

Opexia builds that kind of system: payer connectors (API, X12 278 and permitted portal automation), EHR/FHIR middleware, RCM work queues, human review flows, and audit-ready reporting. The right goal is not "automate everything." The right goal is to make prior authorization visible, trackable, reviewable, and faster without losing control.

Related Opexia reading: Automating prior authorization in healthcare, insurance eligibility automation, claim status automation, and RPA billing automation.

External sources: CMS CMS-0057-F fact sheet, AMA 2025 prior authorization survey, and Healthcare Finance News on RCM concerns.