医院集成平台建设方案.pdf

《医院集成平台建设方案.pdf》由会员分享，可在线阅读，更多相关《医院集成平台建设方案.pdf（113页珍藏版）》请在三一文库上搜索。

1、. 医院信息系统集成平台建 设方案 . 目录 1. 背景 . 7 2. 建设目标 8 2.1 实现医疗信息资源整合与利用. 8 2.2 实现医院数据中心建设 9 2.3 提供管理决策及临床决策支持. 9 3. 设计原则 . 10 实用性和先进性 11 . 安全性和可靠性 11 开放性、互连性和标准化 11 灵活性与可扩展性. 12 经济性与投资保护. 12 易管理和易操作性. 13 整体设计和多种应用相匹配 13 4. 建设方案 . 13 4.1 医院信息化建设面临的问题和难题 . 13 4.2 医院集成平台总体框架 16 4.3 标准化数据中心 18 4.3.1 建立数据中心的意义. 20

2、4.3.2 基础信息库 . 22 4.3.3 业务信息库 . 23 4.4.4 交换信息库 . 23 4.3.5 临床文档库 (CDR) . 24 4.3.6 临床数据中心构建方法 . 27 操作数据存储ODS 29 数据仓库 31 医学知识库 32 4.4 数据交换总线平台. 35 4.1.1. 数据交换总线技术特点 38 4.1.2. 数据交换总线功能特点 40 . 4.1.3. 基于数据交换服务总线的业务数据交互. 42 4.1.4. 业务规则引擎 错误！未定义书签。 4.1.5. 事件驱动引擎 错误！未定义书签。 4.1.6. 集团化医院信息交换平台. 44 4.5 公共消息服务平台.

3、 45 4.1.7. 支持 HL7 引擎服务部件. 46 4.1.8. 适配器服务部件 . 49 4.2. Ensemble集成平台中间件 51 4.2.1. Ensemble HIE 构成组件 . 52 4.2.2. Ensemble HIE 设计原则 . 55 4.2.3. Ensemble HIE 技术特点 . 56 4.2.4. Ensemble HIE 功能介绍 . 61 病人主索引（MPI ） 66 4.2.5. 病人主索引功能 . 68 4.3. 统一身份认证授权平台 71 4.3.1. 统一身份认证授权平台主要功能 73 4.3.1.1. 单点登录 73 4.3.1.2. 身份

4、管理 74 4.3.1.3. 授权管理 74 4.3.1.4. 安全审计 75 4.3.2. 统一身份认证授权实现方法. 75 医院决策分析平台. 77 . 4.3.3. 决策支撑平台技术架构 79 4.3.4. 决策支撑平台数据架构 80 4.3.5. 指标加工逻辑架构 82 4.3.6. 系统工作内容及技术路线. 84 4.3.6.1. 指标库构建与管理的工作内容要求 84 4.3.6.2. 指标库构建与管理的设计原则 89 4.3.6.3. 指标库构建与管理的技术路线 90 短信服务平台 90 4.3.7. 短信平台架构. 91 4.3.8. 短信平台功能模块 92 4.3.8.1. 通

5、知功能 92 4.3.8.2. 查询功能 92 4.3.8.3. 信息管理 92 4.3.8.4. 语音信箱咨询功能 92 4.3.8.5. 医院信息查询功能 93 4.3.8.6. 投诉 /举报 /建议受理功能. 93 4.3.8.7. 自动服务功能 93 4.3.8.8. 导医功能 . 94 后台运维管理系统. 94 4.3.9. 信息资源统一监控系统设计原则 97 4.3.10. 信息资源统一监控系统架构及技术实现. 98 4.3.11. 信息资源统一监控系统管理模型 100 . 安全保障体系 101 4.3.12. 隐私保护措施. 101 4.3.13. 网络安全保障. 104 4.3

6、.14. 数据保密性 106 4.3.15. 数据完整性 107 4.3.16. 恶意代码防范. 108 4.3.17. 性能保障措施. 110 4.3.18. 运行环境保障措施 111 4.3.19. 信息安全与审计保障措施. 112 5. 平台扩展 错误！未定义书签。 . 1. 建设背景 我国医院信息系统建设已经有三十年的发展历史，早期有所谓的All in One 的系统，所有的应用都由一个供应商提供，服务于不同目的的应用模块，包装在 一个软件包中，所有的数据库都是开放给所有的应用的，不需要接口引擎的设计。 然而，医疗卫生信息的复杂性决定了医院信息系统的应用越来越复杂，医院对信 息的需求也

