On January 1, 2027, the most technically demanding part of the CMS Interoperability and Prior Authorization final rule (CMS-0057-F) takes effect. Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs must have three FHIR-based APIs in production, along with an expanded Patient Access API, by that date. Medicaid and CHIP managed care plans follow with rating periods beginning on or after January 1, 2027, and QHP issuers on the federally facilitated exchanges with plan years beginning on or after that date. With about eight weeks left, the question is no longer what the rule requires. It is whether the data, workflows and governance behind each API will hold up once providers and other payers start using them.

The 2026 provisions were largely process changes: decision timeframes of 72 hours for expedited requests and 7 calendar days for standard requests, specific reasons for every denial, and public reporting of prior authorization metrics. The 2027 provisions are different. They expose a plan's prior authorization rules, decisions and member data to outside systems in a structured, machine-readable form. Gaps that a phone call or a fax once covered will now be visible to every connected provider.

What Must Be Live on January 1

Prior Authorization API

Providers will use this API to ask, directly from their own systems, whether an item or service requires prior authorization and what documentation the payer needs. Under the rule, the API must:

  • Be populated with the payer's list of covered items and services, excluding drugs, that require prior authorization
  • Identify all documentation required for approval of those items and services
  • Support a HIPAA-compliant prior authorization request and response
  • Communicate whether a request is approved (with the date or circumstance under which the authorization ends), denied or pended for more information, with a specific reason for any denial

Provider Access API

In-network or enrolled providers with a treatment relationship to a member can retrieve that member's adjudicated claims and encounter data (excluding provider remittances and member cost-sharing), clinical data in the USCDI standard and prior authorization information. Payers must run an attribution process to establish treatment relationships, give members a way to opt out and publish plain-language resources that explain to providers how to request data.

Payer-to-Payer API

With the member's opt-in, the receiving payer must request data from the previous payer no later than one week after coverage starts, or when the member asks, and then incorporate what it receives into the member's record. The exchange covers five years of data. When a member has two or more concurrent impacted payers, those payers must exchange data at least quarterly.

Patient Access API Expansion

The existing Patient Access API must add prior authorization information, available no later than one business day after the payer receives a request or a status changes, and kept available while the authorization is active and for at least one year after its last status change.

Where Plans Are Getting Stuck

The prior authorization list is not truly structured. Many plans keep requirements in policy documents, code lists maintained in spreadsheets and rules applied by delegated entities. The API needs one authoritative, coded list. If what the API returns disagrees with what utilization management staff apply, providers will submit against the wrong rules and avoidable denials will follow.

Documentation requirements are written for people, not systems. Instructions such as "clinical notes supporting medical necessity" have to become discrete, answerable items that a provider's system can assemble. Vague requirements produce incomplete submissions and pended requests, which now count against the turnaround metrics plans already report publicly.

Status data is fragmented. Pended, approved, denied and expiring authorizations often live in different systems, including those of delegated entities. The Patient Access and Provider Access APIs both depend on a single, current status record for each authorization, with dates and denial reasons attached.

Attribution has no single right answer. CMS did not prescribe an attribution method. Plans can rely on eligibility checks, scheduled appointments for patients a provider has not yet seen or claims history for ongoing care, but the method chosen has to be documented, defensible and applied consistently.

Inbound data has nowhere to go. A Payer-to-Payer exchange is not finished when the data arrives. The rule requires plans to incorporate it into the member record, which means matching, validating and deduplicating up to five years of claims, clinical and authorization history produced by another organization.

An Eight-Week Readiness Checklist

  1. Reconcile the prior authorization list. Confirm that the coded list behind the API matches the rules utilization management will apply on January 1, including delegated arrangements, and assign an owner for every future change.
  2. Test documentation rules against real cases. Take a sample of recent requests and confirm that the documentation the API would have returned was sufficient for a decision.
  3. Trace one authorization end to end. Follow a request from submission to decision to status change and confirm it appears correctly in the Prior Authorization, Patient Access and Provider Access APIs within one business day.
  4. Audit denial reasons. Every denial should carry a specific reason a provider can act on, not a generic code.
  5. Put opt-in and opt-out operations in place. Member notices, call center scripts and the systems that record Payer-to-Payer opt-ins and Provider Access opt-outs should be working before data flows.
  6. Finish provider resources. Network teams should know how providers will connect, how attribution works and whom providers contact when a request fails.
  7. Size the January inbound workload. Payer-to-Payer requests arrive with January enrollments. Estimate the matching and reconciliation effort now and staff for it.
  8. Define production monitoring. Track availability, response times, error rates and status update delays from the first day, and agree on who responds when a threshold is missed.

Why It Matters Beyond Compliance

Providers are being pulled toward these APIs as well. Beginning with the CY 2027 performance period, MIPS eligible clinicians, eligible hospitals and critical access hospitals will report on an Electronic Prior Authorization measure under the Promoting Interoperability programs. As provider organizations move to electronic submission, plans whose APIs return accurate, complete requirements should see more complete requests, fewer pended cases and fewer avoidable denials. Plans whose APIs return stale or partial rules will see the opposite, and the public prior authorization metrics required since 2026 make those patterns visible to providers, regulators and members.

The scope is also likely to grow. CMS's April 2026 proposed rule (CMS-0062-P) would extend electronic prior authorization requirements to drugs and update the standards behind these APIs. Its comment period closed on June 15, 2026. Plans that treat January 1 as the start of a durable prior authorization data operation, rather than a one-time technical project, will absorb that next phase far more easily.

A Single Source of Truth for Authorizations

Each of these APIs is only as reliable as the operational data behind it. Curitics manages prior authorizations in the same platform as care management and the member record, with an auto-approval engine for requests that meet defined criteria and utilization tracking across authorizations. Automated data ingestion validates incoming data before it loads into a unified member record, giving plans one consistent source for authorization status and for the history they receive from other payers.