Area Agency on Aging Software Problems: The 7 That Cost Agencies Real Money

Why does the assessment instrument always break scope?

The assessment is not yours. The state unit on aging or the Medicaid agency publishes it, scores it and revises it, and projects get scoped as build the assessment form, which understates it by an order of magnitude.

A real instrument has conditional branching, weighted domain scores, functional limitation counts feeding a priority score, and cut points that decide whether someone qualifies for a waiver slot. Configurable form builders render questionnaires competently and treat a revision as a new form, which quietly breaks your trend data and, more seriously, means an old determination can no longer be reproduced under the rules that produced it.

The second underestimate is duplication. Some states mandate their tool for waiver eligibility while allowing your own for Older Americans Act services, so the same client is assessed twice by two people asking overlapping questions, and the build has to hold both without pretending they are one.

The fix is to treat the instrument as versioned executable configuration. Questions, branch rules, domain weights and cut points are data. Every completed assessment stores the version it was scored under. A rescore never rewrites history. When the state changes a cut point in March, assessments before March keep their original scoring and both remain queryable in one report. That sounds like plumbing. It is the difference between defending a denial at a fair hearing and improvising in front of a hearing officer.

What goes wrong migrating client, authorization and unit history?

Three archives, each with its own trap.

Client records carry duplicates created over years by different intake routes, plus deceased clients never closed, plus households recorded inconsistently where a spouse is sometimes a client and sometimes a contact. Deduplicating is judgement work that belongs with your staff, not a matching rule.

Open authorizations are the operational risk. At cutover, real people are receiving real services against commitments that must carry across intact, with the correct remaining balance. Getting a remaining unit count wrong means either a provider stops being paid or a client keeps receiving services nobody is funding.

Historical service units are the reporting risk. Units were recorded under service category definitions that have changed, sometimes without the change being documented, so last year's totals may not be reproducible from the underlying records at all.

The workable approach is to migrate open cases and open authorizations at full fidelity with staff review of every one, migrate closed history as read only reference, and reconcile reported unit totals for the last two reporting periods before go live rather than after. Where historical categories cannot be mapped cleanly, record that fact rather than forcing a mapping, because an explained gap is defensible and a wrong number is not.

Why do state upload, verification and managed care integrations break after launch?

Each breaks differently, and all three are usually quoted as one line.

The state upload is a fixed format defined in a document that may lag the actual validator. Files pass locally and are rejected on submission for reasons the specification does not describe, and the fix cycle depends on the state's availability rather than yours. After launch, the format changes with limited notice and the job fails on a quarter boundary when everyone is busy.

Electronic visit verification is the hardest. Under the 21st Century Cures Act, Medicaid personal care and home health require verification, and most states use an aggregator that collects visit data from provider agencies. You receive that data with the provider's client identifier and the provider's service code, not yours. Matching by hand defeats the mandate. After launch, a provider changes their internal identifiers and the match rate collapses without an error being raised anywhere.

Managed care interfaces break on their calendar, their testing windows and their file versions.

The fixes are the same shape each time. Build an explicit identity resolution layer with a maintained crosswalk and a review queue, so an unmatched visit becomes a task rather than a mystery. Monitor the match rate as an operational metric and alert when it drops. Alert on the upload that did not run at all, not only on the one that errored. And keep raw inbound files so a rejection can be diagnosed rather than reproduced.

What happens when confidentiality boundaries and audit trails are not covered?

This is the gap that creates real exposure rather than inefficiency. Older Americans Act client data, waiver records generally subject to health privacy rules, adult protective services referrals and Long Term Care Ombudsman records carry different disclosure rules. Ombudsman records in particular are protected in ways that make a freely shared client record dangerous.

What goes wrong when this is designed as tabs on one record: a care manager can see an ombudsman complaint about a provider they are about to authorize, a protective services referral is visible to staff with no need to know, and there is no log showing who read what. The failure surfaces during a monitoring visit or, worse, when a client or an advocate asks who has seen their file.

The audit trail half matters just as much on the money side. If a payment can be released without a traceable link to an authorization, an assessment and an approval, then a state monitor walking the chain backwards will stop where the link is missing, and that is where a finding gets written.

The fix is access enforced at record type level with logging on read as well as write, and a design conversation about these boundaries in the first session rather than the last. A developer who has worked in the aging and disability network will raise ombudsman confidentiality before you do. Ask about it early and treat the answer as a screening question.

Should you build custom or configure what you already own?

Configure, if you are a single county agency running a short list of services, mostly congregate and home delivered meals, transportation and information and referral, with a provider network you could name from memory. WellSky Aging and Disability and PeerPlace are both credible for that shape, they already carry state reporting formats other agencies have pushed on them, and a custom build is an expensive way to reach the same place. Spend the money on drivers and meals.

Configure also if your real complaint is reporting rather than adjudication. Getting your existing product to produce the reports you need is normally cheaper than replacing it, and the work of defining those reports has to be done either way.

The build case starts on the payer side. Case management alone rarely justifies a build. Case management plus payer functions does, because the coordination between what you authorized, what was verified as delivered and what you paid is your actual exposure, and no generic tool models all three as one object.

Build when two or more of these hold. You administer waiver services alongside Older Americans Act programs, so you carry two eligibility regimes and two rate structures. You adjudicate provider claims rather than merely recording them. Your state changed the assessment instrument in the last three years and it cost you weeks. You operate consumer directed options where the client holds a budget. Or you are a lead agency for other counties, which means tenancy that packaged aging tools handle poorly.

How do hidden costs get into the quote?

Funding source count is the first. Each source adds a rate table, a unit definition and an eligibility rule set, so five funding streams is not five configuration rows, it is five sets of rules with five sets of tests.

State integration is the second, and it is quoted as a file format when it is actually a testing relationship with an organisation whose schedule you do not control.

Consumer directed programs are the third. Payroll and tax handling for individual providers is its own discipline and usually belongs with a fiscal intermediary rather than inside your build. Scoping it in without that decision is how budgets double.

Multi tenancy is the fourth. If a second county is even possible within a few years, raise it in the first design session. Retrofitting tenancy onto a single county build is one of the more expensive mistakes in this category.

Provider onboarding is the fifth and it is a staff cost rather than a developer cost. A portal only saves your fiscal team time if providers actually use it, and getting sixty agencies onto it takes training, support and a period of running both ways.

Ask for those five as named items with days against them, and ask specifically which consume agency staff time.

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

The builds that work model the authorization as a budget on day one. It carries a rate, a unit type, a funding title, a provider, a date range and a remaining balance, and claims adjudicate against it. If a developer draws a service plan as a list of services with no rate and no balance, you will still be reconciling invoices by hand a year later.

They start with the two or three funding sources that carry most of your service dollars and leave the smallest grant programs on the current process for release two. Trying to model every stream at once means the first release never lands and the smallest programs consume the most argument.

They give providers a reason to cooperate. Denial reasons visible in a portal, claim status they can check, and a predictable payment cycle turn adjudication from a fight into a process. Without that, the fiscal team simply moves from checking invoices to answering phone calls.

They run one full billing cycle in parallel. Every difference between the system and the manual check is either a rule configured wrongly or an informal practice nobody documented, and both are worth finding before the manual check disappears.

And they settle ownership before kickoff: your repository, your cloud accounts, your right to hire anyone else. Agencies change directors and funding cycles, and a system whose code sits with a vendor is a dependency your successor inherits without knowing it.