从五套系统到一体化平台：临床营养信息系统集成正在经历什么

一组数据的两个面孔

2025年，某省级三甲医院信息科做了一次全院业务系统盘点。结果让人意外：与营养诊疗相关的信息系统，该院同时运行着五套——营养风险筛查模块嵌在护理系统中、肠内营养管理用着一套独立的医嘱系统、肠外营养配置在静脉药物集中调配中心（PIVAS）的系统里完成、营养评估数据记录在营养科自建的一套Access数据库中、出院随访则依靠另一套第三方随访平台。

五套系统，五个数据库，五种数据格式。同一个患者的营养诊疗信息，分散在五个互不相通的系统里。

这不是孤例。中国医院协会信息管理专业委员会（CHIMA）2024年发布的医院信息化现状调查显示，在参与调研的137家三级医院中，超过六成的医院在营养诊疗相关业务上运行着三套或以上的独立信息系统。其中，营养风险筛查模块嵌入护理信息系统是最常见的部署方式，占比约54%；肠内肠外营养管理通过独立系统或模块完成的约占41%；营养评估与处方的信息化管理则分布在电子病历系统、专科系统或自建工具中，部署方式最为分散。

问题的另一面是：同一年，国家卫生健康委发布的《医院信息互联互通标准化成熟度测评方案（2025年版）》将临床营养纳入互联互通测评的必选业务域之一，明确要求营养诊疗数据在院内各系统之间实现语义级互操作。测评标准从”数据可交换”升级为”数据可理解”，对集成深度提出了质的跨越。

一面是多系统分立的现实，一面是互联互通标准加码的趋势。营养诊疗的信息化集成，从来没有像今天这样紧迫。

一、「集成」不是「对接」：被低估的复杂度

医院信息化建设中，”对接”和”集成”是两个经常被混用的词。但在临床营养这个特定领域，二者的区别直接决定了建设路径的选择和最终效果的差异。

对接，是让两个系统之间能传数据。 营养风险筛查系统把筛查结果传给电子病历系统，营养处方系统把医嘱传给HIS——这是对接。对接解决的问题是”数据通路有没有”。

集成，是让多个系统共同服务于一个诊疗流程，数据在其中无缝流转、语义一致、状态协同。 一条典型的营养诊疗流程可能跨越多个系统：护士在护理系统中完成筛查→筛查结果触发评估任务→营养师在营养系统中完成评估→评估结论推送到处方模块→处方经审核后传至HIS执行→执行结果回传→随访系统自动创建随访计划。流程中涉及四到六个系统，每个节点都有状态转换、数据回写和异常处理。

对接和集成之间，是”能传数据”和”能跑流程”的差距。

中国医院协会信息管理专业委员会的一份技术白皮书中提到一个值得注意的数据：在已实现营养筛查数据与HIS对接的医院中，约73%仅完成了单向数据传输——筛查结果写入HIS的指定字段，但HIS中患者的诊断、用药、检验数据无法反向为营养系统所用。数据通路是通的，但数据价值停留在单向上。这不是集成，只是”对了个接”。

把”对接”当作”集成”来规划和预算，是当前临床营养信息化建设中成本最高的认知偏差。对接项目通常以接口数量计价，一只接口几千到几万元不等，五套系统两两对接可能需要十只以上的接口。钱花出去了，数据能传了，但流程还是断的。集成则要求从流程层面重新设计系统间的协作关系，投入更大、周期更长，但效果是流程贯通而非数据搬运。

二、三代集成架构：从点对点到平台化

回顾过去十五年临床营养信息系统的集成方式，可以清晰地看到三条技术路线的演进。

第一代：点对点直连

2008年到2015年前后，临床营养信息化处于起步阶段。营养科的需求相对单一——能开电子处方、能记录评估数据就行。系统供应商提供一个包含基础功能的独立客户端，通过数据库视图或中间表的方式与HIS交换数据。集成方式是典型的点对点直连：A系统和B系统之间建立一条专用数据通道，B系统和C系统之间再建一条。

直连的优势是简单、快速、成本低。一个中级工程师花一到两周时间就能完成一条数据通路的开发。但缺陷在系统数量增加时迅速暴露：五套系统两两直连，需要维护的接口数量理论上达到C(5,2)=10条。每一条接口的字段定义、传输协议、异常处理逻辑都可能不同。系统升级时，接口需要同步修改，牵一发而动全身。

