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

上传人:11****ws 文档编号:2260683 上传时间:2019-05-03 格式:DOCX 页数:16 大小:1.04MB
下载 相关 举报
医院信息集成平台建设方案.docx_第1页
第1页 / 共16页
医院信息集成平台建设方案.docx_第2页
第2页 / 共16页
医院信息集成平台建设方案.docx_第3页
第3页 / 共16页
医院信息集成平台建设方案.docx_第4页
第4页 / 共16页
医院信息集成平台建设方案.docx_第5页
第5页 / 共16页
点击查看更多>>
资源描述

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

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

3、集成方法有三,即应用集成、数据集成、界面集成,这三种集成方式各解决不同方面的问题。应用集成指应用程序之间实时或异步交换信息和相互调用功能,可以采用 HL7 消息,Web Service,CORBA ,EJB,DCOM, RPC 等标准,采用消息中间件,BPM 等中间件实现;数据集成是指应用系统的数据库系统之间的数据交换和共享,以及数据之间的映射变换,常采用 ETL(Extract-Transform-Load)工具实现;界面集成含义是应用程序界面之间相互关联引用合成,采用技术包括 ActiveX 插件、Portlet、IFrame 等。协同应用从早期单纯的点对点接口方式,发展到现如今的集成平台

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

5、成平台体系结构如下图所示,集成平台对外提供支持多种方式的集成服务:包括 WebService 服务、TCP 监听服务、文件监测服务、FTP 服务、SQL 监控服务等方式。医院信息系统在国际、国内广泛采用的有一套集成规范,即:医疗健康信息集成规范(IHE)规范。IHE 规范未定义新的集成标准,而是采用了“标准协调”过程推动基于工业标准的医疗 IT 系统互操作性。在 IHE 中,消息传递采用的是 HL7(2.x 版本)标准,影像传递采用 DICOM 标准。本集成平台的集成严格参照该规范进行:信息集成平台在进行消息时采用 HL7 2.4 标准进行消息传递、在消息内部传递 DICOM StudyUID

6、,以满足后续 DICOM 图像应用时的需要。临床信息集成用于对各临床信息系统进行信息层面的集成事务处理。事务的定义参照 IHE 规范执行,消息的交互标准参照 HL7 2.4 标准执行。集成平台内部引擎本身由 Ensemble 集成平台基础之上进行二次开发而来,依托 Ensemble 本身对各种适配器的支持,集成平台对外能够提供多种接入服务方式:TCP、文件夹监听、FTP 文件监听、自定义 WebService、SQL 监听等形式。以更多接入方式进行各种不同方式集成各业务系统。集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。集成引擎基于标准的业务流程执行语言(Business P

7、rocess Execution Language)进行扩展应用,以描述交互应用。4.1 信息集成模块与示例信息集成组件主要由以下几部分组成 Business Service 业务服务、Business Process 业务处理、Business Operation 业务操作,这几部分共同作用下,将集成事务与消息传递进行完成。其中,Business Service 主要负责进行消息的监听与接收;Business Process 负责全局的消息路由转发、事务流程处理、消息匹配映射等工作职责;Business Operation 负责将转换完成、最原子化的一个操作,发送/调用信息集成的目标端。同时

8、在三者相互作用下,消息的反馈准确的返回到 Business Process,由 Process 来讲反馈消息控制返回到消息发送方。示意图如下(后续对该示例进行说明):4.1.1 业务服务监听与接收在当今医院中,存在各种各种的医疗业务系统,医疗业务系统的多样性,就将导致与其集成时,接入方式的多样性,如部分系统已实现 TCP 的发送传递;部分已实现文本输出等。集成平台作为医院信息系统的中转、适配角色,在接入方式的多样性成为必要条件。如前所述,在这方面,集成平台允许的接入方式有:TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL 等多种方式与相应的适配器。在多种方

