政策文件里写的是「一体化」，但落地时往往是「各管各的」
2025年以来，国家卫健委在多个政策文件中反复强调医疗机构信息化建设的「一体化」方向——数据互通、业务协同、流程闭环。营养科信息化也不例外。营养风险筛查系统、临床营养诊疗系统、营养评估与干预系统、营养处方管理系统……在政策文件里，它们应当是一套整体能力；但在实际落地中，很多医院的情况是：筛查系统管筛查，诊疗系统管诊疗，两套系统「各说各话」。[2]
这不是一个「选型失误」的问题，甚至不完全是技术问题，而是一个系统架构和业务设计的问题。
营养风险筛查系统解决的是「有没有风险」——患者入院后，护士或营养师在系统里完成筛查量表的填写，系统给出阳性/阴性判断。临床营养诊疗系统解决的是「有风险之后怎么办」——评估、诊断、干预、监测、随访，全流程在诊疗系统里跑。两套系统各有各的数据库、各有各的操作界面、各有各的使用人群。筛查系统的高频使用者是护士，诊疗系统的高频使用者是营养师。当两套系统没有在数据层面「对齐」时，筛查阳性这个最重要的信号，就需要人工告知、人工传递、人工录入到诊疗系统里。
人工传递意味着什么？意味着延迟、遗漏、错位。2025年中华医学会肠外肠内营养学分会发布的一份临床营养质控报告中提到，在已实现信息化管理的医院中，营养风险筛查阳性到首次营养评估的启动时间，平均间隔仍超过24小时，其中「系统间数据传递依赖人工」是主要原因之一。[1] 这个数字说明，筛查系统做完了该做的，但它的「产出」没有顺畅地进入诊疗系统。
本文从系统架构设计的角度，拆解「两张皮」为什么长成了两张皮，以及从数据层、业务层到决策层，怎么把它们变成一张网。
数据层：筛查结果「可消费」是融合的起点
两套系统融合的第一步，也是最基础的一步，是数据层打通。但「打通」这个词太笼统，实际需要回答三个具体问题：筛查数据以什么格式进入诊疗系统？进入后存在哪里？进入后怎么保持更新？
筛查结果的数据结构标准化
营养风险筛查的结果，不是一个简单的「阳性/阴性」标签。在完整的筛查数据模型中，至少包含以下信息：患者基本信息（住院号、年龄、科室、病区）、筛查工具名称（NRS 2002、MNA-SF、NUTRIC Score等）、各维度得分（子项得分）、总分、阳性/阴性判定、筛查日期、操作人。这些信息，如果以「半结构化文本」的形式从筛查系统传到诊疗系统——比如在系统里写一段「患者NRS 2002得分4分，阳性」——诊疗系统就无法对筛查结果做结构化处理，无法自动触发后续的评估任务。
结构化输出的标准做法是：筛查系统在产生结果时，以标准化的数据结构输出。具体来说，至少包含患者ID、筛查工具编码、各子项得分、总分、判定结果、筛查时间戳、操作人ID。这些字段可以参照HL7 FHIR标准中的NutritionAssessment资源模型来组织，写入中间数据层。诊疗系统从中间层读取筛查结果数据时，不需要再做二次解析，可以直接使用。[3] 这一步做与不做，决定了筛查结果在诊疗系统里是「可计算的数据」还是「可阅读的文本」。
筛查结果的状态管理
筛查结果不是一成不变的。患者住院期间，可能因为病情变化需要重新筛查——比如术后患者从ICU转到普通病房、或者营养状况在短期内显著恶化。每次重新筛查，都会产生新的筛查结果。诊疗系统需要有能力管理筛查结果的「版本」——最新一次筛查结果是什么、历史筛查结果是什么、两次筛查之间的变化趋势是什么。
如果数据层没有做好状态管理，诊疗系统拿到的永远是「最新一次筛查结果」，丢失了时间序列信息。营养评估时看到的，就只是一个静态的「阳性/阴性」，而不是患者营养风险在住院周期内的动态变化。对于长期住院患者、多次入院的慢性病患者，这种时间序列数据的价值尤其明显——它能帮助营养师判断患者的营养状况是在改善还是在恶化，而不仅仅是「当前有没有风险」。
筛查数据与诊疗数据的同源管理
数据层融合的另一个关键，是「同源」——即筛查系统和诊疗系统里，同一个患者的基础信息来自同一个主数据源。如果两套系统各自维护一套患者信息表，当患者转科、出院、再入院时，两套系统里的患者信息就可能不一致。筛查结果传过去，诊疗系统找不到对应的患者，或者找到了但信息对不上，数据就「断」在了半路。
同源管理，技术上依赖患者主索引（EMPI）或统一患者ID。在科室层面，营养科的信息系统需要与医院HIS共用患者主索引，确保筛查系统和诊疗系统引用的是同一个患者实体。这一步看起来是基础设施问题，但恰恰是很多医院融合推进缓慢的根因——不是因为技术做不到，而是因为患者主索引的维护涉及多个科室的协调。
业务层：从「筛查阳性」到「评估启动」的自动化衔接
数据层打通之后，第二个层面是业务层的融合。数据层解决的是「数据能不能过去」，业务层解决的是「数据过去了，然后呢」。
筛查阳性触发评估任务
营养风险筛查阳性的核心业务价值，是「启动下一步」。筛查阳性之后，系统应该做什么？在「两张皮」的模式下，答案是「等着营养师自己去查筛查结果，然后手动开评估」。在「一张网」的模式下，答案应该是「系统自动生成评估任务，分配给对应科室的营养师」。
这个自动触发的流程，逻辑上并不复杂：筛查系统输出阳性结果，诊疗系统收到后，根据患者所在科室、病区，自动生成一条「待评估」任务，分配给负责该病区的营养师。营养师登录系统时，能直接看到「待评估列表」，点击即可进入该患者的营养评估界面，而评估界面上已经预填了筛查结果的相关信息。从「人工翻查」到「系统推送」，这个转变是业务层融合最直观的体现。
评估任务的分级和排队
一个现实的问题是：筛查阳性患者不是均匀分布的。某一天可能同时出现十几个筛查阳性患者，而科室的营养师人力有限。所有阳性患者都立刻触发评估任务，营养师的工作队列会瞬间爆满。
业务层需要支持「分级排队」机制。筛查阳性本身也有严重程度差异——NRS 2002得分3分的患者和得分6分的患者，优先级的权重不同。系统可以根据筛查得分的严重程度，结合患者的基础疾病、年龄、科室等因素，对评估任务做自动排序，把最紧急的排在前面。营养师按照系统推荐的优先级开展工作，而不是按时间顺序「先到先处理」。这种分级排队机制，本质上是将有限的营养师人力资源优先配置给最需要干预的患者，而不是让所有阳性患者在同一个队列里「公平等待」。
评估结果回流到筛查系统
业务层融合不是单向的——筛查结果进了诊疗系统，评估结果也应该回流到筛查系统。评估确认了营养不良程度、明确了具体问题，这些信息对筛查系统的「回顾性校准」有参考价值。比如，筛查阳性但评估确认没有营养不良的病例，可以用于分析筛查工具的假阳性率，帮助科室优化筛查流程或调整筛查工具的选择。
双向回流的意义在于：两套系统不再是「单向管道」，而是形成了一个业务闭环。筛查系统不仅输出信号，还能接收到诊疗系统的反馈，用于自身质量的持续改进。这种闭环设计，是「一张网」区别于「两张皮」的本质特征。
决策层：当两个系统开始「协商」而不是「通知」
数据层和业务层融合之后，更高级的融合是决策层融合。在这个层面，筛查系统和诊疗系统不再是「一个通知、一个接收」的关系，而是开始协同——筛查数据成为诊疗决策的输入，诊疗反馈成为筛查质量改进的驱动。
筛查数据驱动的诊疗决策支持
当筛查结果以结构化数据进入诊疗系统后，诊疗系统可以基于筛查数据做更精准的决策支持。举个例子：一个NRS 2002得分较高的患者，同时年龄偏大、合并糖尿病，诊疗系统在开立营养处方时，可以根据筛查数据中的风险因子，自动推荐「初始喂养速度偏低、需加强血糖监测」的方案模板。这个推荐不是基于泛化的经验规则，而是基于筛查数据中结构化的风险因子与诊疗方案的匹配逻辑。
另一个应用场景是：筛查结果中的体重下降幅度、摄入减少程度等量化指标，可以直接作为营养处方初始剂量的计算参数。一个重度营养不良的筛查阳性患者和一个轻度风险的筛查阳性患者，在处方初始能量目标上应当有显著差异。筛查数据进入诊疗系统后，这种差异可以自动体现在处方推荐中，而不是依赖营养师手动回忆筛查结果。
诊疗反馈驱动的筛查质量改进
反过来，诊疗系统的使用数据也可以反馈给筛查系统，用于筛查质量的持续改进。比如，诊疗系统记录到某科室的筛查阳性率显著低于其他科室，但该科室营养不良患者的检出率并不低——这可能意味着筛查执行的一致性出了问题。诊疗系统可以把这些异常模式反馈给筛查系统，触发筛查质量的自检。
更具体地说，诊疗系统可以定期分析「筛查阳性但评估确认无营养不良」和「筛查阴性但评估确认有营养不良」这两类病例的分布特征。前者反映筛查的假阳性问题，后者反映筛查的假阴性问题。通过对这些病例的科室分布、筛查工具类型、操作人特征做聚类分析，可以定位筛查执行中的薄弱环节——是某个科室的筛查培训没到位，是某种筛查工具不适用于特定人群，还是某个操作人频繁出现误判。这些分析结果，驱动的是筛查流程的持续优化，而不是一次性的「整改」。
两张报表合并为一张驾驶舱
在管理层面，两套系统融合后，科室主任看到的报表应该从「筛查报表+诊疗报表」两张，变成「营养诊疗全流程驾驶舱」一张。从筛查覆盖率、阳性率、评估响应时间、干预覆盖率、治疗达标率到随访完成率，所有指标串联在一张看板上。筛查阶段的「漏」和诊疗阶段的「断」，不再需要人工关联分析，系统自动把全流程的断点标记出来。
一张驾驶舱和一个数据看板的区别在于：看板展示的是「每个环节各自怎么样」，驾驶舱回答的是「全流程整体怎么样」。当筛查覆盖率正常但评估响应时间偏长，问题出在业务衔接层；当评估响应时间正常但干预覆盖率偏低，问题出在评估到干预的转换层。驾驶舱能把这些跨环节的关联问题暴露出来，让管理决策有据可依，而不是靠科室主任凭经验猜测瓶颈在哪。
融合的节奏：不是一步到位，是分阶段渐进
「两张皮」变「一张网」，不是靠一次系统升级就能完成的。从实际案例看，实现真正意义上的融合，通常需要经历三个阶段。
第一阶段：数据层对接（1-2个月）
这个阶段的目标是「数据能过去」。筛查系统的结构化数据能够写入中间层，诊疗系统能够从中间层读取筛查结果。这个阶段的核心产出是「筛查阳性患者不再需要人工通知」。在数据层对接之前，每个筛查阳性患者需要营养师手动翻查筛查记录，再到诊疗系统里人工录入，耗时从数十分钟到数小时不等。数据层对接完成后，这个时间压缩到接近零。评估周期从「24小时起步」压缩到「数小时内启动」。
第二阶段：业务联动（2-4个月）
数据层跑通之后，进入业务层联动。筛查阳性自动触发评估任务，评估任务分级排队，评估结果回流筛查系统。这个阶段的核心产出是「营养师的工作列表不再需要手动整理」。业务联动带来的变化不仅是效率提升，还有工作模式的转变——营养师从「主动查询筛查结果」变成「系统推送待办事项」，从「自己判断优先级」变成「系统按风险排序」。
第三阶段：决策协同（4-6个月）
最后进入决策层协同。筛查数据驱动的决策支持、诊疗反馈驱动的筛查质量改进、合并驾驶舱看板上线。这个阶段的核心产出是「科室主任不再需要从两张报表里拼凑全貌」。决策协同阶段的价值，在于把两套系统从「数据互通」提升到「能力互补」——筛查系统借助诊疗数据不断校准自身准确性，诊疗系统借助筛查数据做出更精准的决策建议。
每个阶段之间，需要留出足够的时间让科室适应新的工作流程。技术层面的融合可以很快，但业务层面的融合需要和科室的日常运转节奏匹配。强行压缩时间窗口，可能导致系统改了但没人用，反而比不改更糟。
收尾：两张皮不是谁的问题，但「变一张网」是系统的责任
回到开头那句话。政策文件要求「一体化」，但落地时总是「各管各的」——这不是营养科的问题，也不是信息科的问题，而是系统架构在设计之初就没有把「筛查」和「诊疗」当成一个整体来规划。筛查系统采购的是筛查系统，诊疗系统采购的是诊疗系统，两套系统各自独立招标、独立部署、独立验收，最后在科室里「相遇」时，才发现它们之间没有对话能力。
但问题的解决方案，不是「换一套系统」，也不是「指责谁没做好」。在现有架构上，通过数据层标准化、业务层联动、决策层协同这三个层面的渐进式融合，完全可以把两张皮变成一张网。筛查系统不再只是「打分工具」，诊疗系统不再只是「做方案的工具」，它们合在一起，才是一套完整的营养诊疗能力。
最后留一个思考：当科室里下一批筛查阳性数据出来的时候，营养师打开系统，是看到一个「需要手动翻查」的筛查结果列表，还是看到一个「已经排好优先级、等着确认」的待办列表？这个问题的答案，就是两张皮到一张网的距离。
[1] 中华医学会肠外肠内营养学分会. 2025年中国临床营养质控报告. 临床营养质控中心, 2025.
[2] 国家卫生健康委员会. 医院信息化建设标准与规范（2025年版）.
[3] HL7 International. FHIR Release 4: NutritionAssessment Resource. 2023.