CMS-0057-F: A Provider Operations Readiness Checklist
Separate payer obligations from provider reporting measures, then document the workflow questions your practice needs to resolve with payer and EHR partners.
The practical deliverable is a dated readiness register: a requirement, its source, the affected party, an evidence owner and the next action. This checklist explains how to build one. Rule and guidance status below was checked on October 6, 2026.
1. Identify the payer product and service before assigning a requirement
Start with a manageable sample of the authorization work your team handles. Record the payer, product, line of business, requested service, current submission channel and the source used to verify the requirement. An insurer's brand name alone is not a sufficient applicability check.
CMS-0057-F's impacted payer categories include Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the federally facilitated exchanges. Its prior authorization API provisions cover medical items and services, excluding drugs. CMS final-rule fact sheet
Use those categories to begin the review, then have the person responsible for regulatory interpretation resolve the actual product's applicability. Do not mark every product from the same company as covered by the same provision.
Give prescription-drug workflows their own register entry. CMS published a separate drug-related interoperability proposal in April 2026. As of this article's source check, that document is a proposal, not a finalized replacement for the non-drug scope described above. CMS-0062-P proposed-rule fact sheet
For a broader explanation of the rule, see our CMS prior authorization rule guide. This checklist focuses on the work a practice can organize around it.
2. Keep the three calendars separate
A project plan needs more than a column headed "2027." Record whether a date is a payer compliance date, a provider performance or reporting period, or an internal readiness target.
| Workstream | Affected party and current status | Planning implication |
|---|---|---|
| Payer operational provisions | Applicable provisions generally began January 1, 2026. Exact applicability depends on the provision and payer type. | Check the relevant provision before setting a workflow expectation. |
| Payer API provisions | Generally required beginning January 1, 2027, with exact dates varying by payer type. | Obtain the applicable payer's implementation information. |
| MIPS electronic prior authorization measure | Adopted for the 2027 performance period. The 2027 QPP proposal would make it optional for 2027 and required beginning in 2028. | Track the proposal separately until a final rule establishes the outcome. |
| Eligible hospital and critical access hospital measure | CMS describes the finalized FY 2027 IPPS changes as optional for CY 2027 and mandatory beginning CY 2028. | Use the hospital program's current specifications, not the MIPS proposal. |
Sources: CMS-0057-F fact sheet, 2027 QPP proposed-rule fact sheet, electronic prior authorization section, and CMS electronic prior authorization overview.
Assign a program owner to determine whether your clinicians or organization participate in an affected program and which exclusions or specifications apply. Keep that determination separate from the technical team's estimate of when an interface will be available.
The distinction prevents two errors: treating a payer API deadline as every provider's integration mandate, and concluding that providers have no relevant reporting requirements.
3. Build a readiness register with evidence owners
Use the following register as an operating template. The practice tasks are recommendations for organizing readiness; the table does not create additional legal requirements.
| Requirement or readiness task | Affected party | Source to retain | Date to record | Evidence owner | Next verification point |
|---|---|---|---|---|---|
| Determine product and service applicability | Payer, with practice verification | Applicable rule provision and product confirmation | Provision's applicable date | Payer relations or compliance lead | Product or service-scope change |
| Confirm the usable submission channel | Payer and connected vendor | Dated payer instructions and vendor response | Confirmed availability date | Integration lead | Before a pilot or channel change |
| Evaluate a provider reporting measure | Participating clinician or organization | Current program specification and applicability determination | Performance and reporting periods | Program reporting lead | Final rule or specification update |
| Define the staff handoff for unresolved requests | Practice | Approved workflow and role assignment | Internal effective date | Authorization team lead | Pilot review or workflow change |
| Test the exchange and local record | Practice and vendors | Test case, actual result and issue record | Test date and software version | Integration lead | Material interface or workflow change |
Write down what would count as completion for each row. "Vendor contacted" is an activity. "Vendor confirmed the supported product, environment and transaction, with an unresolved-issues list" is usable evidence.
Avoid filling unknown dates with the payer API compliance date. Use "not confirmed" and an assigned follow-up instead. A visible unknown is more useful than an invented commitment.
To see how Linear Health handles the operational side of your prior authorization workflow, book a demo.
4. Ask payer and EHR partners what is available
A vendor discussion should end with a specific account of the workflow that can be supported. Start with one payer product and one transaction path, then ask:
- Which functions are available in our contracted product and software version?
- Is the environment a demonstration, a test connection or a production service?
- What information can the system read, submit and write back?
- Which steps still need a person, another system or a separate channel?
- What evidence will we receive from a test, and who owns unresolved defects?
CMS encourages providers to discuss readiness, upgrades, testing and training with EHR vendors. CMS electronic prior authorization overview. The questions above turn that conversation into a record the practice can use.
Keep a roadmap promise separate from an observed test result. A successful demonstration with sample data should not be recorded as a production transaction for your practice.
For the interface questions behind this exercise, use our FHIR prior authorization API provider guide. For terminology, see what electronic prior authorization means.
5. Document request states and exceptions
Choose status labels that tell staff what happened and what they should do next. A useful local sequence distinguishes information gathering, request submission, confirmed receipt, additional information requested and the payer's decision. These are suggested operational labels, not a CMS-mandated vocabulary.
CMS clarifies that checking coverage requirements does not, by itself, start the payer's decision clock. The clock starts when the payer receives a prior authorization request. CMS process FAQ
That distinction belongs in the record. Preserve the submission event and evidence of receipt separately. If receipt cannot be confirmed, assign someone to resolve it rather than recording an assumed timestamp.
For applicable non-drug requests, CMS describes decisions as due as expeditiously as the patient's condition requires, subject to the relevant maximum timeframes and program-specific extension provisions. The rule's changed decision timeframes exclude QHP issuers on the federally facilitated exchanges. CMS process FAQ. Have the regulatory and clinical owners approve any timer configuration; a generic countdown is not a substitute for that review.
For each exception, retain the original response, its reference, the current owner and the next action. Distinguish a technical delivery problem from missing documentation or a payer decision. Route clinical urgency, medical necessity and decisions about appeals to the appropriately qualified person.
Public payer metrics can provide context, but keep them separate from your practice's measures. CMS's reporting concerns aggregated payer data. CMS process FAQ. Define your own denominator and elapsed-time starting point before comparing results.
6. Maintain a dated change register
Assign someone to maintain the source register after the initial project. Each entry should include the source URL, publication or revision date, access date, affected workflow and whether it describes a final requirement, a proposal or an internal recommendation.
When a source changes, identify the exact register rows affected. Do not replace every date in the project plan just because a new announcement contains a different year.
A useful change note answers four questions: What changed? Who does it affect? Which operational decision must be revisited? Who will verify the new interpretation? Preserve the earlier source reference so the team can understand why a previous decision was made.
The CMS-0062-P proposal and the MIPS proposal belong on that watch list. The finalized hospital measure change belongs in the current requirements register. Keeping those statuses visible makes the next review a targeted update.
Once your register is built, book a demo and we will show you which handoffs Linear can take off your team first.
Before Linear, I needed five systems just to get a patient from referral to appointment. Now I have one screen. The team is coordinating care instead of chasing it.
Frequently asked questions
Which organizations does CMS-0057-F affect?
Which dates belong to which provisions?
How should a provider practice prepare?
How should proposed changes be tracked?
What evidence should the EHR discussion produce?
Sources
Sources accessed October 13, 2026. CMS pages describe CMS's own rules, FAQs and program materials.
- CMS: CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F
- CMS: Electronic Prior Authorization
- CMS: Improving Prior Authorization Processes, FAQs
- CMS: 2027 Quality Payment Program Proposed Rule Fact Sheet and Policy Comparison Table
- CMS: 2026 Interoperability Standards and Prior Authorization for Drugs Proposed Rule