医院信息集成平台建设方案

1、信息集成平台建设方案1 建设需求一个完善的医院信息系统通常由上百个子系统组成，牵涉众多的专业领域。这么庞大的系统需要非常专业化的软件开发分工， 整合不同厂商有特色的专业系统是医院信息系统的发展趋势， 医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。 然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家， 基于不同的技术， 缺乏统一的信息交换标准， 这些系统的集成整合已经逐渐成为医院数字化发展亟待解决的主要问题。系统集成平台的构建主要面向两个核心问题： 一个是为各种医疗应用提供统一的医疗数据访问服务， 从而消除各种医疗应用系统与医疗数据中心的直接耦合性； 另一个

2、是为各种临床信息系统提供系统集成服务， 系统集成服务基于系统集成模型，通过HL7和DICO琳标准通讯协议为各种医疗应用系统提供集成服务，确保各个临床信息系统在工作流整合的基础上实现交互协作， 从而以数字化的形式完成各项医疗业务。2 建设目标系统间的整合、 集成和扩展一直都是制约医院数字化发展的主要障碍， 由于不同厂商之间的产品不兼容， 使得医院整体信息化步履维艰。 通过建设一个规范的系统集成平台，在IHE、DICOM HL7等国际标准的基础上，制定覆盖医疗所有业务流程的系统集成规范， 开发基于规范的系统集成平台， 为遗留的、 当前的以及将来的系统提供了一个统一且标准的数据交换和工作流协同的平台

3、。3 信息集成方法信息集成方法有三，即应用集成、数据集成、界面集成，这三种集成方式各解决不同方面的问题。 应用集成指应用程序之间实时或异步交换信息和相互调用功能，可以采用 HL7消息，WebService , CORBAEJB, DCOM RPC等标准，采用消息中间件，BPM等中间件实现；数据集成是指应用系统的数据库系统之间的数 据 交 换 和 共 享 ， 以 及 数 据 之 间 的 映 射 变 换 ， 常 采 用 ETL( Extract-Transform-Load ) 工具实现； 界面集成含义是应用程序界面之间相互关联引用合成，采用技术包括ActiveX 插件、 Portlet 、 IF

4、rame 等。协同应用从早期单纯的点对点接口方式， 发展到现如今的集成平台方式。 各种方式中：点对点接口方式的复杂性在于要和不同的系统建立1： N 的接口，假定有N个系统相互之间需要建立接口，则接口数为 N*(N-1)/2。集成平台方式中，在N 个系统需要进行应用协同的情况下，只需要开发N 个适配器接口即可，减少了集成平台的系统负荷。由于医院信息系统复杂性， 我们根据不同的需求和应用场景， 设计分别采用上述三种不同集成方法和手段进行信息集成。4 应用集成和医技辅诊科室信息系统(如 PACS/RIS LIS、MUS笥)的信息集成，这种场景， 信息交互的数据量不大， 实时性要求不高， 且各信息系统

5、各专业厂商实现方式相差较大，采用基于集成平台的应用集成方式是最优选择。集成平台体系结构如下图所示， 集成平台对外提供支持多种方式的集成服务：包括WebService服务、TC琳听服务、文彳监测服务、FTP服务、SQL监控服务/ ./ .、1、等方式。过程推动基于工业标准的医疗IT系统互操作性。在IHE中，消息传递采用的是HL7 (2.x版本)标准，影像传递采用DICOMS准。本集成平台的集成严格参照该规范进行：信息集成平台在进行消息时采用 HL72.4标准进行消息传递、在消息内部传递DICOM StudyUID以满足后续DICOMS像应用时的需要。临床信息集成用于对各临床信息系统进行信息层面的

6、集成事务处理。事务的定义参照IHE规范执行，消息的交互标准参照 HL7 2.4标准执行。集成平台内部引擎本身由Ensemble集成平台基础之上进行二次开发而来， 依才t Ensemble本身对各种适配器的支持，集成平台对外能够提供多种接入服务 方式：TCP文件夹监听、FTP文件监听、自定义WebService、SQL监听等形式。 以更多接入方式进行各种不同方式集成各业务系统。集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。集成引擎基于标准的业务流程执行语言(Business Process Execution Language)进行扩展应用，以描述交互应用。4.1 信息集成模块

