医院信息集成平台项目建设方案与实践 第4章 项目建设设计（一）

4.1 项目总体建设原则

  医院信息平台体系架构遵循以下原则:

• ◼  基于医院信息化现状，实现信息共享与业务协同。即平台的建设不是一个推翻现有应用重

  建的过程，而是基于现有信息系统和现有的系统数据，通过医院信息平台来整合信息，并

    实现系统之间的业务协同。
  

• ◼  基于企业信息架构分层设计思路。按照企业信息架构理论和方法，以分层的方式设计医院

    信息平台，不同的层次解决不同的问题。
  

• ◼  全面支持电子病历相关业务规范与标准体系。从数据层面遵循《电子病历基本架构与数据

  标准》，即医院信息平台上保存的电子病历数据符合该标准;在电子病历生成和使用上符

    合电子病历相关业务规范。
  

• ◼  具备良好的稳定性、可靠性、完整性、可扩展性。

• ◼  具备异常应变和容错能力，确保系统安全可靠，提供运行情况实施监控。

• ◼  统筹规划、分布实施原则，先整体设计医院信息集成平台建设框架，进行基础性模块建设，

  然后进行基于集成平台进行应用性建设如 CDR 等。

4.2 平台总体架构

 

 

建立和完善覆盖医院临床业务和管理的一体化院内集成平台，强化以电子病历为核心的临

床数据中心，促进以病人为中心的医院信息资源整合与利用，优化服务流程，规范诊疗行为， 提高医疗服务质量和效率，提升临床服务与决策能力，实现科学化、精细化、专业化管理和服 务。

院内集成平台应立足于医院已有信息系统，将封闭、孤立的信息系统中的数据释放出来， 实现物理集中，转变成各种有价值的信息，以帮助医院实现持续的质量改进和服务创新。医院 信息集成平台建设不必推翻原有业务应用系统，在最大限度保护已有的信息化投入的前提下， 实现医院信息化建设的实质性提升，达到统一数据中心、支持数据分析利用和智慧决策的目的。

院内集成平台的总体框架如上图所示，主要包括平台交换层、平台资源层、平台服务层以 及平台应用层。

4.2.1 医院业务应用层

医院业务应用层是医院信息平台的基础。业务应用层包括三大类业务系统:医疗服务系统、医疗管理系统、运营管理系统。业务应用层要接入到医院信息平台，向平台提供相关业务数据， 同时也从平台获取业务协同支持。

目前，**医院医疗三大类业务系统基本建设成型，同时积累了大量的业务数据，本次信息 化建设主要是把这三大类系统标准化改造后，接入到医院信息平台中来，为医院集成平台提供 数据基础，同时从瓶体获取交换支撑。

4.2.2 医院信息平台交换层

医院信息平台交换层主要以满足临床信息、医疗服务信息和医院管理信息的共享和协同应 用为目标，采集相关业务数据，并对外部系统提供数据交换服务，包括与区域平台的数据交换。 这也是**医院本次信息集成平台建设的重点之一。

信息交换层为整个平台的数据来源提供技术基础和保障，通过信息标准、交换原则的制定， 对业务系统提供标准的信息交换服务，确保数据交换过程的安全性、可靠性，实现数据在系统 平台范围内自由、可靠、可信的交换。

目前，国内各医院信息化厂商的平台交换技术实现形式并不一致，有些厂商是自我研发但 技术并不成熟，有些是采用国际上比较成熟的专业医疗平台交换中间件。从项目技术的成熟性 和系统运行稳定考虑，成熟的专业医疗平台交换中间件比较适合医院目前集成平台建设。

依托于集成平台中间件，借助医院服务总线 ESB 结构模式，通过专门针对医院存在多个信 息系统时实现系统间相互通信与数据交换的 HL7 引擎系统，使多种通讯协议之间路由、在多种 格式之间转换，将业务服务重新组合封装成标准行为，实现**医院各类业务系统的标准化集成。

4.2.3 医院信息平台资源层

医院信息平台资源层用于整个平台各类数据的存储、处理和管理，主要包括:临床数据中 心、运营数据中心、知识库、规则库、术语库等。

在**医院本次集成平台建设项目中，基于统筹规划，分布实施的原则，考虑到集成平台建 设成本和建设的复杂性，本期首先设计医院信息集成平台总体架构，包含平台资源层在平台架 构框架设计中的位置，该层中的相关功能在医院本期完成交换层和服务层相关内容后，进行相 关应用建设。

