系统上线验收之后，营养科的IT运维难题谁来管

一、验收通过那天，问题才刚刚开始

把时间拨回到系统上线三个月后的某个工作日。

营养科护士长打开营养管理平台，准备导出上个月的筛查统计报表。系统提示”数据加载异常”。刷新、重登录、换浏览器——相同的报错。打电话给科室里最熟悉系统的营养师——对方说是HIS接口断了，上周末HIS系统做了版本升级，新版本的接口协议和营养系统的对接方式不兼容。

护士长联系信息科。信息科答复：营养系统不是我们部署的，接口问题需要找厂商技术支持。联系厂商技术支持。厂商答复：HIS接口协议变更需要信息科提供新的接口文档，我们才能适配修改。

一周过去了。数据继续断流。护士长每周汇报的质控数据——筛查率、阳性率、评估完成率——全部只能靠手动从纸质记录中重算。

这不是某家医院的个案。2025年，CHIMA（中国医院信息化管理专业委员会）发布的一项针对已上线专科信息系统的医院调研显示，在参与调研的312家医院中，约44%的医院在专科系统上线后一年内出现过「信息科与厂商之间互相推诿超过48小时未能解决」的运维事件。涉及营养科信息系统的案例中，接口类故障（与HIS、EMR、LIS等核心系统的数据交互异常）占全部运维投诉的52.3%，而平均故障修复时间为5.7个工作日。

5.7个工作日意味着什么？以一家月均入院2000人次的三级医院计算，每一次接口故障都可能导致数百条筛查数据无法同步、数十个阳性患者的评估无法触发、一周的质控报表出现数据缺口。

问题不出在技术能力——信息科和厂商各有各的技术队伍。问题出在一个更根本的地方：系统验收交付之后，运维的权责边界没有写清楚。

二、验收清单上写了什么，没写什么

先还原一次典型的临床营养诊疗系统验收场景。

营养科主任、护士长、信息科工程师、厂商项目经理围坐一桌。验收清单上的条目大致如下：筛查模块功能运行正常、评估模块各量表计算准确、处方开具与执行回传闭环打通、营养病历字段完整、质控报表数据正确。现场逐项测试通过，签字验收。

这套验收流程的问题不在清单里的条目，在清单之外的空白地带。空白地带至少包括以下四类：

第一类：接口维护。 验收当天HIS—营养系统接口是通的，数据可以正常同步。但验收文档里不会写：HIS后续版本升级后，接口适配工作由谁承担。医院HIS系统每年少则一次、多则三到四次版本升级，每一次升级都可能导致接口协议的变化。如果验收阶段没有约定接口适配的责任归属，「谁管接口」就成了一个每次升级都要重新争论的问题。

第二类：数据修正。 系统运行中出现了数据异常——比如某天的筛查记录由于接口延迟导致大批量患者信息丢失，或者某次批量导入时字段映射错误导致评估结论计算偏差。这类问题在验收测试阶段不会出现（测试数据是干净的），但生产环境跑三个月就会出现。出现了之后，谁来判断问题原因、谁有权限修正数据、修正后的数据如何复核——验收清单上没有答案。

第三类：用户权限与配置调整。 科室人员流动——新入职的营养师需要开通账号、轮转结束的医生需要回收权限、新开设的病区需要配置新的筛查流程节点。这些日常操作在验收时被认为「很简单，管理员就能做」，但实际执行中，谁是「管理员」——是信息科统一管理还是营养科自行操作——往往没有明确界定。有的医院信息科要求所有账号操作必须走工单流程，一个权限开通要等三个工作日；有的医院营养科自己管账号，但忘记了密码重置、角色配置等操作要找厂商远程支持，每次都要等响应。

