医院信息化建设方案-HIS-EMR-LIS系统选型指南

医疗健康·IT技术·报告方案

医院信息化建设方案

——HIS/EMR/LIS系统选型指南

标签：医院信息化/HIS/EMR/LIS/系统选型/招标采购/集成平台

适用人群：医院信息科负责人、院级决策者、临床科室代表、采购与招标管理人员日期：2026年9月17日

目录

01第一部分建设背景与规划前提

02第二部分三大核心系统的定位与功能边界

03第三部分选型五步流程：从需求梳理到合同签订

04第四部分选型评估指标体系与权重分配

05第五部分报价拆解与五年总拥有成本测算

06第六部分实施步骤与时间节点

07第七部分集成、数据治理与安全合规

08第八部分合同条款与招标文件要点

09第九部分风险提示：八类需要提前预判的风险

10第十部分避坑指南：十二个最容易出错的地方

11第十一部分常见问题解答

12附录A需求清单模板

13附录B选型评估打分表

14附录C合同条款检查清单

15附录D关键词索引

第一部分建设背景与规划前提

一、医院信息化建设的三类常见困境

信息化建设投入不小，但上线后临床抱怨多、信息科疲于应付、管理层看不到数据价值的案例并不少见。问题往往不在

系统本身，而在建设前的规划缺位。以下三类困境出现频率最高。

困境类型典型表现根本原因

系统孤岛HIS、EMR、LIS由不同厂商在不同时期建设，患者建设时未规划统一的主索引服务和集成平

主索引不统一，同一患者在多个系统中存在多套ID，台，接口由各厂商单独开发，缺少统一规

数据无法关联；门诊医生在一个界面开检查、在另一范

个界面写病历、在第三个界面看检验结果

厂商绑定早期采购未约定接口规范和数据结构，后续新增系统合同中缺少接口开放承诺、数据字典说明

或替换模块时，原厂商报出高额接口费，医院失去议和退出条款

价空间

目标模糊把"上系统"当作目标，而非把"解决什么问题"当作目立项阶段未明确可衡量的建设目标，需求

标；系统上线后门诊等候时间没有下降，病历书写时清单由厂商提供而非医院自己梳理

间没有减少，管理决策仍靠手工报表

二、规划前提：先定目标，再选系统

不同类型的建设目标，会导向完全不同的选型方案。同样是三级医院，以评级达标为目标和以数据驱动为目标，在集成

平台、数据仓库、主数据管理上的投入比例差异很大。

目标类型典型诉求选型侧重点可衡量的验收口径

合规达标型通过电子病历系统应用水平分级评评级条款覆盖度、标准化文档评级目标等级达成、测评

价、医院信息互联互通标准化成熟度能力、闭环管理能力条款自评得分

测评

业务提效型缩短门诊等候时间、减少病历书写负流程引擎灵活度、模板丰富关键业务指标改善幅度、

担、加快检验报告发布、降低护理文度、操作步骤数、响应速度单次操作平均耗时

书时间

数据驱动型支撑临床科研、DRG/DIP管理、运数据仓库能力、主数据管理、指标自动生成率、数据准

营分析、质控指标自动采集开放接口、数据可迁移性确率、报表响应时间

实操建议：一个建设周期内，三类目标可以同时存在，但必须有主次。主目标决定预算分配的大头，次目标通过预

留接口和扩展能力来满足。把三个目标并列且都要求"全面实现"，往往导致每一块都做得不深。

三、医院规模与建设路径的对应关系

医院类型床位数推荐建设路径关键注意点

基层医疗机构100张以下一体化产品为主，HIS、EMR、基础LIS重点看产品的开箱可用程度和本地

由同一家提供，减少接口协调成本化服务响应速度

二级医院100—500张HIS与EMR可分可合，LIS独立建设，接口清单必须在合同中逐项写明，

重视接口规范和数据字典标准化避免后期追加费用

三级医院500张以上多厂商组合，需建设集成平台与临床数平台层选型优先于应用层选型，集

据中心，统一主索引和主数据成能力是核心评估维度

集团化或多院区跨机构统一主数据+分布式部署，支持多院区组织架构与权限模型的可配置性、

独立运营与集团统一管理跨院区数据同步能力

第二部分三大核心系统的定位与功能边界

HIS、EMR、LIS三个缩写经常被混用，也经常在选型时被厂商用功能清单的方式模糊边界。把三者各自的"数据主责"先

划定清楚，后续的接口设计和责任划分才有基础。

一、HIS：以人、财、物、流程为主线

HIS（医院信息系统）的核心是围绕患者就医过程产生的费用流和物资流。它回答的问题是：患者是谁、挂了什么号、开

了什么医嘱、用了什么药、花了多少钱、医保怎么结算。

