随着医院信息化建设的不断深入发展，国际国内的医院信息化建设正朝着数字化、区域化方向发展。在美国、加拿大、英国等国家都已开始了区域医疗信息整合和共享系统的建设。在国内，区域医疗信息系统的建设也越来受到业界关注和重视。随着以财务结算为中心的医院管理信息系统（HMIS）、以临床业务为中心的临床信息系统（HCIS）的逐步完成，建设以临床信息共享为特征的区域信息系统（GMIS）已成为目前国内医院信息化发展的必然趋势。

2006年上海申康医院发展中心在借鉴新加坡和我国香港经验的基础上，结合上海实际，提出了建立市级医院临床信息服务共享系统项目，即“医联工程”，借此推进医院信息化建设、实现信息共享，以此减少医疗资源浪费，提升医疗质量和效率，从而合理控制医疗费用，提高办医质量和效率。

项目目标

“医联工程”的建设目标可以概括为一平台（实现医院之间临床信息共享平台），一库（包括基本临床和管理信息的中心数据库），一网（连接各个医院的网络），一卡（可在所属市级医院通用的就医卡），一站（一个对外公众服务门户网站），两个辅助决策系统（临床医疗辅助决策系统和医院管理辅助决策系统）。

项目总体架构

医联工程架总体架构如图1所示，其中数据交换平台是为医联中心和各医院部署的统一数据交换平台产品，它将实现医院与医联中心、内外网、以及医联系统与其它外部系统之间的数据交换。

数据交换平台的建设是整个医联项目的关键所在，它是整个医联项目中最基础、最重要的信息平台，该信息共享平台的建设的好坏将直接影响到医联项目的成败，故而该平台的选择非常重要。

数据交换需求分析

1. 数据交换场景分析

（1）中心端交换场景

中心端请求医院端服务：在这种场景下，中心端向医院端发起服务调用的请求，当医院端接收到此服务请求后进入医院端的服务处理程序，在医院端的服务处理程序执行完服务后，则把服务结果信息作为回复的消息反馈给中心端。

中心端采集医院端数据：中心端因决策支持需要，会从医院端采集必要的信息。采集分为两种方式，一种是中心端按照需求制定采集规则以主动的方式从医院端的前置库抓取数据，另外一种是由医院端按要求采集需求的数据以主动的方式把数据送交给中心端。

（2）医院端交换场景

医院通过中心请求其它医院服务：医院间的数据交换多数是医院因协作为患者提供更好的医疗服务而发生的，例如：转院预约、院间调档等，这些交换通常是由服务的请求医院向被请求医院发起一次数据交换。

医院直接请求其它医院服务：在中心端提供的服务不可用或者为了降低网络压力的情况下，医院端将直接请求其它医院的服务。

数据即时报送医联数据交换中心：医院对患者的实验室检查结果以及住院病案报告需要以即时方式上报给医联交换中心。

数据定期报送医联数据交换中心：医院的一些医疗资源信息，特别是医生和大型设备信息需要定期报送给医联数据交换中心。

2. 数据交换内容分析

医联项目中需要从各医院采集的数据大致可以分为临床类信息和医院管理类信息，这两类信息将通过数据交换平台来实现数据交换。目前临床信息共享交换的主要内容有：实验室化验检查报告，医学影像检查图像及报告，住院病案首页，就诊患者基本信息，就诊患者就诊日志信息等；医院管理类采集数据内容为：医疗服务费用信息，大型设备使用信息和医院财务管理信息等。

3. 数据交换功能需求分析

从服务的角度来看，在中心端必须具备消息传输、数据整合、服务集成和流程驱动的功能。从管理的角度看，中心端必须具备一定的管理功能，这些管理功能为客户端的接入、交换的数据标准、各种业务规则等。

而接入端节点主要功能是完成消息的收发及对消息中数据的处理功能，因此从功能角度来看在接入端需要部署消息传输和数据整合两个模块。其功能和中心端的功能基本相同。

（1）消息传输

以消息的机制建立接入端和中心端的数据传输通道可以较好的满足应用对于交换的各类需求，例如：异步的数据交换需要、可靠的数据传递等。因为中心端一方面连接了接入端，另一方面还有外部系统连接的任务，因此消息传输的实现目标必须在能够实现各类的不同的系统间的信息通讯。

（2）数据整合

中心端的管理和决策支持的应用需要以格式规整和高质量的基础数据作为支撑。而这些数据通常是由接入的各个医院来提供的，但各医院能够提供的数据在结构和质量方面存在较大的差异，通过采用数据整合可以收集、整理数据，为决策支持提供数据服务。

（3）服务集成

就中心端而言，服务集成必须满足：支持对于webservice的集成，中心端采用统一的服务调用接口完成对医院提供的服务调用，支持对于服务请求和反馈的日志功能。

（4）流程整合

