CMS-0057-F explained: what health plans have to build by 2027
A major change in US healthcare is about to come in January 2027, which is the deadline for health plans to go live with prior authorization APIs.
At Medblocks, we’re working with a lot of health plans, and we see the same pattern time and time again when it comes to implementation where a lot of them have absolutely no idea how to handle this implementation, and on the other hand there are also some who have read the specs and think it’s simple enough but they find very quickly that it is not.
So in this course we’ll guide you through all you need to know about the CMS Interoperability and Prior Authorization Final Rule CMS-0057-F.
We’ll be covering everything you need to get from the spec to a working implementation:
- The three Da Vinci specs behind the rule: CRD (Coverage Requirements Discovery) for discovering if a prior authorization is needed, DTR (Documentation Templates and Rules) for collecting the documentation inside the EHR, and PAS(Prior Authorization Support) for submitting the request and getting the decision back
- The Da Vinci and FHIR specifications in detail
- How to split implementation between a plan and its vendor.
- How to test yourself against compliance, with a build that passes the Inferno test kit
What is CMS-0057-F?
CMS-0057-F is the CMS Interoperability and Prior Authorization final rule, finalized in January 2024. You might also see it written as CMS 0057, or called the CMS interoperability rule.
In plain terms, it’s a federal rule designed to fix prior authorization: the approval a provider needs from a health plan before going ahead with a treatment.
Once it’s in effect, a doctor can find out during the appointment whether a procedure needs approval and what paperwork the plan requires, send the request instantly, and get the plan’s decision within 72 hours for urgent requests, or 7 days for standard ones.
Technically, that means health plans have to share health data through standard FHIR APIs and handle prior authorization electronically: requests and decisions move through APIs, decisions come back within fixed timeframes, and denials come with a reason.
The rule also covers a lot more than prior authorization. It requires a patient access API, a provider access API, and a payer-to-payer API. But the biggest change coming in 2027 is the prior authorization APIs.
We can build CRD, DTR and PAS for you
We already do this for health plans and their vendors. Reach out if you want help with the build, or just want to talk through your setup
Book a CallWho has to comply with CMS-0057-F
CMS calls them “impacted payers,” and the deadline is for health plans serving under any of these programs:
- Medicare Advantage organizations
Every MA plan must implement and maintain the required APIs. This covers the major national MA carriers, UnitedHealthcare, Humana, Aetna, along with the smaller regional MA plans that only operate in a handful of counties. - Medicaid and CHIP, both fee-for-service and managed care
This is four of CMS’s five categories in one: state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities. In practice, that means both a state Medicaid agency running its own FFS program directly, and the managed care organizations states contract out to, Centene, Molina, UnitedHealthcare Community Plan, are all on the hook. - QHP issuers on the Federally Facilitated Exchanges
Exchange plans build the same APIs, but sit outside the 72-hour and 7-day decision timeframes, which apply to the other impacted payers only. This is the marketplace plans sold on healthcare.gov, think Ambetter, Oscar Health, or a Blue Cross Blue Shield affiliate’s exchange product, in any state using the federal exchange rather than a state-run one.
Also when we say health plan, it rarely means one entity, most plans have vendors and business associates executing on their behalf. So they are also involved in this rule.
CMS is reaching providers too, just not directly
The rule doesn’t put a requirement directly on providers but CMS has added a new measure titled Electronic Prior Authorization to the MIPS Promoting Interoperability performance category, and to the Medicare Promoting Interoperability Program for hospitals.
To successfully report it:
- MIPS eligible clinicians must attest “yes” to requesting at least one prior authorization electronically via a Prior Authorization API, using data from certified EHR technology (CEHRT), for a medical item or service ordered during the CY 2027 performance period, or claim an exclusion. The attestation counts toward the CY 2029 MIPS payment year.
- Eligible hospitals and critical access hospitals must attest the same for the CY 2027 EHR reporting period.
To attest, the request has to run through a Prior Authorization API using data from certified EHR technology, which means an EHR has to support these APIs.
Why CMS-0057-F matters
This rule doesn’t leave anyone out. Payers are bound by it directly. Providers are scored on it through the Electronic Prior Authorization measure we mentioned earlier. And EHRs are handled by ONC’s HTI-4 rule, which adds certification criteria g31, g32 and g33.
The federal government has already gone after EHRs for information blocking, for not exposing the FHIR APIs they were certified on, so the enforcement of these regulations is also being done pretty strictly.
HIPAA’s own standard is being set aside to make room.
Since HIPAA, covered entities have been mandated to use X12 for these transactions, a set of standard EDI formats, each one identified by a number. The 278 is the one for prior authorization. CMS is now exercising enforcement discretion: implement the FHIR-based Prior Authorization API, and they won’t come after you for skipping the X12 transaction. So the same agency that mandated a standard in the 1990s is telling you it won’t enforce it, to clear the way for this one.
What actually changes for the clinician
The rule puts prior auth decisions on a clock: 72 hours for an urgent request, 7 calendar days for a standard one, and every denial has to carry a specific reason.
Today, finding out whether a procedure needs prior auth at all is a phone call, or a login to that payer’s portal. Under this rule, it’s answered inside the EHR while the clinician is placing the order.
How prior authorization works today
Somebody at the provider keeps a mental list of which procedures need prior authorization for which plan. When an order comes up, they check it against that list. If they’re not sure, they call the health plan on the phone. Sometimes the plan accepts a fax, so they send the fax. Then everybody waits, and the patient’s treatment waits with them.
If the EHR and the plan both support it: the EHR sends an X12 278 message to the plan and gets a response back a few days later. Approved, or not.
But the process starts with someone who already knew this procedure needed prior authorization. But what do you do if you don’t know? That part was manual. It was the phone call, and a lot of back and forth to get the information out.
And a lot of the time the plan doesn’t support X12 at all. Then the provider goes into that particular plan’s portal and fills out a form for that particular procedure. For a busy practice that’s hundreds of patients every day, each one potentially on a different plan with a different portal. It gets really tiring.
This is what burden reduction is actually about. When CMS uses that phrase, it means reducing the number of forms somebody has to fill out to get something done.
How prior authorization works after CMS-0057-F
The Da Vinci specs that implement the rule, CRD, DTR and PAS, all run on CDS Hooks.
CDS Hooks lives inside the EHR. It’s a way for an outside service to get in the way of a clinician’s workflow: the clinician does something in the EHR, the EHR calls out to the service, and whatever comes back shows up on the clinician’s screen while they’re still there.
For example, when the clinician is prescribing a drug, the CDS Hook alert will pop-up saying “You’re prescribing this drug, consider another one”. Or when the clinician is prescribing a test, the CDS Hooks alert pops up and says “This patient isn’t eligible for this procedure, do something else.”
The health plan can now make use of CDS Hooks to pop-up in the clinician’s workflow. We go through how CDS Hooks works in the next lesson.
CRD: Coverage Requirements Discovery
The Coverage Requirements Discovery is the first step where the health plan answers while the order is being placed
A clinician is working in the EHR. The EHR calls the health plan’s CDS Hooks endpoint, the plan responds, and the response shows up to the clinician as cards. A card might be a warning, or a suggestion to change the drug. The clinician reads it and acts on it in the EHR.
The round trip takes 5 to 10 seconds. Earlier it used to take days, sometimes weeks. The rule brings the decision down to 72 hours. CRD brings the first question, does this need prior auth at all, down to seconds, inside the workflow where the order is being placed.
DTR: Documentation Templates and Rules
This is the second step of the process where the form moves into the EHR
The health plan can return a form to the EHR in a standardised FHIR format, and the clinician fills it out inside the EHR.
Before, that form lived in the plan’s portal. The provider logged in to one portal to fill out one form for one patient on one plan. Now the form sits inside the EHR and the clinician fills it in their own time, in the system they were already using. That’s a real chunk of the burden reduction, just from moving the form into a system the clinician was already using.
There are rules about how the questionnaire has to behave, too. Fields are filled in by default from what’s already in the record, and the clinician only answers what the plan actually needs from them. [SOURCE? DTR IG prepopulation requirement, check the exact wording before we state it as a rule]
We’ll look at how CRD hands off to DTR later in the course. For now: CRD tells you a prior auth is needed, DTR collects what the plan wants.
The plan can read the chart
During both CRD and DTR, the health plan can query the EHR’s FHIR server for data about the patient. So the plan isn’t asking questions blind. It looks at what’s already in the record and decides what it still needs from the clinician. That’s what makes prepopulation possible.
PAS: Prior Authorization Support
Once the form is filled, the EHR generates the prior authorization packet and sends it to the health plan. This is Prior Authorization Support, PAS.
After that, the EHR can ask the plan for status. Is this approved yet? There’s also a second channel through FHIR Subscriptions, where the plan notifies the EHR when the decision is ready, so nobody has to keep polling.
CRD, DTR and PAS are three separate implementation guides under Da Vinci. We’ll take each one apart in detail through the rest of the course.
Where the plan’s vendors fit
A health plan is rarely one entity. Most plans subcontract parts of this to vendors, or buy a product that handles the APIs, or both. What we see is plans struggling to work out how to hand these APIs to a vendor, and vendors struggling to work out what exactly they’re supposed to build.
Before you continue
This course assumes you know FHIR. If you’re just getting started, take the FHIR fundamentals course first and come back, because we’ll be dealing with the APIs at the level of how to implement them properly. There are also a few videos on CDS Hooks specifically if you want the background before the next lesson, where we go through how CDS Hooks works and how CRD uses it.
