Area Agency on Aging Software: Why Provider Claims Never Match the Authorization You Wrote

Why an area agency on aging breaks the software it is sold

You sit on both sides of the transaction, and almost no packaged product is built for that. A hospital discharge planner refers an 82 year old on Tuesday. By Friday one of your care managers has driven out, run the state assessment instrument on a laptop at a kitchen table, written a care plan, and authorized 12 hours a week of personal care from a contracted agency, five home delivered meals a day from a caterer, and a one time grab bar installation from a modification vendor. Three funding streams pay for those three services. Each has its own rate, its own unit definition, its own eligibility test and its own reporting line.

Six weeks later the personal care agency bills 14 hours in a week you authorized 12. The meal provider bills for a week the client spent in hospital. The modification vendor sends a paper invoice with no authorization number on it. Your fiscal staff catch some of it, in a spreadsheet, from memory. That is the whole problem in one paragraph: you are running a case management operation and a small claims payer at the same time, and the join between the two lives in a person.

Across aging and disability network projects we have delivered, the recurring pattern is the same. Two to four staff days a week spent reconciling provider invoices by hand. Recoupments that nobody chases because the amounts look small individually. And a quarterly reporting scramble where units of service are rebuilt from three exports because no single system knows both what was authorized and what was actually delivered.

Problem 1: the assessment instrument belongs to the state, and it moves

Your assessment is not yours. The state unit on aging or the Medicaid agency publishes it, scores it, and revises it, and when it revises it your historical data has to remain comparable or your level of care determinations stop defending themselves. Some states mandate a specific tool outright. Others let you use your own for Older Americans Act services but require theirs for waiver eligibility, which means the same client gets assessed twice by two people asking overlapping questions.

WellSky Aging and Disability and PeerPlace both ship configurable assessment forms and both do a competent job of rendering a questionnaire. The gap shows up in scoring logic and versioning. A real instrument has conditional branching, weighted domain scores, functional limitation counts that feed a priority score, and cut points that decide whether someone qualifies for a waiver slot. When the state changes a cut point in March, you need the old scoring preserved for anyone assessed before March and the new scoring applied after, with both queryable in the same report. Form builders treat that as a new form, which quietly breaks your trend data.

A custom build treats 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, and a rescore never rewrites history. That sounds like plumbing. It is the difference between defending a denial at a fair hearing and improvising.

Problem 2: an authorization is a budget, and nothing enforces it

When your care manager authorizes 12 hours a week of personal care at a contracted rate through 30 June, that is a spending commitment against a funding source with a finite allocation. It has a start date, an end date, a unit type, a rate, a provider, a funding title and a not to exceed total. Every one of those is a rule that a claim can violate.

Most tools in this space store the authorization as a note on the care plan. The claim arrives separately, often as a spreadsheet emailed by the provider, and a human compares them. That is where the money goes. Not through fraud, mostly, but through drift: services continued after an authorization expired, units billed against the wrong funding title, rates billed at last year's number, duplicate lines for the same date of service.

What a custom build must include is adjudication as a first class function. A claim line hits the authorization it names, and the system checks it against remaining units, the effective date range, the provider contract, the client eligibility span and the rate in force on the date of service. It pays, denies with a specific reason code, or suspends for review. Providers see the denial reason in a portal instead of calling your fiscal officer. Every dollar you release ties to an authorization line and an assessment that justified it, which is exactly the chain a state monitoring visit walks backwards.

Problem 3: electronic visit verification arrives from someone else's system

Under the 21st Century Cures Act, Medicaid personal care and home health services require electronic visit verification, and most states settled on an aggregator model where a vendor collects visit data from provider agencies and hands it to the state. Your agency usually receives that data rather than producing it, and it arrives with the provider's client identifier and the provider's service code, not yours.

So you get a file of verified visits that you cannot automatically match to your authorizations. The identifiers do not line up. Visit times are captured in the provider's rounding convention. A visit shows a caregiver arriving at a client you moved to a different provider two weeks ago. Matching that file by hand defeats the entire purpose of the mandate.

