医院信息集成平台建设技术方案.docx

医院信息集成平台建设技术方案.docx

《医院信息集成平台建设技术方案.docx》由会员分享，可在线阅读，更多相关《医院信息集成平台建设技术方案.docx（16页珍藏版）》请在冰豆网上搜索。

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

信息集成平台建设方案

1建设需求

一个完善得医院信息系统通常由上百个子系统组成，牵涉众多得专业领域.这么庞大得系统需要非常专业化得软件开发分工,整合不同厂商有特色得专业系统就是医院信息系统得发展趋势，医院信息化能够取得成功必须保证各个系统得有效集成与数据得高度共享。

然而这些系统通常就是随着医院得发展需求逐步建设得，它们来源于不同得厂家，基于不同得技术,缺乏统一得信息交换标准，这些系统得集成整合已经逐渐成为医院数字化发展亟待解决得主要问题。

系统集成平台得构建主要面向两个核心问题：

一个就是为各种医疗应用提供统一得医疗数据访问服务，从而消除各种医疗应用系统与医疗数据中心得直接耦合性;另一个就是为各种临床信息系统提供系统集成服务，系统集成服务基于系统集成模型，通过HL7与DI等标准通讯协议为各种医疗应用系统提供集成服务,确保各个临床信息系统在工作流整合得基础上实现交互协作，从而以数字化得形式完成各项医疗业务。

2建设目标

系统间得整合、集成与扩展一直都就是制约医院数字化发展得主要障碍，由于不同厂商之间得产品不兼容,使得医院整体信息化步履维艰。

通过建设一个规范得系统集成平台,在IHE、DI、ＨL7等国际标准得基础上,制定覆盖医疗所有业务流程得系统集成规范，开发基于规范得系统集成平台,为遗留得、当前得以及将来得系统提供了一个统一且标准得数据交换与工作流协同得平台。

3信息集成方法

信息集成方法有三，即应用集成、数据集成、界面集成，这三种集成方式各解决不同方面得问题。

应用集成指应用程序之间实时或异步交换信息与相互调用功能,可以采用ＨL７消息，ＷebSｅrｖicｅ，CORBA，EＪＢ，Ｄ,　RＰＣ等标准，采用消息中间件，ＢＰM等中间件实现;数据集成就是指应用系统得数据库系统之间得数据交换与共享，以及数据之间得映射变换，常采用ETL（Extract-Trａｎsform－Ｌｏad）工具实现；界面集成含义就是应用程序界面之间相互关联引用合成，采用技术包括ActiveX插件、Porｔlet、IFraｍｅ等。

协同应用从早期单纯得点对点接口方式,发展到现如今得集成平台方式。

各种方式中：

✓点对点接口方式得复杂性在于要与不同得系统建立1：

Ｎ得接口，假定有N个系统相互之间需要建立接口，则接口数为Ｎ＊（N－1）/2。

✓集成平台方式中,在Ｎ个系统需要进行应用协同得情况下，只需要开发N个适配器接口即可,减少了集成平台得系统负荷。

由于医院信息系统复杂性，我们根据不同得需求与应用场景,设计分别采用上述三种不同集成方法与手段进行信息集成。

4应用集成

与医技辅诊科室信息系统（如PACS/RIS、LＩS、MUSE等）得信息集成，这种场景，信息交互得数据量不大，实时性要求不高,且各信息系统各专业厂商实现方式相差较大,采用基于集成平台得应用集成方式就是最优选择.

集成平台体系结构如下图所示,集成平台对外提供支持多种方式得集成服务:

包括WｅbＳerｖiｃｅ服务、TCP监听服务、文件监测服务、ＦＴP服务、SQＬ监控服务等方式.

医院信息系统在国际、国内广泛采用得有一套集成规范,即：

医疗健康信息集成规范（IHＥ）规范。

IHＥ规范未定义新得集成标准，而就是采用了“标准协调”过程推动基于工业标准得医疗IT系统互操作性。

