CMS-0057-F: What Medical Practices Should Do Before the 2027 Prior Authorization API Deadline

Why Review Prior Authorization Workflows Before 2027

Prior authorization is one of the most persistent administrative burdens in medical practices. Staff check payer requirements, assemble clinical notes, submit through portals, phone lines, or fax, and then follow up on requests that may sit for days. A federal rule now pushes certain payers toward faster decisions and electronic exchange, and that shift will not reach every practice, payer, or request type at the same time.

The rule is known as CMS-0057-F. The Centers for Medicare & Medicaid Services (CMS) released it on January 17, 2024. CMS states that impacted payers must implement certain provisions by January 1, 2026, and that they have until primarily January 1, 2027 to meet the API requirements. The exact date depends on the type of payer, as explained below.

As of October 2026, the first group of operational requirements is already in effect, and the main API date is about two months away. A practice does not need to build technology to benefit from preparation. It needs to understand which of its payers are covered, how its authorization process runs today, and what its EHR and practice management vendors plan to support.

This article separates what payers are required to do from what practices can sensibly do, and it closes with a checklist. It is educational, not legal advice. Details can differ by payer and state program, so confirm specifics with each payer and your own compliance advisor.

What CMS-0057-F Is and Why It Matters

The full title is the CMS Interoperability and Prior Authorization Final Rule. It builds on the 2020 CMS Interoperability and Patient Access final rule (CMS-9115-F) and focuses on improving health information exchange and the prior authorization process. It was published in the Federal Register on February 8, 2024.

For a practice, the rule matters for three practical reasons.

1. Faster, clearer decisions. Covered payers must meet decision timeframes and give a specific reason when they deny a prior authorization. Both requirements have 2026 compliance dates.
2. More transparency. Covered payers must publicly report certain prior authorization metrics each year, which gives practices a new source of information about payer behavior.
3. Electronic exchange. Covered payers must build APIs, including a Prior Authorization API, that let authorization requests and responses move electronically between systems.

The rule does not eliminate prior authorization. It changes how covered payers must process and communicate the requests they already make.

Which Payers and Processes Are Affected

Scope is where many practices go wrong, so it is worth being precise. According to the CMS fact sheet, the rule applies to these impacted payers:

1. Medicare Advantage (MA) organizations
2. State Medicaid fee-for-service programs
3. State CHIP fee-for-service programs
4. Medicaid managed care plans
5. CHIP managed care entities
6. Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (FFEs)

Several limits matter for planning.

1. Not every insurer is on this list. Other commercial coverage, such as many employer-sponsored plans, is not named by CMS as an impacted payer. Those payers may choose to adopt similar capabilities, but the rule does not require it, so do not assume it. Plans on state-based exchanges are also not named in CMS's list.
2. Drugs are excluded. The fact sheet excludes drug prior authorizations from the API requirements, and the specific denial reason requirement does not apply to drug decisions. CMS has a separate proposal on drug prior authorization (listed on its Electronic Prior Authorization page as CMS-0062-P), which is not part of the CMS-0057-F requirements described here.
3. QHP issuers on the FFEs are excluded from the decision timeframes. The 72-hour and seven-calendar-day timeframes apply to the other impacted payers, not to QHP issuers on the FFEs.
4. Dates vary by payer type. The next section explains how.

Most practices will have a mixed payer panel: some payers fully covered, some partly covered, and some outside the rule. Sort your panel by category rather than treating CMS-0057-F as one universal change.

Prior Authorization API Requirements and Timing

The rule has two layers of requirements that are easy to blur together. Keeping them separate is one of the most useful things a practice can do when reading vendor messages or news coverage.

Operational provisions with 2026 dates

The CMS fact sheet describes these as operational policies with a compliance date starting January 1, 2026. They are already in effect for impacted payers.

1. Decision timeframes. Impacted payers must send decisions within 72 hours for expedited (urgent) requests and within seven calendar days for standard requests. QHP issuers on the FFEs are excluded.
2. Specific denial reasons. Impacted payers must provide a specific reason for a denied prior authorization, regardless of how the request was submitted.
3. Public reporting. Impacted payers must publicly report certain prior authorization metrics annually on their websites, with the first set due by March 31, 2026.

For some payer types, such as Medicaid managed care plans and QHP issuers, the rule ties certain dates to rating periods or plan years. Check a specific payer's provider notices if the exact start date matters to your workflow.

API requirements, primarily January 1, 2027

In the text of the final rule, the 2027 API dates are stated by payer type:

1. MA organizations and state Medicaid and CHIP fee-for-service programs: by January 1, 2027
2. Medicaid managed care plans and CHIP managed care entities: by the rating period beginning on or after January 1, 2027
3. QHP issuers on the FFEs: for plan years beginning on or after January 1, 2027

The same rule also lets state Medicaid and CHIP fee-for-service programs seek an extension of the compliance dates or an exemption from certain requirements. In practice, the date a given payer goes live can differ from January 1, 2027.

The APIs include:

