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

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

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

2、. 14 4.3.1 建立数据中心的意义 15 4.3.2 基础信息库 16 4.3.3 业务信息库 17 4.4.4 交换信息库 18 4.3.5 临床文档库 (CDR) 18 4.3.6 临床数据中心构建方法 21 操作数据存储 ODS . 22 数据仓库 . 23 医学知识库 . 24 4.4 数据交换总线平台 . 27 4.1.1. 数据交换总线技术特点 . 29 4.1.2. 数据交换总线功能特点 . 30 4.1.3. 基于数据交换服务总线的业务数据交互 . 32 4.1.4. 业务规则引擎 错误 !未定义书签。 4.1.5. 事件驱动引擎 错误 !未定义书签。 4.1.6. 集团

3、化医院信息交换平台 . 33 4.5 公共消息服务平台 . 34 4.1.7. 支持 HL7 引擎服务部件 . 35 4.1.8. 适配器服务部件 . 38 4.2. Ensemble 集成平台中间件 40 4.2.1. Ensemble HIE 构成组件 . 40 3 / 91 4.2.2. Ensemble HIE 设计原则 . 43 4.2.3. Ensemble HIE 技术 特点 . 44 4.2.4. Ensemble HIE 功能介绍 . 49 病人主索引（ MPI） 52 4.2.5. 病人主索引功能 . 53 4.3. 统一身份认证 授权平台 . 57 4.3.1. 统一身份

4、认证授权平台主要功能 . 58 4.3.1.1. 单点登录 . 58 4.3.1.2. 身份管理 . 59 4.3.1.3. 授权管理 . 59 4.3.1.4. 安全审计 . 59 4.3.2. 统一身份认证授权实现方法 . 60 医院决策分析平台 . 61 4.3.3. 决策支撑平台技术架构 . 63 4.3.4. 决策支撑平台数据架构 . 64 4.3.5. 指标加工逻辑架构 . 65 4.3.6. 系统工作内容及技术路线 . 67 4.3.6.1. 指标库构建与管理的工作内容要求 . 67 4.3.6.2. 指标库构建与管理的设计原则 . 71 4.3.6.3. 指标库构建与管理的技术

5、路线 . 72 短信服务平台 . 72 4.3.7. 短信平台架构 . 73 4.3.8. 短信平台功能模块 . 73 4.3.8.1. 通知功能 . 73 4.3.8.2. 查询功能 . 74 4.3.8.3. 信息管理 . 74 4.3.8.4. 语音信箱咨询功能 . 74 4.3.8.5. 医院信息查询功能 . 74 4.3.8.6. 投诉 /举报 /建议受理功能 . 74 4.3.8.7. 自动服务功能 . 75 4.3.8.8. 导医功能 . 75 后台运维管理系统 . 75 4.3.9. 信息资源统一监控系统设计原则 . 78 4.3.10. 信息资源统一监控系统架构及技术实现 .

6、 79 4.3.11. 信息资源统一监控系统管理模型 . 80 安全保障体系 . 81 4.3.12. 隐私保护措施 . 81 4.3.13. 网络安全保障 . 84 4.3.14. 数据保密性 . 85 4.3.15. 数据完整性 . 86 4.3.16. 恶意代码防范 . 87 4.3.17. 性能保障措施 . 88 4.3.18. 运行环境保障措施 . 89 4.3.19. 信息安全与审计保障措施 . 90 4 / 91 5. 平台扩展 错误 !未定义书签。 5 / 91 1. 建设 背景 我国医院信息系统建设已经有三十年的发展历史，早期有所 谓的 All in One的系统，所有的应用

7、都由一个供应商提供，服务于不同目的的应用模块，包装在一个软件包中，所有的数据库都是开放给所有的应用的，不需要接口引擎的设计。然而，医疗卫生信息的复杂性决定了医院信息系统的应用越来越复杂，医院对信息的需求也不断扩展，任何一个 HIT 厂商不可能提供医院所需要的全线产品（也包括国外的 HIS 厂商），要实现真正一体化的医院信息系统，必须引进不同厂商的信息系统产品。 因此在同一医院环境下，集成不同厂商的产品就成为医院信息化建设过程中必然遇到的问题。一开始几个厂商的产品要达到互连互 通，往往是采用点对点的接口方式，因为这种方式简单、易行且成本低，例如，将一个医疗保险的结算系统与医院的住院及门诊病人的费

