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

《医院信息集成平台建设方案.doc》由会员分享，可在线阅读，更多相关《医院信息集成平台建设方案.doc（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 插件、 Portle

4、t、 IFrame 等。 协同应用从早期单纯的点对点接口方式，发展到现如今的集成平台方式。各种方式中： 点对点接口方式的复杂性在于要和不同的系统建立 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 标准。本集成平台的集成严格参照该规

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

7、务系统。 集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。集成引擎基于标准的业务流程执行语言（ Business Process Execution Language）进行扩展应用，以描述交互应用。 4.1 信息集成模块与示例 信息集成组件主要由以下几部分组成 Business Service 业务服务、 Business Process 业务处理、 Business Operation 业务操作，这几部分共同作用下，将集成事务与消息传递进行完成。其中， Business Service 主要负责进行消息的监听与接收； Business Process 负责全局的消息路由转发、

8、事务流程处理、消息匹配映射等工作职责； Business Operation 负责将转换完成、最原子化的一个操作，发送 /调用信息集成的目标端。同时在三者相互作用下，消息的反馈准确的返回到 Business Process，由 Process 来讲反馈消息控制返回到消息发送方。示意图如下（后续对该示例进行说明）： 4.1.1 业务服务监听与接收 在当今医院中，存在各种各种 的医疗业务系统，医疗业务系统的多样性，就将导致与其集成时，接入方式的多样性，如部分系统已实现 TCP 的发送传递；部分已实现文本输出等。集成平台作为医院信息系统的中转、适配角色，在接入方式的多样性成为必要条件。如前所述，在这

9、方面，集成平台允许的接入方式有：TCP、 FILE、 FTP、 SQL、 SOAP(WebService)、 HTTP、 MAIL 等多种方式与相应的适配器。 在多种方式的接入过程中，将不同来源的消息通过统一的出口转交给业务处理部分，由其进行路由住转发、消息匹配映射、业务流程处理等相关的工作。 在本示例中 ， EMRS 通过 WebService 的服务监听（ BS.WS.EMRWS）方式将消息内容传递进集成平台，在通过验证后，将该消息转发给了业务处理模块中的路由模块。 4.1.2 消息路由转发 在一些应用场景中，如电子病历系统、重症监护系统、 HIS 系统三者进行信息传递时，部分信息是需要三

10、者之间交互的，而部分信息仅仅需要两者之间交互，这在消息转发路由时，需要有一定的控制，起到闸门的作用。如： HIS 系统进行入院登记时，需要将病人的信息发送到电子病历系统与重症监护系统；而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病 历系统即可。因此，在集成平台中，引入消息路由转发的相关模块就显得比较重要。 在本示例中， EMRCTLRouter 这个消息路由者在接受到 BS.WS.EMRWS 的消息时，可能会转发至 EMRPlaceOrder、 EMROrderCA、 BadMessageHandle 三个相关的处理模块。而具体转发至何模块，由消息头定义中的相关信息具体定义

11、。消息路由者起到解析与转发的作用。 4.1.3 事务业务流程处理 即时消息路由已经正确路由转发了消息到准确的端点，但是在对应的端点内，还会有一些业务流程需要进行处理。如在 EMRS 下达一个新的 Order 的时候，需要的一定的情况下产生不同的业务流程分支：如该病人为门诊病人或者住院病人，则有必要产生 HL7 消息中的住院病人登记信息与门诊病人登记信息： ADTA01 与ADTA04。 在本示例中， BPEMRPlaceOrder 的内部业务流程如下，每一个结点代表着一次逻辑处理过程： 4.1.4 消息匹配映射 在一些情况下，消息的传递方并无必要产生 HL7 标准格式消息的情况下，如EMRS

12、与集成平台为内部互调时，双方之间提供预定义的 WebService 的接口，以快速的开发与进行集成。 此时便需要在 WebService 中定义 的消息格式与标准 HL7 消息格式之间进行着匹配转换的工作。而该转换工作的处理调用是由事务业务流程处理模块来发起调用的。 4.1.5 终端消息发送 在进行正确的消息格式转换与业务逻辑处理，此时的消息已经成为一个符合终端系统需要的消息格式。在事务业务流程处理中，会将此消息投递给相应的终端系统。 在投递消息完成工，事务业务流程处理模块会进入等待反馈的状况，等待终端系统反馈一个应答消息，以表示该消息在终端系统中被准确的处理。事务处理模块收到该应答消息，并组

