PHP billing codes: the practical hub

In this article▾

1. What this post covers
2. PHP billing basics at a glance
3. What is PHP in billing terms?
4. Which PHP billing codes matter most?
5. How should you bill PHP on UB-04 vs CMS-1500?
6. How is PHP different from IOP and inpatient for billing?
7. What documentation and medical necessity do you need for PHP?
8. What are the top PHP denial reasons and fixes?
9. What this post does NOT cover
10. How can AI help work these claims?
11. Common pitfalls: quick do-not list
12. FAQ: PHP billing

Your first clue that PHP is different is usually a remit: a whole week of PHP days denied for "not meeting partial hospitalization criteria" or "incorrect code for plan benefits."
Partial hospitalization is a high-intensity outpatient day program that sits between IOP and inpatient, and payers treat it like a high-dollar, high-scrutiny benefit. When you get the coding or medical necessity story wrong, denials stack fast.

What this post covers

• How PHP compares to IOP and inpatient, from a billing lens, and which PHP codes matter most
• How to bill PHP correctly on the UB-04 and CMS-1500, including revenue codes
• What PHP documentation and medical necessity look like when auditors read your charts
• The main PHP denial patterns, fixes, and how AI agents can take on the grunt work

---

PHP billing basics at a glance

Treat PHP as a structured, daily level of care with its own codes, revenue lines, and rules.

Here is the quick PHP billing snapshot.

If you treat PHP like "a long IOP day" operationally or in documentation, PHP billing will not hold up.

---

What is PHP in billing terms?

Think of partial hospitalization as a high-intensity day program: more than IOP, less than inpatient, still outpatient for billing.

Clinically, PHP usually means:

• Clinical intent: Patient needs daily, structured, multidisciplinary treatment, but can safely sleep at home.
• Time: Typically about 5 or more hours per day of therapeutic services. Some payers specify a minimum like 4, 5, or 6. The exact threshold lives in the payer policy and your auth letter.
• Placement: Commonly and plausibly mapped to ASAM 2.5 for SUD or psychiatric PHP, but the mapping is set by the payer or state fee schedule, not the code, so verify per payer.

From the billing side, PHP tends to have tight, rule-driven requirements.

• All-inclusive per diem: Facility billing with a bundled daily HCPCS most days.
• Prior authorization: UR must match level-of-care criteria and keep concurrent reviews moving.
• Daily tracking: Attendance, hours, and core services must be tracked and defensible.

If your center runs both IOP and PHP, assume payers will scrutinize PHP medical necessity the hardest and will expect a clear "in-between inpatient and IOP" story every day.

---

Which PHP billing codes matter most?

You do not need a huge codebook for PHP. You need to know which per diem your payer wants and how they classify your program.

Core PHP per diem codes

These are the main per diem codes you will see for PHP-level care.

H0035 - mental health PHP per diem

Plain language, this is the daily bundled code for mental health partial hospitalization.

• Code: H0035, "Mental health partial hospitalization treatment, per diem"
• Used for:
  • Psychiatric PHP in a hospital or free-standing behavioral health facility
  • Often paired with revenue code 0913 on UB-04
• Typically includes (varies by payer and contract):
  • Group therapy
  • Individual therapy
  • Family sessions
  • Some assessment and treatment planning
  • In some plans H0035 is "all-inclusive," in others professionals still bill separately

If your payer policy or auth says H0035 and you bill something else, expect denials or reprocessing.

S0201 - general PHP per diem

Some payers anchor their PHP policy on S0201 instead of H0035.

• Code: S0201, "Partial hospitalization services, per diem"
• Used for:
  • PHP in certain commercial plans with their own per diem definition
  • Situations where the plan wants a single PHP code for both MH and SUD
• Key nuances:
  • Many payer policies treat S0201 and H0035 as mutually exclusive options. Use the one listed in the authorization and in the plan’s PHP policy.
  • Published rates for S0201 are thin, and many state Medicaid FFS programs use H0035 for PHP instead, so you must verify both recognition and rate against the plan’s fee schedule.

