CMS Prior Authorization Rule 2026: An Operations Guide to CMS-0057-F
A plain-language operations guide to the 2026 and 2027 requirements in the CMS Interoperability and Prior Authorization Final Rule.

On this page: Direct answer
Direct answer
CMS prior authorization rule 2026: what operators need to know
A plain-language operations guide to the 2026 and 2027 requirements in the CMS Interoperability and Prior Authorization Final Rule. The rule applies to specified impacted payers; it is not one universal requirement for every health plan. Beginning in 2026, impacted payers generally must give a specific reason for denied prior authorization decisions.
CMS-0057-F changes prior authorization operations for defined impacted payers in phases. The most useful way to read it is as a set of capabilities and dates: decision timing and denial reasons, public metrics, patient and provider data access, and standards-based prior authorization APIs.
This article is an operational summary, not legal advice. Confirm applicability by payer type, product, service, and effective date against the final rule and subsequent CMS guidance. The final rule generally addresses medical items and services rather than drugs of any type.
Key takeaways
The short version
- The rule applies to specified impacted payers; it is not one universal requirement for every health plan.
- Beginning in 2026, impacted payers generally must give a specific reason for denied prior authorization decisions.
- For impacted payers other than QHP issuers on the federally facilitated exchanges, decisions generally must be sent within 72 hours for expedited requests and seven calendar days for standard requests.
- Initial public prior authorization metrics were generally due by March 31, 2026.
- Many API requirements are generally required by January 1, 2027, with enforcement discretion for some provisions described by CMS.
Which payers are in scope?
CMS identifies impacted payers as Medicare Advantage organizations, state Medicaid and Children's Health Insurance Program agencies, Medicaid and CHIP managed care plans, and qualified health plan issuers on federally facilitated exchanges. The exact requirement can vary by payer category.
A provider workflow should therefore store payer, line of business, product, and governing rule. A label such as 'commercial' or 'Medicaid' is too broad to calculate a compliant deadline or assume an API path.
Operational timeline
| Timing | Rule element | Provider-side preparation |
|---|---|---|
| Beginning 2026 | Specific denial reasons for impacted payers | Capture reason verbatim and classify it separately |
| Beginning 2026 | Generally 72-hour expedited and 7-calendar-day standard decisions for specified impacted payers | Store request type, received timestamp, source rule, and due date |
| March 31, 2026 | Initial public PA metrics generally due | Use payer reports as context, not case-level proof |
| Generally Jan. 1, 2027 | Prior Authorization API and other interoperability provisions | Plan integration, identity, provenance, and exception handling |
Specific denial reasons should change the appeal workflow
A reason is useful only if it survives intake into the provider's workflow. Save the notice, capture the payer's exact language, distinguish administrative from medical-necessity issues, and connect the reason to the policy requirement and response evidence.
Do not overwrite the source reason with a cleaner internal category. Keep both. The internal taxonomy supports reporting; the verbatim notice supports accurate follow-up and appeal review.

The API is a transport layer, not the whole workflow
The Prior Authorization API is intended to support questions about whether authorization is required, documentation requirements, and electronic request and response. Provider organizations still need intake quality, clinical review, identity matching, exception handling, user permissions, monitoring, and downtime procedures.
Ask vendors how they distinguish a payer response from a locally inferred rule, retain source provenance, reconcile asynchronous updates, and route transactions that cannot be completed electronically.
A provider readiness checklist
- Inventory payer and line-of-business volume by service
- Normalize request, submission, response, and decision timestamps
- Store standard versus expedited status and its justification
- Create a denial-reason taxonomy without discarding verbatim notices
- Separate medical-service prior authorization from drug workflows
- Define API, portal, fax, and phone fallback paths
- Validate privacy, security, identity, consent, and audit controls
Common questions
Answers before you build.
What is CMS-0057-F?+
It is the CMS Interoperability and Prior Authorization Final Rule, which establishes phased requirements for defined impacted payers related to prior authorization operations, data exchange, and APIs.
Does the seven-day rule apply to every payer?+
No. The final rule identifies impacted payer types and includes category-specific details. Verify the plan, product, service, jurisdiction, and effective requirement.
Does CMS-0057-F cover pharmacy prior authorization?+
The final rule's prior authorization policies and API generally apply to medical items and services and exclude drugs of any type. Track pharmacy and medical-benefit drug requirements separately.
When is the Prior Authorization API required?+
CMS states that impacted payers generally must meet API requirements by January 1, 2027, with specific applicability and enforcement details in the final rule and guidance.
Practical closeout
Use this operator checklist.
- The rule applies to specified impacted payers; it is not one universal requirement for every health plan.
- Beginning in 2026, impacted payers generally must give a specific reason for denied prior authorization decisions.
- For impacted payers other than QHP issuers on the federally facilitated exchanges, decisions generally must be sent within 72 hours for expedited requests and seven calendar days for standard requests.
- Initial public prior authorization metrics were generally due by March 31, 2026.
- Many API requirements are generally required by January 1, 2027, with enforcement discretion for some provisions described by CMS.
Continue through the cluster
Verified customer case studies are added only with customer permission and supporting evidence; none is implied by these operational examples.
Sources & methodology
Trace the operational claims.
Marsa Health Editorial reviewed the primary and research sources below on July 22, 2026. We translate them into workflow controls, distinguish proposals from final rules, and flag where plan, program, state, contract, or clinical requirements vary.
- 01CMS Interoperability and Prior Authorization Final Rule CMS-0057-F Centers for Medicare & Medicaid ServicesCurrent implementation dates, decision timeframes, denial-reason requirements, metrics, and API provisions for impacted payers.Accessed or rechecked July 22, 2026
- 02Summary of the HIPAA Security Rule U.S. Department of Health and Human ServicesCurrent Security Rule overview covering administrative, physical, and technical safeguards, access controls, risk analysis, and review of ePHI activity.Accessed or rechecked July 22, 2026
- 03Guidance on Risk Analysis U.S. Department of Health and Human ServicesOfficial guidance that risk analysis must cover all ePHI an organization creates, receives, maintains, or transmits.Accessed or rechecked July 22, 2026
- 04Minimum Necessary Requirement U.S. Department of Health and Human ServicesHIPAA guidance on limiting uses, disclosures, and requests for protected health information when the standard applies.Accessed or rechecked July 22, 2026
Organizational author. Editorial review covers source accuracy, search intent, workflow boundaries, and human-oversight requirements. This material is educational and does not provide clinical, legal, coding, or coverage advice.
No named clinical or legal expert reviewer is attributed to this version. Marsa Health does not invent reviewer credentials.
Read our editorial methodRevision history
What changed and when
July 22, 2026
Initial publication, source review, and operational editing.