Orion医院信息集成平台解决方案v200001.docx

《Orion医院信息集成平台解决方案v200001.docx》由会员分享，可在线阅读，更多相关《Orion医院信息集成平台解决方案v200001.docx（15页珍藏版）》请在三一办公上搜索。

1、Orion医院信息集成平台解决方 案Orion HealthSolution Consulting APAC文件历史版本时间作者备注1.02015-01-24欣初始版本2.02015-07-26欣添加产品优势、硬件需求、容灾方案和实例解析目录1引言42系统建设目标及设计要求 42.1 解决问题一：医疗临床信息连续性及相关性42.2 解决问题二：医疗临床信息标准化及再利用42.3设计要求43Orion Health公司及其系统适用性 53.1 Orion产品优势54方案描述65硬件需求75.1 医院规模定义 75.2 小型医院75.3 中型医院85.4 大型医院86容灾方案97实例解析98案例展

2、示128.1 市公共卫生临床中心 128.2 复旦大学附属儿科医院138.3 Inland Empire Health Information Exchange 138.4 加拿大阿尔伯塔州131引言一个完善的医院信息系统通常由数十个甚至上百个子系统组成，牵涉众多的专业领域。这么庞大的系 统需要非常专业化的软件开发分工，整合不同厂商有特色的专业系统是医院信息系统的发展趋势，医院信 息化能够取得成功必须保证这些系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经 逐渐成为医院数字化发展

3、亟待解决的主要问题。Orion医院信息集成平台的构建方案着眼于在医院部实现医疗临床信息的集成重组，利用先进的技术手段，在 最大程度保护医院已有IT系统投资的基础上，建立面向临床面向科研面向集团化管理的信息技术平台，实现医疗 临床信息的统一访问和深层次利用，促进医院部信息流的通畅，从而实现医疗服务质量、医疗管理质量和医疗科 研水平的提高，更好的为患者服务。在实现医院部临床信息整合的同时，统一设计和实现临床信息的对外交换共 享的模型，从而方便地实现与社区医疗、区域医疗和公卫系统的衔接。2 系统建设目标及设计要求系统间的整合、集成和扩展一直都是制约医院数字化发展的主要障碍，由于不同厂商之间的产品不兼

4、容，使 得医院整体信息化步履维艰。通过建设一个规的系统集成平台在I HE、HL7等国际标准的基础上，制定覆盖医疗所有业 务流程的系统集成规，开发基于规的系统集成平台，为遗留的、当前的以及将来的系统提供了一个统一且标准的 数据交换和工作流协同的平台。通过本方案的实施，我们准备着重解决如下两个关键问题和达到相应的设计要求：2.1 解决问题一：医疗临床信息连续性及相关性基于现有的HIS、CIS、LIS、PACS等应用系统，实现医疗机构部及之间信息的互操作性，需要在医院部的各 个分立的业务系统之间构建基于信息交换标准（如HL7）的医疗临床信息集成平台。该平台建成后，实现规系统集成的信息交换标准及相应的

5、接口规标准，以信息技术的手段，在更高的层面上 进行信息集成。考虑到当前各个医院部的HIS、LIS、PACS、电子病历等医疗信息管理系统和医疗辅助系统都已基 本成型，因此医疗服务信息技术共享平台与这些已建成系统的业务关联性主要表现在集成层面，除非必要，不强 制要求原有系统进行根本性改造，而是以信息服务的方式或标准映射的方式与医疗服务信息技术共享平台进行信 息服务级衔接。2.2 解决问题二：医疗临床信息标准化及再利用建立以病人为中心，以优化流程为向导，以信息标准为基础的医疗临床信息标准化、电子化、语义化处理平 台，在实现临床信息采集与存储的基础上，实现临床信息的深度利用。医疗临床信息标准化及电子化

