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

信息集成平台建设方案

1建设需求

一种完善医院信息系统普通由上百个子系统构成，牵涉众多专业领域。这样庞大系统需要非常专业化软件开发分工，整合不同厂商有特色专业系统是医院信息系统发展趋势，医院信息化可以获得成功必要保证各个系统有效集成和数据高度共享。然而这些系统普通是随着医院发展需求逐渐建设，它们来源于不同厂家，基于不同技术，缺少统一信息互换原则，这些系统集成整合已经逐渐成为医院数字化发展亟待解决重要问题。

系统集成平台构建重要面向两个核心问题：一种是为各种医疗应用提供统一医疗数据访问服务，从而消除各种医疗应用系统与医疗数据中心直接耦合性；另一种是为各种临床信息系统提供系统集成服务，系统集成服务基于系统集成模型，通过HL7和DICOM等原则通讯合同为各种医疗应用系统提供集成服务，保证各个临床信息系统在工作流整合基本上实现交互协作，从而以数字化形式完毕各项医疗业务。

2建设目的

系统间整合、集成和扩展始终都是制约医院数字化发展重要障碍，由于不同厂商之间产品不兼容，使得医院整体信息化步履维艰。通过建设一种规范系统集成平台，在IHE、DICOM、HL7等国际原则基本上，制定覆盖医疗所有业务流程系统集成规范，开发基于规范系统集成平台，为遗留、当前以及将来系统提供了一种统一且原则数据互换和工作流协同平台。

3信息集成办法

信息集成办法有三，即应用集成、数据集成、界面集成，这三种集成方式各解决不同方面问题。应用集成指应用程序之间实时或异步互换信息和互相调用功能，可以采用HL7消息，Web Service，CORBA，EJB，DCOM， RPC等原则，采用消息中间件，BPM等中间件实现；数据集成是指应用系统数据库系统之间数据互换和共享，以及数据之间映射变换，常采用ETL（Extract-Transform-Load）工具实现；界面集成含义是应用程序界面之间互有关联引用合成，采用技术涉及ActiveX插件、Portlet、IFrame等。

协同应用从初期单纯点对点接口方式，发展到现如今集成平台方式。各种方式中：

✓点对点接口方式复杂性在于要和不同系统建立1：N接口，假定有N个系统互相之间需要建立接口，则接口数为 N*(N-1)/2。

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

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

4应用集成

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

集成平台体系构造如下图所示，集成平台对外提供支持各种方式集成服务：涉及WebService服务、TCP监听服务、文献监测服务、FTP服务、SQL监控服务等方式。

医院信息系统在国际、国内广泛采用有一套集成规范，即：医疗健康信息集成规范（IHE）规范。IHE规范未定义新集成原则，而是采用了“原则协调”过程推动基于工业原则医疗IT系统互操作性。在IHE中，消息传递采用是HL7（2.x 版本)原则，影像传递采用DICOM原则。本集成平台集成严格参照该规范进行：信息集成平台在进行消息时采用HL72.4原则进行消息传递、在消息内部传递DICOM StudyUID，以满足后续DICOM图像应用时需要。

临床信息集成用于对各临床信息系统进行信息层面集成事务解决。事务定义参照IHE规范执行，消息交互原则参照HL7 2.4原则执行。

集成平台内部引擎自身由Ensemble集成平台基本之上进行二次开发而来，依托Ensemble自身对各种适配器支持，集成平台对外可以提供各种接入服务方式：TCP、文献夹监听、FTP文献监听、自定义WebService、SQL监听等形式。以更多接入方式进行各种不同方式集成各业务系统。

集成流程以业务流程可视化、可编辑化对外提供工作流程制定与使用。集成引擎基于原则业务流程执行语言（Business Process Execution Language）进

行扩展应用，以描述交互应用。

4.1信息集成模块与示例

信息集成组件重要由如下几某些构成Business Service业务服务、Business Process业务解决、Business Operation业务操作，这几某些共同作用下，将集成事务与消息传递进行完毕。其中，Business Service重要负责进行消息监听与接受；Business Process负责全局消息路由转发、事务流程解决、消息匹配映射等工作职责；Business Operation负责将转换完毕、最原子化一种操作，发送/调用信息集成目的端。同步在三者互相作用下，消息反馈精确返回到Business Process，由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内部业务流程如下，每一种结点代表着一次逻辑解决过程：