A build worth paying for solves this with an explicit identity resolution layer: a crosswalk of provider client identifiers to your client record, maintained through a review queue where an unmatched visit becomes a task rather than a mystery. Then verified visits become the evidence behind the claim, and a claim without a matching verified visit gets flagged before payment rather than after an audit. That is the whole return on the module.

Problem 4: the waiting list is a policy instrument, not a queue

Every agency with more demand than allocation runs a waiting list, and almost every agency runs it in a spreadsheet with a date column. That is not what your policy actually says. Your policy says people in greatest social and economic need get priority, that certain referral sources jump, that someone at imminent risk of institutionalization is served now, and that the list is re-prioritized as circumstances change.

Packaged aging tools tend to model this as a status field. What you need is a scored, auditable queue: a priority score computed from assessment data and risk factors, a documented reason for every manual override, periodic re-contact tasks so the list does not go stale, and a record of who was offered a slot and declined. When an advocate or a legislator asks why one person waited nine months and another waited three weeks, you want a defensible answer on a screen, not a story.

Problem 5: unit reporting is a rebuild, every quarter

Older Americans Act reporting wants units of service and unduplicated clients by service category and funding title, and it wants registered services separated from non registered ones. Your operational reality is that units come from delivered service records, clients come from the case management side, and eligibility spans decide which title pays. Any one of the three living in a different system guarantees a manual reconciliation.

The fix is not a report. The fix is that the service delivery record carries its funding title from the authorization that created it, so the report is a query rather than an archaeology project. Once that holds, the same data answers questions you could not previously ask: cost per client per month by funding source, provider performance on delivered versus authorized units, and which service mix actually keeps people out of a nursing facility longest. That last one is the case you take to your county commission when you need a local match.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A focused first release covering the state assessment instrument with versioned scoring, care plans, service authorization and provider claim adjudication with a provider portal runs $70,000 to $150,000 and ships in 14 to 20 weeks. A full platform adding waiting list scoring, electronic visit verification intake and matching, provider contract and rate management, consumer directed budgets with fiscal intermediary handoff, and Title III unit reporting runs $180,000 to $450,000 phased over 8 to 14 months.

What pushes cost up here specifically: the number of distinct funding sources you administer, because each one adds a rate table, a unit definition and an eligibility rule set. State system integration, since a required upload format to the state unit on aging is real work and the specification is often a PDF. Consumer directed programs, because payroll and tax handling for individual providers is its own discipline and usually belongs with a fiscal intermediary rather than in your build. And any requirement to exchange data with a managed care organization, which means their interface, their timelines and their testing calendar.

What keeps cost down: starting with the two or three funding sources that carry most of your service dollars, and leaving your smallest grant programs on the current process for release two.

Build versus buy, and when buying is the right call

Buy 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 carry state reporting formats other agencies have already pushed on them, and a custom build would be an expensive way to reach the same place.

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

The honest tipping point is the claims 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 in one object.

How to choose a developer

Ask them to model the authorization before you sign anything. If they draw a service plan with a list of services and no rate, no unit type, no funding title and no remaining balance, they are building you a to do list and you will be reconciling invoices by hand a year from now.

Ask how they will handle assessment versioning. The right answer mentions storing the scoring version with each completed assessment. A wrong answer talks about form templates.

Ask what they have integrated with on the government side. A state upload with a fixed width file format, an electronic visit verification aggregator feed, and a managed care organization interface are three different problems, and you want the specific one you face named back to you with a timeline.

Ask about confidentiality boundaries in the design. Older Americans Act client data, waiver records subject to HIPAA, adult protective services referrals and Long Term Care Ombudsman records have different disclosure rules, and ombudsman records in particular are protected in ways that make a shared client record dangerous. A developer who has done this will raise it before you do.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit, and any vendor who hedges on that is selling you a dependency, not a system.