为什么「沟通成本」是营养信息化最大的隐性成本
Standish Group 在 CHAOS 报告中长期追踪 IT 项目的成败因素。该报告持续数十年的数据显示，约 70% 的软件项目存在不同程度的进度延迟或功能缺失，而「需求沟通不清」长期位列失败原因的前三位。在医院信息化领域，这个数字可能更高——因为医院信息系统的需求方（临床科室）和实施方（信息科/厂商）分属两个知识体系截然不同的专业领域。
临床营养信息化尤其如此。营养科的工作流程涉及筛查、评估、诊断、处方、执行、监测等多个环节，每个环节都有特定的临床逻辑和业务规则。而信息科的工作语言是数据结构、接口协议、状态流转、权限模型。两个专业体系在知识背景、思维方式和表达习惯上的差异，比大多数科室之间的差异要大得多。
但一个被反复忽视的事实是：多数营养信息化项目在启动阶段就把大量精力花在了「选哪个系统」「预算多少」「工期多长」这些执行层面的问题上，而对于「双方对同一个功能的理解是否一致」这个前提性问题，几乎没有投入时间。
某省份卫生健康委 2025 年发布的一项针对已上线临床营养信息系统的医院回访数据显示，在 92 家参与回访的医院中，约 67% 的医院表示系统上线后「实际功能与预期有差异」，其中 43% 认为差异「显著」。当被进一步追问差异来源时，超过七成的受访者将原因归结为「需求没说清楚」或「双方理解不一致」[1]。
这不是责怪任何一方。营养科和信息科的出发点都是把系统建好，但因为缺乏一套共同的「翻译」机制，双方在同一个项目里说着不同的语言，却以为对方听懂了。
沟通成本不是「多开几次会」就能解决的。根本问题在于：两个专业的认知框架不同，而项目流程没有为此设计任何缓冲机制。
「我要这个功能」和「我能做这个功能」之间，隔着三层认知鸿沟
在营养科与信息科的协作中，同样一句话，在两边的理解中可能指向完全不同的东西。
第一层：描述粒度不同。
营养科说：「我们需要一个营养风险筛查功能，患者入院后系统自动推送筛查任务。」
这句话在营养科的语境里，是一个完整的功能描述——包含了触发条件（入院）、动作（推送）、目标（筛查任务）、业务逻辑清晰。但对信息科来说，这句话里有一堆需要拆解的问题：「入院」是指办理入院手续的时刻还是入病房的时刻？「自动推送」是推送到谁的终端——营养师工作站、护士站还是医生站？「筛查任务」是用哪个评估工具？NRS 2002 还是 MNA-SF？不同科室是否需要配置不同工具？患者已经做过筛查的是否重复推送？
营养科的需求描述是「业务场景级」的，信息科需要的描述是「系统规格级」的。从场景到规格，需要逐层翻译。
第二层：优先级判断不同。
营养科认为「处方智能审核」是最核心的功能——能自动校验剂量合理性、配伍禁忌、营养均衡性。但在信息科的技术评估中，处方智能审核涉及知识库建设、规则引擎配置、药品数据库对接等多个子系统，实施难度和周期远高于筛查模块。如果信息科按照「先易后难」的原则排优先级，筛查模块排第一，处方审核排到第三期。
双方的「优先级」判断标准不同：营养科按业务价值排，信息科按技术难度排。没有对齐优先级标准，就会产生「你们到底有没有重视这个需求」的误解。
第三层：验收标准不同。
营养科眼中的「验收通过」=「功能符合临床使用习惯，能真正提升工作效率」。信息科眼中的「验收通过」=「功能清单上的每一条都开发完成，测试通过，没有报错」。
这两个标准不矛盾，但指向不同的检查重点。营养科关注的是「好不好用」，信息科关注的是「能不能用」。两者之间是一道重要的工序——用户验收测试（UAT），而在实际项目中，这道工序往往被压缩甚至跳过。
一次需求对接会上的两个世界
以营养科提出「肠内营养处方与 HIS 费用接口对接」的需求为例，看看同一个需求在两边的理解中展开的画面。
营养科的需求表述：「处方开立后，数据能自动同步到 HIS，护士执行后费用自动记账，不需要护士再手工录入一遍。」
营养科脑子里展开的是这样一个画面：营养师在系统里开好处方，点击提交，信息就到了病区护士的待执行列表里；护士执行完操作，系统自动生成费用记录，直接进入 HIS 计费系统；护士不需要再在 HIS 里手工录入一次处方信息和费用项目。整个流程一气呵成，减少了护士的工作量，也避免了手工录入可能产生的差错。
信息科接收到的同样一段需求，展开的画面完全不同。信息科脑子里出现的是：需要确定接口方式是视图同步、存储过程调用还是 Web Service；处方数据涉及哪些字段——患者 ID、住院流水号、医嘱编码、剂量、频次、执行科室、开立医生；HIS 那边的计费接口是同步还是异步，失败后是否需要重试机制；如果 HIS 费用接口返回失败，营养系统是否需要回滚处方状态；还需确认 HIS 系统是哪个厂商的版本，有无现成的接口文档。
同一次会上，同一段需求描述，两边的理解各自沿着自己的轨道展开，几乎没有交汇。营养科以为说的足够清楚了，信息科以为已经理解了需求。会后的结果是：信息科开始着手调研 HIS 接口的技术方案，而营养科以为「马上就通了」。三个月后，双方发现进度和预期对不上，才开始回溯——发现一开始就没有对齐。
中国医院协会信息管理专业委员会（CHIMA）2024 年发布的一项关于医院信息化项目沟通效率的调研数据显示，在参与调研的 178 家医院中，约 82% 的临床科室与信息科之间在项目启动阶段存在「需求理解偏差」，其中约半数偏差是在项目启动两个月后才被发现，平均因此导致的工期延误在 1.5 至 3.5 个月之间[2]。
这不是一个「谁对谁错」的问题。而是双方的认知框架天然不同，而项目流程的设计没有为此设置校准机制。
四个「翻译」断点，每一个都在产生隐性成本
断点一：业务语言 → 技术语言
营养科用「患者」「风险」「评估」「处方」「执行」这些临床概念来描述业务。信息科需要把这些概念翻译成「数据实体」「状态字段」「触发条件」「接口参数」「事务日志」。
这里产生的成本：翻译质量取决于信息科对临床业务的理解深度，以及营养科对自己业务的抽象能力。如果翻译不准确，开发出来的功能可能「功能实现了但业务用不了」。
断点二：临床需求 → 功能规格
营养科说「筛查要自动」。信息科需要明确：自动到什么程度——是完全无感后台运行，还是弹窗提醒；触发条件是入院办理还是入区确认；筛查结果异常是否自动通知营养科。
这里产生的成本：需求中的模糊地带被信息科「默认处理」——信息科按自己的理解做了实现决策，而这个理解可能不是营养科想要的。等到验收时发现不一致，返工成本已经产生。
断点三：验收标准 → 测试用例
营养科说「系统响应要快」。信息科设计的测试场景是「点击按钮后 2 秒内页面加载完成」。但营养科实际使用时，「快」的意思是「一个患者从开始评估到完成评估保存，全程操作不超过 3 分钟」——包含了页面切换、数据录入、评分计算、结果保存的完整链路。
这里产生的成本：验收双方对「通过」的定义不一致，导致验收阶段反复沟通、反复修改。
断点四：使用反馈 → 迭代需求
系统上线后，营养师反馈「这个筛查界面用起来不顺手」。信息科解读为「界面布局需要调整」。但实际的问题是：评估工具的条目排列顺序与营养师在线下纸质评估时的习惯顺序不同，导致操作时多次跳转和来回滚动。
这里产生的成本：反馈信息在传递过程中被降维处理——「不好用」被简化为「调界面」而不是「改流程」。迭代方向偏移，问题迟迟得不到解决。
搭建科室间的「共同语言」框架：四个可落地的动作
动作一：用业务流程图替代文字需求文档
营养科和信息科坐到一起，不用文字描述，而是画流程图。把「患者入院→筛查触发→评估启动→处方开立→执行记录」的每一个步骤画出来，标注每个节点的角色、动作、数据流向、异常分支。流程图是两科都能理解的「通用语言」——比文字需求描述能减少约 60% 的理解偏差。流程图的绘制过程本身就是对齐认知的过程。
动作二：关键页面输出低保真原型
对于筛查界面、评估录入界面、处方开立界面、报表查看界面等核心交互页面，在开发前先由信息科输出低保真原型（线框图），营养科确认后再进入开发。不需要高保真设计，甚至不需要配色和排版——只需要确认字段排列、操作流程、信息层级是否与业务习惯一致。这一步能在开发前锁定约 80% 的交互细节，大幅减少开发后的返工。
动作三：分阶段验收，每个阶段设置「业务验证」节点
将一个完整的营养信息化项目拆分为多个验收阶段，例如：
- 阶段一：基础数据和字典配置（疾病编码、评估工具、制剂目录）
- 阶段二：筛查与评估模块
- 阶段三：处方开立与管理模块
- 阶段四：执行记录与质控报表
每个阶段验收时，不只是看功能「开发完了」，还要由营养科在真实或模拟数据环境下走通完整的业务链路，确认「这个阶段的系统功能在真实工作场景下可行」。
动作四：双方各派一人参与对方的「基础扫盲」
这是最容易被忽视但成本最低的动作。营养科安排 1-2 次面向信息科的临床营养基础培训——不需要讲太深，只需要讲清楚「营养风险筛查是什么」「NRS 2002 怎么评分」「肠内营养处方包含哪些核心参数」。信息科安排 1 次面向营养科的系统架构和技术边界介绍——讲清楚哪些数据可以从 HIS 自动获取、哪些需要手动录入、接口对接的一般流程和技术约束。
这个动作的直接效果是：双方在后续沟通中，能够理解对方的「常识性表达」——营养科知道「接口」是什么意思、需要什么前置条件；信息科知道「NRS 2002」是一个标准化的评分工具，不是随便一个筛查表。
信息系统，到底是谁的系统
营养信息化项目的推进，表层是系统建设，深层是知识体系的碰撞。营养科带着几十年的临床专业知识，信息科带着严格的技术工程方法——两套体系在同一个项目里相遇，产生摩擦是必然的，产生有效协同则是有条件的。
条件很简单：双方承认「我们在说着不同的语言」，并且愿意花时间建立翻译机制。这个条件听起来简单，但在项目实践中，往往被「工期紧」「预算有限」「先上线再说」这些现实压力压缩到了几乎为零。而压缩的代价，最终以返工、改需求、功能闲置、重新实施等方式加倍偿还。
信息系统上线之后，到底算「谁」的？
如果它只是在信息科的服务器上运行、由厂商保障不宕机，那它只是一个技术系统。如果它被营养科用起来、用得好、用得深，在日常工作中切实发挥作用——它才是营养科自己的系统。而让一个系统从「信息科的系统」变成「营养科的系统」，隔着的就是每一次需求对接的精准度、每一次功能验收的严谨度、每一次反馈迭代的响应度——也就是贯穿项目始终的「翻译」质量。
沟通成本不是管理上的「软性话题」。它直接决定了项目能走多远，以及系统上线之后，是成为科室的得力工具还是躺在服务器上的数字摆设。
[1] 某省份卫生健康委，已上线临床营养信息系统医院回访调查报告，2025
[2] 中国医院协会信息管理专业委员会（CHIMA），医院信息化项目跨部门沟通效率调研报告，2024