模块群主要功能

门急诊管理挂号、分诊、就诊卡管理、门诊医生站、门诊收费、退费、门诊药房发药

住院管理入院登记、床位管理、住院医生站、护士站、住院收费、出院结算、预交金管理

药品管理药库管理、药房管理、库存管理、效期管理、盘点、调拨、药品字典维护

物资与设备耗材管理、物资出入库、高值耗材追溯、设备台账

医保与结算医保接口、费用上传、结算清单、DRG/DIP分组数据支撑

财务与报表收入统计、科室核算、日结月结、财务接口

HIS的数据主责范围：患者基本信息的初始登记、就诊记录、医嘱执行记录、费用明细、药品与耗材库存数据。

二、EMR：以病历文书与临床决策为主线

EMR（电子病历系统）的核心是围绕患者诊疗过程产生的文本、结构化数据和临床决策支持。它回答的问题是：医生观

察到了什么、判断是什么、依据是什么、下一步做什么。

模块群主要功能

病历书写入院记录、病程记录、手术记录、出院记录、门诊病历、专科病历模板

临床决策支持诊断提示、用药提醒、过敏史警示、检验检查结果趋势提示、临床路径

医嘱处理医嘱开立、审核、执行确认、医嘱闭环、合理用药审查

病历质控时限质控、完整性质控、逻辑性质控、三级质控、质控评分

会诊与知情同意会诊申请与回复、知情同意书签署、电子签名

病案管理病案首页、编码、归档、借阅、复印管理

EMR的数据主责范围：病历文书内容、诊断信息、临床路径执行记录、电子签名与归档状态。

三、LIS：以标本与检验结果为主线

LIS（实验室信息系统）的核心是围绕检验标本从申请到报告发布的完整链条。它回答的问题是：谁的标本、什么时候采

集、送到了哪台仪器、结果是多少、谁审核的、报告发给了谁。

模块群主要功能

申请与标本管理检验申请接收、条码生成、标本采集确认、标本签收、标本状态跟踪

仪器接口双向通讯、结果自动采集、仪器状态监控、项目映射维护

结果处理结果录入、审核、复检、报告发布、报告打印、报告回写

危急值管理危急值识别、推送、确认、闭环记录、超时提醒

质量管理室内质控、室间质评、质控规则设置、失控处理记录

试剂与耗材试剂库存、效期提醒、批次追溯

LIS的数据主责范围：标本信息、检验项目结果、质控数据、仪器通讯日志。

四、边界模糊点的处理原则

以下五处是选型阶段最容易产生责任推诿的地方，需要在需求阶段就明确归属。

争议点常见做法建议处理方式

医嘱开立入口HIS医生站开立，或EMR内开立，部分统一为单一入口，避免同一医嘱在两个系统中出现不

医院两个入口并存一致。若采用EMR作为统一入口，HIS只负责执行

与计费

患者主索引归属由HIS维护，或由集成平台独立维护建议由独立的主索引服务维护，各系统通过接口引

用。多院区或多系统环境下尤其重要

药品字典与诊疗项目各系统各自维护一套由主数据管理统一维护，各系统订阅。字典不统一是

字典费用对不上、报表打架的主要原因

检验申请单来源HIS开单后传LIS，或EMR开单后传LIS明确申请单唯一来源系统，LIS只接收不生成。同时

在接口文档中写明申请单变更与撤销的处理规则

检验报告回写LIS发布后回写HIS与EMR明确回写字段范围、回写时序、失败重试机制，并在

合同中写入接口清单

边界不清的直接后果：上线后出现"医嘱开了但没执行""报告出了但病历里看不到""费用收了但项目对不上"这类问

题，厂商之间互相推诿，医院信息科成为唯一的协调方，耗费大量人力且问题长期得不到根治。

第三部分选型五步流程：从需求梳理到合同签订

选型的顺序很重要。先梳理需求，再看厂商；先做场景测试，再谈价格。顺序颠倒，容易在厂商的演示节奏中失去判断

基准。

步骤一需求梳理与优先级分级

做什么把临床、护理、医技、药事、财务、信息科的需求分类整理，形成一份医院自己的需求清单。

怎么做按"必须有/应该有/可以有"三档分级。每一条需求写明四项内容：现状痛点、期望效果、涉及科室、

验收口径。需求来源不能只有信息科，必须包含一线使用科室，否则容易出现"系统上线了但没人愿意用"的局

面。

示例需求条目写法："现状痛点：门诊医生开具检验申请后，患者需自行到检验科排队打印条码，平均等待8

分钟。期望效果：医生开单后条码自动打印或推送至患者手机。涉及科室：门诊部、检验科、信息科。验收口

径：条码获取环节平均耗时不超过1分钟。"

