Prior authorization tracking: how to build a PA log that prevents missed follow-ups
Prior authorization tracking means logging every PA request in one system with a fixed set of fields (patient, payer, service, submission date, reference number, status, decision, expiration), assigning a single owner to the queue, and enforcing follow-up cadence rules so no request sits unchecked. A disciplined log prevents missed follow-ups, expired approvals, and avoidable denials.
Most prior authorization problems are not clinical disputes. They are tracking failures: a request that was started but never submitted, a submission nobody checked on for two weeks, an approval that expired three days before the procedure. The payer never saw most of these failures. They happened inside the practice.
The fix is unglamorous: a log. Not a pile of sticky notes, not a shared inbox, not "it's in the EHR somewhere." One queue, fixed fields, a small set of statuses, and rules about who touches what and when. This article lays out exactly how to build that log, what belongs in it, and how to know when you have outgrown a spreadsheet.
If you want the upstream context first, see the full prior authorization process flow chart; this article assumes you know the steps and focuses on how to track them.
What a prior auth log must capture
A prior authorization log is a single, structured record of every PA request from identification through final disposition. The test of a good log is simple: any staff member should be able to open it and answer, for any request, "where is this, who owns it, and what happens next?" without opening the chart or calling the payer.
That requires a fixed set of fields. Here is the core schema:
| Field | What it holds | Why it matters |
|---|---|---|
| Patient identifier | Name plus MRN or DOB | Ties the PA to the chart without ambiguity |
| Payer and plan | Specific plan, not just the carrier | PA rules vary by plan, not by logo |
| Service and codes | CPT/HCPCS and diagnosis codes requested | The unit the payer approves |
| Ordering provider | Who ordered the service | Needed for peer-to-peer and clinical questions |
| Date identified | When the PA need was discovered | Starts the internal clock |
| Date submitted | When the request went to the payer | Starts the payer clock |
| Submission channel | Portal, fax, phone, or electronic transaction | Tells you where to follow up |
| Payer reference number | The payer's tracking or case number | Without it, every follow-up call starts from zero |
| Status | One value from your closed taxonomy | The single source of truth for state |
| Next action date | When this record must be touched again | Drives the daily worklist |
| Decision and decision date | Approved, denied, or partially approved, with date | Closes the payer loop |
| Authorization number, effective and expiration dates | The approval's identity and validity window | Prevents expired-auth denials |
Two fields on that list do most of the work and are most often missing: the payer reference number and the next action date. The reference number turns a 20 minute "let me locate your request" call into a 3 minute status check. The next action date turns a passive archive into an active queue.
Add optional fields as volume justifies them: units approved versus requested, renewal or reauthorization date for ongoing services, denial reason code, appeal deadline, and a link to the supporting clinical documentation.
A status taxonomy that works
Free-text status notes kill logs. "Called payer, waiting" and "pending per Amy 3/12" are not statuses; they are archaeology. Use a closed list, small enough to memorize:
- Identified: the order needs a PA, nothing sent yet.
- Preparing: documentation being gathered; requirements confirmed.
- Submitted: sent to the payer; reference number recorded.
- In review: payer has confirmed receipt and is processing.
- Info requested: payer asked for additional documentation; the ball is in your court.
- Approved: decision received; auth number, effective date, and expiration recorded.
- Denied: decision received; routed to the denial workflow.
- Expired / needs reauth: approval lapsed or is about to lapse before the service date.
Optionally add Peer-to-peer scheduled if your specialty sees frequent clinical reviews. Resist adding more. Every extra status blurs the question "what do I do with this record?"
Notice that "Info requested" is separated from "In review." They look similar but have opposite urgency: "In review" means wait and verify on cadence; "Info requested" means the payer clock is paused and every day of your delay is pure added turnaround. Practices that merge these two statuses systematically underestimate their own contribution to cycle time, a pattern that shows up clearly when you compare your numbers against prior authorization cycle time benchmarks.
Follow-up cadence rules
A status without a cadence rule is a place for requests to hide. Attach a maximum touch interval to every open status, for example:
- Identified: must move to Preparing or Submitted within 1 business day.
- Preparing: touch daily; escalate to the ordering provider if documentation is the blocker for more than 2 business days.
- Submitted: verify payer receipt within 2 business days (faxes vanish; portal submissions error out silently).
- In review: check status every 2 to 3 business days for standard requests, daily for expedited ones.
- Info requested: respond within 1 business day, no exceptions.
- Approved: same day, record auth number and expiration, notify scheduling.
- Denied: same day, route to denial management with the appeal deadline logged.
Calibrate the "In review" interval to the payer's actual turnaround. Standard determinations commonly take several days to two weeks depending on payer and service type; expedited reviews are faster. Checking daily on a payer that reliably answers on day 7 wastes staff time, while checking weekly on an expedited request is negligence. Our companion piece on how long prior authorization takes breaks down what to expect by request type.
The cadence rules become real when they are encoded as the next action date. Every touch ends the same way: update the status, write one line of note, and set the next action date per the rule. A record with no next action date is a defect.
Who owns the queue
Shared ownership is no ownership. The single most common failure mode in PA tracking is a queue that "everyone" watches and no one works.
Assign one named owner per queue. In a small practice that is one person who works the PA log as a defined block of time daily, not "when things are slow." In larger organizations, split queues by payer, by service line, or by site, but keep the rule: every record has exactly one owner at all times, and the owner is a person, not a team.
The owner's job is not to do every task. It is to guarantee that every record gets touched by its next action date, to escalate blockers (usually missing clinical documentation), and to hand off cleanly, meaning the log is current enough that a covering colleague can work the queue cold. Vacation coverage is the acid test: if the queue stalls when one person is out, you have a hero, not a system.
Give the owner a hard escalation path: what to do when a payer misses its own stated turnaround, when a provider has not supplied notes after two requests, and when a service date is inside 5 business days with no decision. Escalations that depend on the owner's judgment and bravery do not happen; escalations that are rules do.
Expiration and reauthorization tracking
An approval is not the end of the record's life. Authorizations carry effective windows, and services slip. The classic silent failure: PA approved in March for a procedure that gets rescheduled to June, the auth expires in May, nobody notices, and the claim denies for no authorization on file even though you technically obtained one.
Treat expiration as a tracked event, not a field you fill and forget:
- Record the expiration date the moment the approval arrives.
- Run a standing report (or saved view) of approved auths expiring in the next 14 and 30 days, and reconcile it against the schedule weekly.
- When a service is rescheduled, checking the auth window is part of the reschedule workflow, not a separate hope.
- For ongoing services (therapies, infusions, behavioral health visits, home health episodes), track units or visits consumed against units approved, and set the renewal date early enough to complete a reauthorization before the last approved visit, typically 2 to 3 weeks ahead depending on the payer's turnaround.
Reauthorizations deserve their own rows in the log, linked to the original. They fail for the same reasons initial requests fail, and they hide more easily because the team mentally filed the case as "done."
The daily tracking workflow, step by step
Here is the workflow that turns the log into an operating routine:
- Capture at identification. The moment an order is flagged as PA-required (at order entry, eligibility check, or scheduling), create the log record with status Identified. Do not wait for submission.
- Confirm requirements. Verify against the specific plan whether PA is required for the code, and record the source (portal screenshot, call reference). Unneeded PAs waste days; missed ones cost the claim.
- Submit and stamp. Submit through the best available channel, record the date, channel, and payer reference number, and set status to Submitted.
- Verify receipt. Within 2 business days, confirm the payer has the request in its system. Move to In review only after confirmation.
- Work the next-action list. Each morning, the owner pulls every record whose next action date is today or earlier and works it oldest first. Every touch updates status, note, and next action date.
- Clear payer requests same day. Anything in Info requested is the top of the pile.
- Close decisions completely. Approvals get auth number, window, and a scheduling notification. Denials get a reason, an appeal deadline, and a handoff to the denial workflow.
- Sweep for expirations. Weekly, reconcile expiring approvals against upcoming service dates and open reauth rows where needed.
- Report monthly. Volume, average days from identified to submitted, average days from submitted to decision, percentage touched on cadence, and expired-auth incidents. The first two numbers are yours; own them.
When a spreadsheet stops scaling
A well-built spreadsheet is a legitimate PA log, and for many practices it is the right starting point. It stops being the right tool at a predictable set of thresholds:
- Volume. Somewhere around 100 to 200 active requests, manual next-action-date discipline decays. Rows fall below the fold and out of mind.
- Multiple hands. Two or more people editing concurrently produces overwrites, forks ("PA tracker v3 FINAL"), and silent data loss.
- No timestamps. Spreadsheets record what a cell says now, not when it changed or who changed it. When a request sat for 12 days, you cannot see where.
- No automation. Nothing flags the record that missed its cadence, nothing alerts on expirations, nothing assigns work. The system depends entirely on the owner remembering to run the routine.
- Compliance surface. A spreadsheet full of patient identifiers on a shared drive is a risk you have to manage manually.
The upgrade path is a system that does three things the spreadsheet cannot: timestamps every status change automatically, generates the daily worklist from cadence rules instead of human memory, and checks payer status without a human placing the call. That last piece is where the real time goes; industry surveys such as the CAQH Index have consistently found that manual prior authorization is among the most time-consuming administrative transactions for providers, and the AMA's physician surveys regularly report practices dedicating substantial weekly staff hours to PA work. The status-check loop is exactly the part software does relentlessly and people do not, which is the core case for prior authorization automation.
If you are weighing that decision on cost, the numbers in our piece on the cost of manual prior authorization are the place to start, and our breakdown of prior authorization software cost covers what the automated alternative actually runs.
The bottom line
Missed follow-ups are a design problem, not a diligence problem. A PA log prevents them when, and only when, it has all four load-bearing parts: fixed fields including the payer reference number and next action date, a closed status taxonomy of about eight states, a cadence rule attached to every open status, and one named owner per queue. Track expirations and reauthorizations as live work, not filed paperwork. Start in a spreadsheet if you must, and move to an automated system when volume, concurrency, or the status-check burden outgrows it, because past that point the spreadsheet is not saving money, it is quietly generating denials.
Frequently asked questions
What should a prior authorization log include?
How often should staff follow up on a pending prior authorization?
Who should own the prior authorization queue?
How do you track prior authorization expiration dates?
Is a spreadsheet good enough for tracking prior authorizations?
What statuses should a PA tracker use?
Sources
- CAQH Index, administrative transaction cost and adoption research, caqh.org
- American Medical Association, prior authorization physician survey research, ama-assn.org
- Centers for Medicare & Medicaid Services, prior authorization and interoperability policy, cms.gov
