Developmental Disability Provider Software: How Does a Note Written at 11pm in a Group Home Become a Clean Waiver Claim?

Why the whole business rests on a note written at 11pm

A direct support professional finishes an evening shift in a four person group home. She supported a man through a community outing, prompted him twice on a communication goal, gave two medications, de-escalated a difficult twenty minutes and cleaned up afterwards. At 22:50 she writes the note. She writes what happened, in her own words, because that is what makes sense to a human being at the end of a shift.

Six weeks later the claim for that day is denied. The note did not reference the authorised service by name, did not tie the support to a goal on the individual service plan, and the times recorded do not match the electronic visit verification record because her phone had no signal in the van. The billing coordinator writes it off, because chasing a single unit costs more than the unit is worth. Multiply by a few hundred shifts a month across the agency and the write-off stops being a rounding error. Then the state licensing review arrives, samples the same notes, and finds that goal documentation is inconsistent, which is a finding on the same document that just failed to pay.

That is the structural fact of this sector: one document written by your lowest paid, highest turnover staff member, at the end of a long shift, has to satisfy a clinical plan, a licensing standard and a Medicaid claim at the same time. Every software decision follows from that. If the documentation is hard, everything downstream fails, and no amount of billing sophistication fixes it.

Problem one: the note has three audiences and staff are only trained for one

Therap Services is the sector's default for good reason. It is deeply built for IDD, covers documentation, incidents, medication administration and billing support, and it is affordable relative to what it does. MediSked comes from the care coordination direction and suits agencies and state entities managing across providers. Setworks is strong for provider operations. Sandata is an EVV specialist and often arrives because a state mandated it, not because a provider chose it.

Where providers push past them is not features, it is fit to a specific state's waiver rules combined with a specific agency's programme mix. A provider running residential, day habilitation, supported employment and in-home supports across two states is running four documentation standards multiplied by two rule sets, and every packaged product is configured to a common denominator. The gap gets filled by staff training, which erodes with every departure, and by a billing team that manually fixes what the training did not.

What a custom build does: generate the documentation form from the authorisation and the plan, not from a template library. When a DSP opens a shift, the system already knows which individual, which authorised service, which units remain this month, and which goals are active for that service. The form asks about those goals specifically, in plain language, with a structured progress capture plus a free text field for what actually happened. The note cannot be submitted while it is missing an element the claim will require. The DSP is never asked to remember a rule, because the rule is in the form. This one change is what moves denial rates, and it moves them for the same staff you already have.

Problem two: EVV was mandated on you, and it is usually implemented against you

The federal requirement for electronic visit verification came from the 21st Century Cures Act and applies to personal care and home health services under Medicaid, with states choosing their own models. Some states run a single aggregator that everyone must feed. Others let providers use their own system and submit. The result is that most agencies now carry an EVV tool that was chosen by a state, does not speak to their documentation system, and produces a second set of times that must reconcile with the first.

What a custom build does: capture verification as a property of the shift itself rather than as a separate act. One check in, on the phone the DSP already has, which starts the shift, records location where the service type requires it, opens the documentation, and closes on check out. Offline is mandatory, since homes have poor coverage and vans have none, so the device holds the shift and syncs later with the original timestamps preserved rather than the sync time. Then submit to the state aggregator through their interface on your schedule, with a reconciliation queue for anything the aggregator rejects. The measurable outcome is EVV exceptions per hundred shifts, which is a number most agencies cannot currently produce and which quietly drives a meaningful share of denials.

Problem three: incidents have their own clock and their own audience

A critical incident, a restraint, an injury, a medication error or an allegation carries a state reporting deadline measured in hours, an internal investigation, and follow up actions that a licensing reviewer will check. In most agencies this runs on a paper form, an email to a director, and a spreadsheet the compliance officer maintains. The reporting deadline is met by someone remembering.

