- An authorization can run out two ways: the approved care gets used up, or the approval period ends. Watching one clock misses the other.
- Admissions, utilization review, scheduling, clinical, and billing all rely on the same authorization. It can't live only in the billing workflow.
- A warning that everyone sees and nobody owns is how authorizations lapse. Every warning needs an owner and a due date.
- The goal is visibility, not automated refusal. Decisions about care stay with clinicians.
Monday, 8:12 AM. A patient arrives for IOP.
They have been in the program for several weeks. They are on today's roster. The clinician sees no reason they should not attend, and they shouldn't: the patient completes the day, and the documentation is finished before anyone goes home.
Wednesday afternoon, billing prepares the claim. That's when someone notices:
Illustrative example
Strictly, it hadn't expired. Its end date was still Friday. The visits ran out the week before, and nobody looking at the calendar date would have seen it coming. That distinction, between running out of time and running out of care, turns out to be most of this article.
The authorization did not fail on Wednesday. The workflow failed Monday morning.
If billing is the first department to discover an authorization problem, the organization discovered it too late.
Prior authorization is not a billing field
Most systems store the authorization where billing will need it: on the claim side, next to the payer. But billing is the last department to use it, not the first.
Who relies on the same authorization
- Admissions
- Utilization review
- Scheduling
- Clinical
- Documentation
- Billing
- Admissions may need to know whether authorization is required before the first day.
- Utilization review may need to obtain it, track it, and extend it.
- Scheduling may need to know whether authorized services remain before booking the next one.
- Clinical teams may need to see approaching limits, because they affect treatment and discharge planning.
- Billing needs to know whether the billed service lines up with the applicable authorization.
- Leadership may need to see how authorization issues affect revenue and the program's ability to keep operating.
Six departments, one record. An authorization that lives only inside the billing workflow is visible to exactly one of them, and it is the one that finds out last.
What an authorization record actually needs to answer
An authorization number on the chart proves an approval exists. It doesn't tell anyone whether today is covered. Depending on the payer and service, useful authorization information can include:
- Payer
- Authorization number
- Level of care
- Service
- Effective date
- Expiration date
- Approved visits
- Approved units
- Approved days
- Approved dollars
- Utilization used
- Utilization remaining
- Status
- Notes
- Supporting documentation
- Continued-stay or review date, where applicable
Not every authorization contains all of these. The information available, and the information required, varies by payer, benefit plan, service, contract, and level of care. A visit-based outpatient approval and a day-based residential approval look very different on paper, and a record built for one will quietly lose information from the other.
Three kinds of “should”
This article uses “should” in three different senses, and they are worth keeping apart:
| Kind | Where it comes from | Example |
|---|---|---|
| Operational practice | Your own workflow design | Warning utilization review when two visits remain. Nothing requires it; it's just a good idea. |
| Payer requirement | The plan, the contract, and the payer's policies | Whether a service needs authorization for this member, how utilization is counted, when a review is due |
| Legal or regulatory | Statute and regulation | The HIPAA-adopted X12 278 standard for electronic authorization requests; CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) for certain payers |
Most of this article is the first kind. On the third: CMS-0057-F applies to impacted payers, including Medicare Advantage organizations and state Medicaid and CHIP programs, with some provisions starting January 1, 2026 and most of its API requirements due by January 1, 2027. It doesn't apply to every plan, and it doesn't replace the workflow on your side. Both sources are listed at the end.
Approved is not the same thing as available
Illustrative example
The word “active” is technically useful. The number “2 remaining” is operationally useful. A status tells you the approval exists; the remaining utilization tells you whether next week's schedule fits inside it. You need both.
Now two authorizations side by side:
Illustrative example
Which one needs attention first? Potentially both, for different reasons. A is about to run out of visits. B is about to run out of calendar, with twelve visits still unused. A dashboard sorted by expiration date puts B at the top and A near the bottom. A dashboard sorted by remaining visits does the opposite.
Authorization risk has more than one clock.
There are at least two ways an authorization runs out
Illustrative example
An organization that monitors only expiration dates can miss utilization exhaustion. An organization that monitors only utilization can miss expiration. The second patient above looks healthy on a utilization report, at 60% used, right up until tomorrow.
Depending on how the authorization is structured, other limits can matter too: approved units or dollars, days for a per-diem approval, or a review date that comes before either the end date or the last visit. Two clocks is the minimum, not the full list.
The schedule should know before billing knows
Tomorrow's IOP roster has 16 patients. Five of them:
Illustrative example
| Patient | Auth status | Remaining | Expiration |
|---|---|---|---|
| A. Carter | Active | 12 | Oct 18 |
| J. Miller | Active | 1 | Oct 30 |
| M. Silva | Expiring | 8 | Tomorrow |
| T. Williams | Exhausted | 0 | Oct 22 |
| R. Jones | Active | 9 | Nov 02 |
Every one of these records exists. That isn't the question. The question is whether the person building tomorrow's roster sees that Miller is on his last visit, Silva's approval ends tomorrow, and Williams has nothing left.
Seeing it at scheduling gives the right team a day to act: request an extension, confirm a pending review, talk to the patient about coverage. Seeing it on Wednesday's claim gives them a denial to work, and for many payers a denial for missing authorization is hard to reverse after the fact.
Clinical decisions and patient safety should remain separate from automated financial controls. Authorization alerts should create visibility and appropriate workflow, not replace clinical judgment. A system that silently drops Williams from the group roster has made a clinical decision nobody signed.
The authorization meter should move when care happens
If an authorization approves a defined amount of care, utilization tracking should reflect the qualifying services actually delivered, counted the way the authorization and payer require and your workflow is configured. Not the schedule, and not a number someone updates on Fridays.
Illustrative example
The part that trips programs up is “qualifying.” How utilization is counted depends on the authorization and the payer. Don't assume:
- one appointment equals one visit
- one day equals one unit
- one group equals one unit
Any of those can be true under one authorization and wrong under the next. The relationship has to come from the authorization's terms, be configured once, and then be applied every time, rather than re-decided by whoever updates the tracker.
An authorization warning needs an owner
Here is how most authorizations actually lapse:
| When | The system says | Who owns it |
|---|---|---|
| Thursday | Authorization expires in 3 days. | Everyone saw it. Nobody owns it. |
| Sunday | Authorization expired. | Still nobody. |
The alert worked. It fired on time, and it was accurate. It failed because an alert is not a task. A warning turns into work when it has the same parts any work item has:
An operational framework
- TriggerThe authorization reaches a configured threshold
- OwnerAn assigned member of the utilization review team
- ActionReview, and start the appropriate next step
- StatusIn progress
- Follow-upA due date
- ResolutionUpdated authorization information, or a documented outcome
A warning without an owner is just another notification.
What should trigger an authorization warning?
That's your decision, not the payer's. These are examples of triggers an organization might configure. None of them is a payer rule:
- Approaching expiration
- Low remaining visits
- Low remaining units
- Low remaining days
- Low remaining dollars, where applicable
- No authorization on file where one is required
- Authorization not yet approved
- Authorization exhausted
- Service scheduled outside the authorization period
- Potential level-of-care mismatch
- Continued review approaching
The thresholds are the judgment call. “Two visits left” is plenty of warning for a payer that turns reviews around in a day and not nearly enough for one that takes a week. Set them per payer if the difference is real, and revisit them when a lapse gets through anyway.
Authorization should follow the patient through the workflow
The same authorization, six questions
- Admission“Is authorization required?”
- Schedule“Is applicable authorization available?”
- Service“Which authorization applies?”
- Documentation“What service occurred?”
- Claim“Does the claim line up with the authorization?”
- Follow-up“What utilization remains?”
Each department is asking a different question about the same authorization. When each keeps its own copy, in a spreadsheet, a calendar note, a chart field, and a billing screen, every copy is correct on the day it was typed and drifts from there. The drift is the risk.
The spreadsheet problem
Utilization review maintains a tracker. It is usually good.
September Auth Tracker.xlsx — illustrative
| Patient | Payer | Auth # | Start | End | Approved | Used | Remaining | Next review | Notes |
|---|---|---|---|---|---|---|---|---|---|
| J. Miller | Payer A | A-10442 | Aug 25 | Oct 30 | 30 | 29 | 1 | Sep 15 | Clinical update requested |
| M. Silva | Payer B | B-88317 | Aug 14 | Sep 13 | 20 | 12 | 8 | — | Extension call Friday? |
Meanwhile:
- scheduling works from the calendar
- clinical works from the EHR
- billing works from the billing platform
- leadership gets a weekly report
The spreadsheet may be accurate. The problem is that the people making decisions throughout the day aren't operating from it. The front desk books Miller's next week without opening it. The “Used” column is right as of the last time someone counted. And the note that says “extension call Friday?” is a task with no owner, stored in a cell.
A perfectly maintained spreadsheet can still be operationally invisible.
What happens when authorization and scheduling disagree?
Illustrative operational example — not a care decision
Five scheduled days and two remaining authorized visits are not the same thing, and the system shouldn't silently pretend they are. It shouldn't silently resolve it either, by deleting three days or by booking them as if nothing were wrong.
What the gap needs is a person. Utilization review may be able to extend the authorization before Wednesday. The clinical team may already be planning a step-down. The patient may need to understand their coverage. Whether care continues is a clinical decision made with that information, not one the authorization makes on its own.
Authorization and level of care have to agree
Behavioral health organizations often run several levels of care, and patients move between them:
A typical step-down
- Residential
- PHP
- IOP
- Outpatient
An authorization for one level of care shouldn't be assumed to cover another. The step-down from residential to PHP or IOP is clinically routine, and it is exactly when the authorization on file stops matching the care being delivered.
Illustrative example
Payer requirements differ here, which is the point: verify the applicable authorization every time the level of care changes, including moves into outpatient care and into or out of MAT and OTP services, rather than carrying the old one forward because it is still marked active.
Continued stay should not begin the day authorization expires
Many organizations run an internal review process for continued authorization. What that process looks like, and what a payer needs to see, varies. The timing principle doesn't:
Illustrative timeline — a 20-day authorization
- Day 1Authorization begins
- Day 10Utilization progressing
- Day 15Configured review threshold
- Day 18Documentation and review workflow
- Day 20Current authorization limit
The workflow should give the responsible team enough visibility to act before the current authorization reaches its limit. Where Day 15 sits depends on your payers' turnaround and your own capacity. The failure mode is the same everywhere: the review starts on Day 20, because Day 20 is when someone noticed.
Documentation matters to authorization too
Utilization management can depend on clinical documentation to support a payer's review. Depending on the payer's requirements, relevant information can include:
- current symptoms
- progress
- functional status
- response to treatment
- continued need for care
- progress against the treatment plan
- discharge planning
- other information the payer requests
Documentation should accurately reflect the patient's condition, care, progress, and clinical judgment. Requirements for authorization review vary by payer and service. What operations can do is make sure the documentation exists and is signed when the review needs it; a documentation clock helps with that. What goes in it stays a clinical matter.
One practical note: a review packet built from notes that read the same week after week tells a reviewer very little about change. We wrote about why in Cloned notes and medical necessity.
Authorization problems should become work, not surprises
Illustrative example — authorization work queue
- Expiring
- Low utilization remaining
- Exhausted
- Pending
- Review due
- Missing
- All
| Patient | Program | Issue | Owner | Due |
|---|---|---|---|---|
| J. Miller | IOP | 1 visit left | UR team | Today |
| M. Silva | IOP | Expires tomorrow | A. Brown | Today |
| T. Williams | IOP | Exhausted | J. Smith | Today |
| R. Patel | Residential | Review due | M. Davis | Sep 14 |
The purpose of a queue isn't to report risk. A report tells you how many authorizations are in trouble. A queue tells a named person which one to work next, and shows everyone else when it's done. It's the same principle as a denials queue: reason, owner, due date. The difference is that this one works before the service instead of after the payer.
What leadership should be able to see
Illustrative numbers — not customer data
The numbers matter less than the questions they let an executive answer on a Monday:
- How many patients have authorization risk this week?
- Which programs carry the most exposure?
- Which payers generate the most authorization work?
- How much of next week's scheduled care needs review?
- Where are authorization-related billing problems actually occurring?
Authorization KPIs worth monitoring
No benchmarks here. Turnaround and workload depend too much on payer mix and levels of care for anyone else's numbers to mean much. Trend these against your own:
| Metric | What it tells you |
|---|---|
| Approval turnaround time | How long payers take, by payer, and how much warning your thresholds need |
| Approaching expiration | This week's time-clock workload |
| Approaching utilization limit | This week's utilization-clock workload |
| Expired authorizations | Lapses on the time clock that got through |
| Exhausted authorizations | Lapses on the utilization clock that got through |
| Pending authorizations | Care waiting on a payer decision |
| Scheduled services needing review | How much booked care sits outside, or at the edge of, an authorization |
| Authorization-related denials | Whether the upstream workflow is catching problems before billing |
| Days from request to outcome | Where requests stall: on your side or the payer's |
| Continued-review workload | Whether utilization review is staffed for the census |
A practical behavioral health authorization checklist
At admission
- Determine whether authorization requirements apply
- Capture payer information
- Capture authorization details when available
- Identify the applicable level of care
- Assign a responsible workflow owner
During care
- Track applicable utilization
- Monitor expiration
- Monitor configured thresholds
- Review changes in level of care
- Keep responsible teams informed
Before scheduling future services
- Review applicable authorization status
- Review remaining utilization
- Review expiration
- Surface discrepancies for appropriate review
Before billing
- Confirm the applicable authorization
- Confirm service and date alignment
- Confirm level-of-care alignment where applicable
- Confirm authorization information required for the claim
- Run configured claim validation
After payer response
- Review authorization-related denials
- Identify recurring causes
- Route issues to the appropriate owner
- Update workflows where appropriate
This checklist is an operational framework, not payer-specific authorization guidance. Requirements vary by payer, plan, contract, service, jurisdiction, and level of care.
How ProbityCare approaches prior authorization
ProbityCare makes authorization information part of the operational workflow, instead of a field billing discovers later.
In ProbityCare
The same numbers surface wherever someone makes a decision about that patient's care:
Where it shows up
- Admissions
- Patient record
- Scheduling
- Program roster
- Utilization workflow
- Billing
- Claim validation
Visits remaining and the expiration date are live on the booking screen, with a warning before the last authorized visit is used. Utilization review sees the whole picture, and continued-stay requests surface before authorized days run out. Before a claim leaves, claim scrubbing checks that the date of service falls inside the authorized window and the units fit the authorized amount. None of it decides whether care happens; it makes sure the right person knows in time.
The takeaway
Prior authorization is easy to think of as paperwork between the provider and the payer. Operationally, it is a moving constraint attached to care.
- It has a start.
- It may have an end.
- It may have utilization limits.
- It may change with level of care.
- And several departments may need to act before those limits are reached.
The authorization problem you discover while scheduling is work. The authorization problem you discover after the claim is a surprise.
Move the authorization problem upstream.
Behavioral health prior authorization questions
What is prior authorization in behavioral health?
Prior authorization is a payer process that may require approval before certain behavioral health services are provided, or before they continue. Depending on the payer and service, an authorization may specify a level of care, dates, and approved visits, units, days, or dollars. Whether it is required, and what it covers, varies by payer, plan, and service.
Does behavioral health treatment require prior authorization?
It depends. Requirements vary by payer, plan, service, level of care, and other factors, so there is no universal answer. Verify the applicable requirement for each patient and service rather than assuming either way.
Does IOP require prior authorization?
Some payers and plans require authorization for intensive outpatient programs and some do not. Check the applicable payer and plan requirements for each patient, and track approved visits, dates, and remaining utilization once an authorization is in place.
Does PHP require prior authorization?
Requirements for partial hospitalization vary by payer and plan. Verify the applicable requirement for each patient, and re-verify when the patient moves between PHP and another level of care, because an authorization for one level of care should not be assumed to cover another.
Does residential treatment require prior authorization?
It varies by payer, plan, and program. Where authorization applies to residential care, it is often expressed in days, so tracking days authorized against days used, and starting continued-stay review before the authorized days run out, matters as much as the initial approval.
What happens when behavioral health authorization expires?
The organization should review the applicable payer requirements, the patient’s circumstances and clinical needs, and its financial workflow. That can mean requesting an extension or continued-stay review, confirming a pending decision, or talking with the patient about coverage. Whether care continues is a clinical decision; an expired authorization should create visibility and work for the right team, not an automatic stop.
How should behavioral health organizations track prior authorization?
Keep authorization information in one place that every department uses, and track both clocks: remaining utilization and the approval period. Count utilization as qualifying services are delivered, surface approaching limits where scheduling happens, and give every warning an owner, a due date, and a documented resolution.
Does prior authorization guarantee payment?
No. Prior authorization does not by itself guarantee reimbursement. Payment can still depend on eligibility, benefit coverage, documentation, coding, provider requirements, payer adjudication, contract terms, and other applicable factors.