Prior Authorization API: The Integration You Need
Table of Contents
- Quick answer: prior authorization API provider readiness
- What Changes on January 1, 2027, and What Already Changed in 2026
- What Manual Prior Authorization Already Costs Your Practice
- Why a Payer Mandate Quietly Becomes a Provider Integration Project
- The Actual Mechanics: CRD, DTR, and PAS
- Where This Hooks Into the EHR You Already Have
- Conformance Requirements Worth Knowing Before You Scope the Work
- Three Realistic Paths for a Mid-Market Practice
- What Implementation Looks Like, and Who Maintains It in 2029
- FAQ
January 1, 2027 is the date your practice needs a working prior authorization API, and your EHR vendor probably hasn’t told you where their build actually stands. CMS-0057-F requires the payers you bill to expose that API. It puts no requirement on your practice to connect to it. Mid-market operations teams are about to lose months inside that gap.
A prior authorization API is the FHIR-based connection between your EHR and a payer’s system that checks authorization requirements, pulls the right documentation from the chart, and submits a request without a phone call, a fax, or a separate portal login. Three CMS-named transactions do the work: Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support. None of them require replacing your EHR. Someone does have to build the connection.
Waiting on your EHR vendor is a legitimate option. So is buying a point solution. Either way, the mechanics below are what the decision rests on.
Quick answer: prior authorization API provider readiness
- CMS-0057-F requires payers to launch a Prior Authorization API by January 1, 2027. It requires nothing from providers.
- Three FHIR transactions do the work: CRD checks if authorization is needed, DTR pulls chart data, PAS submits and tracks the decision.
- The integration runs through SMART on FHIR inside your current EHR. No new platform required.
- Manual prior authorization already costs 39 requests and 13 hours per physician weekly, per the AMA, deadline or not.
- Your practice has three paths: wait on your EHR vendor, buy an immature point solution, or build and own the integration.
The three FHIR transactions that move a prior authorization request from chart to payer decision.
What Changes on January 1, 2027, and What Already Changed in 2026
Four APIs come online under CMS-0057-F. Only one, the Prior Authorization API, carries the January 1, 2027 deadline. The decision-timeline rule underneath it has already been running for nine months.
The four APIs CMS-0057-F puts in production
CMS-0057-F names four: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. The first three are mostly payer-to-payer and payer-to-patient data plumbing. The Prior Authorization API is the one that touches your front desk, your schedulers, and your referral coordinators directly. The other three will never show up in a scheduler’s day.
The seven-day and 72-hour decision clocks that are already running
According to the Centers for Medicare & Medicaid Services, CMS-0057-F requires impacted payers to implement the Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API by January 1, 2027, and to send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests. The decision-timeline piece took effect a full year ahead of the API deadline, so payers are already on the clock for turnaround. Your side of that exchange still runs at fax speed.
Who the rule actually regulates, and why that matters to you
CMS-0057-F regulates impacted payers: Medicare Advantage plans, state Medicaid and CHIP managed care programs, and qualified health plan issuers on the federal exchanges, excluding those on the FFEs for this specific requirement. It doesn’t regulate you. AMA data puts the exposure at 99 percent of Medicare Advantage enrollees in plans that apply prior authorization to at least some services, so this isn’t a narrow payer-mix issue you can wait out. Nearly every practice bills one of those plans, even though the rule never names providers as a party.
What Manual Prior Authorization Already Costs Your Practice
A physician’s practice completes an average of 39 prior authorization requests a week, according to the American Medical Association’s 2025 analysis. Physicians and their staff spend 13 hours finishing them. Put the 2027 deadline aside for a moment, because that arithmetic is already reason enough to act.
Thirty-nine requests and thirteen hours per physician, per week
Those figures come from physicians reporting their own week, not from a vendor’s marketing page. Thirteen hours runs longer than a full workday, every week, on paperwork that sits between a clinical decision and a payer’s approval of it. Scale it to a ten-physician practice and you’re looking at roughly 130 hours a week of physician and staff time before anyone touches a patient.
When prior authorization becomes a headcount line item
Only 11.7 percent of denials get appealed, yet 81.7 percent of those appeals succeed, according to AMA-reported data drawn from CMS and KFF figures on Medicare Advantage denials. Most of the denials worth fighting are wrong, and almost no practice has the staff capacity to fight them. Revenue walks out the door every week, because nobody has the hours to chase it.
Delays, abandonment, and the part that shows up in outcomes
Prior authorization delays care, and physicians know it firsthand. It shows up as a canceled procedure, a patient who stops pursuing treatment after a second denial, or a specialist referral that dies in someone’s inbox. None of it waits on a 2027 deadline. It’s happening in your practice this week.
The administrative layer a prior authorization API is designed to replace.
Why a Payer Mandate Quietly Becomes a Provider Integration Project
Nobody has to build anything on the provider side for CMS-0057-F to take effect. Payers must stand up the API. Your practice either connects to it or keeps working the way it does today, and nothing in the rule forces that choice either way.
The asymmetry here is structural. A federal rule written to change payer behavior lands as a provider IT project, because an API nobody on your side consumes delivers zero operational benefit. The rule changes what payers must expose. What your scheduler sees on screen next Tuesday doesn’t change until somebody connects the two.
Your budget owner will read “compliance deadline” and route it to whoever handles compliance. The work underneath it is an integration project, and those two things get funded very differently.
The Actual Mechanics: CRD, DTR, and PAS
Three FHIR transactions handle the whole workflow. The acronyms get listed almost everywhere and explained almost nowhere, so take them one at a time, from the scheduler’s point of view.
CRD: does this order need authorization at all
Coverage Requirements Discovery runs the moment an order gets placed, whether that’s an imaging study, a procedure, or a specialty referral. It checks the patient’s specific payer and plan in real time and answers one question: does this order need prior authorization, and if so, under which payer rule. Today, that question gets answered by someone guessing, calling, or finding out after the claim denies.
DTR: pulling what the payer’s rules require out of the chart
Documentation Templates and Rules takes the payer’s specific documentation requirements and pulls the matching data directly out of the chart, structured the way the payer’s rules engine expects it. According to the AMA’s December 2025 physician survey, 40 percent of physicians now employ staff who work exclusively on prior authorization, and a large share of that work is precisely this: manually assembling the documentation DTR is built to automate.
PAS: submitting the request and tracking the decision
Prior Authorization Support packages the CRD answer and the DTR documentation into a submission, sends it to the payer, and tracks the decision status back into the chart. Your staff stops checking a separate portal for status updates. The answer shows up where the order lives.
How CRD, DTR, and PAS sit inside the ordering workflow your staff already uses.
Where This Hooks Into the EHR You Already Have
This is an integration, not a platform migration. SMART on FHIR is the app framework that lets a prior authorization tool run inside your existing EHR’s interface, using the data already in your system.
SMART on FHIR as the integration surface
SMART on FHIR, a standard maintained through HL7 and ONC’s health IT certification program, lets a certified app launch from inside an EHR session and read or write FHIR resources the EHR already exposes. CRD, DTR, and PAS are typically delivered as SMART on FHIR apps or embedded services that call out to payer endpoints, not as a separate system your staff has to log into.
What you do not have to replace
Your scheduling module stays. The chart stays. Ordering workflows stay largely intact, with CRD and DTR surfacing inside them rather than replacing them. A prior authorization API project adds a connector and a decision-support layer on top of what you already run. That’s a different scope of work than a core EHR replacement, and a much smaller budget conversation.
Conformance Requirements Worth Knowing Before You Scope the Work
CMS defines the Prior Authorization API as a FHIR API conformant with the technical requirements in 45 CFR 170.215, built on FHIR R4 and the implementation guides HL7’s Da Vinci project maintains for CRD, DTR, and PAS. Whoever scopes your build needs these three things.
FHIR R4 and the standards named in 45 CFR 170.215
The certification criteria reference specific HL7 FHIR implementation guides for each transaction. Treat these as the spec your developers build against, not a general FHIR familiarity requirement. A team that has built FHIR integrations before still needs to read the specific CRD, DTR, and PAS guides before estimating hours.
Payer endpoints, directories, and credentialing
Each payer publishes its own API endpoints and its own credentialing process for connecting to them. A mid-market practice billing a dozen payers is looking at a dozen separate connection and testing processes, not one universal hookup. Budget for that early. It’s where timelines usually slip.
How PHI moves, and what that obligates you to log
Every CRD, DTR, and PAS transaction moves protected health information between your EHR and a payer’s system. That obligates your practice to log what moved, when, and to which endpoint, the same audit discipline HIPAA already requires of any system touching PHI. Build the logging into the integration from day one rather than retrofitting it after an audit asks for records you don’t have.
Three Realistic Paths for a Mid-Market Practice
You have three choices here, and only one of them is a software purchase. Each one carries a cost, a timeline, and a way it can go wrong, including the choice where nobody builds anything new.
Wait for your EHR vendor’s roadmap
Some vendors will ship CRD, DTR, and PAS support as part of a certified update, and for a practice on a modern, actively maintained EHR, this can be the lowest-effort path. The risk is sequencing: vendor roadmaps slip, certification timelines compress against January 2027, and “wait” turns into “miss the date” if your vendor’s release lands late. As Skylar Roebuck, CTO at Solvd, says: “AI capability is compounding rapidly, and the real risk for mid-market companies is delay.” The same logic applies here. Waiting still hands the timing of your compliance to somebody else’s release calendar.
Buy a point solution
The market for CMS-0057-F point solutions is younger than it looks. Optum’s own Prior Authorization Submission API, the largest clearinghouse-adjacent product in this space, is still in beta and runs on JSON and EDI-X12 formats with EDI and portal connections, rather than as a CMS-0057-F FHIR CRD/DTR/PAS implementation. Buying your way out of this today means evaluating immature products against a spec that’s still settling. As Ashwin Ballal, CIO at Freshworks, puts it, organizations that add vendors to solve a legacy integration problem are “more often than not… trading one subpar legacy system for another.”
Build the integration and own the workflow
Building means your team, or a partner, writes the connectors against each payer’s endpoints, implements the Da Vinci CRD, DTR, and PAS guides inside your existing EHR, and owns the testing and credentialing process payer by payer. It costs more upfront than waiting and takes longer than flipping on a vendor module. It’s also the only path that leaves your practice owning the workflow and the documentation behind it, instead of renting access to someone else’s roadmap or someone else’s beta.
Three paths to the same January 2027 deadline, each with a different cost and risk profile.
What Implementation Looks Like, and Who Maintains It in 2029
The build is the straightforward part. The question that bites later is who still understands this integration three years on, once the people who wrote it have moved to other jobs, and whether your practice can answer that honestly today.
Integration complexity, workflow disruption, and data consistency
A prior authorization integration touches ordering workflows your clinical staff use dozens of times a day, so testing has to happen without disrupting live operations. Expect iterative rollout by payer and by order type rather than a single cutover, with each payer connection validated against real orders before staff depend on it.
Sequencing a build against the January 2027 date
Work backward from January 1, 2027, and build in time for payer-side credentialing, which is frequently the longest pole in the schedule, not the development work itself. Starting credentialing conversations with your top five payers by volume now buys months you won’t get back if you wait until late 2026.
Documentation transfer and who owns this in three years
Every provider CTO eventually asks this one, and most vendor engagements handle it badly: who maintains this in 2029, when the person who built it is gone. Complete documentation transfer answers it: architecture records, API references, and test coverage reports handed to the client whether or not the engagement continues. Nexa Devs has run integrations inside clinical systems at UCLA’s David Geffen School of Medicine for more than ten years and built similar prior authorization and EHR integration work for Canadian Health Systems, in environments where downtime and data handling tolerances aren’t negotiable. Hold any healthcare integration to that bar, documentation included.
FAQ
What is API for CMS?
CMS’s prior authorization API is a FHIR-based interface payers must build under CMS-0057-F by January 1, 2027. It lets a provider’s EHR check authorization requirements, submit documentation, and track a payer’s decision electronically instead of through phone calls, faxes, or separate portals.
Is there an API for Availity prior authorizations?
Availity offers its own proprietary portal and connection options for prior authorization and eligibility checks with many payers today. That’s separate from the CMS-0057-F Prior Authorization API, which requires impacted payers to expose a standardized FHIR interface rather than a single vendor’s portal.
What does API mean in healthcare?
An API, or application programming interface, is a defined way for one software system to request data or trigger an action in another. In healthcare, APIs let an EHR exchange information with a payer, a lab, or another provider’s system without manual data entry on either end.
What is CRD, DTR, and PAS in prior authorization?
CRD, DTR, and PAS are the three FHIR transactions behind CMS-0057-F’s Prior Authorization API. CRD checks whether an order needs authorization, DTR pulls the chart data a payer’s rules require, and PAS submits the request and tracks the payer’s decision.
When do providers have to connect to the prior authorization API?
There’s no binding deadline for providers. CMS-0057-F only requires payers to expose the API by January 1, 2027. Providers choose whether, and when, to connect, which makes this a decision your practice has to make rather than a date to wait out.
Can we just wait for our EHR vendor to build this?
You can, and for some practices it’s a reasonable choice. The risk is timing: vendor certification updates can slip past January 2027, and a late release leaves you working the old manual process right through the deadline with no fallback already in place.
A date on a calendar doesn’t fix a 13-hour-a-week problem your staff is already living with. closing an EMR integration gap without replacing the EMR covers the other half of CMS-0057-F if you haven’t scoped that side yet. Scope this one now, with payer credentialing timelines in front of you, whichever of the three paths above your practice ends up taking.
Nexa Devs builds prior authorization integrations inside the EHR your practice already runs, using AI-augmented delivery across the build, complete documentation transfer at project close, and SLA-based support that doesn’t end at launch. If CRD, DTR, and PAS need to be live before January 2027, schedule a call and we’ll scope what that actually takes for your payer mix.