13、织成发送端系统需要的消息格式，并作为应答系统，反馈至发送端系统。 4.2 集成事务 处理流程规划 上述主要 针对 集成平台中各个模块作用 于 应用场景进行了阐述，下面将以IHE 规范中医嘱下达方医嘱执行的完整业务流程为例，进行完整的集成事务流程描述。该流程反应了普遍的医嘱流程，多数院内的医嘱流程都可参照执行 ， 为医院的信息系统集成方式提供良好的参考。本示例中，目标系统以 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 消

14、 息对 检 查 申 请 进 行 安 排 后 ， 发 送 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 = 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 消 息查 询

15、 申 请 检 查 信 息报 告 完 成 后 ， 发 送 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 消 息报 告 审 核 后 ， 发 送 O R U R 0 1 消 息 ( O B X . 1 1 = F ， 最 终 报 告 )响 应 O R M O 0 1 消 息查 询 申 请 检 查

16、 报 告发 送 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 系统中，为检查科室）进行医嘱下达的过程并执行的流程。如下图所示： 上 层 应 用 程 序 集 成 平 台P A C S急 诊 检 查

17、登 录 时 ， 发 送 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

18、D T A 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

19、 d e r S t a t u s = C M )响 应 O R M O 0 1 消 息查 询 检 查 信 息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库之间存在较多需要高频率、高性能要求的交互，如计价信息与药品库存

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

21、有相互联系和配合，只有相互无间的结合，才能快速、高效和正确地完 成日常工作。应用 EMRS 电子病历系统之后，医院现有医疗信息系统的主要工作就会变成传统意义上的 HIS 业务工作，如经济管理、人员管理和物资管理等，而 EMRS 电子病历系统主要完成以患者为中心的诊疗行为业务工作。 两者之间存在着千丝万缕的关系，以医嘱业务举例，如 EMRS 电子病历系统下达、转抄和校对医嘱之后，医院现有医疗信息系统需要完成对应的业务操作，如医 嘱摆药和医嘱收费操作等 ，这就需要在这两个系统之间同步数据信息，而涉及到同步的医疗业务往往涉及的医疗各个环节，如诊疗、药房、收费、人员管理等，因此需要信息同步的数据量 会

22、比较大，而同时为了不造成医疗业务的延迟和脱节，也需要很高的实时性。 在这种应用场景下已不适宜采用基于集成平台的，通过消息交互的应用集成方式。消息集成方式，往往需要一个发起方和接受方，而发起方和接受方往往需要一些额外的支持，如发起方需要调用接受方提供的接口等，期间可能还涉及到一些负责的来回交互，最主要的是，消息集成在数据量很大的情况下，处理速度不是很快，因此，我们将通过数据集成的方式来实现数据同步，数据库集成工具采用 Oracle GoldenGate。 医院涉及到需要数据同步的包括两个部分： HIS 数据库和 EMRS 数据库。我们将采用 GoldenGate 实现 HIS 数据库数据和 EM

23、RS 数据库之间的数据双向同步。其基本结构图如下图所示： H I S 数 据 库服 务 器P R I D E 数 据 库服 务 器G o l d e n G a t e双 向 复 制从上图我们可以看到发生在 HIS 数据库上的相关数据变化通过 GoldenGate实时同步到 EMRS 数据库，而发生在 EMRS 数据库上的相关数据变化通过GoldenGate 也会实时同步到 EMRS 数据库。其中具体的实现过程如下图所示： 从上图我们可以看到数据同步的核心是 GoldenGate，在 HIS 数据库和 EMRS数据库上变化数据的捕获、传递和复制都是通过他来完成的。当 EMRS 数据库发生数据变

24、化的时候，如 EMRS 下达、校对医嘱之后，此时运行在 EMRS 数据库服务器上的 GoldenGate 将捕获该功能业务对应的变化数据，并通过网络传递到 HIS数据库， HIS 数据库接收到这些变化数据之后，运行在 HIS 数据库服务器上的GoldenGate 解析这些变化数据并应用到 HIS 数据库，此时如摆药程序就能看到相应的医嘱记录并进行摆药。反之 HIS 数据库上的变化数据也是经过上述过程应用到 EMRS 数据库。 通过 GoldenGate我们可以很好地实现了 HIS数据库和 EMRS数据库的之间的独立和联系，使他们各尽其职，分工明确，一起很好地共同支撑整个医院的正常运营。 5.1

