When the Warning Is in the Record: Predictive Alerts and the Standard of Care

Originally published in AHLA Health Law Weekly, November 6, 2026.

By Michelle Carroll

Summary

Hospitals now run predictive models that score inpatients for sepsis, clinical deterioration, and other risks and push alerts into the electronic health record. When a patient is harmed after an alert fired, or after one should have fired and did not, the alert becomes evidence. This article looks at how predictive alerts fit within the existing negligence framework, why an override is not by itself a breach, where a hospital's duties to select, tune, and monitor these tools come from, and how federal oversight of them is shifting in 2026. It closes with what the alert record actually contains and practical steps for hospital counsel and for litigators on both sides.

Introduction

At 2:14 a.m., a sepsis risk score crosses its threshold on a medical-surgical unit. An advisory appears on the nurse's screen. Ninety seconds later it is dismissed with the reason "provider aware." No new vital signs are charted for almost three hours. At 6:40 a.m., the patient is transferred to intensive care in septic shock. The covering physician's note, signed at 7:30 a.m., describes the night as uneventful.

Not long ago, the chart in a case like this would have shown a set of vital signs and a lab value, and the dispute would have been over whether a reasonable clinician should have recognized the pattern. Today the chart also shows that the hospital's own software recognized it, told someone, and got an answer. That changes the questions a court, a jury, and the hospital's own risk committee will ask.

Predictive alerts are now a routine part of inpatient care. The law has not developed a separate standard of care for them, and it may not need one. What has changed is the evidence, and with it, the attention paid to the institution that chose to install the tool.

What a Predictive Alert Is, and What It Is Not

Clinical decision support comes in two broad forms. A rule-based alert fires when defined criteria are met, such as a heart rate above a set number combined with an elevated lactate. A predictive alert works differently. A model trained on historical patient data produces a score or probability, someone sets a threshold, and the alert fires when the patient crosses it. Federal health IT regulations draw the same line, defining a predictive decision support intervention as technology that supports decision-making based on algorithms or models that derive relationships from training or example data.1

Two features of these tools matter for the legal analysis.

First, how well a model performs depends heavily on where it is used. In a widely cited external validation study at the University of Michigan covering more than 38,000 hospitalizations, a proprietary sepsis model performed well below the figures reported in developer-associated data. It failed to flag about two-thirds of the patients who developed sepsis, while generating alerts on roughly 18 percent of all hospitalized patients. Only about one alert in eight pointed to a patient who actually had sepsis.2

Second, the score is only half of the system. The other half is what the hospital does when the score crosses the line. Kaiser Permanente Northern California deployed a deterioration model across 21 hospitals and routed its alerts not to bedside staff, but to trained remote nurses who reviewed the chart and then contacted the unit's rapid response team. The design choice was deliberate, intended to limit alert fatigue. Patients in the intervention group had lower mortality within 30 days of an alert than comparable patients at hospitals where the program had not yet launched.3

The same kind of tool can produce very different results depending on the response built around it. That is why I find it useful to think of a predictive alert less as a diagnosis and more as an instruction the hospital wrote to itself: when this number crosses this line, someone should look.

The Standard of Care Has Not Changed. The Evidence Has.

Medical negligence still asks what a reasonably prudent clinician in the same field and circumstances would have done with the information available at the time. An alert is information. Once it is displayed, it becomes part of what the clinician knew, or should have known. It does not tell the clinician what to do, and it does not establish what a reasonable clinician would have done. Those remain questions for qualified experts.

Federal law assumes that same division of labor. The statutory exclusion for clinical decision support software that is not regulated as a medical device applies to software that lets a health care professional independently review the basis for its recommendations, so the professional does not rely primarily on them.4 The Food and Drug Administration's revised guidance, issued in January 2026 to replace the 2022 version, keeps that framework, continues to express concern about time-critical recommendations and automation bias, and now allows that some software offering a single recommendation or a risk score may fall outside device regulation.5 6 State medical boards have made the same point from the licensing side. The Federation of State Medical Boards' 2024 policy describes AI tools as aids to physician judgment, not replacements for it, and holds physicians accountable for how they use them.7

That principle cuts both ways. A plaintiff cannot prove breach simply by pointing to an alert. A defendant cannot treat an alert as noise simply because the tool is imperfect. In most cases, the question is what the clinician did with the information.