7、不断扩展， 任何一个 HIT 厂商不可能提供医院所需要的全线产品（也 包括国外的 HIS 厂商） ，要实现真正一体化的医院信息系统，必须引进不同厂商 的信息系统产品。 因此在同一医院环境下， 集成不同厂商的产品就成为医院信息化建设过程中 必然遇到的问题。 一开始几个厂商的产品要达到互连互通，往往是采用点对点的 接口方式，因为这种方式简单、易行且成本低，例如，将一个医疗保险的结算系 统与医院的住院及门诊病人的费用管理系统集成。然而，当医院的应用扩展到十 几个乃至几十个应用系统时，问题就变得困难起来。 医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。 然而这些系统通常是随着医院的

8、发展需求逐步建设的，它们来源于不同的厂家， 基于不同的技术， 缺乏统一的信息交换标准， 这些系统的集成整合已经逐渐成为 制约医院数字化发展的主要障碍。 而如何把这些系统连接实现各部门各专业信息 共享就成了医院信息化建设中面临的一大难题。如果以传统的方式在各系统之间 做接口的话就将出现众多的接口，这将给医院信息系统的稳定性、安全性、可靠 性、效率等带来巨大的隐患， 同时以让医院的运行维护成本成倍增长，如果医院 . 要对其中一个应用系统进行升级或更换就必须再做众多数据接口。 随着国家新医改政策的实施落实，以医院为单位的管理模式已不能满足广大 人民群众日益增长的医疗卫生需求， 信息共享是实现信息价值

9、最大化的重要途径 之一，区域医疗信息共享是信息化发展的必然趋势，为了实现医疗信息的区域化 共享，同样需要在医院内部把不同数据资源进行集成整合。 在此背景下通过医院信息集成平台来代替原来数量众多的点到点数据接口， 为医院信息化建设提供标准和规范，只要各应用系统都支持这些标准和规范，原 则上就能与应用信息平台进行数据交换，并能同与平台相连的应用系统进行数据 交换。 2. 建设目标 2.1 实现医疗信息资源整合与利用 为实现各业务系统信息互联互通，如果采用推倒重建的方法， 就有可能将浪 费大量的资金， 并引起业务震荡。 通过医院信息平台的建设尽量减少不必要的重 复建设。医院原有的各业务系统和信息系统

10、通过医院信息平台提供的接口实现整 合，继承已有的数据资源和服务。 通过建设医院信息平台， 将原先分布在各业务系统中的信息交换整合到医院 信息平台， 实现医院各个科室之间、 医院之间信息的互联互通， 最大限度地方便 病人就医、方便医院一线医护人员工作、方便各类管理人员分析决策。 . 2.2 实现医院数据中心建设 为了使医疗活动可以准确、快速地进行，医疗服务者不但要接收到清晰的医 疗指令信息， 还需要掌握服务对象相关各方面信息、记录服务对象在医疗活动中 的情况及结果； 因此要保证数据信息的高效利用，达到一处采集多处利用； 以病 人为主线， 将病人在医疗机构中的历次就诊时间、就诊原因、 针对性的医疗

11、服务 活动以及所记录的相关信息有机地关联起来，并对所记录的海量信息进行科学分 类和抽象描述，使之系统化、条理化和结构化。 建设医院数据中心，通过数据中心实现不同信息系统、组织机构间信息资源 整合，实现业务数据实时更新，确保信息同步；满足管理决策、临床决策、科学 研究、对外信息共享； 实现统一的数据仓库的设计及技术文档、元数据管理等功 能。建设医院信息集成平台需制定统一的信息交换标准，统一卫生信息标准与数 据字典。 2.3 提供管理决策及临床决策支持 凭借数字化医疗信息服务的先进技术作为强有力的支撑，利用更为先进的信 息化手段，掌握工作的主动权，把传统事后处理转为实时监控。建设医院信息 平台，规

12、划医疗资源，实现诊疗流程再造，提高医院运作效率，提升医院的整体 服务能力， 有效解决就诊 “三长一短 ”现象；建立统一的门户信息， 为病人的全 面医疗健康信息的保存、传递、查询提供有效的数据，对数据的快速实时查询。 通过对数据进行分析和处理， 对信息进行有效利用， 帮助管理者进行科学管理决 策，帮助医生进行基于循证的医疗决策和医疗计划的制定，支持临床应用科研的 . 开展。 3. 设计原则 目前，大部分医院的医疗信息系统实现数据共享是采用了传统点对点通信模 式的方法，这样的方式需要每两个系统之间都有专用的接口，且当有新系统添加 进来的时候，也必须要单独为每个子系统开发与新系统相应的接口，工作量极

13、大。 这样的专用接口也存在很大风险，容易导致系统崩溃， 中断医院正常的医疗业务 流程。 因此， 需要建设一个能与全院所有医疗信息系统直接沟通的数据集成平台， 以此为中介， 实现各系统间的数据共享和交互。建立一个以现有信息系统和数据 资源为基础，符合标准的、高可靠的、开放式医疗卫生信息共享平台，实现区域 卫生协同和诊疗信息共享； 在平台上提供区域级的标准组件服务、 诊疗知识服务， 以及协同医疗、 卫生监管和健康管理等应用服务，有效提升医疗卫生服务水平和 服务能力，支持创新具有区域特色的开放、实用、共享、持续的医疗卫生服务模 式。 目前通常采用基于 中间件模型和数据仓库 等方法来构造集成的系统，

