CMS 0057: A Guide to 2027 Deadlines, APIs, and Compliance

Posted in Healthcare Compliance

CMS-0057-F is a federal interoperability and prior authorization rule issued by the Centers for Medicare & Medicaid Services. It makes prior authorization faster, more transparent, and easier to manage electronically. The rule requires affected payers to implement four HL7 FHIR APIs, make standard prior authorization decisions within seven calendar days and expedited decisions within 72 hours, provide a specific reason for each denial, and publish prior authorization metrics annually. CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and qualified health plans offered through federally facilitated exchanges. The prior authorization and reporting requirements have applied since January 1, 2026, while most API requirements are due January 1, 2027. Some Medicaid managed care plans and qualified health plan issuers follow different deadlines based on their rating periods or plan years.

This guide explains the compliance dates for each plan type, how the FHIR prior authorization workflow connects EHRs and payers, what the seven-day decision standard means for utilization management, and how organizations should prioritize the remaining work.

CMS 0057 Deadlines and Current Status

The March 2027 Deadline Is an Active Requirement

The March 2027 report covers calendar year 2026; that means the work behind the report cannot wait until the reporting deadline approaches.

Plans should already be capturing prior authorization decisions in a consistent, reportable structure. This includes the date a request was received, whether it was standard or expedited, the date and time a decision was issued, the outcome, and the specific reason for any denial.

If that information is not being recorded now, the organization is accumulating a reporting gap. Some data may be recoverable from claims, portals, utilization management platforms, call logs, or document repositories, but those sources may not contain all the fields required for accurate reporting. A plan cannot assume it will be able to reconstruct a full year of authorization activity in February 2027.

• The report is due in 2027.
• The reporting period is happening in 2026.
• The data model, tracking process, and quality controls must already be operating.

CMS-0057-F Expands the Earlier Interoperability Rule

CMS-0057-F does not replace the 2020 CMS Interoperability and Patient Access rule, CMS-9115-F. It amends and expands the framework created by that rule.

CMS-9115-F established the original Patient Access API and Provider Directory API requirements. Those requirements gave patients electronic access to certain claims and clinical information and made provider directory data available through standardized APIs.

CMS-0057-F builds on that foundation in several ways. It expands the data available through the Patient Access API, introduces three additional payer-facing APIs, and adds prior authorization process requirements alongside the technical interoperability requirements.

Under CMS-0057-F, impacted payers must support:

• An enhanced Patient Access API
• A Provider Access API
• A Payer-to-Payer API
• A Prior Authorization API

The rule also adds operational requirements that do not depend solely on API implementation. These include shorter prior authorization decision timeframes, specific reasons for denials, and annual public reporting of prior authorization metrics.

This is what makes CMS-0057-F different from a purely technical interoperability mandate. It changes both the systems payers must operate, and the way prior authorization work must be performed, measured, and explained.

January 1, 2027, Is Not Every Payer’s Exact Deadline

Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs generally work toward the January 1, 2027, compliance date.

Medicaid and CHIP managed care plans, however, follow rating periods beginning on or after January 1, 2027. Qualified health plan issuers on federally facilitated exchanges follow plan years beginning on or after January 1, 2027.

That difference affects implementation planning. A payer should not rely only on the headline date. It must identify the applicable plan year, rating period, contract structure, and line of business before determining its actual production deadline.

For organizations operating several regulated products, this may result in more than one effective date across the enterprise. The technical platform may be shared, but compliance obligations can begin at different times depending on the product.

What the Rule Does Not Cover

Two important areas sit outside the prior authorization requirements of CMS-0057-F.

Drug Prior Authorization

Drug prior authorization is excluded whether the drug is covered under the medical benefit or the pharmacy benefit.

This means the CMS-0057-F Prior Authorization API requirements focus on medical items and services. They do not require payers to process prescription drug prior authorizations through the same API workflow.

This distinction is important because medical and pharmacy authorization processes are often handled by different systems, vendors, benefit managers, and clinical teams. Organizations should avoid assuming that CMS-0057-F creates one unified prior authorization requirement across both medical services and prescription drugs.

Commercial and ERISA Plans