7、与示例信息集成组件主要由以下几部分组成Business Service业务服务、BusinessProcess业务处理、Business Operation业务操作，这几部分共同作用下，将集 成事务与消息传递进行完成。其中，Business Service主要负责进行消息的监听与接收；Business Process负责全局的消息路由转发、事务流程处理、消息 匹配映射等工作职责；Business Operation负责将转换完成、最原子化的一个操作，发送/调用信息集成的目标端。同时在三者相互作用下，消息的反馈准确 的返回到Business Process ,由Process来讲反馈消息控制返回

8、到消息发送方。 示意图如下（后续对该示例进行说明）：4.1.1 业务服务监听与接收在当今医院中，存在各种各种的医疗业务系统，医疗业务系统的多样性，就 将导致与其集成时，接入方式的多样性，如部分系统已实现TCP的发送传递；部 分已实现文本输出等。集成平台作为医院信息系统的中转、适配角色，在接入方式的多样性成为必要条件。如前所述，在这方面，集成平台允许的接入方式有： TCP FILE、FTR SQL SOAP（WebService> HTTP MAIL等多种方式与相应的适 配器。在多种方式的接入过程中，将不同来源的消息通过统一的出口转交给业务处 理部分，由其进行路由住转发、消息匹配映射、业务

9、流程处理等相关的工作。在本示例中，EMRS!过 WebService的服务监听（BS.WS.EMRWST式将消 息内容传递进集成平台，在通过验证后，将该消息转发给了业务处理模块中的路由模块4.1.2 消息路由转发在一些应用场景中，如电子病历系统、重症监护系统、 HIS 系统三者进行信息传递时， 部分信息是需要三者之间交互的， 而部分信息仅仅需要两者之间交互，这在消息转发路由时，需要有一定的控制，起到闸门的作用。如： HIS 系统进行入院登记时， 需要将病人的信息发送到电子病历系统与重症监护系统； 而在重症 监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。因此，在集成平台中

10、，引入消息路由转发的相关模块就显得比较重要。在本示例中，EMRCTLRoute这个消息路由者在接受到 BS.WS.EMRWS消息 时，可能会转发至 EMRPlaceOrder EMROrderCABadMessageHandle三个相关的 处理模块。 而具体转发至何模块， 由消息头定义中的相关信息具体定义。 消息路 由者起到解析与转发的作用。4.1.3 事务业务流程处理即时消息路由已经正确路由转发了消息到准确的端点， 但是在对应的端点内，还会有一些业务流程需要进行处理。如在EMRSF达一个新的Order的时候，需要的一定的情况下产生不同的业务流程分支： 如该病人为门诊病人或者住院病人，则有必要

11、产生HL7消息中的住院病人登记信息与门诊病人登记信息：ADTA0WADTA04在本示例中，BPEMRPlaceOrde的内部业务流程如下，每一个结点代表着一 次逻辑处理过程：4.1.4 消息匹配映射在一些情况下，消息的传递方并无必要产生 HL7标准格式消息的情况下，如 EMRSf集成平台为内部互调时，双方之间提供预定义的 WebService的接口，以 快速的开发与进行集成。此时便需要在WebService中定义的消息格式与标准HL7消息格式之间进行 着匹配转换的工作。 而该转换工作的处理调用是由事务业务流程处理模块来发起调用的。4.1.5 终端消息发送在进行正确的消息格式转换与业务逻辑处理，

12、 此时的消息已经成为一个符合终端系统需要的消息格式。 在事务业务流程处理中， 会将此消息投递给相应的终端系统。在投递消息完成工， 事务业务流程处理模块会进入等待反馈的状况， 等待终端系统反馈一个应答消息， 以表示该消息在终端系统中被准确的处理。 事务处理模块收到该应答消息，并组织成发送端系统需要的消息格式，并作为应答系统，反馈至发送端系统。4.2 集成事务处理流程规划上述主要针对集成平台中各个模块作用于应用场景进行了阐述，下面将以IHE 规范中医嘱下达方医嘱执行的完整业务流程为例， 进行完整的集成事务流程描述。 该流程反应了普遍的医嘱流程， 多数院内的医嘱流程都可参照执行， 为医院的信息系统集