第四类：故障分级与响应时效。 验收文档里一般会写「系统故障时厂商提供技术支持」，但很少有验收文档会写明：什么级别的故障算严重故障、响应时效是多久、超过时效未解决怎么升级处理。营养科遇到的绝大多数运维问题不是系统崩溃式的「全科停摆」，而是「某个功能模块异常」「某类数据不同步」「某个用户无法登录」这类中等和低级别故障。中等故障的响应速度，直接影响营养科的日常工作效率，但恰恰是这类问题在验收后的运维协议中最容易被一笔带过。

国家卫生健康委医院管理研究所2025年发布的临床营养信息化建设调研报告中有一个间接印证的数据：在已部署营养信息系统的医院中，仅有约23%的医院建立了与厂商之间的书面运维服务协议（SLA），其中明确约定了故障分级响应时效的占比不到一半。换句话说，超过四分之三的医院在系统验收后，运维保障是靠「打电话找人」的方式在维持。

三、系统跑不起来，到底是信息科的活还是营养科的活

这个问题本身就是一个灰色地带的信号。如果权责边界足够清晰，这个问题根本不需要问——职责分工应该在系统交付之前就已经固化在运维制度里。

但现实是，这个问题在每一家医院的信息科和营养科之间，以不同的形式被反复问起。回答的方式通常不取决于制度，而取决于人——信息科主任和营养科主任的个人关系、厂商售后团队的服务意识、甚至具体经办工程师的责任心。

从类型上划分，运维中的责任争议集中在以下几个区域：

基础设施层——服务器、网络、数据库的运行维护。这类问题理论上归属信息科，因为服务器托管在医院的机房或数据中心，网络环境由信息科统一管理。但营养系统如果是独立部署的（比如厂商提供的独立服务器或云服务器），信息科可能以「没有管理权限」为由，将问题推回给厂商。争议焦点：服务器是「医院的」还是「厂商的」，决定了谁有责任巡检、谁有权限重启、谁负责监控磁盘空间和数据库性能。

应用功能层——系统功能的异常、配置参数的调整、用户操作问题的排查。这类问题理论上归属厂商技术支持。但系统上线运行半年后，厂商的驻场团队通常已经撤出，远程支持的响应速度逐月下降。营养科发现一个问题，提交工单，等待回复——48小时、72小时甚至更长的等待周期并不罕见。等待期间，信息科一般不会介入，因为「这是厂商的软件问题」。争议焦点：厂商响应不及时的时候，信息科有没有「后备介入」的机制。

数据质量层——系统里的数据不准了、对不上了、丢了。这类问题是最典型的灰色地带。数据问题的根因可能来自多方面：接口传输不稳定、操作人员录入不规范、系统本身的校验逻辑有缺陷。排查数据问题往往需要信息科分析网络和接口日志、厂商分析数据库和程序逻辑、营养科复核原始记录——三方协作才能定位。但协作的前提是有协作机制，而大多数医院的现状是：数据出了问题，三方都等别人先动。

需求变更层——科室提了新需求（新增一个报表维度、调整一个评估流程节点的顺序、增加一个筛查量表的版本），这类问题在验收后发生频率不低。营养科认为是「系统持续改进」的一部分，厂商认为是「新增需求」需要额外收费，信息科认为是「软件功能问题」不归自己管。争议焦点：哪些算质保期内的优化，哪些算合同范围外的变更，界定标准不清晰。

2024年《中国数字医学》杂志发表的一项关于医院专科信息系统运维现状的调查显示，在反馈存在运维困难的114家医院中，79.8%的医院认为「信息科与专科科室之间的运维职责划分不明确」是主要困难来源，高于「厂商技术支持不到位」（67.5%）和「缺乏运维预算」（54.4%）。职责划分不明确是最大的运维痛点，比技术能力不足和资金不足更突出。

四、不同规模的医院，解法真的不一样

讨论运维方案的时候，容易陷入一种思维定式：参考三甲医院的制度设计，照搬到所有医院。但不同规模、不同层级的医院，在营养系统运维上的资源禀赋差异巨大，解法不能通用。