6、，就是将各类临床信息整合成一个标准化、可计算的模型。该模型不是一个简 单的医嘱电子化，而是一个能够应用先进的数据分析技术的临床信息模型，从而使得医务人员可以针对具体的疾 病和患者情况，选择最佳的医疗计划和技术。医疗临床信息标准化及电子化的另一个重点就是以病人为中心，将所有电子化的医疗临床信息进行组织，形 成以患者为核心的统一信息视图。借助上面提及的医疗信息集成平台，结合病人的主索引机制（EMPI），对HIS、 CIS、LIS、PACS等信息系统进行信息集成，以提供完整而准确的病人临床信息。2.3 设计要求针对集团医院运作的实际需要，实现系统间的互联互通及互操作性，集成平台的设计具体要求包括以下

7、几个 方面。一是先进性：系统必须严格遵循IHE四【技术框架及卫生部“基于电子病历的医院信息平台技术规”要求，符 合国际医疗信息交换技术发展潮流；二是可扩展性：系统规划设计必须站在医院的全局高度，充分考虑到医院各个业务系统接入甚至协作医院接 入等互联互通需要，并按照国际标准设计接口，确保今后和新增业务系统或其它院区信息平台的衔接；三是可靠性：系统应具有高可用性，支持7x24小时工作模式。同时系统提供完备的容灾技术，以利于抗干扰运行；提供系统运行日志，以利于及时纠错排障；四是安全性：系统提供严谨的用户权限管理和重要操作监控记录，保证系统使用的安全性；提供可靠的数据 传输技术和患者隐私保护措施，保证

8、数据安全。3 Orion Health公司及其系统适用性Orion Health是新西兰的一家100%专注于医疗健康领域的软件上市公司。它成立20多年来为全球医疗市场提 供了世界一流的解决方案。方案通过异构系统之间的医疗信息交换以及将健康信息在一个统一门户上的整合，解 决了 “信息孤岛”和“信息烟囱”的问题，进而提高了医疗质量和临床决策的精度和速度。Orion Health医院系统为临床医护人员展示了一个清晰，合理的病人记录，并可在其现有的临床工作流程中 使用。Orion Health医院系统能提供准确和关联的完整病人信息，可优化临床应用工作流程。与其他医疗产品进 行集成之后，就可以很容易地在

9、这些系统之间共享信息。Orion Health 医院系统利用强大的集成引擎Orion Health Rhapsody对所有现有和老旧系统的数据进行了 无缝集成。Rhapsody强大的集成能力允许新的系统和模块成功地集成到现有的系统中。Orion Health医院系统本 身可以很容易地被集成到现有的系统架构，而不需要更换现有的临床系统，如实验室信息系统，放射科信息系统 或其他专业系统。Orion Health 医院系统的灵活性，使得医疗机构能够根据不断变化的需求，对它迅速进行改动，使实施新的 医护模式成为可能，并且可以与其他医疗机构合作对病人进行医疗协同服务。3.1 Orion产品优势Orion

10、 Health 公司作为全球化的、独立运营的电子健康软件公司，已经在互连互通和互操作性的解决方案上 为医疗机构/医院和区域提供过其公认且可靠的经验。公司的Rhapsody集成引擎更是以集成平台的核心软件成为 享誉全球的品牌，常年居于美国KLAS排名的三甲位置。选择新西兰奥联公司作为集成平台的原厂商，将获得以下 优势： Orion Health 公司是全球最突出的医疗保健互操作性解决方案的供应商，也是美国健康信息交换的主要 供应商。公司的业务遍及全球30多个国家，并在27个国家设有分公司及办事处； Orion Health 公司拥有全球最专业的医疗信息服务团队，其全球服务中心能全天候为客户提供支

11、持服务; Orion Health 公司的集成引擎获得了美国MU、。入和英国1 TK体系的认证； 美国有49个州的联邦疾控中心选择Orion Health公司的集成引擎作为首要的消息传送软件； 美国马萨诸塞州联手 Orion Health 公司打造州级医疗信息交换平台，并获得奥巴马政府特批的医疗信息 建设资金； 新加坡选择 Orion Health 公司的医院解决方案（包括集成引擎）建成全球首个国家电子档案； 中国有130多家医院（大多为三甲医院）在使用 Orion Health 公司的软件。在帮助医院实现医疗信息系统的全面互连互通和互操作性的同时，Orion Health的Rhapsody集

