Prior authorization workflow for specialty clinics: how ePA actually works

Most of what clinics call electronic prior authorization is someone typing into a payer portal. The part that is genuinely electronic runs on two different standards, and which one applies is decided by how the item is billed, not by what the item is. Send a request down the wrong one and the denial comes back looking like a clinical rejection.

For specialty clinics, the prior authorization workflow splits into eight steps, and two of them decide whether the other six were wasted. This piece covers all eight: which benefit rail an item runs on and why nothing settles that question, why the channel you submit through is a separate decision from the rail, what a payer's clock actually is after CMS-0057-F, how to track an authorized course before it lapses, and what has to survive onto the claim.

What is electronic prior authorization?

Electronic prior authorization (ePA) is the exchange of a prior authorization request and the payer's decision as a structured electronic transaction, rather than a phone call, a fax, or a form typed into a payer portal.

In US healthcare it is not one system. Two different standards apply depending on how the item is billed: the pharmacy-benefit rail, which runs on NCPDP standards, and the medical-benefit rail, which runs on X12 278. Most of the confusion clinics have about ePA comes from treating those two as the same thing.

Two rails, split by how the item is billed

Which rail an item takes depends on how it is billed, not on whether it is a drug. A self-administered injectable that runs through the pharmacy benefit goes NCPDP. The same molecule bought and billed in your clinic goes 278. NCPDP says it plainly: SCRIPT ePA is scoped to the pharmacy benefit and is not used for items covered under a medical benefit.

That decides who reviews the request, how long they have to answer, what the denial looks like, and which of your staff can even see the queue.

The legal basis is 45 CFR 162.1302, which adopts two different prior authorization standards split by benefit type: X12N 278 (005010X217, plus 2008 errata 005010X217E1) for dental, professional, and institutional items and services, and the NCPDP Telecommunication Standard D.0 for retail pharmacy drugs. The pharmacy-benefit ePA exchange a prescriber actually touches runs on NCPDP SCRIPT, adopted separately for Medicare Part D under 42 CFR 423.160.

The pharmacy rail. The prescriber starts it from the e-prescribing workflow, a pharmacy benefit manager adjudicates it, and it moves as request/response pairs: an initiation that tells you what the plan wants to know, a request carrying your answers, then a determination. Appeals and cancellations have their own pairs, and the determination itself can come back approved, denied, or deferred.

What is real time on this rail is the claim. Once authorized, the pharmacy claim adjudicates at the point of sale before the drug is dispensed, which is why coverage problems surface at the counter rather than weeks later.

The versions move on a published schedule. For Medicare Part D, SCRIPT 2017071 has been required since January 1, 2022, and version 2023011 takes over on January 1, 2028. The HIPAA-side pharmacy standard moves too: D.0 holds until August 14, 2027, both D.0 and F6 are permitted until April 14, 2028, and after that F6 is the only adopted standard.

The medical rail. The practice or its clearinghouse submits an X12 278 Health Care Services Review, the health plan's utilization management side adjudicates it, and the response comes back as a certification with an authorization number, a denial, or a pend for more information. Payment happens later, on a claim. The version in force is 005010X217 from May 2006, plus 2008 errata. No newer version has been adopted under HIPAA.

Specialty clinics live on the seam. Injectables, infusions, biologics, and in-office administered drugs all raise the question, and the answer changes by payer and sometimes by plan.

The prior authorization workflow for specialty clinics, end to end

1. Confirm whether an authorization is required

This step fails more often than any other.

Three sources answer the question, in descending order of trustworthiness: the payer's published medical or pharmacy policy for the specific plan, the eligibility response (a 271 can carry a prior-authorization indicator at the benefit level, which is what eligibility checks worth running read), and the EHR's cached requirement data. Treat the third as a hint.

Requirements also move. Cigna's TMS prior authorization requirement changed in March 2026. Anything cached from last plan year is a guess.

“No prior authorization required” is not the same as “no work required.” Where a payer has waived the requirement but kept the coverage criteria, the criteria are still enforceable after the fact, on audit. The packet you would have submitted is the packet you want on file.