产出物需求清单表（模板见附录A），作为后续厂商评估的统一标尺。

步骤二厂商初筛与资质核查

做什么在正式招标前，把明显不匹配的厂商筛掉，减少后续演示评估的工作量。

怎么做从四个角度核查：一是主体资质，包括营业执照、相关软件著作权登记；二是产品成熟度，包括产品版

本迭代历史、已上线医院的运行年限；三是服务能力，包括本地服务团队规模、响应机制、是否有驻场安排；四

是同类案例，要求提供同级别、同规模医院的案例清单，并核实案例的真实性。

示例案例核查时可以要求厂商提供案例医院的联系方式，并核实三个问题：系统上线多长时间、是否经历过版

本升级、接口问题由谁负责协调。三个问题的回答质量，往往比案例数量更能说明问题。

步骤三现场演示与场景化测试

做什么用医院自己的场景和数据，验证产品是否真的满足需求。

怎么做不要让厂商自由演示。医院方提前准备5—8个具体场景，要求厂商在限定时间内现场完成。场景应当

包含跨系统流程，例如从门诊开单到检验报告回到病历的完整链条。演示过程中记录每一步的实际操作步骤数、

耗时、是否需要切换界面。

示例测试场景示例："一名门诊患者，因发热就诊，医生开具血常规与胸部CT。要求现场完成：开单、收费、

标本条码打印、结果录入、报告审核、报告回到门诊病历。全程不得使用提前准备好的演示数据。"

产出物场景测试记录表，含每个场景的实际操作步骤数、耗时、出现的问题。

步骤四商务谈判与报价拆解

做什么把总价拆解到每一个可计价单元，避免"打包价"掩盖后续的追加费用。

怎么做要求厂商按统一格式提供报价明细，至少包含软件许可、接口开发、实施服务、培训、年度维护、定制

开发六项。对每项写明计价单位和单价。同时明确免费接口范围和收费接口清单。

示例报价明细格式："软件许可：按注册用户数计价，单价×××元/用户，暂定×××用户；接口开发：免费接

口×××个（清单见附件），超出部分按×××元/个计价；实施服务：按人天计价，单价×××元/人天，预估×××

人天；年度维护：按软件许可金额的××%计算。"

步骤五合同签订与实施计划确认

做什么把前面四步谈定的内容全部转化为合同条款，并明确实施计划与验收节点。

怎么做合同中至少写入七类条款：验收标准与验收方式、付款节点与比例、接口承诺、数据归属与导出、源代

码或技术资料、违约责任、退出与交接机制。实施计划需要明确里程碑时间、双方责任人、交付物清单。

示例付款节点示例："合同签订后15个工作日内支付30%；系统部署完成并通过基础数据准备验收后支付

20%；科室试点完成并出具验收报告后支付20%；全院单轨运行满30日且无重大缺陷后支付20%；质保期满

且无未决问题后支付10%。"

第四部分选型评估指标体系与权重分配

评估指标需要在厂商演示之前确定，避免演示结束后被厂商的讲解节奏带偏。以下八项维度及权重，可根据医院自身目

标类型调整。

序评估维度权重评估要点

1功能匹配度25%对需求清单中"必须有"条目的覆盖比例；对"应该有"条目的支持程度；未覆盖条

目是否有可行的替代方案

2集成与接口能力20%是否支持主流集成方式；接口文档是否规范完整；是否支持标准数据格式；接

口开发是否有明确工期承诺；历史项目中的接口交付准时率

3技术架构与性能12%并发用户数承载能力；常用操作的响应时间；数据库与中间件的选型是否主

流；是否支持横向扩展；是否有性能测试报告

4合规与资质12%产品是否满足评级与测评的相关条款；是否有信息安全相关认证；是否支持审

计日志与操作留痕；是否满足数据安全与个人信息保护的相关要求

5厂商实力与服务12%公司经营稳定性；本地服务团队规模与响应机制；是否有驻场安排；版本升级

的频率与方式；问题响应时效承诺

6总拥有成本10%五年期总成本，含软件许可、接口、实施、硬件、数据库授权、年度维护、定

制开发、升级费用

7可扩展性5%新增科室、新增院区、新增业务模块的扩展成本与工期；是否支持配置化调整

而非定制开发

8数据可迁移性4%数据字典是否公开；是否提供批量导出工具；历史数据迁移的可行性与成本；

退出时的数据交接安排

权重调整建议：以评级达标为主要目标的，可将"合规与资质"权重提高到20%，相应降低"可扩展性"；以数据驱

动为主要目标的，可将"数据可迁移性"和"集成与接口能力"权重各提高5%。权重调整需要在评估开始前完成，评

估过程中不再变动。

评分标准与计算方式

评分档位分值区间判定标准