The rule applies to specified federally regulated programs. It does not broadly extend to every commercial health plan or every employer-sponsored plan.

Commercial products outside the federally facilitated exchanges and most ERISA plans are not covered solely because they provide health insurance. A payer may therefore have CMS-regulated lines of business that must comply with CMS-0057-F and other commercial lines that are outside the rule.

This creates an important implementation decision. An organization may build the required capabilities only for regulated products, or it may choose to extend the same API and prior authorization processes across additional lines of business for operational consistency.

The rule does not require that broader expansion, but maintaining separate workflows may increase administrative complexity.

Most of the Rule Applies Directly to Payers

CMS-0057-F is primarily a payer regulation. Most of its requirements fall on Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and qualified health plans on federally facilitated exchanges.

Payers are responsible for implementing the required APIs, meeting applicable prior authorization decision timeframes, giving specific reasons for denials, making required data available, and publishing or submitting the required metrics.

Providers are not responsible for operating the payer APIs or reporting payer authorization metrics. They also do not carry the payer’s obligation to issue decisions within the required timeframes. However, providers are not entirely outside the rule.

Why the Provider Measure Creates Demand for the API

The payer requirements create the supply side of the CMS-0057-F framework. Payers must build and operate the Prior Authorization API.

The provider measure creates part of the demand side. Clinicians, hospitals, and critical access hospitals need the ability to use the API through certified EHR technology if they are going to attest successfully.

That creates several connected pressures:

• Payers must make the API available and usable.
• EHR vendors must integrate the prior authorization workflow into clinical systems.
• Providers need access to payer requirements and documentation rules inside their normal workflow.
• Authorization requests must move between EHRs and payer systems without depending entirely on portals, phone calls, fax machines, or manual data entry.
• Both sides need testing, identity management, workflow mapping, and exception handling before production use becomes reliable.

This single provider measure is therefore more important than its size suggests. It gives providers a direct reason to use the Prior Authorization API and gives EHR vendors a reason to support it.

The payer mandate alone requires the API to exist. The provider measure helps create the conditions for the API to be used.

Common Misunderstandings About CMS 0057

Everyone’s Deadline Is January 1, 2027

January 1, 2027, is the correct API deadline for Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs. For other payer types, the deadline is expressed through rating periods or plan years.

A Medicaid managed care organization operating on a July-to-June rating period may have an API compliance date of July 1, 2027. That provides six additional months, which can be the difference between an emergency implementation and a controlled plan. Confirm the date against the applicable contract rather than relying only on trade-press summaries.

Two Important Timing Exceptions

Two distinctions are often missed.

• QHP issuers on federally facilitated exchanges: They are not subject to the seven-day standard decision timeframe, although the denial-reason and API requirements still apply.
• Medicaid managed care plans: The seven-day ceiling reaches the plan through the state’s managed care contract, so the effective date may depend on the state’s contract amendment cycle.

State readiness has not been uniform. A KFF survey found that, as of July 1, 2024, 18 of 36 responding states already required standard decisions within seven calendar days or less. The remaining 18 allowed longer timeframes, meaning roughly half of the responding states with managed care still had contract language to revise.

Those figures are now two years old, and states have continued amending their requirements. However, organizations operating across multiple states should not assume that their effective dates are identical.

Delegated Utilization Management Does Not Transfer the Risk

When utilization management is delegated, the delegate’s turnaround time still becomes the payer’s compliance exposure.

Confirm that the delegation agreement includes service levels capable of meeting the federal decision ceiling. The payer should also be able to access the delegate’s request, decision, and notification timestamps when the annual reporting deadline arrives.

4 APIs Are Four Different Projects

The four required APIs are separate deliverables with different operational problems. Treating them as one technical program with one team is one of the most common planning errors in CMS-0057-F compliance work.

1. Patient Access API

This is an extension of an API most impacted payers already operate. Its scope is relatively contained, and the remaining work is primarily technical.

2. Provider Access API

This is primarily an attribution problem: the payer must determine which patients are connected to which providers.

Before giving an in-network provider access to five years of member data, the payer needs a defensible method for establishing that treatment relationship. The main approaches are:

• Primary care assignment: Clean and easy to explain, but it excludes many specialists.
• Claims-based lookback: Captures more relationships, but the results lag behind care delivery because claims take time to arrive.
• Provider roster submission: Potentially the most accurate method, but only when the provider keeps the roster current.

Choose an attribution method, document the logic, and be prepared to defend it to both auditors and provider organizations.

3. Payer-to-Payer API

This is primarily a consent problem. Five years of data must move when a member changes coverage, but only when the member opts in. The underlying data exchange may be straightforward. Capturing the member’s consent during enrollment is more difficult.

4. Prior Authorization API

This is a clinical policy problem presented as an API implementation. It requires more than a working endpoint and is addressed separately below. Each API has different owners, lead times, dependencies, and failure modes. The staffing plan should reflect those differences.

A Compliant API Can Still Move No Traffic

A prior authorization API supports a two-sided transaction. If providers are not sending requests, the payer’s endpoint processes nothing. WEDI’s February 2026 readiness survey, released at HIMSS26, presents two different pictures.

1. Payers Are Mobilizing

The share of payer respondents that had not started API work fell from 33% in October 2025 to 10% in February 2026. That represents meaningful movement in four months. However, the progress behind the headline remains uneven. Thirty-five percent of payer respondents reported being 25% complete or less on the Patient Access API alone.

2. Provider Readiness Is Falling Behind

One-third of provider respondents still had not started. Sixty-seven percent could not estimate their implementation progress or total cost, and no provider respondent in that survey round reported measurable implementation progress. Provider confidence in meeting the 2027 deadline also fell to 47%, down from 69% in October 2025.

3. The Survey Shows Direction, Not a Census

The respondent pool has also become smaller as the deadline approaches. Eighty-three organizations participated in February 2026, compared with 173 in October 2025 and 243 in early 2025.

The results are therefore better understood as an indication of industry direction than as a complete measure of market readiness.

The MIPS Measure Creates the Demand Signal

This is where the MIPS measure discussed earlier becomes important. Providers have their own attestation requirement beginning in calendar year 2027, and it requires them to submit at least one request through a Prior Authorization API.

That measure creates a demand signal within the rule. It also means the payer endpoint is not merely a compliance artifact. Someone on the other side of the transaction has a reporting reason to use it, which is more than many interoperability mandates provide.

A payer can still pass an audit in January and operate an API that processes no traffic. Technical compliance and real-world adoption are separate problems, require different remedies, and only one of them usually appears on the implementation plan.

How the FHIR Prior Authorization API Workflow Works

The CMS prior authorization API isn’t a single interface. It’s three Da Vinci implementation guides working together inside a doctor’s ordering screen.

CRD, or Coverage Requirements Discovery

A physician places an order. The EHR sends an automatic query to the payer at that moment, usually when the order is selected or signed, asking one question: does this service need prior authorization for this member? The answer comes back as a small card on screen before the clinician moves on.

DTR, or Documentation Templates and Rules

If authorization is required, DTR opens either as a small app inside the EHR or as part of the EHR itself. It pulls what it can from the chart automatically, using the standard data format most certified EHRs already support, and then asks the clinician only for what is genuinely missing. Done properly, twenty minutes of nurse chart abstraction becomes ninety seconds of clicking.

PAS, or Prior Authorization Support

• PAS sends the prior authorization request and returns a response: approved, denied with a reason, or pended for more information.
• PAS can be implemented first, with CRD and DTR added later, although using all three together reduces the most manual work.
• CRD and DTR are harder because utilization management policies must be converted from PDFs, vendor systems, and reviewer knowledge into machine-readable rules.
• This requires engineers, medical directors, and clinical reviewers, so the work often takes longer than expected.
• Medicare Advantage plans that already documented coverage criteria under earlier CMS reforms may have a head start.
• CMS allows an all-FHIR workflow without requiring X12 278 underneath it, but this is enforcement discretion, not a formal repeal of the X12 standard.
• The workflow also depends on provider adoption. Without EHR support for CRD, DTR, and PAS, the payer API may be live but receive little traffic.

Prioritizing The Remaining CMS 0057 Work

Five months forces a prioritization most plans haven’t done explicitly. Score your organization on five factors, then read the pattern rather than the total.

