2. 临床知识表示与规则建模基础

临床决策支持系统（CDSS）的规则引擎，本质上是一台“把临床知识翻译成可执行判断”的机器。要让机器可靠地执行判断，第一步不是写代码，而是把临床指南、临床路径和诊疗协议中隐含的知识，转换成结构明确、边界清晰、可被反复求值的形式。这一节讨论的就是这种“知识表示”与“规则建模”的基础工作。

一、三类临床知识源的区别与规则化难点

临床指南（Guideline）通常是面向疾病整体的循证推荐，例如“对确诊社区获得性肺炎且CURB-65评分≥2的成人患者，建议住院治疗”。它的特点是覆盖面广、证据等级明确，但表述往往是自然语言，包含“建议”“可考虑”“除非”等模糊限定词。临床路径（Pathway）则是针对某一病种或手术的标准诊疗流程，规定了时间节点、必做项目与变异处理，例如“术后第1天拔除导尿管，若未达标则记录变异原因”。诊疗协议（Protocol）更具体，常以“如果—那么”的形式规定用药、监测或调整方案，例如胰岛素强化治疗协议中的剂量调整表。

三类知识源的规则化难点不同：指南难在把推荐强度与条件组合翻译成可判定的逻辑表达式；路径难在时间轴与状态迁移的建模；协议难在数值阈值、单位换算和剂量计算的精确表达。工程上通常先建立“知识源—规则单元—可执行规则”的三层映射，再逐条落地。

二、产生式规则：最基础的“条件—动作”表示

产生式规则（Production Rule）是规则引擎中最常见的表示形式，结构为：IF <条件集合> THEN <动作或结论>。例如一条肺炎严重程度评估规则可以写成：

IF 年龄 >= 65
   AND 呼吸频率 >= 30 次/分
   AND 收缩压 < 90 mmHg
THEN CURB-65 评分 += 1（每项满足各计1分）
     输出：建议住院评估

产生式规则的优点是直观、易审查、易追溯；缺点是当条件维度增多时，规则数量会迅速膨胀，且规则之间的优先级、冲突消解需要额外机制。工程实现中，通常把条件拆成“事实（Fact）”与“谓词（Predicate）”，事实来自患者数据，谓词是对事实的判断，动作则写入结论对象或触发提醒。

三、决策表与决策树：把组合条件可视化

当多个条件以组合方式决定同一结论时，决策表（Decision Table）比一堆产生式规则更清晰。决策表以行表示规则、列表示条件与动作，每一行是一条完整规则。例如抗凝治疗选择可以表示为：

决策表的优势在于“完备性”和“互斥性”可以被显式检查：是否所有条件组合都有结论、是否存在同一组合命中多行。决策树（Decision Tree）则把判断过程展开为树形分支，适合展示“先判断什么、再判断什么”的临床思维顺序，也便于计算每条路径的覆盖率和命中率。

四、HL7 Arden Syntax 与 CQL 初步认识

Arden Syntax 是 HL7 发布的医学逻辑模块（MLM）表示语言，核心结构是 maintenance、library、knowledge 和 evoke 四部分。它用 evoke 定义触发事件，用 logic 槽写判断逻辑，用 action 槽写提醒或写入操作。例如一个简单的血钾报警 MLM：

evoke: 血钾结果可用;
logic:
  IF 血钾 > 6.0 THEN
    conclude true;
  ELSE
    conclude false;
  ENDIF;
action:
  WRITE "高钾血症，建议立即复查并评估处理";

Arden Syntax 的优点是事件驱动、与临床工作流结合紧密；缺点是语法较老、复杂计算和跨患者查询能力有限。CQL（Clinical Quality Language）则是较新的 HL7 标准，面向临床质量测量与决策支持，强调基于 FHIR 等数据模型的声明式查询与逻辑表达。CQL 中常用 define 定义可复用表达式，用 Retrieve 获取患者数据，用 where 过滤条件。例如：

define "高钾血症患者":
  [Observation: "血钾"] O
    where O.value > 6.0 'mmol/L'
      and O.status = 'final'

与 Arden 相比，CQL 更强调类型系统、时间区间运算和可复用性，适合把指南中的复杂条件写成可测试、可版本管理的逻辑库。工程实践中，常见做法是：用 CQL 表达指南与协议中的判断逻辑，用规则引擎执行编译后的表达式，用决策表管理简单组合条件，用决策树或流程图辅助临床审查。

五、从知识到规则的落地要点

把上述方法用于工程时，有几个容易被忽视但影响很大的细节。第一，术语与单位必须统一：指南写“血钾>6.0 mmol/L”，数据源可能返回 mg/dL，规则中必须显式声明单位与换算，否则阈值判断会静默出错。第二，时间语义要明确：是“最近一次”“24小时内”还是“本次住院期间”，不同时间窗口会改变规则命中结果。第三，缺失值策略要预先定义：条件字段为空时，是跳过该规则、按最差情况处理，还是触发数据补录提醒，必须在规则元数据中写明。第四，规则版本与患者快照要绑定：同一条规则在不同版本下可能给出不同结论，审计时需要能还原“当时用的是哪版规则、输入是什么”。

一个可操作的检查清单是：每条规则是否有唯一标识、知识来源、适用人群、触发事件、条件字段与单位、缺失值处理、动作类型、优先级、版本号和审查人。把这些字段补齐，规则才真正具备可维护、可追溯、可复现的工程属性，而不是停留在文档里的自然语言描述。