优90—100分需求完全覆盖，有成熟的同类案例，接口与实施均有明确承诺，报价明细完整无缺项

良75—89分需求基本覆盖，少量条目需通过配置或变通实现，案例真实可核实

中60—74分核心需求覆盖，但存在明显短板，或承诺内容模糊、缺少书面支撑

差60分以下核心需求存在未覆盖项，或案例无法核实，或报价存在重大缺项

综合得分的计算方式为：各维度得分乘以对应权重后求和。建议设置一个入围门槛，例如综合得分低于70分的不进入商

务谈判环节，避免把时间消耗在明显不匹配的厂商上。

第五部分报价拆解与五年总拥有成本测算

软件许可的初始报价往往只占五年总成本的一部分。把后续费用提前算清楚，是选型阶段最有价值的工作之一。

一、报价构成拆解

费用项常见计价方式需要注意的细节

软件许可按注册用户数、按床位数、按不同计价方式在人员增长后的费用差异很大。按并发数计价的，需

并发用户数、按服务器CPU明确并发峰值的计算口径；按CPU计价的，需明确虚拟化环境下

数、按模块打包的授权规则

接口开发按接口个数计价，或包含在实必须在合同中附上免费接口清单和收费接口清单。清单之外的接

施费中口，单价和工期都要写明

实施服务按人天计价，或按项目包干明确实施范围是否包含基础数据准备、流程配置、科室培训、上线

支持。包干价需写明超出范围的处理方式

硬件与网络按设备清单报价服务器、存储、网络设备、终端设备的数量与配置需与并发规模匹

配，避免配置不足导致上线后性能瓶颈

数据库与中间件按授权方式计价不同数据库产品的授权方式差异较大，需明确是按核心数、按用户

数还是按处理器计价，以及虚拟化环境下的计费规则

年度维护按软件许可金额的百分比计算明确维护包含的服务内容，是否含版本升级、是否含一定数量的接

口调整、响应时效承诺

定制开发按人天计价区分"配置可实现"和"需要开发"的边界。厂商倾向于把配置能实现

的功能归入定制开发，需要在合同中约定判定标准

培训与文档包含在实施费中，或单独计价明确培训对象范围、场次、是否提供操作手册和管理员手册、文档

是否随版本更新

二、五年总拥有成本测算框架

成本项第1年第2—5年说明

软件许可一次性投入可能因人员增长追明确用户数增长后的追加计价方式

加

接口开发一次性投入按新增接口追加新增系统或替换模块时会产生新的接口需求

实施服务一次性投入—新增院区或科室时可能产生增量

硬件与网络一次性投入按折旧周期更新服务器和存储通常5年左右进入更新周期

数据库与中间件一次性或按年按年续费部分产品的授权为永久授权，部分为订阅制

年度维护—每年按比例支付通常从质保期满后开始计算

定制开发按需按需业务调整、政策变化都会产生新的定制需求

内部人力成本按需按需信息科投入的协调、测试、培训人力，是最容

易被忽略的隐性成本

常见陷阱：只比较首年报价，忽略年度维护费和追加费用。两家厂商首年报价相差不大，但一家年度维护按许可金

额的15%计算且版本升级免费，另一家按20%计算且大版本升级另行收费，五年下来的差距可能相当可观。测

算时必须按五年口径比较。

第六部分实施步骤与时间节点

实施阶段的时间安排，取决于医院规模、系统数量和基础数据准备的进度。以下节点适用于中等规模医院的多系统建设

项目，实际排期需要结合具体情况调整。

序阶段参考周期主要工作与交付物

1项目启动与调研2—4周成立项目组，明确双方责任人；完成科室流程调研；输出调研报告与流程

现状图

2基础数据准备3—6周整理药品字典、诊疗项目字典、科室字典、人员字典、收费项目字典；完

成数据清洗与核对

3系统部署与环境搭建2—3周服务器与存储部署、数据库安装、网络配置、测试环境与生产环境分离

4流程配置与参数设置3—5周按调研结果配置流程、权限、模板、打印格式、报表

5接口开发与联调4—8周按接口清单逐项开发，完成跨系统联调；输出接口测试报告

6科室试点3—4周选择1—2个代表性科室试点，收集问题并修复；输出试点总结报告

7全员培训2—3周分角色培训（医生、护士、医技、收费、药房、管理员）；输出培训记录

与考核结果

8并行运行2—4周新旧系统并行，双轨录入；每日核对数据差异，形成差异清单

9单轨运行与验收4—8周停止旧系统，进入单轨运行；运行稳定后组织验收，输出验收报告

并行运行期的关键动作：并行期不是简单地"两套系统都用"，而是每天做一次数据核对。核对内容包括：门诊量与

