Key Takeaways:

• Settle regulatory posture first. Under FDA’s January 2026 clinical decision support guidance, software that detects sepsis and fires a time-critical alert is a device function.
• Validate on your own patients before go-live. A widely used vendor model scored an AUC of 0.63 in one independent test against the 0.76 to 0.83 its developer reported, and a high AUC can hide low precision.
• Alert design decides adoption. Tune thresholds to what responders can act on, snooze repeat alerts, skip cases clinicians already see, and route alerts to people.
• Plan outcome measurement and monitoring from day one. The tools with the strongest results paired a model with a defined response workflow, and performance changes over time.

If you’re a health system CTO or innovation director deciding whether to use your EHR vendor’s sepsis model, license an FDA-authorized product, or build your own, the architecture and validation choices you make now decide whether clinicians trust the tool or mute it. The stakes are high: according to the CDC, one in three people who die in a hospital had sepsis during that hospitalization, and at least 350,000 adults with sepsis die in the hospital or move to hospice each year.

The evidence points in a consistent direction. How a model is validated, tuned, and wired into the clinical workflow matters more than which algorithm sits inside it. This guide covers the regulatory question that comes first, the products on the market, the data and model choices, local validation, alert design, the outcome evidence, and a roadmap for getting from pilot to practice.

Why Does the Build, Buy, or License Decision Start With Regulation?

Regulatory status shapes everything downstream: your documentation burden, your validation plan, and your liability. FDA’s revised Clinical Decision Support Software guidance, issued January 6, 2026 and reissued with a minor correction on January 29, keeps the four criteria software must meet to fall outside device regulation. Software that analyzes patient data to detect sepsis risk and fire an alert to a clinician fails them, because a time-critical alarm doesn’t leave room for the clinician to independently review its basis.

The 2026 revision did loosen one thing. FDA now intends to exercise enforcement discretion for software that offers a single recommendation when only one option is clinically appropriate, as long as it meets the other criteria. That helps some decision support, but it doesn’t change the status of a sepsis alarm. If your tool fires an alert, plan for the device pathway, with the software documentation, validation evidence, and cybersecurity work that comes with it. Dogtown’s guide to software as a medical device covers the classification questions.

Which Sepsis AI Products Has FDA Authorized?

It’s small but growing, and its two products take different approaches.

The Sepsis ImmunoScore. Prenosis received De Novo authorization in April 2024 for the first AI diagnostic authorized for sepsis. It’s a calibrated random forest that uses up to 22 inputs, including demographics, vital signs, and lab results, to estimate the probability that a patient has or will develop sepsis within 24 hours. In a prospective multicenter study published in NEJM AI, it reached an AUC of 0.81 in external validation, and in-hospital mortality across its four risk categories ranged from 0.0% in the lowest to 18.2% in the highest. Prenosis designed and ran the study, and its employees and equity holders were among the authors. Clinicians order the ImmunoScore in the EHR like a lab test and view the result.

Bayesian Health’s sepsis flagging device. On May 12, 2026, Bayesian Health received 510(k) clearance for what it describes as the first continuously running AI sepsis monitor cleared by FDA. According to FDA’s summary, the device analyzes EHR data including the emergency department chief complaint, lab results, vital signs, procedures, and medications. It grew out of the TREWS system developed at Johns Hopkins.

EHR-native models. Most hospitals’ first exposure is the model built into their EHR. Epic’s sepsis model is the most widely deployed, and version 2 is now available alongside the original. Many sepsis tools have historically been deployed as general decision support without FDA review, as MedCity News noted when covering Bayesian’s clearance.

Two Interaction Patterns

	Ordered test	Continuous surveillance
Example	Sepsis ImmunoScore	Bayesian Health, Epic’s sepsis model, COMPOSER, Sepsis Watch
Who starts it	A clinician who already suspects infection	The system, running on every eligible patient
What it adds	Risk stratification at the moment of decision	Detection before anyone suspects sepsis
Main risk	It only helps patients someone already worried about	Alert burden and false positives
Workflow need	Clear actions for each risk category	A responder, a threshold, and a response protocol

The patterns aren’t mutually exclusive, but they lead to different builds, different workflows, and different validation questions, so decide which one you need first.

