营养诊断：临床营养诊疗系统中最易被「架空」的环节
一、一个普遍存在的系统功能真空
观察已经上线的临床营养诊疗系统，会发现一个有趣的现象。
系统的功能布局通常呈现一种两头大、中间细的哑铃形态：一头是营养风险筛查和评估模块——数据采集界面设计精细，量表选项齐全，评分自动计算，完成率纳入质控报表；另一头是营养处方和执行管理模块——处方开立、审核、配制、配送、执行记录回传，流程节点齐全。两头的功能密度都很高，投入了大量设计资源。
但位于中间的那个环节——营养诊断——在大多数系统中处于一种尴尬的位置。打开系统查看某个患者的营养诊疗记录，能看到筛查结论（阳性/阴性）、评估结果（NRS-2002 3分、MNA-SF 10分等量表分值）、以及处方内容（肠内营养制剂+剂量+途径）。但如果你问：这个患者的营养诊断是什么——是「能量-蛋白质摄入不足」还是「吞咽障碍导致经口摄入减少」还是「与肿瘤相关的营养不良」——系统里的数据不一定能直接回答这个问题。
在相当比例的现行系统中，营养诊断的处理方式有以下几种：
第一种，直接不设诊断字段。营养诊疗记录的组成是「评估结论 → 处方内容」，中间没有诊断这个节点。评估做完了就直接跳到开处方，营养师在开处方时凭自己的判断决定治疗方案，诊断作为一个思维步骤保留在营养师的脑子里，没有在系统中留下结构化的记录。
第二种，设了诊断字段但用的是自由文本。系统中有一个「营养诊断」输入框，营养师在此输入诊断描述。自由文本的好处是灵活性高——营养师可以用自己的语言描述诊断——但代价是这些文本无法被系统进一步处理。不能参与统计分析，不能用于质控回溯，不能在知识库中匹配对应的干预方案。信息进了系统，但信息处于结构化系统无法理解的「外面」。
第三种，诊断字段与评估结论混用。系统中没有独立的诊断环节，但评估结论中的「营养风险阳性」被当作诊断来使用。这种做法的逻辑是：患者被判定为营养风险阳性，自然需要营养干预，筛查结论直接驱动了处方决策。但这个替代逻辑是经不起推敲的——「有营养风险」和「具体是什么营养问题」是两个不同层面的判断。前者告诉系统「这个患者需要关注」，后者告诉系统「需要解决什么问题」。跳过后者直接开处方，相当于医生在没有明确诊断的情况下直接开药。
这三种处理方式覆盖了当前临床营养诊疗系统在营养诊断环节上的主流现状。而在现实业务中，这个环节的功能缺失正在产生可观察到的实际影响。2024年中国营养学会临床营养分会的一份报告中提及了一项覆盖62家三级医院的调研数据：在已部署营养信息系统的医院中，能够从系统中导出结构化营养诊断记录（而非自由文本或量表评分）的医院占比约为17.7%。也就是说，超过八成的医院在系统里找不到可以作为分析对象的结构化诊断数据。在没有结构化诊断数据的情况下，科室无法回答一个基础问题：本院住院患者中，最常见的营养诊断类型是什么、分布如何、各类诊断对应的干预方案是什么。
这个数据缺口不应该继续存在——不是因为「系统应该有这个功能」的抽象理由，而是因为营养诊断的缺失正在影响一系列后续临床决策的质量。
二、一条临床路径上，诊断决定了后面的所有动作
把营养诊断放在临床营养诊疗的完整路径中来看，它的位置比大多数人意识到的更关键。
标准的营养诊疗流程（Nutrition Care Process, NCP）由四个步骤组成：营养评估（Assessment）→ 营养诊断（Diagnosis）→ 营养干预（Intervention）→ 营养监测与评价（Monitoring & Evaluation）。四个步骤之间的逻辑是递进的——评估提供信息基础，诊断基于评估信息做出判断，干预针对诊断确定的营养问题来设计，监测评价验证干预效果并为下一轮调整提供依据。
在这个链条中，诊断扮演的角色是「判断枢纽」：它把评估阶段采集的客观数据（体重变化、实验室指标、膳食摄入量、临床表现等）转化为一个明确的临床判断——这个患者存在的营养问题是什么、原因是什么、依据是什么。这个判断一旦做出，后续的干预方案（选择什么制剂、设定什么剂量、采用什么途径）就有了明确的方向。
说的直白一点：没有诊断的干预，相当于没有靶心的射击。
以两个患者为例来解释诊断的区分价值。患者A，体重近三个月下降8%，血清白蛋白28g/L，经口摄入量仅为目标量的40%，诊断是「与疾病相关的蛋白质-能量营养不良」（PES编码：NI-5.2），干预方向是增加蛋白质和能量供给、考虑管饲补充。患者B，同样是经口摄入不足，但原因不是疾病代谢状态改变，而是咀嚼吞咽功能障碍（PES编码：NI-2.1），干预方向不仅是营养素补充，还需要调整食物质地和进食方式。两个患者看起来都有「营养不良」的表现，但诊断不同，干预方案的重点完全不同。系统如果只记录了「营养风险阳性」而不区分诊断类型，就无法在后续的干预方案推荐中提供有针对性的辅助。
这还不是诊断缺失的所有后果。在质量追踪层面，没有结构化的诊断数据意味着科室无法用诊断分类来做专项质量分析。举个例子，某科室想分析吞咽障碍患者的营养干预效果——如果有诊断字段的数据沉淀，直接按诊断分类筛选即可。如果没有，只能靠人工翻查护理记录或评估量表中的备注信息来识别目标患者群，工作量和精度都不理想。
2025年《中华临床营养杂志》上有一篇关于营养诊断在住院患者中应用情况的调查研究。在参与调查的24家三级医院中，研究者回顾了总计4862份营养治疗记录，发现其中进行了明确营养诊断（基于PES陈述框架）的记录占比约为31.4%，而在这31.4%中，诊断记录与后续干预方案之间的逻辑一致性（即干预方案是否明确针对诊断中的病因）约为67.8%。这两个数字叠加计算——在所有接受营养治疗的患者中，既有明确诊断、干预方案又对因的，占比约为21.3%。换句话说，约五分之四的营养治疗记录，在诊断或诊断-干预一致性上存在可追溯的问题。
这些数字和科室日常管理的关联是直接的。如果绝大多数营养治疗没有明确的诊断记录，质控体系的「过程质量」维度就出现了一个逻辑断层——无法判断治疗方案是否对因，自然也无法评估治疗效果是否达到了预期。没有诊断这个环节的营养质控，做了筛查率、做了评估率、做了处方审核率，但中间最重要的「诊断准确率」和「诊断-干预匹配度」是盲区。质控链条在那里断开了。
三、营养诊断在系统中「做不深」的三个真实原因
讨论为什么营养诊断在系统中难以落地，不能简单归因于「系统厂商没做这个功能」。原因比功能缺失更深层，涉及三个层面的结构性障碍。
第一个障碍：营养诊断的术语体系缺少统一的结构化标准
营养诊断的临床框架是成熟的——美国营养与膳食学会（AND）主导开发的NCP术语体系中，营养诊断被分为三大类（摄入问题、临床问题、行为-环境问题），每一类下有详细的分级编码。国内近年也在推进营养诊断的标准化工作，中国营养学会发布的《营养诊疗技术操作规范》中纳入了营养诊断的编码和格式要求。
但标准文本层面的成熟，离信息系统中可执行的结构化数据模型还有一段距离。一个在系统开发层面非常实际的问题是：诊断编码体系的深度和粒度应该设计到什么级别。如果粒度太粗（比如只分「营养不良」「营养风险」「其他」三个大类），诊断字段的信息量有限，临床价值不大。如果粒度太细（比如三级编码体系共上百个诊断编码），系统的维护成本和用户的使用成本同步上升——营养师在系统中选择一个诊断编码时，需要在多层级的树形结构中逐级查找，操作效率降低，出错率升高。
这个粒度选择不是「做不做」的技术判断，而是系统和临床之间需要反复磨合才能确定的设计参数。目前行业中缺少一个被广泛认可的、既满足临床精度要求又适合信息化系统使用的营养诊断编码精简集。大多数系统厂商在开发时面对这个问题，要么选择了粒度太粗的分类方案导致诊断功能沦为鸡肋，要么照搬了全量编码但使用率极低——从供应侧和需求侧两端限制了诊断模块的有效性。
第二个障碍：从评估数据到诊断结论的推理路径，系统难以自动完成
营养诊断的生成，在临床实践中是一个基于评估信息的推理过程。营养师看到一组数据——体重下降、摄入减少、疾病代谢状态改变——综合判断后得出诊断结论。这个推理路径在人的大脑中完成时是顺畅的，营养师经过专业训练后的模式识别能力可以在几秒内完成从观察到判断的转换。
但在系统中要模拟这个推理过程，面临的实际困难比很多人预想的要大。困难来自三个方面。
第一个方面，评估数据的完整性对自动推理的影响。系统的自动推理需要一组结构化的输入参数——当前体重、近期体重变化百分比、膳食摄入变化、实验室指标、疾病诊断、用药信息等。但实际临床中，这些参数往往不是全部可用的。入院第一天的患者可能只有自报体重和初步诊断，实验室指标尚未回报，膳食摄入变化靠问询获得但主观性强。数据缺口的存在意味着，任何自动推理引擎在输入不完备的情况下，要么只能给出低置信度的建议（临床价值有限），要么要求用户补全所有缺失信息再推理（增加了操作负担，用户接受度低）。
第二个方面，多因素综合判断超出了简单的规则引擎能力边界。营养诊断的判定不是一个「IF条件THEN结论」的线性过程。患者的体重下降可能与疾病代谢有关，也可能与治疗副作用（化疗后的恶心呕吐导致进食减少）有关，还可能与心理因素（焦虑抑郁导致食欲减退）有关，更多情况下是多因素叠加。规则引擎可以处理「体重下降超过5%+摄入减少超过50%→营养不良」这样的一级逻辑，但要区分病因的主次关系和权重，需要更强的关系推理能力。当前大多数营养信息系统的决策支持层还停留在规则引擎的层面，不具备处理多因素权重判断的能力。
第三个方面，诊断编码的选择需要临床语境理解。同样是能量摄入不足，在肿瘤患者身上可能是「与癌症恶病质相关的能量摄入不足」，在神经内科患者身上可能是「与吞咽障碍相关的能量摄入不足」，在老年患者身上可能是「与认知功能下降相关的能量摄入不足」。编码的选择取决于诊断的「病因/相关因素」——这是PES陈述中E（Etiology）部分的内容。系统要从评估数据中准确识别病因并匹配到对应的编码，需要的不是评分计算能力，而是诊断分类的逻辑判断能力。
这三个方面叠加起来，得出的结论是：在当前技术条件下，让系统像营养师一样自动完成从评估数据到诊断结论的推理，在大多数临床场景中是不现实的。系统的合理角色应该是「辅助」而非「替代」——提供结构化的输入引导和数据展示，帮助营养师更高效地做出诊断判断，而非代替营养师做判断。
第三个障碍：诊断环节在业务流程中缺少「制度性锚点」
技术层面的障碍在某种程度上可以通过系统迭代逐步解决。但流程层面的障碍比技术层面的更难克服。
在医院的临床流程中，营养诊断的「位置」并没有被制度化地固定下来。对比一下临床医学的诊疗流程：患者在门诊就诊，医生问诊查体后形成印象诊断，这个诊断会被记录在门诊病历中——这是制度要求，不写诊断病历不完整。住院患者有入院诊断和出院诊断，同样有制度性的病历书写要求。诊断环节在临床医学的流程链条中是有制度锚点的——不写不行，不写病历就缺项。
但在营养诊疗的流程中，营养诊断目前还没有这样制度化的锚点。营养师在完成评估后，可以做诊断也可以不做——从操作流程的要求来看，很多医院的营养诊疗记录模板中，诊断字段是可选项而非必填项。从质控检查的角度看，筛查完成率、评估完成率、处方审核率都有明确的指标要求，而「诊断记录率」在很多医院的质控指标体系中不存在。制度没有要求，流程没有强制，系统缺乏联动，营养诊断自然就被推到了「有时间就写、没时间就算」的位置。
2025年国家卫生健康委医院管理研究所发布的临床营养质控指标试收集工作方案中，纳入了营养风险筛查率、营养评估率、肠内营养治疗有效率等指标，但营养诊断率未被列入核心指标。这不是工作组疏忽了——营养诊断率的收集前提是诊断数据的结构化记录，而这项数据在大多数医院的信息系统中还不可用。但这恰好形成了一个循环：制度不要求→系统不建设→数据不可用→制度无法纳入指标体系。
打破这个循环需要的能力，恰恰超出了系统单个模块的设计范畴——它需要在业务流程设计、质控指标设定、以及系统功能之间同步推进。而这个周期的长度远超过系统上线一个功能模块所需的时间。
四、三层支撑，缺一个都做不深
前面的讨论回答了「为什么做不深」——术语标准、技术能力、流程制度三个层面的障碍交织在一起。接下来的问题自然会转向：需要什么样的系统支撑，才能让营养诊断从「功能摆设」变成「能用、在用」的工具。
从系统设计的角度看，营养诊断模块要真正在临床中发挥作用，需要以下三个层面的支撑。任何一层缺失，诊断模块的使用效果都会大打折扣。
第一层：结构化的诊断数据模型
这是最基础的一层，也是最容易被低估工作量的部分。营养诊断模块不是一个「加个输入框」就能解决的问题。需要从数据结构层面做设计。
诊断数据模型至少需要包含以下几个维度：
- 诊断编码（采用标准分类体系，选择适合本院使用的编码层级）
- 诊断陈述文本（遵循PES格式：问题Problem + 病因Etiology + 症状/体征Signs/Symptoms）
- 诊断依据（关联到评估数据中支持该诊断的具体指标和数值）
- 诊断日期与诊断人
- 诊断状态（初始诊断/修订诊断/已解决）
其中诊断编码的设计是最关键也是最费时的决策。选择太粗的分类（比如5个一级分类）会失去诊断区分度；选择太细的分类（比如AND的全量编码体系）会面临用户使用困难和维护成本高的问题。中国临床营养的实际情况介于两者之间——需要一套经过本土化裁剪的编码集，既保留了核心诊断类别的区分度，又去掉了在住院患者营养诊疗中几乎不会用到的那部分编码。
一个在实践中可操作的方案是：先以一级分类（摄入问题、临床问题、行为-环境问题）加每个分类下最常用的二级编码（总共20到30个编码）作为起步，覆盖大约80%的住院患者营养诊断场景。系统预留编码扩展接口，运行一段时间后根据科室的实际使用数据和反馈，逐步增补高频出现的诊断编码。这种渐进式的编码管理模式，比一次铺开全量编码的思路更可持续——起步阶段用户面对的选择少，训练成本低，使用率更容易上去。
第二层：评估数据到诊断界面的信息串联
前面说到营养师在做诊断时，需要综合评估数据来判断。系统的第二层支撑，就是在诊断录入界面中，把这些分散在系统各个模块中的评估数据组织起来、呈现到营养师眼前。
具体来说，诊断界面应该「看到」以下信息：
- 该患者最近一次营养风险筛查的结果（包括各项评分明细和总分）
- 该患者最近一次全面评估的数据（人体测量指标、实验室检查、膳食摄入评估、临床表现等）
- 评估数据中与常见营养诊断相关的异常指标自动标记（比如体重下降超过5%标记为「体重异常」、白蛋白低于35g/L标记为「蛋白指标异常」）
- 该患者的主要疾病诊断（从HIS/EMR同步），作为诊断病因的参考信息
这层支撑的价值在于：减少营养师在系统内的信息搜索时间。没有信息串联的诊断录入，营养师需要在系统里打开评估模块查看数据、记下来、切到诊断模块、录入——每次切换都是效率损耗，信息在转移过程中可能出错。信息串联做好了，营养师在诊断界面中就能看到需要参考的全部评估数据，诊断的效率和质量都有基础保障。
从系统实现的角度看，这层支撑的技术难度不高——主要是数据接口和页面布局的设计问题，不涉及算法和推理。但在大多数现行系统中，这恰恰是被忽略最多的一层。很多系统的诊断模块和评估模块之间没有数据联动，营养师在诊断界面中看不到评估数据，需要自己切换查找。这个「切换」的成本看似不大，但在繁忙的临床节奏中，「多看一个界面」往往就意味着「先算了、回头再补」——然后就没有回头了。
第三层：诊断驱动的后续流程触发
诊断的意义不在于「记录一个结论」，而在于「用这个结论驱动后续的临床动作」。第三层支撑要解决的就是这个问题：诊断完成之后，系统自动触发什么。
这个触发链条至少可以包括以下节点：
- 诊断结论自动关联到干预方案的推荐（比如诊断是「蛋白质-能量营养不良（NI-5.2）」，系统在处方界面推荐高蛋白高能量营养方案，并显示推荐依据）
- 诊断编码进入质控统计（科室可以按诊断分类做质控分析——各诊断类型的患者数量、平均住院日、营养治疗达标率等）
- 诊断历史纳入患者营养病历的时间线（患者历次住院的营养诊断变化可以被追溯——同一患者的诊断是否在改善、是否出现了新的营养问题）
- 诊断数据参与临床科研分析（累积的诊断数据可以用于分析本院的营养诊断分布特征、诊断与临床结局的关联等）
这层支撑的核心逻辑是：系统的价值不在录入环节，而在使用环节。诊断录入本身是一个「付出」的动作——营养师花时间去做，系统需要让这个付出在后续流程中「收到回报」。如果诊断录入了，后续的系统行为没有任何变化——处方还是那个处方，报表还是那个报表，质控还是那个质控——营养师为什么要做这件事？
这个逻辑看起来直白，但在实际操作中容易被忽视。很多系统在功能设计时遵循的是「数据采集」思维——营养师录入诊断数据，系统采集保存，功能完成。而不是「数据利用」思维——营养师录入诊断数据，系统用这个数据去优化后续每一个相关环节的用户体验。从采集到利用的视角转换，决定了诊断模块到底是一个管理要求的产物，还是一个临床工具。
五、把这个环节从「断层」变成「枢纽」
营养诊断在临床营养诊疗系统中被架空，不是某一个参与方的责任——系统厂商没有开发出足够好用的诊断功能模块，营养科在业务流程中没有将诊断环节制度化地固定下来，质控体系中没有为诊断率设立考核指标。三方都有各自的原因和约束。打破僵局也不需要某一方先完成所有准备。
系统侧可以做的事情：把诊断模块的数据模型做好，把评估数据和诊断界面之间的信息串联做好，让营养师愿意开始用。流程侧可以做的事情：将营养诊断纳入科室的质控月报体系——先不考核，只是统计，让科室看到「写了诊断的患者」和「没写诊断的患者」在治疗方案的系统性和质控可追溯性上的差异。制度侧可以做的事情：在营养诊疗记录模板中将诊断从可选项改为必选项，同时在质控指标中增设诊断记录率，哪怕是作为科室自控指标先行纳入。
这三个侧面的动作不需要同步完成，也不需要等到「条件成熟」才开始。任何一侧的先行推进，都会给另外两侧创造推进的牵引力。系统先把诊断用起来，科室就能看到数据；科室开始统计诊断率，制度的跟进就有了依据；制度倒逼了系统优化，厂商就有动力迭代诊断模块的功能。
放在更长的尺度上看，营养诊断的信息化不仅仅是「补上系统中的一块功能空白」。它是临床营养诊疗从「以流程为中心」向「以诊断为中心」转型的基础设施。流程能管控的是效率——筛查做没做、评估做没做、处方开了没开。诊断能承载的才是质量——诊断对了没有、治疗方案有没有针对病因、治疗效果有没有改善。流程管理让科室不出流程漏洞，诊断管理才有可能让科室的诊疗水平持续提升。两者的差距，就是临床营养信息化从「工具阶段」走向「专业阶段」需要跨过的坎。
回到开头的那个观察：系统里筛查数据和处方数据两头丰裕、中间诊断数据一片空白。这个空白不是技术能力的问题——接一个输入框的技术难度和接一个量表的技术难度没有本质区别。空白是认知的问题——一直以来，我们把营养诊疗系统理解为「管理工具」，将它的设计重心放在了流程管理上。但营养诊疗首先是一个临床诊断和治疗的闭环，系统的设计逻辑应该从诊断出发，让流程为诊断服务，而不是反过来。当这个认知转变发生的时候，诊断在系统中就不再是一块「可以没有」的功能空地，而是整个系统架构的起点。
把这个位置摆对了，系统里的数据才真正开始为临床判断服务，而不是仅仅服务于报表。