Orion医院信息集成平台解决方案v2.0

Orion 医院信息集 成平台解决方案 Orion Health Solution Consulting APAC 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 2 文件历史 版本 时间 作者 备注 1 0 2015 01 24 谢欣 初始版本 2 0 2015 07 26 谢欣 添加产品优势 硬件需求 容灾方案和实例解析 目录 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 3 1 引言 4 2 系统建设目标及设计要求 4 2 1 解决问题一 医疗临床信息连续性及相关性 4 2 2 解决问题二 医疗临床信息标准化及再利用 4 2 3 设计要求 4 3 Orion Health 公司及其系统适用性 5 3 1 Orion 产品优势 5 4 方案描述 6 5 硬件需求 7 5 1 医院规模定义 7 5 2 小型医院 7 5 3 中型医院 8 5 4 大型医院 8 6 容灾方案 9 7 实例解析 10 8 案例展示 12 8 1 上海市公共卫生临床中心 12 8 2 复旦大学附属儿科医院 13 8 3 Inland Empire Health Information Exchange 13 8 4 加拿大阿尔伯塔州 14 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 4 1 引言 一 个 完 善 的 医 院 信 息 系 统 通 常 由 数 十 个 甚 至 上 百 个 子 系 统 组 成 牵 涉 众 多 的 专 业 领 域 这 么 庞 大 的 系 统 需 要 非 常 专 业 化 的 软 件 开 发 分 工 整 合 不 同 厂 商 有 特 色 的 专 业 系 统 是 医 院 信 息 系 统 的 发 展 趋 势 医 院 信 息 化 能 够 取 得 成 功 必 须 保 证 这 些 系 统 的 有 效 集 成 和 数 据 的 高 度 共 享 然而这些系统通常是随着医院的发展需求逐步 建设的 它们来源于不同的厂家 基于不同的技术 缺乏统一的信息交换标准 这些系统的集成整合已经逐渐成为 医院数字化发展亟待解决的主要问题 Orion医院信息集成平台的构建方案着眼于在医院内部实现医疗临床信息的集成重组 利用先进的技术手段 在最大程度保护医院已有IT系统投资的基础上 建立面向临床面向科研面向集团化管理的信息技术平台 实现医疗 临床信息的统一访问和深层次利用 促进医院内部信息流的通畅 从而实现医疗服务质量 医疗管理质量和医疗科 研水平的提高 更好的为患者服务 在实现医院内部临床信息整合的同时 统一设计和实现临床信息的对外交换共 享的模型 从而方便地实现与社区医疗 区域医疗和公卫系统的衔接 2 系统建设目标及设计要求 系统间的整合 集成和扩展一直都是制约医院数字化发展的主要障碍 由于不同厂商之间的产品不兼容 使得 医院整体信息化步履维艰 通 过 建 设 一 个 规 范 的 系 统 集 成 平 台 在 IHE HL7 等 国 际 标 准 的 基 础 上 制 定 覆 盖 医 疗 所 有 业 务流程的系统集成规范 开发基于规范的系统集成平台 为遗留的 当前的以及将来的系统提供了一个统一且标准 的数据交换和工作流协同的平台 通过本方案的实施 我们准备着重解决如下两个关键问题和达到相应的设计要求 2 1 解决问题 一 医疗临 床信息连续性及相关性 基于现有的 HIS CIS LIS PACS 等应用系统 实现医疗机构内部及之间信息的互操作性 需要在医院内部 的各个分立的业务系统之间构建基于信息交换标准 如 HL7 的医疗临床信息集成平台 该平台建成后 实现规范系统集成的信息交换标准及相应的接口规范标准 以信息技术的手段 在更高的层面 上进行信息集成 考虑到当前各个医院内部的 HIS LIS PACS 电子病历等医疗信息管理系统和医疗辅助系统都 已基本成型 因此医疗服务信息技术共享平台与这些已建成系统的业务关联性主要表现在集成层面 除非必要 不 强制要求原有系统进行根本性改造 而是以信息服务的方式或标准映射的方式与医疗服务信息技术共享平台进行信 息服务级衔接 2 2 解决问题 二 医疗临 床信息标准化及再利用 建立以病人为中心 以优化流程为向导 以信息标准为基础的医疗临床信息标准化 电子化 语义化处理平台 在实现临床信息采集与存储的基础上 实现临床信息的深度利用 医疗临床信息标准化及电子化 就是将各类临床信息整合成一个标准化 可计算的模型 该模型不是一个简单 的医嘱电子化 而是一个能够应用先进的数据分析技术的临床信息模型 从而使得医务人员可以针对具体的疾病和 患者情况 选择最佳的医疗计划和技术 医疗临床信息标准化及电子化的另一个重点就是以病人为中心 将所有电子化的医疗临床信息进行组织 形成 以患者为核心的统一信息视图 借助上面提及的医疗信息集成平台 结合病人的主索引机制 EMPI 对 HIS CIS LIS PACS 等信息系统进行信息集成 以提供完整而准确的病人临床信息 2 3 设计要求 针对集团医院运作的实际需要 实现系统间的互联互通及互操作性 集成平台的设计具体要求包括以下几个方 面 一是先进性 系统必须严格遵循IHE ITI技术框架及卫生部 基于电子病历的医院信息平台技术规范 要求 符合国际医疗信息交换技术发展潮流 二是可扩展性 系统规划设计必须站在医院的全局高度 充分考虑到医院内各个业务系统接入甚至协作医院接 入等互联互通需要 并按照国际标准设计接口 确保今后和新增业务系统或其它院区信息平台的衔接 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 5 三是可靠性 系统应具有高可用性 支持 7x24 小时工作模式 同时系统提供完备的容灾技术 以利于抗干扰 运行 提供系统运行日志 以利于及时纠错排障 四是安全性 系统提供严谨的用户权限管理和重要操作监控记录 保证系统使用的安全性 提供可靠的数据传 输技术和患者隐私保护措施 保证数据安全 3 Orion Health 公司及其系统适用性 Orion Health是新西兰的一家100 专注于医疗健康领域的软件上市公司 它成立20多年来为全球医疗市场提 供了世界一流的解决方案 方案通过异构系统之间的医疗信息交换以及将健康信息在一个统一门户上的整合 解决 了 信息孤岛 和 信息烟囱 的问题 进而提高了医疗质量和临床决策的精度和速度 Orion Health医院系统为临床医护人员展示了一个清晰 合理的病人记录 并可在其现有的临床工作流程中使 用 Orion Health医院系统能提供准确和关联的完整病人信息 可优化临床应用工作流程 与其他医疗产品进行集 成之后 就可以很容易地在这些系统之间共享信息 Orion Health医院系统利用强大的集成引擎Orion Health Rhapsody 对所有现有和老旧系统的数据进行了无 缝集成 Rhapsody强大的集成能力允许新的系统和模块成功地集成到现有的系统中 Orion Health医院系统本身可 以很容易地被集成到现有的系统架构内 而不需要更换现有的临床系统 如实验室信息系统 放射科信息系统或其 他专业系统 Orion Health 医院系统的灵活性 使得医疗机构能够根据不断变化的需求 对它迅速进行改动 使实施新的医 护模式成为可能 并且可以与其他医疗机构合作对病人进行医疗协同服务 3 1 Orion 产品优势 Orion Health 公司作为全球化的 独立运营的电子健康软件公司 已经在互连互通和互操作性的解决方案上为 医疗机构 医院和区域提供过其公认且可靠的经验 公司的 Rhapsody 集成引擎更是以集成平台的核心软件成为享 誉全球的品牌 常年居于美国 KLAS 排名的三甲位置 选择新西兰奥联公司作为集成平台的原厂商 将获得以下优 势 Orion Health 公司是全球最突出的医疗保健互操作性解决方案的供应商 也是美国健康信息交换的主要 供应商 公司的业务遍及全球 30 多个国家 并在 27 个国家设有分公司及办事处 Orion Health 公司拥有全球最专业的医疗信息服务团队 其全球服务中心能全天候为客户提供支持服务 Orion Health 公司的集成引擎获得了美国 MU FDA 和英国 ITK 体系的认证 美国有 49 个州的联邦疾控中心选择 Orion Health 公司的集成引擎作为首要的消息传送软件 美国马萨诸塞州联手 Orion Health 公司打造州级医疗信息交换平台 并获得奥巴马政府特批的医疗信息 建设资金 新加坡选择 Orion Health 公司的医院解决方案 包括集成引擎 建成全球首个国家电子档案 中国有 130 多家医院 大多为三甲医院 在使用 Orion Health 公司的软件 在帮助医院实现医疗信息系统的全面互连互通和互操作性的同时 Orion Health 的 Rhapsody 集成引擎还通过 以下的特性提升用户的使用体验 易于使用 支持复杂的集成要求 集成引擎的开发实施都封装成各种控件模块 绝大部分通过配置即可 完成 仅有少量部分需要用到简单的 JavaScript 脚本和 SQL 语句 集成引擎可独立安装及运行 本身不依托任何数据库系统 引擎的消息存储库是基于文件系统 稳定 快速 支持标准化 内置多种国际主流的医疗信息交换标注 如 HL7 和其最新的 FHIR 标准 同时集成引擎提 供图形化的映射组件 无需业务系统进行接口改造即可完成标准转换 集成引擎支持 IHE 标准 包含 IHE 交换工具 集成引擎内置集成测试功能 可以对流程中的每一个节点的配置进行对比测试代码的语法及逻辑错误 集成引擎提供简化的日常监控 提供可通过网络浏览器访问的中文监控界面 基于安卓和 iOS 系统的手 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 6 机终端监控和将多个引擎的监控集中在同一个页面上进行展示的仪表盘 集成引擎内置版本控制 可以监控和回滚业务逻辑配置上的修改 集成引擎的配置迁移简单迅速 可以通过导出 导入单一的配置文件来实现 4 方案描述 方案设计的数字化集成平台利用消息中间件的企业服务总线 实现各业务系统的数据级整合 它主要包括如下 建设内容 建立一个 IT 基础平台 建立一个符合 SOA 设计理念的 可扩展的 IT 基础架构 为医院内部多业务系统 的接入提供底层支撑 规范临床数据的收集 存储和共享方式 确立以 HL7 CDA 为标准的临床信息模型 实现基于 IHE 的临 床数据共享交换架构 同时基于先进的语义分析技术 实现临床数据的深度利用 规范业务数据交换标准和系统接入方式 确立以 HL7 为标准的业务数据交换 支持 HL7 标准业务数据与 非 HL7 标准业务数据的转化机制 形成一套规范的集成接口的设计要求规范 指导未来的系统接入 提供统一的医疗数据访问服务 使用一个统一视图对医院的病人信息进行访问 确保医院内的临床医生 能够无缝访问完整的病人记录并获得相同的病人诊疗信息 如上图所示 在整个系统架构中 Orion 的解决方案主要分为以下几个层次 集成服务层 以总线的方式构建集成平台 负责实现各个接入系统之间的信息交换功能 数据服务层 负责整个数据中心库的数据管理 即数据中心库 页面展现层 构建业务门户 实现单点登录和个性化处理 根据对需求的分析和理解 本项目的建设应该分成两个关键部分 医疗信息集成平台 使用 Rhapsody 引擎为医院内各个业务系统建立一个集成平台 规范临床信息模型 及信息共享接口标准 规范系统集成的信息交换标准及相应的接口规范标准 以及建立对外的统一数据 交换接口 此集成平台在信息交互的过程中将有效临床数据存入数据中心库 CDR 中 并通过配套的 Portal 进行展示 外部交换平台 形成基于标准的外部信息交换 形成院间交换 同时预留与公卫 医保等信息的交换接 口 从而实现基于标准的区域医疗信息共享交换体系 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 7 为保证院内对同一个患者 但分布在不同系统中的个人信息采集的完整性和准确性 需要建立患者主索引 Enterprise Master Patient Index EMPI 服务 从而达到通过唯一的患者标识将多个医疗信息系统有效地关联 在一起 建立患者主索引是实现大型医院内部系统集成以及医院集团内资源共享的必要条件 同时院内需要建立一 套完善的术语服务 以消除医院各业务系统间的术语差异性 实现对医疗术语的统一管理 综上所述 医院信息平 台的总体架构可参考下图所示 5 硬件需求 5 1 医院规 模定义 医院规模 床位 消息接收 天 消息处理 天 小型医院 1 199 30 000 300 000 中型医院 200 499 100 000 1 000 000 大型 或集团 医院 500 1 000 000 3 000 000 5 2 小型医院 预计医院规模 医院少于 200 张床位 医院业务系统大约接收 30 000 条消息 高峰时期的数据负载量大约为平常时期的 4 倍 每日引擎处理的消息量约为 300 000 条 或者是每秒 4 条 硬件推荐 Windows Server 或者 Linux o CPU 8 核 Intel Xeon 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 8 o 内存 8GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID1 o 64 位操作系统 o UPS 电源 5 3 中型医院 预计医院规模 医院拥有 200 500 张床位 医院业务系统大约接收 100 000 条消息 高峰时期的数据负载量大约为平常时期的 4 倍 每日引擎处理的消息量约为 1 000 000 条 硬件推荐 Windows Server 或者 Linux o CPU 8 核 Intel Xeon o 内存 8GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID1 o 64 位操作系统 o UPS 电源 5 4 大型医院 预计医院规模 医院拥有 1200 张以上床位 医院业务系统大约接收 1 000 000 条以上的消息 高峰时期的数据负载量大约为平常时期的 4 倍 每日引擎处理的消息量约为 15 000 000 条 硬件推荐 Linux o CPU 16 核 Intel Xeon o 内存 16GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID10 o 200GB 用于其它数据 RAID10 o 64 位操作系统 o UPS 电源 Solaris o CPU 8 核 UltraSPARC 或者 SPARC64 o 内存 16GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID10 o 200GB 用于其它数据 RAID10 o 64 位操作系统 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 9 o UPS 电源 HP UX o CPU 8 核 Intel Itanium o 内存 16GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID10 o 200GB 用于其它数据 RAID10 o 64 位操作系统 o UPS 电源 AIX o CPU 8 核 Power Processor o 内存 16GB o 36GB 的硬盘空间用于安装操作系统和引擎 RAID1 o 200GB 用于 Rhapsody 的数据存储 RAID10 o 200GB 用于其它数据 RAID10 o 64 位操作系统 o UPS 电源 6 容灾方案 根据医院信息平台的实际需求 一套良好的容灾方案可以更好的保证院内系统的平稳运行 Orion Health 的 Rhapsody 集成引擎支持主备模式的架构部署 active passive 在使用此种架构的时候 主被两台服务器上的引 擎将共享引擎消息存储库 物理文件夹 通常放置于存储区域网络上 Storage Area Network SAN 如下图 所示 当主服务器上的 Rhapsody 引擎发生异常时 备用服务器的引擎随即启动接管主服务器引擎的工作 由于两台 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 10 服务器使用的是相同的消息存储库 因此正在处理过程中的消息将会被继续处理而不会造成丢失或者需要原业务系 统重新发送 同时 所有的引擎连接都是通过一个虚拟 IP 完成 而这个 IP 永远指向正常工作的那台引擎服务器 7 实例解析 任何级别的区域医疗平台的信息初始来源都是医疗机构 医院 而医院信息系统对信息进行处理的第一步就 是收集和传递信息 通常信息流是伴随着各式各样窗口业务处理过程发生的 医疗事务就是其中一个典型的例子 对于整个医院信息系统来说 窗口事务处理的计算机系统就是一个完整的 HIS 数据收集端口 它们是 HIS 伸向信 息发源地的触角 感受器 以病人挂号 之后在就诊过程中需要进行血检的流程为例 信息流 以下称为 消息 就需要从 HIS 发送 到 LIS 上图是一个简单的将 ADT 入院 挂号 出院和转院 消息通过 Rhapsody 引擎从 HIS 系统发送至 LIS 系统 的简单流程图 图中包括 HIS 的 TCP Server 通信点 引擎通过此通信点监听一个端口 接收从 HIS 系统传来的 ADT 消息 同时也用 它向 HIS 系统发送收到消息的回执 ACK 或者 NACK LIS 的 TCP 代理的通信点 引擎通过此通信点向 LIS 系统开放的 TCP 端口发送从 HIS 系统收集到的消息 同 时等待 LIS 系统发送的消息回执 ACK 或者 NACK 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 11 E mail 客户端通信点 引擎通过此通信点向系统监控人员或者相关管理人员发送消息交互的状态信息 特别是 在发生错误的时候 及时通知相关人员 垃圾箱通信点 引擎通过此通信点回收不需要保存的 LIS 系统回执 HL7 回执生成器 引擎通过此控件在成功接收消息以后生成 HL7 标准回执消息 并传递给 HIS 的 TCP Server 通信点 JavaScript 过滤器 Handle NACK 引擎通过此控件处理从 LIS 系统发回的 NACK 回执 No operation 过滤器 引擎通过此控件将消息进行分流 在分流路径上的消息为原消息的一个副本 依上图所示 引擎将从 HIS 接收收到的 ADT 消息分流成两份 一份发给 HL7 回执生成器 然后将生成的回执 发还给 HIS 系统 如下图所示 当 HIS 系统接收到一个 ACK 回执的时候 表明此消息已经被引擎正常接收并开始进行处理了 设计由 Rhapsody 引擎发送回执的优势在于减少 HIS 系统确认消息成功发送的等待时间 在点对点的消息交互模式中 HIS 系统需要等待 LIS 系统发送回执 等待时间会相对较长 从而使后续消息的传送发生延时 更糟糕的是 如果 HIS 系统需要将消息同时发送给多个其它系统 如同时发送给 LIS RIS 和 CIS 采用点对点的交互模式 等待时 间会更长 因为 HIS 系统需要分别收到三个 ACK 回执才能确认消息完全发送成功 上图的设计也就避免了这一问 题的发生 同时引擎将另一份相同的 ADT 消息副本通过 LIS 的 TCP 代理发送去 LIS 系统 如下图所示 当 LIS 系统将回执返回给引擎的 LIS TCP 代理通信点的时候 引擎又将这份回执分流成两份 一份是正常的 ACK 直接发送给垃圾箱通信点丢弃 如下图所示 另一份为错误回执 NACK 如果存在 的副本 将其使用 JavaScript 过滤器进行简单处理以后 再通过 E mail 客户端通信点发送给相关人员 如下图所示 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 12 在很多情况下 一个高质量的路由一般是要对传递过程中产生的错误进行处理 如下图所示 以上是对一个简单的 HIS LIS 路由的分解 它展示了 ADT 消息在医疗机构内的传递方式 其他系统的互通 如 HIS PACS HIS CIS 可以以此为参照进行设置 当 LIS 或者 PACS 系统将检查报告或者影像图片发还给 HIS 系统时 消息传递方式和上图基本相同 不过路由上的逻辑将更为复杂 8 案例展示 8 1 上海市公共 卫生临 床中心 上海市公共卫生临床中心是复旦大学附属三级甲等医院 拥有金山总院与水电路分院两个院区 两院区相隔较 远 分别使用独立的业务系统 两院医疗信息无法共享 同一患者的临床信息在两个院区之间无法相互调阅 两院 医疗数据需要分别维护 导致整体上形成信息烟囱 造成了数据冗余 效率低下和资源浪费等问题 医院通过使用 Rhapsody 引擎 集成平台 将全院系统架构改造如下 新的架构解决了 集成平台的建设 各个系统直接与平台交互 降低各系统之间的耦合性 HIS 性能提升 两个院区通过院内平台公用一个 RIS 系统 检查结果平台分发到两个 HIS 两个院区通过院内平台公用一个手麻系统 手术申请通过平台汇总给手麻系统 手麻系统返回的收费信 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 13 息 领药信息通过平台分发到各个 HIS 系统中 基础数据同步 统一维护 统一分发 保持系统的数据一致性 同一个患者在两个院区的传染病信息只需上报一次 两个院区的患者统一管理 两个院区的临床信息实现以患者为中心共享 并且集成到医生工作站供医生快捷调阅 两个院区的医技报告实现共享 通过平台 实现两个院区的处方统一点评 实现两个院区的科室 专家统一可以在手机上统一预约 并将预约信息反馈给各自的 HIS 系统 此架构为典型的集团医院信息集成平台架构 8 2 复旦大学附属儿科医院 复旦大学附属儿科医院通过使用 Rhapsody 引擎对现有 HIS CIS LIS PACS 进行基于国际医疗信息交换标 准 HL7 标准的集成 将医院的历史数据和实时产生数据汇总到临床数据中心 实现以患者为中心的门诊 住院诊 疗过程的数据汇聚 为临床医护人员提供患者 360 视图 其系统架构图如下 8 3 Inland Empire Health Information Exchange Inland Empire HIE 是一项集团化的非盈利性区域健康信息交换工程 它向跨美国 7 个州的 32 家医院共 900 多 万人口提供健康信息交换服务 该项目使用了 Orion Health 的集成平台 其中包括 Rhapsody 集成引擎 临床数据 库 CDR 和临床门户 Portal 它同时还选择了 Orion Health 的临床路径以及病人门户 Patient Portal 作为辅助工 具 向整个区域内的信息交换和访问提供帮助 在该工程中 Orion Health 平台的 Rhapsody 引擎提供了强健的可扩展的互操作性和数据集成 平台的临床门 户提供了快速的标准化数据查询 同时平台本身也具备了高度的延展性 为未来需求的增加提供了整合的可能 Orion Health 平台的使用立即给区域中的医疗机构带来了明显的帮助和改变 其中较为显著的是 一家公共检查检验实验室参与了该工程以后 节省了 30 000USD 的接口开发费用 一家联邦医疗中心大大提高了和加利福尼亚州免疫登记系统交互的效率 8 4 加拿大阿 尔伯塔州 加拿大的阿尔伯塔州选用了Orion Health 的临床门户来展示整个州的电子健康档案 EHR 选用的原因是 4 四月 2020 Orion 医院信息集成平台解决方案 V1 0 Copyright 2020 Orion Health group of companies 14 Orion Health 的临床门户可以基于不同的健康数据集提供统一的病人信息视图 同时它的网页界面具备很强的编辑 性 扩展性和配置性 以适应不同的需求 目前 阿尔伯塔州的电子健康档案 EHR 系统已通过Orion Health 的 临床门户整合了药品 检查检验报告 放射影响 就诊历史 病人列表等信息 同时提供PACS影像浏览功能 Orion Health 的平台在整个项目中提供了以下的优化和帮助 提高了医疗数据的利用率 降低了从区域内已有系统中获得以病人为中心的数据的难度 同时降低了系统改造成本 非常易于配置以适应不同机构的需要 提高了区域内多家医疗机构和医疗应用系统信息统一展示的精准性 通过简单的升级就可以整合新的医疗数据集或数据结构 非常易于实施 医护人员可以尽早的获取结果 降低了数据的延迟和重复的可能