4.2.4 医院信息平台服务层

医院信息平台服务层的主要任务是为平台提供各种服务，包括患者主索引、统一代码字典 库、术语及主数据管理、基于平台的医院业务流程再造等。

通过建立统一代码字典库，为数据中心的字典数据管理提供了统一的方式，同时为实现术 语与主数据管理(STM)，对院内各系统中的基础数据进行统一管理，建立准确、完整、一致 的数据，实现数据统一标准化实现提供标准支撑。建立患者主索引系统 EMPI，实现全院范围

内患者交叉索引的统一集中管理，为建立以患者为中心的临床视图打下基础。除此之外集成平 台还提供实时监控功能，对于通过平台的每个数据流，平台都会进行实时监控并记录数据流的 每个节点内容，如果在数据交换的过程中出现问题，系统会通过邮件、短信等方式发送给管理 人员，管理人员可以根据系统的提示，立即定位到问题节点，及时进行处理。

4.2.5 医院信息平台应用层

医院信息平台应用层基于医院信息平台，通过基础业务数据的交换、共享和整合，结合医 院实际业务和管理需要，建立扩展应用。主要包括临床门户、公众服务系统、决策支持系统等。

基于统筹规划，分布实施的原则，考虑到集成平台建设成本和建设的复杂性，本期**医院 集成平台建设着重于医院信息集成平台总体架构设计和基础型建设，平台应用层相关内容本期 暂不建设，但已经包含在平台架构框架设计中，在完成相关内容建设后，进行集成平台应用层 相关应用建设。

4.3 主要建设内容

4.3.1 集成平台交换管理

4.3.1.1 集成引擎中间件

一、 运行平台

中间件平台不是一个单独的概念，它是由多个部件及节点共同完成系统整合的要求。 包括管理平台、监控平台和集成引擎。启动引擎会同时触发管理和监控平台，共同提供服 务。而开发平台则从微软操作系统中另外起动。 集成引擎可安装运行于在各种主流操作系统上，并同时支持 32 及 64 位操作平台，包括:

IBM AIX®, 5.x, 6.x
HP-UX, 11+ (PA-RISC/信息 anium)
Linux® (x86/x64)
Sun Solaris 9 (SPARC)
Microsoft ®Windows ® 2003 Server (x86/x64) 微软 2003 服务器版 

Microsoft ®Windows ® 2008 Server (x86/x64) 微软 2008 服务器版

二、 可视化集成开发环境 ⚫ 可视化开发

集成开发环境是一个基于微软视窗操作系统的图形化设置及设计工具。它连接并 指引引擎展开各项运行处理工作。集成开发环境基于视窗操作系统的特性使它有良好 并直观的图形配置界面方便设计师对通讯点、过滤器及路由进行设置。

集成开发环境(IDE)是构成集成平台的关键节点。基于引擎的所有功能都是通过 IDE进行配置的，而这种配置是非常直观、图形化、拖放可视化及拥有友好用户界面 。

 

如您所见，集成开发环境不需要经历长时间的培训即可掌握而对随后的故障及困 难排除也非常容易。这种直观的界面对认识后台数据包的流向得益匪浅。

⚫ 代码开发
集成开发环境(IDE)支持 Java 编程语言，提供 API 应用程序编程接口，可让用户

自行开发基于 Java 编程语言的通讯点及过滤器。 同时，对于标准的通讯点和过滤器则使用 JavaScript 语言提供灵活的开发、测试

及集成的处理及支持。

⚫ 图形化与代码的相互转换
在集成开发环境里，基于 JavaScript 语言的所有通讯点及过滤器都能很方便地进

行图形化与代码或代码与图形化的转换。特别在 XML 功能上，所有在图形化界面(GUI) 的配置都能被准确地输出为 XML 格式文件，反之亦可。

三、 登录授权控制

系统将用户名和密码都以加密形式保存在内置数据库中，当管理员或设计人员登 录平台进行管理时，系统通过吻合访问控制表的方式授权登录。

四、 信息安全

为提高应用系统系统安全性需要进行一系列的加固措施，支持X.509数字证书技 术对平台全面的数字证书服务，完善的密码等敏感数据管理机制，能够对任何敏感的 消息进行加密及审计跟踪与节点验证，同时被授权的接收端能够高效的对这些信息进 行解密，包括DES、AES、SHA-1、MD5等。

 

