Unnat Patel

Work · 6 of 17 · Deep dive · 4 minutes

On this page
  1. Attach the safety check to the order at dispense, and launch it through explicit go/no-go gates, one state first.
  2. The decisions
  3. What I owned
  4. The situation

Healthcare / Case study

A safety check before dispense, launched through a phased rollout

I led the requirements and phased rollout of a safety check closer to dispense, aligning readiness with clinical and operational partners.

5 min read
Amazon Pharmacy · from my work, written for public reading

01

1 / 9 · Executive brief & flow

Attach the safety check to the order at dispense, and launch it through explicit go/no-go gates, one state first.

  • Evidence
    Millions of dispenses: 12.1% filled with a different NDC than verified
  • Data model
    DUR tasks attached to orders, not prescriptions
  • Gates
    125 tests; production test; four-function go/no-go
  • Phase 1
    One state, a small group of pharmacists, day shift
  • Phase 2Phased expansion with readiness reviews

Product workflow, shown through the decisions and handoffs.

What I learned

Make risks and mitigations explicit, review readiness with responsible specialists, and expand only with evidence that the workflow supports safe operation.

From my original account

02

The decisions

The product connected the safety review to the work being completed, with clear exception handling and communication for unresolved cases. I aligned the customer experience with clinical authority and operational readiness.

GateWhat it requiredOutcome
QA sign-off125 functional tests115 passed; 10 blocked tests covered paths that cannot be simulated in test and became day-one production validations
Production test12 orders across every disposition pathPassed
Go / no-goAt least one approval each from patient safety, compliance, legal and operations, conditions in writingApproved

03

What I owned

I was the product lead. I wrote the functional requirements for DUR at refill and fill, the dial-up plan and the clinical task-workflow blueprints, and led alignment across patient safety, legal, compliance, operations and the customer AI team.

When the context changes

An earlier review can be appropriate when performed and become insufficient when relevant context changes. I worked on that product question: how should a later action remain aligned with the information and decision that preceded it?

I partnered with business intelligence to analyze historical records. We found differences between the context that had been reviewed and the context of a later action. That evidence made the scope of the earlier decision a product question. The important discovery was not only that a difference existed, but what it meant for the qualified person responsible for acting.

Building the change required agreement about what the decision covered and who could reconsider it. I wrote requirements and led alignment with Patient Safety, Legal, Compliance, Operations and technical partners. A contentious question concerned how to handle an unresolved condition without leaving the customer facing unexplained uncertainty. We had to resolve the customer experience and the professional boundary together.

The launch is one I use to explain how I approach risky work. Requirements were connected to scenarios, environment limitations were made explicit, and readiness was reviewed with the responsible functions. We began with a bounded introduction and expanded against agreed evidence. The point was to learn while preserving responsibility, rather than let the deadline stand in for a decision.

Training shipped with the change. Design helped create a prototype-based walkthrough, and operations received supporting procedures. That work mattered because a correct system can still create a poor experience if people do not understand their role. We reviewed early use alongside the original acceptance criteria.

Then the noise problem from the prologue. More frequent evaluation can increase interruptions unless the quality of the signal improves. I treated alert fatigue as a program of cause analysis and specialist review: preserve meaningful coverage, correct avoidable noise and examine where improved information enables better checks. Coverage and professional attention belonged in the same discussion.

Tools in this chapter Redshift SQL · BI partnership · order-level data model · state-aware task routing · functional test reports · go/no-go · staged dial-up · LMS training · SOPs

04

The situation

Patient context can change between verification and dispense. I worked with business-intelligence partners to investigate that gap and define the scope of a safety check closer to dispense.

How it shipped

I led a phased rollout with specialist readiness reviews, explicit exception handling and supporting training. Expansion followed agreed evidence rather than a public date or timing comparison.

Results

More than 800,000 pharmacist tasks completed . The cancellation rate is 0.5%, with two new reason codes, and is expected to settle near 0.3% following the pilot state’s trajectory. A rejections deep-dive dashboard tracks reasons, patient-safety outcomes, customer impact and pharmacist-level performance for coaching. Pre-launch requirements projected about 1% of orders on hold; I report the actuals.