Building a prior authorization tracking process

A tracking process is the structure that sits on top of the day-to-day prior authorization workflow. The workflow describes the sequence of obtaining a single approval — verifying whether a service requires authorization, gathering documentation, and submitting the request. The tracking process, by contrast, records the state of every open request at once and makes that state durable and shareable. One describes how a request moves; the other is the ledger that keeps the practice from losing any request along the way.

The goal is continuity. Authorizations often span days or weeks, cross shifts and staff, and involve back-and-forth with the payer. A tracking process ensures that when the person who submitted a request is unavailable, the next person can see exactly where it stands and what to do next. This article covers designing that system; the ongoing act of checking payer responses and watching due dates is covered in tracking authorization status and deadlines.

Whatever tool holds the log — a shared spreadsheet, a practice-management worklist, or a dedicated module — it should capture a consistent set of fields for every request. Standardizing these fields is what makes the log searchable, auditable, and safe to hand off. The specific fields a practice needs vary by specialty and payer mix, but most tracking logs record the following.

Encounter and patient reference

A non-identifying internal record number that ties the request to the scheduled service, without storing unnecessary detail in the log itself.

Payer and plan

The specific payer and plan, because requirements, submission channels, and timeframes are set by each payer's contract and can differ even within one payer's product lines.

Requested service or item

The service, procedure, or medication being requested, described in plain terms; the log should reference the concept rather than reproduce licensed code descriptors.

Submission date and method

When and how the request went out — portal, fax, phone, or an electronic transaction — which anchors any follow-up clock the payer applies.

Authorization number

The authorization number the payer issues on approval, which later must appear on the claim.

Approved scope and dates

The approved units or visit count and the valid date span, since approvals are frequently limited to a set quantity and window that vary by payer and plan.

Status and next action

The current state (pending, approved, denied, or in appeal) and the date of the next follow-up, so no request goes silent.

1. 01

   Define scope and triggers

   Identify which services and payers require authorization so the right encounters enter the log in the first place. Requirements change over time and differ by payer, so this list should be reviewed against current payer policies rather than treated as fixed; the sibling article on which services require prior authorization explains how to make that determination.
2. 02

   Choose one system of record

   Select a single place where every request lives. Consolidating in one tool prevents the divergence that happens when status is scattered across inboxes and portals. A structured authorization status log or a prior authorization request tracker can serve as a starting point.
3. 03

   Standardize the data fields

   Require the same core fields on every entry so the log is consistent and searchable. Incomplete entries are where requests fall through the cracks.
4. 04

   Assign ownership and a cadence

   Name who monitors the log and how often it is reviewed. The right follow-up frequency depends on payer response times, which vary and are set by each payer, so the cadence should reflect current payer expectations rather than a single universal rule.
5. 05

   Build reminders for deadlines and expirations

   Add prompts for approaching decision deadlines, expiring approvals, and near-exhausted units. Whether these are manual or automated, they must be watched actively.
6. 06

   Close the loop to billing

   Confirm that the approval reaches the claim. An approval that never makes it onto the submitted claim protects nothing.

Much of the value of a tracking process comes from what it prevents. Approvals are typically bounded in three ways — a decision deadline the payer works within, a valid date range for the authorization, and a cap on approved units or visits. All three vary by payer, plan, and the service in question, and all three change over time, so the tracking process should surface them rather than assume them.

• Pending requests that are approaching or past the payer's expected response time and need follow-up.
• Approved authorizations whose valid date range is about to end before the service is rendered.
• Authorizations whose approved units or visits are nearly used up, which is closely tied to matching authorized units to billed services.
• Denied requests that may warrant a peer-to-peer review or an appeal, along with the applicable response window.

Practices generally track authorizations either in a manually maintained log or within a system that is integrated with scheduling and billing. Neither is inherently correct; the right fit depends on volume, specialty, and existing systems. The comparison below highlights the trade-offs across common dimensions.

A tracking process is only complete when it connects back to revenue. Before a claim goes out, the authorization number, approved units, and valid dates should be verified against what is being billed so the two agree. Handling of approvals, denials, and peer-to-peer review then flows from the same log, keeping decisions and their follow-up in one place. When a request is denied or an approval lapses, the log becomes the record of what happened and why, which is exactly the input that authorization-related denials work depends on.

Finally, the accumulated data is worth mining. A consistent log makes it possible to see approval and turnaround patterns, spot payers or services that generate the most friction, and target improvements — the foundation of measuring prior authorization performance. As electronic exchange of authorizations expands, some of this tracking can shift toward electronic prior authorization, though the underlying discipline of capturing, monitoring, and closing out every request stays the same.