Developmental Disability Provider Software Problems: The 7 That Cost You Claims and Findings, and How to Avoid Them

Why does starting with the billing engine go wrong so often?

The business case is usually written by finance, so the project is scoped from the claim backwards. Build the billing engine, add denial management, then get to documentation in phase two. It is a rational sequence and it produces a better machine for processing inputs that are already wrong.

Denials in this sector are overwhelmingly documentation defects rather than claim construction defects. The note did not name the authorised service, did not tie the support to an active plan goal, or recorded times that do not agree with the electronic visit verification record. A more sophisticated claim engine cannot manufacture the element the note is missing. It can only fail faster and produce a better report about failing.

The other consequence is adoption. If the direct support professional's experience does not change in phase one, nothing about the agency's daily reality changes, and the staff who determine whether you get paid never see any benefit from the project. By the time documentation arrives in phase two, the budget is thinner and the goodwill is gone.

The fix is to sequence from the point of documentation. First release is authorisation driven shift documentation on the phone the staff member already carries, with offline capture and verification built into the same flow, plus a supervisor review queue. Export to your existing clearinghouse in phase one rather than building claim submission. Then measure denial rate and licensing findings against the same period last year. If the note improves, everything downstream improves, and the billing engine you build later is worth building.

What goes wrong when you migrate off Therap or a similar incumbent?

Migration in this sector is not a data load, and treating it as one is a common way to lose six weeks and a lot of trust. Your historical documentation is audit evidence with a retention obligation, and it has to remain retrievable in a form a reviewer will accept for years after the system that produced it is gone.

The specific traps are consistent. Individuals appear more than once because they moved between programmes and were entered twice. Plans and goals have version history that matters, since a note from two years ago has to be read against the plan that was active then rather than the current one. Authorisations carry period caps and units already consumed, and importing them without the consumption history produces a system that thinks every individual has a full allocation. Medication records carry a different level of risk again and should never be migrated casually.

What works is a split. Move forward looking data into the new system, meaning individuals, current plans and goals, active authorisations with consumed units, open incidents and open follow up actions. Keep historical documentation in a read only archive that is searchable by individual and date and can produce a legible record on demand. Then run both systems in parallel for at least one complete billing cycle before claims move across, because a billing cycle is the only test that exercises authorisations, units and denials together. Agencies that skip the parallel cycle discover their authorisation import was wrong in the month it matters most.

Why do state EVV aggregator integrations break after launch?

Electronic visit verification became a federal requirement for personal care and home health services under Medicaid through the 21st Century Cures Act, and states implemented it differently, so most agencies now carry a verification tool chosen by a state rather than by them, producing a second set of times that must agree with the first.

The failures after launch are rarely dramatic. A state updates its submission specification and adds a field, and records start rejecting with a code nobody in your agency can interpret. A service code mapping was correct at go live and then the state redefined a service. Timestamps drift because the mobile app recorded the sync time rather than the event time when a van had no signal, so a shift that genuinely happened at 18:05 submits as 21:40 and gets flagged as an exception.

The fixes are concrete. Capture verification as a property of the shift rather than as a separate act, so one check in starts the shift, records location where the service requires it, opens documentation and closes on check out. Make offline the default assumption rather than a fallback, and preserve the original timestamps through the sync rather than overwriting them. Then build a reconciliation queue with an owner and a daily rhythm, tracking exceptions per hundred shifts as a managed number. Most agencies cannot currently produce that number, which is exactly why the exceptions quietly drive denials nobody has attributed.

What happens when incident deadlines and restrictive interventions are not covered?

Critical incidents, restraints, injuries, medication errors and allegations carry state reporting deadlines measured in hours. In most agencies the deadline is met by somebody remembering, which works until the person who remembers is on leave or the incident occurs on a Friday evening at a site with a new supervisor.

Software that treats an incident as a form with a submit button does not solve this. The requirement is that the incident type drives the clock, the notification list and the required fields, all configurable per state by your compliance team rather than by a developer, and that the clock escalates before it expires rather than reporting after the fact.

The part that gets omitted most often is the link between restrictive interventions and the individual's behaviour support plan. A reviewer will ask whether a restraint was consistent with the plan in force at the time, and whether a pattern was identified and acted on. Agencies that cannot show that linkage spend a week assembling it from paper, and the assembly itself looks like the finding. Building the link is not expensive, and it changes what a licensing visit feels like.

Follow up actions need owners, due dates and a closed state that somebody has to assert. An incident record that is submitted and then sits there proves that you reported. It does not prove that you responded, and the second is what a reviewer is actually assessing.

Should you build custom or configure what you already own?

If you operate in one state with roughly a dozen homes, do not build. Therap is genuinely good, it is built specifically for this sector, staff frequently arrive already trained on it because they moved from another agency that used it, and a custom build at that size would consume money that belongs in direct support wages. Your denial problem at that scale is almost always documentation training rather than software capability, and the honest fix is a supervisor reviewing notes for a month.

The same applies if your state mandates a system you must use for core documentation. Running a parallel record against a state mandate creates two versions of the truth and doubles the work for the person least able to absorb it.

If your gap is coordination across providers rather than in home documentation, look at MediSked before commissioning anything, since it comes from the care coordination direction and that is what it was built for. If your gap is provider operations at moderate scale, Setworks is a reasonable configuration path.

Build when the constraints are structural. You operate in two or more states and your compliance team maintains a separate mental model for each, because waiver service definitions, documentation expectations, incident categories and verification models share very little logic across state lines. You run more than roughly forty sites or programmes and your billing team spends the first week of every month reconciling. Your programme mix includes supported employment with its own outcome documentation or self directed services where the individual employs their own staff. Or you are growing by acquisition and inheriting a different system each time.

How do hidden costs get into the quote?

The first and largest is the second state. Each additional state brings its own service definitions, documentation expectations, incident categories and verification model, with very little shared logic. Ask for a per state figure at proposal stage rather than a single number with a note about configurability.

The second is medication administration. It is often listed as a module in a proposal and priced like a form. It is a high risk clinical workflow that deserves proper design, real testing and a considered approach to errors and omissions, and treating it as a checklist is how agencies end up with a module their nurses refuse to use.

The third is state aggregator submission, which varies enormously in quality and documentation. Ask which specific states the developer has submitted to and what actually flowed, not whether they can integrate with aggregators in general.

The fourth is the archive. Keeping historical documentation retrievable for audit is a real deliverable with a real cost, and it is the line most often missing from a migration estimate.

What separates a build that works here from one that fails?

The form is generated from the authorisation and the active plan goals at runtime, not selected from a template library. Template libraries drift the moment a state changes a service definition, and maintaining them per programme per state becomes somebody's full time job. When the form is generated, the staff member is never asked to remember a rule, because the rule is the form.

Validation happens on the day, not at billing. If a shift would exceed the remaining authorised units, the supervisor should know while a service authorisation increase can still be requested. Discovering it in the billing run is discovering it too late to do anything except write it off.

Denial reasons come back into the same system and are attributed to a site and a cause. Agencies that do this almost always find their write offs concentrate in two or three sites, which converts a diffuse cost of doing business into a specific coaching list with names on it. Without attribution, denials stay a monthly number that nobody owns.

And the developer has spent an evening shift in a group home before designing anything. It sounds like a soft criterion and it is the hardest predictor of whether the build works, because a team that has only met the compliance officer will design for the compliance officer.