Two readings worth naming. A plan with high PA volume concentrated in a few large provider groups has the best case for going hard at the prior authorization API, because a handful of joint integrations covers most of the traffic. A plan with volume spread across hundreds of small practices has a much weaker adoption case and should probably meet the requirement competently and spend the marginal dollar on Provider Access instead.

Build In-House, Buy a Platform, or Use a Partner

Packaged platforms fit best when your core administration system is mainstream and your policy set is contained. They fit worst when the hard part is a mainframe claims platform or a homegrown UM system, because the FHIR layer was never your constraint. Partner-led delivery fits when connectivity is the real problem. In-house builds make sense mainly for larger plans with existing FHIR capability who intend to treat interoperability as a lasting capability rather than a one-time compliance event.

Five questions that sort vendors quickly:

• Which implementation guide versions do you support today, and what happens when the versions change?
• Show me a production deployment against my core administration platform, not a reference architecture.
• Who owns conformance testing, and who produces the evidence if CMS asks?
• How do you handle opt-in and opt-out status across systems you don’t own?
• What’s your CMS-0062-P roadmap, and is absorbing it a release or a rebuild?

HL7 and FHIR Integration Support by Folio3 Digital Health

Building the new APIs is usually not the hard part of a CMS 0057 project. The difficulty is connecting them to the systems a health plan already runs. Folio3 Digital Health builds those connections. Our HL7 and FHIR integration services link established payer systems, including older HL7 v2 interfaces that many plans still depend on, to the standards CMS now requires. We address HIPAA requirements during the build rather than reviewing them at the end, and we work to the deadline you have already committed to.

Closing Note 

CMS-0062-P is the next rule to plan for. CMS released the 2026 CMS Interoperability Standards and Prior Authorization for Drugs proposed rule on April 10, 2026. It was published in the Federal Register on April 14, and comments closed on June 15.

It closes the drug gap and extends the architecture:

• Electronic prior authorization and transparency requirements extend to drugs under both the medical and pharmacy benefit
• Tighter decision windows are proposed, including a 24-hour expedited standard for some programs
• Specific implementation guide versions would become required, including CARIN Blue Button 2.2.0, Da Vinci PDex 2.1.0, CRD 2.2.1, DTR 2.2.0, and PAS 2.2.1, with older STU 2-era guides expiring January 1, 2028
• A mandatory FHIR endpoint registry, plus API usage metrics reported to CMS
• Most provisions carry a proposed effective date of October 1, 2027, including the NCPDP pharmacy standards
• Small-group QHP issuers on FF-SHOPs come into scope

Provisions can change before this is finalized. The versioning proposal is the piece to design around today. Assume the implementation guides underneath your build will be re-versioned, because an architecture that hard-codes one version will need surgery within eighteen months. That single design decision is worth more than any feature on a vendor demo.

Frequently Asked Questions 

1. What is CMS 0057?

A federal rule requiring certain health plans to run four FHIR-based APIs, decide prior authorizations faster, give specific denial reasons, and publish authorization metrics every year.

2. Who has to comply with CMS 0057?

Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and QHP issuers on federally facilitated exchanges. Commercial and ERISA plans are out of scope.

3. Is CMS 0057 the same as CMS-0057-F?

Yes. The suffix marks the document stage. CMS-0057-P was the December 2022 proposal. CMS-0057-F is the final rule, announced January 17, 2024, and published in the Federal Register on February 8, 2024.

4. What was due in CMS 0057 2026 vs CMS 0057 2027?

2026 covered decision timeframes, denial reasons, and the first public metrics report by March 31. 2027 covers the four APIs, due January 1 for most impacted payers.

5. Does CMS 0057 cover drugs?

No. Drugs were excluded and addressed separately in CMS-0062-P, released April 10, 2026.

6. Does the prior authorization API replace X12 278?

Not required to. February 2024 enforcement discretion means plans running an all-FHIR workflow aren’t obligated to use X12 278 underneath it. X12 278 is still the adopted HIPAA standard, so this is a policy position rather than a repeal.

7. What are the penalties for non-compliance?

CMS enforcement can reach program participation and contract compliance. For Medicaid managed care, states enforce through MCO contract terms, so consequences vary by state.

About the Author