当中心节点连接了医院和其他外部系统后，有些信息的处理可能需要一个较为复杂的过程控制，在这种过程中需要把多种数据的处理操作按照某些业务规则连接起来，实现业务规则的可视化建模和业务过程的可视化运行监控。

（5）管理功能

中心端负责外部系统、医院等的大多数数据交换，接入节点的数量比较多，而每一家单位能够提供的医疗服务和信息资源也存在不小的差异，因此必须管理和组织好这些交换的节点，使得交换可以有效、可靠的运行。

数据交换产品选型分析

1. 选型原则

根据数据交换需求分析结果，数据交换平台产品选型应遵循以下原则：

（1）开放性原则

允许异构软件平台的系统接入；允许多种类型的接入（医院、医院集团、医联联盟）；按照开放性原则集成各类软硬件产品；按照行业公认的集成规范建立与联盟接入点的关系。

（2）灵活性原则

提高多种前端数据采集方式；提供本地代码设置转换、校验功能，便于整合现有各信息系统数据集。

（3）可扩展性原则

支持HL7数据集，便于以后对信息系统数据集的扩展。

2. 选型因素

数据交换平台是医联系统中最核心的平台之一，整个系统的数据交换主要依赖于该平台，它的功能和性能将直接影响到整个系统的功能和性能，因此，选择数据交换平台产品，不仅需要从技术、功能和性能等方面进行考量，还需要从诸如产品成熟程度、可扩展性、厂家后续本地化的支持力度等方面进行考量。具体包括以下8个方面：数据传输是否安全可靠；是否支持对HL7数据集的集成；是否具备多种部署方式的能力；是否符合技术发展方向；是否支持业界主流产品，如：中间件、数据库；在国内是否具有较强的技术支持和售后服务能力；是否有区域医疗交换共享成功案例；是否符合医联系统功能需求及发展方向。

3. 选型产品比较

目前提供主流数据交换产品的厂商主要有四家，分别为：Oracle、IBM、SUN和BEA，其产品性能和特性分别如下。

（1）OracleHTB（HealthTransaction Base）
● 医院端部署通用接口服务器，提供多种方式用于数据传输。
● 数据在中心进行格式转换，数据上传下载都以非标数据进行传输。
● 没有参考XDS架构。
● 必须采用HL7标准。
● 中心数据库设计采用RMIM，数据存储符合HL7V3标准。
● 融合了医疗行业的安全机制。
● 集成商对RMIM的学习成本比较高，且必要性也有待考虑。
● 只能使用OracleDB和J2EE应用服务器。

（2）IBMIHI（InteroperableHealthcareInformationInfrastructure）
● IHI I遵循IHE规范，实现了注册、存储、安全和PIX。
● IHII是跨区域医疗行业解决方案，用于信息共享交换。
● 要求上传数据已经是满足HL7V3的标准。
● 总体参照IHEXDS框架。
● 输入数据必须采用HL7格式，一般与HBI配合使用。

（3）SUNCAPS（CompositeApplicationPlatformSuite）
● 基于ESB（Enterprise ServiceBus）的解决方案。
● 支持HL7数据集，且支持本地客户化。
● 部署方式灵活，在不增加成本的前提下支持多种模式，即：集中式、分布式、混和式。
● 与总体设计发展思路比较融合。
● 开放性比较好，可以在多种主流中间件上运行，如：BeaWebLogic、IBMWebsphere等。
● 有较多区域医疗信息共享案例，如：澳大利亚、英国。

（4）BEAALSB（Aqua LogicServiceBus）
● 是一个纯ESB产品，且是该类产品的领跑者。
● 提供内核级中文版产品，不是简单的产品汉化。
● 作为数据交换产品案例较多。
● 不提供对HL7数据集的支持。
● 医疗行业案例不多。

（5）数据交换产品选型结果
● BeaALSB：无内置行业标准，影响系统扩展性。
● IBMIHII：产品使用的环境尚不具备，实施成本太高。
● OracleHTB：局限于HL7标准，无法兼容IHE构架。
● SunCAPS：符合项目系统架构设计及功能需求。

4. 选型结果

通过对以上不同产品的分析，综合各方面的因素，结合项目系统架构和功能需求，最终选择了SunCaps作为医联项目数据交换平台产品，SunCaps具有以下优势。
● 基于Java开发，属于ESB产品，开放性好。
● 医院端数据采集比较灵活，可以自主完成，也可以与第三方产品结合，且都能实现数据的可靠传输。
● 数据转换方式在不增加成本的前提下支持多种模式， 即： 中心转换、采集点转换、中心/采集点组合转换。
● 产品支持多种主流关系型数据库。
● 在国外区域医疗行业成功案例较多， 如： 英国NHS、澳大利亚。
● 技术支持、售后服务能力较强。数据交换平台的建设是整个医联项目的关键所在，它关系到整个医联项目建设的成败，故对该平台的选择尤其重要。