CMS-0057-F sets process and data-sharing duties for named payer groups. It does not govern every payer, plan, service, or request. Billing teams must check scope, dates, and the payer's current path before changing work.
This guide reflects the CMS fact sheet checked on October 3, 2026. It separates payer duties from provider tasks.
What is CMS-0057-F and which payers does it affect?
The rule applies to five payer groups named by CMS, subject to each provision's scope.
The named groups are:
- Medicare Advantage organizations.
- State Medicaid and CHIP fee-for-service programs.
- Medicaid managed care plans and CHIP managed care entities.
- Qualified Health Plan issuers on federally facilitated exchanges.
Original Medicare fee-for-service is not a named impacted group. Broad commercial and self-funded plans are not named either. Another law, contract, or payer rule may still apply.
Staff should verify the payer, plan, and product. A payer brand may run affected and unaffected plans. Drug prior authorizations are excluded from these provisions.
When do the process and API provisions start?
Process duties generally start January 1, 2026, while API duties generally start January 1, 2027. Exact dates vary by payer type.
The CMS-0057-F fact sheet gives the official scope and timing. A team should not turn these general dates into one deadline for every payer group.
An API lets software exchange set data.
Keep a dated rule source and current request route for each plan. A compliance date does not prove a vendor link works or a request arrived.
Which 2026 process changes matter to billing teams?
The main changes are decision time frames, specific denial reasons, and public prior authorization metrics.
Impacted payers must send decisions within 72 hours for expedited requests and seven calendar days for standard requests. This decision-time rule excludes Qualified Health Plan issuers on federally facilitated exchanges. Staff should preserve how the payer classed the request and when it received the request. They should not decide clinical urgency on their own.
Beginning in 2026, impacted payers must give a specific reason when they deny a prior authorization request. That duty applies regardless of the route used for the request. The team should save the exact reason instead of replacing it with a broad office label.
Impacted payers must also post certain aggregate prior authorization metrics each year. The first public report was due March 31, 2026, for the prior calendar year. A public metric can show broad payer patterns. It does not decide one patient's request.
These provisions exclude drug prior authorizations. The prior authorization tracking guide shows how to preserve a request, receipt, reply, scope, and next owner.
What do the 2027 APIs do?
Each API has a different data-sharing job, and none turns data exchange into coverage or payment.
The Prior Authorization API must list covered items and services. It must identify the records needed for approval. It must support a request and response. The response must approve and state when or how approval ends, deny with a specific reason, or ask for more information.
The other interfaces serve different needs:
| Interface | Main use for provider teams |
|---|---|
| Provider Access API | Gives in-network providers access to certain patient data when the rule's conditions are met and the patient has not opted out. |
| Patient Access API | Adds certain prior authorization data to information a patient can access through a chosen app. |
| Payer-to-Payer API | Supports exchange of certain patient data between payers when its permission and scope rules are met. |
The fact sheet also describes an Electronic Prior Authorization measure. MIPS eligible clinicians begin reporting with the 2027 performance period and 2029 payment year. Eligible hospitals and critical access hospitals begin with the 2027 EHR reporting period. It is a yes/no attestation with an applicable exclusion path. It requires at least one qualifying electronic request through a Prior Authorization API.
An API receipt shows data movement at one step. It does not prove coverage, approval, network treatment, claim acceptance, payment, or patient cost. The medical need, coverage, and authorization guide maps these decisions.
How should each provision change provider work?
The team should map each payer duty to a narrow provider action and saved proof.
| Rule provision | Provider-team action | Proof to keep |
|---|---|---|
| Named payer scope | Map each plan to a named group before using the rule. | Current scope source and plan record. |
| Decision time frames | Record payer classification, receipt time, and the applicable due point. | Request, receipt, and status history. |
| Specific denial reason | Route the exact payer reason to the right owner. | Full denial response. |
| Public metrics | Use aggregate data only as payer context. | Dated public report. |
| Prior Authorization API | Test rule lookup, required records, send proof, and full response. | Test result and live case evidence. |
| Other access APIs | Coordinate access and data flow with system and privacy owners. | Access test, role approval, and source record. |
The provider controls care and clinical facts. Billing staff may route a record request. They must not create missing facts or change care to fit a payer response.
What does a rule-aware case look like?
The team checks the payer group, applicable date, service type, request route, and written result in order.
Hypothetical scenario: A dental practice prepares a medical prior authorization request. The patient has a Medicare Advantage plan. Staff confirm the named group and that the request is not for a drug.
The payer classifies the request as standard. Staff use the payer's current path and keep its receipt. They track the due point that applies to that payer and request. The provider approves all clinical records.
The payer asks for one more record. Staff route the task to the record owner. They do not add new clinical facts. The payer later denies the request and gives a specific reason. Staff save the full reply and route it through the payer's current review process.
After that payer's API compliance date, the practice may test the new electronic path. It must still preserve the full request and response. The result does not prove coverage, network terms, payment, or patient responsibility.
Frequently asked questions
Does CMS-0057-F apply to every payer and request?
No. CMS names specific payer groups and excludes drug prior authorizations from these provisions. Staff must check the payer, plan, service, date, and current rule for each case.
Does an electronic approval prove that the claim will be paid?
No. Plan status, coverage, network terms, claim facts, payer review, payment, and patient cost remain separate.
This guide is general administrative information, not legal, medical, clinical, dental, coding, documentation, privacy, security, contract, accounting, financial, patient-billing, or coverage advice, and not a statement that any workflow, record, request, response, claim, payment, adjustment, deadline, decision, or outcome is accurate, complete, compliant, authorized, covered, or payable. Requirements and outcomes vary by payer, program, plan, patient, provider, service, record, agreement, system, jurisdiction, and date.
