Skip to main content

Practice Operations

Interventional Radiology Prior Auth for Procedures

Site of service, staged cases and device codes make procedure authorization its own workflow. How AI works the auth queue on athenaOne referral auth records.

8 min read

Interventional radiology prior auth carries a larger downside than most authorization work, because the thing being authorized is expensive, room-bound, and scheduled weeks out. An unauthorized office visit is a write-off. An unauthorized procedure is a write-off plus a wasted suite slot plus a patient who prepared for something that did not happen. The financial exposure per event is what makes the workflow worth building properly.

Three things make procedure authorization behave differently from ordinary authorization work.

The first is that where the case is performed changes the answer. The same procedure at an office-based location and at a hospital outpatient department can carry different requirements, different approving entities, and different turnaround. So the authorization question and the scheduling question are entangled from the start rather than sequential.

The second is that a case is rarely one code. There is the primary procedure, there is imaging guidance, and there are devices or supplies that carry their own line items. An authorization approved for the primary while the case actually performed includes an add-on is a partially denied claim rather than a clean one.

The third is staging. Cases performed in stages need each stage covered, and the interval between stages is set by the clinical plan while the approved date range is set by the payer. Those two windows do not automatically agree, and nothing warns you when they stop agreeing.

Authorization state has to reach the person offering the date

The structural fix is the same one that works everywhere in this category, and it is almost never in place.

At one multi-site pain practice, between six and eight percent of procedures were being scheduled outside the authorization window by human schedulers. None of them were careless. The authorization state simply was not in front of them when they offered the slot, so they offered the best slot rather than the correct one.

Getting the appointment to land inside the window at booking time is how the claim survives checkout. That means the requirement check runs before the slot search, and the earliest offered date reflects how long this payer and this procedure realistically take.

athenaOne holds both halves. Benefit detail sits on the insurance record and the referral authorization record carries the request, its status, its reference number and its approved date range. Reading them before the calendar opens is what turns authorization from a queue that runs behind scheduling into an input that runs ahead of it.

The patient conversation improves as a side effect. A date offered three weeks out with the reason stated is a better call than a date offered for next Tuesday and withdrawn on Monday.

Cover the whole case, not the headline code

The partial approval is the most common expensive outcome and the least visible one, because it looks like an approval.

A request submitted for the primary procedure alone will come back approved, and everyone moves on. Then the case is performed as planned, with the guidance and the supplies that were always going to be part of it, and the portion that was never authorized gets denied weeks later during posting.

The administrative fix is a completeness check against your own procedure definitions. For this procedure at this site, these are the components that historically require coverage, and here is which of them the approval actually names. Any gap becomes an item for your authorization staff before the case rather than an appeal after it.

That is a comparison of a payer response against a stored definition, which automation does reliably and people do inconsistently at four in the afternoon. It is also purely administrative. Nothing about it touches what should be performed, which is set by the interventionalist.

Revenue leakage in practices tends to concentrate at the handoffs between steps rather than inside them, and the handoff between what was authorized and what was scheduled is one of the widest in this workflow.

The status chase is volume, and the escalation is judgment

Once requests are in, the work is following up until each one resolves, and physicians continue to describe authorization as one of the heaviest administrative burdens they carry.

The burden is concentrated in the chase rather than the submission. Submitting takes minutes. Finding out what happened takes weeks of attention delivered in five minute pieces, most of it spent on hold.

That part is deterministic and automates cleanly. Identify open requests by how close their case dates are, work them in that order, obtain current status, record the status with its reference number and approved date range against the authorization record, and surface only what changed.

What gets escalated is what actually needs a person. A denial with a stated reason, a request for additional clinical information, or a peer review requirement goes to your authorization staff with the payer response, the reference number and the affected case already attached. The argument for the procedure is prepared by clinicians, always, and the automation carries paperwork rather than reasoning.

The federal interoperability and prior authorization rule points this whole category toward status that can be queried programmatically and denial reasons that must be stated. A practice whose authorization state is already recorded consistently is positioned to consume that. A practice keeping it in a spreadsheet will have to rebuild first.

Protect the date once you have it

An approved authorization is a perishable asset and most practices treat it as a permanent one.

Rescheduling silently breaks the link. The new case date is not attached to the existing authorization, and the direction of the move matters. A case whose authorization has not returned can be pushed later without harm. It cannot be pulled earlier, because earlier may fall before the approval does, and pulling it earlier is exactly what a scheduler does when a suite slot opens and they are trying to fill it.

Staged cases add the second clock. The approved date range and the interval your clinicians specified between stages have to overlap, and when a stage slips the overlap can disappear without any system objecting.

So the reschedule path needs the same check the original booking had, running automatically. Re-validate against the new date, confirm the approved range still covers it, re-link the record, and flag the case when it does not fit. Where an extension or a new request is needed, it becomes work immediately rather than a discovery at checkout.

This check costs nothing when it runs on every move and costs a denied high-dollar claim the one time it does not.

The boundary, stated plainly

Everything above is paperwork and timing, and the line holds because none of it requires an opinion about the patient.

The automation does not decide whether a procedure is warranted, does not construct or argue the case for coverage, does not respond to a request for additional clinical information, and does not participate in peer review. Those belong to your interventionalists and to staff working under their direction.

With patients it is narrower still. It can say that coverage is being confirmed, what the current case date is, and what happens next procedurally. It does not explain a payer’s reasoning, discuss what the procedure is for, or advise anyone about their options. Any of those routes to your staff with the record open.

The value delivered is time and consistency. The status is current, the date is protected, the gaps surface before the case rather than after it, and your authorization team spends its day on the exceptions that needed a person.

Key Takeaways

  • Run the requirement check before offering a case date, because an appointment booked outside the authorization window is the failure that costs the suite slot too.
  • Treat site of service as part of the authorization question, since the same procedure can carry different requirements at an office-based location and a hospital outpatient department.
  • Check the approval against your full procedure definition, as an authorization naming only the primary code produces a partial denial that looks like an approval.
  • Work the status queue in case-date order and escalate only denials, information requests and peer review to your authorization staff.
  • Re-validate on every reschedule and watch the approved range against staged intervals, and never pull a case earlier while its authorization is still open.

Procedure authorization is high-dollar administrative work that fails at three specific seams: the date offered before the requirement was known, the components left off the request, and the reschedule that quietly detaches an approval. Close all three with checks that run automatically, keep the clinical argument with your clinicians, and let the authorization team work exceptions. The cases you perform stay the same. What changes is how many of them you get paid for in full.

Sources

Ready to See It in Action?

See how PGA works the procedure authorization queue and protects the date inside athenaOne

Schedule a Demo →

Written by Kevin Henrikson