Prior authorization APIs will open before providers can call them

Prior authorization APIs will open before providers can call them. On January 1, 2027, impacted payers must run a FHIR Prior Authorization API. They include Medicare Advantage plans and Medicaid programs. Plans on the federal exchanges are covered too. Payers have spent 2026 building. Providers, whose systems have to call those APIs, mostly have not started.

The gap shows in the surveys. In February 2026, only 10% of payers said they had not started their API work, according to WEDI. In the same round, no provider reported any implementation progress on the Prior Authorization API, according to healthsystemCIO. The deadline applies to payers, so payers will mostly meet it. Whether anyone uses the APIs in 2027 depends on the other side.

With 3 months to go, the question is what plans can do now so that the APIs carry real traffic.

Key takeaways

• The date holds. CMS said in May that electronic prior authorization interfaces will go live in January 2027.
• Payers are close. Only 10% of payers had not started API work by February 2026, down from 42% a year earlier.
• Providers are not. No provider in WEDI’s February survey reported implementation progress, and provider confidence in the deadline fell to 47%.
• The standards will shift. An April 2026 proposal would require specific guide versions from October 2027 and would add drugs covered under the medical benefit.
• Use will be measured late. Payers would first report API usage in 2028, covering 2027.
• Plans should measure traffic now. We think plans should publish their own usage data in 2027 and keep other channels working on the same terms.

What the rule requires on January 1

CMS’s 2024 interoperability and prior authorization rule, CMS-0057-F, set the date. Impacted payers must run a Prior Authorization API by January 1, 2027, according to CMS’s fact sheet. The API has to do 4 things for items and services other than drugs.

• Say what needs approval. The API tells a provider’s system whether an item or service requires prior authorization.
• Say what documents are needed. It returns the documentation the payer requires for that item or service.
• Take the request. It accepts a prior authorization request with its supporting information.
• Return the decision. It sends back the decision, including a specific reason when the payer denies a request.

Other parts of the rule are already in force. Medicare Advantage plans and Medicaid programs have had to decide expedited requests within 72 hours since January 2026. Standard requests get 7 calendar days. Payers have also had to give a specific reason for each denial. They posted their first prior authorization metrics in March 2026, as our review of those postings described.

The API is built on HL7’s Da Vinci implementation guides. Our piece on the 2027 payer API deadline described the full standards stack.

HIPAA still names the X12 278 transaction for prior authorization requests. CMS will not enforce that requirement against covered entities that use an all-FHIR Prior Authorization API instead, according to its enforcement discretion notice. An X12 278 alone does not satisfy the rule, because the rule requires the HL7 guides.

CMS has not moved the date. In a May 5 blog post, Administrator Mehmet Oz wrote that the interfaces will go live in January 2027. He said cross-industry working groups would align on the deadlines and close gaps in workflow.

Where payers stand

Payers have moved fastest. WEDI’s survey in February drew 86 responses, and 52% came from payers. Only 10% of payers had not started their API work. That share was 33% in October 2025 and 42% in early 2025.

Starting is not finishing. Only 13% of payers reported being at or near completion in February, according to WEDI. A quarter expected their API costs to exceed $5 million, up from 15% in October. Another 28% expected costs between $1 million and $5 million.

The hardest work is not the interface. In WEDI’s October survey, payers named digitizing their prior authorization policies as a top challenge, according to Becker’s. The API can only return documentation requirements that a payer has written down in a form software can read.

That translation is slow work. A policy that calls for 6 weeks of conservative care before imaging has to become a set of questions an EHR can answer from the chart. The questions have to name the evidence, such as dated therapy visits. They also have to say what counts as a warning sign that skips the wait. Every policy a payer covers through the API needs the same treatment. Our piece on publishing coverage criteria like code argued for that work on its own merits.

Vendors plan to carry much of the load. In WEDI’s February round, 82% said they planned to help their customers comply. Clearinghouses said 60% of them planned to handle the API exchanges for payer customers.

Industry pledges point the same way. Health plans that signed AHIP’s 2025 pledge committed to a common FHIR framework for electronic prior authorization by January 2027. They also committed to answer 80% of electronic approvals in real time by 2027, as our piece on the pledge’s progress described. CMS’s May post said plans had already eliminated 11% of prior authorizations for a range of services, or about 6.5 million fewer requests.

Where providers stand

The rule does not require providers to do anything on January 1. That is the problem. A payer API answers only when a provider’s system asks, and most provider systems cannot yet ask.

WEDI’s February survey found that 33% of providers had not started. Another 67% were unsure of their own progress. Provider confidence in meeting the deadline fell to 47% from 69% in October, according to healthsystemCIO. About two-thirds of providers did not know what implementation would cost.

The barriers are practical. Providers named a lack of internal expertise first. Coordinating tests with vendors and health plans came next. Confusion over overlapping exchange networks ranked third.