某医院信息科主任在一次行业会议上分享过直连模式下的典型困境：HIS系统的一次常规升级，导致营养筛查数据接口字段类型变更，营养系统侧数据解析失败，筛查数据连续三天未能正常写入。问题定位用了两天、修复用了一天——因为两条系统由不同的供应商维护，沟通成本远高于技术修复本身。

第二代：企业服务总线

2015年以后，随着集成需求的增长，企业服务总线（ESB）模式开始进入医院信息化领域。ESB的核心思路是在各业务系统之间引入一个中间层，所有系统的数据交换统一通过总线完成。接入新系统时，只需要开发一条连接到总线的适配器，不需要为每对系统分别开发接口。

ESB模式的进步是显著的。接口数量从O(n²)降为O(n)，数据交换有了统一的监控和管理平台，系统的增删变更不再需要联动修改多条接口。中国医院协会信息管理专业委员会的数据显示，截至2023年，三级医院中采用ESB作为集成平台的占比已超过50%。

但在临床营养这个具体场景中，ESB模式有结构性的局限。ESB擅长的是数据层面的路由和转换——把A系统的数据转成B系统能识别的格式、按路由规则发到指定目标。但营养诊疗流程需要的不仅是数据路由，还有流程编排：筛查完成后是否自动触发评估、评估结果满足什么条件才自动生成处方建议、处方审核超时后如何升级处理。这些流程逻辑如果全部写在ESB的路由规则里，总线会变得异常臃肿，维护成本急剧上升。

第三代：集成平台+微服务

近三到五年，集成平台加微服务架构在临床营养信息化领域开始获得关注。这一代架构的核心思路是：不再试图让所有系统互相通信，而是在业务层面抽象出统一的营养诊疗服务层。筛查服务、评估服务、处方服务、随访服务——每一个临床业务环节被封装为独立的服务单元，服务之间通过标准化的API接口通信，流程编排由独立的流程引擎管理。

与ESB的核心区别在于：ESB是被动的数据管道，系统主动把数据丢进管道，ESB负责投递到目标；而集成平台模式中，平台本身是主动的流程调度者，它按照预设的诊疗路径，依次调用各个服务，管理每个节点的输入输出和状态流转。

这种架构对流程复杂、涉及系统多的临床营养业务场景尤其适用。一条营养诊疗路径可能包含六个步骤、涉及四个系统、需要两个科室的协作——集成平台模式可以把这条路径定义为一个可执行的流程模板，平台负责调度，各系统以服务的方式参与。流程的执行状态、每个节点的耗时、异常发生的频率和环节——全都可以通过平台监控。

当然，这种架构对医院信息基础设施的要求也更高。需要独立的流程引擎、服务注册中心、API网关，运维复杂度不可同日而语。目前国内采用第三代架构的医院营养科尚属少数，但头部三甲医院和新建院区已经开始布局。

三、绕不开的三个核心命题

无论采用哪种集成路径，有三个方面的问题是任何集成项目都必须回答的。

命题一：数据标准化——接口通了，但数据「各说各话」

这是临床营养信息化集成中最基础也最棘手的问题。

一个简单的例子：营养风险筛查结果中的”体重”字段，在护理系统中字段名为”body_weight”，单位是公斤，数据类型是decimal(5,1)；在营养系统中字段名为”weight_kg”，单位同样是公斤，数据类型是float；在电子病历系统中，体重数据以字符串形式记录在生命体征段落中，格式为”XX kg”。三个系统存储的是同一患者的同一项数据，但字段名不同、数据类型不同、存储格式不同。

这就是典型的”接口通了、数据成了”。ESB和集成平台可以在传输层做数据格式转换——把decimal转成float、从字符串中解析数值。但更复杂的语义差异无法在传输层解决：比如营养状况评估中的”营养不良”分级标准，不同系统可能参照不同的指南（GLIM标准、SGA分级、PG-SGA评分），同一个术语在不同系统中的含义范围可能不同。

国家卫生健康委2025年版互联互通测评方案中明确要求营养诊疗数据实现语义级互操作，这意味着医院需要在院内建立统一的临床营养数据元标准，明确每一个共享数据项的定义、数据类型、值域和编码体系。这项工作需要在集成项目实施前启动，因为数据标准一旦确定，涉及所有系统的字段映射和改造。

