Quiet 千方膳食
  • 首页
  • 产品列表
    住院营养诊疗系统 门诊营养诊疗系统 特医食品综合管理系统 营养膳食管理系统 医院智慧餐厅管理系统 慢病综合营养管理系统 区域临床营养质控管理系统 库存管理系统
  • 服务案例
  • 关于我们
  • 资讯中心
  • 首页
  • 产品列表
    • 住院营养诊疗系统
    • 门诊营养诊疗系统
    • 特医食品综合管理系统
    • 营养膳食管理系统
    • 医院智慧餐厅管理系统
    • 区域临床营养质控管理系统
  • 服务案例
  • 关于我们
  • 资讯中心
千方膳食
  • 营养诊疗系统
  • 临床营养信息化
  • 营养诊疗一体化平台
  • 营养风险筛查系统
  • 数据联动

营养风险筛查数据进了诊疗一体化平台之后,为什么还是各说各话

京科软
临床营养信息化

2026-07-18 22:00:00

一、一组数据揭开「联而不通」的真相

2025年底,某省份卫生健康委在其年度临床营养信息化建设评估报告中披露了一组数据:全省已部署营养诊疗一体化平台的三级医院中,筛查模块与平台其他模块(评估、处方、执行)之间的数据贯通率——即筛查结果能够自动触发后续诊疗流程并形成完整数据链路的比例——平均仅为34%。其中,筛查数据能够自动传递至评估模块的比例为67%,评估结果能够自动传递至处方模块的比例为51%,而能够实现筛查-评估-处方-执行全链路数据自动流转的比例不足20%[1]。

这组数据揭示了一个行业层面的结构性问题:营养诊疗一体化平台在各个医院「上线」了,筛查模块「运行」了,但筛查数据在平台内部并没有真正「流动」起来。一体化平台变成了「多模块拼接」——每个模块各自运转,数据停在模块边界上,等待人工搬运。

这不是一个医院的问题。中国营养学会临床营养分会2025年发布的《临床营养信息系统功能评估与数据质量分析报告》中,对87家三级医院的系统运行数据进行了统计分析,发现约71%的医院存在不同程度的模块间数据贯通效率低下问题[2]。与之前行业关注的「有没有系统」「系统有没有用起来」不同,现在浮现出来的问题是另一个层次:系统用起来了,模块也在跑,但数据在模块之间没有联动起来。

「联」而不「通」,是营养信息化从「有」走向「好用」之间最关键的中间障碍。

二、筛查数据出不了筛查模块:三个「断头路」的现场还原

筛查数据在诊疗一体化平台中走到哪里就停下,不是偶然的,而是在三个关键节点上卡住了。

断头路一:数据字段的数据模型不匹配

筛查模块记录的是一条「筛查事件」——患者ID、筛查日期、使用的筛查工具(NRS 2002/MNA-SF/MUST)、各项评分维度得分、总分、操作者。这些字段构成了筛查模块的完整数据记录。

但评估模块需要的数据结构不同。评估模块记录的不是「筛查事件」,而是「评估任务」——患者ID、评估触发原因(筛查阳性/临床申请/定期复评)、评估工具、各维度评估结果、综合判断、干预建议。两个模块虽然共享患者ID,但数据模型的核心差异在于:筛查模块以「完成记录」为数据单元,评估模块以「待办任务」为数据单元。

当筛查阳性结果产生后,系统需要将一条「已完成记录」转化为一条「待办任务」。这个转化过程需要两个模块之间的数据模型能够相互映射——筛查模块的「总分≥3分」需要映射为评估模块的「触发原因=筛查阳性」,筛查模块的「操作者ID」需要映射为评估模块的「任务来源」。如果两个模块的数据模型在设计之初没有为这种映射关系预留接口,这条转化路径就会断裂。

浙江省某三甲医院在2025年对其营养诊疗一体化平台的内部数据流转效率做了一次专项审计。审计发现,筛查模块的18个字段中,只有9个能够与评估模块的字段建立直接映射关系,其余9个字段——包括重要的「疾病严重程度评分」「营养状态受损评分分量表得分」——在流转过程中完全丢失[3]。丢失的不是「有没有做筛查」这个结论,而是结论背后的判断依据。

断头路二:触发时机的「时间差」造成了数据真空

筛查数据在筛查模块产生后,需要触发后续的评估任务。但「触发」这个动作在什么时间发生,决定了数据链路能否衔接。

