What a Sepsis Alert Is, Why Most Get Ignored, and How to Build One That Does Not

What A Sepsis Alert Is, And What It Is Not

A sepsis alert is an automated notification generated inside the electronic health record when a patient’s data crosses a defined threshold for sepsis risk.

Three things get used interchangeably at the bedside and mean different things in a requirements document.

• A sepsis alert is the system speaking. Vitals, labs, or a model score cross a line and the EHR notifies someone. Nobody has decided anything yet.
• A sepsis screen is the structured assessment a nurse completes, often prompted by the alert. A human is now involved.
• A code sepsis is the hospital’s response being activated. A team assembles, the bundle clock is running, and resources move.

The alert is the cheapest and least certain of the three. Treating it as a diagnosis is the most common misreading, and it is where most of the frustration with these systems begins. Its only job is to make a clinician look at a patient sooner than they otherwise would have.

That framing matters for anyone specifying one. Written as “detect sepsis,” the system gets judged against a standard it cannot meet. Written as “surface patients who warrant a look, early enough that the look is useful,” it can be built, measured, and tuned.

What Triggers A Sepsis Alert: SIRS, SOFA, and qSOFA

Three criteria sets do most of the work, and they were designed for different jobs.

The practical difference is data latency, and it decides where in the workflow an alert can live. SIRS and qSOFA run on vitals available at triage; SOFA needs laboratory values that may be an hour away. An alert built on SOFA is more specific and arrives later. One built on SIRS arrives immediately and fires on many patients who have influenza, pancreatitis, or a postoperative inflammatory response rather than sepsis.

Most production alerts are not a pure implementation of any of the three. They are a local rule set layered on one of these frames and adjusted after go-live in response to complaints. That is a reasonable way to build one, but it means the published performance of SIRS or qSOFA tells you very little about the performance of your alert. Increasingly the trigger is a model scoring a trajectory rather than a rule testing a threshold, which changes the tuning problem substantially and the delivery problem not at all.

The Three-hour Clock, And What It Does To Alert Design

Sepsis alerting is not a general clinical decision support problem. It carries a payment-linked deadline, and that deadline is why timing dominates every other design consideration.

CMS measures the severe sepsis and septic shock management bundle as SEP-1. Within three hours of time zero, the bundle requires that clinicians measure a lactate level, draw blood cultures before antibiotics, administer broad-spectrum antibiotics, and, where hypotension or lactic acidosis is present, begin 30 cc/kg of intravenous crystalloid. CMS finalized SEP-1’s inclusion in the Hospital Value-Based Purchasing program in the FY2024 IPPS rule, and for fiscal year 2026 it sits in the program’s Safety domain. Compliance now moves payment rather than only appearing in a report.

Here is the part that changes how the alert should be built. Time zero is when the patient met the clinical criteria, not when your system noticed. Every minute the alert is late is subtracted from the window the clinician has to complete four tasks, one of which depends on a laboratory turnaround they do not control.

Two consequences follow, and both are design decisions rather than clinical ones. An alert that fires accurately but late has failed even when it is right, because the measure is not detection but detection early enough to act. And the alert should carry the bundle with it: a notification saying a patient may be septic leaves the clinician to recall four tasks and their sequence under time pressure, while one arriving with the orders attached removes that step. That is the difference between reporting risk and reducing time to treatment, and it turns on what the alert is allowed to do rather than how well it predicts.

Why Most Sepsis Alerts Get Ignored

Because most of them are wrong, and clinicians have correctly learned this.

A systematic review of sepsis alerts in emergency departments by Hwang, Bond and Powell examined ten studies. Positive predictive value ranged from 5.8% to 54%. Sensitivity ranged from 10% to 100%, specificity from 78% to 99%, and negative predictive value was consistently high at 99% to 100%. No high-quality study in the review showed a mortality difference, and one showed an effect on ICU length of stay. A later JAMA Network Open meta-analysis of alert systems, mortality and bundle adherence reached a similarly cautious position.

Sit with the low end of that range. At 5.8%, roughly one alert in seventeen is a patient with sepsis, so a clinician who investigates every one spends most of a shift confirming that patients are not septic. Clearing those alerts quickly is not negligence. It is an accurate response to a tool with a poor signal-to-noise ratio, and it is the behavior the system has trained.

The high negative predictive value is usually left out, and it reframes what these tools are for. A sepsis alert is a poor confirmer and a good excluder. Used as a filter that narrows attention, it is genuinely useful. Used as an accusation, it burns credibility on every false positive.

The tempting conclusion is that the model needs to be better. Sometimes that is true. More often, an alert with a PPV of 30% is tolerated perfectly well when delivered in a way that makes checking cheap, and intolerable as a full-screen interruption that must be dismissed with a documented reason before the clinician can continue. The literature has measured the accuracy problem thoroughly. The delivery problem has had far less attention, and it is the one usually within your control.

For the wider question of how alert burden accumulates across every alert type in a health system, and the governance that manages it, we cover that separately in reducing alert fatigue in clinical decision support. What follows here is specific to sepsis.

Where The Alert Fires Decides Whether It Works

Two alerts can run the identical model and produce completely different override rates, because an alert is not only a prediction. It is a prediction delivered at a moment, into a screen, with a set of available actions.

In an EHR that supports CDS Hooks, the delivery point is an explicit architectural choice rather than an accident of configuration. A hook is a named moment in the clinician’s workflow. When it is reached, the EHR calls a decision support service, which can return cards.

