Cutting alert noise without weakening the safeguard

1. Quantify

   Tens of millions of alerts a year; a third need acknowledgement
2. Locate

   Most acknowledgement volume in three conflict types
3. Root cause

   Bulk doses normalized to daily equivalents fired “below minimum”
4. Program

   Eleven optimizations across three themes
5. Arbiter

   Risk score (RPN) decides; coverage up while volume goes down

Product workflow, shown through the decisions and handoffs.

The decision

I designed eleven proposed optimizations across three themes: reduce avoidable alerts, surface useful clinical context, and consolidate review. The proposal also adds or improves safety checks. Its modeled benefits remain distinct from delivered results.

What I learned

Attention is part of a safety product. Reducing volume is easy; proving that each removed alert was non-actionable, and converting the rest into better checks, is the work. Root causes are often arithmetic, not policy.

My reflection

A safety system that fires too often is a safety system nobody trusts.

I was looking at drug-interaction alerts from a pharmacy. Many required a pharmacist to stop, read and acknowledge them. Duplicate therapy, real interactions and real dosing problems were the reason the system existed. But some apparently ordinary prescriptions produced avoidable messages. I read the records to understand why.

The cause involved how a value was represented and rounded between systems. The arithmetic was technically repeatable but changed the meaning of the source information. That distinction mattered: deleting the alert category could hide useful warnings, while correcting the representation addressed the source of the noise. I investigated the data model because the clinical meaning and the arithmetic had to agree.

I am a pharmacist by training. I am also, for the last seventeen years, the person in the room whose job is to make the system work for the people inside it. That combination is why I could investigate the data model and understand what would be lost if we simply removed a category instead of fixing its cause.

Here is the pattern, in one sentence: find the number, ship the gate, measure the defect. Everything else is detail. The detail is what follows.

Related work: DUR at Fill

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

The safety-alert system generated tens of millions of alerts, with about a third requiring acknowledgement. The proposal projects greater review workload as checks move closer to dispense, so scaling the workflow also requires attention to avoidable interruptions.

What I found

Most of the acknowledgement volume sat in three conflict types. Dose alerts were the largest fixable share, and most of them were non-actionable. The root cause was arithmetic: the legacy monolith normalized bulk prescriptions to daily equivalents, so 0.5 mL a week was stored as 0.071 mL a day, and 0.071 times 7 is 0.497, which fires “dose below minimum”. Non-drug items such as devices produced a large volume of “not checked” alerts because the engine could not match them to a drug database; a single device product accounted for about a quarter of them. Duplicate-therapy alerts were the largest single bucket, driven partly by the absence of a stored override, so the same conflict re-fired every fill.

What has shipped and what has not

A narrower dose-check enhancement is reported as shipped. The broader optimization program remains distinct from that release; projected benefits are not presented as delivered results.