McKesson
2025-2026
Unlocking Prescription Routing
Only McKesson could change the rules that decided where prescriptions got filled. I led design of the tool that lets pharmacy chains set those rules themselves.
Lead Product Designer
Lead Complexity Fighter
Team of 12
6 Engineers, 4 Product Folks
1 Year, 5 Months
Total Project Timeline
Overview
What was this project about?
Traditional local fill
Central fill is more complex
What this platform controls
The Problem
McKesson's routing engine decides whether a prescription is filled at the local pharmacy or sent to a central fill site. The logic worked, but it lived in code, so every change a pharmacy chain wanted became a request to McKesson.
The Solution
I led design of Central Fill Manager, a web admin tool inside McKesson's pharmacy platform (EnterpriseRx) that turned that legacy logic into intuitive configurations that pharmacy chains can see and change themselves.
How it Works
Inside the Rules Check ( )
In a pharmacy chain, there are 3 levels of groupings. Each determine the associated quantity of pharmacies and permissions.
01
Corporate
The chain's head office. Rules set here reach every pharmacy below.
02
Node
A regional group of pharmacies. Changes here stay within the node.
03
Pharmacy
A single store. It follows the rules above unless an admin deliberately overrides them.
Who uses it?
Admins at the chain decide which drugs can go to central fill, which sites can fill them, and in what order. Pharmacists never open the tool. They fill as usual and the routing happens behind them.
Example
A prescription for atorvastatin arrives at a store.
One prescription, four questions. CF Manager is where admins set the answers.
Research
Nobody could see how routing was decided.
Goal
Understand how routing decides before designing a screen, because I couldn't design controls for logic nobody could explain.
What I did
Ran working sessions with McKesson's product owners
Reviewed the old admin screens and configuration files
Mapped a prescription's path through the system
What I learned
The engine re-checks every prescription four times, and nobody outside McKesson could see that.
What it changed
01
Admins changed settings at the wrong level.
So the tool shows how far a change will reach before you make it.
02
Admins couldn't trust what a rule caught.
They built drug lists by hand, so every row says why it matched.
03
Site data already lived in the main platform.
So each piece of data gets one home, and CF Manager only configures routing.
Process
Design Process
Two workshops to set direction, then one loop on repeat.
I led two workshops with every stakeholder to agree on what had to be built.
Working session with users and the product team, design in Figma, test with four pharmacy chain admins, revise within three days
Why this cadence?
Routing rules are too complex to get right in one pass, so I kept each round small enough to test and fix inside a week.
Design
Two key decisions that shaped the platform.
Decision 1: Corporate sets the rules. Pharmacies keep their exceptions.
Problem
Chains needed the same routing rules across every store, but rules had to be configured one location at a time.
Hypothesis
If changes flow down from corporate, an admin sets a rule once and every pharmacy follows.
Testing
Customers liked it, but individual pharmacies had local exceptions that a pure top-down model would erase. The nuance had to be respected.
Shipped
Each pharmacy keeps a Retain Locally Rx List, so its exceptions stay local and everything else still follows corporate.
Decision 2: Match prescriptions to what a site can do.
Problem
Prescriptions needing specialty labels, like braille or large print, almost never went to central fill.
Hypothesis
If each fulfillment center lists what it can handle, the system can send those prescriptions to a capable site instead of ruling them out.
Testing
Customers liked it and named other criteria worth attaching to a site.
Shipped
Each center's profile now carries all prescription criteria, and the system matches on all of them.
Results
More prescriptions going to central fill. Less manual work for all.
Lessons
What i'd carry into the future
Learn the logic before drawing screens
With rules this complex, I dug into the details early and kept going back to them. That shared foundation is what keeps new complexity and scope from surfacing late in a project.
Bring engineers into design early
Leading design on a project this size can feel like development is waiting on you. Bringing engineers into our design conversations cleared technical concerns early and made the handoff smoother.
Shape the component library before it shapes the product
We built on Material Design and a limited component library, and the visuals landed somewhere I didn’t love. I put my effort into making the functionality and core UX hold up. Next time, I’d advocate for a more robust libary to match the needs of heavy enterprise software like this.