12、成引擎还通过 以下的特性提升用户的使用体验： 易于使用，支持复杂的集成要求：集成引擎的开发实施都封装成各种控件模块，绝大部分通过配置即可 完成，仅有少量部分需要用到简单的JavaScript脚本和SQL语句； 集成引擎可独立安装及运行，本身不依托任何数据库系统。引擎的消息存储库是基于文件系统，稳定、 快速; 支持标准化，置多种国际主流的医疗信息交换标注，如HL7和其最新的FHIR标准。同时集成引擎提供图 形化的映射组件，无需业务系统进行接口改造即可完成标准转换； 集成引擎支持I HE标准，包含 IHE交换工具； 集成引擎置集成测试功能，可以对流程中的每一个节点的配置进行对比测试代码的语法及逻辑

13、错误。 集成引擎提供简化的日常监控：提供可通过网络浏览器访问的中文监控界面，基于安卓和iOS系统的手 机终端监控和将多个引擎的监控集中在同一个页面上进行展示的仪表盘； 集成引擎置版本控制，可以监控和回滚业务逻辑配置上的修改； 集成引擎的配置迁移简单迅速，可以通过导出/导入单一的配置文件来实现。4 方案描述方案设计的数字化集成平台利用消息中间件的企业服务总线，实现各业务系统的数据级整合。它主要包括如 下建设容： 建立一个IT基础平台：建立一个符合SOA设计理念的，可扩展的IT基础架构，为医院部多业务系统的 接入提供底层支撑。 规临床数据的收集、存储和共享方式确立以HL7 CDA为标准的临床信息模

14、型，实现基于IHE的临床数 据共享交换架构。同时基于先进的语义分析技术，实现临床数据的深度利用。 规业务数据交换标准和系统接入方式确立以HL7为标准的业务数据交换，支持HL7标准业务数据与非 HL7标准业务数据的转化机制，形成一套规的集成接口的设计要求规，指导未来的系统接入。 提供统一的医疗数据访问服务使用一个统一视图对医院的病人信息进行访问，确保医院的临床医生能 够无缝访问完整的病人记录并获得相同的病人诊疗信息。如上图所示，在整个系统架构中， Orion 的解决方案主要分为以下几个层次： 集成服务层以总线的方式构建集成平台，负责实现各个接入系统之间的信息交换功能。 数据服务层负责整个数据中心

15、库的数据管理，即数据中心库。 页面展现层构建业务门户，实现单点登录和个性化处理。根据对需求的分析和理解，本项目的建设应该分成两个关键部分： 医疗信息集成平台 使用Rhapsody引擎为医院各个业务系统建立一个集成平台，规临床信息模型及信息 共享接口标准，规系统集成的信息交换标准及相应的接口规标准，以及建立对外的统一数据交换接口。 此集成平台在信息交互的过程中将有效临床数据存入数据中心库CDR中，并通过配套的Portal进行展示。 外部交换平台形成基于标准的外部信息交换，形成院间交换，同时预留与公卫、医保等信息的交换接 口，从而实现基于标准的区域医疗信息共享交换体系。为保证院对同一个患者，但分布

16、在不同系统中的个人信息采集的完整性和准确性，需要建立患者主索引 (Enterprise Master Patient Index， EMPI)服务，从而达到通过唯一的患者标识将多个医疗信息系统有效地关 联在一起。建立患者主索引是实现大型医院部系统集成以及医院集团资源共享的必要条件。同时院需要建立一套完善的术语服务，以消除医院各业务系统间的术语差异性，实现对医疗术语的统一管理。综上所述，医院信息平 台的总体架构可参考下图所示：医院信息平台注堪苏僚底p tzm其享交质画务曾建（Bill泉团择同任肮&主91 海宣主住尻医生业务泡件系携曲据自1$DW机构盛统注fl0，血迁舶CDR患.拦王常引IEMPI

