Home Health Care Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build expand from one state and one line to everything at once?

The first release that works is deliberately small. The caregiver mobile app, scheduling with a matching engine, the authorization ledger and Electronic Visit Verification integration for one state, while your clinical system keeps handling assessments and Medicare claims. Ten to fourteen weeks, $40,000 to $90,000 in our delivery experience.

What expands it is that every part of the agency has been waiting. The biller wants claims. The clinical director wants documentation. The owner wants the family portal that a competitor advertises. And because the agency operates in three states, somebody points out that building for one state and then doing it again seems wasteful, which sounds obviously true and is not.

It is not true because each state aggregator certifies separately, with its own specification, its own test cases and its own queue. Three certifications in parallel does not cost three times one, it costs more, because your one person who understands the visit data model is now answering three sets of test findings at once while development waits.

The scoping rule that holds is to define phase one by a single billing path end to end. One state, one aggregator, one payer type, from clock in on a phone to a submitted visit that clears. Prove that path completely, then repeat it. Repeating a proven path is genuinely faster the second time, because the data model is settled and only the specification differs. Building three unproven paths simultaneously is how agencies end up nine months in with nothing submitting anywhere.

What goes wrong when you migrate clients, authorizations and schedules?

Three things carry real risk and one of them can produce unbillable care on day one.

Authorizations are the dangerous item. In the old system an authorization is often a note, a date range and a number of units, with the actual consumed units known only by subtracting what was scheduled. Migrating the number without migrating consumption produces an opening balance that is wrong, and a scheduler booking against a wrong balance delivers care nobody will pay for. Every authorization needs its remaining balance reconciled against actual delivered and billed visits before it goes live, and any that cannot be reconciled needs a supervisor decision rather than an assumption.

Client identity is the second. A multi line agency has the same person in two systems with different identifiers, different addresses after a move and sometimes a different spelling. Merge carelessly and you attach one client's plan of care to another. Do not merge automatically. Produce a review list and have a nurse confirm it.

Caregiver credentials are the third and the quietest. Certifications, competencies and background check dates live in a mix of the scheduling system and a filing cabinet. If the matching engine trusts incomplete credential data it will offer shifts to caregivers who are not qualified for them, which is a compliance problem wearing the costume of a feature.

Plan for four to six weeks of parallel running on a defined subset of clients before full cutover, with the old system authoritative for billing throughout that window. The subset should include your most complex clients, not your simplest, since a pilot on straightforward companion care proves nothing about authorization enforcement.

Why does the caregiver app fail in the field after launch?

The demo works. The pilot works. Then it meets a basement in February and the reasons are consistent.

Signal is the obvious one and it is only half the problem. The other half is that many builds capture visits offline but load reference data online, so the caregiver can clock in with no signal but cannot see the task list from the plan of care, because that came from the server. A half working app produces paper, and paper cannot be validated or searched.

Device reality is the second. Aggressive battery savers on inexpensive Android handsets suspend background processes, so a clock out queued for sync never leaves the phone. Location permission gets reset by an operating system update and the app keeps running while silently recording nothing usable. Neither of these produces an error the caregiver can see.

Geofence geometry is the third. Apartment complexes, care facilities and rural addresses with imprecise geocoding generate exceptions on entirely legitimate visits, and an exception rate high enough to be annoying teaches everyone to ignore exceptions.

The fixes are specific. Cache the full day of clients, plans of care, tasks and rates locally, not just the capture forms. Show the caregiver a visible sync status with an unmistakable indicator when records are still waiting, and alert the office when a device has not synced within a defined window. Record clock in times on the device rather than at sync, so a three hour reconnection does not corrupt the visit record. Draw geofences per client, by hand where needed, with a documented radius override for complexes. And test on the worst phone on your roster, which means buying one, not borrowing the office iPhone.

What happens when the authorization ledger is not wired into scheduling?

Almost every system in this category records authorizations. Very few make them behave like a ledger, and the gap between recording and enforcing is where agencies bleed quietly.