2. Determine which benefit the item runs under

For a specialty drug, nothing settles this question, and getting it wrong sends three weeks of work into the wrong queue. For a procedure it is easy: a service billed with a CPT code on a professional claim runs on the medical benefit and nothing else.

The same product can be a pharmacy-benefit drug for one member and a medical-benefit drug for another, depending on the payer, the line of business (commercial, Medicare Advantage, Medicaid managed care), the state, and sometimes the site of care or the indication. There is no lookup that settles it.

Three things go wrong when the routing is wrong:

• You submit to the health plan's utilization management team for a drug the PBM adjudicates. It is denied or ignored, and the denial reads like a clinical rejection.
• You build the packet against the wrong criteria set. Pharmacy and medical policies for the same product frequently differ on trial counts, durations, and documentation.
• You bill the wrong way. A drug obtained through a specialty pharmacy that you then bill as buy-and-bill is a claim denial waiting to happen, and the reverse is worse.

Three sources answer the routing question, and you want them in this order. The payer's own medical policy and pharmacy policy for that plan — read both, because sometimes only one of them mentions the product. The benefit verification, where a benefit-level response distinguishes the two. And the manufacturer's coverage-support resources: many specialty products publish a free provider-facing payer-policy lookup, and those tools generally report benefit type as a first-class field for each plan they list. They are a good index, not a citation. Confirm against the payer's own document.

Whatever you conclude, record it as a field on the patient, with the source and the date. The next person to touch this patient should not have to redo the reasoning, and when a payer changes its position you want to know which patients were routed on the old answer.

3. Find out what this payer requires

The pharmacy rail hands you this: the initiation response returns the question set. The medical rail does not. On 278 you are working from the plan's published policy and, in practice, from what got approved last time.

For a specialty clinic this is where the work is. Payer criteria for the same treatment vary on nearly every axis that matters. How many prior therapies must have failed. How long each had to run. Whether they fall in the current episode of illness, how recent they must be, which outcome instruments are accepted, and whether a non-drug therapy trial is required at all. Two payers covering the same drug can differ on all six.

Prior-therapy evidence has to be auditable, which takes more than a sentence in a note. Free-text narrative is what gets kicked back; structured evidence against the plan's own criteria is what clears. A complete GLP-1 packet wants BMI history, comorbidities, and documented lifestyle intervention. A buprenorphine film authorization usually wants a documented trial of the formulary tablet. And criteria are payer-specific enough that a single drug can break into five distinct Spravato denial clusters across payers.

AHIP, the insurers' trade association, says in its June 2025 report that initial denials are often the result of incomplete information from providers rather than clinical disagreement. The other side of that: a 2022 HHS OIG review of one week of Medicare Advantage denials from 2019 found 13% of denied requests met Medicare coverage rules, and one of the two common causes was plans asking for documentation the case file already contained.

Two things are true. Some denials are packaging failures you control, fixable before submission rather than after. A documented share are payer error you do not control, which is why an 11.5% appeal rate is its own problem.

4. Submit through the channel the payer accepts, and capture proof

Which benefit rail applies is a different question from how the request physically reaches the payer, and clinics that treat them as one question stay confused.

Most “electronic” prior authorization is not electronic in the standards sense.

Portal volume grew 20% year over year while the standard 278 transaction grew 6%, and CAQH's own language is that providers request a prior authorization from a health plan most often via a portal.

So “we do prior authorization electronically” almost always means someone is typing into a portal. Payers are retiring fax and phone by pushing providers into proprietary web portals, not into the standard transaction. CAQH points at complex and changing plan requirements, inconsistent data, and low adoption. The documentation problem is separate and structural: there is still no federal standard for attachments, which is why electronic attachment use is the lowest of any medical transaction CAQH measures.

The practical response is a payer-channel matrix. Six columns, one row per payer and service class:

Clinics that skip this end up with a different tribal process per payer, held by one person. How the ePA vendor categories differ turns on exactly this point: some of them cover one rail only.