What the provider’s system has to do

The provider side of the exchange is more than a single call. When a clinician signs an order, the EHR has to ask the payer whether approval is needed, usually through a CDS Hooks request. If approval is needed, the EHR opens the payer’s documentation questions. It fills in what it can from the chart. The clinician answers the rest. The EHR then sends the request and waits. The decision may come back at once or later through a subscription.

Each of those steps is a separate piece of software in the EHR. ASTP’s HTI-4 rule created certification criteria for them, effective October 2025. As our piece on HTI-4 described, the rule does not require developers to certify to them. A provider can only call a payer’s API once its vendor has built the client and the provider has turned it on.

Turning it on is its own project. A health system has to connect to each payer’s endpoints and test them. It also has to decide which orders trigger a check and train clinicians to answer the questions that the chart cannot. Large systems with dedicated staff can do that in months. A small practice will wait for its vendor.

CMS has said it will bring electronic prior authorization into its Medicare incentive programs for hospitals and clinicians. The May post said that would happen eventually. Until it does, a practice has little financial reason to switch from a portal it already knows.

What providers can do before January

Providers do not need to wait for every payer. A health system can rank its payers by prior authorization volume and start with the 2 or 3 that send the most requests. It can ask its EHR vendor for a release date for each prior authorization client and the guide versions it will support. It can also pick a few high-volume services, such as advanced imaging, for a first round of live tests.

Coverage discovery is the easiest place to begin. Knowing at the moment of ordering whether approval is needed saves calls and rework, even before the rest of the exchange works. WEDI’s respondents who favored a staggered start most often picked that step first.

The other APIs arrive the same day

The Prior Authorization API is not the only deadline. The same rule requires a Provider Access API and a Payer-to-Payer API by January 2027. The provider access interface lets in-network providers pull claims and prior authorization data for patients they treat. Only 33% of providers said they were likely to implement it, down from 44% in October, according to healthsystemCIO.

For a plan, the 3 deadlines compete for the same engineers. For a provider, the provider access data may prove more useful in 2027 than the request workflow, because it needs no change at the moment of ordering.

On January 1, payers will open the door. Most providers will still be finding the handle.

The overall level of electronic prior authorization is still low. In 2024, 40% of medical prior authorizations were conducted electronically, up from 31% in the 2023 index, according to CAQH as reported by AJMC. That figure predates the FHIR APIs, which were not yet required.

The standards are still moving

CMS recommended versions 2.0.0 and 2.0.1 of the Da Vinci guides in 2024. EHR certification under HTI-4 uses version 2.1.0. In April, CMS proposed rules that would set the versions payers must support from October 1, 2027, according to the CMS-0062-P fact sheet.

Some of the newer versions depend on ASTP finalizing its own proposals, according to the fact sheet. A payer and a provider can each follow the rules and still run versions that need work to talk to each other.

The proposal does more than pin versions. It would require payers to bring drugs covered under the medical benefit into the Prior Authorization API from the same date. It would adopt FHIR as the HIPAA standard for prior authorization transactions. Covered entities would have 24 months to comply after the final rule takes effect. Small plans would have 36. The proposal would also have payers report every API endpoint so CMS can publish them in 1 place.

Those changes help in the long run. In the short run, they mean a payer may upgrade its guides within a year of going live. Every upgrade has to be tested against the EHRs that call it, and those EHRs may be on other versions.

The industry has asked for a slower start. More than half of WEDI respondents across all groups supported staggering the Da Vinci components rather than requiring them on the same date. A third of those favored starting with coverage discovery, according to healthsystemCIO.

Testing tools exist but are thin. ASTP released an open-source test kit for Prior Authorization Support in 2024, according to ASTP. It runs on ASTP’s Inferno framework and tests both the provider client and the payer server. A kit can show that each side follows the guide. It cannot show that a given payer’s rules and a given provider’s EHR work together.

What the first months will look like

This section is our reading of the evidence, not a forecast from any survey.

Most impacted payers will have an API that answers on January 1. Some will miss parts of it, especially the documentation step, because their policies are not yet in a form software can read. Few providers will call those APIs in the first quarter. Requests will keep arriving through portals and fax. Payers will keep deciding them on the same clocks. Failed calls will be the early signal. A payer that logs its API errors and fixes them within days will earn traffic that a slower payer will not.

The calls that do arrive will come from a small number of large health systems on current EHR versions. Their experience will shape the market. Early adopters will also find the gaps in each payer’s rules faster than any test kit. If a payer’s API returns clear documentation requirements and fast approvals, those systems will route more volume to it. If it returns errors or vague answers, they will go back to the portal.

Pended requests will test the design. Many requests will not be decided on the spot. The payer’s answer will come later, and the provider’s system has to be listening for it. A request that sits unanswered in a system nobody watches is worse than a fax, because nobody knows to call.