14、这些技 术在不同的着重点和应用上解决数据共享和为企业提供决策支持。在方案设计时 遵循了以下原则： 统一性 统一设计原则统筹规划和统一设计系统结构。应用系统建设结构、数据模型 结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、 从长远的角度 . 考虑。 实用性和先进性 当今的计算机技术日新月异，因此要求选择的方法、技术、工具、设备不仅 要保证具有先进性， 而且要保证技术方向的正确性。 设计的方案要结合考虑实用 和兼顾今后发展的目的， 不论在服务器、 软件及中间件等软硬件产品方面，还是 在方法论、 工具方面， 都应选择当今国际上成熟的、主流的并领先的产品和技术 来适应更高的数据处理要求，

15、以满足医疗管理信息系统未来5-10 年的需求发展， 并应具有良好的扩展潜力，以适应未来业务的发展和技术升级的需要。 安全性和可靠性 设计的整体方案要通过多种安全技术和防护手段，保证系统自身的安全性， 保证服务不会中断。 在本项目方案中， 最重要的设计出发点就是系统的安全，关 键设备或设备核心部件应当采取冗余设计，能够避免单点故障导致系统整体或重 要功能的丧失， 保证系统平稳运行， 最大限度减少停机时间而且包括便于故障排 查、恢复和日常的运行维护的机制。在采用硬件备份、冗余、负载均衡等可靠性 技术的基础上， 采用相关的软件技术提供较强的管理机制和控制手段，以提高整 个系统和数据的安全可靠性。 开

16、放性、互连性和标准化 系统必须采用国际、国家标准、协议和接口，能与现有的和未来的系统互连 . 与集成，支持 HL7、IHE、DICOM 、ICD10 等标准。 灵活性与可扩展性 设计的方案应当考虑系统的灵活性和可扩展性。系统建成后要能够满足业务 近期、中期甚至长期时间范围数据和业务快速增长的需要。适应目前需求的基础 上，能够满足医院以及相关医疗机构不断发展的信息化需要，充分地为将来可预 见和不可预见的性能扩充留有余地， 并具备方便地扩展系统容量和处理能力和支 持多种应用的能力， 可以根据业务发展的需要进行灵活、快速的调整， 实现信息 应用的快速部署， 而且新功能、新业务的增加能够在不影响系统运

17、行的情况下实 现。系统要充分考虑到扩容和升级的需要，能灵活方便地适应未来系统可能的变 化。选择应用开放性标准的产品，确保设备的兼容性； 通过系统结构的合理设计 和适度资源冗余，为未来的系统扩充打下基础， 保证需求增加时系统的平滑扩充， 保证前期的投资。 经济性与投资保护 方案所选用的技术和产品应当全部遵循通用的国际或行业标准，各系统模块 之间有良好的兼容性和较高的性能价格比。从长远来看， 也便于系统的升级和移 植或运行其他应用软件， 实现整体效益， 而且能以较低的成本、 较少的人员投入 来维护系统运转，提供高效能与高效益的医疗信息服务。 . 易管理和易操作性 设计方案支持全面、完善、便捷、统一

18、的系统管理和应急处理预案，保证一 旦发生问题能在最短的时间内处理解决。 而且，系统应具有良好的用户操作界面、 完备的帮助信息。集成完备的运行监视系统、 良好的管理界面工具或远程控制台， 易于管理人员对其进行管理和维护，系统参数的维护与管理通过操作界面实现。 整体设计和多种应用相匹配 集成平台需要进行统一设计，但是考虑到应用的多样性以及业务、部门等的 差异，整体设计又不要过于制约具体的应用开发，要为各种应用开发提供灵活的 手段。 可维护、可管理性 通过统一网管，对信息系统平台进行统一管理，提供可视化的网络拓扑、网 络状态监控、故障事件实时预警和告警、异常网络流量统计等。 4. 建设方案 4.1

19、医院信息化建设面临的问题和难题 难题 1:系统集成度较低 . 医院信息工作以采集到的数据范围与数量为主要工作目标，而这些数据 采集后的共享与深度利用往往被忽略。目前，很多的医院都建设有独立的 PACS、LIS、手术麻醉等系，这些系统很多是科室根据自身业务需要，由科 室主导建立起来的。这些系统在建立时并未考虑与医院信息系统的集成，或 者当时医院信息系统并不具备集成应用的条件，所以就成为孤立的系统。由 于信息没有利用好，往往使医院无法看到信息化工作的真正回报，医院信息 化工作就无没得到医院领导者们足够的重视。对于信息化工作来说，信息的 采集基本上是投入性的工作，而信息的有效、及时利用才是信息化工作

