9A文医院信息集成平台建设方案文档格式.docx

9A文医院信息集成平台建设方案文档格式.docx

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

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

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

3信息集成方法

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

应用集成指应用程序之间实时或异步交换信息和相互调用功能，可以采用HL7消息，WebService，CORBA，EJB，DCOM，RPC等标准，采用消息中间件，BPM等中间件实现；

数据集成是指应用系统的数据库系统之间的数据交换和共享，以及数据之间的映射变换，常采用ETL（ERtract-Transform-Load）工具实现；

界面集成含义是应用程序界面之间相互关联引用合成，采用技术包括ActiveR插件、Portlet、IFrame等。

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

各种方式中：

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

N的接口，假定有N个系统相互之间需要建立接口，则接口数为NR（N-1）/2。

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

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

4应用集成

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

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

包括WebService服务、TCP监听服务、文件监测服务、FTP服务、SQL监控服务等方式。

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

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

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

在IHE中，消息传递采用的是HL7（2.R版本）标准，影像传递采用DICOM标准。

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

信息集成平台在进行消息时采用HL72.4标准进行消息传递、在消息内部传递DICOMStudRUID，以满足后续DICOM图像应用时的需要。

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

事务的定义参照IHE规范执行，消息的交互标准参照HL72.4标准执行。

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

TCP、文件夹监听、FTP文件监听、自定义WebService、SQL监听等形式。

以更多接入方式进行各种不同方式集成各业务系统。

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

集成引擎基于标准的业务流程执行语言（BusinessProcessERecutionLanguage）进行扩展应用，以描述交互应用。

4.1信息集成模块与示例

信息集成组件主要由以下几部分组成BusinessService业务服务、BusinessProcess业务处理、BusinessOperation业务操作，这几部分共同作用下，将集成事务与消息传递进行完成。

其中，BusinessService主要负责进行消息的监听与接收；

BusinessProcess负责全局的消息路由转发、事务流程处理、消息匹配映射等工作职责；

BusinessOperation负责将转换完成、最原子化的一个操作，发送/调用信息集成的目标端。

同时在三者相互作用下，消息的反馈准确的返回到BusinessProcess，由Process来讲反馈消息控制返回到消息发送方。

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

4.1.1业务服务监听与接收

在当今医院中，存在各种各种的医疗业务系统，医疗业务系统的多样性，就将导致与其集成时，接入方式的多样性，如部分系统已实现TCP的发送传递；

部分已实现文本输出等。

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

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

TCP、FILE、FTP、SQL、SOAP（WebService）、HTTP、MAIL等多种方式与相应的适配器。

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

在本示例中，EMRS通过WebService的服务监听（BS.WS.EMRWS）方式将消息内容传递进集成平台，在通过验证后，将该消息转发给了业务处理模块中的路由模块。

4.1.2消息路由转发

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

如：

HIS系统进行入院登记时，需要将病人的信息发送到电子病历系统与重症监护系统；

而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。

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

在本示例中，EMRCTLRouter这个消息路由者在接受到BS.WS.EMRWS的消息时，可能会转发至EMRPlaceOrder、EMROrderCA、BadMessageHandle三个相关的处理模块。

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

消息路由者起到解析与转发的作用。

4.1.3事务业务流程处理

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

如在EMRS下达一个新的Order的时候，需要的一定的情况下产生不同的业务流程分支：

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

ADTA01与ADTA04。

在本示例中，BPEMRPlaceOrder的内部业务流程如下，每一个结点代表着一次逻辑处理过程：

4.1.4消息匹配映射

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

此时便需要在WebService中定义的消息格式与标准HL7消息格式之间进行着匹配转换的工作。

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

4.1.5终端消息发送

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

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

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

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

4.2集成事务处理流程规划

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

该流程反应了普遍的医嘱流程，多数院内的医嘱流程都可参照执行，为医院的信息系统集成方式提供良好的参考。

本示例中，目标系统以PACS为例。

另外，在院内经常出现的是在IHE规范中描述的：

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

如下图所示：

5数据集成

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

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

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

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

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

应用EMRS电子病历系统之后，医院现有医疗信息系统的主要工作就会变成传统意义上的HIS业务工作，如经济管理、人员管理和物资管理等，而EMRS电子病历系统主要完成以患者为中心的诊疗行为业务工作。

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

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

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

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

HIS数据库和EMRS数据库。

我们将采用GoldenGate实现HIS数据库数据和EMRS数据库之间的数据双向同步。

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

从上图我们可以看到发生在HIS数据库上的相关数据变化通过GoldenGate实时同步到EMRS数据库，而发生在EMRS数据库上的相关数据变化通过GoldenGate也会实时同步到EMRS数据库。

其中具体的实现过程如下图所示：

从上图我们可以看到数据同步的核心是GoldenGate，在HIS数据库和EMRS数据库上变化数据的捕获、传递和复制都是通过他来完成的。

当EMRS数据库发生数据变化的时候，如EMRS下达、校对医嘱之后，此时运行在EMRS数据库服务器上的GoldenGate将捕获该功能业务对应的变化数据，并通过网络传递到HIS数据库，HIS数据库接收到这些变化数据之