2. 临床决策支持系统需求工程

临床决策支持系统（CDSS）失败的最常见原因，不是算法不够先进，而是需求从一开始就没有被正确捕获和转化。临床路径、诊疗指南、质控指标这三类知识源，分别代表了“标准动作序列”“最佳证据推荐”和“质量底线约束”，它们与可执行需求之间隔着一条需要工程化翻译的鸿沟。本节的任务，就是建立这条翻译链，并给出利益相关者分析、功能与非功能需求划分、需求追踪矩阵以及真实科室调研的完整方法。

三类知识源如何转化为可执行需求

临床路径描述的是某病种从入院到出院的标准诊疗流程，例如“急性ST段抬高型心肌梗死”路径中，从急诊接诊、心电图完成、双联抗血小板负荷、到导管室激活的时间节点。它转化为需求时，核心是时序约束与触发条件：系统应在“心电图确诊STEMI”这一事件发生后，立即触发“启动导管室”提醒，并记录从确诊到激活的时间戳。

诊疗指南提供的是证据等级分层的推荐意见，例如“对于eGFR<30的房颤患者，不推荐使用达比加群”。它转化为需求时，核心是条件判断与禁忌拦截：当处方系统检测到患者eGFR值低于阈值且医嘱药品为达比加群时，弹出不可覆盖的禁忌警告，并记录拦截日志。

质控指标则是可量化的质量底线，例如“抗菌药物使用前微生物标本送检率≥50%”。它转化为需求时，核心是统计口径与实时监测：系统需在医嘱开立环节判断“是否已送检”，并在科室看板中按“使用前”这一时间窗口实时计算送检率。

利益相关者分析：谁的需求在说话

CDSS的需求来源从来不是单一的。临床医生关注“提醒是否准确、是否打断工作流”，护士关注“评估表单是否自动带出、是否重复录入”，信息科关注“接口是否稳定、规则是否可配置”，医务处关注“质控指标是否达标、能否导出上报”，患者则关注“是否被过度检查或延误”。这些诉求之间存在天然张力：医生希望减少弹窗，医务处希望增加拦截，信息科希望规则集中管理，护士希望数据自动流转。

实际调研中，建议按“影响力—关注度”矩阵对利益相关者排序。以某三甲医院急诊科CDSS项目为例，高影响力高关注度的核心角色是急诊科主任和信息科接口负责人，必须深度参与需求评审；高影响力低关注度的角色是医务处处长，需定期汇报质控指标达成情况；低影响力高关注度的角色是轮转医生，可通过问卷收集痛点；低影响力低关注度的角色是后勤部门，保持通知即可。

功能需求与非功能需求的划分

功能需求回答“系统做什么”，非功能需求回答“系统做得怎么样”。在CDSS中，功能需求通常以“当……时，系统应……”的句式描述，例如：“当医生为eGFR<30的房颤患者开具达比加群时，系统应弹出禁忌警告并阻止医嘱提交。”非功能需求则包括响应时间、并发能力、可用性、安全审计、可维护性等。

一个容易被忽视的非功能需求是告警疲劳控制。如果系统对每个轻微药物相互作用都弹窗，医生会在两周内形成“无脑点击关闭”的习惯，导致真正的高危提醒也被忽略。因此，非功能需求中应明确：高危提醒采用硬拦截，中危提醒采用软提示并汇总展示，低危提醒仅记录不弹窗。这一策略需要在需求阶段就与临床科室达成一致，而不是上线后被动调整。

需求追踪矩阵：让每条需求可溯源

需求追踪矩阵（RTM）是需求工程的核心工具。它的基本结构是：每一行是一条需求，每一列是追踪维度，包括知识源ID、需求ID、优先级、验证方法、测试用例ID、上线状态。例如：

RTM的价值在于变更影响分析：当指南更新导致某条推荐变化时，可以快速定位受影响的需求、测试用例和上线模块，而不是靠记忆和翻文档。

真实科室需求调研任务

需求调研不是发一张问卷就结束。以急诊科CDSS为例，建议按以下任务闭环执行：

1. 现场观察：跟随急诊医生完成3～5个班次，记录实际工作流中的决策节点、信息查询动作和中断点。例如，医生在开具抗凝药前，实际会打开几个系统、查询哪些检验值。
2. 半结构化访谈：对急诊科主任、主治医生、护士长、信息科接口人分别访谈，每次30～45分钟，围绕“最近一次因为信息缺失导致决策困难是什么情况”展开。
3. 知识源梳理：收集科室现行临床路径、常用指南、质控上报指标，标注每条知识的来源、更新频率和当前执行方式。
4. 需求条目化：将访谈和观察结果转化为“当……时，系统应……”的条目，每条标注来源角色、优先级和验证方法。
5. 评审与确认：组织跨角色评审会，逐条确认需求，重点解决冲突项（如医生希望减少弹窗与医务处希望增加拦截之间的矛盾）。

从临床路径、指南、质控指标到可执行需求，本质上是把“医学知识”翻译成“工程约束”的过程。利益相关者分析决定了需求的来源是否完整，功能与非功能需求的划分决定了系统边界是否清晰，需求追踪矩阵决定了变更是否可控，而真实科室调研则决定了这一切是否扎根于临床实际。这四者缺一不可，共同构成CDSS需求工程的完整闭环。