20、的收 益。 难题 2：规范化、标准化程度低 我国医院信息化建设的过程中，采用的标准、规范很少，信息的共享与 交换主要以 “点对点 ”的方式进行，这种方式个性化极强，往往会因为系统 升级、更换厂商而带来严重后果。 传统点对点模式 . 基于传统“点对点”直连数据接口方式来集成系统，如果另一个应用程序 系统 A（第 n+1 个）必须集成进来，将需要产生、 文档化、测试和维护2n 个新的接口。而更糟的是，必须修改每个已有的应用程序中的代码以包括进 新的接口，因而将增加大量的成本和复杂度。: 点对点集成方式存在以下问题： 接口不规范 接口间的调用方式各不相同，如有存储过程、视图、中间表、应用程 序、动态

21、库等等 ,无法形成统一的接口规范。 数据不共享 虽然现在大多数系统间均有做接口进行数据交互，但往往只做到最 基础的数据采集上，信息间的共享并不充分，如急诊、危重病人的 报告、异常的报告无法做到第一时间提醒医生。医生也无法主动查 询病人的报告进行到哪一步。 数据不一致 由于数据共享不充分，导致多数接口在重复做，往往会出现数据在 不同系统间不一致的情况，如同样的检验报告，在LIS系统下看到的 格式有可能与 HIS看到的不一样， 甚至连数据都有可能不同， 这就给 医生带来不小的困扰。 数据入口多 由于点对点的接口方式，数据重复存在于各个系统中，无法形成统 一的数据中心模式，造成同一数据多个采集入口。

22、 . 接口安全性差 很显然在不同供应商之间开放数据库用户进行连接视图或读写中间 表，这种接口方式的安全性较低，一旦出现数据异常责任往往无法 追踪。 接口耦合度高 点对点集成方式导致接口耦合度高，不利于后期的扩展及维护。 各系统界面、用户分散，无统一管理机制 用户必须来回切换登录不同系统 用户必须记住不同系统的不同用户及密码 系统维护成本高 4.2 医院集成平台总体框架 . 医院集成平台总体架构图 如上图所示， 本平台中医院信息平台信息交换层，主要用于实现全院级应用系统 互联互通的需求， 主要任务以满足临床信息、 医疗服务信息和医院管理信息的共 享和协同应用为目， 标采集相关业务数据， 并对外部

23、系统提供数据交换服务；提 供支持 HL7标准的消息传输机制，建立服务之间的通信、连接、组合和集成的服 务动态松耦合机制，为集成遗留系统和新建基于SOA 的应用系统的服务集成提 供了支撑。 并在此基础上， 开发面向应用的业务适配器组件，实现各集成应用之 间可管理的接口透明， 为医疗应用提供了便捷、 一致、安全并符合标准的丰富接 . 口，保证服务之间信息的可靠传送，实现不同操作系统，不同数据库、中间件运 行平台及其基于这些平台之上开发的应用软件的服务集成。 信息资源层是对于各个业务系统产生的医疗业务信息、临床信息、医院管理 信息，通过业务信息库进行整合，主要服务于建立全院级的病人主索引的需求、 建

24、立全院级电子病历的需求， 并为医院信息二次利用、 为患者提供公众服务、 与 外部互联奠定数据基础； 支持结构化数据存储， 以XML格式提供结果数据， 便于 相关系统进行二次处理（如科研或质控） 。 4.3 标准化数据中心 依据卫生部 2011 年 8 月 2 日发布的城乡居民健康档案基本数据集 ，该标 准于 2012 年 2 月 1 日起正式实施。 该标准规定了城乡居民健康档案基本数据集 的数据集元数据属性和数据元目录。 数据元目录包括城乡居民健康档案个人基本 信息、健康体检信息、 重点人群健康管理记录和其他医疗卫生服务记录的相关数 据元。适用于城乡居民健康档案的信息收集、存储与共享,以及城乡

25、居民健康档 案管理信息系统建设。 标准中规定了卫生信息中标识类数据元的数据元标识符、数据元名称、定义、 数据元值的数据类型、 表示格式和数据元允许值内容。 数据元目录包括标识信息 相关数据元。 按此标准建设的数据集内容涵盖了人员、医疗机构、医疗卫生术语、电子健 康档案的数据集、 数据元和各种代码标准的注册管理，数据标准化则提供了在数 据注册过程中基于标准化转换服务， 其囊括了区域卫生业务数据的所有数据标准 规范，根据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准， . 并通过数据校验机制保障数据中心的数据进行标准化。 标准数据完全匹配国家对全程健康档案服务和注册服务的要求。数据注册

