Home Health Care Software: What Actually Breaks and When to Build Custom

What actually breaks in a home care agency running on AxisCare, Alora, and paper visit logs

Here is a Monday morning we have watched play out at dozens of agencies. The scheduler is on her third call-out before 8am, scrolling AxisCare for anyone within 20 minutes of a dementia client who cannot be left alone. The biller is inside the state Electronic Visit Verification (EVV) aggregator portal, hand-clearing 60 visit exceptions from last week because caregivers clocked in from the driveway instead of the living room. The office coordinator has a stack of paper visit logs from the caregivers who still refuse the app, and she will spend most of Friday keying them in so payroll can run.

If the agency runs both a private duty line and a skilled line, it compounds: personal care lives in AxisCare, skilled nursing lives in Alora, and the same client exists twice. Address changes get entered twice, medication lists drift apart, and the daughter paying privately for companion care receives a second invoice that does not match the first. Nobody chose this architecture. It accreted one workaround at a time, and now three back-office salaries are spent gluing it together.

The tools themselves are not bad. AxisCare is genuinely good at private duty scheduling, and Alora handles clinical documentation and OASIS competently. The failures live in the seams between them, and between them and your state Medicaid program's EVV mandate. Off-the-shelf software cannot fix seams, because your seams are specific to your states, payers, and service lines. That is the territory where a custom build earns its money. Here are the five failures we see most.

Problem 1: EVV exceptions eat your biller alive

The scenario: your state routes EVV through Sandata or HHAeXchange. Every Friday billing run, 40 to 80 visits sit in exception status: GPS outside the geofence because the client lives in an apartment complex, a manual clock-in with no reason code because a phone died, a visit that ran 20 minutes past schedule. Each one must be opened, corrected with the right reason code, and resubmitted before the claim goes out. That is a biller doing data janitor work 10 to 15 hours a week, and any exception that ages past timely filing becomes free care.

AxisCare and Alora transmit EVV data, but transmission is where their responsibility ends. The rejection comes back from the aggregator and the rework lands on you, in the aggregator's portal, one record at a time. A national product cannot pre-validate against your specific state's reason code list and your specific managed care organization's (MCO's) matching rules.

A custom build attacks the problem before submission. Clock-out triggers an immediate verification pass: does the GPS point fall inside a per-client geofence you drew yourself, do times reconcile with the schedule within your payer's tolerance, is a reason code required and attached. Failures go to the caregiver's phone while she is still standing in the home and can fix them in 30 seconds. What survives to Friday is a short exception queue sorted by dollar value and filing deadline, with one-click resubmission through the alt-EVV interface.

Problem 2: one client, two systems, no single record

The scenario: Mrs. Alvarez gets 20 hours of personal care weekly, scheduled in AxisCare, plus skilled nursing twice a week after a hospitalization, documented in Alora. Her daughter calls to change the emergency contact. The office updates AxisCare and forgets Alora. Three weeks later the RN dials a disconnected number during a wound care concern, and the family holds two invoices that do not reconcile.

Picking one vendor does not fix this, because each product is architected around one line of business. AxisCare will not do OASIS assessments and Medicare claims. Alora's private duty side is not why anyone buys Alora. Every multi-line agency we have met runs two systems plus a spreadsheet pretending to be the master record.

A custom platform inverts the architecture: one client record, with service lines, payers, and care teams attached to it. Demographics, contacts, and medications exist once. Both calendars render from the same record, the family portal shows one statement across both lines, and a change propagates everywhere because there is no second place for data to live. If you keep Alora for OASIS during transition, the custom system syncs shared demographics through an interface, so double entry ends on day one.

Problem 3: the 6am call-out and the overtime spiral

The scenario: Saturday, 5:47am. A caregiver texts in sick for a 7am shift covering a two-person transfer client. The on-call scheduler works a phone list from memory: who is close, who is trained on the Hoyer lift, who will not decline a Saturday. She fills it on the ninth call, with a caregiver already at 38 hours. The visit bills at $32 an hour, the replacement now costs time-and-a-half, and the week's margin on that client evaporates.

AxisCare's open shift broadcast helps, but it broadcasts on availability alone. It does not know that two available caregivers have never done a two-person transfer, that one has a documented conflict with this client, or that the cheapest qualified option is at 22 hours and lives nine minutes away. Those constraints live in your scheduler's head, which is exactly why nobody else can take on-call weekends.

A custom matching engine encodes those constraints: required skills pulled from the plan of care, client preferences and exclusions, drive time, hours worked against the overtime threshold, and remaining authorization units. On a call-out, it scores every eligible caregiver and pushes the offer to the top five phones. The knowledge stops living in one person's head, and on-call becomes a rotation instead of a punishment.

Problem 4: authorization units bleed out quietly

