Rebuilding the drug-safety check to run in real time

• Legacy gate
  Async check inside the monolith; results lag the live record
• Requirements
  Six check types, real-time execution, severity and acknowledgement
• Offline replay
  Historical executions re-run outside production; 99.42% match
• Dial-up0 to 100% with go/no-go checkpoints
• Result
  3x faster; 99.75% automated; manual reviews cut 5x; zero incidents

Product workflow, shown through the decisions and handoffs.

The decision

The product decision was to replace the asynchronous review path with a synchronous service. The launch account describes historical replay before live rollout.

Option	What it would give	Why not / why
Improve the pharmacist interface only	Less friction	Leaves the lag and the 1.5% manual fallout untouched
Patch the async service	Some latency gain	Still asynchronous
Standalone synchronous service (chosen)	Live data, scalable, measurable	Requires offline validation and a careful dial-up

What I learned

Validate against history before touching live traffic, and make the dial-up a sequence of decisions rather than a date. In healthcare, launch is when you have proven safety at scale, not when the code ships.

My reflection

I was the product co-lead with an engineering partner. I wrote the requirements for all six check types, the real-time execution model, severity classification and the acknowledgement and follow-up workflows; drove alignment across pharmacy operations, patient safety and engineering; managed the offline validation; and wrote the launch announcement, which was read by more than a hundred stakeholders.

The gate

Drug-utilisation review helps pharmacists assess interactions, allergies, contraindications, duplicate therapy and dose. In the workflow I worked on, information freshness and the responsiveness of the check both mattered. A review that arrives quickly but reflects outdated context does not solve the same problem as a current, usable result.

The decision I owned was to modernize the supporting service rather than only improve its presentation. Synchronous interaction makes responsiveness part of the professional’s experience; asynchronous work has different tradeoffs around freshness and delay. I wrote requirements covering the relevant checks, understandable severity and acknowledgement, and made the responsiveness budget part of the acceptance discussion.

Then the question that governs everything in this book: how do you establish sufficient evidence before changing a safety-related product? We compared historical examples against the replacement, investigated disagreement classes and used that evidence in readiness reviews with specialist partners. I wrote the launch communication against the criteria established before build, including responsiveness, successful handling and manual effort.

I also worked on verification capabilities and the pharmacist’s experience. The product question was not simply whether the interface looked newer, but whether a professional could complete the task dependably. Throughput and user effort were adoption considerations alongside technical behavior. I connected the modernization with requirements and launch readiness.

Separate prescriber-verification work also addressed an operational dependency on engineering. That account is distinct from the DUR service rebuild.

Tools and methods: synchronous service design, historical replay, launch readiness and staged rollout.

Drug utilization review supports clinical-safety checks in the pharmacy workflow. The rebuild replaced an asynchronous path with a synchronous service. Related pharmacist-verification platform work is a separate initiative.

How it shipped

The launch account describes a staged rollout with readiness reviews. Verification-platform adoption belongs to a related initiative and is separate from this service rebuild.

Results

The rebuild account reports faster checks and less manual review. A narrower follow-on dose-check fix is reported separately. Verification-platform adoption and savings belong to another initiative and are not outcomes of this service rebuild.