26、涵 盖了人员、医疗机构、医疗卫生术语、电子健康档案的数据集、数据元和各种代 码标准的注册管理，数据标准化提供了在数据注册过程中基于标准化转换服务， 其囊括了区域卫生业务数据的所有数据标准规范，根据应用领域分为数据类标 准、技术类标准、 管理类标准和业务类标准， 并通过数据校验机制保障数据中心 的数据进行标准化。 依据标准建设的中心数据库数据集内容包括： 1)基本数据字典：科室字典、员工字典、用户字典等； 2)患者注册基本信息； 3)门诊业务数据结果集：挂号记录、诊断记录、处方记录、结算记录等； 4)住院业务数据结果集：住院记录、诊断记录、医嘱记录、结算记录等； 5)健康体检数据结果集：体检登记

27、记录、诊断记录、体格检查记录、评估 报告、费用记录等； 6)电子病历结构化数据集； 7)决策分析数据集； 8)医院管理指标数据集； 上述部分结构主要是结果集的采集存储，为了满足不同平台之间或系统之间 数据交互，涉及的业务相关数据集： 1)住院患者信息相关表：如在院患者记录表、出入转记录表； 2)临床路径相关表； 3)单据记录及状态相关表：单据表、单据状态事件表等； . 4)电子申请单记录表及医技预约反馈记录表； 5)检验、检查报告记录表； 6)系统间消息交互数据集； 4.3.1 建立数据中心的意义 数据中心是医院的业务系统与数据资源进行集中、集成、共享、分析的场地、 工具、流程等的有机组合。

28、它将不同业务系统之间需要共享的信息、综合业务系 统与区域共享需要的业务数据， 按行业标准转换明文方式长期存贮在一个数据仓 库中。 当前医院各业务系统面临的最大问题： 系统业务无统一数据标准 数据标准是指卫生信息采集表的处理过程中涉及到的标准，主要是指数据采 集里的标准， 定义各类数据标志的含义， 规范数据采集的数据集能在不同系统之 间传递的电子报文或者是电子文档。 由于医院各业务系统产生的数据需要长期保存，但建立在这些业务数据基础 之上的各种字典，由于医改的需要在不断地变化，系统中各类字典也不断膨胀， 为减少业务数据错误与系统维护工作，很多系统设计者只能将明文保存的基础业 务数据表，造成业务系

29、统运行效率低下，维护困难。 数据中心的建立， 就是要将原各系统不能共享的孤岛信息，转换成符合国家 或卫生部相关标准的数据集。 为全院系统打造一个共享平台，统一字典维护， 降 低业务系统标准字典维护量， 为区域共享提供可进行信息统计与挖掘的标准数据 集。 . 涉及到医院系统的主要标准有：疾病代码、科室分类、药典、非药品记费项 目。 业务系统数据接口 由于医院业务管理系统， 是一个长期运行， 不断完善的情况下壮大成长起来 的，医疗信息技术标准没有惯彻到整个业务中。由此造成上线系统越来越多，各 系统之间数据的调用频繁， 数据接口也就越来越多， 越来越复杂。 经常出现某个 业务系统升级无法到相关信息，

30、 或因某业务系统升级造成其它业务系统数据混乱 的现象。 医院业务需求扩张 各业务系统随着用户应用不断深入产生新的业务需求：如质控、CA 认证、 闭环医嘱等。 这些应用必须建立在多个系统之上，若将这些应用需求不断加入到 基础业务系统中， 势必造成基础业务系统数据量不断膨胀，造成基础业务系统的 可维护性与运行效率越来越差。 病人信息综合处理 目前医院的系统是按功能进行划分的，如：HIS 系统保存病人费用与医嘱内 容、LIS 保存病人检验数据、 PACS 保存病人影像信息等。医生对病人的诊断往 往来源于医院各业务系统， 对其数据进行综合的结果。 将这些来源不同系统并标 准不统一信息， 整合在一个界面

31、中进行综合处理，存在巨大的障碍与分析效率低 下的问题。 将基本业务产生的数据， 对其进行质量控制、 清洗、转换保存到综合医疗业 务数据仓库， 长期海量保存。 使基本业务与综合医疗业务的运行建立不同数据仓 库中，实现分布式并行运行， 有效地解决了高效、 稳定的前台业务与多变的综合 . 展示业务之间运行效率的矛盾，极大地提高了基础业务系统的维护性与稳定性。 4.3.2 共享基础信息库 基础信息库集中了整个医院信息平台的基础信息和共享数据，是为各个子系 统提供基础信息服务的。 基础信息库包括了患者的人口学信息、医疗卫生人员的 注册信息、以及各种医疗卫生、公共卫生术语字典数据及流程模板数据等。 病人基