If your auth is for S0201 and you drop H0035, the remit will reflect that mismatch.

H2036 - SUD PHP and SUD day treatment per diems

For SUD PHP-level care, many payers do not label it "PHP" in the policy but treat it as a high-intensity day program.

• Common code: H2036, "Alcohol and/or other drug treatment program, per diem"
• Used for:
  • SUD day treatment or SUD PHP-level care
  • Sometimes mapped to the same benefit bucket as MH PHP
• Variations:
  • Some payers use alternative HCPCS or local codes for SUD PHP-level programs
  • Medicaid plans can be very state specific, so check manuals and state fee schedules

You can get a deeper SUD-specific view here:
H2036 SUD per diem guide.

Build a payer-by-payer PHP code matrix

For every PHP program, you should have an internal reference that lists:

• Policy description: The level-of-care name in that payer’s policy.
• HCPCS per diem: H0035, S0201, H2036, or a plan-specific code they require.
• Diagnostic carveouts: Whether SUD and psychiatric PHP use different codes or benefits.
• Revenue codes: Which revenue code pairs with which PHP code per payer.

If you do not have this matrix and staff are guessing, your denial rate will make that obvious.

---

How should you bill PHP on UB-04 vs CMS-1500?

Separate the facility per diem billing from individual professional billing. Many organizations do both and need clean rules for each.

PHP facility billing on UB-04

For PHP days, you are usually sending one all-inclusive line per day on the UB-04 that meets the PHP hour requirement.

Core building blocks for PHP on UB-04:

• Claim form:

  • UB-04 for institutional billing
  • Billing entity is the facility or program, not individual clinicians

• Revenue code:

  • 0913: Partial Hospitalization - Intensive, commonly used for a full psychiatric PHP day
  • 0912: Partial Hospitalization - Less Intensive, sometimes used by payers for a lower-intensity PHP day, often defined as 3 or fewer services per day
  • Other BH revenue codes: For SUD PHP-level programs, many payers use other 090x behavioral health revenue codes, which you must confirm per plan

• HCPCS per diem code:

  • H0035, S0201, H2036, or other plan-specific per diem assigned to PHP
  • Units: Usually "1" per date of service that meets the PHP hourly threshold

• Charge description:

  • Clearly labeled in your charge master as "PHP per diem"
  • Distinguish mental health versus SUD where needed
  • Do not reuse IOP descriptions or service definitions for PHP

• Bill type:

  • Often 013x or 083x, depending on facility type and payer rules
  • Confirm required bill type in payer contracts and manuals

Sample UB-04 PHP line (simplified) for a single PHP day when the plan requires H0035 and 0913:

• Revenue code: 0913
• HCPCS / HIPPS: H0035
• Service units: 1
• From date: 09/01/2026
• Through date: 09/01/2026
• Total charges: Your PHP per diem charge
• Serv. date: 09/01/2026

If you are still billing PHP days as separate group therapy and 908xx lines on UB-04, that is usually a signal the payer will not pay as intended.

PHP professional billing on CMS-1500

On the clinician side, psychiatrists, NPs, psychologists, and therapists may bill professional services depending on how the payer treats PHP.

There are two typical models.

• Facility primary, professional carved out:

  • Facility bills H0035 / S0201 per diem on UB-04.
  • Individual clinicians bill E/M and psychotherapy CPT / HCPCS on CMS-1500.
  • Payers pay both facility and professional, often at office-rate levels or a specific PHP setting rate.

• Facility all-inclusive only:

  • Facility per diem is intended to cover all PHP services.
  • Payer treats psychiatrist and therapist work as bundled into the PHP rate.
  • Professional claims deny as "included in facility payment."

To avoid double billing or unpaid work:

• Confirm policy: Read the PHP section of each payer’s facility and professional policies.
• Check auth: Many auth letters say explicitly "all-inclusive facility authorization."
• Standardize per program: Decide by payer and program whether professionals bill separately and enforce one pattern.

If professionals do bill:

• Claim form: CMS-1500
• Place of service: Often 52 (psychiatric facility partial hospitalization) or a payer-specified code
• Common CPT: 90791 / 90792, 90832 / 90834 / 90837, 99231-99233 and related E/M, all tied to the PHP location

You want every clinician in the PHP program following the same rules so you do not have one therapist billing like office visits and another billing nothing for identical days.

---

How is PHP different from IOP and inpatient for billing?

Payers care less about your marketing labels and more about clear operational differences between PHP, IOP, and inpatient.

The core billing differences center on:

• Hours and structure per day
• Risk level and rationale for choosing PHP
• Setting and revenue code mix

PHP vs IOP at a glance

You can hand this table to a new biller or UR nurse and it will cover most of the differences.

You can go deeper on IOP specifics here:
IOP billing codes guide.

PHP vs inpatient

Billing-wise, PHP and inpatient differ on three main axes.

• Setting and revenue structure:

  • Inpatient uses inpatient bill types and inpatient psychiatric or detox revenue codes.
  • PHP uses outpatient bill types and PHP or psych revenue codes under outpatient or behavioral health benefits.

• Hours and supervision:

  • Inpatient: 24-hour nursing, beds, overnight stay.
  • PHP: No overnight stay, but structured daily programming with frequent psychiatric involvement.

• Medical necessity logic:

  • Documentation for PHP must show why 24-hour supervision is no longer needed or not yet needed, and why lower levels like IOP or routine outpatient are not enough.
  • Payers explicitly use this "in between" position to approve or deny PHP.

If your UR notes read like "patient is doing well, stable, and just attending groups," it will be hard to defend PHP over IOP.

---

What documentation and medical necessity do you need for PHP?

Think in two buckets: program-level artifacts and date-of-service documentation. You need both to survive audits and concurrent review.

Program-level documentation

Program-level artifacts explain what your PHP is, who it serves, and how it runs.

You should have clean, current documentation for each PHP program that covers:

• Program description:

  • Target population and diagnoses.
  • Clinical goals and target outcomes.
  • Required services per day, such as groups, individual, psychiatry, nursing.
  • Staffing model and disciplines involved.

• Schedule and structure:

  • Hour-by-hour daily calendar.
  • Which groups are required and which are optional.
  • Minimum hours required to count as a PHP day.

• Admission criteria:

  • Tied to ASAM or psychiatric level-of-care criteria where applicable.
  • Clear threshold that patient has failed or would likely fail IOP or OP.
  • Risk and symptom profiles that justify PHP instead of lower levels.

• Discharge and step-up criteria:

  • What "step down to IOP" looks like in practice.
  • What triggers a "step up to inpatient" transfer.

If UR staff are improvising criteria on the phone because none of this is documented, payers will control concurrent review.

Date-of-service level documentation

This is where each billed PHP day lives or dies. Every billed PHP date should have:

• Attendance and time in / out:

  • Actual start and end times for the day.
  • Clear evidence that required daily hours were met.
  • Notes if patient left early, arrived late, or skipped a required group.

• Group notes with patient-specific content:

  • Group topic, modality, and objectives.
  • Patient-specific participation and response, not copy-paste macros.
  • Tie-ins to treatment plan goals and current symptoms.

• Individual and family sessions:

  • Normal, complete documentation even if the service is included in the per diem.
  • Separate, defensible documentation if billed separately as a professional service.

• Psychiatric or medical oversight:

  • Evidence of daily psychiatric availability, and visits as clinically appropriate.
  • Med management and safety monitoring documented at the right frequency.

• Risk and safety monitoring:

  • Routine suicide, homicide, and substance use check-ins noted.
  • Any crisis or decompensation addressed with specific interventions.

• Ongoing medical necessity narrative:
  A UR or daily progress note that answers:

  • Why PHP was required today rather than IOP or OP.
  • What would likely have happened without PHP that day.
  • What barriers remain to step-down or discharge.

When PHP days get denied for medical necessity, denial letters often quote your own "stable, no issues" notes repeated over days. That is the pattern you need to break.