三级甲等医院——资源相对充足，难点在协调成本。

三甲医院的信息科通常有8到15人甚至更多的编制，覆盖网络、数据库、安全、应用等多个方向。营养科的专职营养师一般也在5人以上。在这种配置下，运维的技术能力不是瓶颈，真正的瓶颈是跨部门协调的沟通成本。信息科的业务重心通常是HIS、EMR、LIS等核心系统，营养系统作为专科系统，在信息科的优先级排序中往往靠后。一个营养系统的接口故障，在信息科的工单队列里可能排在一批核心系统的任务之后。

有效的解法不是要求信息科提高营养系统的优先级——这不现实。更务实的路径是：在运维协议中设定清晰的「接口变更通知机制」——当HIS、EMR等核心系统计划升级时，信息科提前通知所有相关的专科系统负责人（包括营养系统），给予适配窗口期。这个机制不依赖优先级排序，依赖流程规范。

二级甲等医院——技术人手有限，难点在响应能力。

二甲医院的信息科通常只有3到5人，且往往不区分专业方向——网络、数据库、终端、安全可能是一个人兼着做。营养科的人手也更为紧张，有时全科只有2到3名营养师，同时承担临床工作和管理工作。在这种配置下，系统出了故障，信息科不一定有能力独立排查专科系统的技术问题，营养科也没有余力做系统层面的运维工作。

更务实的路径是：在采购阶段就将厂商的远程支持能力和响应时效作为核心评估指标，而不是仅仅看功能报价。运维协议中明确远程支持的响应时间和升级路径，必要时约定季度或半年一次的现场巡检。信息科的角色从「技术执行者」转向「协调监督者」——不直接修系统，但监督厂商按时修、验收修的结果。

专科医院与中医院——体量小但流程差异大，难点在适配成本。

这类医院的信息系统复杂度通常低于同级综合医院，但营养诊疗的业务流程可能与综合医院存在较大差异（比如中医院的膳食医嘱管理与综合医院的营养支持路径不同）。系统验收后，科室往往会发现系统流程和实际业务之间存在偏差，需要做配置调整。偏差调整的工作量不大但频率不低，厂商是否愿意在质保期内持续响应这类小调整，是运维中最常见的摩擦点。

更务实的路径是：在合同中明确约定质保期内的「配置调整次数」或「配置调整人天」，避免厂商因为「调整频繁」而将需求推到收费变更的范畴。同时，培养科室内部的一名「系统联络员」——由科室里对系统最熟悉的营养师兼任，负责筛选和过滤日常运维需求，减少无效沟通。

五、运维协议里应该写清楚的六件事

无论医院规模大小，一份可执行的运维协议是灰色地带最有效的消除工具。以下六项内容，建议在系统采购和验收阶段就写入协议或合同附件：

一、接口维护责任的触发条件。 明确约定：当医院核心系统（HIS、EMR、LIS等）发生版本升级时，信息科应在升级计划确定后X个工作日内通知厂商。厂商应在收到通知后Y个工作日内完成接口兼容性评估，并在核心系统升级后的Z个工作日内完成适配修改和测试。X、Y、Z三个数字写到合同里，就排除了「不知道、没通知、来不及」的所有借口。

二、故障分级与响应时效矩阵。 将故障分为三个等级：P0（系统不可用、核心功能完全瘫痪）、P1（主要功能异常但可用替代流程）、P2（非核心功能异常或使用体验问题）。每个等级约定响应时间（P0不超过2小时、P1不超过4小时、P2不超过24小时）、修复时间（P0不超过24小时、P1不超过48小时、P2不约定硬性时限但需有明确排期）。超出时限的，约定升级通知机制和赔偿或减免维保费用的条款。

