重症医学科 AI 已经走过 18 年。它真正要解决的问题，不是让机器替医生盯着监护屏，而是把分散在监护仪、呼吸机、实验室、EHR 和护理记录里的风险信号，变成能被医生护士接住、确认、处置、复盘的行动链路。
图注：Obs Medical VISENSIA 官方页面截图，访问时间 2026-07-19。它代表早期 ICU/高依赖病区连续生命体征风险指数产品形态；标题年数起点另由 FDA 510(k) K081140 核验。
ICU为什么是AI难题？
ICU 看起来天然适合 AI：数据连续、设备多、风险高、医生护士需要随时判断。问题是，ICU 也天然会放大 AI 的缺点。
第一，数据不是一张干净表。监护仪每秒都在出数，呼吸机有自己的参数，输注泵、检验、血气、用药、护理记录、病程记录又在不同系统里。一个模型如果只能看单一时间点，很难理解患者是在稳定恢复，还是已经进入失代偿前夜。
第二，报警不是越多越好。ICU 已经充满提示音，错误的 AI 提醒不会只是“多一条消息”，它会直接增加护士负担，稀释真正危险的信号。很多 ICU AI 产品最后卡住，不是因为 AUC 不够漂亮，而是因为临床团队没有办法把提示嵌入排班、复核和处置流程。
第三，责任链很重。脓毒症、呼吸衰竭、循环崩溃都不是单一数字能决定的诊断。AI 可以提示风险，可以排序队列，可以提醒“这个患者值得再看一眼”，但最终要落到医生判断、护士执行、医嘱调整和质控复盘。
所以，ICU AI 的成熟度不能只看模型论文。更关键的是四件事：数据能不能接进来，提示能不能被接住，处置能不能追踪，效果变差时能不能回滚。
AI怎样重写ICU工作流？
ICU AI 的真实入口通常不是“点开一个 AI 软件”。它更像一层贴在 ICU 工作流上的风险感知系统。
患者进入 ICU 后，系统先要知道他的病情基础、入科来源、诊断、既往病史和当前治疗目标。随后，床旁监护仪、呼吸机、血气、实验室、用药、护理记录和 EHR 不断产生数据。AI 在中间做的事情，是把这些变化合成一个“值得关注”的风险提示。
真正有价值的环节在提示之后。提示给谁？护士站、主管医生、值班医生还是远程 ICU 指挥中心？多久没有被处理要升级？医生确认后，系统是否能记录“已复核、已排除、已干预、待观察”？这些细节决定 AI 是临床工具，还是多一个噪声源。
我认为 ICU AI 的工作流至少要形成三个闭环。
第一是风险闭环：从连续数据到风险提示，再到医生护士复核。第二是处置闭环：从提示到医嘱、会诊、补液、抗感染、呼吸支持或升级处理。第三是治理闭环：从提示结果到真实结局、误报、漏报、报警疲劳和模型阈值调整。
没有这三个闭环，ICU AI 再聪明，也只是一个会闪灯的风险分数。
18年演变：从指数到治理
ICU AI 的历史起点，本期从 FDA 510(k) K081140 计算。openFDA 记录显示，Obs Medical 的 VISENSIA 在 2008-07-17 获得 substantially equivalent 决策。到 2026-07-19，精确相差 18年0个月2天。
这不是说 VISENSIA 就等于今天所有 ICU AI 的技术形态。它代表的是一个更早的产品化起点：把生命体征连续数据变成风险指数和病情恶化提示。
2010 年代以后，ICU 信息化、床旁设备联网、EHR 和临床规则预警逐步成熟。这个阶段的核心不是“模型多先进”，而是医院开始有条件把监护数据、检验数据和医嘱数据放进同一个可计算环境。
2020 年前后，疫情让远程 ICU、病情恶化预测和病房负荷管理变得更紧迫。CLEW ICU 这类产品把“连续监测 + 风险队列 + 远程团队”作为产品语言，说明 ICU AI 已经开始从单个床旁提示转向病房级管理。
2024 年，Prenosis 的 Sepsis ImmunoScore 把脓毒症风险分层推到更明确的监管产品节点。2026 年 4 月 30 日，openFDA 510(k) 记录显示 Bayesian Health Sepsis Flagging Device 获得 clearance。近 90 天的这个节点说明，ICU AI 的热点正在从论文里的早期预警，走向可采购、可审计、可嵌入 EHR 的连续监测工具。
| 时间 | 节点 | 说明 |
|---|---|---|
| 2008 | VISENSIA | 连续生命体征风险指数产品化 |
| 2010s | ICU信息化 | 设备、检验、EHR 接入成为前提 |
| 2020 | 远程ICU | 高负荷病房推动连续监测 |
| 2024 | Prenosis | 脓毒症风险分层监管节点 |
| 2026 | Bayesian Health | EHR 内连续脓毒症提示进入近90天热点 |
| 当前 | 治理闭环 | 竞争焦点转向数据、报警和责任链 |
产品竞争分四层
ICU AI 不能直接放进一张“准确率排行榜”。不同产品解决的是不同环节。
第一层是生命体征风险指数。它靠近监护数据，价值是把连续变化压缩成趋势和风险等级。VISENSIA 属于这个早期路线。
第二层是病情恶化和远程监测。它不只计算一个床旁分数，还要服务 ICU 指挥中心、护士站和高负荷病房队列。CLEW ICU 更接近这个方向。
第三层是脓毒症风险分层。它聚焦一个高风险临床问题，把实验室、生命体征、病史和当前状态整合成风险提示。Prenosis 和 Bayesian Health 都在这个层面，但前者更强调风险分层产品，后者更强调 EHR 内连续提示。
第四层是多源数据融合和治理平台。它把床旁设备、监护、呼吸机、实验室和 EHR 统一到一个 ICU 决策视图里。Etiometry 的价值就在这里：不是单个模型更强，而是把复杂 ICU 的数据变成可解释的临床视图。
医院选 ICU AI，不能只问“模型准不准”，还要问它属于哪一层、接哪类数据、提示给谁、谁来复核、出了问题怎么回滚。
代表产品逐个拆解
VISENSIA：连续生命体征风险指数
VISENSIA 的价值在于它很早就把 ICU/高依赖病区连续生命体征变成风险指数。它看的是心率、血压、呼吸、血氧等信号，输出病情恶化提示、风险分层和趋势变化。
它适合说明 ICU AI 的第一个产品化逻辑：临床不缺单个数字，临床缺的是“这些数字一起变化时，是否意味着患者正在变坏”。
优势是起点早、贴近监护数据、适合连续观察，也容易被医生护士理解。局限也很明显：早期产品形态更接近风险指数和监护增强，不能直接代表今天强调 EHR 嵌入、多源数据融合和行动闭环的新一代 ICU AI。
CLEW ICU：把风险预测做成病房队列
图注：CLEW ICU 官方产品页截图，访问时间 2026-07-19。页面作为官方入口证据，产品价值需结合其 ICU 监测与预测定位理解。
CLEW ICU 的产品语言更接近“远程监测 + 病情恶化预测 + 行动队列”。它不只是给单个患者打分，而是把 ICU 患者放进一个动态风险队列，让临床团队知道谁更值得优先复核。
这类产品特别适合高负荷 ICU、远程 ICU 和多院区管理。它的优势不是替代医生，而是帮助团队在大量床位、连续数据和人手紧张之间重新排序注意力。
局限在于报警阈值和解释。一个 ICU 科室能不能接受 AI 提示，取决于提示是否稳定、是否能解释、是否减少无效报警，以及护士医生是否愿意把它纳入交班和查房。
Prenosis：把脓毒症风险分层做窄
图注：Prenosis Sepsis ImmunoScore 官方页面截图，访问时间 2026-07-19。它代表把脓毒症风险分层单独做成产品的路线。
Prenosis 的特点是边界更窄：它不试图覆盖 ICU 全部风险，而是聚焦脓毒症风险分层。输入包括实验室指标、生命体征、临床数据和患者状态，输出 Sepsis ImmunoScore、风险等级和复核线索。
这种路线的优点是临床问题清楚，监管和验证也更容易围绕一个目标展开。脓毒症本来就是 ICU 和急诊都极其重视的病种，早发现、早复核、早干预有明确临床意义。
但也正因为它聚焦脓毒症，医院不能把它当成“ICU 通用智能系统”。它更像一个高风险病种分层工具，必须和本院脓毒症流程、抗感染规范、检验回报时间、护士执行链路和医生复核机制绑在一起。
Bayesian Health：EHR里持续盯脓毒症风险
图注：Bayesian Health 官方页面截图，访问时间 2026-07-19。openFDA 记录显示其 Sepsis Flagging Device 在 2026-04-30 获得 510(k) clearance。
Bayesian Health 是本期近 90 天最值得关注的节点。openFDA 记录显示，Bayesian Health Sepsis Flagging Device 在 2026-04-30 获得 510(k) clearance。
它的关键不是“又一个脓毒症模型”，而是 EHR 内连续风险监测。也就是说，AI 不只是研究环境里跑分，而是把生命体征、实验室、医嘱变化和病历数据持续汇总，在医生护士日常使用的系统里提示风险。
这类产品最容易获得医院关注，也最容易触发治理难题。提示太少，临床觉得没用；提示太多，护士和医生很快疲劳。它必须回答：谁收到提示，多久响应，哪些提示被排除，哪些提示带来处置变化，最终是否真的减少漏诊或延误。
Etiometry：把ICU数据变成统一决策视图
图注：Etiometry 官方页面截图，访问时间 2026-07-19。它代表 ICU 多源数据融合和临床决策支持平台路线。
Etiometry 和单病种预警工具不一样。它的重点是把床旁设备、监护仪、呼吸机、实验室、EHR 和治疗数据整合进一个统一视图，帮助 ICU 团队看风险趋势、治疗反应和处置参考。
这类产品适合复杂 ICU，尤其是儿科 ICU、心脏 ICU 或多设备密集场景。它解决的不是“某个模型能不能提前预测”，而是医生每天面对的另一个问题：数据太多、分布太散、上下文太难拼。
优势是系统价值更强，能把监测变成决策支持和质量追踪。局限是部署成本更高。设备网关、数据标准、接口、权限、审计、模型版本和院内治理能力，都会直接决定最终效果。
横向对比
| 产品 | 位置 | 输入 | 输出 | 优势 | 主要边界 |
|---|---|---|---|---|---|
| VISENSIA | 风险指数 | 生命体征 | 恶化提示 | 起点早、贴近监护 | EHR嵌入较弱 |
| CLEW ICU | 远程监测 | ICU连续数据 | 风险队列 | 适合高负荷ICU | 报警治理要求高 |
| Prenosis | 脓毒症分层 | 检验+临床 | ImmunoScore | 病种边界清楚 | 不能替代诊断 |
| Bayesian Health | EHR提示 | EHR+生命体征 | 风险旗标 | 近90天监管热点 | 易引发报警疲劳 |
| Etiometry | 数据平台 | 设备+EHR | 统一视图 | 多源融合强 | 集成成本高 |
我认为，ICU AI 的产品竞争已经很清楚：一类产品抢“早期风险提示”，一类产品抢“脓毒症流程”，一类产品抢“ICU 数据底座”。它们都叫 ICU AI，但采购逻辑完全不同。
如果医院只是想先做一个可控试点，脓毒症风险分层更容易定义指标。如果医院已经有远程 ICU 或多院区管理需求，病房队列和连续监测更值得看。如果医院真正想做 ICU 数字化升级，多源数据平台才是长期底座。
医院如何选型与部署
ICU AI 上线前，医院至少要问六个问题。
第一，数据源是否真实可接。监护仪、呼吸机、输注泵、血气、检验、EHR、护理记录和医嘱系统，哪些是实时，哪些是批量，哪些根本没有标准接口？如果数据延迟太长，所谓“早期预警”就会变成事后提醒。
第二，提示如何进入临床班次。AI 提示发给谁？护士、医生、值班总住院、ICU 指挥中心还是质控人员？是否进入交班、查房、会诊和医嘱流程？如果只是多一个独立网页，使用率通常很难稳定。
第三，报警阈值谁来调。ICU 患者本来波动大，阈值太敏感会造成报警疲劳，阈值太保守又会漏掉风险。医院要在试点期记录提示数量、确认率、排除率、干预率和真实结局。
第四，医生护士如何复核。AI 不能直接承担诊疗责任。产品必须支持“确认、排除、延迟处理、升级处置、记录理由”，并能追踪每一次提示后来发生了什么。
第五，效果怎么证明。不要只看厂家给的 AUC。院内试点更应该看：提前多久发现风险、误报带来多少额外工作、是否缩短抗感染或升级处置时间、是否降低漏报、是否改善 ICU 质量指标。
第六，失败时怎么退出。模型版本、阈值、接口和提示策略都可能漂移。医院必须要求供应商提供升级回滚、报警关闭、审计日志和本院数据再验证资料。
国内代表厂家：产品边界与交付方式
| 公司 | 具体产品 | 可核验优势 | 部署方式 |
|---|---|---|---|
| 迈瑞医疗 | 重症监护与中央站方案 | 监护设备入口和院内装机基础强 | 院内设备/中央站；AI模块边界招采确认 |
| 麦迪科技 | 重症/麻醉/急诊信息系统 | 专科临床信息化和数据采集交付 | 院内项目制；AI预警能力按资料确认 |
| 卫宁健康 | 医院信息平台/数据治理 | HIS/EMR/数据平台入口 | 院内部署；ICU算法边界招采确认 |
| 东软集团 | 医院信息化/专科数据平台 | 系统集成和数据平台经验 | 项目制交付；重症AI模块需核验 |
| 联影智能 | uAI平台与医疗AI生态 | AI平台化和设备生态能力 | 院内/云边按产品确认；ICU场景需核验 |
这张表不是说这些厂家都已经有成熟 ICU AI 预警产品，而是给医院一个采购坐标：ICU AI 不只看算法公司，也要看设备入口、专科系统、EHR、数据平台和 AI 平台生态。招采时必须索取注册证或备案资料、接口清单、网络拓扑、数据流向、权限设计、升级回滚、本院验证方案和报警治理方案。
风险与边界要先说清楚。 ICU AI 最大的风险，是把“风险提示”误读成“诊断结论”。
脓毒症尤其典型。AI 可以提示患者风险升高，可以帮助医生更早复核，但它不能替代感染灶判断、器官功能评估、血培养、抗感染策略和临床经验。把 AI 提示写成“确诊脓毒症”，不仅不准确，也会带来责任风险。
第二个风险是报警疲劳。ICU 的每一次提醒都会消耗注意力。医院不能只看模型召回率，还要看每百床日新增多少提醒、护士需要多花多少时间、医生确认率是多少、多少提示最终改变了处置。
第三个风险是数据漂移。ICU 患者结构、治疗流程、检验回报时间、设备型号、护士记录习惯都会变。一个模型在 A 医院表现好，不代表在 B 医院照样能用。
第四个风险是系统集成。很多 ICU AI 产品听起来是算法，真正实施时却是接口工程、设备网关工程、数据治理工程和临床运营工程。医院如果没有信息科、医务、护理、重症科和质控一起参与，很容易上线后没人用。
ICU AI 的边界要写在采购合同和上线制度里：AI 提示什么，不提示什么，谁复核，谁签字，谁负责监测效果，谁有权暂停。
未来会怎么发展？
图注：这张图解释未来 ICU AI 的业务闭环：从患者入口、床旁数据、AI 任务到临床行动和治理复盘。
图注：这张图解释未来 ICU AI 的技术底座：设备接入、时间序列特征、模型层、工作流层和治理层必须一起设计。
未来 3-5 年，ICU AI 会沿着两条线发展。
第一条线，是更窄但更可验证的病种工具。脓毒症、病情恶化、呼吸风险、循环风险、拔管失败、急性肾损伤等，都会被做成更具体的风险分层和行动提示。它们的优势是目标清楚，验证也相对可控。
第二条线，是更宽的 ICU 数据和治理平台。医院不会长期忍受每个 AI 都单独接一次设备、单独建一个网页、单独发一套提醒。最终更可能形成统一的数据接入、统一的风险队列、统一的医生护士复核和统一的质控复盘。
这也是 ICU AI 和影像 AI 最大的不同。影像 AI 先从单个检查切入，再慢慢进入工作流；ICU AI 从第一天开始就绕不开工作流，因为 ICU 的数据和责任本来就是连续的。
写在最后
ICU AI 的故事，表面上是模型越来越会预测风险，实际上是医院越来越需要把风险管理做成系统工程。
如果一个产品只能给一个风险分数，却说不清数据来自哪里、提示给谁、谁来复核、处置怎么记录、效果怎么复盘，那它很难真正进入 ICU。反过来，一个产品即使模型没有被包装得很神，只要能稳定接入数据、减少漏看、降低无效报警、把责任链记录清楚，就有机会成为 ICU 的基础设施。
本期一句话：重症医学科 AI 已经走过 18 年，下一阶段的核心不是替医生盯屏，而是把连续风险提示、临床复核和报警治理做成可追踪的 ICU 行动链路。
如果你是医院管理者或重症科负责人，你更愿意先试点哪一类 ICU AI：脓毒症风险分层、病情恶化预警，还是 ICU 多源数据治理平台？