---

What are the top PHP denial reasons and fixes?

PHP denials follow a few predictable patterns. You want to fix the patterns upstream, not fight every denial one by one.

Common PHP denials and fixes

A few focused process changes will remove most of these denials before they show up on remits.

Upstream fixes that move the needle

Put more effort into rules and less into appeals.

• Make PHP-specific VoB standard:
  Do not stop at "behavioral health outpatient covered." Ask "Is partial hospitalization covered at our facility type, and which codes and revenue codes are recognized."

• Turn payer policies into system rules:
  For each PHP payer policy, build rules in your EMR and claim scrubber: required PHP code, revenue code, auth flag, minimum hours, documentation expectations.

• Create a UR playbook by payer:
  Document which criteria set they use, how often they require updates, and how they want to receive clinical notes.

• Give clinicians PHP note examples:
  Provide sample language that clearly justifies PHP level without exaggeration and lines up with the payer’s criteria language.

If your documentation and billing rules look like the payer’s own policy, UR and appeals both get easier.

---

What this post does NOT cover

This is a high-level PHP hub. For deeper, code-specific or level-specific topics, see:

• IOP and day treatment specifics: IOP billing codes hub
• H2036 details for SUD day programs: H2036 billing guide
• Detailed denial language patterns: behavioral health denial glossary

Use those when you are troubleshooting narrower questions that this hub only touches.

---

How can AI help work these claims?

PHP billing is repetitive, rule-heavy, and full of small, expensive errors, which makes it a strong fit for AI agents. The goal is not to replace your billers, it is to offload the grunt work so humans focus on edge cases and medical necessity.

Platforms like Supa’s Supabill are already doing this in real revenue cycle teams.

Use AI to eliminate repetitive PHP grunt work

PHP has lots of binary rules: which PHP code for which payer, required revenue code, hour minimums, auth rules.

Agents in a system like Supabill can:

• Run PHP-specific VoB: Log into portals, confirm if PHP is covered at your facility type, which HCPCS codes and revenue codes the plan recognizes, and capture limits and auth rules into your PM or EMR.
• Compare auth letters to your code matrix: If a payer issues S0201 for PHP but the program is set to H0035, the agent flags the conflict before claims go out.
• Scrub PHP claims pre-submission: Check bill type, revenue code, per diem code, units, and auth dates so nearly all PHP claims go out clean on the first pass.

Your billers stop hunting for codes in PDFs and instead review only the exceptions AI cannot resolve.

Use AI and voice agents so staff do not sit on hold

Checking PHP coverage, days used, or odd policy details often means calling payers or wrestling with dated portals. That is a poor use of clinician or biller time.

You can route that work to AI:

• VoB and auth-check agents: Hit payer portals or IVRs to verify PHP coverage, prior auth requirements, and remaining days, then store that data directly in your system.
• Voice agents for payer calls: In a Supa setup, a voice agent can call the payer, work through menus, talk to a rep, and log all details in structured form. Reps usually just experience it as a very prepared caller.

Your UR and billing staff get clean, current data on PHP benefits and auths without the hours of hold music.

Use AI to prevent PHP errors at scale

Most PHP denials come from small misses that humans are too busy to catch every time.

Agents can:

• Cross-check PHP hour requirements before charging: Compare attendance and group hours against payer hour minimums and block a PHP per diem if the threshold is not met, or suggest an IOP code where policy allows.
• Match plans to product rules: Automatically select H0035 vs S0201 vs H2036 based on payer and product rules, so front-end staff are not guessing.
• Run denial analytics: Identify patterns like "Plan X is denying PHP when psychiatric contact is less frequent than weekly" so you can adjust care and documentation.

In practice, teams using Supabill often let agents handle roughly 80 to 90 percent of day-to-day billing tasks, including PHP. Human billers and UR staff then spend their time on:

• Hard medical necessity denials and complex appeals
• New payer products and contracts that do not fit existing rules
• Working with clinical leaders when denials point to documentation or care-model gaps

