Area Agency on Aging Case Management Software: Authorizations, Provider Units and the NAPIS Report at Year End

Why one client with three funding sources breaks the system

A care manager visits an 84 year old woman living alone after a hip fracture. By the end of the visit she needs home delivered meals, two personal care visits a day, transport to dialysis three times a week, and her daughter needs respite so she can keep her job. That is four services drawn from at least three funding sources: Older Americans Act nutrition money, a Medicaid home and community based services waiver, and the family caregiver programme. Each has its own eligibility, its own unit rate, its own cap, its own allowable provider list and its own reporting obligation. The care manager writes a care plan. Somewhere behind her, an agency has to authorise, procure, pay and report all of it correctly for years.

The client experiences one plan. The agency runs three sets of rules, and the seams between them are where the money and the audit findings live. When the state reviews you, they will not ask whether the woman was well served. They will ask why 43 meals were charged to a funding source her eligibility did not cover in March, and whether the units you reported to NAPIS match the units you paid for.

The market here is genuinely mature. WellSky Aging and Disability, descended from the SAMS product most directors have used at some point, handles Older Americans Act reporting properly and is the default for a reason. Eccovia ClientTrack is highly configurable. PeerPlace fits particular statewide deployments well. All three are credible. The pattern we see is not that they fail, it is that agencies above a certain size run them for the client record and run the money in spreadsheets beside them, and the spreadsheets are where the risk concentrates.

Problem 1: the authorisation is where money and eligibility actually meet

An authorisation is not a note that says the client gets meals. It 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. Change any one of those and the authorisation changes. Clients move between funding sources constantly as waiver eligibility is established or lost, as a spend down completes, as a state programme runs out of allocation in month nine.

Where systems fall short is treating funding as an attribute of the service rather than as a rule set with its own arithmetic. So when a client transitions from a state funded programme to a waiver mid month, the split is calculated by a person, and when the state asks why the units do not reconcile, the answer is in someone's head.

What a custom build does: authorisations carry the funding source, rate, unit cap, effective dates and the eligibility condition that must hold. Transitions produce a clean split with both segments retained and visible. Remaining units and remaining dollars are live figures a care manager can see before she promises anything to a family. And an authorisation cannot be issued against a funding source whose eligibility criteria the client does not currently satisfy, which removes an entire category of finding at source rather than at audit.

Problem 2: provider invoices are reconciled by hand and everyone knows it

At month end a nutrition provider submits meal counts, a transport contractor submits trip logs, and three in home care agencies submit visit hours. Somebody in finance compares those totals to authorisations and to what the care managers believe was delivered. In most agencies that comparison is a workbook, and the realistic depth of checking is whether the total looks plausible.

The exposure runs both ways. You pay for units nobody authorised, and you also fail to notice a client who was authorised for daily visits and received four in a month, which is a service failure hiding inside a payment process. Where Medicaid personal care is involved, electronic visit verification is a federal requirement under the Cures Act, so visit data exists in some form and is very often stranded in a vendor portal that never meets your authorisation data.

What a custom build does: providers submit units through a portal or a file in a defined format, or the system ingests the electronic visit verification feed directly. Each unit is matched to an authorisation and validated on rate, date range, remaining units, provider eligibility and the client's funding eligibility for that date. Exceptions land in a queue with the reason. Payment is generated from validated units rather than from a submitted total. Under service surfaces as an alert to the care manager rather than as a discovery during a complaint investigation.

Problem 3: the waitlist is the most consequential spreadsheet you own

Demand exceeds funding, which means most agencies maintain waiting lists for home delivered meals, personal care or caregiver support. The Older Americans Act directs services toward those in greatest social and economic need, and your state adds its own prioritisation. In practice that policy is implemented by a coordinator ranking people in a spreadsheet with a scoring rubric nobody has looked at since the last director.

This is the least defensible process in most agencies and the one with the most human consequence. When a legislator asks how long an older adult in a rural county waits for a meal, or when an advocate asks whether prioritisation disadvantages a particular group, the honest answer is usually that nobody can compute it.

What a custom build does: prioritisation is a versioned scoring rule set, applied automatically from assessment data, producing a ranked list with the reasoning visible for each person. Time on list, reassessment prompts and outcome at removal are recorded, including the people who died waiting, which is a number every director should be able to state and almost none can. When capacity opens, the offer sequence follows the policy and any deviation is recorded with a reason.

Problem 4: NAPIS units should be derived, not counted

