The healthcare industry is approaching one of its most significant interoperability milestones in years. A long-term compliance initiative, the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) has become more immediate given the complexity of changes required by the January 1, 2027, deadline.
January 1, 2027, is not simply a technology deadline. It is an operating-readiness deadline. FHIR enables standardized, timely digital exchange. Operations determine whether that exchange actually improves healthcare.
Released in January 2024, the rule addresses longstanding industry challenges including administrative burden, delays in care, fragmented data exchange, and lack of transparency in prior authorization processes.
At its core, CMS-0057-F is an operational transformation mandate with success depending not only on API deployment, but also on an organization’s ability to redesign workflows, improve data quality, standardize authorization processes, and coordinate activities across clinical, administrative, and technology teams.
The Road from Readiness to Results
As of January 1, 2026, most impacted payers were required to meet new prior authorization decision timeframes: 72 hours for expedited requests, and 7 calendar days for standard requests. As of March 31, 2026, they had to post prior authorization metrics publicly and submit Patient Access API usage data to CMS. The final and most complex phase arrives at the beginning of 2027, when required interoperability and API capabilities must be fully implemented. Being ready means moving beyond API implementation to address data quality, prior authorization workflows, provider attribution, consent management, exception handling, education, monitoring, and cross-functional governance.
Key API Requirements Under CMS-0057-F
At the center of CMS-0057-F are FHIR-based APIs designed to enable more consistent and secure healthcare information. Four key FHIR-based API requirements are particularly important as payers prepare for the 2027 deadline:
- Patient Access API: In addition to making member data electronically accessible (per the 2020 CMS Interoperability and Patient Access Rule), CMS-0057-F also requires payers to include prior authorization information (excluding Part D drugs) and related data to the API. Updates must be available in the API within one business day regardless of how the request was originally submitted.
- Provider Access API: This rule requires payers to share claims, encounter data, United States Core Data for Interoperability (USCDI) clinical elements, and prior authorization details with in-network providers who have an active treatment relationship with the patient. Payers are responsible for verifying the treatment relationship, managing patient opt-outs, and establishing a provider attribution process. Once these verification conditions are met, payers must make the requested data available within one business day. Additionally, payers must provide plain-language resources to educate both patients and providers.
- Payer-to-Payer API: The expansion of previous requirements establishes FHIR-based data exchange between health plans when members change coverage or have concurrent coverage. New plans must request eligible claims, clinical and prior authorization information with dates of service within the preceding five years. The previous payer must generally provide the requested information within one business day of receiving the request. The rule excludes prior authorizations that were denied from the payer-to-payer data requirement. New payers must collect explicit member opt–in consent and embed a formal compliance attestation directly into every API request.
- Prior Authorization API: This new API supports electronic prior authorization workflows across key processes, including rule discovery, documentation gathering, electronic submission, and digital status tracking. It must expose explicit clinical documentation requirements and deliver determinations within 72 hours for expedited requests and 7 calendar days for standard ones. Updates must be reflected in the API within one business day.
Together, these APIs are designed to create a more connected healthcare ecosystem — one with improved transparency, streamlined prior authorization, and more seamless information exchange among patients, providers, and health plans. In addition, payers must support electronic provider directory capabilities, building on existing interoperability infrastructure, including the Provider Directory API established under CMS’s earlier interoperability rule.
Why API Readiness Alone Is Not Enough
A payer could technically deploy compliant APIs and still experience:
- Incomplete or inconsistent data
- Poor provider attribution
- Authorization backlogs
- Manual documentation handling
- Unresolved exceptions
- Fragmented clinical workflows
- Provider abrasion
- Member confusion
- Poor adoption of electronic workflows
Avoiding these outcomes requires more than API deployment. Health plans need connected operations that align data, workflows, clinical decision-making, technology, and operational teams around the new interoperability model.
Five Priorities for Health Plans Before January 2027
Health plans should focus on the operational capabilities needed to scale interoperability.
1. Validate API Readiness: Confirm that required APIs are aligned with applicable technical requirements, secure, reliable, and tested across real-world workflows, including authentication, data availability, error handling, and external connectivity.
2. Improve Data Readiness: Assess whether claims, clinical, member, provider, and prior authorization data are complete, standardized, current, and available within required timeframes. Strong interoperability depends on usable data, not just connected systems.
3. Redesign Prior Authorization Workflows: Examine the processes behind intake, documentation, clinical review, determinations, status updates, and exceptions. Standardization, automation, and intelligent routing can help reduce manual friction and support required turnaround times.
4. Operationalize Provider and Payer Data Exchange: Establish repeatable processes for provider attribution, treatment-relationship validation, member consent and opt-out management, payer identification, data reconciliation, and exception resolution.
5. Build Monitoring and Governance: Create visibility into API performance, data quality, authorization turnaround times, workflow exceptions, and adoption. Cross-functional governance can help identify issues early, maintain compliance, and drive continuous improvement.
These priorities can help health plans move beyond technical compliance toward a more connected operating model that improves information flow, operational performance, and provider and member experience.
How Sagility Supports CMS-0057-F Readiness
Sagility approaches CMS-0057-F from both sides of the equation: the technology requirements and the healthcare operations that make those requirements work in practice.
We connect the regulatory requirements with the workflows required to operationalize them — from prior authorization intake, documentation and clinical review to provider attribution, consent management, payer-to-payer exchange, exception handling and performance monitoring.
In short, we combine our deep understanding of healthcare workflows with AI-led capabilities.
- CoreIQ identifies: readiness gaps, exceptions, processing performance and workflow bottlenecks.
- Synchrony coordinates: activity across systems, teams, clinical workflows and exceptions.
- SmarTec executes: AI-assisted and automated workflow activities.
These solutions help payers streamline operations, improve transparency, and enhance experiences for members and providers.
From Compliance To Connected Operations
CMS-0057-F is about more than meeting regulatory requirements. The health plans that derive the greatest value from CMS-0057-F will not simply connect systems. They will connect the data, workflows, clinical decisions, and operational teams behind them. That is where compliance becomes operational transformation.