Fax still sits in that matrix and it is the expensive lane. The fully manual bucket fell 37% in a single year. Keep fax as a compatibility layer for the payers that accept nothing else, and stop treating it as the workflow.

Whatever the channel, capture three things at submission: a timestamp, a reference number, and a copy of exactly what was sent. Portals are the weak point. Some return no reference number at all, and a screenshot is the only artifact you will have. That artifact is what you need in an appeal three weeks later, and it is the difference between “we submitted it” and being able to prove when.

Attachments deserve their own warning. There is still no HIPAA-adopted standard for prior authorization attachments. CMS finalized an attachments rule in March 2026 but limited it to claims attachments and explicitly declined to finalize PA attachments. Clinical documentation therefore moves by portal upload, by fax, or by whatever a specific payer's implementation supports. If any part of the packet is drafted for you rather than by you, a verification framework for AI-drafted prior-auth packets covers what to check before it goes out.

5. Track the decision against the clock

For CMS-regulated plans, the clock is now written down. Under CMS-0057-F, impacted payers must decide expedited requests within 72 hours and standard requests within 7 calendar days, effective January 1, 2026. Impacted payers means Medicare Advantage, Medicaid and CHIP fee-for-service, Medicaid and CHIP managed care, and Qualified Health Plan issuers on the federally facilitated exchanges.

QHP issuers on the FFEs sit outside the new 7-calendar-day standard clock. CMS left them on the existing 45 CFR 147.136 rules, which give them 15 days for standard decisions. Their expedited clock is already 72 hours, the same as every other impacted payer.

Commercial group plans, ERISA self-funded plans, standalone Medicare Part D plans, and QHPs sold on state-based exchanges are not impacted payers at all. Every prior authorization provision in the rule also excludes drugs.

State timeframes move faster than any summary of them, including this one. Treat the dates above as a starting point and confirm against the current statute and the payer's own provider manual before you build a clock around them.

Read that again if your book is mostly commercial and mostly drugs, because it means the rule everyone calls “the 2026 prior auth rule” changes very little for you today. State law fills some of the gap unevenly, and some of it has not landed yet. Vermont requires 24 hours for urgent requests and two business days for standard. Virginia's 72-hour expedited and seven-calendar-day standard rule for health care services takes effect January 1, 2027; today Virginia's drug-benefit rule runs 24 hours urgent and two business days standard.

Two provisions are live right now and underused. Payers must give a specific reason for every denial, detailed enough to tell you whether to appeal, send more documentation, or change the treatment plan, and that duty holds no matter how the payer communicates the denial, including by phone or fax. And impacted payers had to publish prior authorization metrics on their websites by March 31, 2026. The CMS prior-authorization metrics payers now publish are sitting there, and they are usable in a payer conversation.

Nothing in a PA workflow rots faster than a submitted request nobody is watching, so whatever the payer's clock, you need your own queue for “sent, no answer yet.”

6. Handle the decision

An approval carries an authorization number, an approved code set, a unit count, and a date span. Capture all four as structured fields. The Prior Authorization API that impacted payers must stand up by January 1, 2027 has to return, on an approval, the date or circumstance under which the authorization ends — the regulator treating span limits as a distinct field you are expected to capture.

Decide what to do with a denial before you appeal it. In the AMA's 2025 physician survey, roughly a third of physicians (32%) report PAs are often or always denied, but only 21% always appeal, mostly because they expect the appeal to fail (59%) or have no staff time (52%). Given how often appealed denials are overturned, that expectation is usually wrong. But the faster fix is often a corrected code, a peer-to-peer review, or an amendment to the existing authorization rather than a formal appeal.

7. Track utilization, and renew before coverage lapses

This is the step specialty clinics most often run on a spreadsheet, and it is where a course of treatment quietly turns into unpaid work.

An approval is a budget: N units of a specific code, inside a date window. Every delivered session spends part of it. If nobody is counting, the clinic finds out it went over when the claim is denied, and by then the service has been delivered.

Three things have to be true for this to work.

Delivered has to be counted against authorized, continuously. Not at month end. The count has to come from something that reflects delivery, such as completed appointments or encounters, and it has to be idempotent, because sync jobs re-run and you do not want a double count deciding a patient is out of sessions.

