Partial Hospitalization Program (PHP)

What a Partial Hospitalization Program is

Partial Hospitalization Program (PHP) is a high-intensity outpatient behavioral health service for patients who need more structure and monitoring than traditional outpatient therapy, but who do not require 24-hour inpatient care. Care is typically delivered in a hospital outpatient department, psychiatric facility, or community mental health center, and includes a combination of group therapy, individual therapy, medication management, and other therapeutic services.

Clinically, PHP is commonly mapped to ASAM Level 2.5 for substance use services and to an equivalent intensive level for mental health. Patients attend for multiple hours per day on multiple days per week, then return home at night. Many payers use PHP as a step-down from inpatient or as an alternative to admission when risk can be managed without an overnight stay.

Why PHP matters operationally in RCM

Operationally, PHP is where inpatient-style utilization management meets outpatient-style billing. Stays are often weeks long, services are delivered almost daily, and payers frequently require both prior authorization and ongoing concurrent review. That creates continuous denial risk: one missed update or expired auth date can turn an otherwise clean claim into a CO-197 or N130 denial.

Most health plans treat PHP on a per-diem or bundled basis, so each service day can represent hundreds or thousands of dollars. A single unbilled or denied PHP day has a much larger revenue impact than a missed 45-minute therapy visit. On top of that, many plans cap PHP at a certain number of days or hours per year, which can trigger CO-50 or CO-97 denials late in the episode if benefit tracking is weak.

PHP also distorts your standard outpatient metrics. Episodes are long, charges accrue daily, and the use of per-diem or bundled codes makes it harder to tie individual services to individual payments. Days in AR, denial rate, and net collections can all look worse or better than reality if PHP is not segmented and analyzed separately.

How PHP is billed and read on claims

Billing structures for PHP depend on setting and payer policy. Hospital-based PHP is typically billed on a UB-04 with specific revenue codes for psychiatric partial hospitalization, commonly 0912 and 0913, combined with appropriate HCPCS or CPT codes for the services included in the day. Community and free-standing behavioral health programs are often instructed by Medicaid and commercial plans to bill PHP as a per-diem HCPCS code, such as H0035 for mental health partial hospitalization, with one unit per covered treatment day.

Place of Service (POS) codes matter. Many payers expect POS 52 (Psychiatric facility partial hospitalization) or POS 53 (Community mental health center) for professional claims tied to PHP services, while hospital outpatient PHP services may use the hospital outpatient POS codes under the facility NPI. Using an office POS can trigger CO-16 or CO-96 denials when the payer sees a PHP code that does not match the expected setting.

Most payers treat PHP as an in-person service, although some temporarily allowed virtual PHP during public health emergencies. Policies differ on whether therapy and medication management within PHP can also be billed separately on the same day, or whether those services are considered included in the per diem and denied as CO-97 if billed in addition. For RCM, the key is knowing, by payer and plan, which codes, rev codes, and POS combinations are valid and which will auto deny, then building edits so those rules are enforced before submission.

• Billing PHP per diem (for example H0035 or a 0912 revenue-code day) under an office Place of Service instead of POS 52 or 53, which leads to CO-16 or CO-96 denials because the payer sees a mismatch between the setting and the intensity of service.
• Letting a concurrent authorization expire mid-episode and continuing to bill daily PHP units, so the first part of the stay pays but all units after the auth end date deny as CO-197 or N130. These are avoidable write offs if no one is tracking auth-through dates by patient and level of care.
• Billing both a PHP per diem and separate psychotherapy or medication management codes on the same date of service for the same patient and provider when the payer considers those services bundled, which results in CO-97 or CO-50 denials on the carve out codes and wasted charge-entry time.
• Using the same service code and units for all payers without checking plan-specific PHP definitions, for example billing H0035 with 1 unit for a short day where the Medicaid contract requires a minimum block of hours and a different code for half days. Claims may pay inconsistently or be later recouped in audit.
• Failing to separate PHP from traditional outpatient services in AR and denial reporting, so a few high-dollar PHP write offs from one Medicaid MCO mask a pattern that is adding weeks to Days in AR and quietly costing thousands per month.

PHP is fundamentally a behavioral health level of care, and payers often carve it out to specialized behavioral health administrators. That means benefit rules, authorization criteria, and billing requirements for PHP can be completely different from the medical benefits administered by the main health plan. If your team only checks eligibility on the medical card, you can easily miss that PHP is covered, or not covered, under a separate behavioral vendor.

State Medicaid and Medicaid Managed Care plans tend to have highly specific PHP codes, limits, and medical necessity criteria. Some states carve PHP into the behavioral benefit with its own fee schedule and day limits, while others manage it through waiver programs or specialty plans. Payers may require an ASAM 2.5 or equivalent level-of-care assessment in the record, along with daily group documentation and active psychiatric involvement, to justify PHP-level intensity.

PHP also involves long episodes and per-diem billing, which raises audit and recoupment risk. If documentation does not support the billed PHP day for a given date of service for example, insufficient hours of therapeutic activity, missing signatures, or no clear evidence of active treatment a payer can retroactively deny weeks of care. For substance use PHP, misalignment between ASAM criteria and the documented clinical picture is a common point of contention in appeals and audits.