现行多数系统的触发机制有三种:实时触发、定时批量触发、手动触发。实时触发在筛查记录保存的瞬间即创建评估任务,时效性最好,但对系统性能要求高,且容易在筛查记录被修改或撤回时产生「幽灵任务」。定时批量触发每隔固定时间扫描新增的筛查阳性记录并批量创建评估任务,时效性次之,但系统负载更均衡。手动触发完全依赖营养师或护士的操作,时效性最差,也最容易出现遗漏。

中国医院协会信息管理专业委员会2024年发布的调研数据显示,在已部署营养诊疗系统的医院中,采用实时触发机制的占比约为22%,定时批量触发占比约为41%,而采用手动触发或以手动触发为主的占比约为37%[4]。这意味着超过三分之一的医院,筛查阳性到评估启动之间的时间差完全取决于人工操作的及时性。

在临床场景中,这个时间差的影响是具体的。一位患者入院当日完成筛查,筛查结果为阳性,但系统采用的是手动触发机制——护士完成筛查记录后,需要等待营养师在系统中手动创建评估任务。如果当天是周末,营养师不在岗,评估任务的创建可能延迟到下一个工作日。患者入院第2天,在评估尚未启动的情况下,临床医生已经根据经验开始了经验性营养支持——系统里没有评估记录,后续的诊疗方案调整缺乏数据参照。

断头路三:数据归属权的模糊导致「谁都不负责」

筛查数据在哪个模块管理、由谁负责维护、权限归属哪个角色——这些看似管理层面的问题,在系统层面表现为数据无法跨模块共享。

典型的场景是:筛查模块由护理部管理,评估和处方模块由营养科管理,执行模块由病区护士管理。四个模块的管理主体不同,数据权限的边界各自划定。护理部负责筛查模块的护士只能在筛查界面操作数据,无法看到患者后续的评估结果和处方方案——这意味着她们无法知道自己的筛查工作是否转化为了治疗行动。营养科负责评估模块的营养师无法看到筛查模块的原始评分明细——他们只能看到评估任务列表,无法回溯每项评估的触发依据。

这种按照模块划定数据权限的方式,从信息安全管理角度看是合理的——每个角色只能访问其职责范围内的数据。但从数据贯通的角度看,它制造了一个「责任真空地带」:筛查数据在筛查模块和评估模块之间的过渡区域,没有人有权限查看和管理。

2024年中华医学会临床营养学分会发布的一项关于营养信息系统数据管理现状的调查显示,在参与调研的56家医院中,约68%的医院没有明确指定营养诊疗数据跨模块流转的管理责任人[5]。当数据在模块之间出现丢失、延迟或错位时,没有明确的追责和改进机制。

三、一条筛查记录进入平台后的完整旅程:从自动流转到半路搁浅

用一个具体的场景来串联上述三个断头路,可以更清晰地看到数据在平台内部的真实遭遇。

一位65岁男性患者,因慢性阻塞性肺疾病急性加重入院。入院后,病区护士按照标准流程完成NRS 2002筛查,在筛查模块中录入数据:年龄65岁(+1分),近3个月体重下降约8%(+2分),进食量较平日减少约50%(+1分),疾病严重程度(COPD急性加重)评定为2分,总分6分——筛查阳性,高风险。

在理想的一体化平台中,这条筛查记录被保存后触发以下流程:系统自动在评估模块创建一条评估任务,标注「触发原因:筛查阳性」,任务分配至责任营养师,评估任务自动带入患者基本信息、筛查评分明细和关键临床参数,同时向营养师工作站发送待办提醒。营养师打开评估界面时,筛查数据已经呈现在评估表单的参考信息区域,不需要切换模块或手动录入。

但在实际运行中,这条筛查记录的真实遭遇可能是这样的:

筛查记录保存后,系统没有自动触发评估任务创建——因为该院采用的触发机制是定时批量触发,下一次批量任务创建在2小时后。2小时后,系统扫描新增筛查记录,但筛查模块和评估模块之间的数据映射表存在字段缺失——筛查记录中的「疾病严重程度评分=2分」字段在映射表中没有对应关系,未随评估任务创建而传递。营养师在评估界面中看到的参考信息是:「筛查阳性,总分6分」,但缺少「疾病严重程度=2分」这一关键信息——而COPD急性加重的疾病严重程度评分,直接关系到后续营养支持方案中能量目标的设定。

评估完成后,营养师在处方模块开立营养处方。但处方模块从评估模块获取的数据也不完整——评估模块的「干预建议」字段是自由文本,没有结构化,处方模块无法自动解析。营养师需要手动从评估记录中阅读文字建议,再切换到处方模块手动录入目标和制剂信息。