The clocks do not change with the channel. A standard request still gets a decision within 7 calendar days whether it arrives by API or by portal. A payer that answers API requests faster than portal requests will show it, and providers will notice.

The public will not see much of this at first. Under the April proposal, payers would first report usage of the Prior Authorization API in 2028, covering 2027. The only measure of success until then will be what payers and providers choose to share.

Drugs will remain outside the API through most of 2027. Our piece on drug prior authorization described how the 2024 rule left them out. The April proposal would bring in drugs under the medical benefit from October 2027. Drugs under the pharmacy benefit would follow NCPDP standards instead.

Where Redlake stands

Redlake builds tools that health plans use in utilization review. We want the API to carry real requests, because a request that arrives with structured data can be approved faster.

Measure traffic rather than existence. Plans should publish monthly counts of API requests and automated approvals through 2027. They should not wait for the 2028 report. A count of calls tells providers which payers are worth connecting to.

Write the documentation rules first. The documentation step is where most of the value sits and where payers are furthest behind. A plan that publishes its requirements as structured rules helps every channel, including its portal.

Keep every channel on the same terms. A provider who cannot call the API in 2027 should get the same decision, on the same clock, through a portal. The API should be faster. It should not be the only way to be treated fairly.

Let software approve and people deny. A machine can say yes, but only a person can say no. A request that arrives through the API with complete documentation should be approved automatically when it meets the criteria. A request that does not should go to a clinician, with the missing items named.

Return reasons as data. The rule already requires a specific reason for each denial. That reason should name the criterion and the missing evidence in a form the EHR can show the clinician. Our piece on denial letters described what a useful reason looks like.

Test with real partners. Plans should run joint tests with the EHR vendors their largest providers use, on the versions those vendors will ship. Passing a test kit is necessary but not enough.

Publish endpoints now. The April proposal would have payers report every API endpoint to CMS. Plans do not need to wait. A public list of endpoints, with the guide versions each supports, saves every provider the work of finding them.

What to watch in the rest of 2026

• January 1. Watch which payers announce production APIs and which announce delays for parts of the workflow.
• The April proposal. Watch for a final rule on guide versions and drug coverage in the API.
• HTI-5. Watch for the final rule and any changes to the certification program that affect prior authorization criteria.
• Incentive programs. Watch the Medicare physician payment rule for when electronic prior authorization enters the incentive programs.
• Vendor releases. Watch which EHR vendors ship certified prior authorization clients before January.
• Real-time approvals. Watch whether plans that signed the AHIP pledge report their real-time approval rates for 2027.

About this analysis

Method. What CMS-0057-F requires for January 2027 is compared with survey evidence on payer and provider readiness, and with the standards CMS proposed in April 2026. The section on the first months is our reading of that evidence.

Data notes. WEDI’s February 2026 figures come from 86 responses, about half from payers. Provider findings from the same round are as reported by healthsystemCIO. CAQH’s figure covers 2024 activity. Survey samples are small and self-selected. WEDI does not report payer results by line of business. Medicaid plans cannot be compared with Medicare Advantage plans from its figures.

Sources. CMS-0057-F fact sheet (January 17, 2024). CMS enforcement discretion notice on HIPAA transactions (2024). CMS blog by Administrator Oz (May 5, 2026). WEDI survey release (March 10, 2026). healthsystemCIO (March 12, 2026). Becker’s Payer Issues (December 22, 2025). CAQH Index as reported by AJMC (May 1, 2026). CMS-0062-P fact sheet (April 10, 2026). ASTP on the Prior Authorization Support test kit (April 17, 2024).

Frequently asked questions

When is the prior authorization API deadline?

Impacted payers must run the Prior Authorization API by January 1, 2027. Impacted payers include Medicare Advantage plans and plans on the federal exchanges. Medicaid and CHIP programs and their managed care plans are covered too.

Do providers have to use the prior authorization API?

The 2024 rule does not require providers to use the API. CMS has said it will eventually bring electronic prior authorization into its Medicare incentive programs for hospitals and clinicians.

Does FHIR replace the older prior authorization transaction?

Not yet. CMS will not enforce the X12 278 requirement against entities that use an all-FHIR API. The April 2026 proposal would make FHIR the HIPAA standard for prior authorization, with 24 months to comply after a final rule.

Are drugs included in the prior authorization API?

Not under the 2024 rule. The April 2026 proposal would add drugs covered under the medical benefit from October 1, 2027.

What does the documentation step do?

It tells the provider’s system which documents the payer needs and fills in what it can from the chart. The clinician answers the rest before the request is sent.

What is coverage requirements discovery?

It is the first step of the exchange. The EHR asks the payer whether an ordered item needs approval as soon as the clinician places the order. The answer comes back while the clinician is still in the chart.

How ready are payers for the deadline?

Only 10% of payers had not started their API work in February 2026, according to WEDI. Only 13% said they were at or near completion.