Centralized Medication Purchasing: Multi-location inventory and procurement workflow design
UX Research & Design Strategy Lead
Optimizing centralized medication purchasing across 84 treatment locations.
A large oncology practice with 84 treatment locations and a centralized warehouse needed to answer one question, over and over, every day: what does each site actually need, what do we already have on hand, and what still has to be ordered from McKesson? That question was being answered through spreadsheets, email, and manual routing. I modeled the entire decision into Lynx.
As research and design lead, I ran discovery with the practice's procurement and pharmacy operations teams, mapped their existing purchasing process end to end, and designed a purchase-order workflow that gives centralized buyers a single place to compare site demand against warehouse inventory, route orders, and manage exceptions — replacing a fragmented, external process with one built natively into the platform.
A high-volume, multi-location purchasing operation with no native home in Lynx.
This wasn't a simple form-to-order feature. It was a coordination problem spanning dozens of locations, a central warehouse, and a procurement team that had to reconcile all three before a single order could be placed.
Treatment sites drawing from one centralized warehouse.
Purchase orders submitted per day across the practice.
Coordinated via spreadsheets, email, and an external 4-day demand report.
The buyer wasn't simply placing purchase orders. They were trying to answer: what do my 84 locations need, what do I already have in my central warehouse, what can I redistribute internally, and what actually needs to be purchased from McKesson?
A centralized buying decision that had no centralized system to support it.
The research reframed this from "add a purchase order screen" to "bring an entire purchasing ecosystem into Lynx" — procurement governance, warehouse-vs-site inventory comparison, station-level routing, and exception handling all needed a home in the product.
The practice's existing process ran almost entirely outside Lynx. A report generated externally every four days told pharmacy staff what to consider ordering. From there, purchase orders moved through a centralized procurement review before ever reaching a distributor — a workflow Lynx didn't support, since it was built to send orders directly to distributors with no buyer review step in between.
I mapped the practice's full purchasing workflow — how the external demand report was generated and used, how orders moved through procurement review and approval, how the practice separated orders by treatment station rather than by clinic, and how add-on and exception orders were handled outside the standard flow. That gave the team a complete picture of what "centralized purchasing" actually required, rather than treating it as a single missing screen.
Because the practice operates a central warehouse, every purchasing decision was really three decisions stacked together: what does this site need, what do we already have in the warehouse that could fulfill it, and what actually has to be newly ordered from McKesson. None of that reconciliation had a shared system — it lived in whichever spreadsheet a given buyer happened to maintain.
Lynx sent orders straight to the distributor with no review step, no warehouse-inventory comparison, and no concept of a treatment station distinct from a clinic. For a practice this size, that meant the platform simply couldn't represent how they actually bought medication — so the workflow stayed external, manual, and invisible to Lynx.
Discovery sessions surfaced a workflow built around procurement governance, not just ordering.
I ran discovery sessions with the practice's pharmacy operations and procurement teams to document their current-state process end to end, then translated that into requirements for a native Lynx workflow.
Demand lived outside the platform
An external report, generated on a 4-day cycle, told staff what to consider ordering. Purchasing decisions were made from that report, not from anything inside Lynx.
Procurement review was mandatory
Orders had to be created, pre-approved, and then reviewed and submitted by a centralized procurement team — a multi-step approval Lynx didn't model at all.
Stations, not just clinics
The practice organized orders by treatment station within a location, while Lynx only recognized the clinic level — a structural gap, not a cosmetic one.
Add-ons needed their own path
Once submitted, an order was locked. Anything needed after that point required a separate add-on request with its own cutoff times and ticketing process.
Purchase order tracking, by facility and status
The resulting workflow gives centralized buyers a single view across every location — order status, who created and reviewed each order, and full audit history — replacing what had lived across spreadsheets and email threads.
This wasn't a request for a purchase-order form. It was a request to bring an entire procurement governance model — buyer review, station-level routing, warehouse-vs-site inventory comparison, and exception handling — natively into Lynx.
Understanding the full governance model up front meant the design didn't just digitize a spreadsheet — it gave centralized buyers a structured way to reconcile site demand, warehouse stock, and new purchasing in one place, for the first time.
The real design problem was inventory reconciliation, not order entry.
What looked at first like a missing purchase-order screen was actually a multi-location inventory orchestration problem: comparing what each site needs against what a central warehouse already has, before ever generating a new order to McKesson. Designing for that reconciliation — not just the transaction at the end of it — was what made the workflow actually usable for a practice operating at this scale.
This is the same pattern behind Auto Queue and Treatment Readiness: the visible action in Lynx (dispense, submit an order) is often the last step in a much longer, mostly invisible decision. Designing for the decision, not just the transaction, is where the real product opportunity lives.
What this changed.
The resulting workflow replaced a manual, external, 175-order-a-day process with a native Lynx model: centralized buyers can now compare treatment-site demand against warehouse inventory, fulfill from available stock first, and determine what still needs to be ordered from McKesson — all with buyer review and add-on exceptions built in, across all 84 locations.
Reducing the manual coordination this required helps practices maintain medication availability for upcoming treatments, and gives McKesson a template for supporting other large, multi-location customers with centralized purchasing operations.
Another example of designing for the hidden decision behind a visible Lynx action — this time for treatment prep instead of purchasing.