Because PHP is often the pivot point between inpatient, residential, and IOP, authorization rules can get tangled. A payer might require discharge from inpatient straight into PHP to approve certain codes, or might cap the total combined days of PHP and IOP per year. Without clear BH-specific workflows, treatment centers end up with preventable CO-50 and CO-97 denials when patients cross internal program boundaries.

AI can help with Partial Hospitalization Program operations by handling the repetitive, rules-heavy work that makes PHP revenue so fragile. An AI agent can read eligibility and benefits data, identify whether PHP is carved out to a behavioral vendor, surface visit limits and level-of-care rules, and flag when a patient is approaching day caps or session limits. The same agent can store payer-specific PHP rules like valid POS combinations, acceptable rev codes, and whether separate therapy codes are allowed on PHP days, then apply those rules as edits before claims go out.

Supabill uses specialized agents to support this workflow. A benefits-verification agent can scan payer portals and 270/271 responses for PHP coverage specifics and carve-out indicators, then push that data into your intake and scheduling process so PHP is authorized correctly from day one. A claims-scrubbing agent that holds state-level and payer-level PHP rules can stop claims with invalid rev-code and POS combinations, missing active auth, or code combinations that are known to trigger CO-97 or CO-50. A denials agent can ingest every 835, classify CO-197, N130, and CO-50 denials by payer and program, and show you exactly where PHP is bleeding. Humans still have to make clinical and contractual judgment calls for example, when to appeal a medical necessity denial or negotiate with a plan about PHP length of stay but the AI takes on the high-volume pattern recognition and rule enforcement so your team spends time where expertise matters.

How is a Partial Hospitalization Program different from Intensive Outpatient (IOP) from a billing and coverage perspective?

Clinically, PHP is a higher-intensity level of care than Intensive Outpatient, commonly mapped to ASAM Level 2.5 compared with IOP at Level 2.1, and payers usually reflect that difference in both reimbursement and authorization rules. PHP is often billed as a per-diem or bundled day using specific rev codes or HCPCS such as 0912, 0913, or H0035, while IOP is more likely to be paid either as a lower-intensity per diem or as a set of group and individual services. Many payers require stronger medical-necessity documentation and more frequent concurrent review for PHP, and may cap PHP days separately from IOP days. Because of this, mixing PHP and IOP rules in your system for example, using the same auth structure or codes will create denials and audit exposure. Source

Can PHP services be provided via telehealth and still be billed as PHP?

Policies on telehealth-based PHP vary widely by payer and have changed over time, especially around the COVID-19 public health emergency. Some payers temporarily allowed virtual PHP, often with specific modifiers and documentation requirements, while others required in-person attendance to bill PHP-level codes and instructed providers to bill telehealth services under standard outpatient therapy codes instead. For current policy you must check each payer's behavioral health and telehealth guidance, and your contracts, before billing PHP via telehealth. When in doubt, confirm with the payer whether virtual services meet their definition of PHP for coverage and billing purposes. Source

What documentation is usually required to support PHP medical necessity and avoid post-payment recoupments?

Payers expect PHP documentation to show that the patient needs a level of structure and monitoring that is clearly higher than traditional outpatient care, but does not require 24-hour inpatient treatment. That typically includes an admission psychiatric evaluation, level-of-care or ASAM assessment, an individualized treatment plan with measurable goals, daily progress or group notes that reflect active therapeutic intervention for multiple hours per treatment day, medication management documentation where applicable, and discharge or step-down planning. Missing or generic notes, unclear time spent in treatment, and weak risk documentation are frequent findings in audits that lead to large PHP take-backs. Many payer and CMS guidelines, as well as state Medicaid manuals, emphasize clear evidence of active intensive treatment rather than passive attendance. Source

Can a provider bill PHP and a separate outpatient therapy visit for the same patient on the same day?

Sometimes, but many plans consider all therapy and psychiatric services provided on a PHP day to be included in the PHP per diem and will deny separate psychotherapy or evaluation and management codes as CO-97. Some payers make limited exceptions, for example allowing a separate crisis visit or a medical-surgical E/M service if it is clearly unrelated to the PHP treatment episode and billed under a different taxonomy or NPI. The only safe path is to follow each payer's written policy or contract language about same-day billing with PHP. If you choose to bill same-day services, documentation must clearly distinguish the separate service from the PHP program, or you increase your denial and audit risk. Source

How do carve-outs affect PHP billing and payment for commercial plans?

For many employer and commercial health plans, PHP coverage is administered by a behavioral health carve-out vendor that is different from the medical plan on the front of the insurance card. That vendor may have a separate network, its own authorization process, and different billing rules and fee schedules for PHP. If your team only verifies eligibility with the medical carrier and sends PHP claims there, you can see a mix of CO-50, CO-109, or CO-197 denials that are really routing or benefit issues. Always confirm whether behavioral health, including PHP, is carved out during benefits verification and make sure your claims go to the correct behavioral vendor, not just the medical payer. Source

• CMS, Medicare Behavioral Health Services
• Medicaid.gov, Behavioral Health Services
• SAMHSA, Levels of Care and Treatment Settings