When Does Building Your Own Make Sense?

Building makes sense when you have data engineering depth, a clinical champion, and a plan to either pursue the device pathway or keep the tool clearly inside a research or quality improvement boundary. The best-known sepsis tools started this way: COMPOSER at UC San Diego, Sepsis Watch at Duke, and TREWS at Johns Hopkins were all built and studied in-house before anyone sold them. Building rarely makes sense as a shortcut around a vendor contract. If you build, budget for the regulatory work and the workflow design along with the model. Dogtown’s clinical decision support app development team works through those decisions with health systems.

What Data Streams Does a Real-Time Sepsis Model Need?

A real-time sepsis model draws on streaming vitals, discrete lab values, and clinical context from the record, such as medications and demographics. Each behaves differently, and most integration pain comes from the mismatch between them.

Streaming vitals. Heart rate, respiratory rate, temperature, and blood pressure arrive continuously or at charted intervals. They’re noisy, and gaps are common, so the model has to handle missing values without silently degrading.

Discrete lab values. Lactate, white blood cell count, creatinine, and bilirubin arrive irregularly and late relative to the bedside. Timestamp discipline matters: a lab drawn at 1:00 p.m. but resulted at 3:10 p.m. must be treated as known only at 3:10, or your retrospective accuracy will be inflated by information the live system wouldn’t have had.

Medications and record context. Antibiotic orders, vasopressors, and demographics complete the picture, and they also create a labeling trap. If your training label depends on clinician actions, such as the time an antibiotic was ordered, the model learns to predict recognition instead of the underlying condition and arrives after the clinician does. Epic’s version 2 model moved to labels based on Sepsis-3, the consensus clinical definition.

Where you deploy matters too. More than 80% of sepsis is present on admission, which is one reason UC San Diego started COMPOSER in its emergency departments. Most health systems pull these streams through HL7 or FHIR interfaces, so scope that integration layer before model work begins. Dogtown’s guide to FHIR API integration covers the patterns.

Which Model Approaches Work for Sepsis Prediction?

No single architecture wins. The right choice depends on your data, your interpretability needs, and your regulatory plan.

Deep learning for time series. Recurrent networks fit sequential vitals and labs naturally. UC San Diego’s COMPOSER was built to predict sepsis 4 to 48 hours before clinical suspicion, and it uses conformal prediction to decline to score patients or data that look unfamiliar, cutting false alarms from erroneous inputs. Across its test cohorts, it gave warnings a median of 12.2 hours before the first antibiotic order in the ICU and 2.1 hours in the emergency department. That ability to say “I don’t know” is a useful pattern for any model you deploy.

Tree ensembles for mixed inputs. Ensembles handle tabular data, mixed input types, and missing values well, and they’re easier to explain. The ImmunoScore is a calibrated random forest, and Epic’s version 2 model is a locally trained gradient-boosted tree ensemble.

Simple benchmarks. Epic’s original model was a penalized logistic regression, and its documented problems came from calibration, labeling, and local fit, not from a lack of complexity. Whatever you build, benchmark it against a simple score so you can show leadership what the added complexity buys.

How Do You Validate a Sepsis Model Before Clinicians Will Trust It?

Validate on your own population, prospectively where possible, and keep validating after go-live. Treat vendor-reported performance as a hypothesis to test.

The cautionary case is well documented. When Michigan Medicine independently tested Epic’s original sepsis model across 38,455 hospitalizations, it found an AUC of 0.63 against the 0.76 to 0.83 reported by the developer. The model generated alerts on 18% of all hospitalized patients while missing 67% of patients with sepsis. Performance also varies by site: across nine hospitals in one network, the same model’s C-statistic ranged from 0.55 to 0.73, worse at hospitals with higher sepsis incidence and sicker patients. A county hospital emergency department found a positive predictive value of 7.6%.

The story keeps evolving. Epic reported internal AUCs of 0.83 to 0.86 for version 2, and a multicenter prospective study across four health systems found improved discrimination over the original. Mass General Brigham ran version 2 in silent mode before deciding whether to deploy it, which is exactly the step every buyer should take.

Read Precision, Not Just AUC