8、用管理系统集成。然而，当医院的应用扩展到十几个乃至几十个应用系统时，问题就变得困难起来。 医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经逐渐成为制约医院数字化发展的主要障碍。而如何把这些系统连接实现各部门各专业信息共享就成了医院信息化建设中 面临的一大难题。如果以传统的方式在各系统之间做接口的话就将出现众多的接口，这将给医院信息系统的稳定性、安全性、可靠性、效率等带来巨大的隐患，同时以让医院的运行维护成本成倍增长，如果医院要对其中一个应用系统进

9、行升级或更换就必须再做众多数据接口。 随着国家 新 医改政策的实施 落实 ，以医院为单位的管理模式已不能满足广大人民群众日益增长的医疗卫生需求 ， 信息共享是实现信息价值最大化的重要途径之一，区域医疗信息共享是信息化发展的必然趋势 ， 为了实现医疗信息的区域化共享， 同样需 要在医院内部把不同数据资源进行集成整合。 在此背景 下 通过 医院信息 集成 平台来代替原来数量众多的点到点数据接口，为医院信息化建设提供标准和规范，只要各应用系统都支持这些标准和规范，原6 / 91 则上就能与应用信息平台进行数据交换，并能同与平台相连的应用系统进行数据交换。 2. 建设目标 2.1 实现 医疗 信息资源

10、整合与利用 为实现各业务系统信息互联互通，如果采用推倒重建的方法，就有可能将浪费大量的资金，并引起业务震荡。 通过医院信息平台的建设尽量减少不必要的重复建设。医院原有的各业务系统和信息系统通过医院信息平台提供的接口实现整合，继承已有的数据资源和服务。 通过建设医院信息平台， 将原先分布在各业务系统中的信息交换整合到医院信息平台，实现医院各个科室之间、医院之间信息的互联互通，最大限度地方便病人就医、方便医院一线医护人员工作、方便各类管理人员分析决策。 2.2 实现医院数据中心建设 为了使医疗活动可以准确、快速地进行，医疗服务者不但要接收到清晰的医疗指令信息，还需要掌握服务对象相关各方面信息、记录

11、服务对象在医疗活动中的情况及结果；因此要保证数据信息的高效利用，达到一处采集多处利用；以病人为主线，将病人在医疗机构中的历次就诊时间、就诊原因、针对性的医疗服务活动以及所记录的相关信息有机地 关联起来，并对所记录的海量信息进行科学分类和抽象描述，使之系统化、条理化和结构化。 建设 医院数据中心，通过数据中心实现不同信息系统、组织机构间信息资源整合，实现业务数据实时更新，确保信息同步；满足管理决策、临床决策、科学研究、对外信息共享；实现统一的数据仓库的设计及技术文档、元数据管理等功能。建设医院信息 集成 平台需制定 统一的 信息交换标准，统一卫生信息标准与数据字典。 7 / 91 2.3 提供

12、管理决策 及 临床决策 支持 凭借数字化医疗信息服务的先进技术作为强有力的支撑，利用更为先进的信息化手段，掌握工作的主动权，把传统事后处理 转为实时监控。 建设医院信息平台，规划医疗资源，实现诊疗流程再造，提高医院运作效率，提升医院的整体服务能力，有效解决就诊 “ 三长一短 ” 现象；建立统一的门户信息，为病人的全面医疗健康信息的保存、传递、查询提供有效的数据 ， 对数据的快速实时查询。通过对数据进行分析和处理，对信息进行有效利用，帮助管理者进行科学管理决策，帮助医生进行基于循证的医疗决策和医疗计划的制定，支持临床应用科研的开展。 3. 设计 原则 目前，大部分医院的医疗信息系统实现数据共享是

13、采用了传统点对点通信模式的方法，这样的方式需要每两个系统之间都有专用的接 口，且当有新系统添加进来的时候，也必须要单独为每个子系统开发与新系统相应的接口，工作量极大。这样的专用接口也存在很大风险，容易导致系统崩溃，中断医院正常的医疗业务流程。因此，需要建设一个能与全院所有医疗信息系统直接沟通的数据集成平台，以此为中介，实现各系统间的数据共享和交互。建立一个以现有信息系统和数据资源为基础，符合标准的、高可靠的、开放式医疗卫生信息共享平台，实现区域卫生协同和诊疗信息共享；在平台上提供区域级的标准组件服务、诊疗知识服务，以及协同医疗、卫生监管和健康管理等应用服务，有效提升医疗卫生服务水 平和服务能力