A related question comes up often: can a hospital be negligent for not using predictive tools at all? Professional care is usually measured against customary practice, but courts have long reserved the power to find that an entire field has fallen behind. Judge Learned Hand made the point about tugboats without radio receivers in The T.J. Hooper,8 and the Washington Supreme Court applied it to glaucoma screening in Helling v. Carey.9 Courts use that power rarely, and with the published evidence on predictive models as mixed as it is, a holding that a hospital was negligent for declining to deploy one seems unlikely for now. The more realistic exposure arises after a hospital adopts a tool and does not run it responsibly.

An Override Is Not a Breach

Most alerts are overridden, and many should be. A review of clinician responses to medication safety alerts found override rates between 49 and 96 percent, and noted that overriding is often clinically justified.10 The sepsis model in the Michigan study alerted on nearly one in five inpatients. A clinician who escalated every one of those alerts would expose patients to unnecessary testing and antibiotics.

So an override, standing alone, says very little. What matters is whether it reflects a clinical judgment. In reviewing these cases, I ask four questions:

• Who saw the alert, and could they act on it? An alert routed only to a nurse, with no clear path to a provider, raises a different issue than an alert dismissed by the physician responsible for the patient.

• What was in front of them? The score, the vital signs and lab values driving it, and anything else in the record at that moment.

• Was there an assessment? A bedside evaluation, documented at or near the time of the override.

• Does the override reason match the rest of the record? "Provider aware" should line up with a page, a call, or an order. "Clinically assessed" should line up with an assessment somewhere in the chart.

A one-click override followed by silence in the chart is hard to defend. A documented assessment explaining why the score did not fit the patient is often a strong defense, even when the outcome was poor.

The alert that never fired deserves equal attention. A threshold set too high, a model switched off on certain units, or an alert suppressed for hours after an earlier dismissal are design decisions. They belong to the institution, not to the clinician at the bedside.

The Institution's Duty: Choosing, Tuning, and Watching the Tool

Hospitals owe patients duties of their own, separate from those of the clinicians who practice in them. Darling v. Charleston Community Memorial Hospital is the familiar starting point,11 and the Pennsylvania Supreme Court's decision in Thompson v. Nason Hospital lists those duties to include maintaining safe and adequate facilities and equipment, overseeing everyone who practices medicine within the hospital, and formulating, adopting, and enforcing adequate rules and policies for patient care.12 Not every state recognizes corporate negligence in that form, but the duties it describes map closely onto predictive alerts. The hospital chooses the model, sets the threshold, decides who receives the alert and how, defines the expected response, and decides whether anyone checks whether the tool is working.

The governance expectations are increasingly written down. In September 2025, the Joint Commission and the Coalition for Health AI released guidance calling on health care organizations to establish AI governance structures, validate tools locally before deployment, monitor them for performance drift afterward, and train staff by role on each tool's intended use and limits.13 The guidance is voluntary, but in litigation, published guidance from an accrediting body has a way of becoming the yardstick experts reach for.

Federal civil rights rules also reach these tools. Regulations implementing Section 1557 of the Affordable Care Act require covered entities to make reasonable efforts to identify patient care decision support tools that use race, color, national origin, sex, age, or disability as input variables, and to make reasonable efforts to mitigate the risk of discrimination from their use.14 Those provisions became applicable in 2025 and remain in the Code of Federal Regulations as of this writing.

At the same time, federal transparency requirements have moved in the other direction. The HTI-1 rule required developers of certified health IT to make "source attributes" available to users for predictive decision support, sometimes called a model card, describing intended use, training data, validation, and fairness testing, and to apply risk management practices to those tools.15 The HTI-5 final rule, released on October 26, 2026, following a December 2025 proposal, removes both requirements.16 17 The decision support interventions criterion survives in narrower form, but certified health IT no longer has to support source attributes or risk management for predictive tools. ONC finalized the change even though most commenters opposed it, many warning that it would shift evaluation, governance, and liability burdens onto providers and health systems. The rule takes effect December 28, 2026, with some provisions effective January 1, 2027. ONC said it would consider restoring some transparency requirements for evidence-based decision support that does not rely on AI. It signaled nothing similar for predictive tools.

Less federal oversight does not reduce the duty of care. It moves the question of whether a tool was safe to use out of a regulator's file and into the hospital's own records, and eventually into a courtroom. Now that vendors are no longer required to supply a model card, a hospital that deploys a model without asking for validation data in writing will have a harder time showing that it acted reasonably. ONC made a similar point in the final rule, reminding providers that their own obligations remain, including the Section 1557 duty to identify and mitigate the risk of discrimination from these tools.16