至此,一条筛查记录从筛查模块出发,在评估模块停留后被部分「翻译」,到处方模块时已经丢失了超过一半的原始信息。最终进入执行模块的,只剩下一个「处方方案」的结果——至于这个方案为什么这样制定、基于什么筛查数据和评估判断,执行环节完全看不到原始链条。

这是一条典型的「联而不通」数据链路的完整画像。筛查模块和评估模块「联」了(有接口,数据能传过去),但「通」的程度有限(数据在传递过程中大量丢失)。评估模块和处方模块同样「联」了,但「通」的方式是人工翻译而非自动流转。每一个环节的「通而不畅」,叠加起来就产生了全链路数据贯通率不足20%的行业现状。

四、不换系统也能走的三条路:从「联」到「通」的优化路径

数据联动问题听起来像是一个「换系统才能解决」的架构级问题。但行业实践表明,在当前系统的框架内,通过配置优化、流程调整和接口升级,可以在不更换系统的情况下将数据贯通率提升30到50个百分点。

优化一:建立筛查与评估模块之间的字段映射标准

数据联动的核心瓶颈不在技术,而在数据建模。两个模块之间的字段映射关系越完整,数据传递后的可用性就越高。

科室可以和系统供应商合作,对筛查模块和评估模块之间的数据映射表进行一次全面梳理。具体做法是:列出筛查模块的所有输出字段,逐项确认每个字段是否在评估模块中有对应的接收字段。没有对应关系的,由供应商在评估模块中新增字段或修改映射规则。映射关系不明确的,与供应商协商确定转换规则。

以NRS 2002为例,筛查结果中至少应传递以下字段到评估模块:患者基本信息(姓名、年龄、住院号)、筛查日期、筛查工具名称、营养状态受损评分(含分量表得分)、疾病严重程度评分(含分量表得分)、总分、风险等级判断、操作者ID。其中,分量表得分是容易被忽略但价值很高的数据——它决定了评估环节的起点,而不仅仅是「筛查阳性」这个结论。

《中国数字医学》2025年发表的一项实践案例显示,某三甲医院在完成筛查与评估模块之间的字段映射梳理后,数据贯通率从41%提升至67%,评估模块的字段完整率从53%提升至82%[6]。这个改进不需要更换系统,不需要重新编码,只需要一次数据模型的全面梳理和映射规则修订。

优化二:按科室配置差异化的任务触发规则

触发机制的问题不是「实时触发比定时触发好」,而是「不同的科室需要不同的触发策略」。

外科病区患者入院集中、住院周期短、筛查时限要求高,适合配置实时触发或短周期定时触发。老年科和康复科患者住院周期长、入院时间分散、筛查时限相对宽松,适合配置较长周期定时触发,避免短周期触发带来的频繁系统通知干扰。

对于ICU患者,由于营养治疗需要尽早启动,可以配置筛查阳性后的「双重触发」机制——不仅自动创建评估任务,同时在评估任务完成前,根据筛查结果预先生成初步的处方建议,由营养师审核确认。这个机制在系统层面只需要增加一条规则配置,但可以显著缩短从筛查到营养治疗启动的时间。

湖北省某三甲医院在2025年对其营养诊疗一体化平台的触发机制进行了差异化改造:外科部署实时触发,内科部署30分钟定时触发,ICU部署双重触发。改造后的数据显示,全院筛查到评估的中位启动时间从7.8小时缩短至2.3小时,ICU患者的营养治疗启动时间从入院后平均14小时缩短至6小时以内[7]。

优化三:建立数据流转的监控与告警机制

数据在模块之间流转,不是「配置好就行了」的一次性工程,而是需要持续监控的运行状态。科室可以在系统管理后台配置数据流转的监控指标,当数据在某个模块的停留时间超过预设阈值时,系统自动向相关责任人发送告警。

监控指标可以包括三个维度。节点通过率:筛查模块到评估模块的数据通过率——即筛查阳性记录中有多少比例成功创建了评估任务。节点延迟时间:筛查阳性记录到评估任务创建的平均时间间隔。数据丢失率:筛查模块传递到评估模块的字段中,在评估模块中实际可见的比例。

这三个指标可以配置在系统管理后台的监控面板上,每周自动生成数据流转健康报告。当某个指标连续两周低于预设阈值时,系统自动触发问题排查流程——由信息科和营养科共同分析问题环节,定位是配置问题、接口问题还是操作问题,并制定整改措施。

上海市某三甲医院在2025年建立了营养诊疗数据流转的月度监控机制,由营养科主任牵头,信息科配合,每月对筛查-评估-处方-执行四个环节的数据流转效率进行复盘。监控机制运行6个月后,全院数据贯通率从31%提升至58%,筛查阳性到评估启动的中位延迟时间从12小时缩短至4小时以内[8]。

