All addiction-treatment program guides
Software for the PHP day you already staff
Your PHP has a defined schedule, documentation process, attendance record, and billing workflow. Test whether software can represent the day you actually run—including late arrivals, missed sessions, and corrections—not merely display appointments.
What to know
A PHP day combines the group schedule with each participant’s attendance, documentation, and billable services. A late arrival or corrected note needs a clear path through those records. At Sunwave, our EMR connects clinical, administrative, and financial workflows. This guide explains how to map your PHP day so the schedule, participant record, and billing setup reflect the work your team actually does.
Test PHP separately from IOP and residential
Consider a hypothetical Tuesday: one participant arrives after the first group, another leaves before the final session, and a clinician corrects documentation after the roster is reviewed. The questions are which services require documentation for each person, how actual attendance changes recorded service time, and whether billing receives the corrected record. Clinical and billing reviewers should confirm the note, signature, time, authorization, and coding requirements for each service and payer because they can depend on program policy, payer rules, license, and jurisdiction. Run the same scenario through the proposed PHP, IOP, and residential configurations to see whether the system preserves any schedule, census, documentation, and billing differences defined by your organization and applicable requirements.
For substance use disorder care, The ASAM Criteria describes levels of care in terms that include setting, staffing, service intensity, and other core elements. It also describes regular reassessment and the use of transition and continued-service criteria when considering less intensive, more intensive, or continued care. Those criteria do not replace the current requirements of your program, payers, licenses, and jurisdiction. Configure and test the system against the services you actually provide rather than a generic outpatient template.
What that day needs from the EMR
The day’s curriculum in one place
Represent the mix your program actually runs—for example, a morning group, skills block, and individual sessions—without treating that example as a universal PHP curriculum. Staff should be able to preview a future day and see how schedule changes affect assignments and participant records.
Attendance that survives a late arrival
When one person misses the first hour or leaves before the last group, test whether the individual record and roster remain reconcilable with documented service time and, where attendance affects billing under the applicable rules, the resulting charge or claim units.
Documentation matched to the service
Test whether common session details can be reused without overwriting participant-specific facts. Ask clinical and billing reviewers to inspect the resulting records for full attendance, partial attendance, and a later correction. The required note type and frequency should come from the service, payer, program policy, license, and jurisdiction—not a generic daily-note setting.
Hours that match the claim
For each service and payer, map scheduled time, actual attendance, documented service, authorization, charge, and claim unit. In a test record, change a late arrival or early departure after documentation begins, then inspect the downstream charge, claim, exception handling, and audit trail. Billing reviewers should determine whether the resulting mapping follows the organization’s current rules.
The step-down and the step-up
Using a synthetic transition, specify which plan, assessment, authorization, effective-date, and status fields should carry forward and which should remain tied to the prior episode or level of care. Confirm that the receiving team can find the transition rationale and the source of carried-forward information without overwriting the earlier record.
The report the day-program lead already runs
Choose the report used by the day-program lead and define its reporting period, attendance rules, and included services. Reconcile a synthetic day against its roster, documented hours, and corrections. If the report combines several sources, record how those sources are matched and when each was last updated.
Connecting your PHP day in Sunwave
Our EMR includes individual and group scheduling alongside clinical documentation. Our revenue-cycle tools support claim generation from census and attendance data. Your schedule, documentation rules, and payer setup determine how those tools should be configured. A useful planning example is a participant who arrives late and later needs a documentation correction: identify the changes needed in the roster, patient record, charge, and claim.
Confirm which capabilities are included in the proposed package and configuration, who can make each correction, and where its audit trail appears. Assign operations, clinical, and billing owners to compare the demonstration with the program’s schedule, documentation, authorization, coding, and claim rules. If a system produces a level-of-care prompt or recommendation, treat it as an input to the organization’s clinical process—not as proof that a transition is clinically appropriate or covered by a payer.
What to bring to a PHP workflow demonstration
Build a synthetic test packet
Prepare a synthetic Tuesday roster with the program’s usual session types, staff assignments, and operating times. Add a late arrival, an early departure, a missed group, and a correction made after initial documentation. Include the note templates and signature rules to be tested, a sample authorization and payer mapping, the expected charge or claim output, the report used by the day-program lead, and a role matrix showing who should be able to view, enter, correct, approve, and bill each item.
Trace the correction from source to claim
Enter the schedule and attendance, create the required documentation, and inspect the resulting authorization use, charge, claim, and report. Then correct the arrival time or documentation and repeat the inspection. Record which downstream items update automatically, which become exceptions, which require approval, whether prior values remain visible, and how users are notified. Compare the result with the organization’s defined rules rather than assuming that a generic outpatient workflow is sufficient.
Test one system across levels of care
A separate vendor is not automatically necessary, and a single platform is not automatically preferable. Run the same synthetic record through the proposed PHP, IOP, and residential configurations to see whether the system preserves any schedule, census, documentation, authorization, billing, permission, and reporting differences defined by your organization and applicable requirements. Follow a residential discharge through PHP admission and a later IOP transition; note what carries forward, what remains level-specific, how effective dates are handled, and where staff must reconcile data between systems. Use those results to compare a single-platform design with a multi-system design.
Turn the demonstration into acceptance criteria
For every tested step, record the expected result, actual result, responsible role, required configuration, unresolved dependency, and evidence location. Distinguish included functionality from custom configuration, integration work, manual procedure, and roadmap statements. That record gives implementation and contracting teams a specific basis for resolving gaps without treating a polished demonstration as proof that the deployed workflow will behave the same way.
Sources and current product pages
Bring us your PHP schedule
Share a typical day’s schedule, the services you bill, and the corrections that create the most rework. We can focus your demonstration on those handoffs and the setup your PHP requires.