命题二：流程编排——谁在调度营养诊疗的每一步

营养诊疗不是单点操作，而是一条链路。筛查→评估→诊断→处方→执行→监测→随访，七个步骤环环相扣，每个步骤的完成状态决定下一步的触发时机和执行内容。

在多系统并行的环境下，这条链路的调度靠什么来完成？最常见的方式是人工——护士做完筛查后电话通知营养师、营养师完成评估后到病房查看患者、处方开好后打印纸质单送到护士站。人工调度有灵活性，但代价是效率低下、容易遗漏、无法追踪。

系统层面的流程编排，是集成平台区别于简单对接的核心能力。流程引擎接收来自各系统的事件（如”筛查完成”事件），根据预设的规则判断下一步操作（如”筛查阳性则生成评估任务并推送到营养师工作台”），调用相应的服务执行操作，并记录执行结果。

流程编排的难点不在于技术实现，而在于规则定义的颗粒度和覆盖度。营养诊疗流程存在大量边界情况和例外路径——患者转科了流程怎么走、患者出院了随访任务是否继续、急诊入院的患者是否跳过筛查直接进入评估。流程设计需要在规范性和灵活性之间找到平衡点。

命题三：服务治理——多系统协同时的可用性保障

当营养诊疗的关键流程依赖多个系统的协同工作时，任何一个系统的不可用都可能造成整条链路的中断。筛查系统正常但处方系统宕机了——营养师完成了评估却无法开具处方。集成平台是否应该缓存处方数据、等待系统恢复后再提交？处方系统恢复后，积压的未处理处方如何排序、如何提醒？

这是服务治理的范畴。集成平台需要具备服务注册与发现、健康检查、熔断降级、异步消息等基础能力。当某个下游服务不可用时，平台可以暂存请求、提供降级方案（如转为纸质流程并在系统恢复后补录），而不是让整条链路卡死。

服务治理的另一个维度是监控和告警。集成环境中，一条营养诊疗请求经过的节点至少在三个以上，任何一个节点的异常都可能导致超时或失败。没有端到端的链路监控，问题定位就像在黑箱里找断点。集成平台应提供全链路追踪能力——从请求进入平台到最终完成，经过每个服务的耗时、状态、错误信息都应有记录。

四、集成带来的几个实际变化

从多家已推进营养信息化集成的医院反馈来看，集成深度的提升会带来几项可以量化的变化。

筛查到评估的闭环时间缩短。直连模式下，筛查结果从护理系统传输到营养系统的平均延迟在数分钟到数小时不等——取决于接口的轮询频率。集成平台模式下，筛查完成后的事件实时推送，营养师工作台在数秒内即可收到评估任务。浙江省某三甲医院在完成营养筛查与评估模块的流程集成后，筛查阳性患者的评估启动时间从平均4.6小时缩短至0.8小时。

数据重复录入减少。多系统并行时，同一患者的营养数据可能需要在不同系统中分别录入。集成平台通过统一数据服务层，实现了数据的单次录入、多处复用。前述省级三甲医院在集成平台上线后，营养师在系统中的日均录入操作次数减少了约37%，减少的部分主要来自不再需要在多个系统间重复输入同一数据。

质控数据的可及性提升。分散的系统意味着分散的数据，分散的数据意味着无法统计。集成平台汇总了各环节的数据后，科室主任可以在一张视图中看到从筛查到处方的全链条数据，质控指标的统计从”手动收集”变为”自动生成”。有医院反馈，集成后质控报表的生成时间从之前的每周半日人工整理，缩短到系统实时生成。

五、集成不是终点

回到开篇的那组数据。五套系统并行不是某家医院的落后——它是临床营养信息化发展到一定阶段的自然产物。业务的细分带来了专业系统，专业系统林立造成了集成困局。

但集成不是终极目标。集成之后，当营养诊疗数据在系统间自由流动、流程自动编排、质控实时监测，临床营养信息化才真正具备了从”记录工具”向”决策支持”跃升的基础条件。数据打通之后，才能谈数据分析；流程贯通之后，才能谈流程优化。

从五套系统到一体化平台，这一步跨过去，前面才有更开阔的空间。不是接口数量归零，而是诊疗流程归位——让信息系统回归工具的定位，让临床营养师把精力从系统操作中解放出来，回到患者床边。