17、苗崖株用军CDft临床如诅摩CDSp-aEnnzE； CMV安主队任1怆置所工藁抵别更岳够1由子璃而L2_sL2f_e7住尻医生5 硬件需求5.1 医院规模定义医院规模床位消息接收/天消息处理/天小型医院1-19930,000300,000中型医院200-499100,0001,000,000大型（或集团）医院500 +1,000,000 +3,000,000 +5.2 小型医院预计医院规模： 医院少于200床位 医院业务系统大约接收30,000条消息 高峰时期的数据负载量大约为平常时期的4倍 每日引擎处理的消息量约为300,000条，或者是每秒4条硬件推荐： Windows Server 或

18、者 LinuxoCPU： 8 核 Intel Xeono 存：8GBo36GB的硬盘空间用于安装操作系统和引擎（RAID1）o 200GB用于Rhapsody的数据存储（RAID1）o 64位操作系统5.3UPS电源中型医院预计医院规模： 医院拥有200 - 500床位 医院业务系统大约接收100,000条消息 高峰时期的数据负载量大约为平常时期的4倍 每日引擎处理的消息量约为1,000,000条硬件推荐： Windows Server 或者 Linuxo CPU： 8 核 Intel Xeono 存：8GBo 36GB的硬盘空间用于安装操作系统和引擎（RAID1）o 200GB用于Rhaps

19、ody的数据存储（RAID1）o 64位操作系统o UPS电源5.4 大型医院预计医院规模： 医院拥有1200以上床位 医院业务系统大约接收1,000,000条以上的消息 高峰时期的数据负载量大约为平常时期的4倍 每日引擎处理的消息量约为15,000,000条硬件推荐： Linuxo CPU： 16 核 Intel Xeono 存：16GBo 36GB的硬盘空间用于安装操作系统和引擎（RAID1）o 200GB 用于 Rhapsody 的数据存储（RAID10）o 200GB用于其它数据（RAID10）o 64位操作系统o UPS电源 Solariso CPU： 8 核 UltraSPARC

20、或者 SPARC64o 存：16GBo 36GB的硬盘空间用于安装操作系统和引擎（RAID1）o 200GB 用于 Rhapsody 的数据存储（RAID10）o 200GB用于其它数据（RAID10）o 64位操作系统o UPS电源 HP-UXo CPU： 8 核 Intel Itaniumo 存：16GBo36GB的硬盘空间用于安装操作系统和引擎（RAID1）o200GB 用于 Rhapsody 的数据存储（RAID10）o200GB用于其它数据（RAID10）o64位操作系统o UPS电源AIXo CPU： 8 核 Power Processoro 存：16GBo36GB的硬盘空间用于安

21、装操作系统和引擎（RAID1）o200GB 用于 Rhapsody 的数据存储（RAID10）o 200GB用于其它数据（RAID10）o64位操作系统o UPS电源6 容灾方案根据医院信息平台的实际需求，一套良好的容灾方案可以更好的保证院系统的平稳运行。 Orion Health 的 Rhapsody集成引擎支持主备模式的架构部署（active-passive）。在使用此种架构的时候，主被两台服务器上的 引擎将共享引擎消息存储库（物理文件夹，通常放置于存储区域网络上Storage Area Network, SAN），如下 图所示：消息存堵库（SAN ）当主服务器上的Rhapsody引擎发生

22、异常时，备用服务器的引擎随即启动接管主服务器引擎的工作。由于两台 服务器使用的是相同的消息存储库，因此正在处理过程中的消息将会被继续处理而不会造成丢失或者需要原业务 系统重新发送。同时，所有的引擎连接都是通过一个虚拟IP完成，而这个IP永远指向正常工作的那台引擎服务 器。7 实例解析任何级别的区域医疗平台的信息初始来源都是医疗机构（医院），而医院信息系统对信息进行处理的第一步 就是收集和传递信息。通常信息流是伴随着各式各样窗口业务处理过程发生的，医疗事务就是其中一个典型的例 子。对于整个医院信息系统来说，窗口事务处理的计算机系统就是一个完整的HIS数据收集端口。它们是HIS伸 向信息发源地的触