13、成方式提供良好的参考。本示例中，目标系统以 PAC效例。PACS上层应用程序集成平台新开申请单查询申请安排情况4I II住院病人：发送 ADA01消息/门诊病人：发送 ADTAA04消息响应ADTAA01消息/响应ADTAA04消息发送 PRMAO01 力肖息-(COntrOcOde=NW)响应ORMAO01消息对检查申请进行安排后，发送 SIUAS12消息响应SIUAS12消息通知收费系统进行收费查询申请检查信息查询申请检查报告开始检查日t,发送 ORMAO01 消息(control code=SC Order Status=SC)响应ORMAO01消息检查完成后，发送 ORMAO01 消息

14、(control code=SC Order Status=CM)响应ORMAO01消息有图像数据（图像匹配）后，发送1ORMAO01 消息(control code=SC Order Status=DA)响应ORMAO01消息发送DFTAP03消息响应DFTAP03消息报告完成后，发送 ORUAR01消息（OBX.11=P ,初步报告）响应ORMAO01消息J-查询申请检查报告报告审核后，发送 ORUAR01消息（OBX.11=F ,最终报告）响应ORMAO01消息另外，在院内经常出现的是在IHE规范中描述的：执行者医嘱流程，即由医 嘱执行者（PACS系统中，为检查科室）进行医嘱下达的过程并

15、执行的流程。如 下图所示：PACS发送ORMAO01(control code=SN)消息时，消息中必须包含病人号( PID.3 ),也就是说病人已经挂过号。上层应用程序集成平台PACS急诊检查登录时，发送 ORMAO01消息(control code=SN)发送响应 ORRAO02 消息(control code=NA)开始检查日发送 ORMAO01 消息(control code=SC Order Status=SC)响应ORMAO01消息检查完成后，发送 ORMAO01 消息(control code=SC Order Status=CM)响应ORMAO01消息发送DFTAP03消息 响

16、应DFTAP03消息i 1通知收费系统进行收费111 11 11 11111111查询检查信息Q:i)报告完成后，发送 ORUAR01消息(OBX.11=P,初步报告)口响应ORUAR01消息jj查询检查报告报告审核后，发送ORUAR01消息(OBX.11=F ,最终报告)响应ORUAR01消息查询申请检查报告更新或合并病人信息发送ADTAA08消息，更新病人信息/发送ADTAA40消息，合并病人号响应ADTAA08消息/响应ADTAA40消息5数据集成在实际业务应用中，日常医院的HIS库与ERMSI之间存在较多需要高频率、 高性能要求的交互，如计价信息与药品库存等信息的实时共享等。针对这样的

17、应 用场景，我们采用了 ETLX具(GoldenGate)在数据库底层进行的DB层同步方式。目前，医院已经存在比较完整的医疗信息系统，这些医疗信息是以JW1H系统为基础，增加医院自己的需求发展而来。ERMS电子病历系统是一个完整的独立产品， 他有他自己完整一套的系统架构和数据中心结构， 而在系统架构和数据 中心结构上医院现有医疗信息系统和EMRSI子病历系统都存在较大差异，这就决定了现有系统和EMRS子子病历系统很难共用一个数据库。可另外一方面，EMRS 电子病历系统和医院现有医疗信息系统都是医院系统不可分割的一部分， 他们即 有自己工作的重点，又有相互联系和配合，只有相互无间的结合，才能快速

18、、高 效和正确地完成日常工作。应用EMRSI子病历系统之后，医院现有医疗信息系统的主要工作就会变成传统意义上的HIS业务工作，如经济管理、人员管理和物资管理等，而EMRSI子病历系统主要完成以患者为中心的诊疗行为业务工作。两者之间存在着千丝万缕的关系，以医嘱业务举例，如EMRSt子病历系统下达、转抄和校对医嘱之后，医院现有医疗信息系统需要完成对应的业务操作，如医嘱摆药和医嘱收费操作等， 这就需要在这两个系统之间同步数据信息， 而涉及到同步的医疗业务往往涉及的医疗各个环节，如诊疗、药房、收费、人员管理等， 因此需要信息同步的数据量会比较大， 而同时为了不造成医疗业务的延迟和脱节，也需要很高的实时

