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

The week

By mid-May 2026, a federal effort to take the fax machine out of prior authorization was halfway through its rollout. The CMS Interoperability and Prior Authorization Final Rule, issued in January 2024 by the Centers for Medicare & Medicaid Services, sets duties for what it calls impacted payers. They include Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federal exchanges.

Ask any physician’s office manager about prior authorization and you will likely get a sigh. Before an insurer pays for many scans, procedures, drugs or pieces of equipment, it wants the provider to ask permission first and justify the request. For decades that has meant payer websites, phone calls on hold and, remarkably, the fax machine. Patients wait while paperwork travels.

Since January 1, 2026, those payers had faced new timeframes for making decisions and a duty to give a specific reason when they deny a request, rather than a vague refusal. Their first public prior authorization metrics, figures showing how they handle requests, were due by March 31.

The larger milestone was still ahead. By January 1, 2027, those payers must offer three new APIs and enhance a fourth. An API, or application programming interface, is a standardized doorway that lets one computer system ask another a question and get a structured answer, with no human retyping anything. The three new ones are a Prior Authorization API, so a provider’s system can submit and track requests electronically; a Provider Access API, so in-network providers can pull data the payer holds about their patients; and a Payer-to-Payer API, so a patient’s history can follow them when they switch plans. The existing Patient Access API, which lets patients see their own data through apps, must be enhanced.

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 their doorways. Providers were deciding how, and whether, they would walk through them.

The rule regulates payers, so most commentary follows the payers. Our focus here is 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.

How the electronic route is meant to work

Prior authorization exists because insurers want to confirm that an expensive service is covered and appropriate before they pay for it. The provider sends a request with supporting clinical information. The payer approves it, denies it, or “pends” it, meaning it wants more information before deciding. Every step today tends to involve a person reading something on one screen and typing it into another.

The CMS rule points payers to HL7 FHIR and the Da Vinci implementation guides. HL7 is the standards body that has defined health data formats for decades. FHIR, pronounced “fire” and short for Fast Healthcare Interoperability Resources, is its modern standard for exchanging health information over the internet, using the same web techniques that let a banking app fetch your balance. A FHIR “resource” is a standard building block, such as a patient, a medication or a coverage record, that any system following the standard can understand.

Da Vinci is an industry project that wrote detailed playbooks, called implementation guides, for using FHIR in exchanges between payers and providers. 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. In the best case, a clinician places an order and, within the same workflow, learns whether authorization is needed and what the payer wants to see, with much of the answer filled in automatically.

One knee MRI, old route and new

Follow a single request through both the old world and the new one. Take a patient with persistent knee pain whose orthopedic surgeon wants an MRI.

In the old world, the surgeon places the order. Days later, a scheduler tries to book the scan and discovers the patient’s plan requires authorization. The request goes to a central team, where a staff member logs into the payer’s website, retypes the patient’s details, and searches the chart for the notes the payer wants. If the notes are thin, the staffer messages the surgeon’s office, waits, and tries again. If the payer pends the request, someone faxes more pages. The patient, meanwhile, calls to ask why the scan has not been scheduled.

In the new world, as the Da Vinci guides describe it, the surgeon places the order and the system immediately asks the payer whether authorization is needed. If it is, the system retrieves the payer’s documentation rules and fills in what it can from the chart, such as the date of a prior X-ray and the weeks of physical therapy already completed. The surgeon is asked only the one or two questions the chart cannot answer. The request is submitted electronically and the decision comes back the same way, attached to the order.

The API alone does not make the difference between those two stories. It takes the API plus a chart that holds the right answers in readable form, plus a work design that sends the leftovers to the right person. Remove any one of the three and the new world turns back into the old one, only with more screens.

The transition will also be untidy. For some time, the same health system will handle some payers through the new route and others through portals and fax. Staff will need to know, for every request, which path applies. Connection status by payer is therefore an operational fact as well as an IT milestone, and it belongs where revenue-cycle leaders already look.

The connection: which system makes the call

Few health systems will build those calls themselves. An EHR vendor, a clearinghouse or a revenue-cycle platform will make them. The electronic health record, or EHR, is the main clinical system where orders and notes live. A clearinghouse is an intermediary that has long routed claims and other transactions between providers and payers.

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. ONC is the federal office that certifies health IT products against defined requirements, so this 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. A duplicated request wastes staff time, confuses the payer and can produce two different answers about the same scan.

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. X12 278 is the older electronic format for authorization requests named under HIPAA, the federal law that sets standards for many health care transactions. The enforcement statement 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. These are federal programs that tie part of Medicare payment to the use of certified health technology. As finalized in 2024, the measure 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 works only if the record holds the information in structured, consistent form.

