过去三年，临床营养信息化建设从「有没有系统」进入了「系统用得好不好」的阶段。越来越多的医院完成了营养诊疗系统的部署，筛查覆盖率、评估完成率等前端指标在持续改善。但当数据往下游走——从评估到干预方案的生成——问题就出现了。
中国医院协会信息管理专业委员会2025年的一项调研显示，在已部署营养信息系统的三级医院中，营养风险筛查完成率的中位数已达到79%，营养评估启动率为64%。但同一批医院中，筛查阳性患者的干预方案系统生成率（即在系统中直接开具营养干预方案的比例）仅为38%。从评估到干预之间的转化率，比从入院到筛查的转化率低了近一倍。
这不是个别现象。在多家医院的实际运行数据中，「评估数据产出了，但干预方案没有跟着生成」是一个普遍存在的链路断点。问题出在系统层面：评估模块和干预模块之间的数据通路没有真正打通——评估结果没有被系统自动转化为干预决策的依据，营养师需要手动将评估结论「搬运」到处方界面。
本文顺着评估数据到干预方案的流转路径，拆解这条决策链路中的四个关键节点。每个节点对应一类系统能力，四类能力叠加，才能实现从数据采集到方案生成的完整闭环。
第一步：评估数据的结构化程度，决定了下游能走多远
决策链路的第一关，在评估环节就埋下了伏笔。评估数据能不能被下游的干预模块有效利用，根本上取决于评估数据的结构化程度。
字段结构的粒度问题
一份营养评估记录在系统中的呈现方式，直接决定了它能否被下游决策逻辑识别和调用。
以「营养诊断」这个字段为例。在结构化程度低的系统中，营养诊断是一个自由文本框，营养师在其中输入「患者存在中度营养不良，主要与疾病消耗有关」。这段文字人读了能理解，但系统无法从中自动提取「营养不良程度=中度」「主要病因=疾病消耗」这两个关键信息。当系统试图根据诊断结果推荐干预方案时，它面对的是一个无法解析的文本块。
在结构化程度高的系统中，营养诊断被拆解为多个编码化字段：
- 诊断类型：下拉菜单选择（蛋白质-能量营养不良/微量营养素缺乏/营养过剩）
- 严重程度：下拉菜单选择（轻/中/重）
- 主要病因：下拉菜单选择（摄入不足/吸收障碍/消耗增加/代谢紊乱）
- 是否与疾病相关：是/否，关联疾病诊断编码
每一个字段的值都是可枚举、可计算、可映射的。系统可以基于「严重程度=中」+「主要病因=消耗增加」+「关联诊断=胰腺炎」这组结构化数据，自动匹配适用的干预路径模板——比如推荐肠外营养支持、设定蛋白质目标范围、提示监测炎症指标。
国家卫生健康委医院管理研究所2025年发布的评估报告中有一个数据侧面印证了结构化程度的影响：评估记录结构化字段占比超过60%的医院，评估数据的下游调用率（即在干预方案制定中被系统自动引用的比例）平均为71%；结构化字段占比低于30%的医院，这个数字仅为22%。
「够用」的结构化：一个经验判断标准
但结构化不是越细越好。把评估模板做成三十个必填下拉菜单，操作成本上升，评估完成率反而下降。这里存在一个经验判断：「够用」的结构化，是指所有需要在干预决策中使用的评估维度，都拆解到了系统可识别的粒度。
具体来说，以下五类评估信息必须结构化：
- 营养诊断编码及分级——决定干预方案的类型和强度
- 体重及体重变化趋势——决定能量和蛋白质目标
- 膳食摄入评估结果——决定营养支持途径（口服/肠内/肠外）
- 实验室关键指标（白蛋白、前白蛋白、CRP等）——决定代谢状态评估和配方调整
- 吞咽功能及胃肠道功能评估——决定喂养途径和制剂选择
这五类信息是干预方案制定时的核心输入参数。它们如果以自由文本形式存在于评估记录中，下游的决策支持模块就无法自动读取和利用这些数据。反之，只要这五类信息实现了结构化录入，系统就具备了从评估到干预的基础数据条件。
一个实用的自检方法是：打开任意一份已完成的营养评估记录，看系统能否自动从中提取出「患者画像」——即一组可用于匹配干预规则的参数组。如果不能，说明评估数据的结构化程度还不足以支撑下游决策链路的自动化。
第二步：结构化数据到风险画像，中间缺一个计算层
评估数据完成了结构化录入，下一步是什么？不少系统的做法是：把结构化的评估数据直接展示在干预模块的「参考信息」区域，让营养师自己看、自己判断。
这种做法没有错，但它绕过了系统可以发挥最大价值的一环——计算层。
从原始参数到综合风险评分
孤立的结构化数据点对决策的支撑有限。一份评估记录中包含体重62kg、近期下降8%、血清白蛋白32g/L、CRP 45mg/L、NRS2002评分4分。这些数据各自有意义，但营养师需要一个综合性的判断：这位患者的营养干预紧迫度有多高？首选干预途径是什么？最适合的蛋白质目标范围是多少？
系统层面的「计算层」，就是把这些原始参数转化为可用于决策的综合性指标。具体包括但不限于以下几类计算：
- 营养风险分层：基于NRS2002评分、体重下降速率、疾病严重程度的综合判断，输出「高风险/中风险/低风险」的分层结果
- 能量需求估算：根据体重、活动系数、应激系数、疾病修正因子，自动计算目标能量范围
- 蛋白质需求估算：根据体重、肾功能状态、分解代谢程度，自动计算目标蛋白质量
- 营养支持途径推荐：根据吞咽功能、胃肠道功能、进食量的综合评估，推荐「口服营养补充/肠内营养/肠外营养」的优先级
- 监测频率建议：根据风险等级和代谢稳定性，建议营养指标的复评周期
这些计算在营养师的大脑里也在进行，但系统化的计算层有两点优势：第一，计算规则全院统一，不会出现不同营养师对同一份评估数据得出不同方案的情况；第二，计算结果可以直接传入下游的处方推荐模块，省去营养师的重复录入。
规则引擎的配置原则
实现计算层的关键技术组件是规则引擎——一套将「如果-那么」逻辑以可配置方式运行的模块。规则引擎的建置需要遵循三个原则。
原则一：规则来源要可追溯。 每一条计算规则都应标注出处——来自哪份指南、哪个共识、哪个版本的推荐。例如「胰腺炎急性期患者的目标蛋白质按1.2-1.5g/kg/d计算」这条规则，出处标注为「中华医学会肠外肠内营养学分会《急性胰腺炎营养支持专家共识》(2024版)」。标注出处不是为了做学术文章，而是为了规则迭代时有据可查——当新指南发布时，能快速定位需要更新的规则。
原则二：规则参数要可配置。 不同医院的临床实践存在差异。一家以肿瘤患者为主的专科医院和一所以创伤急救为主的综合医院，在能量目标的设定上可能有不同的数据积累和习惯。规则引擎中的各项计算系数（应激系数、活动系数、各类修正因子）应开放给医院自定义配置，而不是固化在代码中。
原则三：规则的优先级要清晰。 当多条规则同时适用于同一患者时，需要明确的优先级规则。例如「患者肾功能不全（eGFR<30mL/min），同时处于高分解代谢状态」——蛋白质限制的规则建议0.8g/kg/d，高分解状态的规则建议1.2-1.5g/kg/d。规则引擎需要预设冲突解决策略：哪个规则优先，还是取中间值，还是标记为人工判断。
广东省某三甲医院在规则引擎上线后的数据可以作为参考。该医院营养科自定义了47条计算规则，覆盖了能量需求、蛋白质需求、电解质调整、液体管理等主要决策场景。规则引擎上线六个月后，评估完成后系统自动生成「营养干预建议方案」的耗时从营养师平均15分钟（人工计算+查阅指南）缩短至系统即时生成，方案生成率的同质化程度（即同一患者的干预方案在不同营养师之间的一致性）从62%提升至89%。
第三步：从风险画像到干预方案，规则映射是核心工程
计算层输出了患者的风险画像和营养需求参数。第三步是将这些参数映射为具体的干预方案——包含营养支持途径、制剂选择、剂量范围、输注路径等维度的完整处方建议。
这一步是整个决策链路中最接近「临床智能」的环节，但它的实现原理并不神秘：本质上是一张多维度的规则映射表。
映射表的设计逻辑
一张干预方案映射表由「条件列」和「结果列」组成。条件列描述患者的特征参数组合，结果列描述对应的干预方案建议。
以营养支持途径的决策为例。条件列包括：吞咽功能（正常/障碍/丧失）、胃肠道功能（正常/部分受损/不能耐受）、经口摄入量（满足目标需求的百分比）。这三组参数的组合，可以映射出六到八种支持途径的优先级排序——吞咽功能正常且经口摄入达标则首选口服营养补充，吞咽障碍但胃肠道功能正常则首选管饲肠内营养，胃肠道不能耐受则考虑肠外营养。
映射表的设计质量取决于两个维度：条件组合的覆盖度和结果推荐的精准度。
条件组合的覆盖度，指的是映射表能否覆盖临床中绝大多数常见的患者情况。一个覆盖度好的映射表应该能处理90%以上的日常处方场景，只有少数边界情况需要人工判断。检验覆盖度的方法是抽样：从前三个月已处理的处方中随机抽取100-200份，逐个验证系统映射表是否覆盖了这些处方的决策条件。覆盖度低于80%的映射表，需要补充条件组合或调整分类粒度。
结果推荐的精准度，指的是映射表推荐方案与实际处方方案的一致程度。同样用抽样方法验证——看系统推荐的方案与营养师最终开具的方案在核心参数上的一致性。一致率在85%以上说明映射表与临床实践匹配良好，低于70%则说明映射表的规则需要调整（可能阈值不合适、条件粒度过粗或忽略了重要的修正因子）。
映射表的持续更新机制
映射表不是上线时配置一次就完事的。它需要经历持续的更新迭代。
更新的驱动力来自两方面。一是外部知识更新——新指南发布、新制剂上市、新循证证据出现。二是内部数据积累——随着处方数据量的增加，系统可以分析本院各科室的实际处方习惯，发现映射表与实际操作之间的偏差，找出需要修正的规则。
从多家医院的实际操作经验来看，映射表维护的合理节奏是：上线后前三个月，每两周复查一次映射表的推荐精准度，重点优化推荐一致率偏低的规则。三个月后转为月度审查，主要处理新出现的临床需求和指南更新。每季度做一次完整的映射表审核，确保所有规则的出处信息仍然有效。
第四步：方案生成到执行反馈，链路需要形成闭环
前三步走完，系统已经从评估数据走到了干预方案。但链路并未结束。方案被执行之后发生了什么——患者对治疗的反应如何、营养指标的改善情况、方案是否需要调整——这些反馈信息如果不能回到系统，决策链路就是「半开环」的。
反馈数据的采集机制
干预方案执行后的反馈数据采集，需要系统在流程层面做好三个前置设计。
第一个是「方案执行状态的自动追踪」。处方开具后，系统需要能追踪到：处方是否已执行、执行了多少剂量、执行途径是否正确、有无出现喂养中断。这些信息的最佳来源是医嘱执行记录和护理记录——通过接口从护理系统或移动护理终端获取。在没有接口的条件下，至少需要在系统中设计一个轻量级的执行确认流程，由执行护士在系统中勾选完成状态。
第二个是「临床指标变化的自动关联」。患者接受了营养干预后，体重变化、营养筛查评分的动态变化、实验室指标（白蛋白、前白蛋白、转铁蛋白等）的改善情况，这些数据分布在不同的系统和记录中。系统需要能将同一患者的时间序列指标自动关联到他的营养干预记录上——营养师查看一份干预方案时，能同时看到该方案实施后患者各项指标的走势。
第三个是「方案调整理由的结构化记录」。当营养师对初始方案做出调整时，系统应引导营养师记录调整原因——是患者不耐受（具体表现）、指标未达标（哪个指标）、还是临床状况变化（什么变化）。这些调整记录积累到一定量后，可以作为映射表优化的输入——某个方案的调整频率超过阈值，说明初始的推荐规则可能存在偏差。
闭环数据反哺决策链路的两种方式
反馈数据积累到一定规模后，可以反哺到链路的前端。
第一种反哺方式是用实际效果校正推荐参数。例如，映射表为某类患者推荐的能量目标为25-30kcal/kg/d，但在六个月的临床数据中，按此目标干预的患者中有约四分之一的体重持续下降。这个信号提示该推荐区间可能偏低，需要重新审视适用条件或调整推荐值。
第二种反哺方式是用执行数据优化方案细节。如果追踪数据显示，肠内营养的喂养中断有约六成发生在置管相关问题上，系统在生成管饲方案时就应该增加「置管方式评估」的前置提示。这个问题不是营养方案本身的问题，而是方案执行条件的评估——但闭环数据能把这个关联暴露出来，成为决策链路上的一个新增的参考维度。
五、链路打通之后，决策时间的压缩是可见的
回到文章开头的问题：从评估到干预的转化率为什么低？
拆解完四个节点后，问题本质上不是营养师不勤快，而是数据在系统内部的流转路径没有建好。评估数据是结构化的吗？有没有计算层把它转化为决策参数？参数有没有映射到处方推荐规则？推荐的方案在执行后有没有反馈回来？四个节点任何一个断掉，决策链路就卡住了。
链路打通之后，效率改善是可衡量的。某省级三甲医院在完成上述四层能力建设后，内部做了一个对比测试：选取50例需要进行营养干预的患者，一组（25例）由营养师按传统方式完成评估到方案开具，另一组（25例）使用系统决策链路辅助。前者的平均耗时（从评估完成到处方提交）为47分钟，后者为11分钟。前者在方案核心参数（能量目标、蛋白质目标、途径选择）上的一致率为71%，后者为88%。
这不是一个「机器替代人」的故事。系统的决策链路做的是标准化和自动化的部分——把指南推荐、数据计算、规则匹配这些可重复的脑力劳动交给系统。营养师在这些工作的基础上，把精力集中在需要临床判断的环节：当系统推荐与患者个体情况出现偏差时的调整决策、边界情况的处理、以及方案的动态优化。
决策链路的价值，不是让系统代替营养师开处方，而是让营养师在开处方这件事上腾出更多时间和精力，去处理那些真正需要专业判断的临床问题。链路打通之后，每个环节省下的几分钟累加起来，对一个每天处理数十份处方的营养科来说，释放的时间总量是可观的。
从更大范围看，决策链路的打通还是临床营养数据资产积累的基础设施——每一条从评估到干预再到反馈的数据链路，都是一次完整的诊疗知识结构化记录。当这些记录积累到足够规模时，它不仅支撑今天的处方推荐，还为明天基于本院真实数据的决策支持提供了「燃料」。数据积累从链路打通的第一天就开始了，不需要等到系统运行一年后再启动。
这个认知，可能是决策链路建设中最值得投资回报率的认知转变：链路不是成本，它是数据资产的管道。管道建好了，数据才能流动。数据流动起来，它的价值才有机会被释放。