The renewal trigger has to fire before the window closes, not when it closes. Lead time is payer-specific, and so is the required wait between courses. Build in the payer's lead time, not a generic 30 days.

The evidence a renewal needs has to already exist. This is the trap. Many payers gate a repeat course on documented improvement against a baseline. If the baseline instrument was never administered, or the end-of-course score was never captured, the renewal is unfundable no matter how well the patient did. The score has to be collected on schedule, during the course, by someone whose workflow includes it, which is a clinic operations decision rather than a billing one.

That last point generalizes past any one specialty. Any treatment authorized in courses has the same shape: a unit budget, a date window, an outcome measure that gates renewal, and a lead time before the boundary.

8. Carry the authorization onto the claim

This is where approved work still turns into lost money.

Nothing in any federal rule requires a payer to reconcile the authorization it issued with the claim you send. That reconciliation is your job, and the denial codes that result are worth watching as a group rather than one at a time.

Where this breaks in practice

What comes up repeatedly in the specialty and telemedicine clinics we work with:

• One person holds the whole process. The AMA's 2025 survey found 40% of physicians have staff who work exclusively on prior authorization. Smaller clinics do not, so the knowledge lives in one person's head and one spreadsheet, and it walks out the door with them.
• Submitted requests go unwatched. There is no queue for “sent, no answer yet,” so a stalled authorization surfaces when the patient calls.
• The pharmacy path is not always yours to start. When a specialty pharmacy or a manufacturer hub opens the case, your clinic is answering questions inside someone else's workflow while the clinical detail they need sits in your chart.

Getting the data right before you automate anything

Most of a specialty clinic's authorization pain is decided upstream, in what the chart captures and how. You cannot automate your way past a note that does not contain the fact a payer requires. This is the part of an implementation that is easy to skip and expensive to skip.

The exercise is straightforward: take the criteria for your top payers by volume, list the specific data elements they require, and check whether your current documentation produces those elements in a form someone could pull without reading prose. Where it does not, the fix is usually a template change rather than a technology purchase.

What that inventory tends to surface, in roughly the order it matters.

Prior therapy history as a table, not a sentence

Payers count trials against their own definition of adequate, which varies from four weeks to eight weeks at a therapeutic dose depending on who you are billing.

What else the inventory surfaces

Whether a prior therapy falls in the current episode. Some payers count only failures inside the current episode of illness; others impose a recency window of a few years. “The patient tried that years ago” is either qualifying evidence or worthless depending on the payer, and you cannot tell which without dates.

Outcome measures with a position in the course. Not just the score, but whether it was a baseline, mid-course, or end-of-course measurement, plus the date and who administered it. This is what makes renewal automatic instead of a scramble. It is also where payer variation bites: accepted instruments differ, and some payers set a hard numeric threshold on a specific instrument, so administering only the one your clinicians prefer can disqualify a patient on paper.

Screening and exclusion checks recorded as answered, not absent. There is a real difference between “assessed and negative” and “not assessed,” and a packet that cannot distinguish them reads as incomplete. A structured checklist with an explicit answer per item, plus detail where the answer is yes, produces a packet that can affirmatively state exclusions with a source.

Corroboration for history the clinic did not generate. Patients remember that they tried a medication; they rarely remember the dose or duration. Pharmacy fill history corroborates dates and strengths. Where a prior therapy has no records trail at all, from a cash-pay provider or an out-of-network therapist, the workable fallback is a documented patient-attested history plus a log of the attempts you made to obtain records. That combination at least shows diligence, which is more than a blank field does.

A delivery record you can count. Whatever system holds appointments or encounters has to be the one that says a session happened, and it has to say so in a way a machine can read against an authorization.

None of this requires new software. It requires deciding that the note template exists partly to satisfy a payer's auditor, and designing it that way.

What to measure

Six numbers, none of which requires new software to start tracking:

1. First-pass approval rate, by payer and by CPT or drug.
2. Median time to decision, by payer, against that payer's stated or regulated clock.
3. Percentage of submitted requests with no payer response after 7 days.
4. Authorization-related denial dollars, split between “no auth on file” and “auth present but mismatched.”
5. Percentage of services rendered before the authorization was confirmed.
6. Rework caused by benefit-routing errors: requests that had to be rebuilt and resubmitted on the other rail.

The fifth is usually the worst number on the list the first time a clinic measures it, and it is the one that turns a clinical decision into an uncompensated visit. The sixth is usually invisible until someone counts it.

How Foresight handles this

Foresight sits between the EHR and the payer, and treats a prior authorization as a case record rather than a form submission. Routing, assembling, and sending a request are three separable problems.

Foresight settles routing before anything moves. It resolves each authorization to the pharmacy benefit or the medical benefit per payer and per patient state, records which source answered and how firm that answer is, and skips the question entirely for services that only ever bill one way. When the sources disagree or do not cover the case, nothing advances: Foresight opens a work item carrying the full determination and a recommended next step, and a person decides. A pharmacy-benefit answer stops the medical lane the same way, because that rail is handled separately.

The payer's policy governs the case, rather than grading it afterward. Foresight stores each payer's authorization posture as structured data: whether prior authorization is required, which channel, how long an authorization runs, how many units it covers, and what has to be true to renew it. Every row carries a source URL, an effective date, and a verification status, so a stale policy is visible rather than assumed current.

Foresight picks that payer's row for that service, preferring verified rows, and the same row drives every step that follows: the criteria check, the documentation, the channel, the authorization window, the unit grant, and the renewal rules.

The criteria are evaluated before anything is sent, so a gap holds the request and files one work item naming exactly what is missing, rather than sending an incomplete packet and learning about the gap three weeks later. Where a criterion cannot be resolved from the record, it resolves to “unknown” and goes to a person. It never resolves to a guess.

Foresight never copies proprietary licensed criteria sets into the platform. Payers who use them get routing and documentation-completeness handling instead.

The letter is built from what is on file, and blocked when it is not. Foresight drafts clinical documentation from the patient's structured evidence rows and checks it for completeness against that evidence. A draft the record does not support is not attached. The generated letter is marked as requiring provider sign-off before submission, and a missing element becomes a named gap on the work item rather than a plausible sentence in a letter.

That is why implementations start with the data. Before automation runs against a payer, we work through the clinic's current documentation against the criteria for its highest-volume payers and identify what has to change: which fields become structured, which template needs a therapy-history table, where an outcome measure has to be scheduled rather than administered ad hoc.

The platform models prior therapy trials with the dose reached and the reason for discontinuation, therapy history with a records-unobtainable fallback, outcome measures tagged by position in the course, and screening checklists that distinguish “assessed and negative” from “not assessed.” That structure only pays off if the clinic's workflow fills it, which is why that work is the implementation rather than a prerequisite to it.

Foresight treats an approval as a budget and counts it down. It records the approval as an authorized course: the authorization number, plus the unit budget and date window the payer's policy sets for that service. It counts completed appointments against that budget in a ledger that cannot double count when a sync re-runs, so remaining units are always reconstructible, and it flags the authorization before the units are gone rather than after.

Renewal timing comes from the payer's own rules where the payer publishes them: lead days before the window closes, required wait after a completed course. Where a payer gates renewal on documented improvement, Foresight computes it from recorded outcome scores and separates three problems: no baseline, no end-of-course score, and a score below the bar.

When the bar is met, Foresight drafts the successor request from the predecessor and puts it in a review queue. It does not send it.

Channel is a data problem, not a preference. The payer's policy row records how that payer takes the request, and the case is routed accordingly: the standard transaction through a clearinghouse, the payer's own portal, the ePA API in your e-prescribing vendor or EHR where the pharmacy benefit exposes one, a documentation-only posture where the payer has waived prior authorization but kept the criteria, or straight to a person where the payer takes nothing else.

In the documentation-only case the packet is still assembled and retained as an audit-ready record rather than the case being skipped. Requests that go out and get no answer surface on their own, so a stalled authorization lands in the review queue instead of nobody's inbox.