Structured data is a field with a defined meaning, like a checkbox for “tried physical therapy for six weeks: yes or no.” Free text is the narrative a physician types, like “patient has had PT without much improvement.” A person reads both easily. A computer can reliably read only the first.

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, meaning patients the payer has linked to that provider. That can fill gaps in history, such as care received at another health system, 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, alongside 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.

Clinician attention is the scarcest resource in this design. If every order triggers a pop-up, physicians will learn to click through them, and the benefit evaporates. The goal is to show a clinician only what they alone can answer, such as a clinical judgment, and route the rest to staff or fill it automatically.

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.

Revenue, staff and patients

Prior authorization touches almost every lever a health system executive watches. On the revenue side, a service performed without a valid authorization may not be paid, and a slow authorization can delay scheduling and push revenue into a later period. On the cost side, every request worked by phone and fax consumes staff hours that could go to more complex cases. On the clinical side, delays can mean patients wait longer for imaging or treatment, and some give up. On the reputational side, patients rarely distinguish between the insurer’s delay and the hospital’s.

There is a workforce angle as well. Authorization teams are often among the hardest roles to staff in revenue cycle: the work is repetitive, the queues never empty, and the frustration of chasing faxes wears people down. Moving routine requests into an electronic flow does not eliminate those jobs, but it changes them. The remaining work, judging whether documentation supports a request, handling pended cases and preparing appeals, is more skilled and arguably more satisfying. Leaders who plan that shift deliberately, with training and revised job descriptions, are more likely to keep experienced staff than those who let it happen by accident. Clinicians will apply their own test to the new process: whether it asks them fewer questions than before, or more.

The regulatory picture adds a further dimension. Payers now publish metrics about their own performance. A health system that measures its own order-to-decision time can tell whether a delay sits with the payer or inside its own walls, which is useful both for fixing internal bottlenecks and for contract conversations.

Starting with advanced imaging

Suppose a mid-sized health system with a busy imaging department picks advanced imaging as the first service to prepare. The revenue-cycle team pulls a year of denials and finds that most were for missing documentation of prior conservative treatment. The informatics team checks the imaging order and finds no structured question about it; the information, when present, is buried in free-text notes.

The system adds two order questions, short and required only when relevant. The EHR team confirms with its vendor which release supports the electronic prior authorization steps, and which HTI-4 criteria the product is certified to. A routing rule sends imaging requests through the EHR and nothing else. Central staff are retrained to work pended cases and appeals rather than enter every request. A single program lead reports one number monthly: the share of imaging requests decided without a phone call or fax, by payer.

All of this can be done before January. When the first major payer’s API goes live, the system has structured answers ready to send and a queue designed to handle what comes back.

Where readiness usually breaks

A prepared health system has a named product and release for each payer connection, a short list of high-denial services with their documentation mapped to chart fields, a decided home for incoming payer data, a redesigned queue, and one executive who owns the end-to-end measure. The gaps tend to appear in the same places:

• Assuming the vendor has it covered. A vendor release supplies the connection, but neither the structured documentation nor the redesigned work.
• Automating free text. Sending a payer the same incomplete note faster does not reduce denials.
• Flooding clinicians with prompts. Alerts that do not need a clinician’s judgment belong with staff.
• Letting requests travel two routes. Without a routing rule, duplicates multiply.
• Measuring pieces instead of the whole. Separate team metrics can all look good while patients still wait.

What to settle before January

1. For each of our major payers, which product will call its Prior Authorization API, in which release, with which HTI-4 certification, and when will it be tested?
2. What are our ten services with the most authorization denials, and does the chart capture each payer’s documentation requirement in a discrete field?
3. Where will data from the Provider Access API land, and who reviews and reconciles it?
4. Which authorization prompts will clinicians see, and which will go to staff?
5. Who owns the end-to-end time from order to decision, and what is that number today, by payer and service?

With hindsight

No change to the January 2027 API date has been announced, as far as we can tell, and the payer-side deadline is now less than three months away. The doorways should open on schedule, and the open issue is who will be ready to use them.

Payers can meet the rule on time while providers see little difference, and that remains the risk. A regulation can require an insurer to build an API. It cannot require a hospital to connect to it, structure its documentation or redesign its staffing. The benefit sits on the far side of work only providers can do.

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, because pharmacy and medical authorizations often run through different teams and systems, and a drug requirement would widen the scope of the readiness work.

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. It is a yes-or-no question, so it sets a floor rather than a target. 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. Whether the payers are ready matters less this autumn than whether each health system has picked its first services, fixed their documentation and named the person who owns the result.