CMS-0057-F and January 1, 2027: Payer APIs on In-House Claims and Prior Authorization Systems

By January 1, 2027, Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs must have four FHIR APIs running under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F): the existing Patient Access API, extended to carry prior authorization data, and new Provider Access, Payer-to-Payer and Prior Authorization APIs. Medicaid managed care plans, CHIP managed care entities and Qualified Health Plan issuers on the federal exchanges follow from their first rating period or plan year that begins on or after that date. As of October 16, 2026, that is eleven weeks away, and CMS has not moved it.

The operational half of the rule is already in force. Since 2026, impacted payers have had to give a specific reason for every denied prior authorization, decide within fixed timeframes and publish prior authorization metrics.

If your claims, utilization management and member systems come from a vendor that ships these four APIs, most of the build is the vendor's. Your part is configuration, digitized prior authorization rules, member notices and testing with partners.

This article is for the rest: plans and agencies whose claims engine, UM workflow or member data sits in a system they own, whether built in-house, customized past the point of upgrades, or a Medicaid Management Information System (MMIS) with decades of local changes. Nobody ships the APIs for those. We are engineers, not lawyers: this explains what the rule asks a system to do, not how it applies to your contracts.

The Dates

The final rule was published in the Federal Register on February 8, 2024 and took effect on April 8, 2024. For each of the four APIs it sets the same compliance dates: "by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs."

A Medicaid managed care plan whose rating periods start on July 1 therefore has until July 1, 2027. A plan on a calendar-year contract does not.

CMS still gives the same date. Its policy page for the rule, last modified on October 8, 2026, says that "impacted payers have until primarily January 1, 2027, to meet the application programming interface (API) requirements in this final rule."

The 2026 obligations, as the CMS fact sheet puts them, are decisions "within 72 hours for expedited (i.e., urgent) requests and seven calendar days for standard (i.e., non-urgent) requests" (QHP issuers on the exchanges are excluded from the timeframes), a specific reason for every denial, and public metrics, of which "the initial set of metrics must be reported by March 31, 2026." Patient Access API usage is reported to CMS every year by March 31 as well. If any of this is not running yet, it is already late, and it draws on the same data as the APIs.

Drugs are outside all of it. Every prior authorization provision in CMS-0057-F excludes them.

Who Is in Scope, and Who Is Not

The rule calls them impacted payers: Medicare Advantage (MA) organizations, state Medicaid and CHIP fee-for-service (FFS) programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally-facilitated Exchanges (FFEs). Its impact analysis counts "365 parent organizations, including state Medicaid and CHIP agencies," that "are responsible for implementing and maintaining three new APIs," and notes that "75 percent of payers in this category have under 500 employees." Many are regional plans without a large platform team.

Not in scope, at least not directly:

• Employer plans outside these programs, and Original Medicare. They are not on the list of impacted payers.
• Providers. Their side is the Electronic Prior Authorization measure in Medicare's Promoting Interoperability programs, met through certified EHR technology. The FY 2027 IPPS final rule of August 4, 2026 made it an optional bonus measure for hospitals in 2027.
• Delegated UM entities and TPAs. They carry no obligation of their own, but the payer's runs through their systems. For QHP issuers the rule repeats that they "are responsible for their own compliance and the compliance of any delegated or downstream entities."

There are few ways out, and none helps much this late. A state may request a one-time, one-year extension for its Medicaid or CHIP FFS program, but the request goes in its Advance Planning Document (APD) and must be "approved before the compliance date." A state with at least 90 percent of its Medicaid beneficiaries in managed care can request an exemption, and QHP issuers can ask the exchange for an exception. On the plans themselves, CMS wrote: "We did not propose extensions or exemptions for MA organizations or Medicaid managed care plans." States can also claim 90 percent enhanced federal matching funds for building the APIs, approved case by case through the APD.

What Each API Has to Do

All four depend on one thing a custom system often lacks: prior authorization as structured data with a status history. Build that once and all four read from it.

Patient Access API: add prior authorizations

You have run this API since January 1, 2021, for claims, encounters and clinical data. From 2027 it must also carry each prior authorization for items and services: its status, the date it was approved or denied, when it ends, the items and services approved, a specific reason if denied, and related structured documentation from the provider. The data must be available "no later than 1 business day after" the payer receives the request, updated within one business day of any status change, and kept while the authorization is active and for at least a year after its last change.

A UM system that records decisions as free-text notes, or sends status only by fax, cannot feed that without changes.

Provider Access API

In-network providers can request a patient's data: claims and encounters without provider remittances or cost-sharing, the USCDI clinical data classes, and prior authorization information, for dates of service from January 1, 2016. The payer answers within one business day, but only for patients it has attributed to that provider and who have not opted out.

That needs three things a legacy system rarely has. An attribution process that ties members to providers. An opt-out the member can change at any time, with plain-language notices before first use, within a week of coverage start and every year. And bulk export, because the required standards include FHIR Bulk Data Access for a provider asking about a whole panel.

Payer-to-Payer API

When a member joins, the new payer asks for permission (this one is opt-in) and starts identifying previous and concurrent payers within a week of coverage start. Once it has them, it requests five years of data within a week: claims and encounters without remittances or cost-sharing, USCDI data, and prior authorizations other than denied ones, with their unstructured documentation. The previous payer answers within one business day. With concurrent coverage, the exchange repeats at least quarterly.

The hard part is not the outbound response. It is taking in data from payers you have never tested against and incorporating it into your member record, as the rule requires.

Prior Authorization API

This is the one that reaches the UM core. The API must list the covered items and services that require prior authorization, identify the documentation required for each, support a HIPAA-compliant request and response, and say whether the payer approved (with the end date), denied (with a specific reason) or needs more information.

