OSRM
We host OSRM on a single c6a.large in the same AWS region as the planner. It answers in two to four milliseconds for cache-hits, six to ten for cache-misses. It is free per call. It is the answer for 99% of distance queries.
One thousand patient draws to plan. Eleven constraints to honour per assignment. A four-hour planning window collapsed into minutes. A STAT walk-in re-routed in under thirty seconds. And the whole thing has to be auditable, three years from now, by a person who wasn't there.
Every number measured against the manual baseline that the operations team used before. No demo-mode comparisons.
A typical metro home-phlebotomy operation has thirty technicians, a thousand draws a day, and an operations lead who arrives at 5am to plan the routes on a whiteboard. They are tracking fasting windows, PT/INR peak-trough windows, specimen-stability drop-off deadlines, certification levels, equipment compatibility, contiguity, and the rest. The plan is finished by 7am. Five technicians call in sick. Three patients walk off. Two specimens hit their stability cliff. One STAT comes in from the hospital. The whiteboard is wrong by 8am.
The off-the-shelf dispatch software does not understand any of this. It treats a draw like a pizza order — distance and time, nothing else. So the operations lead patches it manually, and the engineering team builds an "AI routing" feature next quarter. We were called when the next quarter became this quarter.
This is the pipeline the dispatch engine runs every morning, and every time a STAT walk-in changes the shape of the day. Each stage is a real piece of the production system — not a re-creation. Step through, or let it advance.
24 orders, 3 technicians, one depot. No structure yet — just dots on a map and constraints in a database. This is where every shift starts.
POST /orders/batch?day=2025-10-14Every routing decision in Phlebtrax writes a full audit record — every constraint result, every alternative we considered, every score factor that drove the choice. This is the actual record for order S04 · West End.
Normalizes inbound orders from EMR webhooks, lab requisition imports, and the call-center app. Validates patient ID, draws a hash of PHI fields for downstream redaction, and stamps a UUID that follows the order through every downstream step.
Distance queries do not all need the same answer. Most need cheap and accurate; STAT needs traffic-aware; emergencies need anything. The cascade lets us tune the spend without losing the ability to operate. Pick a scenario.
We host OSRM on a single c6a.large in the same AWS region as the planner. It answers in two to four milliseconds for cache-hits, six to ten for cache-misses. It is free per call. It is the answer for 99% of distance queries.
Reserved exclusively for STAT walk-ins where traffic-aware ETA actually matters and the request count is small. Bypasses our OSRM cache because the value of the call is in 'now', not in 'recent'.
The cheap, dumb, last-resort straight-line distance. Used when OSRM is unavailable and the system needs to keep moving. Worse routes — but the system never stops.
Each tier has a clean adapter behind it. Adding a fourth provider — Mapbox, HERE, a private gazetteer — is a one-class change. Swapping out Google Maps when its prices move is a config flag, not a rewrite.
We could have written our own. We have written ours before. OR-Tools is twelve years of routing research compressed into a battle-tested C++ engine, with first-class Python bindings, that other engineers will recognize on the team in three years. Choosing OR-Tools was choosing to be replaceable.
Hierarchical produced cleaner cluster shapes but at O(n³) it became the bottleneck above 200 stops. K-Means at O(n·k·iterations), with our capacity-aware reassignment step, handles 1,000+ stops in under a second on a single core. Aesthetics lost.
Modelling fasting-window violations as a score penalty meant the optimizer would sometimes 'pay' for the violation and still produce a route that broke clinical safety. Hard constraints cannot be paid for. Score factors can.
We tested 'recompute when audit asks'. It took 19 seconds for a single day's decision and assumed all upstream services were still running. The ledger is 200 KB per day. The choice was not close.
Day-one Google Maps spend was $80–$200/day at a tenth of target volume. With OSRM-primary, the bill is single dollars. The difference funds three months of engineering every year. We pay Google when we actually need traffic-aware routing — i.e., almost never.
An LLM with a routing tool would have shipped a demo in two weeks. It would also have made decisions we could not defend to a regulator, retrained itself with subtle distribution shift, and burned cents per inference for a problem rules solve in milliseconds. Phased maturity is the path.
Every phase is shipped in production with an explicit fallback to the phase before it. There is no flag day, no "we replaced the rules engine," no live customer ever discovers that the system below their dispatch has gone from determinism to a learned model.
Deterministic, fast, auditable. Every decision can be traced through a constraint filter and a scoring formula with weights stored as configuration. Zero training data required. Drift cannot happen because there are no learned weights to drift. This is where every Phlebtrax tenant starts, and where most stay.
Where rules consistently produce a sub-optimal answer for a known scenario (specimen rejection at the lab, technician complaints about a specific pairing), we train an XGBoost model on the historic decision log + outcome data and let it nudge the weights. Still explainable: SHAP values for every prediction. Falls back to rules if the model's confidence is below a threshold or the input is out of distribution.
Not for dispatch decisions — for explanation. A local LLM turns the audit record into prose for operators and regulators: 'Tech 02 was selected because the fasting window required arrival before 09:00, Tech 01 was already committed, and Tech 03 lacked the PT/INR certification.' The LLM never decides; it only narrates from the structured record.
No new framework adopted in production. No new database introduced. No proprietary research published. The work was in choosing the right algorithms, modelling the right constraints, and writing the audit ledger so the operations team — and three years from now, a regulator — can ask any question and get an answer.
We have applied this architecture pattern to home phlebotomy, mobile imaging, in-home infusion, and discussed it for last-mile delivery, HVAC dispatch, and mobile mechanics. The constraint vocabulary changes. The bones don't.
If you're thinking about AI for your business and you want to talk to someone who will tell you the truth — including when AI is the wrong answer — book a call. We'll spend 30 minutes understanding what you're trying to do, what you're worried about, and whether we're the right fit.