32、本信息是基础信息数据库中的核心内容之一。无论是电子病历、医疗 业务、临床信息，还是疾病分析信息和公共卫生条线数据都是以病人基本信息为 基础的。在此基础上，实现电子病历、医疗业务（含临床数据）的关联。 医护人员库是基础信息数据库中的另一个核心内容，以医护人员信息为基 础。可以建立医院诊疗资源注册库，可以作为医院管理以及绩效考核的基础。 数据元字典是辅助各类医院业务、临床业务的基本数据元、代码集以及数据 字典；以及包含了医院各种业务、 流程说明模版的操作模型。 流程模版库是包含 了医疗机构医疗业务、 临床路径、管理流程、财务结算等所有信息系统正常运转、 分布协同的规则库。 通过流程模版库的流程引擎

33、指导，能够明确患者在医疗机构 内如何进行就医， 临床医生如何对患者进行准确诊断，防保医生如何对疾病进行 控制和分析， 管理及后勤人员如何对医疗资源进行合理分配或者补充采购、财务 结算人员如何统计和控制医院的收入和开支。流程模版库是医疗机构保证正常运 转的核心，对各级医疗卫生人员和患者的医疗行为起着规范和指导作用。 . 4.3.3 原始业务信息库 业务信息库是整个医院信息平台的数据基础，主要存储原始业务产生的数 据，以未经过进一步加工的数据为主。包括诊疗业务流程产生的结果数据、医疗 服务管理数据以及医院运营管理流程产生的结果数据。这些未经修改的数据， 作 为电子病历的备份存储， 在以后发生任何疑

34、问时， 可调阅业务信息库中的数据进 行核实。业务信息库中的数据要求在存储后不能被修改和删除，将作为系统的原 始凭证被永久保留。 从时效性和实际业务需求出发， 业务信息库至少也要保存 50 年之内在线业务操作及结果数据。 医疗机构内部的业务数据分布于不同的信息系统自身的数据库之中，因此需 要接入到覆盖整个医疗机构的信息平台上，以提供对原有业务数据的整合、 利用 服务，并为机构之间以及业务系统之间的联动提供支持。 业务系统通过设置交换信息库作为与信息平台的接入端代理，来实现业务系 统与信息平台的互联互通性。 体现在数据结构层面， 就是业务信息库通过交换信 息库实现数据的接入。 除了在信息平台上保存

35、即时产生的，符合临床诊疗要求的 各种业务原始数据以外， 还需要以患者的基本信息为基础，整合患者历次就诊的 就诊履历， 完善患者的医院电子病历。 患者的基本信息保存在基础信息库中，电 子病历保存在临床文档信息库中，也就是说，业务信息库根据基础信息库中的患 者信息进行整合，并最终形成存储在临床文档信息库中的电子病历。 4.4.4 交换信息库 交换信息库是信息平台的数据转换枢纽，包括中心交换库和对外交换库。中 心交换库的作用主要是对医疗机构内部信息系统业务数据的采集、整合以及医疗 . 机构内部信息系统之间业务联动。 对外交换库的作用主要是实现医院信息平台与 区域信息平台的数据交互。 中心交换库 考虑

36、到医疗机构各个信息系统相对的独立性以及数据之间的关联性，我们在 医院信息平台中设立中心信息交换数据库。中心交换库是采集医院各个业务信息 系统的信息， 并整合程电子病历信息的区域， 也是各个业务信息系统基础信息和 专业信息交换的信息存储区域。 中心交换库存放各个信息系统交互的信息，包括 了电子病历信息、基础信息（患者基本信息、医疗人员信息等）、专业信息（医 疗业务、临床数据、检验检查报告以及影像数据等）。 对外交换库 对外信息交换库是医院信息系统与区域卫生信息平台进行数据交换的信息 存储区域。 为保证系统的相对独立， 我们设立对外信息交换数据库。对外交换库 存储要推送到区域卫生信息平台的电子病历

37、，同时也存储着从区域平台推送来的 健康档案。在对外交换库中完成电子病历与健康档案的相互转换。 4.3.5 临床文档库 (CDR) 电子病历存储服务具体由临床数据存储库CDR(Clinical Data Repository) 来实现。电子病历主要由临床文档组成， 临床文档是电子病历中各类业务活动记 录的基本形式。 临床文档中的数据存在着一定的层级结构关系，其中有包含与被 包含的关系， 也有按同类属性相互嵌套的关系。临床文档的结构化和标准化，是 电子病历实现语义层数据交换与共享的基本要求。 CDR是医院为支持临床诊疗和全部医、教、研活动而以病人为中心重新构建 . 的新的一层数据存储结构。 它应该

38、是物理存在的， 而不仅仅是概念存在或者是逻 辑存在。它是医院基于电子病历的信息平台的核心构件。它是否存在可以作为医 院是否拥有真正电子病历系统的标志。它与直接支持医疗操作的前台业务信息库 不同，其数据来自这些业务系统， 但与前台业务流程无关。 它也不是通常意义上 的数据仓库， 因为它的内容是随着医院业务活动动态变化的，并且直接支持医生 /护士对病人临床记录的实时应用。 CDR独立存在主要用于实现： 1、与复杂的业务处理流程分割 病人的临床信息来自医院现已存在的多种多样的应用系统。一般说来，它们 是面向应用过程设计的， 是由不同供应商提供的， 具有不同的信息模型和软硬件 平台，其功能必须满足管理

