The 2027 CMS-0057-F interoperability deadline is approaching. Are your health plan’s APIs, data systems, and operational workflows ready to work together?
Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), impacted payers must implement three new FHIR-based APIs and expand their existing Patient Access API. These requirements are designed to improve access to health information, reduce administrative burden, increase prior authorization transparency, and support continuity of care.
But API availability alone is not enough. Health plans must ensure that the required information can be retrieved, exchanged, protected, and maintained across their existing technology ecosystems.
This guide explains the four APIs, what each must deliver, payer-specific deadlines, and the steps health plans should take to prepare for 2027.
What Are the Four CMS-0057-F API Requirements?
CMS-0057-F introduces three new APIs and expands one existing API, with compliance dates generally beginning January 1, 2027.
| API | Primary purpose | Key requirement |
|---|---|---|
| Patient Access API (Expanded) | Give members access to their health information | Add prior authorization information for non-drug items and services |
| Provider Access API | Support data exchange between payers and treating providers | Share claims, clinical, and specified prior authorization information |
| Payer-to-Payer API | Support continuity of care when members change or have concurrent coverage | Exchange required health data with the patient’s opt-in |
| Prior Authorization API | Digitize prior authorization information exchange | Support coverage-requirements discovery, documentation requirements, and electronic requests and responses |
Although the APIs serve different users, they depend on shared capabilities, including accurate data, standards-based interoperability, secure access, and consistent information governance.
1. Patient Access API: Expanding Member Access to Prior Authorization Information
What does CMS require?
The Patient Access API was established under the 2020 CMS Interoperability and Patient Access Final Rule (CMS-9115-F). CMS-0057-F expands the information available through that API to include specified prior authorization information for non-drug medical items and services.
The expanded API must enable members to access relevant information about their prior authorization requests and decisions through third-party applications of their choosing.
Key requirements
- Make specified prior authorization information available, including applicable status, decision, approval, and denial information.
- Maintain access to required prior authorization information for at least one year after the last status change.
- Continue supporting existing applicable requirements for claims, encounter, and clinical data.
- Maintain appropriate security, authentication, and patient-authorized access controls.
- Continue the annual Patient Access API usage reporting obligation that began in 2026.
Why it matters for health plans
Prior authorization information often exists across utilization management systems, clinical review applications, and administrative databases. Making that information available through an API requires consistent data mapping, reliable updates, and integration across relevant systems.
Health plan readiness priorities
Validate that required prior authorization information can be retrieved from source systems, mapped to the applicable standards, and made available through the API with appropriate access controls.
2. Provider Access API: Enabling More Connected Clinical and Administrative Data Exchange
What does CMS require?
The Provider Access API must enable impacted payers to share specified patient information with in-network or enrolled providers who have a treatment relationship with the patient, unless the patient has opted out of this exchange.
The required information includes:
Key requirements
- Individual claims and encounter data, excluding provider remittances and enrollee cost-sharing information.
- Applicable United States Core Data for Interoperability (USCDI) data classes and elements maintained by the payer.
- Specified prior authorization information for non-drug medical items and services.
Payers must also establish a patient attribution process to determine appropriate provider-patient treatment relationships and provide plain-language educational resources explaining the data exchange and the patient’s ability to opt out.
Why it matters for health plans
Provider Access API readiness depends on more than technical connectivity. Health plans must determine which providers are eligible to access member information, validate treatment relationships, apply patient preferences, and make the required data available securely.
Health plan readiness priorities
- Establish and validate patient-provider attribution processes.
- Maintain accurate provider and member identifiers.
- Implement and test opt-out management.
- Validate clinical and administrative data mapping.
- Document access controls and data exchange activities.
The goal is to support more consistent information sharing without compromising data governance or patient privacy.
3. Payer-to-Payer API: Supporting Continuity of Care Across Health Plans
What does CMS require?
The Payer-to-Payer API enables required information exchange when members transition between health plans or maintain concurrent coverage with multiple payers.
Unlike the Provider Access API’s opt-out model, the Payer-to-Payer API requires an affirmative patient opt-in.
Subject to the rule’s requirements, impacted payers must support the exchange of:
- Individual claims and encounter data, excluding provider remittances and enrollee cost-sharing information.
- Applicable USCDI data elements.
- Specified prior authorization information, excluding drug prior authorizations and denied prior authorizations.
- Related structured and unstructured administrative and clinical documentation submitted by providers, as applicable.
Required historical data sharing is generally limited to maintained data with dates of service within five years of the request.
Payers must also support applicable processes for identifying previous and concurrent coverage, obtaining opt-in permission, requesting and responding to data exchanges, and incorporating received information into member records.
Why it matters for health plans
A change in health plan should not unnecessarily interrupt access to relevant medical information. However, the operational challenge extends beyond transferring records.
Payers must reconcile member identities, maintain consent records, identify previous and concurrent coverage, and accurately incorporate incoming information into existing systems.
Health plan readiness priorities
- Establish and maintain opt-in and withdrawal processes.
- Validate payer and member identification.
- Define data exchange workflows for previous and concurrent coverage.
- Support historical data retrieval within the required scope.
- Track successful transfers, failures, and appropriate follow-up.
- Maintain provenance and auditability of exchanged information.
Effective payer-to-payer exchange requires a coordinated approach across enrollment, IT, data management, compliance, and operations.
4. Prior Authorization API: Digitizing Coverage Requirements, Documentation, and Decisions
What does CMS require ?
The Prior Authorization API is one of the most operationally significant requirements under CMS-0057-F.
It must support electronic exchange between providers and payers for covered non-drug medical items and services by enabling three key functions.
A. Coverage Requirements Discovery: Enable providers to determine whether prior authorization is required for a particular covered medical item or service.
B. Documentation Requirements: Identify the documentation and information needed to support a prior authorization request.
C. Prior Authorization Requests and Responses: Support electronic submission and exchange of requests and responses through the API. A prior authorization response must communicate one of the following:
- Approved: Specify the approval and the date or circumstance under which the authorization ends.
- Denied: Provide a specific reason for denial.
- Additional information needed: Identify that further information is required to make a decision.
CMS-0057-F does not require every prior authorization decision to be made in real time. Clinical review may still be necessary. The API facilitates electronic exchange, while applicable decision timeframes and other operational requirements continue to apply separately.
Why it matters for health plans
- The Prior Authorization API requires coordination between technology and utilization management operations.
- Health plans must ensure coverage requirements, documentation rules, authorization records, and decision information are accurate and accessible.
- An API cannot compensate for inconsistent authorization policies, incomplete source data, or disconnected decision workflows.
Health plan readiness priorities
- Maintain an accurate inventory of covered items and services requiring prior authorization.
- Map coverage and documentation requirements to relevant systems.
- Support electronic request and response exchange.
- Align API activity with existing utilization management workflows.
- Ensure denial reasons and authorization outcomes are consistently recorded.
- Validate interoperability and error-handling processes.
When Must Health Plans Comply With the Four API Requirements?
While CMS commonly refers to January 1, 2027, payer-specific compliance dates must be considered.
| Impacted payer | Applicable 2027 API compliance timing |
|---|---|
| Medicare Advantage organizations | January 1, 2027 |
| State Medicaid fee-for-service programs | January 1, 2027 |
| State CHIP fee-for-service programs | January 1, 2027 |
| Medicaid managed care plans | Rating periods beginning on or after January 1, 2027 |
| CHIP managed care entities | Rating periods beginning on or after January 1, 2027 |
Applicable program-specific extensions, exemptions, or exceptions may modify individual obligations where CMS regulations permit them.
CMS-0057-F does not automatically apply these API requirements to every commercial health plan. Commercial issuers are directly impacted through qualifying individual-market QHP offerings on the federally facilitated Exchanges.
What Technical Standards Support CMS-0057-F API Compliance?
The four APIs rely on standardized interoperability technologies, including HL7 Fast Healthcare Interoperability Resources (FHIR), applicable USCDI content standards, and API security and authorization specifications.
CMS also identifies recommended implementation guides that can support more consistent implementation, including:
- Da Vinci Coverage Requirements Discovery (CRD): Supports identification of coverage and prior authorization requirements.
- Da Vinci Documentation Templates and Rules (DTR): Supports discovery and collection of relevant documentation.
- Da Vinci Prior Authorisation Support (PAS): Supports electronic prior authorization requests and responses.
- Da Vinci Payer Data Exchange (PDex): Supports payer-related clinical and administrative data exchange.
- CARIN for Blue Button: Supports consumer-directed access to payer data.
The distinction between mandatory technical standards and recommended implementation guides is important. Health plans should validate their selected versions against current CMS requirements, ONC-adopted standards, and permitted version updates rather than assuming every recommended guide is mandatory.
Five Actions Health Plans Should Prioritize Before 2027
API implementation is a technical requirement, but readiness requires coordination across IT, compliance, utilization management, data governance, and operational teams.
Assess API readiness and implementation gaps.
Determine which APIs and capabilities already exist, which require enhancement, and which depend on new integrations. Validate readiness against the payer’s applicable compliance date.
Map required data across source systems.
Identify where claims, encounters, clinical information, prior authorization records, documentation requirements, and member preferences are currently maintained. Assign data ownership and identify gaps in availability or quality.
Validate consent, attribution, and security controls.
Ensure the organization can support the appropriate patient opt-in and opt-out mechanisms, verify provider treatment relationships, and protect API data exchange.
Test complete workflows, not just API endpoints.
Test real operational scenarios, including prior authorization submission, denial responses, incomplete documentation, coverage changes, concurrent enrollment, and data exchange failures.
Establish evidence-based compliance monitoring.
Maintain implementation documentation, test results, access logs, exception handling records, and other evidence needed for internal governance and regulatory oversight.
The objective is to establish APIs that function reliably within the broader payer environment, not simply demonstrate that a technical endpoint is accessible.
What Does CMS-0062-P Mean for Future API Requirements?
In April 2026, CMS issued CMS-0062-P, a proposed rule that would extend certain interoperability and prior authorization requirements to prescription drugs and introduce additional technical and reporting proposals.
As of November 3, 2026, these broader drug prior authorization provisions remain proposed and are not part of the finalized CMS-0057-F requirements.
Health plans should therefore distinguish current mandatory API obligations from potential future requirements when planning technical investments.
A modular architecture and well-governed data integrations may make it easier to accommodate future changes without repeatedly rebuilding core workflows.
How Can an API-First Healthcare Platform Support Readiness?
The four API requirements highlight the importance of a technology architecture that connects information and processes across the payer enterprise.
An API-first, configurable healthcare platform can support this foundation through:
- Integration-ready architecture: Connecting existing payer applications, data sources, and operational systems.
- Low-code/no-code configuration: Supporting adaptable workflows, business rules, and operational processes.
- Data validation and governance: Helping identify inconsistencies and improve the reliability of information used across systems.
- Workflow orchestration: Coordinating operational activities, task routing, notifications, and escalations.
- Compliance visibility: Supporting monitoring, audit trails, evidence management, and operational accountability.
- Scalable infrastructure: Accommodating additional integrations and evolving data exchange requirements.
Inovaare’s healthcare-focused platform is designed to support configurable workflows, enterprise integration, data management, and connected compliance operations.
These capabilities can provide supporting infrastructure for payer interoperability initiatives. Compliance with the specific CMS-0057-F APIs, however, must be established through technical validation of the relevant implementations and standards.
Frequently Asked Questions
No. The rule establishes three new APIs: Provider Access, Payer-to-Payer, and Prior Authorization. It also expands the existing Patient Access API to include certain prior authorization information.
The compliance dates generally begin January 1, 2027, but Medicaid and CHIP managed care entities follow applicable rating periods, while federally facilitated Exchange QHP issuers follow applicable plan years.
The new prior authorization information requirements under CMS-0057-F generally exclude drugs. CMS-0062-P proposes additional drug-related requirements, but those proposals must not be treated as finalized CMS-0057-F obligations.
No. CMS requires the API to support electronic prior authorization information exchange, but it does not mandate real-time clinical decisions.
The requirements differ. Provider Access uses a patient opt-out approach, while Payer-to-Payer exchange requires affirmative patient opt-in. Patient Access uses the applicable patient-authorized access framework.
No. API-first architecture can support interoperability, but compliance requires implementation of the appropriate API functionality, data content, security requirements, access controls, and applicable technical standards.
The requirements differ. Provider Access uses a patient opt-out approach, while Payer-to-Payer exchange requires affirmative patient opt-in. Patient Access uses the applicable patient-authorized access framework.
It is whether the systems, data, workflows, and governance processes supporting those APIs can operate together reliably.
Start by identifying your API integration gaps, data dependencies, operational risks, and compliance evidence requirements.
Inovaare’s API-first, configurable healthcare platform can support the integration, workflow, data governance, and compliance management capabilities that underpin payer modernization.
Talk to an Expert About Your 2027 Readiness