If AI handles the repeatable PHP rules, your staff can protect the dollars that really require judgment.

---

Common pitfalls: quick do-not list

Use this as a PHP "never do" checklist for new staff.

Do not:

• Assume PHP is covered just because "behavioral health outpatient" is covered on VoB.
• Use the same PHP code across all payers without checking policies and auth letters.
• Bill the PHP per diem on days when the patient did not meet minimum hours or required services.
• Let clinicians document "stable, no issues" day after day and expect UR to keep PHP approved.
• Treat PHP and IOP as interchangeable when scheduling, documenting, or building programs.
• Bill professional services separately when the plan clearly treats PHP as all-inclusive.
• Ignore concurrent review or additional information requests for PHP. Those days are easy for payers to deny retroactively.

Clean PHP rules and documentation guardrails are cheaper than fighting audits.

---

FAQ: PHP billing

1. What is the minimum number of hours for a PHP day?

It depends on payer policy. Many require about 5 or more hours of therapeutic services per day, not counting lunch or long breaks. Some specify 4 or 6.

You will find the real threshold in:

• The payer’s PHP policy
• Your contract, if it is customized
• Sometimes the authorization letter

Build that minimum into scheduling and EMR rules so staff are not guessing.

2. Can I bill PHP if the patient only attends half the day?

Usually not. If the patient does not meet the minimum hours or core service requirements, many payers will:

• Deny the per diem as "criteria not met"
• Or expect you to bill a lower level like IOP or standard outpatient, if their policy allows that substitution

You need a clear internal rule for short days: when to bill at a lower level, when to not bill at all, and how staff should handle those situations.

3. Should I use H0035 or S0201 for PHP?

Use whichever code the payer’s policy and authorization specify.

Common patterns:

• Some commercial plans only recognize S0201 for PHP.
• Others follow H0035 for mental health PHP.
• SUD PHP may be mapped to H2036 or another per diem.

Create a payer-specific table and hard-code it into your billing system so staff are not picking codes from memory.

4. How do I know if PHP is all-inclusive or if professionals can bill separately?

Check all three:

1. The payer’s facility policy for partial hospitalization
2. The professional policy section about "services in facility-based programs"
3. The EOBs from early or test claims, to see if professional claims deny as "included"

If policies are vague, your provider rep is the next stop. Whatever you learn, document it in your billing rules so every psychiatrist and therapist in the PHP program follows the same pattern.

5. What revenue code should I use for PHP?

For psychiatric PHP, many payers expect:

• 0913, Partial Hospitalization - Intensive, which is the level commonly used for psychiatric PHP

Officially, 0912 is Partial Hospitalization - Less Intensive, defined as 3 or fewer services per day, and some payers blend 0912 and 0913 for PHP-like services. For SUD day programs, payers can require different behavioral health revenue codes.

Confirm the correct revenue codes in:

• Payer manuals
• Medicaid state guidance
• Contract language

Then lock the right revenue code into your charge master for each PHP program so staff cannot pick the wrong one.

6. Can I bill PHP and IOP on the same day for the same patient?

Usually no. Most plans treat PHP and IOP as mutually exclusive levels of care on the same date.

Typical logic:

• If PHP criteria are met, the day is PHP.
• If PHP is not met but IOP criteria are, the day is IOP.
• Billing both levels on the same date usually gets one or both denied and raises audit risk.

If your clinical model is truly hybrid, you need explicit payer clarification and preferably something in writing.

7. How often do I need psychiatric visits in PHP?

Payer expectations vary, but PHP is generally seen as medically or psychiatrically driven.

That usually means:

• A psychiatric evaluation at admission
• Regular follow-up, often at least weekly in higher-intensity programs
• Clear availability for medication changes and crisis intervention

Your documentation should show enough psychiatric involvement to distinguish PHP from IOP, especially in utilization management reviews.

8. My PHP days are getting denied as "could be treated at lower level of care." What should I change?

Start by reviewing:

• Admission criteria and how they are documented in the record
• UR notes for the first few days
• Daily progress notes, especially around risk, function, and response to treatment

