Why One Software Can't Run Both Home Health and Home Care (and How We Solved It)

When we started building, the plan was simple: one product, two modes. Home health agencies would toggle one switch, home care agencies would toggle another, and the same software would serve both. It made sense as a slide. It made sense as a roadmap. It made sense to investors.

It did not make sense to users.

Six months in, we had built a single application with a mode setting that swapped the schedule view, the documentation form, and the navigation. On paper it looked clean. In practice, every screen was a compromise. Home health users wanted more clinical depth than the home care UI could carry. Home care users wanted a faster, simpler version of the screens we'd built for clinicians. Every product decision had two stakeholders and one of them was always unhappy.

We eventually killed the unified version and shipped two separate products on the same engine. This post is about why.

The architectural fork

The deepest fork between home health and home care is not regulatory. It is structural. The two industries treat fundamentally different things as the primary unit of work.

In home health, the primary unit is the patient. Everything orbits around a patient: cert periods, OASIS, plan of care, visit frequency, care team. The schedule is a derivative of the patient's plan. If you ask "what's happening Monday at 10am," you'd get back a list of patients with visits due — and the route optimization is about which clinician drives the shortest path between those patients.

In home care, the primary unit is the shift. Everything orbits around the shift: who's covering it, what tasks are authorized, EVV check-in, ADL log, hours burned against the authorization. The schedule isn't derivative of anything — it is the product. If you ask "what's happening Monday at 10am," you'd get back a list of shifts with caregivers assigned (or unassigned and open) — and the optimization isn't about routing, it's about fill rate.

That difference looks small until you try to build software for it. Then it gets very large very quickly.

What broke

Here are the specific places the unified product broke down.

The schedule view

The home health calendar wants to show patient names with visit types color-coded by discipline. A clinician's day is six 45-minute visits across six patients in a 30-mile radius.

The home care shift board wants to show open and filled shifts color-coded by status. A scheduler's day is staring at a wall of recurring shifts and figuring out which caregiver can cover Mrs. Johnson's Tuesday-Thursday-Saturday block.

We tried to build one calendar that did both. We ended up with a calendar that did neither well — the home health users wanted patient-focus and the home care users wanted shift-focus, and the compromise made everyone slow.

The documentation flow

OASIS is a hundred-plus items, takes ninety minutes, and is signed by a credentialed clinician. ADL logs are a dozen tasks, take three minutes, and are filled out on a phone in a client's bathroom.

We tried to build one documentation engine that handled both. The result was an engine that was too slow for caregivers and too shallow for clinicians. Nobody asked for a documentation form that took an hour and only captured ten fields, but that's what you get when you average the two.

The data model

Home health software treats patient as the central table. Visits, plans of care, OASIS assessments, cert periods all foreign-key into it. The patient is the persistent thing; the visits are the events.

Home care software is closer in spirit to a staffing platform. The persistent thing is the recurring shift template (or the authorization), and individual shifts are instances of it. The patient/client matters, but the shift is what gets billed, what triggers EVV, what produces the ADL log.

We tried to model both with one schema and ended up writing constant special-case logic to figure out which mode the user was in before answering even simple questions like "what's open this week."

The mental model of the staff

This was the one I underestimated. Home health clinicians and home care caregivers are not the same workforce. RNs and PTs come from clinical-school training and expect software that respects that — terminology, depth, assessment-grade documentation. CNAs and HHAs come from a different training pipeline and need software that respects that — speed, mobile-first, low-friction.

A unified UI tries to be both, and ends up feeling sterile to the clinicians and clinical to the caregivers. Both groups end up calling support more, not less.

The pivot

We stopped trying to merge the two products and split them apart.

Home Health Scheduling is built around the patient. It opens to a patient list. The schedule view is patient-centric. The documentation engine is OASIS-grade. Cert periods, plan of care signatures, route optimization, and CMS submission live at the center of the product.

Home Care Scheduling is built around the shift. It opens to a shift board. The schedule view is shift-centric. The documentation engine is ADL-fast and clock-out-locked. Authorizations, EVV, caregiver retention metrics, and Medicaid waiver tracking live at the center of the product.

Two completely different surfaces. One shared infrastructure layer underneath — auth, payments, multi-tenancy, the rules engine, audit logs, route geometry, the underlying scheduling primitives. We share what should be shared. We don't share what shouldn't.

What we kept shared

Building two products doesn't mean building two of everything. The pieces that genuinely don't care which vertical you're in are shared:

Auth + multi-tenancy. A user belongs to an agency. Agencies are agencies regardless of vertical.
The rules engine. Both products lean on rules-based automation; the rules differ but the engine is the same.
Audit logging. HIPAA doesn't care which vertical you're in.
The geometry library. Driving distance between two coordinates is driving distance regardless of whether the next stop is a SOC visit or a 6-hour CNA shift.
The component library. Buttons are buttons. Tables are tables.

What's not shared: the schedule view, the documentation engine, the data model, the navigation IA, the marketing site, the onboarding wizard, the dashboard. Anything that touches the user's daily mental model is built fresh for each vertical.

The lesson

The temptation to ship one product that serves two markets is strong, especially at the early-stage. It looks like leverage. It looks like efficiency. It looks like the engineering team is being asked to build half as much.

What it actually is is a vote against your users. Two different industries with two different mental models will not be served well by one compromised UI, no matter how clean the abstraction looks on a whiteboard.

The right architectural move — counterintuitively — was to ship two products. Same company, same engine, two different surfaces. We did not realize that until we tried the other way and watched it not work.

If you are a software buyer evaluating "all-in-one" platforms that claim to handle both home health and home care: ask to see the schedule view. Ask to see the documentation flow. If the answer to "show me how a home health clinician does an OASIS" is the same screen as "show me how a home care caregiver fills out an ADL log," the product was designed for the slide, not for the work.

We learned this the expensive way. You don't have to.

Home Health Scheduling is built specifically for home health agencies and solo clinicians.

Home Care Scheduling is built specifically for non-medical home care agencies.

Same engine, two surfaces — because the work is genuinely different.