19、性。在这种应用场景下已不适宜采用基于集成平台的， 通过消息交互的应用集成方式。 消息集成方式， 往往需要一个发起方和接受方， 而发起方和接受方往往需要一些额外的支持， 如发起方需要调用接受方提供的接口等， 期间可能还涉及到一些负责的来回交互， 最主要的是， 消息集成在数据量很大的情况下， 处理速度不是很快， 因此， 我们将通过数据集成的方式来实现数据同步， 数据库集成工具采用 Oracle GoldenGate 。医院涉及到需要数据同步的包括两个部分：HIS数据库和EMRSB据库。我们将采用GoldenGate实现HIS数据库数据和EMR嗷据库之间的数据双向同步其基本结构图如下图所示：HIS数

20、据库服务器GoldenGate双向复制从上图我们可以看到发生在HIS数据库上的相关数据变化通过GoldenGate实时同步到 EMRS数据库，而发生在EMRSR据库上的相关数据变化通过GoldenGate也会实时同步到EMR颔据库。其中具体的实现过程如下图所示：从上图我们可以看到数据同步的核心是 GoldenGate,在HIS数据库和EMRS 数据库上变化数据的捕获、传递和复制都是通过他来完成的。当EMR数据库发生数据变化的时候，如EMR下达、校对医嘱之后，此时运行在EMR数据库服务 器上的GoldenGate将捕获该功能业务对应的变化数据，并通过网络传递到HIS数据库，HIS数据库接收到这些

21、变化数据之后，运行在 HIS数据库服务器上的 GoldenGate解析这些变化数据并应用到 HIS数据库，此时如摆药程序就能看到 相应的医嘱记录并进行摆药。反之HIS数据库上的变化数据也是经过上述过程应 用到EMR数据库。通过GoldenGate我们可以很好地实现了 HIS数据库和EMR敛据库的之间的 独立和联系，使他们各尽其职，分工明确，一起很好地共同支撑整个医院的正常 运营。5.1 GoldenGate 概述Oracle GoldenGate软件是一种基于日志的结构化数据复制软件，它议决剖 析源数据库在线日志或归档日志取得数据的增量改变，再将这些改变运用到目标数据库，从而完成源数据库与目标

22、数据库同步。GoldenGate能够在异构的IT基本结构（包括几乎一切常用操作系统平台和数据库平台）之间完成大量数据亚 秒一级的及时复制，从而在能够在应急系统、在线报表、及时数据仓库供应、买 实跟踪、数据同步、集中/分发、容灾等多个场景下运用，而我们采用的场景是 数据双向复制，GoldenGate双向复制的工作原理如下图所示：V目的数据库如上所示，GoldenGate在实现数据同步的时候，主要涉及到三个重要进 程：抽取进程、投递进程和应用进程。1 .抽取进程：就是上图Capture进程，该进程主要负责读取数据库对应的 日志文件，将数据变化保存到队列文件中；2 .投递进程：也叫传输进程，该进程主

23、要负责将源数据库中产生的变化的 队列文件进过压缩和加密等方式，通过网络传输到目的数据库；3 .应用进程：也叫接纳进程，该进程主要负责将投递进程传递过来的源数 据库的数据变化队列文件解析出来，并应用到目的数据库中。上述三个进程完成了从源数据库到目的数据库的单项同步，如果再加上从目的数据库到源数据库的相似的三个进程，就实现了源数据库和目的数据库之间的 双向同步。5.2GoldenGate 的特性1.国工毋目总§数雌日志0 JData Pumo基于日志的实时数据复制：相比传统依赖数据库触发器和规则的方法来捕获数据变化，GoldenGate采用读取日志方式对源数据库影响小很多, 速度也快很多

24、。如上图所示，GoldenGate是通过数据日志挖掘的方式实现的。2.事务完整性：GoldenGate只复制成功提交的事务，同时目标数据库按照源数据库的操作顺序，而且，可以中断可以自动恢复，这些保证了源和目标之间的事务完整性。3.检查点机制保障数据无丢失：GoldenGate的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，具检查点记录当前已经抽取日志的位置和写队列文件的位置;对于投递进程，具检查点记录当前读取队列文件的位置Insert. TX 1Update. TX 1Gtitrt吊儿 TX 2Begin. TX 3CaptureCheckpoint*Inter!, TX 1I

