PHP Billing Mental Health: Documentation Rules for Authorization and Level-of-Care to Get Paid

PHP Billing Mental Health

PHP billing mental health programs run on an entirely different logic than routine outpatient claims: program-level structure instead of visit-based billing, authorization sitting at the center of nearly every claim, and level-of-care criteria deciding whether a stay is even payable. The rules for proving all of it also vary sharply depending on which payer is on the other end. PHP authorization requirements are plan-specific — the free payer policies lookup shows what each payer requires before you submit.

What makes PHP billing mental health different from routine outpatient claims

A partial hospitalization program bills as a program, not a series of individual sessions, which means facility and program-level billing rules apply on top of everything a standard outpatient claim already requires. Those rules aren’t consistent across payers either.

Infographic contrasting UnitedHealthcare Rocky Mountain Health Plans, which explicitly requires prior authorization for PHP under revenue codes 912 and 913, against Original Medicare, which has no routine prior authorization structure and instead relies on physician certification, an individualized plan of care, and a 20 hour per week medical necessity threshold
The same level of care, two entirely different rule structures.

UnitedHealthcare’s Rocky Mountain Health Plans, for example, explicitly requires prior authorization for behavioral health PHP under revenue codes 912 and 913. Original Medicare takes a completely different approach, with no routine pre-service authorization step at all. Coverage instead depends on physician certification, an individualized plan of care, documented medical necessity, and a requirement that the patient need at least 20 hours of therapeutic services a week as evidenced by that plan of care. The emphasis sits on clinical eligibility and documentation rather than a standard prior-auth checkpoint, which means a billing process built around one payer’s rules can fail completely against another’s.

Step-down timing adds one more layer that doesn’t exist in routine outpatient billing. When a patient transitions to a lower level of care matters clinically, but it also directly affects what’s still billable and what isn’t.

The billing challenges that come with PHP mental health programs

Authorization itself gets granted by day or specific date range rather than as a blanket approval, which means continued stay reviews become a recurring, unavoidable part of the billing cycle rather than an occasional task. CMS’s own billing and coding guidance for PHP is explicit that the medical record has to fully support medical necessity for every service included, not just a general sense that the patient needed a higher level of care.

Level-of-care denials show up when a payer decides the documentation doesn’t support PHP intensity specifically, separate from whether the service itself was delivered. Partial attendance determination adds another wrinkle, since a day with reduced participation can affect whether that day is billable at all. And distinguishing program billing from individual service billing has to happen consistently, or claims start conflicting with each other inside the same treatment episode.

Not sure if your A/R is normal for a practice your size? Run it through the free Mental Health AR Benchmark.

What effective PHP program billing looks like

Reactive PHP billing (common) Proactive PHP billing (what protects revenue)
Authorization status discovered when a claim denies A live census and authorization dashboard tracking approved dates, remaining days, and next review date by patient
Documentation style varies by clinician Standardized PHP documentation, refined continuously based on what the billing team finds
Uncovered days found after the fact Uncovered or pending days automatically flagged
Payer rules held informally, checked claim by claim A payer-specific PHP matrix built as the actual rule base and integrated into daily workflow
Attendance and billing tracked in separate systems that never get reconciled Attendance reconciled directly against billing, even though pulling that data across systems is genuinely hard

A dashboard like this needs to show at-risk revenue by payer and level of care, not just administrative status. Once that foundation exists, a practice can eventually start measuring actual payer profitability from real supporting data, rather than assuming every contract is worth the same amount of effort to maintain.

Why this work needs full RCM expertise, not just a biller

Providers running PHP programs carry a version of this burden that has nothing to do with claims directly. Utilization management can turn into a full-time job on its own, and it can start to feel like the insurer, not the clinical team, is the one deciding how long a patient actually stays. Some practices end up with staff whose entire role is justifying continued care, and certain payer contracts create enough administrative burden that providers genuinely question whether the relationship is worth keeping.

Both sides of this problem call for real expertise, not someone who can simply “handle billing.” The right level of support covers the entire revenue cycle, end to end, including which payers are actually worth pursuing, what standard of continued-stay documentation consistently satisfies a given payer, and how to free up meaningful staff time that would otherwise go entirely to utilization review and justifying care that’s already been delivered.

The cost of getting PHP billing mental health wrong

Acting without that expertise shows up as a specific, repeatable pattern. Staffing keeps growing to manage the workload while cash sits tied up or gets lost outright. Unauthorized or missed-authorization days accumulate quietly into significant write-offs that rarely get traced back to a single fixable cause. Appeal work can balloon from there, with staff forced to reconstruct treatment rationale and rebuild support for denied days after the fact, pulling attention away from the higher-priority work that actually protects revenue going forward.

The right first step is understanding your current workflow and finding the actual gaps, since upstream issues need to be fixed before anything downstream gets better. Denial and A/R work itself can be used to uncover exactly where those upstream problems live, which is proactive billing in practice, not just a phrase.

Getting it right

Billing for a PHP program has to be treated as full revenue cycle management, not a standalone task anyone can pick up quickly, or it has to come with a real investment in training a team properly. Either path takes real commitment, but the alternative is a slow, recurring drain that never quite shows up as one obvious problem.

Wondering how your current PHP billing process would hold up against a real authorization and documentation review? Schedule a brief call and we’ll walk through where your program’s revenue is most likely at risk.

Wondering how much your claims are actually leaving on the table? Schedule a brief call for a free billing performance audit, and we will walk through your denials, A/R and credentialing status with you and show you exactly where your practice is losing money.