Executive Summary: The CMS-0057-F Interoperability and Prior Authorization Final Rule requires impacted payers to offer standardized FHIR APIs, with the API requirements generally beginning January 1, 2027. Operational requirements are already in effect—most impacted payers must now send prior authorization decisions within 72 hours (urgent) or 7 calendar days (standard), and all impacted payers must give specific reasons for denials.
CMS-0057-F Compliance Requirements — Quick Summary
- FHIR APIs: Patient Access (adding prior authorization information), Provider Access, Payer-to-Payer, Prior Authorization
- 72-hour / 7-day decision rules — in effect since January 2026 (QHP issuers on the FFEs excluded)
- Specific denial reasons must be given for denied prior authorization decisions (drugs excluded)
- Public reporting of prior authorization metrics, first due March 31, 2026
- Generally January 1, 2027: API requirements begin; exact timing depends on payer category
What is CMS-0057-F?
CMS-0057-F is the Interoperability and Prior Authorization Final Rule published by the Centers for Medicare & Medicaid Services (CMS) in January 2024. This article summarizes the main CMS-0057-F requirements for payers — including deadlines, technical requirements, and what is at stake if you miss them. Impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally-facilitated Exchanges (see the CMS fact sheet).
Why This Rule Matters
Prior authorization has long been a pain point in healthcare:
- Manual channels: much prior authorization still runs through phone, fax and payer portals
- Administrative burden: providers consistently report prior authorization as a major burden (AMA physician survey)
- Delays: waiting for decisions can delay care
CMS-0057-F aims to reduce these delays through standardized APIs and firm decision timeframes.
Critical Timeline: Two Deadlines
| Requirement | Effective Date | Status |
|---|---|---|
| Operational Requirements | January 1, 2026 | IN EFFECT NOW |
| Prior Authorization decision within 72 hours (urgent; QHP issuers on the FFEs excluded) | January 1, 2026 | Active |
| Prior Authorization decision within 7 calendar days (standard; QHP issuers on the FFEs excluded) | January 1, 2026 | Active |
| Specific reasons for denials (drugs excluded) | January 1, 2026 | Active |
| API Requirements | Generally January 1, 2027 | Timing depends on payer category |
| Patient Access API (enhanced with prior authorization information) | Generally January 1, 2027 | Upcoming |
| Provider Access API | Generally January 1, 2027 | Upcoming |
| Payer-to-Payer API | Generally January 1, 2027 | Upcoming |
| Prior Authorization API (Da Vinci guides recommended) | Generally January 1, 2027 | Upcoming |
Important: The operational requirements are not future obligations—they apply now. Enforcement depends on the program; CMS has program-specific compliance and enforcement tools.
Preparing for CMS-0057-F?
Many payers are starting testing in 2026 to meet the 2027 deadline.
Published X12 278 samples can be converted to FHIR PAS in the public converter; the FHIR PAS to X12 278 direction is still in development. Testing customer inputs requires an evaluation key and a supported input; integration requirements are reviewed separately.
Try the 278 ↔ PAS Converter Request a Test LicenseNo setup required.
The Required APIs
1. Patient Access API
Allows patients to access their claims, encounters, and prior authorization data through third-party apps.
Requirements:
- FHIR R4 format
- Claims and encounter data
- Prior authorization status and decisions
- SMART App Launch authorization (a required standard)
2. Provider Access API
Allows in-network providers to access patient data for treatment purposes.
Requirements:
- FHIR R4 format
- Attribution process linking patients to in-network or enrolled providers
- Patient opt-out
- Claims and encounter data, clinical data (USCDI) and prior authorization information (drugs excluded from prior authorization information)
3. Payer-to-Payer API
Enables data exchange when patients switch health plans.
Requirements:
- FHIR R4 format
- Patient opt-in
- Claims and encounter data, clinical data (USCDI) and prior authorization information (excluding prior authorizations for drugs)
- Data with dates of service within five years of the request
4. Prior Authorization API
This is the most technically complex requirement. It lets providers learn whether prior authorization is needed and what documentation is required, submit requests, and receive decisions through a FHIR API (drugs excluded). CMS recommends the HL7 Da Vinci CRD, DTR and PAS implementation guides for it; CMS’s list of relevant standards and guides names PAS 2.0.1 and 2.1.0 (as of October 2026).
With the recommended PAS guide, this typically includes:
- Support
$submitoperation for new requests - Support
$inquireoperation for status checks - Return FHIR ClaimResponse with decision
Architecture Overview
Before diving into code, here's how the pieces fit together in a typical payer implementation:
Key Insight: Many payer backends still run on X12 278. In that architecture, a conversion layer transforms FHIR requests into X12 for processing, then converts X12 responses back to FHIR for the API layer. The Patient Access, Provider Access and Payer-to-Payer APIs draw on claims, member and clinical data through their own integrations; the X12 278 conversion path applies to prior authorization. For deployment details and security considerations, see the PAS architecture & deployment guide.
Prior Authorization API: Key Technical Requirement
The Prior Authorization API is the most technically demanding of the four required APIs. For payers with X12 278 backends, it typically means translating between FHIR R4 requests and responses (following the recommended Da Vinci PAS guide) and X12 278 processing. Including FHIR Provenance in converted output helps trace how each resource was produced. For implementation details and code examples, see the CMS PAS implementation guide.
Implementation Checklist
A typical sequence for CMS-0057-F implementation work:
Phase 1: Assessment
- Inventory existing prior authorization systems
- Identify X12 278 transaction volumes
- Assess current FHIR capabilities
- Review X12 validation coverage (syntax, inter-segment and balancing checks)
- Review current 72h/7d decision compliance (operational requirement)
- Determine whether conversion is needed and select a solution if applicable
Phase 2: Development
- Add prior authorization information to the existing Patient Access API
- Implement Provider Access API
- Implement Payer-to-Payer API
- Implement the Prior Authorization API; where PAS is selected, implement its applicable operations
- Build the X12 278 ↔ FHIR conversion layer, if X12 backends remain
- Decide how converted output is traced (for example, FHIR Provenance)
Phase 3: Testing
- End-to-end testing with trading partners
- Test API latency, throughput and availability
- Verify applicable operational decision deadlines, including manual-review workflows and escalation
- Security and SMART on FHIR testing
- Test the provider/EHR and portal integrations included in the deployment
- X12 validation testing where X12 is used
Phase 4: Go-Live (by the applicable compliance date)
- Production deployment
- Monitoring and alerting
- Provider communication
- Verify patient-authorized application access through the Patient Access API
What Happens If You Miss the 2027 API Requirements?
CMS-0057-F is not advisory. It is a final rule with enforcement mechanisms. Organizations that fail to comply face real risks:
- Regulatory enforcement action. Each program (Medicare Advantage, Medicaid, CHIP and the Exchanges) has its own compliance and enforcement mechanisms.
- Operational requirements are already enforceable. The 72-hour (urgent) and 7-day (standard) prior authorization decision timelines took effect January 1, 2026 for most impacted payers (QHP issuers on the FFEs are excluded). Plans that miss these timelines today are already out of compliance.
- Provider and member complaints. The rule requires that specific denial reasons be communicated. Failure to do so creates a documented trail of non-compliance that providers and patient advocates can escalate.
- Provider relations. Providers consistently report prior authorization as a major administrative burden, and plans that make it faster and more transparent are better placed with their networks.
- Limited flexibility. Organizations that support only one format may have less room to adapt if trading-partner requirements change, and adding a second format under deadline pressure is slow and error-prone.
The operational requirements already apply, and the API requirements follow on fixed dates. Planning against the applicable compliance date for each program is the safer course.
Frequently Asked Questions
Who must comply with CMS-0057-F?
Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
Does this affect fee-for-service Medicare?
Medicare fee-for-service is not an impacted payer under these payer API requirements.
Are the CMS-0057-F operational requirements (72h/7d) already in effect?
Yes. Since January 1, 2026, impacted payers must send prior authorization decisions within 72 hours for expedited (urgent) requests and 7 calendar days for standard requests; QHP issuers on the FFEs are excluded from this timeframe provision. Impacted payers must also give a specific reason for denied prior authorization decisions (drugs are excluded).
What is the CMS-0057-F API deadline?
The API requirements generally begin January 1, 2027, with exact timing depending on payer category. They cover the Patient Access API (adding prior authorization information), the Provider Access API, the Payer-to-Payer API and the Prior Authorization API. CMS recommends, rather than requires, the Da Vinci CRD, DTR and PAS implementation guides for the Prior Authorization API.
Can we use existing X12 278 infrastructure for CMS-0057-F compliance?
Yes. The Prior Authorization API is a FHIR interface, but payers can keep X12 278 processing behind it. A conversion layer can translate between the FHIR API and an X12 278 backend for supported transactions. Published X12 278 samples can be converted to FHIR PAS in the public converter; the FHIR PAS to X12 278 direction is still in development. Testing customer inputs requires an evaluation key and a supported input; integration requirements are reviewed separately.
What is Provenance in FHIR and why does it matter for CMS-0057-F?
Provenance is a FHIR resource that records where data came from, who produced it and when. CMS-0057-F does not name Provenance as a requirement, but including it in converted output helps payers trace how each resource was produced.