Ordering, dispensing and receiving.
Ordering, dispensing and receiving across BESTMED's two connected systems: Facility, on the ward, and Pharmacy, in dispensing. It covers an order from the moment a nurse raises it to the moment the delivery is checked in against it.
Facility, on the ward
- order.submitted, Facility to Pharmacy
- order.status.changed, Pharmacy to Facility
- order.line.dispensed, Pharmacy to Facility
- order.completed, Pharmacy to Facility
- delivery.receipted, Facility to Pharmacy
- discrepancy.reported, Facility to Pharmacy
Pharmacy, in dispensing
How both systems were mapped.
Four maps, drawn live in business-analysis sessions: the seam as it stands today, then each module end to end, then the one mechanism that has to cross between them.
Everything the facility can raise converges on a single press, and that press puts one row in the pharmacy queue. The only other thing that crosses the boundary is the message thread - status comes back, nothing else does.
The whole module on one page. Every order type is staged in the cart and leaves in one submit; the right-hand half - everything after the delivery arrives - has no counterpart in the current ordering flow.
Five fixed stages, one hold loop, one gate that cannot be skipped. Solid arrows advance, rust arrows hold, the dashed green route is Send to skipping forward, and the dashed grey route is release.
The dispense label barcode is the only identifier physically attached to the medication. It is created once and read twice, and each read answers a different question. The third step is not a scan at all.
Facility
Receiving sits outside ordering.
Raising an order means choosing from six separate tiles, four of which submit immediately - no cart, no review, no undo beyond a separate Cancel afterwards. Rows can appear locked with no explanation, and the Urgent flag is hidden by a facility-level setting more often than not, so the warning about ordering after cut-off appears on a form with no way to mark the order urgent. The bigger gap is that receiving isn't part of the ordering flow at all. Check-in lives in BESTtrack, a separate module, and it is entirely manual: the nurse searches for each resident by name, opens them one at a time, picks the medication and types in the current stock level. Nothing on that screen refers to the order it answers, so a delivery is never checked against what was ordered, and the pharmacy never hears what actually arrived.
Pharmacy
The queue disagrees with itself.
The queue's default date range silently disagrees with the count that linked into it, so clicking a facility's own "22" can land on "No items to display." Its summary labels don't match the queue's actual states, so the pharmacist translates on every click, and the task spans three different shells with browser back crossing app boundaries. "Add to Dispense List" doesn't add anything to the dispense list - it silently sets the order to Pending - and when a dispensing report does load it arrives with every row pre-ticked, so one press of Dispense can dispense an entire facility's orders at once with no confirmation, no toast and no undo.
Closed loop
Six events, one barcode.
The redesign closes the loop with six named events crossing between the two systems. Most of them run through one mechanism: a dispense-label barcode, created once by the pharmacy at Confirm dispense and read twice - at the pharmacist's own check, and again by the ward at goods receipt. It's the one field that has to be written back to Facility for the ward's scan to mean anything; without it, check-in degrades to a manual checklist.
On the facility side, ordering becomes one screen with five tabs replacing the six-tile hub, the cart becomes a real review step, and Deliveries brings receiving into the ordering flow: a scan-gated check-in list, a decision tree for what a scan resolves to, and a discrepancy report the pharmacy can act on. On the pharmacy side, the queue becomes five fixed stages - Unprocessed, Pending, Waiting, Check, Completed - with role gates printed on the actions themselves, so a Packer accepts, dispenses and hands off, a Technician can move and hold orders, and only a Pharmacist or Manager can scan an order off into Completed.
Facility
One screen, five tabs, and a receiving gate.
Prototype captures from the tablet design, not yet tested with nurses. The five tabs replace a six-tile hub; the three check-in states are what happens once a delivery lands on the ward.
Pharmacy
Unprocessed, Pending, Check, Completed.
The Product Manager started the pharmacy rework. I helped shape the solution and produced the UX and UI designs: five fixed stages, with role gates printed on the actions themselves. One plate per stage follows, then the stage picker and the teams a pharmacy owns.
Traceable rather than assumed.
Success means an order can be traced from the moment a nurse raises it to the moment it's verified on the shelf, across two separate products built by two separate teams, with no manual reconciliation step in between. The six crossing events and the shared barcode make that traceable rather than assumed.
Neither side has shipped. The pharmacy side has been through sanity-check sessions with pharmacists; after a round of UI refinement, the business analyst writes the specs and it moves into development. The facility side follows, and hasn't been tested with nurses yet.