A high AUC can look excellent while most alerts are wrong, because sepsis is uncommon in any given hour. Duke’s Sepsis Watch reached AUCs of 0.906 to 0.960 across four sites in a multisite external validation, while its area under the precision-recall curve ranged from 0.177 to 0.252. Mass General Brigham’s silent test of Epic’s version 2 found the same pattern, with an AUC of 0.89 and a precision-recall area of 0.24 for Sepsis-3. Report positive predictive value and alerts per day alongside AUC, because those are the numbers your responders will feel.

A Practical Validation Sequence

1. Retrospective local validation. Replay your own historical data with strict timestamps, and report sensitivity, positive predictive value, and calibration.
2. Silent mode. Run the model live without showing alerts, and compare its flags with what clinicians actually did and when.
3. Subgroup checks. Test performance across age, sex, race, and care setting before any clinician sees an alert, and document who signs off. Dogtown’s AI compliance and risk mitigation practice builds this into the process.
4. Limited live rollout. Start in one unit, and review alert volume, positive predictive value, and lead time weekly.
5. Ongoing monitoring. Track drift and revalidate on a schedule.

How Do You Design Alerts That Don’t Cause Alarm Fatigue?

Design every alert around what your responders can act on. If the volume exceeds their capacity, adoption collapses regardless of accuracy.

Tune the threshold to staffing. The Sepsis Watch validation measured how many alerts a charge nurse or rapid response team would receive at each threshold, and it snoozed further alerts for eight hours after one fired, to cut repeat alerts and alarm fatigue. Pick a threshold your team can respond to, then revisit it as staffing changes. For comparison, Epic’s original model alerted on 18% of patients at Michigan Medicine, while TREWS fired on about 7% of encounters during its five-hospital deployment.

Skip cases clinicians already see. UC San Diego’s team chose not to alert on patients whose sepsis risk is obvious at triage, such as someone febrile, tachycardic, and hypotensive, and to focus the model where it adds information. Suppress alerts once antibiotics or a sepsis bundle are underway, too, since an alert that arrives after the clinician has acted erodes trust.

Route alerts to people. Duke designed Sepsis Watch around rapid response team nurses who monitor emergency department patients remotely. In interviews with nurses and physicians, participants credited the easy-to-use tablet app and the communication strategies nurses developed for sharing model output with physicians, and they named information flow between clinicians as a barrier.

Show the why. Clinicians act on alerts they can interrogate. Surface the top contributing factors, the trend, and whether treatment has already started.

Getting this right pays off in trust. At MemorialCare, a Bayesian Health customer, a leader told MedCity News that clinicians are working with significantly fewer electronic alerts, which he credits with restoring their trust in AI tools. That’s one customer’s account through one outlet, so treat it as a design target.

What Does the Outcome Evidence Show?

A few deployments have reported effects on patient outcomes, and every one depended on a defined response workflow.

• COMPOSER at UC San Diego. In a before-and-after study of 6,217 septic patients at two emergency departments, deploying COMPOSER through a nurse-facing alert was associated with a 17% relative reduction in in-hospital sepsis mortality and a 10% relative increase in sepsis bundle compliance.
• TREWS at Johns Hopkins. Across 764,707 encounters at five hospitals, patients whose alerts were confirmed by a clinician within three hours were about 18% less likely to die in the hospital than those whose alerts weren’t. That compares patients of responsive and unresponsive clinicians, not randomized groups, and critics have flagged the difference.
• MemorialCare. The health system reported a 3.6-point absolute mortality reduction when providers engaged with the Bayesian flag, and antibiotic timing cut in half when they engaged within the first hour. Those figures are customer-reported.

None of these is a randomized trial, and each measured the combination of a model and a response process. Plan to measure the same things in your own deployment: time to antibiotics, bundle compliance, and mortality among patients who were and weren’t flagged.

Fit the Tool Into Your Sepsis Program

An AI tool works only as well as the program around it. In 2023, the CDC released its Hospital Sepsis Program Core Elements, a guide built on seven elements: leadership commitment, accountability, multiprofessional expertise, action, tracking, reporting, and education. The same CDC survey found that only 55% of hospitals gave their sepsis program leaders dedicated time to run them.

Treat the AI tool as part of that program. Name an owner for its performance, report its metrics alongside your other sepsis measures, and include it in clinician education.

