Aging Services Case Management Software Problems: The 7 That Cost Money and Audit Findings, and How to Avoid Them

Why does we just need a client record become a funding rules engine?

The project starts as a case management system: intake, assessment, care plan, notes. Then someone asks what happens when the client on that care plan receives home delivered meals under an Older Americans Act title, personal care under a Medicaid waiver, and respite under the family caregiver programme. Each has its own eligibility test, its own unit rate, its own annual cap, its own allowable provider list and its own reporting obligation. The client experiences one plan. The agency is running three rulebooks and the seams between them are where the money sits.

This is specific to aging services because the rulebooks are set by different authorities on different cycles, and none of their changes arrive as a software requirement. So a build scoped as a client record grows a funding engine halfway through, at the point where it is most expensive to add.

The fix is to model the authorisation properly from the first sprint. An authorisation is a commitment: this service, from this provider, at this rate, up to this many units, between these dates, charged to this funding source, valid only while the client meets that source's eligibility. Get that object right and transitions produce a clean split with both segments retained and reportable, remaining units and remaining dollars become live numbers a care manager can see before she promises anything to a family, and the system can refuse to authorise against a source whose eligibility the client does not currently meet. That refusal removes a whole category of finding at the point of entry rather than at audit.

What goes wrong when years of client and authorisation data are migrated?

Agencies underestimate this because demographic data moves cleanly. Everything attached to it does not. Authorisation history has to carry its funding source, rate and date range, because an audit sampling a service from three years ago will ask what authorised it. Assessments are versioned instruments, and one completed under the 2019 version of your state tool cannot be displayed as though it were current. Provider contracts and rates changed mid year, so a flat rate table loses the history that reconciles old invoices.

The aging specific complication is client identity across programmes. The same person appears in the nutrition roster, the information and assistance call log, the waiver case file and possibly as a care recipient on a caregiver's record. Merge them carelessly and you either double count in reporting or attach a service to the wrong person.

The fix is to migrate authorisations and services with full fidelity for the retention period your state requires, keep assessments versioned with the instrument they were completed under, and run client matching as its own workstream with a confidence threshold and a human queue. Then reconcile: pick three closed months, regenerate the unit totals from migrated data, and compare them to what was actually reported and paid. If those do not agree, you have found the migration defect before go live rather than during a review.

Why do electronic visit verification and state billing integrations break after launch?

Two integrations dominate this category and neither is under your control. Electronic visit verification is a federal requirement under the Cures Act wherever you touch Medicaid personal care, and the aggregator or vendor was chosen by your state, not by you. Their file format changes on their schedule, their identifiers for clients and workers rarely match yours, and their idea of a completed visit may not match a unit as your authorisation defines it. State Medicaid billing has the same character: a submission format that is stable until it is not, and a rejection code set that describes the technical failure rather than the business cause.

These break after launch because the test file was clean. Real feeds carry visits for discharged clients, visits spanning midnight, worker identifiers that changed when a provider ran payroll, and duplicates from resubmissions.

The fix is to treat every inbound visit and every outbound claim as a record with a state and an exception reason, never as a batch that either succeeded or failed. Visits that cannot be matched to an authorisation land in a queue with the reason visible, and the queue has an owner and a service level. Claims carry their rejection code translated into something a billing clerk can act on. Build a replay path in the first release, because you will need to reprocess a month when a rate is corrected retroactively, and an agency that cannot replay does that by hand.

What happens when waitlist prioritisation and provider validation are not covered?

These are the two gaps that most often survive a build, because neither blocks anything on the day it is skipped. Waitlist prioritisation stays in a spreadsheet with a scoring rubric nobody has revisited since the last director. It works until a legislator asks how long an older adult in a rural county waits for a meal, or an advocate asks whether prioritisation disadvantages a particular group, and the honest answer is that nobody can compute it. Meanwhile the Older Americans Act directs services toward those in greatest social and economic need, so the policy exists and the evidence that you followed it does not.