What the Alert Record Shows

My earlier AHLA articles addressed the EHR audit trail and the admissibility of AI-generated evidence in long-term care litigation.18 Predictive alert cases extend that work. The alert record is not part of the printed chart. It lives in separate logs and configuration files, and it rarely arrives with a standard records request. A complete review usually needs:

• the patient's full score history with timestamps, not just the value that triggered the alert;

• the alert log, showing when each alert fired, who received it, whether it was interruptive or passive, what action was taken, the override reason selected, and the time to action;

• the model version and threshold in effect on the dates at issue, along with any local configuration changes;

• the routing rules, including which roles and units receive the alert and what happens if no one acknowledges it;

• the EHR audit trail for the relevant notes, flowsheets, and orders;

• the hospital's sepsis or deterioration response policy and its alert governance charter; and

• any performance monitoring reports for the model.

Two evidentiary issues come up early. The first is subsequent remedial measures. If a hospital lowers a threshold or reroutes an alert after an adverse event, Federal Rule of Evidence 407 and its state counterparts generally bar using that change to prove negligence, although it may come in for other purposes, and state rules vary.19 The second is privilege. Analyses prepared within a patient safety evaluation system and reported to a patient safety organization may qualify as privileged patient safety work product under federal law, but original patient records and information kept separately from that system generally do not.20 Hospitals should decide deliberately where model performance reviews are created and kept. Litigators should expect privilege disputes over them.

Practical Steps for Hospital Counsel and Risk Leaders

• Inventory every predictive alert in production. Record the owner, the vendor, the model version, the threshold, and the units where it runs.

• Require local validation before go-live and documented monitoring afterward. Ask vendors for validation data in writing, and put that obligation in the contract. Federal certification no longer requires them to provide it.

• Write the response, not just the alert. Specify who responds, how quickly, and what must be documented.

• Make override reasons meaningful and audit them. Periodically compare override reasons against the rest of the chart.

• Check the routing. Confirm that every alert reaches someone with the authority and the means to act on it.

• Keep a change log. Document every threshold or configuration change, the date, the reason, and who approved it.

• Set the privilege structure in advance. Decide which reviews belong in a patient safety evaluation system before an event occurs, not after.

• Train by role. Nurses, hospitalists, and rapid response teams need different instruction on the same tool.

For Litigators on Both Sides

For plaintiffs, the alert log is often the most objective timeline in the case, and it should be the subject of a specific preservation letter at intake. But the alert alone does not prove the case. An expert still has to connect it to what a reasonable clinician would have done with that information, and to causation: whether a timely response would have changed the outcome.

For defendants, the same data can help. A documented assessment at the time of the override is persuasive, and the model's published false-positive rate is relevant context. One caution: arguing that the tool is unreliable invites the next question, which is why the hospital deployed it and what it did to confirm the tool worked for its patients.

Conclusion

Predictive alerts do not create a new standard of care. They create a record of what the hospital's systems knew, when they knew it, and who was told. In these cases, the central question is rarely whether the algorithm was right. It is whether the people and the institution behind it responded the way a reasonable clinician and a reasonable hospital would have. More and more often, the record itself can answer that.

This article is for educational purposes and is not legal or medical advice. The case example is fictional.

Endnotes

1. Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing, 89 Fed. Reg. 1192 (Jan. 9, 2024) (codified at 45 C.F.R. pts. 170, 171); see 45 C.F.R. § 170.102 (2026) (defining "predictive decision support intervention"). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-A/section-170.102

2. Andrew Wong et al., External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients, 181 JAMA Internal Med. 1065 (2021). https://doi.org/10.1001/jamainternmed.2021.2626

3. Gabriel J. Escobar et al., Automated Identification of Adults at Risk for In-Hospital Clinical Deterioration, 383 New Eng. J. Med. 1951 (2020). https://pmc.ncbi.nlm.nih.gov/articles/PMC7787261

4. 21 U.S.C. § 360j(o)(1)(E)(iii). https://www.law.cornell.edu/uscode/text/21/360j

5. U.S. Food & Drug Admin., Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff (rev. Jan. 6, 2026) (superseding the Sept. 2022 guidance). https://www.fda.gov/media/109618/download