What a custom build does: incident type drives the clock, the notification list and the required fields, all from configuration you control per state. Reporting deadlines are visible and escalate before they expire rather than after. Follow up actions are assigned with owners and due dates and stay open until closed. Restrictive interventions link to the individual's behaviour support plan so a pattern is visible, which is exactly what a reviewer asks about and what agencies usually cannot show. Trend views by site and by programme let a director see that one home has generated most of the incidents this quarter, which is a supervision question and not a documentation one. Reviewers are consistent about what they ask for here, and the difference between an agency that can produce it in a click and one that needs a week is the difference between a routine review and an unpleasant one.

Problem four: the claim is assembled from thousands of small facts

Waiver billing is not complicated in concept and is punishing in detail. Services bill in units against an authorisation with a period cap. Different services have different rules about overlap, about staffing ratios where one staff member supports two people, about what happens on a day the individual was hospitalised, about transport as a separate billable, and about which credentials the staff member had to hold. Get any of it wrong and the claim is denied months later, at which point the shift note is old and the DSP has left.

What a custom build does: validate against the authorisation at the moment of documentation rather than at billing. If a shift would exceed the remaining authorised units, the supervisor knows on the day, when a service authorisation increase can still be requested. Ratio services derive the correct split automatically rather than depending on someone remembering to record it. The claim assembles from documentation that has already been validated, so the billing team's job becomes exception handling rather than reconstruction. Denial reasons come back into the same system and are attributed to a site and a cause, which turns a monthly write-off into a specific coaching list. Agencies that make this shift usually find their write-offs concentrate in two or three sites, which is a manageable problem rather than a diffuse cost of doing business.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering individual records with plans and goals, authorisation-driven shift documentation on mobile with offline support, EVV capture and the supervisor review queue runs $70,000 to $140,000 in 12 to 18 weeks. A full platform adding medication administration records, incident and investigation workflow, claim generation and denial management, staff scheduling with credential checking, and state aggregator submissions runs $180,000 to $420,000 across 7 to 14 months.

What drives cost up in this sector: the number of states, because each waiver has its own service definitions, documentation expectations, incident categories and EVV model, and there is very little shared logic between them. Medication administration, which is a high risk module and deserves proper design rather than a checklist. State aggregator integration, since each state's technical interface differs and some are unpleasant. Payroll and scheduling integration, if you want the shift to drive both documentation and pay. And data migration from Therap or a similar incumbent, which is real work because historical documentation must remain accessible for audit.

What keeps cost down: one state and your two largest programme types first, documentation and EVV before billing, and exporting to your existing clearinghouse rather than building claims submission in phase one.

Build versus buy, and when buying is the right call

Buy if you operate in one state with a dozen homes or fewer. Therap is genuinely good, the sector knows it, staff move between agencies already trained on it, and a custom build at that size would consume money that should go to DSP wages. Buy also if your state runs a mandated system that you are required to use for core documentation, because operating a parallel record against a state mandate creates two versions of the truth.

Build when two or more of these are true. You operate in two or more states and your compliance team maintains a separate mental model for each. You run more than roughly 40 sites or programmes and your billing team spends the first week of every month reconciling. Your programme mix includes something the packaged products handle badly, which is commonly supported employment with its own outcome documentation or self-directed services where the individual employs their own staff. You are growing by acquisition and inheriting a different system with each agency you acquire. Or your denial write-offs have become a line item that the board asks about.

Our position: the return on this build is almost entirely at the point of documentation. Any project that starts with the billing engine is building a better machine for processing bad inputs, and the input is a tired person at 22:50 who deserves a form that helps her.

How to choose a developer for IDD provider software

Ask them to spend an evening shift in a group home before designing anything. If they are not willing, they will build for the compliance officer, and the compliance officer is not the person whose behaviour determines whether the agency gets paid.

Ask how the documentation form is generated. The answer you want is from the authorisation and the active plan goals at runtime, not from a library of templates that someone has to maintain per programme per state. Template libraries drift the moment a state changes a service definition.

Ask how they will handle offline and time integrity. Homes and vans have poor coverage, and an EVV record whose timestamps reflect the sync rather than the event is worse than useless because it creates exceptions you then have to defend. Local capture with preserved original timestamps and an explicit exception queue is the right answer.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. For an agency that grows by acquisition, owning the platform is also what lets you fold a newly acquired provider onto your own system instead of inheriting theirs.