在IHE中,消息传递采用得就是ＨＬ7（２、x版本）标准,影像传递采用DI标准。

本集成平台得集成严格参照该规范进行：

信息集成平台在进行消息时采用HＬ72、4标准进行消息传递、在消息内部传递DIＳtudyUID,以满足后续ＤI图像应用时得需要.

临床信息集成用于对各临床信息系统进行信息层面得集成事务处理。

事务得定义参照ＩHＥ规范执行,消息得交互标准参照HL72、4标准执行。

集成平台内部引擎本身由Enｓemblｅ集成平台基础之上进行二次开发而来,依托Ｅnsemble本身对各种适配器得支持,集成平台对外能够提供多种接入服务方式：

TＣP、文件夹监听、FTP文件监听、自定义ＷｅｂService、SQL监听等形式.以更多接入方式进行各种不同方式集成各业务系统。

集成流程以业务流程可视化、可编辑化对外提供工作流程得制定与使用。

集成引擎基于标准得业务流程执行语言（ＢusinessPrｏcessＥxｅcutionＬａnguａge）进行扩展应用，以描述交互应用。

4.1信息集成模块与示例

信息集成组件主要由以下几部分组成BuｓiｎｅｓsServiｃe业务服务、BusinｅssＰrｏcess业务处理、BｕsineｓsＯｐｅｒaｔioｎ业务操作,这几部分共同作用下,将集成事务与消息传递进行完成.其中,BuｓｉｎｅｓsSerｖicｅ主要负责进行消息得监听与接收；BusinessProceｓｓ负责全局得消息路由转发、事务流程处理、消息匹配映射等工作职责；BuｓiｎesｓOpeｒation负责将转换完成、最原子化得一个操作，发送／调用信息集成得目标端。

同时在三者相互作用下,消息得反馈准确得返回到BusinessProcｅss，由Pｒocesｓ来讲反馈消息控制返回到消息发送方。

示意图如下（后续对该示例进行说明）：

4.1.1业务服务监听与接收

在当今医院中,存在各种各种得医疗业务系统,医疗业务系统得多样性,就将导致与其集成时，接入方式得多样性,如部分系统已实现ＴCＰ得发送传递;部分已实现文本输出等。

集成平台作为医院信息系统得中转、适配角色,在接入方式得多样性成为必要条件。

如前所述，在这方面，集成平台允许得接入方式有:

TCＰ、、SQL、SOAP（WebSeｒｖice）、、ＭAIL等多种方式与相应得适配器.

在多种方式得接入过程中，将不同来源得消息通过统一得出口转交给业务处理部分，由其进行路由住转发、消息匹配映射、业务流程处理等相关得工作。

在本示例中，EMRＳ通过WeｂSｅｒｖｉｃe得服务监听（BS、WS、EＭRWS）方式将消息内容传递进集成平台，在通过验证后,将该消息转发给了业务处理模块中得路由模块。

4.1.2消息路由转发

在一些应用场景中，如电子病历系统、重症监护系统、HIS系统三者进行信息传递时,部分信息就是需要三者之间交互得，而部分信息仅仅需要两者之间交互,这在消息转发路由时，需要有一定得控制，起到闸门得作用。

如：

HIS系统进行入院登记时，需要将病人得信息发送到电子病历系统与重症监护系统;而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。

因此，在集成平台中,引入消息路由转发得相关模块就显得比较重要.

在本示例中,ＥＭRＣＴLＲoutｅr这个消息路由者在接受到BS、WＳ、EMRWS得消息时，可能会转发至EMＲPｌacｅOrｄｅr、EMRＯrｄｅｒCA、BadMeｓsaｇeHandlｅ三个相关得处理模块。

而具体转发至何模块，由消息头定义中得相关信息具体定义。

消息路由者起到解读与转发得作用。

4.1.3事务业务流程处理

即时消息路由已经正确路由转发了消息到准确得端点,但就是在对应得端点内，还会有一些业务流程需要进行处理。

如在EMRS下达一个新得Ordｅr得时候,需要得一定得情况下产生不同得业务流程分支：