CMS recommends, but does not require, three Da Vinci implementation guides here: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). In practice your coverage rules and documentation questionnaires have to become machine-readable, not a PDF policy manual. Payers in the WEDI survey put "Digitizing prior authorization policies" among their top three challenges.

On the transaction itself, HHS gave payers room. On February 28, 2024 it announced enforcement discretion: according to CMS, its National Standards Group "will not take HIPAA Administrative Simplification enforcement action against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process." You may build FHIR only or FHIR with X12, and keep an X12-only transaction alongside.

The standards

The required standards are HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access and OpenID Connect Core; payers may use updated versions voluntarily, under conditions. The 2024 rule listed US Core 3.1.1 and SMART App Launch 1.0.0 with an expiry date of January 1, 2026, so settle which versions you build to before anyone writes the mapping.

Where In-House Systems Usually Fall Short

From what the rule asks, these are the gaps to look for first:

• Prior authorization as a record, not a document. Status, timestamps, denial reason codes and the end date need to be fields, written when they change, with history. A faxed decision needs a structured twin.
• The coverage rules. Which services need authorization, and what documentation each needs, must be data the API can serve. In many plans it lives in policy PDFs and in reviewers' heads.
• Claims as FHIR. Claims and encounters have to come out as FHIR resources, with remittance and cost-sharing removed for providers and other payers but kept for the member.
• Member identity and history. Matching another payer's data to your member, and finding a new member's previous payers, takes demographics and coverage history you may not keep in one place.
• Consent state. An opt-out for Provider Access and an opt-in for Payer-to-Payer, each changeable at any time and checked on every request. A state must also pass a beneficiary's opt-in on to that person's Medicaid managed care plans.
• The one-business-day clock. A nightly mainframe batch is fine for some data and too slow for others. Measure the time from decision to API, not only whether the API answers.
• Delegated vendors. If a delegated UM vendor makes the decisions, its data has to reach you in time for your one-business-day obligation. WEDI's February 2026 survey put "Delegated third parties facing challenges connecting with different systems" first among payers' challenges.

How Far Along the Industry Is

WEDI's survey from February 2026, released on March 10, 2026, found that for the API requirements "10% have not yet started their work," against 33% in October 2025. It also reported "a notable increase in an estimated cost exceeding $5 million from 15% (Oct ’25) to 25% (Feb ’26)." The sample is small: 86 responses, 52% of them from payers. Read it as a signal, not a census.

An Eleven-Week Plan to January 1, 2027

From mid-October, an MA organization or a state FFS program has about eleven weeks. That is not enough to build four APIs from nothing, so the plan is about sequence, and about what you can show on day one.

1. This week: confirm your date and your starting point. January 1, or a later rating period or plan year? List what is already live: the Patient Access and Provider Directory APIs, the 2026 metrics, the denial reasons.
2. Weeks 1 to 2: map every data element to its source. For each API, write down which system holds the data today (claims, UM, enrollment, provider network, clinical) and how fresh it is.
3. Weeks 1 to 3: decide where the FHIR layer lives. A FHIR server or facade in front of the legacy systems, fed by change events or frequent extracts, is usually faster than teaching the core system to speak FHIR. The mapping and the feeds are where the time goes.
4. Weeks 2 to 7: build the shared pieces first. The prior authorization record, consent and attribution, member matching. All four APIs depend on them.
5. Weeks 4 to 9: build the APIs. The Patient Access additions, Provider Access with bulk export, Payer-to-Payer in both directions, and the Prior Authorization API with your coverage rules loaded.
6. Weeks 8 to 11: test with real counterparts. A provider's EHR vendor, another payer, your delegated UM vendor. Test consent changes, a denial with its reason, and a status change that reaches the member within a business day.
7. January 1, 2027: go live and measure. Track latency against the one-business-day rules from day one, and keep a dated list of what is not finished.

If eleven weeks is not enough, take that to your compliance team and counsel now, not in December, with a plan that shows what will be live on January 1 and what follows when.

A Medicaid managed care plan with a July 1, 2027 rating period, or a QHP issuer with a later plan year, can follow the same steps with more room. Start now anyway: the payers and providers you will test with go live on January 1.

What Could Still Move

CMS-0062-P. On April 14, 2026, CMS published a proposed follow-up rule. It would make the currently recommended implementation guides mandatory from October 1, 2027, add drugs to electronic prior authorization from the same date, and have HHS adopt FHIR as the HIPAA standard for prior authorization transactions in place of X12 278. On the existing deadlines it says: "This proposal would not change those compliance dates." Comments closed on June 15, 2026, and as of October 16, 2026 no final rule has appeared in the Federal Register. Build to the 2024 rule, and keep your guide versions in one configurable place.

Versions. The Da Vinci guides keep moving. The FY 2027 IPPS final rule notes that EHRs certified to the new ONC prior authorization criteria "will require use of version 2.2 of the Da Vinci IGs." Those are the systems your Prior Authorization API will talk to.

None of this is a reason to wait. The rule is final, the dates are in the regulation text, and CMS repeated them on October 8.

Where to Get Help

We work on the systems behind the APIs: FHIR mapping of claims, encounter and authorization data, change feeds out of older claims and UM platforms, consent and attribution logic, and the tests that show the one-business-day rules hold. Our legacy system maintenance service is where that starts when the core system is old or the people who built it have left, and if the deadline lands in the middle of a platform replacement, see ERP modernization.

If your claims or UM platform is one no vendor will ship these APIs for, write to office@c9group.dev. We are engineers, not health care lawyers: questions of scope and contract belong with your counsel, and we build to their answer.