五、 数据转换

通过自动映射工具和拖放字段映射，使得系统与系统之间快速转换数据。同时在 进行配置更改时不影响引擎的后台工作，这意味着后台可以不间断的处理信息，直到 嵌入了最新的配置后，引擎直接按照最新命令进行信息处理。

 

六、 数据连接

对大量的协议和标准提供本地支持，从旧系统(如 Z-Modem)到网络服务标准(如 SOAP)以及中间的所有内容(XML、HL7、X.12、NCPDP、DICOM 等)。 支持将网络服务呼叫映射到应用程序的特定命令，从而实现任何传统应用程序网络化。

七、 确保传输

医疗环境不能出现信息以及数据包的丢失，因此对于错误信息采用缓存机制，确 保信息及时恢复，同时 HL7 确认协议的嵌入式支持使得无应答系统也能得到多层保 护，并且具有高性能和可扩展性。
八、 定制格式

医疗界面还暂时没有一个统一的集成标准。Rhapsody 强大的 EDI 设计软件提供 专用工具对标准信息(HL7、X.12 等)进行本地化修改，或者配置定制格式如逗号分隔 文件格式(CSV)、不可变宽度和其他对限定有严格规定的文件格式。
九、 接口适配器

  接口通过通讯点、路由、过滤器构建连接起来:

⚫ 通讯点 通讯点是内外关键接口适配器。它可以被设置成输入、输出或双模式。每个通讯

　　点是实施不同协议以连接不同系统的节点。

⚫ 路由 路由是由多个通讯点及过滤器组成的通路或路径。数据包会按照路由指定的方向

　　流动，配合接口适配器，达到传输信息的目的。通常路由会由输入模式流向输出模式 的通讯点。

⚫ 过滤器 过滤器可以被认为是另外一种接口适配器，它可以让管理员或分析人员对流动的

　　数据包进行整理、归类、提取、删除、过滤、检验及开发。另外，过滤器也支持 JavaScript，提供更多更灵活的数据接口处理。

十、 简化标准支持

 目前医院上线系统由不同厂商提供，各个系统采用的架构不同、技术不同，所能

提供的接口也不一样，所以进行集成时需要支持多种通讯协议和标准，目前支持的标 准协议如下:
支持 TCP、FTP、HTTP、HTTPS、MLLP 网络服务等标准协议;
支持 HL7(版本 2.X);

支持临床文档架构(CDA);
支持 DICOM 图像格式转换及应用; 支持医用信息系统集成(IHE)配置文件。

十一、 集成测试环境

嵌入、嵌出式(check in/check out)的测试环境使系统管理员能把引擎和当前集成 开发环境(IDE)的配置分离开来，他们可以配置及改变集成开发环境(IDE)而不影响引 擎的后台工作。这意味着引擎能不间断地处理信息。直到集成开发环境(IDE)嵌入了最 新的配置，引擎才会按照最新的命令进行处理。

同时 IDE 也带有自己集成的测试环境，每一个通讯点或过滤器在应用时都会通过对比 /测试其语法或逻辑错误。直到没有任何错误才会放行正确的路由。

另外，Orion Health 根据长时间在 HL7 框架内操作的经验，在 Rhapsody 集成平台开 发了对于 HL7 全系列的字库支持。消息设计师只需提供标准或自定义 HL7 的要求，Rhapsody 内的 EDI 设计工具就能提供嵌入及整合服务，让此流程实施到整个平台里。由此最大化 Rhapsody 的价值

十二、 实时在线监控

监控平台与管理平台都可以通过web浏览器进行访问，对平台所有服务数据、消 息路由情况、性能数据等进行监控，通过监控平台提供给系统管理员作为参考。

 

4.3.1.2 业务系统集成

本期业务系统集成需要接入的医院信息系统主要包括医院的 HIS、LIS、RIS/PACS、EMR 等。

医院信息平台，通过平台对信息标准、交换原则的统一定制，为各业务系统提供标准统一 的信息交换服务，用以规范统一标准解决各业务系统的集成需求。促使医院经历了多年发展的 财务、药品、临床等部门的信息系统，实现标准化业务集成，初步实现系统之间的数据标准化 交换功能。同时，当医院信息化建设的不断发展，医院内的系统越来越多，系统间的数据交换 也越来越频繁时，实现标准化的统一集成和管理。