1. Prior Authorization API. Payers must implement and maintain it beginning in 2027. It must identify documentation requirements, support requests and responses, and tell the requester whether a request is approved, denied with a specific reason, or needs more information, as described in CMS's Prior Authorization API FAQ.
2. Provider Access API. It lets in-network providers get certain patient data from the payer. CMS describes it as an opt-out process for patients.
3. Payer-to-Payer API. It supports sharing patient data when a patient changes payers, using an opt-in process. Only data with a date of service within five years of the request must be shared.
4. Patient Access API additions. This API must add prior authorization information, excluding drugs.

The Provider Access and Payer-to-Payer APIs exclude provider remittances and enrollee cost-sharing information, so they are not a substitute for remittance advice or claims data.

What practices are required to do, and what CMS suggests

The CMS fact sheet places the API requirements on impacted payers, not on medical practices, and it does not describe a direct provider duty to use the Provider Access or Payer-to-Payer APIs. The one provider-facing regulatory item is the electronic prior authorization measure in Medicare quality reporting, covered next.

Separately, CMS's Electronic Prior Authorization page presents provider actions as recommended steps rather than mandates. They include confirming readiness and timelines with your EHR vendor, upgrading EHR templates and workflows if needed, beginning FHIR API testing with vendors and payers, and training staff to answer patient questions about prior authorization decisions. Everything in the practical sections of this article falls in that second category: sensible preparation, not a legal requirement.

The MIPS electronic prior authorization measure

The 2024 rule added an Electronic Prior Authorization measure to the Promoting Interoperability category of the Merit-based Incentive Payment System (MIPS), beginning with the CY 2027 performance period. As originally finalized, it is a yes or no attestation, not a numerator and denominator measure. A MIPS eligible clinician attests that they requested a prior authorization electronically through a Prior Authorization API, using certified EHR technology (CEHRT) data, for at least one non-drug item or service, or claims an applicable exclusion.

That finalized timing may change for clinicians. In the CY 2027 Physician Fee Schedule proposed rule (CMS-1848-P, published July 16, 2026), CMS proposes to make the measure optional for the CY 2027 performance period and to require it beginning with CY 2028. The comment period closed on September 14, 2026. This is a proposal. As of October 19, 2026, CMS's Physician Fee Schedule regulation page lists the proposed rule and no final rule, so the clinician measure should be treated as not yet settled. Check the final CY 2027 Physician Fee Schedule rule when it is released before you decide how much to invest around this measure.

The hospital measure is separate. For eligible hospitals and critical access hospitals, CMS has already finalized in the FY 2027 IPPS final rule that the measure is an optional bonus measure for the CY 2027 reporting period and required starting with CY 2028. If your practice works with a hospital or health system, do not assume its timeline is the same as the clinician timeline.

Questions to Ask Your EHR and Practice Management Vendors

Because the Prior Authorization API is a payer-side obligation, your EHR or practice management vendor will not be "compliant with CMS-0057-F" in the same way a payer is. The more useful question is what your systems will be able to do when payers turn their APIs on. Vendors differ widely here, and you should rely on written answers rather than marketing language.

1. Does your product support electronic prior authorization through a payer API, or only through a third-party tool or portal?
2. If support exists, is it live, in testing, or on a roadmap? What is the expected date?
3. Which payers and payer types can you connect to today, and how is that list maintained?
4. If we plan to attest to the MIPS electronic prior authorization measure, does your certified EHR technology support the data and the attestation workflow?
5. What happens when a payer is not connected? Can staff still submit and track requests through current channels without duplicate entry?

Ask for answers in writing. Treat any promise to be "fully ready" as a prompt to ask which payers, which request types, and by what date.

Reviewing Intake, Status Tracking, Documentation, and Staff Workflows

You do not need API connectivity to improve the parts of your process that an API would depend on. Most readiness work is process work.

Authorization intake

Start by listing the services and procedures that trigger prior authorization requests for each major payer. Note which requests come through scheduling, referral, clinical orders, or front-desk intake. Gaps at this stage create delays that no API can fix, such as discovering a requirement after the appointment is booked.

Status tracking

Many practices track prior authorization across spreadsheets, portal logs, and EHR notes. Decide where the single source of truth will live. At minimum, each request should show the payer, service, submission date, submission channel, expected decision date, decision, and the denial reason if one was given. For payers that fall under the 72-hour and seven-day timeframes, tracking the expected decision date gives staff a clear trigger to follow up on late requests.

Documentation

A Prior Authorization API is designed to surface documentation requirements. That helps only if your clinical documentation is organized and consistent. Review the notes, imaging, and test results payers most often ask for, and build short internal templates for the highest-volume authorizations so clinicians capture the same required elements each time. Weak documentation also drives avoidable denials downstream. For related background, see our guide to common Medicare claim denials and how to prevent them.

Denial reasons and appeals

