1. CDS规则引擎工程导论

临床决策支持系统（Clinical Decision Support System，CDSS）并不是一个单一软件，而是一类在诊疗流程的关键节点上，把“可执行的医学知识”推送给医生、护士、药师或患者的信息系统能力。它的核心价值在于：在正确的时间、以正确的方式、把正确的信息交给正确的人，从而减少遗漏、降低差错、提升诊疗一致性。而规则引擎，正是把“医学知识”转化为“系统可执行判断”的那台发动机。

一、CDSS的定义与边界

从工程视角看，一个CDSS至少包含四层：数据层（患者基本信息、诊断、检验、用药、生命体征等）、知识层（指南、路径、药品说明书、机构共识）、推理层（规则引擎、逻辑判断、评分计算）、交互层（弹窗提醒、医嘱拦截、面板展示、报告生成）。缺少推理层，系统只是数据展示；缺少交互层，知识无法在诊疗现场生效。因此，CDSS的边界不是“有没有知识库”，而是“知识能否在具体患者上下文里被触发并影响决策”。

二、CDSS的常见分类

按干预时机可分为前置型（开医嘱前提醒、禁忌拦截）与后置型（回顾性质控、病历审核）；按干预方式可分为主动推送（弹窗、强制拦截）与被动查询（医生主动查看评分、用药建议）；按知识形态可分为基于规则的、基于评分模型的、基于路径的以及混合型。工程上最常落地的是“规则+评分”的混合模式：规则负责硬性约束（如青霉素过敏禁用），评分负责风险分层（如CHA₂DS₂-VASc、CURB-65）。

三、规则引擎在CDS中的核心地位

规则引擎承担三件事：第一，把医学知识从代码中解耦出来，让临床专家可以参与维护；第二，在患者数据流中持续匹配条件，决定是否触发；第三，输出可解释的结论与建议，而不是黑箱结果。一个典型的规则结构可以写成“当条件集合满足时，执行动作”。例如：

规则：肾功能不全患者使用二甲双胍提醒
WHEN
  患者.eGFR < 45 mL/min/1.73m²
  AND 当前医嘱.药品通用名 = "二甲双胍"
THEN
  触发提醒：建议评估肾功能，考虑减量或更换
  严重级别：中
  可覆盖：是（需填写理由）

这条规则里，eGFR是数据字段，二甲双胍是医嘱对象，触发提醒是动作，严重级别和可覆盖性则是工程治理参数。规则引擎的价值，正是让这类逻辑可以被版本化、测试、审计和灰度发布。

四、课程知识地图与实战项目

本课程围绕“从知识到可运行规则，再到临床可评估效果”的主线展开，整体分为五个阶段：基础认知（CDSS定义、分类、价值与规则引擎定位）、知识建模（规则结构、数据模型、术语与编码）、引擎实现（规则解析、匹配算法、冲突消解、执行链）、工程治理（版本管理、测试、监控、告警、权限与审计）、临床落地与评估（交互设计、告警疲劳治理、效果指标与迭代）。

贯穿课程的实战项目是“住院患者抗菌药物与肾功能联动提醒引擎”。项目会从一份真实风格的规则集出发，逐步完成数据字段映射、规则编写、优先级设置、测试用例设计、模拟运行与结果判读。示例参数均为教学假设，例如：患者肌酐清除率按Cockcroft-Gault公式估算，体重取70 kg，年龄取65岁，血清肌酐取1.8 mg/dL，则估算CrCl约为36 mL/min，属于中度肾功能不全，此时若开具某些经肾排泄且需减量的抗菌药物，规则应触发“剂量调整建议”而非简单禁用。

五、从“能提醒”到“值得提醒”

很多CDS项目失败，不是因为规则写不出来，而是因为提醒太多、太频繁、太不可解释，最终被临床用户关闭。工程上必须把“告警疲劳”当作一等公民来治理：设置合理的严重级别、允许有理由覆盖、对低价值提醒做降噪合并、对高频触发规则做定期评审。一个可用的判断标准是：如果某条规则的“采纳率”长期低于10%，且覆盖理由高度集中为“临床已考虑”，就应进入复审或下线流程。

接下来的章节将沿着“知识建模—引擎实现—工程治理—临床落地”的路径逐步展开。你会看到规则如何从一段自然语言指南，变成可测试、可版本化、可审计的工程资产，也会看到当规则真正进入医嘱流程后，如何用数据判断它是否值得继续存在。