考虑到院内各系统的架构、数据类型、存储方式、文件形式等多样性的数据，需要平台支 持多种数据采集集成技术，因此集成方面可提供以下几种集成模式。

4.3.1.2.1 基于 HL7 标准集成

由于 HL7 是当前国际上医院信息交换的标准，因此集成平台首先应支持基于 HL7 标准的信 息交互。

考虑到系统间的异步通信以及各种消息类型，我们采用发布/订阅消息模式，HL7 消息交互 流程如下图:

 

一、发送方在业务节点触发后，如果需要把业务信息传递给其它系统，按照集成规范定义 的 HL7 消息格式，对相应的业务内容进行 HL7 消息封装;

二、发送方将封装好的 HL7 消息发送给消息引擎; 三、消息引擎在接收消息后按照通道配置情况，把消息分发到指定的系统; 四、各系统在收到发来的消息后，由接收方发送一条处理结果应答消息给消息引擎; 五、接收方解析消息内容，对收到的消息进行相关的业务处理。

所有与平台对接的系统都需支持 HL7 消息，通过平台的集成引擎中间件实现以下功能: ◼ 路由与分发

根据各个系统的业务需要，分别订阅各 HL7 消息。通过中间件路由功能将 HL7 消息分发给 各个已订阅的系统。同时根据业务的需要平台做出可以返回各种消息的应答消息。

 

 

 

◼ 消息映射与转换
基于 HL7 消息的各个版本格式的不同，同时为了能将个各个版本的 HL 消息进行互通。中

间件给出了完美的解决方法。能够根据需要将各种消息进行相互映射，提供了非常简单且易操 作的映射工具。以使得消息的转换与映射的工作非常方便与快捷。

4.3.1.2.1.1. 集成 HIS 系统

设计 HIS 接口规范，实现 HIS(包括门诊系统、住院系统、药品管理系统等)集成:将检 查、检验申请通过集成平台发送相应系统，接收其它系统发送的检查、检验确认消息，接收检 验、检查结果;调用检验和检查报告展现工具;将病人就诊记录(如门诊处方、门诊病例、检 查、检查、治疗申请单、门诊费用、住院医嘱、护理记录等)存储到业务库中。

◼ 入院登记:
HIS 系统生成 HL7 的 A01 类型的消息，从消息中获取患者的登记信息，在目的系统中对患

者登记信息进行录入等操作。 ◼ 患者出院:

HIS 系统生成 HL7 的 A03 类型的消息，从消息中获取患者的出院信息，在目的系统中对患 者出院信息进行更新等操作。
◼ 患者取消出院:

HIS 系统生成 HL7 的 A13 类型的消息，从消息中获取患者的取消出院信息，在目的系统中 对患者出院信息进行更新等操作。
◼ 门诊挂号:

HIS 系统生成 HL7 的 A04 类型的消息，从消息中获取患者的挂号等信息，在目的系统中对 患者挂号信息进行更新等操作。
◼ 患者信息更新:

HIS 系统生成 HL7 的 A08 类型的消息，从消息中获取患者的个人信息，在目的系统中对患 者信息进行更新等操作。
◼ 医嘱消息:

HIS 系统生成 HL7 的 ORMO01 类型的消息，从消息中获取患者的医嘱信息，在目的系统中 对患者医嘱信息进行更新等操作。
◼ 涉及的其他业务集成。

4.3.1.2.1.2. 集成 RIS/PACS 系统

设计 RIS 接口规范，实现 RIS/PACS(包括放射、超声、内镜、病理等)集成:接受其它应 用系统的检查申请或取消申请并发给 RIS/PACS 系统;将 RIS/PACS 系统的检查确认消息发送到 相应系统;将生成的检查结果通过集成平台发送到相应系统并存储到标准业务库中;提供集成 平台调用展现检查报告的 API，供其它系统使用。执行后，RIS/PACS 系统负责建立报告单与申 请单的关联关系，并把检查文字报告发送到集成平台。

◼ 入院登记:
该系统接收 HL7 的 A01 类型的消息，从消息中获取患者的登记信息，在目的系统中对患者

登记信息进行录入等操作。 ◼ 门诊挂号:

该系统接收 HL7 的 A04 类型的消息，从消息中获取患者的挂号等信息，在目的系统中对患 者挂号信息进行更新等操作。
◼ 医嘱消息:

RIS 系统生成 HL7 的 ORMO01 类型的消息，从消息中获取患者的医嘱信息，在目的系统中 对患者医嘱信息进行新增或更新等操作。
◼ 报告消息:

RIS 系统生成 HL7 的 ORUR01 类型的消息，从消息中获取患者的报告信息，在目的系统中 对患者报告信息进行增加或更新等操作。
◼ 涉及的其他业务集成。

4.3.1.2.1.3. 集成 LIS 系统

设计 LIS 接口规范，实现 LIS 集成:接受其它应用系统的检验申请或取消申请并发给 LIS 系 统;将 LIS 系统的检验确认消息发送到相应系统;将生成的检验结果通过集成平台发送到相应 系统并存储到业务库中;提供集成平台调用展现检验报告的 API，供其它系统使用。
◼ 入院登记:

该系统接收 HL7 的 A01 类型的消息，从消息中获取患者的登记信息，在目的系统中对患者 登记信息进行录入等操作。
◼ 门诊挂号:

该系统接受 HL7 的 A04 类型的消息，从消息中获取患者的挂号等信息，在目的系统中对患 者挂号信息进行更新等操作。

◼ 医嘱消息:
LIS 系统生成 HL7 的 ORMO01 类型的消息，从消息中获取患者的医嘱信息，在目的系统中

对患者医嘱信息进行更新等操作。 ◼ 报告消息:

LIS 系统生成 HL7 的 ORUR01 类型的消息，从消息中获取患者的报告信息，在目的系统中 对患者报告信息进行增加或更新等操作。
◼ 涉及的其他业务集成。

4.3.1.2.1.4. 集成 EMR 系统

◼ 入院登记:
该系统接收 HL7 的 A01 类型的消息，从消息中获取患者的登记信息，在目的系统中对患者

登记信息进行录入等操作。 ◼ 患者出院:

该系统接收 HL7 的 A03 类型的消息，从消息中获取患者的出院信息，在目的系统中对患者 出院信息进行更新等操作。
◼ 患者取消出院:

该系统生成 HL7 的 A13 类型的消息，从消息中获取患者的取消出院信息，在目的系统中对 患者出院信息进行更新等操作。
◼ 患者信息更新:

该系统接收 HL7 的 A08 类型的消息，从消息中获取患者的个人信息，对患者信息进行更新 等操作。

◼ 医嘱消息:
该系统接收 HL7 的 ORMO01 类型的消息，从消息中获取患者的医嘱信息，对患者医嘱信

息进行新增或更新等操作。 ◼ 涉及的其他业务集成。

4.3.1.2.1.5. 其他系统集成

其他系统，如医生工作站、手术麻醉等综合采用上述各种集成方式，实现与集成平台其他 系统的业务集成。

4.3.1.2.2 基于 Web Service 集成

医院信息平台支持 WebService 的集成服务模式，以面向服务架构的方式进行医院信息系 统的集成，医院信息系统可以通过平台进行交互，而不需要使用底层协议和自定义的编程接口， 只需以服务的形式来规定系统如何与其他系统进行通信，选择与该服务交互的其他系统，发现 服务，并在运行和设计时与这些服务绑定。这种模式使得系统具有了跨平台、跨操作系统、跨 网络等特点，同时也使得整个系统集成具有广泛的适应性，可以使跨系统的业务处理更加自动

化，相对容易实现跨系统的互操作性。 对现有的异构信息系统，无论是否符合标准，都利用web service提供统一的接口，只要

把业务逻辑封装成为 WebService，就可以让任何指定的合作伙伴调用这些业务逻辑，能够方便 的实现消息的构建、解析和传输，实现系统间的数据交换。

 

一、发送方在业务节点触发后，如果需要把业务信息传递给其它系统，按照集成规范定义 的 XML 消息格式，对相应的业务内容进行 XML 消息封装;

二、发送方将封装好的 XML 消息发送给消息引擎; 三、消息引擎在接收消息后按照通道配置情况，把消息分发到指定的系统; 四、由接收方发送一条处理结果应答消息给消息引擎; 五、各系统在收到发来的消息后，解析消息内容，对收到的消息进行相关的业务处理。