What Does a Build Roadmap Look Like?

A realistic roadmap runs in phases, and the clinical and workflow work takes as long as the engineering.

1. Define the use case and regulatory posture. Pick the care setting, whether the emergency department, inpatient wards, or the ICU, along with the intended user, the interaction pattern, and whether you’re pursuing the device pathway.
2. Audit your data. Confirm vital sign frequency, lab timestamps, and the label definition you’ll train against.
3. Build the pipeline and model. Start with a benchmark score, and add complexity only if it earns its keep.
4. Run silent validation. Compare flags with real clinician actions.
5. Design the response workflow with nurses and physicians, and bring in human factors expertise to shape how model output reaches the bedside. Treat it as a staffing line item.
6. Launch narrow, measure, and expand.

A Readiness Checklist for Sepsis AI

• Regulatory posture decided. You know whether the tool is a device and which pathway it’ll take.
• Interaction pattern chosen. Ordered test, continuous surveillance, or both, with a reason for each.
• Label defined. The training and evaluation outcome doesn’t depend on clinician actions.
• Timestamps verified. Every input is used only from the moment it would have been available.
• Local validation done. Positive predictive value, calibration, and alerts per day are measured on your patients.
• Subgroups checked. Performance is reviewed across age, sex, race, and care setting.
• Responder identified. A named team owns every alert, with a threshold matched to its capacity.
• Suppression rules set. Snooze windows and treatment-started suppression are in place.
• Outcomes measured. Time to antibiotics, bundle compliance, and mortality are tracked from go-live.
• Program ownership assigned. The tool reports into your sepsis program, with drift monitoring and revalidation scheduled.

Why Partner With Dogtown Media

Dogtown Media builds clinical decision support applications that connect to the EHR data streams real-time models depend on, along with the clinician-facing apps that deliver alerts to the right person. Our AI-powered healthcare app development team builds the data pipelines and model integrations, and our AI compliance practice plans validation, subgroup testing, and the regulatory path alongside the architecture.

If you’d like to talk through your sepsis project, request a free consultation with our team.

Frequently Asked Questions

Is an AI sepsis alert considered a medical device?

In most cases, yes. FDA’s January 2026 Clinical Decision Support Software guidance treats software that analyzes patient data to detect a time-critical condition like sepsis and alerts a clinician as a device function, because an alarm doesn’t leave room for independent review of its basis. Confirm your specific design with regulatory counsel, since intended use and labeling drive the classification.

Why did Epic’s sepsis model underperform in outside studies?

Michigan Medicine’s independent validation of the original model found poor discrimination and calibration, with an AUC of 0.63 against the 0.76 to 0.83 the developer reported, and other hospitals found performance varied with their patient populations. Epic has since released a version 2 model trained locally on Sepsis-3 labels, which a multicenter study found discriminates better. Whatever model you consider, validate it on your own patients before relying on it.

Do you need deep learning for sepsis prediction?

No. Recurrent networks suit sequential data, and COMPOSER shows what they can do, but the first FDA-authorized sepsis AI uses a calibrated random forest, and Epic’s version 2 uses gradient-boosted trees. Pick the approach that fits your data quality, explainability needs, and validation capacity, and benchmark it against a simple score.

How do you reduce false alerts without missing true cases?

Set the threshold to the number of alerts your responders can handle, snooze repeat alerts, skip patients whose sepsis risk is already obvious, suppress alerts once treatment starts, and review alert volume, positive predictive value, and lead time weekly during rollout. The Sepsis Watch validation used an eight-hour snooze window and measured alert burden at each threshold.

What should you monitor after deployment?

Track alert volume, positive predictive value, lead time against clinician recognition, subgroup performance, and the outcomes you’re trying to change, such as time to antibiotics and sepsis mortality. Models can behave differently as patient populations, documentation habits, and EHR configurations change, which is why external validations of widely deployed sepsis models keep finding gaps.

Closing Thoughts

The decision in front of you is less about which algorithm to pick and more about whether you can prove a model works on your patients and deliver its output in a way your clinicians will act on. Start with regulatory posture, choose your interaction pattern, validate locally in silent mode, design alerts around responder capacity, and measure outcomes after launch. Those steps separate the sepsis tools that stay in use from the ones that get muted.