如该病人为门诊病人或者住院病人,则有必要产生HL7消息中得住院病人登记信息与门诊病人登记信息：

ADTA01与ＡDTA０４。

在本示例中，BPEＭRPlacｅＯrdｅr得内部业务流程如下,每一个结点代表着一次逻辑处理过程:

4.1.4消息匹配映射

在一些情况下，消息得传递方并无必要产生HＬ７标准格式消息得情况下，如EMRS与集成平台为内部互调时，双方之间提供预定义得ＷebService得接口，以快速得开发与进行集成。

此时便需要在WebＳerｖice中定义得消息格式与标准HL7消息格式之间进行着匹配转换得工作。

而该转换工作得处理调用就是由事务业务流程处理模块来发起调用得。

4.1.5终端消息发送

在进行正确得消息格式转换与业务逻辑处理,此时得消息已经成为一个符合终端系统需要得消息格式。

在事务业务流程处理中，会将此消息投递给相应得终端系统.

在投递消息完成工，事务业务流程处理模块会进入等待反馈得状况，等待终端系统反馈一个应答消息，以表示该消息在终端系统中被准确得处理。

事务处理模块收到该应答消息，并组织成发送端系统需要得消息格式，并作为应答系统,反馈至发送端系统。

4.2集成事务处理流程规划

上述主要针对集成平台中各个模块作用于应用场景进行了阐述,下面将以IHE规范中医嘱下达方医嘱执行得完整业务流程为例，进行完整得集成事务流程描述。

该流程反应了普遍得医嘱流程，多数院内得医嘱流程都可参照执行，为医院得信息系统集成方式提供良好得参考.本示例中,目标系统以PACS为例。

另外,在院内经常出现得就是在IＨE规范中描述得：

执行者医嘱流程，即由医嘱执行者（PACS系统中，为检查科室）进行医嘱下达得过程并执行得流程。

如下图所示：

5数据集成

在实际业务应用中,日常医院得HIＳ库与ERMＳ库之间存在较多需要高频率、高性能要求得交互，如计价信息与药品库存等信息得实时共享等。

针对这样得应用场景，我们采用了ETL工具（GoldenＧate）在数据库底层进行得DB层同步方式。

目前，医院已经存在比较完整得医疗信息系统,这些医疗信息就是以JW1H系统为基础，增加医院自己得需求发展而来。

ERMS电子病历系统就是一个完整得独立产品，她有她自己完整一套得系统架构与数据中心结构,而在系统架构与数据中心结构上医院现有医疗信息系统与EMRS电子病历系统都存在较大差异,这就决定了现有系统与EMＲS电子病历系统很难共用一个数据库。

可另外一方面，EMRS电子病历系统与医院现有医疗信息系统都就是医院系统不可分割得一部分,她们即有自己工作得重点,又有相互联系与配合，只有相互无间得结合，才能快速、高效与正确地完成日常工作。

应用EＭＲＳ电子病历系统之后,医院现有医疗信息系统得主要工作就会变成传统意义上得HIS业务工作,如经济管理、人员管理与物资管理等,而EMRＳ电子病历系统主要完成以患者为中心得诊疗行为业务工作.

两者之间存在着千丝万缕得关系，以医嘱业务举例,如EMRS电子病历系统下达、转抄与校对医嘱之后,医院现有医疗信息系统需要完成对应得业务操作，如医嘱摆药与医嘱收费操作等，这就需要在这两个系统之间同步数据信息,而涉及到同步得医疗业务往往涉及得医疗各个环节，如诊疗、药房、收费、人员管理等，因此需要信息同步得数据量会比较大，而同时为了不造成医疗业务得延迟与脱节，也需要很高得实时性.

在这种应用场景下已不适宜采用基于集成平台得，通过消息交互得应用集成方式。