6. Sonia Nath, Son Nguyen & Wyatt Kernell, Automation Bias and Clinical Practice: FDA Makes Incremental Updates to Clinical Decision Support Software Guidance, Cooley LLP (Jan. 20, 2026). https://www.cooley.com/news/insight/2026/2026-01-20-automation-bias-and-clinical-practice-fda-makes-incremental-updates-to-clinical-decision-support-software-guidance

7. Fed'n of State Med. Bds., Navigating the Responsible and Ethical Incorporation of Artificial Intelligence into Clinical Practice (Apr. 2024). https://www.fsmb.org/advocacy/policies/navigating-the-responsible-and-ethical-incorporation-of-artificial-intelligence/

8. The T.J. Hooper, 60 F.2d 737, 740 (2d Cir. 1932).

9. Helling v. Carey, 83 Wash. 2d 514, 519 P.2d 981 (1974).

10. Heleen van der Sijs et al., Overriding of Drug Safety Alerts in Computerized Physician Order Entry, 13 J. Am. Med. Informatics Ass'n 138 (2006). https://pmc.ncbi.nlm.nih.gov/articles/PMC1447540

11. Darling v. Charleston Cmty. Mem'l Hosp., 33 Ill. 2d 326, 211 N.E.2d 253 (1965).

12. Thompson v. Nason Hosp., 527 Pa. 330, 591 A.2d 703, 707 (1991).

13. Joint Comm'n & Coal. for Health AI, Guidance on the Responsible Use of AI in Healthcare (Sept. 17, 2025). https://www.chai.org/news/joint-commission-and-coalition-for-health-ai-chai-release-initial-guidance

14. 45 C.F.R. § 92.210(b)–(c) (2026); id. § 92.1(b) (applicability of § 92.210(b)–(c) within 300 days of July 5, 2024). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-A/part-92

15. 45 C.F.R. § 170.315(b)(11) (2026) (decision support interventions certification criterion, including source attribute requirements for predictive decision support interventions, before amendment by the HTI-5 final rule). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315

16. Health Data, Technology, and Interoperability: ONC Deregulatory Actions to Unleash Prosperity, Final Rule, 91 Fed. Reg. 67916 (Oct. 28, 2026) (effective Dec. 28, 2026, with certain provisions effective Jan. 1, 2027) (revising 45 C.F.R. § 170.315(b)(11) to remove source attribute and risk management requirements for predictive decision support interventions). https://www.federalregister.gov/documents/2026/10/28/2026-21943/health-data-technology-and-interoperability-onc-deregulatory-actions-to-unleash-prosperity

17. Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity, Proposed Rule, FR Doc. No. 2025-23896 (Dec. 29, 2025). https://www.govinfo.gov/content/pkg/FR-2025-12-29/pdf/2025-23896.pdf

18. Michelle Carroll, When AI Becomes Evidence: Admissibility and Governance Risk in Long Term Care Litigation, AHLA Health Law Weekly (Mar. 27, 2026). https://www.americanhealthlaw.org/content-library/health-law-weekly/article/90b10172-ea57-4a85-b271-b0e9730d0441/when-ai-becomes-evidence-admissibility-and-governa

19. Fed. R. Evid. 407. https://www.law.cornell.edu/rules/fre/rule_407

20. 42 U.S.C. § 299b-22 (privilege and confidentiality of patient safety work product); see id. § 299b-21(7)(B) (excluding original patient records and other information collected or maintained separately from a patient safety evaluation system). https://www.law.cornell.edu/uscode/text/42/299b-22

Author Bio

Michelle Carroll is the Founder and Chief Clinical Strategist of Lexcura Summit and the developer of the Lexcura Clinical Intelligence Model™. Drawing on more than four decades of health care experience, she focuses on helping legal professionals interpret complex medical records, reconstruct clinical decision-making, and evaluate standard-of-care and causation issues in high-stakes health care litigation. She is also an author and host of the Lexcura Clinical Insights podcast.

Copyright 2026, American Health Law Association, Washington, DC. Reprint permission granted.

Michelle Carroll is the Founder and Chief Clinical Strategist of Lexcura Summit, where she leads clinical intelligence reviews of medical records for attorneys and healthcare organizations.

Talk to Us

If you are working a case where a predictive alert fired, or should have, we can map the alert record against the chart and show what the hospital's own systems knew. Visit lexcurasummit.com or book a brief conversation at calendly.com/michelle-lexcurasummit.