9、式的接入过程中,将不同来源的消息通过统一的出口转交给业务处理部分,由其进行路由住转发、消息匹配映射、业务流程处理等相关的工作。在本示例中,EMRS 通过 WebService 的服务监听(BS.WS.EMRWS)方式将消息内容传递进集成平台,在通过验证后,将该消息转发给了业务处理模块中的路由模块。4.1.2 消息路由转发在一些应用场景中,如电子病历系统、重症监护系统、HIS 系统三者进行信息传递时,部分信息是需要三者之间交互的,而部分信息仅仅需要两者之间交互,这在消息转发路由时,需要有一定的控制,起到闸门的作用。如:HIS系统进行入院登记时,需要将病人的信息发送到电子病历系统与重症监护系统;而

10、在重症监护系统采集到病人生命体征信息时,仅仅将此信息发送到电子病历系统即可。因此,在集成平台中,引入消息路由转发的相关模块就显得比较重要。在本示例中,EMRCTLRouter 这个消息路由者在接受到 BS.WS.EMRWS 的消息时,可能会转发至 EMRPlaceOrder、EMROrderCA、BadMessageHandle 三个相关的处理模块。而具体转发至何模块,由消息头定义中的相关信息具体定义。消息路由者起到解析与转发的作用。4.1.3 事务业务流程处理即时消息路由已经正确路由转发了消息到准确的端点,但是在对应的端点内,还会有一些业务流程需要进行处理。如在 EMRS 下达一个新的 Or

11、der 的时候,需要的一定的情况下产生不同的业务流程分支:如该病人为门诊病人或者住院病人,则有必要产生 HL7 消息中的住院病人登记信息与门诊病人登记信息:ADTA01 与 ADTA04。在本示例中,BPEMRPlaceOrder 的内部业务流程如下,每一个结点代表着一次逻辑处理过程:4.1.4 消息匹配映射在一些情况下,消息的传递方并无必要产生 HL7 标准格式消息的情况下,如 EMRS 与集成平台为内部互调时,双方之间提供预定义的 WebService 的接口,以快速的开发与进行集成。此时便需要在 WebService 中定义的消息格式与标准 HL7 消息格式之间进行着匹配转换的工作。而该

12、转换工作的处理调用是由事务业务流程处理模块来发起调用的。4.1.5 终端消息发送在进行正确的消息格式转换与业务逻辑处理,此时的消息已经成为一个符合终端系统需要的消息格式。在事务业务流程处理中,会将此消息投递给相应的终端系统。在投递消息完成工,事务业务流程处理模块会进入等待反馈的状况,等待终端系统反馈一个应答消息,以表示该消息在终端系统中被准确的处理。事务处理模块收到该应答消息,并组织成发送端系统需要的消息格式,并作为应答系统,反馈至发送端系统。4.2 集成事务处理流程规划上述主要针对集成平台中各个模块作用于应用场景进行了阐述,下面将以IHE 规范中医嘱下达方医嘱执行的完整业务流程为例,进行完整

13、的集成事务流程描述。该流程反应了普遍的医嘱流程,多数院内的医嘱流程都可参照执行,为医院的信息系统集成方式提供良好的参考。本示例中,目标系统以 PACS 为例。上层应用程序 集成平台P A C S新开申请单发送 O R M O 0 1 消息 ( c o n t r o l c o d e = N W )响应 O R M O 0 1 消息对检查申请进行安排后 , 发送 S I U S 1 2 消息响应 S I U S 1 2 消息查询申请安排情况开始检查时 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S C O r d e r S t a t u s

14、 = S C )响应 O R M O 0 1 消息检查完成后 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S C O r d e r S t a t u s = C M )响应 O R M O 0 1 消息查询申请检查信息报告完成后 , 发送 O R U R 0 1 消息 ( O B X . 1 1 = P , 初步报告 )响应 O R M O 0 1 消息查询申请检查报告住院病人 : 发送 A D T A 0 1 消息 / 门诊病人 : 发送 A D T A 0 4 消息响应 A D T A 0 1 消息 / 响应 A D T A 0 4 消息

15、报告审核后 , 发送 O R U R 0 1 消息 ( O B X . 1 1 = F , 最终报告 )响应 O R M O 0 1 消息查询申请检查报告发送 D F T P 0 3 消息响应 D F T P 0 3 消息通知收费系统进行收费有图像数据 ( 图像匹配 ) 后 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S C O r d e r S t a t u s = D A )响应 O R M O 0 1 消息另外,在院内经常出现的是在 IHE 规范中描述的:执行者医嘱流程,即由医嘱执行者(PACS 系统中,为检查科室)进行医嘱下达的过程并