挂号数是否一致、收费金额是否一致、检验报告数量是否一致、医嘱执行记录是否一致。差异清单要当日反馈、次

日复检，避免差异累积到单轨运行时才发现。

基础数据准备是工期最大的变数。药品字典、诊疗项目字典、收费项目字典的清洗工作，往往由医院内部承担，耗

时取决于历史数据的规范程度。历史字典中存在一药多名、一项目多码的情况时，清洗周期可能显著延长。建议在

项目启动阶段就对字典质量做一次评估，据此调整整体排期。

第七部分集成、数据治理与安全合规

一、集成方式的三种路径

集成方式实现方式适用场景与局限

点对点接口两个系统之间直接开发接口，一对一传输数据适用于系统数量少、接口关系简单的场景。系统

数量增加后，接口数量呈平方级增长，维护成本

迅速上升

集成平台通过集成引擎统一接入各系统，由平台负责消息适用于三级医院和多系统环境。接口关系由平台

路由、格式转换、日志记录统一管理，新增系统时只需对接平台。建设周期

和投入相对较高

临床数据中心在集成平台基础上，将各系统数据汇聚为统一的适用于数据驱动型建设目标。对主数据管理、数

数据模型，支撑查询、分析与科研据质量管理的要求较高，需要持续投入

二、接口标准与数据格式

标准/格式主要用途选型时需要确认的内容

HL7医疗信息交换的通用消息标准，常用于产品是否支持HL7消息的接收与发送；支持哪些消息类

患者信息、医嘱、检验结果等消息传输型；是否提供消息日志与重传机制

FHIR面向现代接口设计的数据交换标准，基产品是否提供FHIR接口；支持的资源类型范围；是否用

于资源模型，支持RESTful风格访问于对外数据服务场景

DICOM医学影像的存储与传输标准，用于影像影像相关系统的DICOM兼容性；是否支持影像与报告的

设备与影像系统之间的数据交换关联查询

标准文档规范用于电子病历共享文档的生成与交换，产品是否支持标准共享文档的生成；覆盖哪些文档类型；

支撑互联互通测评相关要求是否支持文档的注册与检索

WebService/系统间实时接口调用，常用于查询类、接口文档是否完整；是否提供测试环境；是否有调用频率

RESTfulAPI写入类接口限制；错误码是否规范

三、患者主索引与主数据管理

患者主索引（EMPI）解决的是"同一个人在不同系统中是不是同一个人"的问题。主数据管理解决的是"同一个药品在不同

系统中是不是同一个药品"的问题。这两项工作在系统数量增加后，重要性迅速上升。

管理对象典型问题处理方式

患者主索引同一患者在不同系统中存在多套ID；姓名相同建立统一的主索引服务；制定匹配规则（证件

但并非同一人；一人多卡号、姓名、出生日期、联系电话等组合匹配）；

设置人工合并与拆分流程

药品字典同一药品存在多个名称或编码；规格剂型表述不由药事部门牵头统一字典；建立字典变更审批流

统一程；各系统订阅统一下发的字典版本

诊疗项目字典同一项目在不同系统中编码不同，导致费用对不与收费项目字典建立映射关系；映射表由财务与

上信息科共同维护

科室与人员字典科室调整后各系统未同步更新；人员调岗后权限建立统一组织架构源；人员变动触发权限同步；

未及时回收定期开展权限核查

四、安全合规要点

依据《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》对网

络运营者、数据处理者的安全保护义务作出了规定。医疗卫生机构在信息化建设中应当落实网络安全等级保护相关

要求。具体条款以最新官方发布为准。

合规维度建设与选型中需要落实的内容

等级保护按相关标准确定系统定级；落实安全区域边界、安全计算环境、安全管理中心等层面的技术要求；定

期开展测评与整改

访问控制基于角色的权限模型；最小权限原则；敏感操作二次确认；离职人员权限及时回收

操作留痕关键操作（病历修改、医嘱撤销、报告修改、费用调整）全程留痕；日志不可篡改；日志保存期限明

确

数据保护传输加密、存储加密；患者隐私信息脱敏展示；数据导出需审批；导出记录可追溯

备份与容灾本地备份与异地备份结合；备份恢复演练定期开展；明确恢复时间目标与恢复点目标

电子签名病历、医嘱、报告的电子签名需符合相关规定；签名与文档绑定；签名验证机制可查

第八部分合同条款与招标文件要点

合同是选型成果的最终载体。以下条款需要在合同或技术附件中明确写入，缺一项都可能在后续产生争议。

条款类别需要写明的内容

功能范围以需求清单为附件，逐项标注"满足/部分满足/不满足"；部分满足的写明替代实现方式；不满

足的写明处理安排

