Multi-State Pharmacy Routing
Routing a telehealth prescription to the right pharmacy depends on state law, drug schedule, inventory, and SLA. Inside the routing engine that makes it look easy.
When a patient clicks 'place order,' a quiet decision happens in the background: which pharmacy fills this prescription, and how does the order get there? In a single-state, single-pharmacy world, this is trivial. In a national telehealth operation with dozens of SKUs and multiple pharmacy partners, it becomes one of the most consequential systems in the stack.
What the router actually decides
For every prescription, the router answers four questions: who is legally allowed to fill this in this state, who has the inventory today, who can meet the patient's shipping SLA, and what's the cost-quality trade-off. The answer changes if any of those inputs change — sometimes within minutes.
Modeling state and drug rules
State pharmacy law and DEA scheduling rules aren't a spreadsheet you set once. We model them as versioned policies the router evaluates at decision time, so a regulatory change becomes a config update, not a code deploy. Every routing decision references the policy version that produced it, which is essential for audit.
Inventory, SLA, and the live picture
Pharmacies expose inventory and capacity differently — some via API, some via flat-file feeds, some via portals. We normalize that into a live view the router queries on every order, with sensible fallbacks when a partner feed goes stale.
Failover without dropping the patient
If the primary route fails — out of stock, integration outage, license issue — the router cascades to the next eligible pharmacy without bouncing the order back to the operator. The patient sees a fulfilled order; the operations team sees a clean audit trail of why the route changed.
Designing for new partners
As the platform grows, new pharmacy partners are added for better pricing, faster shipping, a new drug class, or a new state. The routing engine treats pharmacy partners as plug-in adapters, so onboarding is integration work, not a re-architecture.