14、，支持创新具有区域特色的开放、实用、共享、持续的医疗卫生服务模式。 目前通常采用基于 中间件模型和数据仓库 等方法来构造集成的系统，这些技术在不同的着重点和应用上解决数据共享和为企业提供决策支持。 在 方案设计 时遵循 了 以下原则： 8 / 91 统一 性 统一设计原则统筹规划和统一设计系统结构。应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。 实用性和先进性 当今的计算机技术日新月异，因此要求选择的 方法、技术、工具、设备 不仅要保证具有先进性，而且要保证技术方向的正确性 。 设计 的方案 要 结合考虑实用和兼顾今后发展的目的，不 论

15、在服务器 、软件及中间件 等 软 硬件 产品 方面，还是在 方法论、工具 方面，都 应 选择当今国际上成熟 的 、主流 的 并领先的产品和技术来适应更高的数据处理要求， 以满足 医疗管理 信息系统未来 5-10 年的需求发展，并 应 具有良好的扩展潜力，以适应未来业务的发展和技术升级的需要。 安全性和可靠性 设计 的整体方案 要 通过多种安全技术和防护手段，保证系统自身的安全性，保证服务不会中断。在 本 项目方案中，最重要的设计出发点就是系统的 安全 ，关键设备或设备核心部件 应当采取 冗余设计，能够避免单点故障导 致系统整体或重要功能的丧失，保证系统平稳运行，最大限度减少停机时间而且 包括

16、便于故障排查、恢复和日常的运行维护 的机制 。在采用硬件备份、冗余、负载均衡等可靠性技术的基础上，采用相关的软件技术提供较强的管理机制和控制手段，以提高整个系统和数据的安全可靠性。 开放性、互连性和标准化 系统必须采 用国际、国家标准、协议和接口，能与现有的和未来的系统互连与集成，支持 HL7、 IHE、 DICOM、 ICD10 等标准。 灵活性与可扩展性 设计的 方案 应当 考虑系统的灵活性和可扩展性。系统建成后 要 能够满足业务9 / 91 近期、中期甚至长期时间范围 数据 和业务 快速增长的需要。适应目前需求的基础上，能够 满足医院以及相关医疗机构 不断发展的信息化需要，充分地为将来可

17、预见和不可预见的性能扩充留有余地， 并 具备方便地扩展系统容量和处理能力 和 支持多种应用的能力 ， 可以根据业务发展的需要进行灵活、快速的调整，实现信息应用的快速部署，而且新功能、新业务的增加能够在不影响系统运行的情况下实现。 系统要充分考虑到扩容和升级的需要，能灵活方便地适应未来系统可能的变化。选择应用开放性标准的产品，确保设备的兼容性；通过系统结构的合理设计和适度资源冗余，为未来的系统扩充打下基础，保证需 求增加时系统的平滑扩充，保证前期的投资。 经济性与投资保护 方案所选用的技术和产品 应当 全部遵循通用的国际或行业标准，各系统模块之间有良好的兼容性和较高的性能价格比。从长远来看，也便

18、于系统的升级和移植或运行其他应用软件， 实现整体效益， 而且能以较低的成本、较少的人员投入来维护系统运转，提供高效能与高效益 的医疗信息服务 。 易管理和易操作性 设计方案支持 全面、完善、便捷、统一的系统管理 和 应急处理预案， 保证 一旦发生问题 能 在最短的时间内处理解决。而且，系统 应 具有良好的用户操作界面、完备的帮助信息。集成完备的运行监视系 统、良好的管理界面工具或远程控制台，易于管理人员对其进行管理和维护，系统参数的维护与管理通过操作界面实现。 整体设计和多种应用相匹配 集成平台需要 进行统一设计，但是考虑到应用的多样性以及业务、部门等的差异，整体设计又不要过于制约具体的应用开