25、nstrt. TX 3当前耳G蟒当*读 拉置Cammit TX 3当前试PumpCheckpointln4+d. TX 2Pijfnp目标数据库刍前写, 位置:Carnrit Ordered T4g帆也Delrvery Checkipoinl上图中，Capture、Pumpf口 Devlivery 将传递状态存储至checkpoint file确保其恢复性，检查点机制可以保证在系统、网络或GoldenGate进程故障重启后数据无丢失。可靠的数据传输机制： GoldenGate 用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成， 否则将自动重新传输数据， 从而保证了抽取出的所有数据

26、都能发送到目标端。 数据传输过程中支持128 位加密和数据压缩功能。6 界面集成对于医学影像、心电图波形数据，临床医生的需求是，不仅能浏览图像和波形，还须有对其处理的要求，通常对应系统供应商提供了 DICOMM象浏览器和心电图浏览器， 这些浏览器提供相应的工具来处理、 管理、 传输和转换图像和波形。针对这种带专业处理功能的人机交互界面的应用程序， 我们采用界面集成的方式， 集成专业浏览器插件或应用程序。针对这种方式的场景，EMR繇统将采用界面集成应用的方式集成数据综合浏览视图， 在临床数据中心一节中已提到， 该视图采用组件化方式进行开发， 实 质是各类专业浏览插件的容器，支持对各种医学影像（X

27、-Ray、CK MRk超声、胃肠镜） 、心电图、监护数据和麻醉监护数据等在内的多种医疗数据的综合阅览 分析。至于各专业浏览器插件内部的实现， 可能又会采用应用集成的方式， 但通常 为了提高性能，和多媒体资料库中心采用直连的方式获取影像和波形。以DICOMM象浏览器组件为例，其内部采用DICOM准进行医学影像格式定 义与交互传输。该模块以OCX空件的方式实现，同时提供给集成事务处理模块和 医护工作站使用。EMRS!护工作站使用DICOMEI擎主要实现从影像中心查询和 获取影像等功能。6.1 DICOMfM象应用流程规划而户曲求潮览资像I设置参数.谙求获取影像DIC'UM Query事件通

28、知（敬世）kQuery RespondbtCOM»件期知I新文刊）D1COX1 SJtnrnge$LUUgH RapElKBLHCOU StorageSLorane Response显小里件通如询束）影像显小流程DICOMM象的显示流程如上图所示，主要由以下几步组成：医护工作站通过调用DICOMH擎，设置参数（Study UID或Study Type + Study ID, DICOM Server的IP、Port、A® *,请求获取一个检查的影像；DICO用I擎启动DICOMQuery服务，获取检查影像数，事件通知医护工作站， 医护工作站可以根据返回的影像数启动初始化进度

29、条；DICOMH擎启动DICOM Move艮务，向影像中心请求影像；影像中心启动DICOM Storage服务，向DICOWI擎发送影像；DICOMH擎每接收到一个新文件，事件通知医护工作站，医护工作站可以在 此事件的处理中打开并显示此文件，同时改变进度条位置；DICOMBI擎接收到DICOM Mov。向应，表明文件获取已经结束，事件通知医 护工作站。7核心价值通过建立集成信息平台，集成各类应用系统以及日常运营的业务， 通过该平 台整合医院内部业务应用系统，形成一个互联互通的医院业务协作网络。 医院信 息集成平台可以很好支持不同系统之间的医疗数据整合、业务整合与数据共享，快速实施应用程序节点部

30、署以及各医疗子系统之间的协同通讯。在医院信息系统中的各子系统中，比如 HIS,LIS,RIS,OA等，传递和展现整个医疗过程中的相关 信息。同时，集成信息平台为临床数据中心的数据来源提供了技术基础和保障， 通过信息标准、交换原则的制定，对业务系统提供标准的信息交换服务， 确保数 据交换过程的安全性、可靠性，实现数据在系统平台范围内自由、可靠、可信的 交换。通过医院信息平台建设，一方面可以规避“点对点”式的信息共享与交换，并使得医院可以基于信息平台整体上进行业务流程优化与管理，对内提高管理水平，对外以统一的方式接入区域卫生协同网络， 更好地为人民健康服务。另一方 面利于医院信息系统建设的持续性发展，以适应未来的需求变化，