Prior Authorization Status Is a Tracking Problem

Most orthopedic practices have solved the first half of prior authorization. Someone gathers the clinical detail, someone submits it, and there is a process for both. What almost nobody has solved is prior authorization status: the days or weeks between submission and a decision, during which a surgery date is sitting on the schedule and nothing is watching whether the approval will arrive before it does.

The gap is structural rather than careless. A submitted authorization leaves the practice and enters a payer’s queue, where it may be approved, pended for more information, redirected to a benefits manager, or quietly denied. None of those events announce themselves. Somebody has to go look, in a portal, one case at a time.

So status checking becomes the task that gets done for the cases someone remembers and skipped for the rest. In orthopedics that skew is expensive, because the cases carry imaging, implants, facility time, and an anesthesia group whose schedule was blocked on the assumption the case would go.

A case that reaches the day before surgery without a confirmed approval creates two bad options: proceed and risk a denial on a high-dollar claim, or cancel and lose a block that could have been filled three weeks earlier.

The cheapest check is whether an authorization is needed at all

Before any of the tracking work, there is a question that saves more staff time than anything downstream: does this plan require authorization for this code at this site of service?

Practices routinely work authorizations that were never required, because the safe habit is to submit when unsure and nobody has time to research the alternative. That habit costs real hours and adds delay to cases that could have been scheduled immediately.

Running the requirement check first splits the queue into three groups. Not required, which goes straight to scheduling with the determination documented. Required, which goes into the submission workflow. And unclear, which goes to a person, because that is exactly the case where a wrong assumption is expensive.

Documenting the not-required determination matters as much as making it. When a claim is later questioned, the record of what was checked and when is what turns an argument into a two-minute answer.

Status lives in portals, and the portals are not consistent

This is the operational reality that makes status tracking a labor problem rather than a data problem.

Status for a given case may sit in the payer’s own portal, in a delegated benefits manager’s portal for imaging or musculoskeletal services, or behind a phone call for the plans that never built a usable portal at all. Each has its own login, its own session timeout, and its own vocabulary for the same three or four states.

An out-of-state plan makes it sharper. A patient with a plan administered in another state may have benefits processed by an entity the practice has never contracted with, and the local portal will show nothing useful. Knowing that early, at the point of scheduling rather than at the point of denial, is the difference between a rescheduled case and a written-off one.

The machinery that works here is unglamorous and it is exactly the kind of thing that should not consume a coordinator’s day: check every open case on a cadence, record the state and the date it changed, and surface only the ones where the state moved or where the clock has run past a threshold. The value is in the sweep being complete rather than clever.

Status has to land where scheduling can see it

An authorization status that lives in a spreadsheet is a status nobody acts on, and this is where most tracking efforts quietly fail.

The status belongs against the case in athenaOne, connected to the appointment it gates, so the people looking at next week’s surgical schedule can see which cases are approved, which are pending, and which have gone past a threshold. When status only exists in a coordinator’s tracker, the surgical scheduler is working from a different set of facts than the person chasing the payer.

The write-back also has to include the details that matter later: the authorization number, the approved code set, the units or visit count approved, and the valid date range. An approval for a different code than the one that gets billed is a denial with extra steps, and the mismatch is only catchable when both sit in the same record.

One more field earns its place: what changed and when. A case that moved from pending to more-information-requested on Tuesday needs a different response than one that has been pending untouched for eleven days, and only the history tells you which is which.

The orthopedic complications specifically

Three that show up constantly in this specialty.

The case that changes. A surgical plan adjusts, codes change, and an existing approval no longer matches what will be performed. Any change to the planned procedure has to trigger a re-check against the approval on file rather than being treated as a scheduling edit.

The reschedule that breaks the window. Approvals carry a valid date range, and moving a case later can push it outside. This is the mirror image of the waitlist constraint: an authorized case can often be moved earlier but not later without a fresh look, and a scheduler moving a date without that check creates a denial three weeks out.

Post-operative visits and therapy. Approved visit counts for therapy attached to a surgical episode get consumed over weeks, and running out mid-course produces exactly the kind of patient conversation nobody wants to have. Tracking remaining authorized visits alongside the surgical authorization keeps that from arriving as a surprise.

The numbers worth reporting weekly

Two numbers belong at the top of any weekly review.

First, cases scheduled inside the next fourteen days without a confirmed approval. This is the operational risk list, it is short, and it is actionable. Every entry is either a chase, a reschedule, or a decision to proceed with eyes open.

Second, authorizations pending past a threshold the practice sets by payer. Payers differ enough that a single threshold hides the problem; tracked per payer, the pattern that emerges is usually one or two plans generating most of the delay, which is a conversation the practice can have with a contract in hand.

Below those, watch denials attributed to authorization: no auth on file, code mismatch, expired window, and wrong site of service. That breakdown points directly at which step failed rather than telling you that prior auth is hard, which everyone already knows.

And track the requirement check itself. The share of cases determined not to require authorization is a measure of hours saved, and it tends to be larger than practices expect once someone is actually checking.

Key Takeaways

Check whether an authorization is required for the code, plan, and site of service before working one, and document the determination.
Sweep every open case on a cadence rather than checking the ones somebody remembers. Completeness is the value.
Expect status to be split across payer portals, delegated benefits managers, and phone-only plans, and identify out-of-state administration at scheduling rather than at denial.
Write status back against the case and the appointment in athenaOne, including authorization number, approved codes, units, and valid date range.
Keep the status history. Pending for eleven days and moved to more-information-requested yesterday need different responses.
Re-check the approval whenever the planned procedure or codes change, and whenever a case is rescheduled later.
Track remaining authorized therapy visits alongside the surgical authorization so a mid-course shortfall is not a surprise.
Report cases inside fourteen days without approval, pending age by payer, and denials split by cause.

The submission is the part everyone staffs. The tracking is the part that decides whether the surgical schedule holds, and it fails not because the work is difficult but because it is repetitive, spread across portals nobody enjoys, and easy to defer until the week of the case. An AI team can run that sweep every day, put the status and the approved detail back on the case in athenaOne where the scheduler can see it, and surface the short list of cases that need a person.

Sources