39、与临床应用不同的过程要求，例如一个实验室系统。 从医生开出医嘱，到条码打印和取得样本，样本传送与接受，上化验设备，化验 过程的双向控制， 化验结果的自动获取， 报告的产出与确认， 报告的发出与接受 确实是十分复杂的。 应用系统的数据结构设计必须满足这些要求，数据库内的化 验结果表达必然是复杂多变的。 而电子病历仅仅关心化验报告的最终结果。因此， 如果CDR仅仅保存从检验系统传递来的化验结果，那么电子病历系统就可以和 复 杂的业务处理流程相分割。 如果电子病历系统中的化验结果要从检验系统中直接 获取，就不得不关注上述的所有细节。 2、透明、一致化的数据模型 CDR的独立存在使得一个统一的、 透明

40、的、一致化的电子病历信息模型的设 计与实现成为可能。这样一个模型的存在对所有应用系统的开发商、对系统集成、 . 对医生护士对病人信息的进一步应用都十分重要。 3、应用系统升级容易 由于CDR和复杂的业务处理流程相分割，使得以后各应用系统 （POS）的升 级 换代变得简单易行。 而这种变化随着业务流程的变化和信息化水平的提高，是经 常发生的，也是医院信息化发展进程中最让人头痛的问题。 4、对医生 /护士更友善，效率更高 医生/护士使用物理上保存的以病人为中心的电子病历记录比起使用分散在 不同应用系统中的病人记录来更得心应手、更符合他们的思维习惯， 应答速度会 更快。特别是简单、 统一、透明的信息

41、模型的存在使得他们有可能根据自己临床 工作的需要从 CDR中剪裁出自己的病人临床记录子集。 5、有利于电子病历深层次应用的开发推广 电子病历的存在不仅仅是要满足临床信息查询的需要，更重要的是要满足临 床决策、教学、科研的深层次的要求，例如警告与提示系统、临床路径控制、循 证医学支持等等。 这些应用的开发， 当面对一个数据相对稳定、 信息模型简单清 晰、与操作过程无关的存储库时， 要简单得多。特别的，当服务点应用系统 (Point of Service ，PoS)发生变化时，也不会影响这些深层次的应用。 . 4.3.6 临床数据中心构建方法 广义的电子病历覆盖了患者过去、现在、未来所有的医疗健康

42、相关的数据， 这些数据的生成和利用涉及到了整个医疗过程的各个环节。即使在一个医疗机构 内部，电子病历也是往往建立在各类临床信息系统充分发展的基础之上，临床信 . 息系统构成了电子病历的信息源。显然，一个共享的电子病历逻辑信息模型对于 构建临床数据中心以及最终实现共享的电子病历来说都具有十分重大的意义。 目前，我国大多数医疗机构都已经在不同程度上实现了信息化，建成了各种不同 规模的临床信息系统。在这种情况下，不改变各个已有系统的底层信息模型， 采用仅在逻辑上集中的方案构建临床数据中心比较具有现实意义。按照这种方 案，各种类型的电子病历数据仍由相应的临床信息系统负责管理和维护，保持原 有的物理分布

43、特性； 在此之上，采用一定的技术手段将这些分散存储的数据在逻 辑上集中起来， 为上层的各种电子病历应用提供统一的数据访问接口，使得在这 些上层系统看来， 它们所面对的就是一个集中式的临床数据中心。为了实现对这 些多模态电子病历数据的逻辑上的集中，通常有两种技术方案： 基于面向服务架 构（SOA）和基于集中索引。 SOA 是一种将应用程序的不同功能单元（称为服 务）通过定义一些接口和契约联系起来的软件系统架构，数据访问服务是SOA 架构中最常见、使用最广泛的服务。基于SOA构建逻辑集中的临床数据中心就 是指面向各个异构临的床信息系统开发一系列的数据访问服务，上层应用通过这 些服务访问电子病历数据

44、。 在这种技术方案中， 所有对于服务接口的调用都会涉 及到访问一个或多个临床信息系统数据库，整体效率比较低。 集中索引是指在各 个临床信息系统之上， 根据上层应用的需求， 为那些经常被访问到的电子病历数 据建立一个集中的索引， 基于索引实现对电子病历数据的访问。在这种技术方案 中，由于大部分的数据访问操作不需要直接连接具体的临床信息系统数据库，提 高了 数据访问效率。 但是，为了确保医护人员能够随时获取到患者最新的电子病历数 据，索引必需与原始数据保持同步更新。采用这种逻辑集中的方案时， 由于原始 . 数据仍存在于各自临床信息系统的服务器中，同样的数据可能同时在不同系统中 存在多个备份， 因此

