Prior Authorization: The Complete Guide

Prior authorization is a payer's requirement that a service be approved before it is delivered. It exists to apply the plan's medical-necessity criteria before cost is incurred. Operationally, it means a practice must prove — in the payer's format, against the payer's published criteria — that the ordered service meets those criteria.

Three things determine whether a given referral needs one: the patient's specific plan and product, the service code being ordered, and whether the specialist is in or out of network. All three are patient-specific, which is why organization-level requirement lists go stale immediately.

An approval is a payment condition, not a clinical one — but because most practices will not schedule until it is in hand, it functions as a gate on care delivery. That is what makes turnaround time a patient-access metric and not just a billing metric.

1. Determine whether authorization is required for this patient's plan, this code, and this site of service.
2. Identify the payer's criteria and the documentation that satisfies them — typically clinical notes, imaging results, and evidence of prior conservative treatment.
3. Assemble the packet from the chart, which is where most staff minutes are consumed.
4. Submit by payer portal, fax, phone, or API.
5. Track and follow up until a determination is issued, escalating when the request stalls.
6. Act on the determination — schedule on approval, or correct and resubmit when the denial reason is fixable.

ReferralPoint runs steps one through five programmatically as part of the referral itself, so the referral leaves the office already authorized. See Auto PriorAUTH for how that works inside the EHR, and prior authorization automation for the mechanics.

Payer review time is rarely the largest component. The delay accumulates before submission and after denial:

• Requirement uncertainty. Staff cannot confirm quickly whether this plan requires authorization for this code, so requests are either submitted unnecessarily or discovered late.
• Manual documentation assembly. The evidence exists in the chart but has to be located, exported, and attached by hand.
• Portal fragmentation. A practice may work three to fifteen payer portals, each with distinct credentials, forms, and attachment limits.
• No status visibility. Without a tracked queue, follow-up depends on someone remembering to check.
• Preventable denials. A large share of denials are documentation or coding defects rather than genuine medical-necessity disagreements — and each one restarts the clock. See reducing prior authorization denials.

Model it as labor plus delay. For labor: authorization volume multiplied by staff minutes per request multiplied by loaded hourly cost, plus the rework multiplier for denied requests. Most practices find that authorization handling is the single largest labor line in the referral workflow.

For delay: the share of referrals abandoned while waiting, multiplied by the downstream contribution margin of the service that never happened, plus the quality-measure and risk-contract impact of a care gap.

Both models want the same inputs you should already be reporting for referral management. Every ReferralPoint outcome figure and its source is listed on the facts page.

Authorization metrics belong in the same report as keepage, leakage, and time-to-appointment, cut the same way: by payer, by specialty, and by ordering provider. Averages hide the problem, because authorization burden concentrates in a handful of payer and service-line combinations.

The practical test of a program is whether an operations leader can name their three worst payer-by-specialty turnaround combinations from a report rather than from anecdote. See the referral management guide for the surrounding metric set.

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) requires impacted payers to stand up FHIR-based APIs covering prior authorization requirements, submission, and status, and to publish decision timelines and denial reasons.

The operational consequence is that programmatic submission stops being a per-payer custom integration and becomes a standard interface. That is what makes automation durable: the same code path works across payers, and status is retrievable rather than phoned for.

Organizations should be asking vendors how they consume those APIs today and what happens for payers that have not yet exposed them. Our readiness write-up is in the CMS-0057-F readiness post.

Sequenced by impact per unit of effort:

1. Check the requirement at the point of order, against the patient's actual plan, before the referral is sent.
2. Assemble documentation automatically from the chart against the payer's published criteria, rather than by hand.
3. Submit through payer APIs wherever available, and keep one tracked queue for everything else.
4. Triage denials by reason code and fix the preventable categories at the source instead of appealing them one by one.
5. Report turnaround by payer and specialty so the worst combinations get attention and contract conversations have evidence.

Together those five changes attack the parts of the timeline the practice actually controls, which is most of it.