16、执行的流程。如下图所示:上层应用程序 集成平台P A C S急诊检查登录时 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S N )发送响应 O R R O 0 2 消息 ( c o n t r o l c o d e = N A )报告完成后 , 发送 O R U R 0 1 消息 ( O B X . 1 1 = P , 初步报告 )响应 O R U R 0 1 消息查询检查报告发送 A D T A 0 8 消息 , 更新病人信息 / 发送 A D T A 4 0 消息 , 合并病人号响应 A D T A 0 8 消息 / 响应 A D T A

17、4 0 消息报告审核后 , 发送 O R U R 0 1 消息 ( O B X . 1 1 = F , 最终报告 )响应 O R U R 0 1 消息查询申请检查报告更新或合并病人信息开始检查时 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S C O r d e r S t a t u s = S C )响应 O R M O 0 1 消息检查完成后 , 发送 O R M O 0 1 消息 ( c o n t r o l c o d e = S C O r d e r S t a t u s = C M )响应 O R M O 0 1 消息查询检查

18、信息P A C S 发送 O R M O 0 1 ( c o n t r o l c o d e = S N ) 消息时 , 消息中必须包含病人号 ( P I D . 3 ), 也就是说病人已经挂过号 。发送 D F T P 0 3 消息响应 D F T P 0 3 消息通知收费系统进行收费5 数据集成在实际业务应用中,日常医院的 HIS 库与 ERMS 库之间存在较多需要高频率、高性能要求的交互,如计价信息与药品库存等信息的实时共享等。针对这样的应用场景,我们采用了 ETL 工具(GoldenGate)在数据库底层进行的 DB 层同步方式。目前,医院已经存在比较完整的医疗信息系统,这些医疗信

19、息是以 JW1H 系统为基础,增加医院自己的需求发展而来。ERMS 电子病历系统是一个完整的独立产品,他有他自己完整一套的系统架构和数据中心结构,而在系统架构和数据中心结构上医院现有医疗信息系统和 EMRS 电子病历系统都存在较大差异,这就决定了现有系统和 EMRS 电子病历系统很难共用一个数据库。可另外一方面,EMRS 电子病历系统和医院现有医疗信息系统都是医院系统不可分割的一部分,他们即有自己工作的重点,又有相互联系和配合,只有相互无间的结合,才能快速、高效和正确地完成日常工作。应用 EMRS 电子病历系统之后,医院现有医疗信息系统的主要工作就会变成传统意义上的 HIS 业务工作,如经济管

20、理、人员管理和物资管理等,而 EMRS 电子病历系统主要完成以患者为中心的诊疗行为业务工作。两者之间存在着千丝万缕的关系,以医嘱业务举例,如 EMRS 电子病历系统下达、转抄和校对医嘱之后,医院现有医疗信息系统需要完成对应的业务操作,如医嘱摆药和医嘱收费操作等,这就需要在这两个系统之间同步数据信息,而涉及到同步的医疗业务往往涉及的医疗各个环节,如诊疗、药房、收费、人员管理等,因此需要信息同步的数据量会比较大,而同时为了不造成医疗业务的延迟和脱节,也需要很高的实时性。在这种应用场景下已不适宜采用基于集成平台的,通过消息交互的应用集成方式。消息集成方式,往往需要一个发起方和接受方,而发起方和接受方往往需要一些额外的支持,如发起方需要调用接受方提供的接口等,期间可能还涉及到一些负责的来回交互,最主要的是,消息集成在数据量很大的情况下,处理速度不是很快,因此,我们将通过数据集成的方式来实现数据同步,数据库集成工具采用 Oracle GoldenGate。医院涉及到需要数据同步的包括两个部分:HIS 数据库和 EMRS 数据库。我们将采用 GoldenGate 实现 HIS 数据库数据和 EMRS 数据库之间的数据双向同步。其基本结构图如下图所示:

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 实用文档资料库 > 策划方案

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。