23、角、感受器。以病人挂号、之后在就诊过程中需要进行血检的流程为例，信息流（以下称为“消息”）就需要从HIS发送 到 LIS。上图是一个简单的将 ADT （入院/挂号、出院和转院）消息通过Rhapsody引擎从HIS系统发送至LIS系统的 简单流程图。图中包括HIS的TCP Server通信点：引擎通过此通信点监听一个端口，接收从HIS系统传来的ADT消息；同时也用它 向HIS系统发送收到消息的回执ACK或者NACKLIS的TCP代理的通信点：引擎通过此通信点向LIS系统开放的TCP端口发送从HIS系统收集到的消息；同时 等待LIS系统发送的消息回执ACK或者NACKE-mail 客户端通信点：引

24、擎通过此通信点向系统监控人员或者相关管理人员发送消息交互的状态信息，特别 是在发生错误的时候，及时通知相关人员垃圾箱通信点：引擎通过此通信点回收不需要保存的LIS系统回执HL7回执生成器：引擎通过此控件在成功接收消息以后生成 HL7标准回执消息，并传递给HIS的TCP Server 通信点JavaScript过滤器Handle NACK:引擎通过此控件处理从LIS系统发回的NACK回执No-operation过滤器：引擎通过此控件将消息进行分流，在分流路径上的消息为原消息的一个副本依上图所示，引擎将从HIS接收收到的ADT消息分流成两份，一份发给HL7回执生成器，然后将生成的回执 发还给HIS

25、系统，如下图所示当HIS系统接收到一个ACK回执的时候，表明此消息已经被引擎正常接收并开始进行处理了。设计由 Rhapsody引擎发送回执的优势在于减少HIS系统确认消息成功发送的等待时间。在点对点的消息交互模式中，HIS 系统需要等待LIS系统发送回执，等待时间会相对较长，从而使后续消息的传送发生延时。更糟糕的是，如果HIS 系统需要将消息同时发送给多个其它系统，如同时发送给LIS、RIS和CIS，采用点对点的交互模式，等待时间会 更长，因为HIS系统需要分别收到三个ACK回执才能确认消息完全发送成功。上图的设计也就避免了这一问题的 发生。同时引擎将另一份相同的ADT消息副本通过LIS的TC

26、P代理发送去LIS系统，如下图所示当LIS系统将回执返回给引擎的LIS TCP代理通信点的时候，引擎又将这份回执分流成两份，一份是正常的 ACK，直接发送给垃圾箱通信点丢弃，如下图所示另一份为错误回执NACK （如果存在）的副本，将其使用JavaScript过滤器进行简单处理以后，再通过E- mail 客户端通信点发送给相关人员，如下图所示在很多情况下，一个高质量的路由一般是要对传递过程中产生的错误进行处理，如下图所示以上是对一个简单的HIS-LIS路由的分解，它展示了 ADT消息在医疗机构的传递方式。其他系统的互通，如 HIS-PACS, HIS-CIS可以以此为参照进行设置。当LIS或者P