The state programme report asks for units of service by category, registered and unregistered client counts, and characteristics that have to be collected consistently across a network of subcontracted providers who each have their own definition of a unit. Agencies assemble it once a year from provider reports, and the number reconciles to the money only approximately.

What a custom build does: units are captured once, at delivery, in the definition the report requires, and the report is a query with drill down to the underlying records. Because the same validated units drive payment, the report and the accounts agree by construction rather than by reconciliation. When the state changes a definition, the crosswalk is versioned so prior years remain reportable as they were filed.

Problem 5: caregiver and respite programmes do not fit a client centred model

Under the family caregiver programme the person you serve is the caregiver, and the care recipient is a related but distinct individual with their own eligibility relevance. Most case management systems model one client with services attached, so agencies improvise: a duplicate record, a note, a relationship field that reporting cannot use. Respite then gets recorded against the wrong person and the caregiver's own service history becomes unreadable.

What a custom build does: model the caregiver and the care recipient as separate people with a typed relationship, and let a service be delivered to one on behalf of the other. Respite hours attach to the caregiver's authorisation while the care recipient's needs drive eligibility. It sounds like a small modelling decision and it is the difference between a caregiver programme you can report on and one you cannot.

What a build has to include

• Intake and screening from multiple entry points, including referrals from hospitals, the information and assistance line and no wrong door partners.
• Your state assessment instrument, versioned, with reassessment scheduling and change detection between assessments.
• Care plan and authorisations with funding source rules, rates, caps, effective dates and eligibility conditions.
• Provider network management with contracts, rates by service and funding source, capacity and geographic coverage.
• Provider unit submission with validation, plus electronic visit verification ingestion where Medicaid personal care applies.
• Invoice generation from validated units, with an exception queue rather than silent adjustment.
• Cost sharing and voluntary contributions handled with the confidentiality the programme requires, since contribution must never gate service.
• Waitlist prioritisation as versioned policy with visible reasoning.
• NAPIS reporting derived from the same units that drive payment, plus waiver billing export.
• Conflict of interest separation where your state applies conflict free case management rules to waiver services.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, a focused first release, meaning assessment and care planning, authorisations with funding stream rules, and provider contracts and rates, runs $80,000 to $160,000 and ships in 12 to 18 weeks. Adding provider unit capture with validation, invoice generation, waitlist prioritisation, caregiver programme modelling and NAPIS reporting brings the total to $200,000 to $500,000 across 8 to 14 months.

What drives cost up in this category specifically: the number of funding streams, since each one is a rule set rather than a dropdown value, and agencies administering both Older Americans Act titles and waiver services are carrying two governance regimes at once. Electronic visit verification integration, because the aggregator or vendor in your state determines how pleasant that is and you do not get to choose. The provider network size, since onboarding forty subcontracted providers to a submission portal is change management, not software. And any state specific assessment instrument with licensing conditions attached.

What keeps cost down: implementing authorisations and provider unit validation first and leaving assessment where it is for one more year. The money problems are the expensive ones and they can be fixed without touching the clinical workflow.

When buying is the right answer

Buy if you are a smaller agency running one or two Title III programmes, without waiver case management, with a provider network you can count on two hands. WellSky Aging and Disability will do NAPIS properly, your reconciliation is manageable, and a build would be an expensive way to reach the same place.

Build when two or more of these are true. You authorise over roughly $6M 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. Your finance team spends more than a week a month reconciling provider invoices. You maintain waiting lists and cannot explain your prioritisation with data. Or your state has changed rates, reporting or conflict free requirements and your current configuration is a consulting engagement away from compliance every time.

How to choose a developer for aging services systems

Ask them to model a client who moves from a state funded programme to a Medicaid waiver on the 14th of the month while receiving three services. If they cannot describe the split cleanly, with both segments retained and reportable, they will build you a client database and you will keep the spreadsheet.

Ask how a provider invoice is validated. The answer should mention matching to authorisation, rate, remaining units, date range and eligibility on the date of service, with an exception queue. Anything vaguer means payment will still be a trust exercise.

Ask how they would represent a caregiver and a care recipient. A developer who reaches for a duplicate client record has not worked in this domain.

Ask what they have integrated in this sector, specifically electronic visit verification aggregators and state Medicaid billing, since those are the two that consume schedule. Then settle ownership in writing before kickoff: repository, cloud accounts, data export and the right to hire anyone else. At Digital Heroes the agency owns the code from the first commit, which matters here because these systems hold years of client history that must remain accessible long after any single vendor relationship ends.