Payer prior authorization APIs will only help the providers ready to call them

The week

By mid-May 2026, the CMS Interoperability and Prior Authorization Final Rule, issued in January 2024, was halfway through its rollout. Since January 1, impacted payers had faced new decision timeframes and a duty to give a specific reason for denials. They include Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federal exchanges. Their first public prior authorization metrics were due by March 31. The larger milestone was still ahead. By January 1, 2027, those payers must offer a Prior Authorization API, a Provider Access API and a Payer-to-Payer API, and enhance the Patient Access API. Meanwhile, comments were open until mid-June on a CMS proposal, released in April, to extend electronic prior authorization requirements to drugs. Payers were building. Providers were deciding how they would connect.

The rule regulates payers, so most commentary follows the payers. Earlier in this series we looked at what the first public metrics told provider operations teams. This article looks at the other end of the pipe. An API a payer exposes creates value only if a provider can call it from inside clinical and revenue-cycle work, with the right data, at the right moment. A payer can meet its obligation in full while a health system gains nothing.

Provider readiness has three parts, and they fail independently. The connection is which system makes the call. The chart is whether the record can answer what the payer asks. The queue is who owns a request from order to decision. A health system can be strong on one and still get little benefit if the other two are weak.

The connection: which system makes the call

The CMS rule points payers to HL7 FHIR and the Da Vinci implementation guides. Those guides describe three steps. A provider system asks whether authorization is required for an order. It retrieves the payer’s documentation rules and gathers answers, partly from the chart. It then submits the request and receives a decision. Few health systems will build those calls themselves. An EHR vendor, a clearinghouse or a revenue-cycle platform will make them.

That puts vendor roadmaps on the critical path. A CIO should know which product will make each call, which release delivers it, what it costs, and how it will be tested against each major payer. ONC’s HTI-4 rule, finalized in July 2025, added three certification criteria for electronic prior authorization. That gives buyers a precise question: which criteria is the product certified to, and from which release. Some health systems will use more than one route, such as the EHR for most orders and a separate platform for imaging. They need a routing rule so that no request travels two ways.

There is also a timing gap to plan for. HHS has said it will not enforce the older X12 278 transaction standard against covered entities that use the FHIR Prior Authorization API instead. That removes one obstacle. Many payers will still run portals, fax and X12 alongside the API for years, so health systems will operate mixed channels well into 2027. Payer-by-payer connection status belongs in the same tracker that revenue cycle uses for contract terms.

Leadership has a reason to fund this. CMS-0057-F added an electronic prior authorization measure to the Medicare Promoting Interoperability program for hospitals and to the MIPS Promoting Interoperability category for clinicians. As finalized in 2024, it is a yes-or-no attestation that starts with the 2027 reporting period.

The chart: what the payer will ask for

The promise of the Da Vinci approach is that documentation rules become machine-readable, and that much of the answer can be pulled from the record. That only works if the record holds the information in structured, consistent form. Many denials are documentation failures. The clinical rationale is in a progress note but not in a field a system can read, such as a prior therapy, a failed conservative treatment or a relevant imaging result. Automating a workflow that depends on free text does not remove the problem. It moves it to another queue.

The practical sequence is to start with the highest-volume and highest-denial services, map what major payers typically require for each, and test whether the chart captures those items in discrete fields today. Advanced imaging, specialty procedures and durable medical equipment are common starting points. Where a field is missing, the fix is often an order question or a documentation template, which is cheaper than any interface.

The Provider Access API raises a separate data question. It lets in-network providers request claims and clinical data a payer holds about attributed patients. That can fill gaps in history, but only if incoming payer data has a destination. Someone must decide where it lands, how it is reconciled with the chart and who reviews it. Clinical informatics, not only integration engineering, should own that design.

The queue: who owns the request

Today prior authorization is largely worked by central teams using payer portals, phone and fax. Electronic requests move the start of the process to order entry, because the system can tell at that point whether authorization is needed. That is good for patients and for cash flow. It also changes who does what. Clinicians see prompts. Central staff handle exceptions instead of every request. Pended and denied requests still need people.

The redesign should be explicit. Decide which prompts reach clinicians and which route to staff. Set rules for pended requests that wait on more documentation. Define who appeals and when. Measure the provider side of turnaround by payer and service, from order to decision, so the organization can see whether the new channel is faster. Staffing models should be revisited too, because the work shifts from data entry toward clinical review and appeals.

Governance needs one owner across the three parts. In many health systems the EHR team, revenue cycle and clinical documentation report to different executives. Each can declare success on its own piece while the end-to-end time from order to decision stays the same. A single program lead with a shared measure, such as the share of requests decided without a phone call or fax, keeps the work joined up. It also gives payer contract negotiations a provider-side number to set against the metrics payers now publish.

With hindsight

From October 2026, the payer-side deadline is less than three months away. As far as we can tell, no change to the January 2027 API date has been announced. Payers can meet the rule on time while providers see little difference, and that remains the risk. The proposal to extend electronic prior authorization to drugs drew comments through June. We had not seen a final rule when we checked. Organizations should confirm its status and dates with CMS guidance. The 2027 attestation measure, as finalized in 2024, gives hospitals and clinicians a modest reason to make at least one request through a payer API. The larger gains depend on structured documentation and redesigned work queues. Neither comes from a vendor release. Health systems that started with their most-denied services in 2026 will have something to switch on in January. Those that waited will have the plumbing first and the benefit later.