Route optimization
Same patients, same time windows, a different order, and a fifth to a third less driving. Here is why that gap exists, what a real solver has to handle, and how to judge the savings anyone quotes you.
Home health routing is a vehicle routing problem with time windows, and it is genuinely hard: the number of possible visit orders grows faster than any person can hold in their head past about six stops. Which is why the order most clinicians drive is the order the visits were entered, or the order they have always driven, and why the miles quietly pile up.
Take six patients across a town. Driven in the order the referrals arrived, the day crosses the same ground several times. Driven in a good order, with the same six patients and the same time windows, the driving falls by a fifth to a third. Nobody is dropped and nothing is rushed; only the sequence changed.
That difference is paid for twice. Once in fuel, which in home health is very often the clinician's own. And once in time, which is the hour they get home late.
We built a free calculator that puts your own numbers into that, with the arithmetic printed so you can check it against your odometer rather than trust a marketing figure.
The day is solved as a vehicle routing problem with time windows using Google OR-Tools. Arrival time is the variable being reasoned about, so a visit that cannot be reached inside its window is identified as such rather than silently scheduled at an impossible time.
Every unpinned visit carries a penalty for being left out rather than a hard requirement. An over-full day returns what fits, plus a human reason for each visit that did not: no capacity that week, no window that works, too far.
When a visit cancels, the app solves the day once as a baseline and once per candidate patient, then ranks them by the driving each would actually add. A candidate the solver refuses genuinely does not fit.
Drive estimates use real road data rather than straight-line distance, and every lookup happens on servers we run, because a patient's address is not something to hand to a mapping vendor from the phone.
Buying them separately is why so many agencies have a tidy calendar and an exhausting week. If the scheduler assigns the week without knowing distances, the router can only make the best of a bad set. Obillions plans the week and orders the day with the same model, so the assignment is made knowing what it will cost to drive.
Deciding the order in which a clinician visits their patients so that total driving is as low as possible while every time window, visit length and break is still respected. It is a vehicle routing problem with time windows, not a sorting task.
Published figures for route optimisation generally fall between ten and thirty percent, but the honest answer is that it depends on your territory, how tight the time windows are and how good the current order already is. Ask any vendor to demonstrate it on your own addresses.
Google Maps optimises a handful of stops with no time windows, no visit lengths, no clinician constraints and no way to re-solve when a patient cancels. It is a navigation tool, not a scheduler.
It should be named with a reason you can act on: no capacity in the week, no time window that works, too far from the rest of the day. Obillions returns what fits plus that reason rather than refusing the whole day.
It plans the day, shows the route and hands the drive to Apple Maps or Google Maps for the turn-by-turn, sending coordinates only.
Not from the phone. Addresses are turned into coordinates by servers we run, because a patient's address is protected information and only servers under our control should see one.
A voice agent for a day of visits. You say what changed and the day re-plans itself: the order, the drive times, and who nearby could take the hour a cancellation just freed. Nothing changes until you confirm, and your voice and photos never leave your phone.
In private testing now. A public TestFlight comes next, then the App Store.