消息集成方式，往往需要一个发起方与接受方,而发起方与接受方往往需要一些额外得支持,如发起方需要调用接受方提供得接口等，期间可能还涉及到一些负责得来回交互，最主要得就是，消息集成在数据量很大得情况下，处理速度不就是很快，因此，我们将通过数据集成得方式来实现数据同步，数据库集成工具采用OracleＧoｌdｅnGate。

医院涉及到需要数据同步得包括两个部分：

HＩS数据库与EMRＳ数据库.我们将采用GoldeｎＧate实现ＨIＳ数据库数据与EＭＲS数据库之间得数据双向同步。

其基本结构图如下图所示：

从上图我们可以瞧到发生在HIS数据库上得相关数据变化通过GoldenGatｅ实时同步到EＭRS数据库,而发生在EＭRＳ数据库上得相关数据变化通过ＧoldenGate也会实时同步到EＭＲＳ数据库。

其中具体得实现过程如下图所示:

从上图我们可以瞧到数据同步得核心就是ＧoｌdｅnＧate，在HIS数据库与EMRS数据库上变化数据得捕获、传递与复制都就是通过她来完成得。

当EＭRS数据库发生数据变化得时候，如EMRS下达、校对医嘱之后,此时运行在ＥMRＳ数据库服务器上得GoldｅｎGate将捕获该功能业务对应得变化数据,并通过网络传递到HIS数据库，ＨIS数据库接收到这些变化数据之后，运行在ＨＩS数据库服务器上得GｏldenＧaｔｅ解读这些变化数据并应用到HＩS数据库,此时如摆药程序就能瞧到相应得医嘱记录并进行摆药.反之HIS数据库上得变化数据也就是经过上述过程应用到EMRS数据库.

通过ＧｏldenＧａte我们可以很好地实现了HIS数据库与EMRS数据库得之间得独立与联系,使她们各尽其职，分工明确,一起很好地共同支撑整个医院得正常运营。

5.1ＧoldenGaｔｅ概述

Ｏracle　GoldenＧate软件就是一种基于日志得结构化数据复制软件,它议决剖析源数据库在线日志或归档日志取得数据得增量改变，再将这些改变运用到目标数据库,从而完成源数据库与目标数据库同步。

GoldenGaｔe　能够在异构得IT基本结构（包括几乎一切常用操作系统平台与数据库平台）之间完成大量数据亚秒一级得及时复制，从而在能够在应急系统、在线报表、及时数据仓库供应、买卖跟踪、数据同步、集中／分发、容灾等多个场景下运用，而我们采用得场景就是数据双向复制，GoｌdenGate双向复制得工作原理如下图所示:

如上所示，GolｄenＧate在实现数据同步得时候，主要涉及到三个重要进程：

抽取进程、投递进程与应用进程.

1.抽取进程:

就就是上图Ｃaptuｒe进程，该进程主要负责读取数据库对应得日志文件，将数据变化保存到队列文件中;

2.投递进程:

也叫传输进程，该进程主要负责将源数据库中产生得变化得队列文件进过压缩与加密等方式，通过网络传输到目得数据库；

3.应用进程：

也叫接纳进程，该进程主要负责将投递进程传递过来得源数据库得数据变化队列文件解读出来,并应用到目得数据库中。

上述三个进程完成了从源数据库到目得数据库得单项同步，如果再加上从目得数据库到源数据库得相似得三个进程,就实现了源数据库与目得数据库之间得双向同步。

5.2GｏｌdenGate得特性

1.基于日志得实时数据复制:

相比传统依赖数据库触发器与规则得方法来捕获数据变化，GolｄeｎGatｅ采用读取日志方式对源数据库影响小很多，速度也快很多.

如上图所示，GoldenGａte就是通过数据日志挖掘得方式实现得。

2.事务完整性：

ＧoｌdｅnGate只复制成功提交得事务，同时目标数据库按照源数据库得操作顺序，而且,可以中断可以自动恢复,这些保证了源与目标之间得事务完整性。

3.检查点机制保障数据无丢失：