接口清单附免费接口清单（逐项列明接口名称、涉及系统、数据方向）和收费接口清单（含单价与工

期）；接口变更的处理流程

验收标准分阶段验收节点；每个节点的验收内容、验收方式、判定标准；验收不通过的处理方式与整改期

限

付款节点各阶段付款比例与触发条件；付款前提是取得对应阶段的验收文件；质保金的留存比例与退还条

件

工期与延期各里程碑的时间节点；延期的责任划分；因医院方原因（如基础数据未按时提供）导致延期的处

理方式

数据归属系统产生的全部数据归医院所有；厂商不得以任何形式将数据用于其他用途；厂商需提供数据导

出工具及格式说明

源代码与技术资料明确是否提供源代码；如不提供，需提供完整的技术文档、数据库结构说明、接口文档，并约定

在厂商无法继续服务时的源代码托管或交付安排

服务响应分级响应机制：不同级别问题的响应时限、处理时限、升级路径；驻场安排；年度维护包含的服

务内容

版本升级小版本升级是否免费；大版本升级的计价方式；升级前的测试要求；升级失败的回退安排

违约责任延期交付的违约金计算方式；功能未达标的处理；数据泄露的责任；单方终止合同的条件与后果

退出与交接合同终止或到期后的数据交接方式、交接期限、交接内容；厂商配合交接的义务；交接期间的过

渡安排

知识产权定制开发部分的成果归属；医院提供的数据和流程资料的所有权；厂商使用医院名称进行宣传的

授权方式

最容易被忽略的三项：一是数据导出工具与格式说明，缺少这一项，更换系统时数据迁移会非常被动；二是接口变

更的处理流程，缺少这一项，上线后的每一次流程调整都可能变成新的收费项目；三是退出与交接条款，缺少这一

项，合同到期后厂商的配合义务没有约束力。

第九部分风险提示：八类需要提前预判的风险

风险类型具体表现与应对方向

需求失真风险需求清单由厂商提供模板后填写，实际反映的是厂商产品的现有功能，而非医院真实需求。应对

方式：需求梳理阶段由临床科室主导，信息科负责整理，厂商不参与需求清单的编写

演示与实际不符风险演示环境使用定制数据，实际部署后功能达不到演示效果。应对方式：要求厂商在测试环境中用

医院提供的模拟数据现场操作，演示过程全程记录

接口工期失控风险接口开发被安排在项目后期，成为整体进度的瓶颈。应对方式：接口清单在合同签订时即确定，

接口开发与主系统部署并行推进，设置独立的接口验收节点

基础数据质量风险历史字典存在重复、错误、缺失，清洗工作量远超预期。应对方式：项目启动阶段即开展字典质

量评估，把清洗工作纳入正式排期并明确责任人

用户抵触风险系统操作步骤比原有流程复杂，临床科室抵触使用，出现"系统上线但线下照旧"的情况。应对方

式：试点阶段充分收集反馈，优先优化高频操作路径；培训分角色开展并设置考核

并行期数据差异风险新旧系统并行期间未做每日核对，差异累积到单轨运行时集中暴露。应对方式：并行期建立每日

核对机制，差异当日反馈、次日复检

厂商服务能力衰减风险项目交付后服务团队撤场，后续问题响应缓慢。应对方式：合同中约定服务响应时限和升级路

径；要求提供本地服务团队名单；保留一定比例的质保金

数据安全事件风险权限管理不严、日志缺失、数据导出无审批，导致数据泄露或无法追溯。应对方式：建设阶段同

步落实权限模型、操作留痕、导出审批机制；定期开展权限核查

第十部分避坑指南：十二个最容易出错的地方

坑一让厂商提供需求清单

厂商提供的需求清单模板通常按自家产品功能组织，医院照着填，最后得到的是"厂商产品的功能说明"，不是医

院的需求。需求清单应当由医院各科室从实际工作痛点出发编写，信息科负责归并和分级。

坑二只看功能清单，不做场景测试

功能清单上写着"支持"，实际使用时的操作步骤数可能相差数倍。同样是"支持检验报告查询"，有的产品需要三次

点击，有的需要七次。必须用具体场景现场测试，记录实际操作步骤与耗时。

坑三先谈价格，后定需求

在需求未确定的情况下先谈价格，等于用厂商的产品范围定义了医院的需求范围。价格应当基于确定的需求清单

来谈，需求清单越明确，报价的可比性越强。

坑四报价只看首年总价

首年总价包含软件许可、接口、实施、硬件等一次性投入，后续年度的维护费、升级费、定制开发费才是长期支

出的大头。必须按五年口径测算总拥有成本。

坑五接口清单写成"按需开发"

合同中写"接口按实际需要开发"，等于没有约定。上线后每一次接口需求都可能变成新的收费谈判。接口清单必

