Healthcare Has A Sync Problem
Healthcare interoperability keeps failing for the same two reasons: inconsistent data models and bad sync. Here's what solving both would actually take.
Prior authorization is changing under new federal rules from CMS and ONC, and 2027 is the year most of that change becomes mandatory. Starting January 1, 2027, most health plans that touch Medicare Advantage, Medicaid, CHIP, or the federal insurance exchanges will be required to support electronic prior authorization through FHIR APIs, and clinicians will need to attest that they’ve used one at least once as part of their MIPS reporting.
Insurers have tried this before on their own terms. In June 2025, roughly 60 health insurers pledged to reform prior authorization on their own, promising faster turnaround and less friction for physicians. The American Medical Association’s 2025 Prior Authorization Physician Survey, published a year later, found that only a third of physicians believe that pledge will actually change anything. The federal rules arriving in 2027, CMS-0057-F and HTI-4, are a separate and much harder deadline that doesn’t depend on insurers keeping their word.
TL;DR
- CMS-0057-F requires most Medicare Advantage, Medicaid, CHIP, and federal exchange plans to run FHIR-based prior authorization APIs by January 1, 2027, after an operational phase that started January 1, 2026.
- Two hard turnaround windows kick in: 72 hours for expedited requests, 7 calendar days for standard ones, replacing a process that has never had a standard timeline.
- HTI-4, ONC’s companion rule, certifies the FHIR implementation guides behind this: CRD, DTR, and PAS. The certification is voluntary, but a MIPS attestation requirement starting the 2027 performance period makes it unavoidable for any EHR vendor whose customers need to report.
- CRD gives providers a coverage answer inside the EHR in 5 to 10 seconds. DTR embeds the paperwork as a form in the EHR instead of a separate payer portal. PAS sends the completed request to the payer as a structured FHIR packet.
- A 2018 industry pledge and a June 2025 follow-up both promised reform with no deadline attached. Eight years after the first one, 84% of physicians say prior auth requirements for medications have gone up, and only a third believe the 2025 pledge will change anything.
- Prior authorization currently costs the average physician 40 requests and 13 hours of staff time a week. 94% say it contributes to burnout, 95% say it delays care, and 26% report it has led to a serious adverse event for a patient in their care.
- Providers spend less time chasing coverage answers and re-entering paperwork. Payers face public reporting on approval and denial rates for the first time. Patients get visibility into a process that’s historically been invisible to them.
What is prior authorization?
Prior authorization is a step some health plans require before they’ll pay for a prescription medication or medical service. Before a provider can deliver certain treatments, they have to submit a request to the patient’s health plan and get approval first. If the plan doesn’t approve it, the patient either doesn’t get that treatment, pays for it out of pocket, or the provider has to appeal the decision.
Health plans use prior authorization mainly to control costs and confirm that a treatment is medically necessary before agreeing to pay for it. In practice, this means an extra step, and often an extra wait, standing between a provider’s recommendation and the care a patient actually receives.
What prior authorization looks like today
Prior authorization is the process where a health plan has to sign off on a prescription or medical service before it gets covered. In practice, a provider’s office has done this the same way for decades. Often from memory or a lookup table, it works out which procedures need prior auth for which plan, then calls or faxes the request in and waits.
Right now there’s no standard turnaround time built into the process itself, and the prior authorization statistics are proof. According to the AMA’s 2025 Prior Authorization Physician Survey, a survey of 1,000 practicing physicians fielded in December 2025, physicians and their staff spend an average of 13 hours a week on prior authorization, completing about 40 requests per physician in that time. 95% of physicians say the process delays access to necessary care, and 32% say requests are often or always denied outright.
The same survey found that 92% of physicians believe prior authorization has a negative impact on patient clinical outcomes, and 26% report that it has led to a serious adverse event for a patient in their care, including hospitalization or, in some cases, permanent harm. 88% say the process leads to higher overall use of health care resources than necessary, since a delayed or denied request often means a patient tries an ineffective first-line treatment, schedules an extra office visit, or ends up in an ER instead.
Why voluntary prior authorization reform hasn’t worked
Insurers have promised to fix prior authorization before. In January 2018, the AMA, AHIP, and several other national health care organizations signed the Consensus Statement on Improving the Prior Authorization Process. They committed to things like reducing prior auth requirements for providers with strong track records, improving transparency about which services need approval, and building out electronic automation. Almost eight years later, physicians report little progress. 84% say the number of prior auths required for prescription medications has increased over that period, not decreased, and 63% say it’s still difficult to determine whether a given medication requires prior auth at all.
A second pledge followed in June 2025, when more than 60 health insurers committed to a new round of voluntary reforms, this time with staggered deadlines: medical review of non-approved requests starting immediately, reduced scope and better continuity-of-care protections by January 2026, and standardized electronic prior authorization with real-time responses by January 2027. The dates track closely with the regulatory timeline in CMS-0057-F, which likely isn’t a coincidence.
Physicians aren’t convinced this round will go differently. The AMA’s 2025 survey found that only 33% believe the pledge is likely to make a meaningful difference for patients and physicians. Patients share that skepticism: a July 2025 KFF poll found only 39% of consumers believe insurers will follow through in a way that actually helps them.
Part of the skepticism is that the one 2025 pledge commitment already in effect at the time of the survey, ensuring that medical necessity denials get reviewed by a licensed, qualified clinician, doesn’t appear to be happening consistently. Only 24% of physicians agree that denials are being reviewed by an appropriately qualified clinician, and among physicians who participate in peer-to-peer reviews, only 16% say the health plan’s reviewer often or always has the right qualifications.
This is the context CMS-0057-F and HTI-4 arrive in. Earlier attempts to fix prior authorization depended on insurers keeping their word. This time, they’re mandated.
What CMS-0057-F actually requires
CMS-0057-F, formally the CMS Interoperability and Prior Authorization final rule, was published on January 17, 2024. It applies to what CMS calls “impacted payers”: 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. If a health plan operates under any of those programs, it’s in scope.
The rule rolls out in two phases, a year apart.
| Phase | Compliance date | What’s required |
|---|---|---|
| Operational | January 1, 2026 | 72-hour decision turnaround for expedited requests, 7 calendar days for standard requests (excluding QHP issuers on the exchanges); a specific denial reason for every rejected request, regardless of how it was submitted; annual public reporting of approval, denial, and appeal metrics, with the first set due by March 31, 2026 for calendar year 2025 data |
| API | January 1, 2027 | A Prior Authorization API that lists covered items and services, identifies documentation requirements, and supports electronic request and response; updates to the Patient Access, Provider Access, and Payer-to-Payer APIs to include prior authorization data |
The 72-hour and 7-day windows are a genuine change from a process that currently has no standard turnaround at all. Providers can still expect delays, but the rule puts an outer bound on them for the first time.
On the technical side, the required standards are FHIR Release 4.0.1, the US Core Implementation Guide (STU 3.1.1), the SMART Application Launch Framework (Release 1.0.0), and FHIR Bulk Data Access (STU 1). CMS also names several Implementation Guides it strongly recommends without mandating, including the Da Vinci CRD, DTR, and PAS guides at version 2.0.1 (2.0.0 for DTR), which is where the course this article supports picks up.
HHS is also granting enforcement discretion on the older X12 278 prior authorization transaction standard, the format HIPAA has required since the 1990s. Covered entities that implement an all-FHIR prior authorization API won’t be enforced against for skipping X12 278. It doesn’t mandate dropping X12, but it lets a health plan build a FHIR-only implementation without a HIPAA compliance risk on the side.
The rule also adds a new MIPS measure, Electronic Prior Authorization, that clinicians and eligible hospitals report starting with the calendar year 2027 performance period. It’s an attestation measure. A clinician just needs to confirm they requested at least one prior authorization electronically, through a Prior Authorization API, using certified EHR technology, for at least one medical item or service during that period.
How HTI-4 fits alongside it
CMS-0057-F governs what health plans have to build. HTI-4, or the Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit, and Electronic Prior Authorization final rule, governs the certification side that sits underneath it. It was published by ONC on July 31, 2025, as part of the FY2026 IPPS/LTCH PPS rule.
HTI-4 adds new certification criteria, §170.315(g)(31) through (g)(33), covering the CRD, DTR, and PAS Implementation Guides at version 2.0.1 for CRD and PAS and 2.0.0 for DTR. This is the certification path health IT developers, not health plans directly, go through with ONC-authorized testing labs to have their products certified as supporting electronic prior authorization.
This certification is voluntary. There’s no fixed date by which a health IT developer must get certified under (g)(31-33), because the ONC Certification Program itself is opt-in. What makes it matter anyway is that CMS’s MIPS Electronic Prior Authorization measure, covered in the previous section, requires clinicians to attest using certified EHR technology. A clinician can’t make that attestation without their EHR vendor having gone through certification. So the certification stays technically voluntary, but the 2027 MIPS deadline makes it practically unavoidable for any EHR vendor whose customers need to report that measure.
HTI-4 also folds these new criteria into ONC’s Real World Testing requirement. Any Health IT Module certified to (g)(31-33) before August 31, 2026 has to conduct real-world testing on those criteria for calendar year 2027, with results submitted by March 2028. That’s a second layer of accountability beyond the initial certification, meant to confirm the APIs actually work in production, not just in a test environment.
Put together, CMS-0057-F and HTI-4 are two halves of the same requirement. CMS-0057-F obligates the health plan to expose a working Prior Authorization API. HTI-4 obligates the EHR vendor to build certified software capable of calling it. Neither side moving alone would get providers to the 5-to-10-second CRD response described in the next section, both had to happen.
How CRD, DTR, and PAS change the actual workflow
The old process runs through a provider calling or faxing a request and waiting, sometimes for weeks, sometimes with no more visibility into the process than a status check by phone. The Da Vinci APIs replace that with three connected steps, each addressing a different point where the old process broke down.
Coverage Requirements Discovery, or CRD, is the first and fastest of the three. It runs on CDS Hooks, a specification that lets an EHR call out to an external service the moment a clinician does something: places an order, starts an appointment, discharges a patient, and gets a response back inside that same workflow. When a provider places an order, the EHR fires a hook to the health plan’s CRD service, which checks the patient’s coverage and sends back an answer in roughly 5 to 10 seconds. That answer can be as simple as “covered, no additional requirements,” or it can flag that prior authorization is needed and point to what’s required next. No more checking a CPT code against a mental list of which plans require prior auth for which service. The answer comes back in the same workflow the clinician is already in, before they’ve finished placing the order.
Documentation Templates and Rules, or DTR, picks up from there when prior authorization is actually required. Instead of the provider opening a separate payer portal to fill out a form, one portal per health plan, per patient, DTR embeds that form directly inside the EHR. The form can pull in data the EHR already has, so the practitioner is only answering questions the health plan needs a human to answer rather than re-entering information the system already holds. This step directly addresses the paperwork burden, since it removes the separate login and separate form per payer that has historically made prior authorization such a heavy administrative lift.
Prior Authorization Support, or PAS, is the final step. Once the DTR form is filled out, the EHR packages it into a structured prior authorization request and sends it to the health plan through PAS. The health plan can respond with an approval, a denial with a specific reason, or a request for more information, and CMS-0057-F’s 72-hour and 7-day turnaround windows apply here. PAS also supports FHIR Subscriptions, so instead of the EHR having to repeatedly check back on a request’s status, the health plan can notify it the moment a decision is made.
Together, these three specifications turn prior authorization from a process with no defined turnaround, run through phone calls and faxes, into one with a real-time coverage check, an embedded form, and a bounded response window, all without the provider leaving their EHR. Medblocks’ free Da Vinci CRD course walks through building a CRD server that passes the Inferno test kit, hook by hook.
What this means for providers, payers, and patients
For providers, the immediate change is less time spent on prior authorization itself. The AMA’s 2025 survey found physicians and their staff currently spend 13 hours a week on prior auth, with phone listed as the most common method for completing requests for medical services. A CRD-based coverage check that returns an answer in 5 to 10 seconds, followed by a DTR form pre-filled with data the EHR already holds, is a genuinely different process from that. It doesn’t eliminate prior authorization, and it doesn’t guarantee approvals. Nothing in CMS-0057-F changes the clinical criteria a health plan applies. What it changes is the mechanics of finding out and responding.
For health plans, the requirement is a build-out with a hard deadline and real operational consequences attached. Beyond the API work itself, plans now have to hit the 72-hour and 7-day decision windows, give a specific reason for every denial regardless of how the request came in, and publicly report their approval, denial, and appeal rates starting with the March 2026 filing. For the first time, a health plan’s prior authorization performance becomes a number the public and competitors can see. A plan that denies at a noticeably higher rate than peers, or takes longer than the allowed window, no longer has that go unnoticed. For health plans and the vendors implementing this on their behalf, the technical requirements are covered in depth in Medblocks’ Da Vinci CRD course, [link to course].
For patients, the practical effect is mostly indirect, since patients don’t interact with CRD, DTR, or PAS directly. But CMS-0057-F does extend the Patient Access API to include prior authorization information, so patients get visibility into a process that’s historically been opaque to them. Given that 92% of physicians report negative clinical outcomes tied to prior authorization delays and 26% report a serious adverse event, faster and more transparent turnaround has a direct bearing on patient care, not just administrative convenience.
None of this depends on insurers volunteering to do better, which is the structural difference from the 2018 Consensus Statement and the 2025 pledge covered earlier. CMS-0057-F and HTI-4 carry compliance dates, reporting requirements, and in HTI-4’s case, a Real World Testing obligation that checks whether the APIs work in production. That’s what makes 2027 a different kind of deadline than the ones before it.
Key takeaways
Condensed for quick reference.
The 2027 deadline is regulatory. Two prior industry commitments, the 2018 Consensus Statement and the June 2025 insurer pledge, made similar promises without producing measurable change. CMS-0057-F and HTI-4 carry compliance dates, public reporting requirements, and a Real World Testing obligation that checks whether the APIs actually work in production.
The rollout happens in two phases. Operational requirements, including the 72-hour/7-day decision turnaround and denial reason requirements, took effect January 1, 2026. The API requirements, including the Prior Authorization API itself, are due January 1, 2027.
CMS-0057-F and HTI-4 cover different sides of the same requirement. CMS-0057-F obligates health plans to build and expose the APIs. HTI-4 obligates EHR vendors to get certified software capable of calling them. The certification is optional on paper, but the MIPS attestation requirement leaves EHR vendors little choice.
CRD, DTR, and PAS replace three separate points of friction. CRD replaces the guesswork of checking whether a service needs prior auth. DTR replaces the separate payer portal and form. PAS replaces the fax or portal submission of the final request, with a bounded response window behind it.
The burden this is meant to address is well documented. Physicians currently spend 13 hours a week on prior authorization, completing about 40 requests per physician. 95% report it delays care, 94% say it contributes to burnout, and 26% report it has led to a serious adverse event for a patient in their care.
It doesn’t change approval or denial rates. The new rules change speed, transparency, and process. The clinical criteria a health plan applies remains the same. Physicians report that requests are denied often or always regardless of submission method.
X12 278 doesn’t need to be supported. Health plans that implement an all-FHIR prior authorization API get enforcement discretion on the older X12 278 standard, though they can still support both.
Build a CRD server
Reading about the requirements will only take you so far. The fastest way to know whether your implementation actually works is to build one and test it against the Inferno kit.
Da Vinci CRD course
Get a CRD server passing Inferno, hook by hook. Medblocks’ Da Vinci CRD course is a structured walkthrough of building a CRD server against CMS-0057-F and HTI-4, covering authentication, discovery, every required hook, and every response type, tested live against the ONC Inferno test kit.
Frequently asked questions
What is prior authorization?
Prior authorization is a health plan cost-control process that requires a health care provider to get advance approval from the plan before a prescription medication or medical service qualifies for payment. Providers have historically requested this by phone, fax, or a payer-specific portal, and turnaround has had no standard limit, often taking days to weeks.
What is CMS-0057-F?
CMS-0057-F is the CMS Interoperability and Prior Authorization final rule, published January 17, 2024. It requires Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federal exchanges to implement FHIR-based prior authorization APIs, meet a 72-hour/7-day decision turnaround, and publicly report prior authorization metrics.
Why does prior authorization change in 2027?
January 1, 2027 is the compliance deadline for the API requirements in CMS-0057-F, and the first performance period for the new MIPS Electronic Prior Authorization measure. It follows an earlier operational phase that began January 1, 2026, covering decision turnaround times and denial reason requirements.
What is HTI-4, and how is it different from CMS-0057-F?
HTI-4 is ONC's companion rule, published July 31, 2025, that adds certification criteria for the FHIR Implementation Guides behind electronic prior authorization: CRD, DTR, and PAS. CMS-0057-F obligates health plans to build the APIs; HTI-4 obligates EHR vendors to get certified software that can call them. The certification has no fixed deadline of its own, but CMS-0057-F's MIPS measure requires clinicians to attest using certified EHR technology, so EHR vendors end up needing it anyway.
What are CRD, DTR, and PAS?
They're the three Da Vinci Implementation Guides that make up the electronic prior authorization workflow. Coverage Requirements Discovery (CRD) gives a real-time coverage answer inside the EHR in about 5 to 10 seconds. Documentation Templates and Rules (DTR) embeds the required paperwork as a form inside the EHR instead of a separate payer portal. Prior Authorization Support (PAS) sends the completed request to the health plan and carries the response back.
Do all health plans have to comply with CMS-0057-F?
No. It applies specifically to 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. Fully private commercial plans outside those programs aren't directly covered by the rule, though several major commercial insurers made their own voluntary commitments in the June 2025 pledge.
What happens to the X12 278 standard?
HHS is granting enforcement discretion on X12 278, the prior authorization transaction standard HIPAA has required since the 1990s. Covered entities that implement an all-FHIR prior authorization API won't be enforced against for not using X12 278, though they can still choose to support it alongside FHIR.
How long can a health plan take to decide on a prior authorization request under the new rule?
72 hours for expedited, urgent requests, and 7 calendar days for standard requests, excluding QHP issuers on the federal exchanges. This is a new requirement; there was previously no standardized turnaround time.
Will these changes actually reduce prior authorization denials?
No. CMS-0057-F changes the process, turnaround time, transparency, and how requests are submitted and tracked, but it doesn't change the clinical criteria a health plan applies to approve or deny a request. 32% of physicians currently report that requests are often or always denied, and nothing in the rule requires that rate to change.
Related articles
View all
Epic EHR: A Complete Guide to Architecture, FHIR APIs, and Integration
How Epic EHR works under the hood: the MUMPS database, free FHIR APIs, integration paths, implementation costs, and why production access depends on a hospital.
Medblocks × HiGHmed: Adapting Synthea for Germany’s MII FHIR Profiles
Synthea generates brilliant synthetic patient data, but only in US Core. HiGHmed needed it in Germany's MII profiles. Here is how we rebuilt it. Fully open source.
