There is a quiet shift happening across the HCBS sector. State Medicaid agencies, pushed by the 2014 CMS HCBS Settings Rule, have been steadily moving provider agencies away from purely facility-based day services and toward something with a longer name and higher expectations: community integration.
In Louisiana it is called Community Life Engagement. Ohio and Texas call it Community Integration. Florida uses Community Inclusion. The billing codes differ by state. The documentation requirements, however, follow a consistent federal logic — and most agencies are not fully meeting them.
This is not a criticism. Community integration is genuinely harder to document than a 1:1 home visit or even a facility-based Day Habilitation session. The service happens at a library, a park, an employer's office, or a grocery store. The location changes session to session. Multiple clients may participate, each with different goals. And unlike a home visit, there is no physical address pre-registered in your system that anchors the record.
This guide is for agency directors and quality assurance staff who want to understand what compliant community integration documentation actually requires — and where most agencies fall short.
What the CMS Settings Rule Actually Says
The 2014 CMS HCBS Final Rule drew a sharp line between two categories of service settings:
Provider-operated facilities — a company-owned or leased day center. The client comes to you. This covers traditional Day Habilitation.
Community settings — the broader community: public spaces, employers, retail environments, recreational facilities. The client goes out into the world with DSP support. This is community integration.
The rule requires that community integration services actually take place in community settings — not in agency facilities dressed up with community-sounding names. More importantly, it requires that documentation demonstrates this. An auditor reviewing a CLE claim should be able to look at the record and see where the session happened, what was done there, and how it connected to the individual's goals.
A sign-in sheet and a general note that says "community outing" does not meet that standard.
The Five Documentation Requirements That Matter
1. Community Location — Specifically Where, Not Just "Community Outing"
Every community integration session must document the specific location or locations visited. This means a name and address — "East Baton Rouge Public Library, 7711 Goodwood Blvd" — not a category like "library" and not a vague description like "out in the community."
This matters for two reasons. First, auditors verify that services are happening in genuine community settings and not in your facility. Second, for states that bill community integration at different rates based on the type of setting (an employer site vs. a recreational setting, for example), the location type directly affects billing legitimacy.
One additional complication: a single community integration session often involves more than one stop. A DSP might take a client to a grocery store and then to a bank in the same session block. Both locations need to be documented, not just the first one.
2. Individual Goal Progress — Required, Not Optional
This is where most agencies are most exposed.
CMS policy classifies individual progress toward goals as a required daily documentation field for community integration sessions, not an optional add-on. A session note that documents location and activities but omits goal progress is technically incomplete — and in a Medicaid audit, an incomplete note is a non-billable note.
The practical implication: your DSPs need to know, at session time, what each client's active goals are. They need to record progress for each goal — achieved, partially met, not attempted, or refused. And if a client refused or was unable to work toward a goal, the reason should be captured.
This requires more than just telling DSPs to "track goals." It requires that goals are entered into the system before sessions begin, linked to the individual's schedule, and surfaced automatically when the DSP opens the session. If your DSPs are manually looking up goals from a paper support plan while managing four clients in a community setting, this step gets skipped.
3. Activities and Skills Practiced
Beyond goals, documentation should capture what specifically happened during the session. The CMS activity categories that tend to appear in state policy include:
- Volunteering and civic participation
- Adult education and vocational exploration
- Recreation and fitness
- Social clubs and community groups
- Travel training and transportation independence
- Daily living skills practiced in natural settings (grocery shopping, banking, meal preparation)
- Career exploration and supported employment activities
This is not a checklist to complete for its own sake. This data becomes the monthly aggregated record that demonstrates the breadth and quality of your community integration programming — which is increasingly what states use to evaluate provider quality.
4. Time In and Time Out
Standard across all Medicaid waiver services, but worth stating explicitly: community integration sessions require documented time in and time out for each client. For EVV-required services, this also means electronic verification tied to the actual community location, not your facility address.
5. Staff Signature and Supervisor Review
Daily documentation requires a DSP signature. Most agencies have this. What many are missing is the supervisor review layer.
CMS policy and most state CLE regulations include a requirement that supervisors review session notes — not every note the same day, but on a regular basis — and flag sessions with missing or incomplete documentation before billing is submitted. Agencies that skip this layer are submitting claims without a quality check, which is an audit risk regardless of how carefully their DSPs document.
The Monthly Aggregation Requirement
Individual session notes are the foundation. The structure built on top of them is the monthly summary, and it is not optional.
Most state CLE regulations require that agencies (or their software) aggregate session data over a billing period into a monthly summary that shows, per individual:
- Total sessions and attendance
- Community locations visited (unique locations and total visits)
- Activities completed, broken down by category
- Skills practiced and engagement levels
- Goal progress over the period — which goals advanced, which were not attempted, and how often
This monthly record is what a Medicaid auditor or state QA reviewer is likely to ask for when auditing community integration billing. Generating it manually from individual session notes is a significant administrative burden. Agencies that can produce it quickly are in a much stronger position during reviews.
Where Most Agencies Fall Short
Based on the documentation requirements above, the most common gaps are:
Vague location documentation. "Community outing" or "community trip" in place of a specific address. This is the most frequent finding in CLE audits.
Missing or inconsistent goal tracking. Goals are maintained on paper or in a separate system and are not consistently surfaced to DSPs at session time. Goal progress is therefore inconsistently documented or omitted.
No multi-stop documentation. Sessions that visit more than one location are documented with only one, leaving a gap in the record.
No supervisor review before billing. Session notes go directly from DSP submission to billing without a QA layer. This is fine until one incomplete note triggers a recoupment.
Monthly summaries produced manually. Administrators compile monthly summaries from individual notes by hand, which is time-consuming, error-prone, and not scalable as census grows.
What a Good Documentation Workflow Looks Like
A compliant community integration documentation workflow follows roughly this sequence:
Before sessions begin: The supervisor enters the client's active community integration goals into the system and links them to the client's CLE schedule. This is a one-time setup that holds until goals change, not something that happens every session.
At session start: The DSP opens the session on their mobile device. The client's goals appear automatically, pre-populated from the schedule. The DSP does not need to look them up.
During the session: As the group visits community locations, the DSP captures each location — name, address, and type. This can be as simple as using the phone's GPS to confirm the location rather than typing an address from scratch.
At session end: The DSP records activities completed, selects skill categories practiced, notes engagement level, and records goal progress for each client using a simple status selector (achieved, partially met, not attempted, refused). A brief narrative note is added. Total session time is confirmed. The note is submitted.
This should take under five minutes. If it takes longer, the workflow has too much friction and DSPs will shortcut it.
After submission: The supervisor reviews the session note before it enters the billing queue. Any missing fields — goal progress, location, time out — are flagged back to the DSP for correction before the claim is submitted.
Monthly close: The system aggregates the session data into the monthly summary automatically. The supervisor adds a narrative review and approves for billing.
A Note on State Variation
Everything above describes the federal CMS framework. Your state will add requirements on top of it.
Louisiana's Community Life Engagement has specific billing codes (H0043 HH for group, H0043 for individual) and documentation requirements that reflect the state's CLE policy framework. Ohio, Texas, and Florida have their own procedure codes and their own checklists for what session notes must contain. If you operate across multiple states, your documentation system needs to accommodate these differences without requiring a different workflow for each state.
The underlying documentation logic — location, goals, activities, supervisor review, monthly aggregation — is consistent across states. The labels and billing codes change.
Conclusion
Community integration services are among the most person-centered services an HCBS agency can offer, and they carry documentation requirements that reflect that complexity. The bar is higher than a home visit because the service is happening in dynamic, uncontrolled settings where the stakes — community access, skill building, employment readiness — are also higher.
Meeting that bar consistently requires a documentation system designed for group, community-based services. Not a home visit platform with an extra field for "location."
At Cura OS, we are building exactly this kind of infrastructure for community integration and Day Habilitation services. If you want to talk through how your agency is currently handling CLE documentation, we'd be glad to connect.