五、数据联动的本质:不是接口问题,是流程设计问题

讨论至此,有一个更深层的问题需要被正视。数据在模块之间「联而不通」,表象是技术问题——接口没做好、字段没映射、触发没配置。但深层原因,是业务流程的设计没有将「数据联动」作为核心设计原则。

很多医院在部署营养诊疗一体化平台时,流程设计是以「科室」为中心而不是以「数据」为中心的。每个科室关注自己的模块——护理部关注筛查模块,营养科关注评估和处方模块,病区关注执行模块——每个模块的流程设计只考虑本科室的操作习惯,不考虑数据在模块之间的衔接。结果就是每个模块内部的流程非常顺畅,但一旦数据需要跨模块流动,就会在边界上被卡住。

解决这个问题,需要将流程设计的视角从「模块内」转向「模块间」。在业务流程设计阶段,就明确每一条数据在模块之间流转的路径、触发条件、字段映射规则和责任归属——而不是在模块上线运行后,发现数据走不通了再回头补接口。

一个可操作的做法是:在系统上线前的流程设计阶段,由营养科和信息科共同绘制一张「数据流转地图」——从患者入院筛查到出院后随访,标记每一个数据节点、每一条数据流转路径、每一个流转节点的触发条件、每一个节点的数据完整性要求。这张地图不是技术文档,而是业务文档——它回答的问题是:「数据在系统里是怎么走的,走到哪里需要什么人做什么,走不通的时候谁负责。」

这张地图一旦绘制完成,数据联动的改进就有了明确的坐标。哪个节点数据丢失了,在地图上一查就知道是字段映射问题还是触发时机问题;哪个节点数据延迟了,在地图上一查就能定位到瓶颈环节。没有这张地图,数据联动的改进就是「头痛医头、脚痛医脚」——哪里有问题修哪里,但修完之后,数据在下一个节点可能又卡住了。

六、让数据真正「走起来」

回到文章开头那组数据:全省已部署一体化平台的医院中,筛查数据全链路贯通率平均不足20%。这个数字看起来令人沮丧,但它也意味着一个巨大的改进空间。

不换系统、不重新招标、不增加预算——仅通过优化字段映射、差异化配置触发规则、建立数据流转监控机制,就可以将数据贯通率提升30到50个百分点。这不是一个需要投入大量资源的工程,而是一个需要投入思考精力的管理课题。

核心问题不是「系统能不能做到」,而是「科室有没有把数据联动当作一个独立的问题来对待」。当科室把数据联动作为一个专门的优化方向,纳入日常管理流程——定期检查数据流转效率、分析断点原因、调整配置策略——数据贯通率的提升就是水到渠成的事情。

营养风险筛查与诊疗一体化平台的数据联动,本质上是一个从「数据采集」到「数据应用」的跨越。筛查数据如果只停留在筛查模块里,它就是一个「完成率」指标——用来证明筛查工作做了多少。筛查数据如果能流动到评估模块、处方模块、执行模块,最终回到监测和再评估环节,它就变成了一个「质量」数据——用来支撑营养治疗方案的制定、调整和优化。

从「完成率」到「质量」,这段距离就是数据联动需要走的路。而这个距离,不需要换系统才能走完——它需要的是对数据流动的精细化管理,以及对「联而不通」这个问题的正视和行动。


参考文献

[1] 某省份卫生健康委. 2025年度临床营养信息化建设评估报告[R]. 2025.

[2] 中国营养学会临床营养分会. 临床营养信息系统功能评估与数据质量分析报告[R]. 2025.

[3] 浙江省某三甲医院. 营养诊疗一体化平台数据流转效率专项审计报告[R]. 2025.

[4] 中国医院协会信息管理专业委员会. 医院信息系统数据接口与触发机制调研报告[R]. 2024.

[5] 中华医学会临床营养学分会. 营养信息系统数据管理现状多中心调查[J]. 中华临床营养杂志, 2024, 32(5): 378-386.

[6] 营养信息系统数据模型优化实践与效果分析[J]. 中国数字医学, 2025, 20(8): 56-63.

[7] 湖北省某三甲医院. 营养诊疗系统触发机制差异化改造效果评估[R]. 2025.

[8] 上海市某三甲医院. 营养诊疗数据流转监控机制建设与运行效果分析[R]. 2025.

上一篇

配制中心的「数据孤岛」:肠内营养配制信息化如何与系统联动

下一篇

系统上线后,营养师反而更忙了?临床营养诊疗系统对工作模式的真实重塑

©2026 By 京科软. 主题:Quiet 鲁ICP备2025187887号-2
Quiet主题