The failure shows up in three ways. A scheduler books forty two hours against a forty hour authorization from habit, and nobody sees it until the remittance shows two hours a week paid at zero for six weeks. An authorization expires mid month, visits keep running for a fortnight, and the agency delivers thousands of dollars of care no payer will reimburse. Or a client has two authorizations from different payers with overlapping date ranges, and visits are attributed to whichever one the scheduler happened to pick.

What is common to all three is that the number was visible and nothing prevented the action.

The fix is enforcement at the point of booking rather than reporting after the fact. Booking a visit decrements remaining units in real time. A visit that would exceed the authorization cannot be saved without a supervisor override that leaves an audit trail with a reason. A daily forecast flags every client on pace to exhaust units within a defined window, and expirations generate reauthorization tasks for the nurse with the payer paperwork pre filled. Attribution rules for overlapping authorizations are configured once rather than decided per booking.

The override matters as much as the block. Agencies that build a hard stop with no override find schedulers working around the system entirely within a month, because sometimes care has to happen and the paperwork follows.

Should you build custom or configure what you already own?

Configure if you run one service line in one state with fewer than roughly 100 active clients and your complaints are about training and data entry discipline. AxisCare is genuinely good at private duty scheduling and most agencies use a fraction of it. Sit with your account manager and ask specifically what your licence covers for open shift broadcasting, authorization alerts and app enforcement, then spend the money you saved on caregiver retention instead. Custom software fixes structural problems. It does not fix an office that never adopted the tool it already has.

Configure, and wait, if your main issue is that a third of caregivers refuse the app. That is a management problem first, and building a better app for people who will not use any app is an expensive way to avoid a difficult conversation.

Build when the signals are structural. Two or more states with different aggregators. The same clients maintained in AxisCare and Alora simultaneously. A full time employee whose actual job is reconciling systems, spreadsheets and paper. Or growth math where every fifty 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 do hidden costs get into the quote?

• Each additional state aggregator. Sandata, HHAeXchange and Netsmart certify differently and each certification is its own project with its own queue.
• Claims and remittance. Managed care organisations, waiver programmes, veterans programmes and private pay each behave differently, and a clearinghouse relationship is its own onboarding.
• Genuine offline. A web application in a wrapper is not offline capable, and converting one into the other later touches the data model and every screen.
• Test devices. Buy the cheapest handsets your caregivers actually carry. Testing on good phones is how a launch fails in week two.
• Security infrastructure. Encryption, access logging, a signed business associate agreement and a lost device plan that keeps protected health information off the handset are scope, not assumptions.
• Running cost. Roughly 15 to 20 percent of build cost annually, and the line agencies forget is aggregator specification changes, which arrive on the state's schedule with a deadline attached.

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

Whether the caregiver can complete a visit faster than she could on paper, on the phone she already owns, in a basement. That is the whole adoption question and everything else follows from it. Two taps to clock in, the task list already loaded, the signature on screen, a visible sync indicator. If it takes longer than the paper log, the paper log comes back and you will find out during a survey rather than during rollout.

The second marker is that exceptions get fixed in the home rather than in the portal on Friday. Validate at clock out, while the caregiver is still standing in the living room and a correction takes thirty seconds. What survives to the biller should be a short queue sorted by dollar value and filing deadline, not a week of data janitor work.

The third is that scheduling knowledge moves out of one person's head. Required skills from the plan of care, client preferences and exclusions, drive time, hours worked against the overtime threshold and remaining authorization units, all encoded rather than remembered. That is what turns on call from a punishment into a rotation, and it is the change that makes the agency sellable.

The fourth is a measured baseline. Count unbillable hours, exception volume and overtime for a month before launch, because the improvement is easy to feel and hard to prove, and phase two needs the proof.

The fifth is ownership. Source code, database, infrastructure accounts and documentation transferred to you under a work for hire agreement, confirmed in the contract before signing. Reject any arrangement where the developer hosts a platform you merely licence, because ownership is the entire reason for building instead of renting.