19、发，要为各种应用开发提供灵活的手段。 10 / 91 可维护、可管理性 通过统一网管，对信息系统平台进行统一管理，提供可视化的网络拓扑、网络状态监控、故障事件实时预警和告警、 异常 网络流量统计等。 4. 建设方案 4.1 医院信息化建设面临的问题 和难题 难题 1:系统集成度较低 医院信息工作以采集 到的数据范围与数量为主要工作目标，而这些数据采集后的共享与深度利用往往被忽略。 目前，很多的医院都建设有独立的PACS、 LIS、手术麻醉等系，这些系统很多是科室根据自身业务需要，由科室主导建立起来的。这些系统在建立时并未考虑与医院信息系统的集成，或者当时医院信息系统并不具备集成应用的条件，所以

20、就成为孤立的系统。 由于 信息没有利用好，往往使医院无法看到信息化工作的真正回报，医院信息化工作就无没得到医院领导者们足够的重视。 对于信息化工作来说，信息的采集基本上是投入性的工作，而信息的有效、及时利用才是信息化工作的收益 。 难题 2： 规范化、标准化程度低 我国医院信息化建设的过程中，采用的标准、规范很少，信息的共享与交换主要以 “ 点对点 ” 的方式进行，这种方式个性化极强，往往会因为系统升级、更换厂商而带来严重后果。 11 / 91 传统点对点模式 基于传统“点对点”直连数据接口方式来集成系统，如果另一个应用程序系统 A（第 n+1 个）必须集成进来，将需要产生、文档化、测试和维护

21、 2n 个新的接口。而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将增加大量的成本和复杂度。 : 点对点集成方式存在以下问题： 接口不规范 接 口间的调用方式各不相同，如有存储过程、视图、中间表、应用程序、动态库等等 ,无法形成统一的接口规范。 数据不共享 虽然现在 大多数 系统 间均有做接口进行数据交互，但往往只做到最基础的数据采集上， 信息 间的共享并不充分，如 急诊、危重 病人的报告、异常的报告无法做到第一时间 提醒医生。 医生也无法主动查询病人的 报告 进行到哪一步 。 数据 不一致 由于数据共享不充分，导致多数接口在重复做，往往会出现数据在不同系统间不一致的情况

22、，如同样的检验报告，在 LIS系统下 看到的格式 有可能与 HIS看到的不一样 ， 甚至连数据都有可能不同，这就给12 / 91 医 生带来不小的困扰。 数据入口多 由于点对点的接口方式，数据重复存在于各个系统中，无法形成统一的数据中心模式，造成同一数据多个采集入口。 接口安全性差 很显然在不同供应商之间开放数据库用户进行连接视图或读写中间表，这种接口方式的安全性较低，一旦出现数据异常责任往往无法追踪。 接口耦合度高 点对点集成方式导致接口耦合度高， 不利于后期的扩展及维护。 各系统界面 、用户分散，无统一管理机制 用户 必须 来回切换登录不同系统 用户 必须记住不同系统的不同用户及密码 系统

23、维护成本高 4.2 医院集成平台 总体框架 13 / 91 医院集成平台总体架构 图 如上图所示， 本平台中 医院信息平台信息交换层 ，主要用于实现全院级应用系统互联互通的需求，主要任务以满足临床信息、医疗服务信息和医院管理信息的共享和协同应用为目，标采集相关业务数据，并对外部系统提供数据交换服务；提供支持 HL7标准的消息传输机制，建立服务之间的通信、连接、组合和集成的服务动态松耦合机制，为集成遗留系统和新建基于 SOA 的应用系统的服务集成提供了支撑。并在此基础上，开发面向应用的业务适配器组件，实现各集成应用之间可管理的接口透明，为医疗应用 提供了便捷、一致、安全并符合标准的丰富接口，保证

24、服务之间信息的可靠传送，实现不同操作系统，不同数据库、中间件运行平台及其基于这些平台之上开发的应用软件的服务集成。 信息资源层 是对于各个业务系统产生的医疗业务信息、临床信息、医院管理信息，通过业务信息库进行整合， 主要服务于建立全院级的病人主索引的需求、建立全院级电子病历的需求，并为医院信息二次利用、为患者提供公众服务、与外部互联奠定数据基础； 支持结构化数据存储，以 XML格式提供结果数据，便于14 / 91 相关系统进行二次处理（如科研或质控） 。 4.3 标准化 数据中心 依据卫生 部 2011 年 8 月 2 日发布的城乡居民健康档案基本数据集，该标准于 2012 年 2 月 1 日