The scenario: a Medicaid waiver client is authorized for 40 hours a week. The scheduler books 42 from habit. Nobody notices until the remittance shows two hours a week, for six weeks, paid at exactly zero. Worse: an authorization quietly expires, visits keep running for two more weeks, and the agency delivers roughly $3,000 in care no payer will reimburse. Every home care biller has a version of this story.

AxisCare and Alora record authorizations and will show you the number if you look. They will not reliably hard-stop a scheduler at the moment of booking, forecast exhaustion across all clients at once, or open a reauthorization task the moment usage crosses 80 percent. Auth tracking in off-the-shelf tools is a report you must remember to run.

In a custom build, the authorization is a live ledger wired into scheduling. Booking a visit decrements remaining units in real time, and a visit that would exceed the auth cannot be saved without a supervisor override that leaves an audit trail. A daily forecast flags every client on pace to exhaust units within 14 days, and expirations generate reauthorization tasks for the nurse with payer paperwork pre-filled. Unbillable care stops being a quarterly surprise.

Problem 5: paper visit logs and the survey you cannot pass from a banker's box

The scenario: a third of your caregivers still turn in paper logs, some because of old phones, some because the vendor app dies in a client's basement with no signal. Then the state surveyor asks for six months of visit documentation for eight clients, and your team spends two days pulling boxes and hoping every log has a signature and every task matches the plan of care. The deficiencies that surface are almost never care failures. They are paperwork failures.

Vendor apps lose caregivers at the worst moments: no signal, aggressive battery savers on cheap Android phones, a login that resets. When the app fails in the field, paper returns, and paper cannot be validated, searched, or produced on demand.

The custom answer is an offline-first mobile app designed around the worst phone on your roster. The visit's task list is generated from that client's plan of care, required fields cannot be skipped, the client signs on screen, and everything stores locally and syncs when signal returns, with clock-in times recorded on the device so EVV data stays accurate from a dead zone. Documentation compliance shows on a dashboard the day it slips, not the week a surveyor asks.

What this costs and how long it takes

These numbers come from Digital Heroes delivery experience across 2,000+ projects, not a pricing page. A focused first release for a home care agency typically lands between $40,000 and $90,000 and ships in 10 to 14 weeks: the caregiver mobile app, scheduling with the matching engine, the authorization ledger, and EVV integration with one state aggregator, while Alora keeps handling OASIS and Medicare claims until a later phase. A fuller platform, meaning multi-state EVV, claims through a clearinghouse, family portal, payroll export, and retirement of both AxisCare and Alora, runs $100,000 to $250,000 over five to eight months.

What pushes price up, in order of impact: each additional state aggregator (Sandata, HHAeXchange, and Netsmart each certify differently, and each certification is its own project), claims and remittance handling for Medicaid MCOs and VA alongside private pay, true offline mobile rather than a web wrapper, and HIPAA infrastructure done properly with encryption, access logging, and a signed business associate agreement. One state and one payer type sits at the bottom of these bands. Three states and five MCOs does not.

When you should not build: an honest position on build vs buy

If you run one service line in one state, have fewer than roughly 100 active clients, and your complaints are about training and data entry discipline, do not build. Configure AxisCare properly, enforce app usage, and spend the $60,000 you just saved on caregiver retention. Custom software fixes structural problems. It does not fix an office that never adopted the tool it already has.

The build signals are structural: you operate in two or more states with different EVV aggregators; you maintain the same clients in AxisCare and Alora simultaneously; a full-time employee's actual job is reconciling systems, spreadsheets, and paper; or your growth math is broken, meaning every 50 new clients forces another back-office hire. When two or more of those are true, you are already paying for custom software in salaries. You are just not getting the software.

How to choose a developer for home health and senior care software

Four filters that separate builders who know this industry from builders who will learn it on your budget:

• Make them explain your state's EVV path. The right answer names the alt-EVV specification, the certification and testing process with Sandata or HHAeXchange, and reason code handling. "We will build an API integration" is not an answer, it is a research project you are funding.
• Push past the word HIPAA. They should volunteer a signed business associate agreement, encryption at rest and in transit, role-based access with audit logs, and a lost-phone plan that keeps protected health information (PHI) off the device entirely. Anyone reciting "we build HIPAA compliant apps" without those specifics is reciting.
• Ask how the app behaves with no signal. Demand a walkthrough of offline clock-in, local storage, sync conflicts, and what the EVV timestamp looks like when a caregiver's phone reconnects three hours later from a rural dead zone.
• Have them do authorization math out loud. Give them 40 authorized weekly hours, a 42-hour schedule, and an auth expiring on the 15th. A developer who has built for this industry immediately talks about hard stops, overrides, and exhaustion forecasts. One who has not will talk about dashboards.

The right partner will also tell you when not to build. That is the fastest credibility test there is.