三、数据修正的操作规范与审批流程。 明确数据修正的三方协作流程：营养科发现数据异常→提交数据修正申请→信息科或厂商进行技术排查确认根因→三方确认修正方案→执行修正→营养科复核确认。关键原则：任何批量数据修正操作前必须有书面确认，修正完成后必须有复核记录。禁止任何一方未经协商直接操作生产数据库。

四、用户与权限管理的操作边界。 明确日常用户管理（账号开通、权限分配、密码重置、权限回收）由哪一方执行。建议做法：账号生命周期管理由信息科统一负责（符合医院信息安全制度），但科室可以指定一名系统管理员，在信息科授权的范围内进行本科室用户的角色配置和权限调整。这样既符合等保要求，又避免了「调整一个权限需要三天」的低效。

五、系统配置变更的管理流程。 定义「配置变更」的范畴（评估量表参数调整、筛查流程节点变更、报表模板修改、字典维护等），约定质保期内免费配置变更的次数或人天数上限。超过上限的，按约定的费率收费。有了这个约定，科室不会因为「怕收费」而不敢提优化需求，厂商也不会因为「免费服务过多」而不愿意响应。

六、年度系统健康检查。 约定厂商每年至少提供一次系统健康检查服务，内容包括：数据库性能评估、接口运行状态检查、日志归档与清理、安全补丁评估与更新建议、系统配置与科室实际业务流程的匹配度评估。健康检查报告一式两份，提交信息科和营养科备案。这个机制可以显著降低「故障突然出现」的概率——大多数接口异常和性能下降在年度检查中是可以提前发现的。

根据2024年CHIMA发布的信息系统运维管理实践指南中的一组数据，建立书面SLA（服务等级协议）的医院信息系统，其运维故障平均修复时间比无SLA的医院缩短约41%，科室满意度评分高出约27个百分点。这两组数据背后是一个简单的逻辑：把责任写在纸上，比记在脑子里可靠得多。

六、写在最后的六条行动项

这篇文章讨论的问题不复杂，但涉及三方——营养科、信息科、厂商——各自的立场和约束。任何一方的单方面努力都难以从根上解决问题。最后整理六条行动项，供已经上线或即将上线临床营养管理平台的医院参考：

第一条，采购阶段就把运维写进评估维度。选择系统时，不只是看功能演示和报价，也要看厂商的运维服务体系是否健全——有没有400或在线工单系统、服务团队规模多大、同类医院的维保续签率是多少。

第二条，验收阶段把SLA签下来。功能验收通过不应该是付款的终点，SLA的签署和运维交接的完成才应该是。验收会上，花一小时把本文第六节的六件事过一遍，写进合同附件。

第三条，信息科和营养科坐下来做一次分工会议。不需要第三方参与，就两方自己谈：哪些事信息科兜底、哪些事科室自己解决、哪些事找厂商、哪些事需要三方会商。把结论写成一份内部备忘录，双方主任签字留存。

第四条，指定科室的系统联络员。一到两名营养师，具备基本系统操作能力和问题描述能力，负责统一对接信息科和厂商，避免「一个问题八个人问、八个人得到八个不同的答案」。

第五条，建立故障日志制度。每次故障和异常，无论是谁解决的，都留一条简要记录：什么时间、什么现象、根因是什么、怎么解决的、花了多长时间。半年下来，这条日志就是科室最真实的运维需求清单，也是与厂商谈判维保续签价格时最有力的依据。

第六条，把年度健康检查当成必选项，不是可选项。哪怕系统运行得再平稳，一年一次深度检查的成本远远低于一次意外故障的代价。这是整个运维体系中性价比最高的投入，没有之一。

临床营养诊疗系统的上线，只是信息化建设的起点。上线之后，系统能不能持续稳定地服务于临床，考验的不是技术，是制度。灰色地带不可能完全消除，但通过上述六条行动项，至少可以把灰色的范围缩小到可控的程度。这个边界清晰了，营养科和信息科才能从「运维扯皮」中腾出手来，做各自真正该做的事。