The prior authorization workflow

Prior authorization is a utilization-management control in which a payer agrees, in advance, that a proposed service meets its coverage and medical necessity criteria. The workflow is the operational process that produces that decision — a defined series of steps that confirms the requirement, builds the clinical case, moves the request through the payer's channel, and closes the loop at billing. Treating it as a workflow rather than a one-off task matters because most authorization problems are process failures: a requirement missed, a document omitted, a deadline passed, or an approval that never made it onto the claim.

At a high level the same stages recur across payers, even when the tools and deadlines change. The sequence below describes the shape of the process; the specifics at each step are governed by the current rules of the patient's plan.

1. 01

   Identify the requirement

   Verify active coverage and check whether the specific service, drug, or device requires authorization under the patient's current plan.
2. 02

   Gather documentation

   Collect the clinical record, ordering rationale, and any prior-treatment history needed to demonstrate medical necessity.
3. 03

   Submit the request

   Send the request and its supporting documentation through the payer's designated channel.
4. 04

   Track status

   Monitor the request against the payer's decision timeframe and respond promptly to any request for additional information.
5. 05

   Receive the decision

   Record an approval's authorization number, approved codes, units, servicing provider, and date range — or note the stated reason for a denial.
6. 06

   Resolve a denial

   Where available, pursue peer-to-peer review or a formal appeal supported by added documentation.
7. 07

   Reconcile at billing

   Confirm the service delivered and billed matches what was authorized before the claim goes out.

The workflow begins before any request is drafted. Confirming the patient's active coverage through eligibility verification establishes which plan's rules apply, because a requirement that exists under one plan may not exist under another. From there the team determines whether the specific service is subject to review. Payers publish authorization lists, but those lists are plan-specific and change, so the current source always governs; guidance on reading them appears in which services require prior authorization.

A request is only as strong as the clinical evidence behind it. Most decisions turn on documented medical necessity — the clinical facts showing the service is appropriate for the patient's condition. Some drug and service categories also apply step therapy, which asks that a preferred or lower-cost option be tried first unless an exception is documented. Assembling that support up front is the focus of gathering clinical documentation for authorization.

• The ordering clinician's rationale and the relevant diagnoses
• Pertinent history, exam findings, and prior test or imaging results
• A record of previously tried treatments where step therapy applies
• The requested service described using the standard code sets its maintainers publish, with the requested units or frequency

Once assembled, the request is submitted through whatever channel the payer designates. The channel, required form, and turnaround time are set by each payer and can differ for standard versus expedited review. Preparing and sending a request is covered in submitting a prior authorization request, and the growing role of standardized electronic submission is covered in electronic prior authorization.

A payer's decision is the pivot point of the workflow. An approval is specific: it authorizes named services for a defined number of units, for a particular servicing provider, within a date range, and it carries a number that must be captured. A denial states a reason — commonly insufficient documentation, a step-therapy gap, or a determination that criteria were not met. Denials are not final; the mechanics of each outcome, including reviewer discussions and appeals, are detailed in approvals, denials, and peer-to-peer review.

Approval

Advance agreement to cover the named service; record the authorization number, codes, units, servicing provider, and date range.

Denial

A decision not to authorize; the stated reason drives the next step.

Peer-to-peer review

A discussion between the ordering clinician and the payer's reviewer that can resolve a denial without a full appeal.

Appeal

A formal request to reconsider a denial, usually with added documentation and within a payer-set deadline.

The workflow does not end at approval. Because an authorization is bounded, the service actually delivered must match what was approved — the same procedure, servicing provider, and unit count — or the claim can be denied even though an authorization exists. Reconciling those details is the subject of matching authorized units to billed services. When care must proceed before approval, or a requirement is discovered after the fact, retroactive and urgent authorizations describes the narrower pathways some payers allow.

Understanding why these requests fail — and preventing repeat problems — is covered in authorization-related denials. Throughout the workflow, the constant is variation: requirements, submission channels, decision timeframes, and appeal windows are set by each payer and plan and change over time, so the authoritative source should always be checked against current rules rather than assumed from a prior case.