内容导读
近年来，在电子病历应用水平评级要求以及医院在不同业务间实现协同等多种因素的推动下，集成平台成为各大型医院信息化建设中重点的项目。
“医疗信息系统集成”并不是一个全新的词汇，早在十几年前就已经在医院信息化的浪潮中初露端倪，也有一些敢于“吃螃蟹”的医院开始尝试建设自己的集成平台。这些年，在国家卫健委的互联互通标准化测评推动下，集成平台作为参评的“必要条件”进入众多医院信息化建设的优先发展名单，经过了行业化的不断论证和实践，取得了飞跃式的发展。
对于集成平台，很多HIT行业领域的专家人士都有精辟独到的见解。本系列文章会从我们公司集成平台的建设、过程、经验、应用、成果等五个部分展开，向大家分享我院一路走来的集成平台实践经验，希望能够为更多医院信息化同仁提供借鉴和些许参考。
本文将围绕医院集成平台的资源需求以及其对 IT 基础架构的要求展开讨论，并给出基于超融合架构的方案配置参考与传统架构的对比分析。
图：集成平台总体架构图
随着医院信息化建设的不断完善，医院逐步上线了 HIS、EMR、PACS、LIS 等多个业务系统。
由于这些业务系统由不同厂家开发，各个系统拥有不同的操作系统、数据库，进而导致不同业务系统之间需求调用复杂、接口数量多且无统一标准、数据交互效率低下、维护困难等问题。
集成平台的重要性在于，其不仅能够在各个系统之间实现统一集成和交互，同时为数据集成提供了可能。
通过将各个系统产生的数据集中存储并重新组织形成医院的数据仓库，集成平台为下一步数据分析创造条件，即充分挖掘数据价值进而形成一系列数字化应用支撑智能化决策，帮助医院实现真正数字化转型。可以说，集成平台是医院数字化转型的重要基础。
在部署集成平台时，医院需要清晰了解集成平台的架构，从平台的实际需求出发，并结合医院资源池建设的整体规划，为集成平台选择合适的基础架构。
医院集成平台的实现方案有很多种，早期以接口调用集成方案为主，但这种方案集成效率较低，后期逐渐转向企业服务总线（ESB）为主要框架。
可根据客户的请求和事件提供路由，数据转换、翻译等服务。
具有快速、并行的消息处理能力。
无法保证消息或服务请求的顺序，而医院业务之间调用大多有严格处理顺序要求。
不支持国际医疗标准，不利于医疗数据上报、医疗机构之间的数据交互。
ESB 引入消息队列软件处理服务请求顺序的问题、改造 ESB 支持医疗标准协议等方案虽然在一定程度上实现了 ESB 的优化，但存在方案极其复杂，开发难度过大，成本过高等问题，可见在集成平台建设中，单凭 ESB 软件是无法完全满足业务的需求。
经过多年的发展与试错，医院集成平台逐步形成了以 ESB（企业服务总线）、IE（集成引擎）、ETL 工具三种技术组合而成的搭建方案。
如上图所示，集成平台的集成工作主要包括两个部分：应用集成和数据集成。
应用集成主要实现各个业务系统之间的请求和调用，由 ESB 和 IE（集成引擎）两部分组成；其中 ESB 负责同步数据处理操作，IE 集成引擎负责异步数据处理。
ESB 充分发挥并行处理优势，实时、高效地处理系统之间的请求。
IE 集成引擎支持以 HL7、CDA 等国际医疗标准协议交互，提供消息异步处理机制，解决重视次序的服务调用需求。
国内集成平台常用的集成引擎方案如下表所示。可以看出，国内的集成平台厂商大多采用国外成熟的 ESB 企业服务总线产品/集成引擎产品。
常见 ESB/集成引擎 产品的系统要求和数据库支持情况如下：
数据集成主要任务是将医院各个系统所产生的数据集中，清洗，并以新的组织结构进行存储，形成医院数据仓库，以便后续对数据进行分析，挖掘和利用。
ETL 是 extract-transform-load 三个数据处理过程的缩写：
数据抽取（Extract）：连接各个业务系统数据库，抽取数据库日志和事务数据。
数据转换（Transform）：抽取数据后，对数据进行验证、清洗、根据规则执行转换。
数据加载（Load）：将处理好的数据加载到目标数据库。
理论上， ETL 工具可从生产业务系统的数据库直接抽取数据并转换数据，但这种方式会对生产数据库带来较大压力，直接影响业务系统响应速度。为了解决这个问题， ETL 过程会先将数据完封不动地抽取到中间数据库（临时库），数据转换、数据加载都会发生在临时库中，以最大程度上降低对生产数据库的影响。
量体裁衣，平台运行环境和架构是什么？
集成平台运行在vSphere虚拟化集群环境，虚拟化集群由6台X86架构的华为RH5885服务器和一套CHANGHONG CNX400 2存储组成。逻辑主机的配置为windows server 2008 R2 64位，64G内存，E7-4830四核四处理器，500G的磁盘空间。常态情况的CPU利用率为20%，内存平均利用率为70%左右。从硬件运行环境而言，集成平台不需要非常高的硬件配置，其对内存消耗比较大，主要是缓存线程的使用。
图：集成平台服务器内存使用率
集成平台的核心技术架构是ESB(Enterprise Service Bus的简称，中文翻译为企业服务总线)。在这里，我们把企业服务总线在医疗卫生行业内特定的实现称之HSB(健康服务总线,Health Service Bus),这些特定的实现包括了医疗行业特殊的协议和标准，例如：信息交换标准HL7,医学数字成像和通信标准DICOM等。
我司集成平台采用基于电子病历的医院信息平台进行各系统间的业务及数据集成，主要通过服务总线(DHC-ESB)完成系统间的业务协同，通过主数据管理（DHC-MDM）完成数据标准的管理，通过临床数据中心（CDR）完成数据的整合。
图：集成平台总体架构图
我院集成平台的内部架构采用的是InterSystems Ensemble，HSB是其运行的逻辑架构，InterSystems Ensemble平台的内部架构如图所示：
图：Ensemble平台的内部架构
Ensemble的内部架构由三个主要的构件组成，分别是：BS、BP、BO。
业务服务（BusinessService）简称BS，是Ensemble中所有外部请求/外部数据的入口。Ensemble中内置了多种常用的导入型适配器供开发人员在BS中直接使用，其中包括并不限于SOAP、SQL、HTTP、File、FTP、HL7等。
业务流程（BusinessProcess）简称BP，是Ensemble中的业务处理模块，在BP中可以实现数据转换、数值对照以及根据规则引擎做出的消息分发等功能，BP是Ensemble的中枢，由各种不同类型BS进入的数据，经过BP的处理，最终通过各种不同类型的BO流出Ensemble。
业务操作（BusinessOperation）简称BO，是Ensemble对外发送请求或数据的出口，Ensemble中内置了多种常用的导出型适配器（OutboundAdapter）供开发人员在BO中直接使用，其中包括并不限于SOAP、SQL、HTTP、File、FTP、HL7等。
通过打开Ensemble的消息路径图，我们可以监测每一条消息的运行状态和路径，通过此图，我们可以一目了然的看到消息是如何在平台内部运行的。
图：Ensemble的消息路径图
3.集成平台能做什么？
集成平台基于SOA（Service-Oriented Architecture，面向服务的架构），无侵入式设计，不改变现有信息系统的运行，由集成平台完成各类业务数据的采集、转发、解析、存储和使用管理。集成平台管理层提供业务日志、事件日志、业务规则日志、端到端的消息跟踪业务监控功能，实现在开发阶段的有效调试以及运行期间的故障诊断分析，利用集成平台的故障可追溯机制，管理员可快速定位导致异常的环节。
图：标准字典维护模块
图：基于HL7的标准文档CDA
图：消息日志
通过集成平台，其他业务系统可以很容易的对接到集成平台的业务流程中来，通过集成平台的数据集成和业务集成，各个系统继承已有的数据和服务，降低了各个子系统之间的高耦合性。
4.集成平台是如何实现业务互通的？
集成平台通过Ensemble的“注册－发布－访问”机制对医院信息平台各种共享服务资源进行注册与发布，从而实现服务资源共享及粗粒度应用服务之间的互操作。其核心是建立基于消息引擎的院内集成平台服务总线(HSB)，通过基于SOAP（Simple Object Access Protocol，简单对象访问协议）的WebServices、HL7消息等将各系统与业务系统(HIS、EMR、PACS等)对接，并实现患者就医流程的闭环处理。第三方系统通过集成平台获取所需信息并将回传信息返回给集成平台。
当某个业务需要某个应用程序将数据发送给另一个方应用时，由该程序向平台发送一个消息，经过平台对消息进行接收和处理(BS中定义)，按照平台预先设计好的消息流程(BP中定义)，调用目标系统的服务，通过此服务将消息内容写入目标业务系统中。在此过程中，业务系统不需要考虑目标系统的数据结构是否与自己一致，也不需要链接对方的数据库（比如采用视图，存储过程的方式调用目标系统）。只需要将消息发送给平台，再由平台完成后续的流程。平台的BO能通过输出适配器，API，或者其他方式来访问Ensemble外部应用。
图：集成平台内部业务流程处理
5.集成平台的主要作用
总体而言，集成平台主要解决了以下几个问题:
第一：兼容多个异构系统，并快速进行对接，使各个业务系统之间的数据可以交互。
第二：通过平台交互，统一患者就诊档案。
第三：以集成平台为基础，可逐步建立区域级的信息平台,从而使发展区域医疗，集团化医院有了技术上的保证。
第四：同时，能够采集海量的临床数据，为医院的教学科研工作奠定基础。