25、 GoldenGate 概述 Oracle GoldenGate 软件是一种基于日志的结构化数据复制软件，它议决剖析源数据库在线日志或归档日志取得数据的增量改变，再将这些改变运用到目标数据库，从而完成源数据库与目标数据库同步。 GoldenGate 能够在异构的 IT基本结构（包括 几乎 一切常用操作系统平台和数据库平台）之间完成大量数据亚秒一级的及时复制 ,从而在能够在应急系统 、在线报表、及时数据仓库供应、买卖跟踪、数据同步、集中 /分发、容灾等多个场景下运用，而我们采用的场景是数据双向复制， GoldenGate 双向复制的工作原理如下图所示： 如上 所示， GoldenGate 在实现

26、数据同步的时候，主要涉及到三个重要进程：抽取进程、投递进程和应用进程。 1. 抽取进程：就是上图 Capture 进程，该进程主要负责读取数据库对应的日志文件，将数据变化保存到队列文件中； 2. 投递进程：也叫传输进程，该进程主要负责将源数据库中产生的变化的队列文件进过压缩和加密等方式，通过网络传输到目的数据库； 3. 应 用进程：也叫接纳进程，该进程主要负责将投递进程传递过来的源数据库的数据变化队列文件解析出来，并应用到目的数据库中。 上述三个进程完成了从源数据库到目的数据库的单项同步，如果再加上从目的数据库到源数据库的相似的三个进程，就实现了源数据库和目的数据库之间的双向同步。 5.2 G

27、oldenGate 的特性 1. 基于日志的实时数据复制： 相比传统依赖数据库触发器和规则的方法来捕获数据变化， GoldenGate 采用读取日志方式对源数据库影响小很多，速度也快很多。 如上图所示， GoldenGate 是通过数据日志挖掘的方式实现的。 2. 事务完整性： GoldenGate 只复制成功提交的事务，同时目标数据库按照源数据库的操作顺序，而且，可以中断可以自动恢复，这些保证了源和目标之间的事务完整性。 3. 检查点机制保障数据无丢失： GoldenGate 的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置

28、；对于投递进程，其检查点记录当前读取队列文件的位置。 上图中， Capture、 Pump和 Devlivery将传递状态存储至 checkpoint file确保其恢复性，检查点机制可以保证在系 统、网络或 GoldenGate 进程故障重启后数据无丢失。 可靠的数据传输机制： GoldenGate 用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到目标端。数据传输过程中支持 128 位加密和数据压缩功能。 6 界面集成 对于医学影像、心电图波形数据，临床医生的需求是，不仅能浏览图像和波形，还须有对其处理的要求，通常对

29、应系统供应商提供 了 DICOM 影像浏览器和心电图浏览器，这些浏览器提供相应的工具来处理、管理、传输和转换图像和波形。针对这种带专业处理功能的人机交互界面的应用程序，我们采用界面集成的方式，集成专业浏览器插件或应用程序。 针对这种方式的场景， EMRS 系统将采用界面集成应用的方式集成数据综合浏览视图，在临床数据中心一节中已提到，该视图采用组件化方式进行开发，实质是各类专业浏览插件的容器，支持对各种医学影像（ X-Ray、 CT、 MRI、超声、胃肠镜）、心电图、监护数据和麻醉监护数据等在内的多种医疗数据的综合阅览分析。 至于各专业浏览器 插件内部的实现，可能又会采用应用集成的方式，但通常为

30、了提高性能，和多媒体资料库中心采用直连的方式获取影像和波形。 以 DICOM 影像浏览器组件为例，其内部采用 DICOM 标准进行医学影像格式定义与交互传输。该模块以 OCX 控件的方式实现，同时提供给集成事务处理模块和医护工作站使用。 EMRS 医护工作站使用 DICOM 引擎主要实现从影像中心查询和获取影像等功能。 6.1 DICOM 影像应用流程规划 DICOM 影像的显示流程如上图所示，主要由以下几步组成： 医护工作站通过调用 DICOM引擎，设置参数（ Study UID或 Study Type + Study ID， DICOM Server 的 IP、 Port、 AE） *，请

31、求获取一个检查的影像； DICOM 引擎启动 DICOM Query 服务，获取检查影像数，事件通知医护工作站，医护工作站可以根据返回的影像数启动初始化进度条； DICOM 引擎启动 DICOM Move 服务，向影像中心请求影像； 影像中心启动 DICOM Storage 服务，向 DICOM 引擎发送影像； DICOM 引擎每接收到一个新文件，事件通知医护工作站，医护工作站可以在此事件的处理中打开并显示此文件，同时改变进度条位置； DICOM 引擎接收到 DICOM Move 响应，表明文件获取已经结束，事件通知医护工作站。 7 核心价值 通过建立集成信息平台，集成各类应用系统以及日常运营

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