25、起正式实施。该标准规定了城乡居民健康档案基本数据集的数据集元数据属性和数据元目录。数据元目录包括城乡居民健康档案个人基本信息、健康体检信息、重点人群健康管理记录和其他医疗卫生服务记录的相关数据元。适用于城乡居民健康档案的信息收集、存储与共享 ,以及城乡居民健康档案管理信息系统建设。 标准中规定了卫生信息中标识类数据元的数据元标识符、数据元名称、定义、数据元值的数据类型、表示格式和数据元允许值内容。数据元目录包括标识信息相关数据 元。 按此标准建设的数据集内容涵盖了人员、医疗机构、医疗卫生术语、电子健康档案的数据集、数据元和各种代码标准的注册管理，数据标准化则提供了在数据注册过程中基于标准化转换

26、服务，其囊括了区域卫生业务数据的所有数据标准规范，根据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准，并通过数据校验机制保障数据中心的数据进行标准化。 标准数据完全匹配国家对全程健康档案服务和注册服务的要求。数据注册涵盖了人员、医疗机构、医疗卫生术语、电子健康档案的数据集、数据元和各种代码标准的注册管理，数据标准化提供了在数据注册 过程中基于标准化转换服务，其囊括了区域卫生业务数据的所有数据标准规范，根据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准，并通过数据校验机制保障数据中心的数据进行标准化。 依据标准建设的中心数据库数据集内容包括： 1) 基本数据字典：科室字典

27、、员工字典、用户字典等； 2) 患者注册基本信息； 3) 门诊业务数据结果集：挂号记录、诊断记录、处方记录、结算记录等； 4) 住院业务数据结果集：住院记录、诊断记录、医嘱记录、结算记录等； 5) 健康体检数据结果集：体检登记记录、诊断记录、体格检查记录、评估15 / 91 报告、费用记录等； 6) 电子病历 结构化数据集； 7) 决策分析数据集； 8) 医院管理指标数据集； 上述部分结构主要是结果集的采集存储，为了满足不同平台之间或系统之间数据交互，涉及的业务相关数据集： 1) 住院患者信息相关表：如在院患者记录表、出入转记录表； 2) 临床路径相关表； 3) 单据记录及状态相关表：单据表、

28、单据状态事件表等； 4) 电子申请单记录表及医技预约反馈记录表； 5) 检验、检查报告记录表； 6) 系统间消息交互数据集； 4.3.1 建立数据中心的意义 数据中心是医院的业务系统与数据资源进行集中、集成、共享、分析的场地、工具、流程等的有机组合。它 将不同业务系统之间需要 共享的信息、综合业务系统与区域共享需要的业务数据，按行业标准转换明文方式长期存贮在一个数据仓库中。 当前医院各业务系统面临的最大问题： 系统业务无统一数据标准 数据标准是指卫生信息采集表的处理过程中涉及到的标准，主要是指数据采集里的标准，定义各类数据标志的含义，规范数据采集的数据集能在不同系统之间传递的电子报文或者是电子

29、文档。 由于医院各业务系统产生的数据需要长期保存，但建立在这些业务数据基础之上的各种字典，由于医改的需要在不断地变化，系统中各类字典也不断膨胀，为减少业务数据错误与系统维护工作，很多系统设计 者只能将明文保存的基础业务数据表，造成业务系统运行效率低下，维护困难。 数据中心的建立，就是要将原各系统不能共享的孤岛信息，转换成符合国家或卫生部相关标准的数据集。为全院系统打造一个共享平台，统一字典维护，降16 / 91 低业务系统标准字典维护量，为区域共享提供可进行信息统计与挖掘的标准数据集。 涉及到医院系统的主要标准有：疾病代码、科室分类、药典、非药品记费项目。 业务系统数据接口 由于医院业务管理系

30、统，是一个长期运行，不断完善的情况下壮大成长起来的，医疗信息技术标准没有惯彻到整个业务中。由此造成上线系统越来越多，各系 统之间数据的调用频繁，数据接口也就越来越多，越来越复杂。经常出现某个业务系统升级无法到相关信息，或因某业务系统升级造成其它业务系统数据混乱的现象。 医院业务需求扩张 各业务系统随着用户应用不断深入产生新的业务需求：如质控、 CA 认证、闭环医嘱等。这些应用必须建立在多个系统之上，若将这些应用需求不断加入到基础业务系统中，势必造成基础业务系统数据量不断膨胀，造成基础业务系统的可维护性与运行效率越来越差。 病人信息综合处理 目前医院的系统是按功能进行划分的，如： HIS 系统保