You likely need:

• Clearer language on why IOP or OP is not adequate
• Stronger symptom and impairment descriptions, not just "attended group"
• A proactive UR script that walks the reviewer through level-of-care criteria

Appeals should quote the payer’s own policy point by point and show how your documentation meets those standards.

9. Can I use telehealth for PHP?

Tele-PHP rules changed during COVID and have continued to shift. Current rules vary widely by payer.

Common scenarios:

• Some plans allow partial or full tele-PHP with strict documentation and technology requirements.
• Others have reverted to requiring in-person presence for PHP.

You must check:

• Payer telehealth policies
• PHP-specific sections and updates
• Any temporary guidance that has expired or been made permanent

Do not assume tele-PHP is covered just because tele-IOP or individual teletherapy is.

10. Do I need a new auth when a patient steps down from inpatient to PHP?

Often yes. Even with the same payer and facility, plans typically issue separate auths.

Typical pattern:

• One authorization for the inpatient admission
• A separate authorization for PHP, with its own number and date span

UR should start the PHP auth process as soon as a step-down is being discussed, not on discharge day.

11. How are PHP rates usually set compared to IOP?

Rates are contract specific, but in general:

• PHP per diem rates tend to be higher than IOP rates because they represent more intensive daily care.
• Some contracts peg PHP as a percentage of inpatient per diem or as a fixed unit price.

To know your real differential:

• Pull contracts and remits for PHP and IOP.
• Confirm whether your census and staffing make PHP sustainable at those rates.

For a real reference point on the MH PHP per diem (H0035): published Medicaid figures run roughly $140 to $271 per day. Montana Medicaid FFS pays $140.48 for a half day and $187.51 for a full day (2024), and UnitedHealthcare Community Plan of Colorado pays $271.21 (2024 to 2025). These are real published examples that vary by state, program, and year, so confirm against your own fee schedule.
Source: https://medicaidprovider.mt.gov/docs/feeschedules/2024/AdultMHeffective07012024Final.pdf

12. Can I bill PHP for weekends?

From a billing perspective, yes, if all the rules are met.

You need:

• A real PHP program that runs on weekends
• Patients who meet the same hour and service requirements on those days
• No payer policy that explicitly limits PHP to weekdays only

In practice, clinical operations and staffing are usually the limiter, not billing rules. Always check contracts and manuals for "maximum days per week" language.

13. How long can a patient stay in PHP before payers push back?

There is no universal maximum. Payers focus on:

• Clinical progression and symptom change
• Risk level over time
• Functional gains
• Step-down or discharge planning

Some have internal expectations for average length of stay, but they rarely publish them.

Your best defense is:

• UR notes that show why PHP remains necessary at each review point
• A credible, evolving step-down plan with target dates
• Avoiding documentation that sounds like "day care" once acute issues are resolved

14. What should I audit first if my PHP denial rate is high?

Start with three fast internal audits.

1. Code-to-auth alignment:
   For your top 5 payers, pull a sample of recent PHP cases and compare the code on the auth letter to the HCPCS on the UB-04.

2. Hours and attendance:
   Take a random week of PHP census and verify that every billed PHP day meets the hour and service threshold from payer policy.

3. Medical necessity language:
   Compare the first 3 days of notes for denied vs paid cases. Patterns in risk description, function, and response to treatment will usually be obvious.

Fixes from these three audits will recover more dollars than chasing rare edge cases.

15. Do all payers follow ASAM 2.5 for SUD PHP?

No. Many use ASAM for SUD, but there is real variation.

• Some commercial plans use ASAM plus their own modifications.
• Medicaid plans may use state-specific level-of-care guidelines instead of or in addition to ASAM.

UR staff should know, for each payer:

• Which criteria set applies
• Where to find it
• How to map your documentation and scripting to that language

Do not assume "ASAM 2.5" means the same thing across payers in real-world UM reviews.

---

If you want to see what it looks like when agents handle most of this work and your team sticks to the hard problems, you can book a live demo here.