With specific denial reasons now required of impacted payers, practices can sort prior authorization denials into categories they can act on, such as missing documentation, service not covered, or medical necessity criteria not met. Capture the reason in a structured field rather than free text. Over time, this shows which payers and services generate the most rework and where an appeal or an upstream documentation fix pays off. Our article on medical claim denial management covers the broader workflow of triaging and following up on denials.

FHIR and Interoperability in Plain Language

FHIR stands for Fast Healthcare Interoperability Resources. It is a standard, developed by HL7, for describing and exchanging healthcare data in a consistent, machine-readable format. An API is the doorway through which one system asks another for data or sends data to it.

Today, a prior authorization often depends on a person reading a payer web page and typing details into a form. In an API-based process, the practice's system can send a structured request to the payer's system, and the payer's system can send back a structured response: approved, denied with a specific reason, or more information needed.

Two cautions keep expectations realistic. First, an API is only as useful as the systems on both ends. A payer API does little for a practice whose EHR cannot connect to it. Second, CMS recommends but does not require the HL7 Da Vinci implementation guides for coverage requirements discovery, documentation templates and rules, and prior authorization support, as noted in CMS's rulemaking snapshot. That means vendors may implement the connection differently. Confirm which specifications your vendor actually supports rather than assuming.

Common Readiness Gaps and Assumptions to Avoid

1. Assuming every payer is covered. Only the payer categories CMS lists are covered, and some provisions exclude drugs or specific payer types.
2. Assuming the API date is the practice's deadline. January 1, 2027 is primarily the payer API date. It is not a date by which a practice must have installed new software.
3. Believing all prior authorizations will move to the API immediately. Payers will roll out at different speeds, and drug authorizations are outside the rule. Expect a long period where portals, fax, and phone remain in use.
4. Treating the clinician MIPS measure as settled. The CY 2027 proposal could change its timing and scoring role, and the hospital measure follows a different, already finalized path.

Practical Readiness Checklist

1. Sort your payers. List your top payers by volume and mark whether each falls into an impacted category: Medicare Advantage, Medicaid or CHIP (fee-for-service or managed care), or a QHP on the FFEs.
2. Map your authorization triggers. Document which services require prior authorization for each major payer and who initiates the request.
3. Choose one tracking method. Record payer, service, dates, channel, decision, and denial reason in one place.
4. Standardize denial reason capture. Use structured categories so you can report on patterns.
5. Prepare documentation templates. Start with your highest-volume authorizations.
6. Send written questions to your EHR and practice management vendors. Use the list above and file the responses.
7. Check your MIPS plan. Decide whether you are MIPS eligible, whether an exclusion may apply, and watch for the final CY 2027 Physician Fee Schedule rule.
8. Look for payer announcements. Watch for provider notices from your major payers about API availability, portals, and timelines.
9. Keep a fallback. Maintain portal, phone, and fax procedures until a payer confirms a new channel works for your practice.

Frequently Asked Questions

What is CMS-0057-F?

It is the CMS Interoperability and Prior Authorization Final Rule, released January 17, 2024. It sets requirements for certain payers on prior authorization timeframes, denial explanations, public reporting, and several data-exchange APIs.

Does CMS-0057-F apply to every insurance company?

No. CMS lists Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally Facilitated Exchanges. Other coverage is not named by the rule, and some provisions have further limits.

Is January 1, 2027 a deadline for my practice?

Not as a practice-level compliance date. It is primarily the date by which impacted payers must meet the API requirements, with payer-specific variations. The provider-facing regulatory item is the Medicare electronic prior authorization measure, and the clinician version of that measure is under a CY 2027 proposal.

What took effect in 2026?

Decision timeframes of 72 hours for expedited and seven calendar days for standard requests (except for QHP issuers on the FFEs), the requirement for a specific denial reason, and public reporting of prior authorization metrics, with an initial set due by March 31, 2026.

Do these rules cover prescription drug prior authorization?

No. CMS excludes drugs from the API requirements, and the specific denial reason requirement does not apply to drug decisions. CMS has a separate proposal on drug prior authorization.

What is the MIPS electronic prior authorization measure?

It is a Promoting Interoperability attestation in MIPS that CMS originally finalized for the CY 2027 performance period. The CY 2027 Physician Fee Schedule proposed rule would make it optional for 2027 and required from 2028. That proposal had not been finalized as of October 19, 2026, so check the final rule for the current status.

Conclusion

CMS-0057-F is a payer-focused rule, but its effects will reach practices through faster decisions, clearer denial reasons, new transparency data, and, over time, electronic authorization channels. The best preparation is steady and practical: know which of your payers are covered, keep your authorization intake and tracking clean, organize your documentation, and get written answers from your vendors. The January 2027 date is a useful prompt to review workflows, not a reason to panic or to buy technology before you understand your needs.

How Edge RCM Can Help

Edge RCM provides medical billing and revenue cycle management for medical practices, including prior authorization support, denial management, and appeals. If your team wants help keeping prior authorization requests, denial follow-up, and documentation organized as payer processes change, you can contact the Edge RCM team.