31、存病人费用与医嘱内容、 LIS 保存病人检验数 据、 PACS 保存病人影像信息等。医生对病人的诊断往往来源于医院各业务系统，对其数据进行综合的结果。将这些来源不同系统并标准不统一信息，整合在一个界面中进行综合处理，存在巨大的障碍与分析效率低下的问题。 将基本业务产生的数据，对其进行质量控制、清洗、转换保存到综合医疗业务数据仓库，长期海量保存。使基本业务与综合医疗业务的运行建立不同数据仓库中，实现分布式并行运行，有效地解决了高效、稳定的前台业务与多变的综合展示业务之间运行效率的矛盾，极大地提高了基础业务系统的维护性与稳定性。 4.3.2 共享 基础信息 库 基础 信息库集中了整个医院信息平台的

32、基础信息和共享数据，是为各个子系 17 / 91 统提供基础信息服务的。基础信息库包括了患者的人口学信息、医疗卫生人员的 注册信息、以及各种医疗卫生、公共卫生术语字典数据及流程模板数据等。 病人基本信息是基础信息数据库中的核心内容之一。无论是电子病历、医疗 业务、临床信息，还是疾病分析信息和公共卫生条线数据都是以病人基本信息为 基础的。在此基础上，实现电子病历、医疗业务（含临床数据）的关联。 医护人员库是基础信息数据库中的另一个核心内容，以医护人员信息为基 础。可以建立医院诊疗资源注册库，可以 作为医院管理以及绩效考核的基础。 数据元字典是辅助各类医院业务、临床业务的基本数据元、代码集以及数据

33、 字典；以及包含了医院各种业务、流程说明模版的操作模型。流程模版库是包含了医疗机构医疗业务、临床路径、管理流程、财务结算等所有信息系统正常运转、分布协同的规则库。通过流程模版库的流程引擎指导，能够明确患者在医疗机构内如何进行就医，临床医生如何对患者进行准确诊断，防保医生如何对疾病进行控制和分析，管理及后勤人员如何对医疗资源进行合理分配或者补充采购、财务结算人员如何统计和控制医院的收入和开支。流程模版库是医疗机 构保证正常运转的核心，对各级医疗卫生人员和患者的医疗行为起着规范和指导作用。 4.3.3 原始 业务信息库 业务信息库是整个医院信息平台的数据基础，主要存储原始业务产生的数 据，以未经过

34、进一步加工的数据为主。包括诊疗业务流程产生的结果数据、医疗 服务管理数据以及医院运营管理流程产生的结果数据。这些未经修改的数据，作 为电子病历的备份存储，在以后发生任何疑问时，可调阅业务信息库中的数据进 行核实。业务信息库中的数据要求在存储后不能被修改和删除，将作为系统的原 始凭证被永久保留。从时效性和实际业务需求出发，业务信息 库至少也要保存 50 年之内在线业务操作及结果数据。 医疗机构内部的业务数据分布于不同的信息系统自身的数据库之中，因此需 要接入到覆盖整个医疗机构的信息平台上，以提供对原有业务数据的整合、利用 服务，并为机构之间以及业务系统之间的联动提供支持。 业务系统通过设置交换信

35、息库作为与信息平台的接入端代理，来实现业务系 统与信息平台的互联互通性。体现在数据结构层面，就是业务信息库通过交换信 18 / 91 息库实现数据的接入。除了在信息平台上保存即时产生的，符合临床诊疗要求的各种业务原始数据以外，还需要以患者的基本信息为基础，整合患 者历次就诊的就诊履历，完善患者的医院电子病历。患者的基本信息保存在基础信息库中，电子病历保存在临床文档信息库中，也就是说，业务信息库根据基础信息库中的患者信息进行整合，并最终形成存储在临床文档信息库中的电子病历。 4.4.4 交换信息库 交换信息库是信息平台的数据转换枢纽，包括中心交换库和对外交换库。中 心交换库的作用主要是对医疗机构

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