须逐项列明，免费范围和收费范围分开写。

坑六忽略数据库授权成本

数据库授权方式差异较大，有的按CPU核心数计价，有的按用户数计价，虚拟化环境下的计费规则也各不相同。

这部分成本在软件许可之外，容易被漏算。

坑七基础数据准备未纳入正式排期

字典清洗、历史数据整理往往被视为"医院内部的事"，没有纳入项目排期，也没有明确责任人和完成时间。结果

主系统部署完成后，因字典未就绪而无法进入测试。

坑八试点科室选择过于简单

选择流程最简单、配合度最高的科室试点，试点顺利通过，全院推广时问题集中爆发。试点科室应当选择业务量

中等、流程具有代表性、既有配合意愿又敢于提问题的科室。

坑九并行期不做每日核对

并行期只关注"两套系统都能用"，不关注"两套系统的数据是否一致"。差异在单轨运行后集中暴露，此时旧系统已

停用，核对基准消失。

坑十权限模型照搬厂商默认配置

厂商默认的权限模板通常过于宽泛，上线后出现"护士能看到医生站""非本科室人员能查全院数据"的情况。权限模

型需要在建设阶段根据医院实际组织架构重新设计，并建立定期核查机制。

坑十一忽视日志与留痕要求

病历修改、医嘱撤销、报告修改、费用调整等关键操作如果没有完整留痕，后续出现争议时无法追溯。日志功能

需要在需求阶段明确提出，并在验收时逐项核对。

坑十二合同未约定退出与交接

合同只约定建设期义务，未约定合同到期或终止后的数据交接安排。更换系统时，厂商配合度无法约束，数据迁

移进度完全取决于对方意愿。

第十一部分常见问题解答

问一HIS、EMR、LIS可以由同一家厂商提供吗？

可以。基层医疗机构和部分二级医院采用一体化产品，由同一家厂商提供三个系统，接口协调成本低，实施周期短。缺

点是单一厂商绑定程度高，后续替换某一模块的难度较大。三级医院由于业务复杂度和专科化需求高，通常采用多厂商

组合，此时集成平台和主数据管理的重要性显著上升。

问二先建集成平台还是先上应用系统？

取决于系统数量和建设目标。系统数量在三到五个以内、接口关系简单的，可以先上应用系统，预留标准化接口，后续

再建平台。系统数量多、已有多个异构系统、或者建设目标包含数据驱动型的，建议先规划集成平台和数据标准，再逐

步接入应用系统。平台先行会导致前期投入大、见效慢，需要管理层的理解和耐心。

问三电子病历系统应用水平分级评价对选型有什么影响？

分级评价的条款覆盖了病历书写、医嘱处理、临床决策支持、数据质量、闭环管理等多个维度。如果建设目标包含通过

某一级别的评价，选型时应当把评价条款作为需求清单的一部分逐项核对，并在合同中要求厂商提供条款覆盖说明。需

要注意的是，评价条款会随版本更新，具体条款内容以最新官方发布为准。

问四云部署和本地部署怎么选？

核心业务系统对可用性和响应速度要求高，多数医院采用本地部署或私有云部署。部分非核心系统、对外服务类系统可

以考虑公有云部署。选择云部署时需要确认：数据存储位置、数据加密方式、网络链路冗余、服务可用性承诺、数据导

出方式、以及是否符合相关合规要求。涉及患者隐私数据的系统，部署方式的选择需要经过合规评估。

问五如何处理多个厂商之间的接口责任划分？

在合同中分别约定各厂商的接口义务，包括接口清单、开发工期、联调责任、问题响应时限。指定一家厂商作为接口协

调方，或者由医院信息科统一协调。跨系统的联调测试应当有统一的测试计划和测试用例，测试结果由各方共同确认。

避免出现"A说B的接口没准备好、B说A的接口文档不规范"这类互相推诿的情况。

问六历史数据需要全部迁移吗？

不需要全部迁移，但需要分类处理。当前在院患者和历史未结清费用相关的数据必须完整迁移；近三年的病历数据建议

迁移，以满足调阅和统计需求；更早期的数据可以采用归档查询的方式保留，不进入新系统的生产库。迁移范围在合同

签订时就应当明确，并约定数据迁移的验收标准。

问七系统上线后临床科室抵触怎么办？

抵触通常来自两个原因：操作步骤比原来多，或者看不到对自己工作的帮助。处理方式分三步：一是把高频操作路径做

优化，减少点击次数和界面切换；二是让科室骨干参与配置过程，把他们的意见体现在系统中；三是培训时重点讲解能

减少工作量的功能，而不是逐项介绍菜单。试点阶段收集的反馈，是优化体验最重要的输入。

问八验收时应该重点核对哪些内容？