Provider invoice validation is the money version of the same problem. A nutrition provider submits meal counts, a transport contractor submits trip logs, three home care agencies submit hours, and finance compares totals to authorisations in a workbook where the realistic depth of checking is whether the total looks plausible. The exposure runs both ways: you pay for units nobody authorised, and you miss a client authorised for daily visits who received four in a month.

The fix on the waitlist is a versioned scoring rule applied automatically from assessment data, producing a ranked list with visible reasoning, and recording time on list, offers made and outcome at removal, including people who died waiting. The fix on invoices is unit level matching: every submitted unit checked against an authorisation on rate, date range, remaining units, provider eligibility and client funding eligibility for that date of service, with exceptions queued rather than adjusted silently. Payment then comes from validated units rather than from a submitted total.

Should you build custom or configure what you already own?

Configure, genuinely, if you are a smaller agency running one or two Title III programmes with a provider network you can count on two hands and no waiver case management. WellSky Aging and Disability handles the state programme report properly and is the default for a good reason. Eccovia ClientTrack is highly configurable and will express more of your rules than agencies expect, provided you have someone who can drive the configuration. PeerPlace fits certain statewide deployments well. Building at that size is an expensive route to the same place.

The pattern above a certain size is not that these products fail. It is that they hold the client record well while the money moves in spreadsheets beside them, and the spreadsheets are where the risk concentrates. If your finance team spends more than a week a month reconciling provider invoices, that is the signal.

The honest trigger list: you authorise over roughly six million US dollars a year across three or more funding streams. You perform waiver case management alongside Older Americans Act services, so two rulebooks meet on one client. You maintain waiting lists you cannot explain with data. Or every state rate or reporting change becomes a consulting engagement. Two or more of those and the build pays. A useful middle path is to keep the incumbent for assessment and client records and build only the authorisation and provider validation layer, which is where the money problems live.

How do hidden costs get into an aging services quote?

Three overruns recur. The first is funding stream count, because each stream is a rule set rather than a dropdown value. An agency administering both Older Americans Act titles and waiver services is carrying two governance regimes at once, and a quote based on the first two streams will miss the third and fourth entirely. Ask for the count in writing before scope is fixed, and list the rules for each on one page.

The second is provider network onboarding. Getting forty subcontracted providers submitting units in a defined format is change management, not software. Some can export a file, some have a person with a clipboard, and the clipboard providers are usually delivering the most units. Budget the manual entry path and the training, because a portal nobody uses means finance is still keying invoices and none of the validation happens.

The third is the state assessment instrument, which may carry licensing conditions and a fixed question order that constrains your interface. In Digital Heroes delivery experience a focused first release covering assessment, care plan and authorisations with funding rules, plus provider contracts and rates, runs 80,000 to 160,000 US dollars over 12 to 18 weeks, with a full platform at 200,000 to 500,000 over 8 to 14 months. Quotes materially below that band usually treat funding as a field.

What separates an aging services build that works from one that fails?

The builds that work sequence by risk rather than by workflow order. Care managers assume you start with intake and assessment because that is where their day starts, but the expensive failures are downstream in authorisation and payment. Agencies that implement authorisations and provider unit validation first, leaving assessment where it is for another year, get the audit exposure closed in months and can fund the rest from the reconciliation time they recover.

They also model the caregiver programme properly at the start. Under the family caregiver programme the person served is the caregiver while eligibility relates to the care recipient, so you need two people with a typed relationship and a service delivered to one on behalf of the other. Agencies that discover this late end up with duplicate client records, respite hours recorded against the wrong person, and a programme they cannot report on. Ask a prospective developer how they would represent this. A developer who reaches for a second client record has not worked in this domain.

The builds that fail share two habits. They generate the state programme report as a separate exercise from payment, which guarantees the two numbers disagree and puts an annual reconciliation on someone's desk forever. And they leave overrides undocumented, so when a care manager authorises outside policy for a genuinely good reason, the system records the exception without the reasoning. Units should be captured once at delivery in the definition the report requires, the same validated units should drive payment, and every override should carry a named person and a reason.