27、ACS系统将检查报告或者影像图片发还给HIS系统 时，消息传递方式和上图基本相同，不过路由上的逻辑将更为复杂。8 案例展示8.1市公共卫生临床中心市公共卫生临床中心是复旦大学附属三级甲等医院，拥有金山总院与水电路分院两个院区，两院区相隔较远， 分别使用独立的业务系统，两院医疗信息无法共享，同一患者的临床信息在两个院区之间无法相互调阅，两院医 疗数据需要分别维护，导致整体上形成信息烟囱，造成了数据冗余、效率低下和资源浪费等问题。医院通过使用Rhapsody引擎/集成平台，将全院系统架构改造如下EMPI 患者主素引CMV 受控医学词汇库临昧数据中心 (Orion Health Corepackag

28、e)HIS LIS RIS EMRHIS LIS RI5新的架构解决了 集成平台的建设，各个系统直接与平台交互，降低各系统之间的耦合性，HIS性能提升； 两个院区通过院平台公用一个RIS系统，检查结果平台分发到两个HIS； 两个院区通过院平台公用一个手麻系统，手术申请通过平台汇总给手麻系统，手麻系统返回的收费信息， 领药信息通过平台分发到各个HIS系统中； 基础数据同步：统一维护，统一分发，保持系统的数据一致性； 同一个患者在两个院区的传染病信息只需上报一次； 两个院区的患者统一管理； 两个院区的临床信息实现以患者为中心共享，并且集成到医生工作站供医生快捷调阅； 两个院区的医技报告实现共享；

29、通过平台，实现两个院区的处方统一点评； 实现两个院区的科室、专家统一可以在手机上统一预约，并将预约信息反馈给各自的HIS系统。此架构为典型的集团医院信息集成平台架构。8.2 复旦大学附属儿科医院复旦大学附属儿科医院通过使用Rhapsody引擎对现有HIS、CIS、LIS、PACS进行基于国际医疗信息交换标准 -HL7标准的集成，将医院的历史数据和实时产生数据汇总到临床数据中心，实现以患者为中心的门诊、住院诊疗 过程的数据汇聚，为临床医护人员提供患者360视图。其系统架构图如下国过敏反应号问廉列衰I阁床门户(Portal)病人隐私及同意监控和审计日志通知和订阅管理T聋堂匾匾金蝶LIS 复商HIS

30、 GE W1射GE超声 到高EMR 直盲院观 旧版本EMR GE PACS8.3 Inland Empire Health Information ExchangeInland Empire HIE是一项集团化的非盈利性区域健康信息交换工程，它向跨美国7个州的32家医院共900 多万人口提供健康信息交换服务。该项目使用了 Orion Health 的集成平台，其中包括Rhapsody集成引擎，临床 数据库CDR和临床门户 Portalo 它同时还选择了 Orion Health 的临床路径以及病人门户(Patient Portal)作为 辅助工具，向整个区域的信息交换和访问提供帮助。在该工程中

31、， Orion Health 平台的Rhapsody引擎提供了强健的可扩展的互操作性和数据集成；平台的临床 门户提供了快速的标准化数据查询；同时平台本身也具备了高度的延展性，为未来需求的增加提供了整合的可能。 Orion Health 平台的使用立即给区域中的医疗机构带来了明显的帮助和改变，其中较为显著的是： 一家公共检查检验实验室参与了该工程以后，节省了 $30,000USD的接口开发费用； 一家联邦医疗中心大大提高了和加利福尼亚州免疫登记系统交互的效率。8.4 加拿大阿尔伯塔州加拿大的阿尔伯塔州选用了 Orion Health 的临床门户来展示整个州的电子健康档案(EHR)。选用的原因是

32、Orion Health 的临床门户可以基于不同的健康数据集提供统一的病人信息视图，同时它的网页界面具备很强的编 辑性、扩展性和配置性，以适应不同的需求。目前，阿尔伯塔州的电子健康档案(EHR)系统已通过Orion Health 的临床门户整合了药品、检查检验报告、放射影响、就诊历史、病人列表等信息，同时提供PACS影像浏览功能。Orion Health 的平台在整个项目中提供了以下的优化和帮助： 提高了医疗数据的利用率； 降低了从区域已有系统中获得以病人为中心的数据的难度，同时降低了系统改造成本； 非常易于配置以适应不同机构的需要； 提高了区域多家医疗机构和医疗应用系统信息统一展示的精准性; 通过简单的升级就可以整合新的医疗数据集或数据结构； 非常易于实施； 医护人员可以尽早的获取结果，降低了数据的延迟和重复的可能。