重点核对四类内容：一是需求清单中"必须有"条目的实际实现情况，逐项核对而非抽查；二是接口清单中各项接口的实际

运行情况，包括数据方向和字段完整性；三是关键业务指标的实际表现，如常用操作的响应时间、并发用户数下的系统

稳定性；四是权限配置、操作留痕、数据备份等功能是否按约定落实。验收不通过的，应当出具书面整改清单并约定复

验时间。

问九年度维护费一般包含哪些服务？

通常包含系统故障处理、日常咨询答复、小版本升级、数据备份检查、性能巡检。不包含的内容一般有：新增功能开

发、大版本升级、新增接口开发、因医院流程调整导致的大规模配置变更。这些内容需要在合同中明确列出，并约定计

价方式。维护费的比例通常在软件许可金额的一定百分比范围内，具体比例需要双方协商确定。

问十更换系统时，原系统数据怎么办？

更换前的关键动作是确认原系统提供数据导出工具和格式说明。导出内容至少包括结构化数据（患者信息、医嘱、费

用、检验结果）和非结构化数据（病历文书的文本内容）。导出格式建议采用通用格式，便于新系统导入。如果原厂商

不配合，可以依据合同中的退出与交接条款主张权利。因此，在建设期就把数据导出条款写进合同，比更换时再交涉要

主动得多。

问十一医院信息科需要投入多少人力和时间？

建设期信息科的投入往往被低估。中等规模医院的多系统建设项目，信息科通常需要投入两名以上人员作为项目协调

人，负责需求归并、进度跟踪、问题协调、测试组织、培训安排。项目启动到单轨运行的周期内，这部分人力投入会显

著增加。在项目立项时，应当把信息科的人力投入纳入资源规划，避免出现"项目在推进但没人协调"的局面。

问十二厂商提供的案例怎么核实？

核实案例可以从三个角度入手：一是核实案例医院的基本情况，包括床位数、门诊量、上线系统范围，判断与本院的相

似度；二是核实上线时间与运行年限，运行时间过短的案例参考价值有限；三是核实后续服务情况，包括版本升级是否

顺利、问题响应是否及时。有条件的情况下，可以安排到案例医院实地走访，直接了解使用科室的真实评价。

附录A需求清单模板

下表为需求清单的填写模板，每一条需求对应一行。优先级分为"必须有""应该有""可以有"三档。本表建议由临床科室填

写初稿，信息科归并后交厂商作为响应依据。

编所属系涉及科

现状痛点期望效果优先级验收口径

号统室

Q-EMR呼吸内入院记录中的既往史、个首次录入后自动带入后续必须有同一患者后续文书

001科人史需要重复录入，平均文书，支持按模板批量引中既往史自动带入

每份病历多花4分钟用率不低于95%

Q-LIS检验门诊患者开单后需自行排开单后条码自动打印或推必须有条码获取环节平均

002科、门队打印条码，平均等待8送至患者移动端耗时不超过1分钟

诊部分钟

Q-HIS财务科日结报表需人工汇总多个日结报表自动生成，支持应该有日结报表生成时间

003系统数据，每日耗时约40按科室、按收费类别展开不超过3分钟，数

分钟据与各系统明细一

致

Q-集成平信息科各系统患者ID不统一，跨建立统一患者主索引，支必须有主索引覆盖全部在

004台系统查询需要人工比对持按证件号、姓名、联系院患者，重复患者

方式组合查询合并操作可追溯

Q-EMR医务科病历质控依靠人工抽查，实现时限质控、完整性质应该有质控规则覆盖全部

005覆盖率低，问题发现滞后控自动运行，问题实时提病历类型，问题提

醒醒到达责任医师

填写要点："现状痛点"要写具体数字，例如"多花4分钟""等待8分钟"，避免写"效率低""体验差"。"验收口径"要

可测量，例如"不超过1分钟""覆盖率不低于95%"，避免写"明显改善"。可测量的验收口径，是后续验收阶段判

定是否达标的唯一依据。

附录B选型评估打分表

下表按八个维度对每家厂商分别打分，最终计算加权总分。建议由信息科、临床科室代表、财务、采购等多方共同参与

打分，各方权重可根据医院管理要求确定。

序评估维度权重厂商A得分厂商B得分厂商C得分扣分理由记录

1功能匹配度25%未覆盖条目编号、部

分满足条目编号

2集成与接口能力20%接口文档完整度、历

史项目接口交付情况

3技术架构与性能12%并发测试数据、响应

时间实测值

4合规与资质12%评级条款覆盖情况、

安全功能落实情况

5厂商实力与服务12%本地团队规模、响应

机制、案例核实结果

6总拥有成本10%五年总成本测算值、

报价缺项情况

7可扩展性