对接了三个月，EMR中仍无法查看营养评估结果

现象

在医疗机构营养信息化建设中，营养管理系统与电子病历系统（EMR）的数据互通是一个常见难点。

某三甲医院信息科在年度工作计划中立项：实现临床营养管理系统数据在电子病历系统中的集成查看。项目计划工期两个月。

实际执行三个月后，进展仍停留在数据推送的中间阶段：营养评估数据能够推送至中间库，但EMR侧仍无法完成解析和展示。

项目启动时，信息科评估认为工作量不大。理由是：营养系统有现成的数据推送接口，EMR也支持标准的HL7接收模块，两端对接应该能够较快完成。

计划工期两周。

实际推进中发现第一个问题：营养系统与EMR使用不同的营养评估量表体系。

营养系统以NRS-2002（营养风险筛查2002）为主，评分范围0-7分；EMR系统中嵌入的是PG-SGA（患者主观全面营养评估）分级体系，用字母A/B/C表示。

两套体系之间没有公认的行业换算标准。数据推送后，EMR无法将营养系统的评分结果转化为符合临床解释框架的信息。

《电子病历系统应用水平分级评价标准》对数据标准化有明确要求，但在实际执行中，不同系统供应商采用不同数据标准的问题仍然普遍存在。

解决方案最终定为：两端各自保留原始数据，互相对照存储。但这一方案意味着营养评估结果在EMR中只能以原始分数形式展示，无法直接呈现为临床可解读的分级结论。

数据字典问题刚有眉目，又出现新的障碍。

营养系统中的患者标识为住院号，EMR使用的是患者主索引ID。两套体系编码规则不同，同一患者在两个系统中的ID可能不一致。

这导致营养系统推送的数据，在EMR侧无法找到对应患者记录，被系统丢弃。临床医生在EMR中看到的仍是空白。

患者主索引（MPI）的统一是《医院信息互联互通标准化成熟度测评方案》中的重点内容，但在部分老系统较多的医院中，这一基础数据标准化工作仍不完善。

事后复盘，项目进展受阻的根因集中在三个层面：

其一，预估阶段缺少详细的现状调研。 项目启动时，信息科基于类似项目经验做了工期预估，但没有逐字段梳理两个系统之间的数据差异。《信息系统项目管理标准》中强调，项目启动阶段应进行充分的需求分析和现状调研，这一环节的缺失导致后续问题集中爆发。

其二，缺乏统一的数据标准。 国内医疗信息化领域虽有HL7、DICOM等国际标准和《电子病历数据集》等行业标准，但在具体系统对接时，两套系统的数据字典、术语编码、单位定义仍可能存在差异，且缺乏可直接对照的行业权威映射表。

其三，中间转换层的规划被低估。 两个系统之间的数据格式转换、字段映射、单位换算工作，在项目预估阶段往往被归为”技术细节”，而非”核心工作量”。实际上，这部分工作量通常显著影响项目工期和成本。

与已完成类似对接项目的医院交流后，梳理出几种不同的解决思路：

思路一：中间层方案。 在营养系统与EMR之间部署数据转换服务，负责格式转换、字段映射、单位换算。这是完整的集成方案，但开发和维护成本相对较高。

思路二：附件集成方案。 营养系统生成评估报告PDF，通过EMR的附件功能挂载到患者病历下。《电子病历系统应用水平分级评价标准》中明确允许以附件形式集成外部报告。这一方案技术难度较低，但数据的时效性和结构性较弱。

思路三：延迟对接方案。 暂缓系统层面的实时对接，通过其他沟通机制（如内部消息系统）解决信息传递问题，等待更成熟的时机再推进技术对接。

第一，对接类项目要做详细的现状调研再预估工期。 建议在项目启动前，信息科与营养科、EMR供应商三方共同参与，对照现有数据字段逐条梳理差异点，明确数据流向和转换逻辑，再做工期和资源测算。

第二，根据业务需求选择集成方案。 不同临床场景对数据时效性要求不同。《电子病历系统应用水平分级评价标准》将数据可用性作为重要评价维度，但在实际建设中，应根据业务需求而非技术完美度来选择方案。

第三，明确长期运维责任。 系统集成不是一次性工程。接口会变、数据字典会调整、业务规则会优化，这些持续性工作需要在项目启动前就明确责任归属和响应机制。

系统对接项目的复杂度往往在前期被低估。其挑战不仅在于技术实现，更在于多系统、多供应商、多标准之间的协调。《医院信息互联互通标准化成熟度测评方案》的出台，正是为了推动这一问题的解决。但在标准落地过程中，仍需要项目各方投入足够的调研和沟通时间，而非仓促进入开发阶段。