45、，如何确保数据的一致性、 以及在出现数据不一致时系统的 容错能力是在开发服务和建立索引过程中需要关注的问题。相对于基于共享信息 模型的技术方案而言， 逻辑集中的方式可以保持已经建立的各个临床信息系统不 变，或仅需要为了支持数据交换开发少量的基于标准的消息通讯接口，是一个比 较适合我国当前阶段医院信息化需求的构建临床数据中心的方法。 ODS （操作数据存储） CDR存储库的组织形式以患者电子病历为核心展开，其存储结构方式更多的 以个人基本索引模式组织展开， 以结果数据为主体， 这样的组织形式在以个人视 角所见的电子病历中能够完整迅速的定位，但对纵向条线业务的支持却明显缺乏 有力的索引组织，不能完

46、全满足业务的需求。所以很多业务数据并不都在CDR 存 储库中存储， 为了完成某些特定业务上的流程要求，可能产生很多中间数据， 而 这些中间数据都有赖 ODS数据库实现其存储方式。 ODS数据库主要涵盖临床和管理数据，对数据即席查询、数据仓库、面向患 者的公众信息服务以及区域卫生提供数据层支持。同时，ODS数据库支持整个 医 院范围内各业务系统的协同，可以与CDR结合作为院内临床及其他业务驱动的 数 据，为医院内平台级别的应用（非POS应用），如统一调阅等提供信息支撑。 ODS数据库主要是作为 CDR存储库外的业务需求的补充。除了电子病历外， . 医 院信息平台还需要支持一些其他业务，比如说妇幼

47、保健等具体医疗业务。这些业 务所需的一些信息可以从电子病历中抽取，但是同时另一部分信息可能和健康信 息毫无关系只是为业务统计分析时使用，他们也有一定的业务流程，ODS就成 为 此类数据的存放场所。 ODS数据库还包含对这些业务数据的汇总、展现、统计查询等功能的支持， 他不仅仅是一个单纯的存储服务，他可以依赖LRS实现共享和使用 CDR存储库 中已 经存储信息的展示。 ODS、数据仓库和业务信息库的区别在于：业务信息库一般针对实时性非常 强的事务性操作和这些操作所对应的业务数据。其特点是数据实时性很强， 但数 据规模不大。 数据仓库一般针对很大规模的数据量。但是其数据为历史数据， 时 效性不强。

48、 ODS 则介于二者之间。 ODS数据来源于在线业务系统的实时映像。映像数据保存周期为数据集市或 数据仓库的装载周期。利用ODS系统，我们即可以允许历史数据在保存周期中 进行更新， 又可以随时对现有监测数据进行分析，满足应急性分析需求。 数据从 业务库抽取出来装载到 ODS后，从 ODS系统中进行数据清洗和转换从而完成在 建立数据仓库 /数据集市之前的数据准备工作。为了不影响业务数据库的性能， 一般ODS的数据库结构和业务数据库是完全一致的，这样数据可以高效的从业 务数据库中抽取出来。 ODS和数据仓库的数据库结构则往往区别较大。ODS的 数据需要进行数据转换方可进入数据仓库。 . 数据仓库

49、数据仓库是在临床数据、 医院管理类数据以及财务类数据采集的基础上对各 类数据进行归类整合并加以利用。按其数据的性质大致可分为三类：卫生资源信 息、临床诊疗信息、 卫生业务信息。 其中卫生资源信息可作为卫生资源分布的基 础数据；临床诊疗中与费用相关的信息可作为卫生资源消耗的基础数据；临床诊 疗中的疾病数据和卫生业务信息可作为卫生资源需求的基础数据，医院的管理与 决策可利用这些数据所产生的信息为相关的卫生决策进行支撑。 为快速的展示各种业务统计分析的报表及结果，必须首先对不同来源的数据 按照主题的方式来进行组织和处理，按照业务统计分析的需求搭建数据仓库，实 现对数据的多维管理。 数据仓库包括相应的事实表和维度表，基于上述业务统计 分析的要求，可采用多个面向不同主题的事实表共享维度表的“星型”数据仓库 模型。数据仓库的建立，有利于后期对数据的高效应用。 ODS库是医院医疗信息原始业务数据库的镜像库，定时与医疗信息业务数据 库进行同步， 为后面的数据转换、 数据仓库建立提供稳定、 可靠的数据源。 ODS 库的设置，缓解了ETL 过程中频繁访问生产数据服务器产生的大批量数据交换对 医院信息平台及网络造成的压力， 并最大限度降低数据数据仓库对原有业务系统 的影响。 数据仓库是数据整合汇总中心， 以业务需求为基础创建ODS库数据的抽取整 理规范及流程，抽象出满足业务