When the service changes: modifications, extensions and retro authorization
An authorization approves a specific service, in a specific setting, within a specific window, at a specific quantity. Care does not always cooperate. Procedures get rescheduled, findings change what is done, and courses of treatment run longer than expected. Each of those breaks the fit between what was approved and what happened.
#The three situations
The date moved- The most common and the easiest to miss. If the new date falls outside the approved window, the authorization does not cover it. Some payers will extend on request; some require a new review. Either way, a rescheduled procedure should automatically re-open the authorization, and in most practices it does not.
The procedure changed- A diagnostic procedure that becomes therapeutic, or a finding that changes the approach. The authorized code is no longer the performed code. Many payers have a defined process for this, sometimes retrospective, and it is far better to know it before theatre than to discover it at billing.
The course ran longer- For therapy, home health or any authorized quantity of visits, an extension is a distinct transaction type. Submitting it as a new initial request creates a duplicate review rather than extending the existing approval.
#Retrospective authorization
Some plans permit review after the service in defined circumstances: genuine emergencies, retroactive eligibility determinations, or cases where the clinical situation made prospective review impossible. It is not a general safety net, the window is short, and the standard applied is often stricter.
It is worth knowing which of your major payers allow it and under what conditions, recorded somewhere findable, because the moment you need this you are already under time pressure and reading policy documents is the last thing anyone wants to be doing.
#The operational principle
Treat the authorization as a set of constraints attached to an encounter rather than as a completed task. When any of the constrained facts change, the authorization needs revisiting. Practices that model it as a checkbox discover the mismatch at the remittance; practices that model it as live constraints catch it while it is still cheap to fix.