Epic supports exactly three of these hooks in practice: patient-view, order-select, and order-sign. Most vendor documentation says only that Epic supports CDS Hooks, without saying which. The three behave very differently for sepsis.

• patient-view: fires when a chart is opened. This is where a sepsis risk score belongs. It is present when the clinician arrives, it interrupts nothing, and it is available to be read rather than demanding to be answered.
• order-select: fires when a clinician picks an order. Useful for suggesting the bundle elements once someone has started acting on a suspicion.
• order-sign: fires immediately before an order is committed. This is the last moment anything can change the order, and it is the right place for a check that must not be missed.

Placement resolves an argument that otherwise runs in circles. Teams debate whether a sepsis alert should be interruptive, and the answer depends which moment you mean. A passive risk score at patient-view and a hard stop at order-sign coexist without competing, because they address different decisions at different times. The failure pattern is one interruptive alert doing all of it, firing whenever the data updated.

One integration detail consistently surprises teams: not every EHR exposes the discovery endpoint that lets a service publish which hooks it responds to. Where it is missing, hook endpoints and prefetch conditions are configured by hand per environment, a real cost in a multi-site deployment. The technical implementation detail covers the request and response contract.

Six Card-level Decisions That Change The Override Rate

These are properties of the card itself. They sit below policy and above the model, and they are where a delivery layer is usually won or lost.

1. One action per card: A card presenting a decision and a single way to act on it gets acted on. A card offering four options becomes a menu, and menus get closed.
2. Never fire on an empty array: If the service has nothing to say, it must return no cards, not an empty card confirming that nothing is wrong. Reassurance notifications are the fastest way to teach clinicians that this source is not worth reading.
3. Cache aggressively, and prefetch: A card arriving after the clinician has moved on is worse than no card, because it trains people to expect nothing. Prefetch what the service needs so the round trip does not run on the clinician’s time.
4. Deduplicate through the feedback endpoint: CDS Hooks provides a feedback mechanism so a service learns that a suggestion was accepted or overridden. Use it. Re-firing on a recommendation someone already acted on is the most avoidable override in the system.
5. Put the reason in the card: A score with no explanation cannot be evaluated in the seconds available. Naming the two or three values that moved it lets a clinician agree or dismiss on the evidence, which is faster and more defensible.
6. Know when a card is the wrong container: A card is one decision at one moment. Anything genuinely multi-step, such as working through a full bundle with documentation, belongs in an embedded SMART on FHIR application launched from a card link.

Track override rate from the day the alert goes live, split by hook and by unit. A rising rate is a design signal, and it arrives long before the complaints do.

What We Have Built, And What We Have Not

We have not built a sepsis product: We have no sepsis case study, and nothing here should be read as a claim to sepsis detection capability. Being specific about that is more useful to a buyer than the alternative.

What we have built is both halves of the architecture a sepsis alert requires, separately, for other clinical problems.

The scoring half: For an obstetric client we built a predictive clinical model that reached 83% accuracy on childbirth timing, validated it clinically, and surfaced its output inside Epic through SMART on FHIR. Training ran on AWS SageMaker, and the work covered validation and production deployment rather than stopping at a notebook. That is the same shape as a sepsis risk score: a model whose output has to arrive inside a clinician’s existing screen to matter.

The delivery half: For a perioperative client we built decision support delivered as CDS Hooks cards in Epic’s ordering workflow. The order-sign hook fires, patient data goes to the service, and missing preoperative labs come back as a card. Missed labs fell from 15% to 2%. Lab ordering time dropped from 60 minutes a day to 10 to 15 minutes. Surgery delays caused by missing labs went from around 10 a month to 3 to 5.

Provider engagement with that card was 87%.

That last number is the relevant one, and it is worth stating against the PPV range above. It is not a claim that the underlying logic was more accurate than anyone else’s. It is evidence that a card presenting one decision, at the moment the decision is made, with the reason attached, gets used rather than cleared. The sepsis literature documents the accuracy problem carefully. This is a data point about the other one.

What To Ask Before You Build Or Buy One

Whether the answer is a vendor product, an EHR-native module, or custom work, the same questions separate a tool that changes behavior from one that adds notifications.

1. On accuracy, ask for the denominator: A vendor quoting sensitivity without positive predictive value is quoting the flattering half. Ask what share of alerts in a live deployment were patients who turned out to be septic, and on which population.
2. On timing, ask when it fires relative to time zero: Not how fast the model runs. How much of the three-hour window remains, on average, when the notification reaches someone who can act.
3. On delivery, ask which hook: If the answer is that it supports CDS Hooks, ask which ones, in which EHR, and what the card contains. If the answer is a dashboard, ask who is expected to be looking at it, and when.

The CDC’s Hospital Sepsis Program Core Elements is the reference for what a sepsis program should have in place around the alert.

On tuning, ask who owns the threshold after go-live, how often it is reviewed, and what evidence triggers a change. An alert nobody owns drifts until people stop reading it.

On the bundle, ask whether the alert carries the orders, or whether it announces a risk and leaves four tasks to recall.

Where an EHR’s native sepsis alerting already performs, the work is tuning and governance rather than building. Where it does not, the gap is usually the delivery layer rather than the model, and that can be built as a CDS service against hooks the EHR already exposes, without replacing anything. If you are comparing options, our clinical decision support software buyer’s guide sets out the criteria, and worked examples of clinical decision support shows what these look like in production. Teams whose problem is broader than one alert should start with clinical workflow automation.