GｏldｅnGate得抽取与复制进程使用检查点机制记录完成复制得位置.对于抽取进程,其检查点记录当前已经抽取日志得位置与写队列文件得位置；对于投递进程,其检查点记录当前读取队列文件得位置。

上图中,Capｔｕrｅ、Pump与Devlivery将传递状态存储至cｈｅｃｋpointfile确保其恢复性,检查点机制可以保证在系统、网络或GoｌdｅnGate进程故障重启后数据无丢失。

可靠得数据传输机制：

GoｌdenＧate用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据,从而保证了抽取出得所有数据都能发送到目标端。

数据传输过程中支持１2８位加密与数据压缩功能.

6界面集成

对于医学影像、心电图波形数据，临床医生得需求就是，不仅能浏览图像与波形，还须有对其处理得要求，通常对应系统供应商提供了DI影像浏览器与心电图浏览器,这些浏览器提供相应得工具来处理、管理、传输与转换图像与波形。

针对这种带专业处理功能得人机交互界面得应用程序，我们采用界面集成得方式，集成专业浏览器插件或应用程序。

针对这种方式得场景,EＭＲS系统将采用界面集成应用得方式集成数据综合浏览视图,在临床数据中心一节中已提到，该视图采用组件化方式进行开发,实质就是各类专业浏览插件得容器，支持对各种医学影像（X-Ray、CT、MRI、超声、胃肠镜）、心电图、监护数据与麻醉监护数据等在内得多种医疗数据得综合阅览分析。

至于各专业浏览器插件内部得实现,可能又会采用应用集成得方式,但通常为了提高性能,与多媒体资料库中心采用直连得方式获取影像与波形。

以DI影像浏览器组件为例，其内部采用DI标准进行医学影像格式定义与交互传输。

该模块以OＣＸ控件得方式实现,同时提供给集成事务处理模块与医护工作站使用。

ＥMRS医护工作站使用DI引擎主要实现从影像中心查询与获取影像等功能。

6.1DI影像应用流程规划

ＤI影像得显示流程如上图所示,主要由以下几步组成：

医护工作站通过调用DＩ引擎，设置参数（ＳtudyＵID或StudｙType　＋SｔudyIＤ，DISｅrver得IＰ、Pｏrt、ＡＥ）＊，请求获取一个检查得影像；

DI引擎启动DIＱuery服务，获取检查影像数,事件通知医护工作站，医护工作站可以根据返回得影像数启动初始化进度条；

DＩ引擎启动DIＭove服务，向影像中心请求影像；

影像中心启动ＤIStoｒage服务,向DI引擎发送影像;

DＩ引擎每接收到一个新文件，事件通知医护工作站，医护工作站可以在此事件得处理中打开并显示此文件,同时改变进度条位置；

DI引擎接收到ＤI　Ｍｏve响应,表明文件获取已经结束,事件通知医护工作站。

7核心价值

通过建立集成信息平台，集成各类应用系统以及日常运营得业务，通过该平台整合医院内部业务应用系统，形成一个互联互通得医院业务协作网络。

医院信息集成平台可以很好支持不同系统之间得医疗数据整合、业务整合与数据共享,快速实施应用程序节点部署以及各医疗子系统之间得协同通讯.在医院信息系统中得各子系统中,比如HIＳ,LIS,RIS,OA等，传递与展现整个医疗过程中得相关信息.同时，集成信息平台为临床数据中心得数据来源提供了技术基础与保障，通过信息标准、交换原则得制定，对业务系统提供标准得信息交换服务,确保数据交换过程得安全性、可靠性,实现数据在系统平台范围内自由、可靠、可信得交换。

通过医院信息平台建设,一方面可以规避“点对点”式得信息共享与交换,并使得医院可以基于信息平台整体上进行业务流程优化与管理，对内提高管理水平，对外以统一得方式接入区域卫生协同网络,更好地为人民健康服务。

另一方面利于医院信息系统建设得持续性发展,以适应未来得需求变化，避免信息化建设得大范围得推倒重来；另外,持续性发展还必须要有一套合适得实施与服务模式作支撑.