37、与区域卫生信息平台进行数据交换的信息 存储区域。为保证系统的相对独立，我们设立对外信息交换 数据库。对外交换库 存储要推送到区域卫生信息平台的电子病历，同时也存储着从区域平台推送来的 健康档案。在对外交换库中完成电子病历与健康档案的相互转换。 4.3.5 临床文档库 (CDR) 电子病历存储服务具体由临床数据存储库 CDR(Clinical Data Repository)来实现。 电子病历主要由临床文档组成，临床文档是电子病历中各类业务活动记录的基本形式。临床文档中的数据存在着一定的层级结构关系，其中有包含与被包含的关系，也有按同类属性相互嵌套的关系。临床文档的结构化和标准化，是19 / 9

38、1 电子病历实现语义层数据 交换与共享的基本要求。 CDR是医院为支持临床诊疗和全部医、教、研活动而以病人为中心重新构建 的新的一层数据存储结构。它应该是物理存在的，而不仅仅是概念存在或者是逻 辑存在。它是医院基于电子病历的信息平台的核心构件。它是否存在可以作为医 院是否拥有真正电子病历系统的标志。它与直接支持医疗操作的前台业务信息库 不同，其数据来自这些业务系统，但与前台业务流程无关。它也不是通常意义上 的数据仓库，因为它的内容是随着医院业务活动动态变化的，并且直接支持医生 /护士对病人临床记录的实时应用。 CDR独立存在主要用于实 现： 1、与复杂的业务处理流程分割 病人的临床信息来自医院

39、现已存在的多种多样的应用系统。一般说来，它们是面向应用过程设计的，是由不同供应商提供的，具有不同的信息模型和软硬件平台，其功能必须满足管理与临床应用不同的过程要求，例如一个实验室系统。 从医生开出医嘱，到条码打印和取得样本，样本传送与接受，上化验设备，化验 过程的双向控制，化验结果的自动获取，报告的产出与确认，报告的发出与接受 确实是十分复杂的。应用系统的数据结构设计必须满足这些要求，数据库内的化 验结果表达必然是复杂多变的。而电子病历仅仅关心化验报 告的最终结果。因此， 如果 CDR仅仅保存从检验系统传递来的化验结果，那么电子病历系统就可以和复 杂的业务处理流程相分割。如果电子病历系统中的化

40、验结果要从检验系统中直接 获取，就不得不关注上述的所有细节。 2、透明、一致化的数据模型 CDR的独立存在使得一个统一的、透明的、一致化的电子病历信息模型的设 计与实现成为可能。这样一个模型的存在对所有应用系统的开发商、对系统集成、 对医生护士对病人信息的进一步应用都十分重要。 3、应用系统升级容易 由于 CDR和复杂的业务处理流程相分割，使得以后各应用系统（ POS）的 升级 换代变得简单易行。而这种变化随着业务流程的变化和信息化水平的提高，是经 常发生的，也是医院信息化发展进程中最让人头痛的问题。 4、对医生 /护士更友善，效率更高 20 / 91 医生 /护士使用物理上保存的以病人为中心

41、的电子病历记录比起使用分散在 不同应用系统中的病人记录来更得心应手、更符合他们的思维习惯，应答速度会 更快。特别是简单、统一、透明的信息模型的存在使得他们有可能根据自己临床 工作的需要从 CDR中剪裁出自己的病人临床记录子集。 5、有利于电子病历深层次应用的开发推广 电子病历的存在不仅仅是要满足临床信息查询的 需要，更重要的是要满足临 床决策、教学、科研的深层次的要求，例如警告与提示系统、临床路径控制、循 证医学支持等等。这些应用的开发，当面对一个数据相对稳定、信息模型简单清 晰、与操作过程无关的存储库时，要简单得多。特别的，当服务点应用系统 (Point of Service， PoS)发生

42、变化时，也不会影响这些深层次的应用。 21 / 91 4.3.6 临床数据中心构建方法 广义的电子病历覆盖了患者过去、现在、未来所有的医疗健康相关的数据，这些数据的生成和利用涉及到了整个医疗过程的各个环节。即使在一个医疗机构内部，电子 病历也是往往建立在各类临床信息系统充分发展的基础之上，临床信息系统构成了电子病历的信息源。显然，一个共享的电子病历逻辑信息模型对于构建临床数据中心以及最终实现共享的电子病历来说都具有十分重大的意义。 目前，我国大多数医疗机构都已经在不同程度上实现了信息化，建成了各种不同规模的临床信息系统。在这种情况下，不改变各个已有系统的底层信息模型， 采用仅在逻辑上集中的方案

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

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

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

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

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

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

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