最新医院集成平台建设方案

医院信息系统集成平台建

设方案

目录

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标准化数据中心 (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. 集团化医院信息交换平台 (33)

4.5公共消息服务平台 (34)

4.1.7. 支持HL7引擎服务部件 (35)

4.1.8. 适配器服务部件 (38)

4.2. Ensemble集成平台中间件 (40)

4.2.1.Ensemble HIE 构成组件 (40)

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. 统一身份认证授权平台主要功能 (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. 指标库构建与管理的技术路线 (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. 信息资源统一监控系统架构及技术实现 (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)

5. 平台扩展....................................................................................................错误!未定义书签。

1.建设背景

我国医院信息系统建设已经有三十年的发展历史，早期有所谓的All in One 的系统，所有的应用都由一个供应商提供，服务于不同目的的应用模块，包装在一个软件包中，所有的数据库都是开放给所有的应用的，不需要接口引擎的设计。然而，医疗卫生信息的复杂性决定了医院信息系统的应用越来越复杂，医院对信息的需求也不断扩展，任何一个HIT厂商不可能提供医院所需要的全线产品（也包括国外的HIS厂商），要实现真正一体化的医院信息系统，必须引进不同厂商的信息系统产品。

因此在同一医院环境下，集成不同厂商的产品就成为医院信息化建设过程中必然遇到的问题。一开始几个厂商的产品要达到互连互通，往往是采用点对点的接口方式，因为这种方式简单、易行且成本低，例如，将一个医疗保险的结算系统与医院的住院及门诊病人的费用管理系统集成。然而，当医院的应用扩展到十几个乃至几十个应用系统时，问题就变得困难起来。

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

随着国家新医改政策的实施落实，以医院为单位的管理模式已不能满足广大人民群众日益增长的医疗卫生需求，信息共享是实现信息价值最大化的重要途径之一，区域医疗信息共享是信息化发展的必然趋势，为了实现医疗信息的区域化共享，同样需要在医院内部把不同数据资源进行集成整合。

在此背景下通过医院信息集成平台来代替原来数量众多的点到点数据接口，为医院信息化建设提供标准和规范，只要各应用系统都支持这些标准和规范，原

则上就能与应用信息平台进行数据交换，并能同与平台相连的应用系统进行数据交换。

2.建设目标

2.1实现医疗信息资源整合与利用

为实现各业务系统信息互联互通，如果采用推倒重建的方法，就有可能将浪费大量的资金，并引起业务震荡。通过医院信息平台的建设尽量减少不必要的重复建设。医院原有的各业务系统和信息系统通过医院信息平台提供的接口实现整合，继承已有的数据资源和服务。

通过建设医院信息平台，将原先分布在各业务系统中的信息交换整合到医院信息平台，实现医院各个科室之间、医院之间信息的互联互通，最大限度地方便病人就医、方便医院一线医护人员工作、方便各类管理人员分析决策。

2.2实现医院数据中心建设

为了使医疗活动可以准确、快速地进行，医疗服务者不但要接收到清晰的医疗指令信息，还需要掌握服务对象相关各方面信息、记录服务对象在医疗活动中的情况及结果；因此要保证数据信息的高效利用，达到一处采集多处利用；以病人为主线，将病人在医疗机构中的历次就诊时间、就诊原因、针对性的医疗服务活动以及所记录的相关信息有机地关联起来，并对所记录的海量信息进行科学分类和抽象描述，使之系统化、条理化和结构化。

建设医院数据中心，通过数据中心实现不同信息系统、组织机构间信息资源整合，实现业务数据实时更新，确保信息同步；满足管理决策、临床决策、科学研究、对外信息共享；实现统一的数据仓库的设计及技术文档、元数据管理等功能。建设医院信息集成平台需制定统一的信息交换标准，统一卫生信息标准与数据字典。

2.3提供管理决策及临床决策支持

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

3.设计原则

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

目前通常采用基于中间件模型和数据仓库等方法来构造集成的系统，这些技术在不同的着重点和应用上解决数据共享和为企业提供决策支持。在方案设计时遵循了以下原则：

统一性

统一设计原则统筹规划和统一设计系统结构。应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。

实用性和先进性

当今的计算机技术日新月异，因此要求选择的方法、技术、工具、设备不仅要保证具有先进性，而且要保证技术方向的正确性。设计的方案要结合考虑实用和兼顾今后发展的目的，不论在服务器、软件及中间件等软硬件产品方面，还是在方法论、工具方面，都应选择当今国际上成熟的、主流的并领先的产品和技术来适应更高的数据处理要求，以满足医疗管理信息系统未来5-10年的需求发展，并应具有良好的扩展潜力，以适应未来业务的发展和技术升级的需要。

安全性和可靠性

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

开放性、互连性和标准化

系统必须采用国际、国家标准、协议和接口，能与现有的和未来的系统互连与集成，支持HL7、IHE、DICOM、ICD10等标准。

灵活性与可扩展性

设计的方案应当考虑系统的灵活性和可扩展性。系统建成后要能够满足业务

近期、中期甚至长期时间范围数据和业务快速增长的需要。适应目前需求的基础上，能够满足医院以及相关医疗机构不断发展的信息化需要，充分地为将来可预见和不可预见的性能扩充留有余地，并具备方便地扩展系统容量和处理能力和支持多种应用的能力，可以根据业务发展的需要进行灵活、快速的调整，实现信息应用的快速部署，而且新功能、新业务的增加能够在不影响系统运行的情况下实现。系统要充分考虑到扩容和升级的需要，能灵活方便地适应未来系统可能的变化。选择应用开放性标准的产品，确保设备的兼容性；通过系统结构的合理设计和适度资源冗余，为未来的系统扩充打下基础，保证需求增加时系统的平滑扩充，保证前期的投资。

经济性与投资保护

方案所选用的技术和产品应当全部遵循通用的国际或行业标准，各系统模块之间有良好的兼容性和较高的性能价格比。从长远来看，也便于系统的升级和移植或运行其他应用软件，实现整体效益，而且能以较低的成本、较少的人员投入来维护系统运转，提供高效能与高效益的医疗信息服务。

易管理和易操作性

设计方案支持全面、完善、便捷、统一的系统管理和应急处理预案，保证一旦发生问题能在最短的时间内处理解决。而且，系统应具有良好的用户操作界面、完备的帮助信息。集成完备的运行监视系统、良好的管理界面工具或远程控制台，易于管理人员对其进行管理和维护，系统参数的维护与管理通过操作界面实现。

整体设计和多种应用相匹配

集成平台需要进行统一设计，但是考虑到应用的多样性以及业务、部门等的差异，整体设计又不要过于制约具体的应用开发，要为各种应用开发提供灵活的手段。

可维护、可管理性

通过统一网管，对信息系统平台进行统一管理，提供可视化的网络拓扑、网络状态监控、故障事件实时预警和告警、异常网络流量统计等。

4.建设方案

4.1医院信息化建设面临的问题和难题

?难题1:系统集成度较低

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

?难题2：规范化、标准化程度低

我国医院信息化建设的过程中，采用的标准、规范很少，信息的共享与交换主要以“点对点”的方式进行，这种方式个性化极强，往往会因为系统升级、更换厂商而带来严重后果。

传统点对点模式

基于传统“点对点”直连数据接口方式来集成系统，如果另一个应用程序系统 A（第 n+1 个）必须集成进来，将需要产生、文档化、测试和维护 2n 个新的接口。而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将增加大量的成本和复杂度。:

点对点集成方式存在以下问题：

?接口不规范

接口间的调用方式各不相同，如有存储过程、视图、中间表、应用程

序、动态库等等,无法形成统一的接口规范。

?数据不共享

虽然现在大多数系统间均有做接口进行数据交互，但往往只做到最

基础的数据采集上，信息间的共享并不充分，如急诊、危重病人的

报告、异常的报告无法做到第一时间提醒医生。医生也无法主动查

询病人的报告进行到哪一步。

?数据不一致

由于数据共享不充分，导致多数接口在重复做，往往会出现数据在

不同系统间不一致的情况，如同样的检验报告，在LIS系统下看到的

格式有可能与HIS看到的不一样，甚至连数据都有可能不同，这就给

医生带来不小的困扰。

?数据入口多

由于点对点的接口方式，数据重复存在于各个系统中，无法形成统

一的数据中心模式，造成同一数据多个采集入口。

?接口安全性差

很显然在不同供应商之间开放数据库用户进行连接视图或读写中间

表，这种接口方式的安全性较低，一旦出现数据异常责任往往无法

追踪。

?接口耦合度高

点对点集成方式导致接口耦合度高，不利于后期的扩展及维护。

?各系统界面、用户分散，无统一管理机制

?用户必须来回切换登录不同系统

?用户必须记住不同系统的不同用户及密码

?系统维护成本高

4.2医院集成平台总体框架

医院集成平台总体架构图

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

信息资源层是对于各个业务系统产生的医疗业务信息、临床信息、医院管理信息，通过业务信息库进行整合，主要服务于建立全院级的病人主索引的需求、建立全院级电子病历的需求，并为医院信息二次利用、为患者提供公众服务、与外部互联奠定数据基础；支持结构化数据存储，以XML格式提供结果数据，便于

相关系统进行二次处理（如科研或质控）。

4.3标准化数据中心

依据卫生部2011年8月2日发布的《城乡居民健康档案基本数据集》，该标准于2012年2月1日起正式实施。该标准规定了城乡居民健康档案基本数据集的数据集元数据属性和数据元目录。数据元目录包括城乡居民健康档案个人基本信息、健康体检信息、重点人群健康管理记录和其他医疗卫生服务记录的相关数据元。适用于城乡居民健康档案的信息收集、存储与共享,以及城乡居民健康档案管理信息系统建设。

标准中规定了卫生信息中标识类数据元的数据元标识符、数据元名称、定义、数据元值的数据类型、表示格式和数据元允许值内容。数据元目录包括标识信息相关数据元。

按此标准建设的数据集内容涵盖了人员、医疗机构、医疗卫生术语、电子健康档案的数据集、数据元和各种代码标准的注册管理，数据标准化则提供了在数据注册过程中基于标准化转换服务，其囊括了区域卫生业务数据的所有数据标准规范，根据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准，并通过数据校验机制保障数据中心的数据进行标准化。

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

依据标准建设的中心数据库数据集内容包括：

1)基本数据字典：科室字典、员工字典、用户字典等；

2)患者注册基本信息；

3)门诊业务数据结果集：挂号记录、诊断记录、处方记录、结算记录等；

4)住院业务数据结果集：住院记录、诊断记录、医嘱记录、结算记录等；

5)健康体检数据结果集：体检登记记录、诊断记录、体格检查记录、评估

报告、费用记录等；

6)电子病历结构化数据集；

7)决策分析数据集；

8)医院管理指标数据集；

上述部分结构主要是结果集的采集存储，为了满足不同平台之间或系统之间数据交互，涉及的业务相关数据集：

1)住院患者信息相关表：如在院患者记录表、出入转记录表；

2)临床路径相关表；

3)单据记录及状态相关表：单据表、单据状态事件表等；

4)电子申请单记录表及医技预约反馈记录表；

5)检验、检查报告记录表；

6)系统间消息交互数据集；

4.3.1建立数据中心的意义

数据中心是医院的业务系统与数据资源进行集中、集成、共享、分析的场地、工具、流程等的有机组合。它将不同业务系统之间需要共享的信息、综合业务系统与区域共享需要的业务数据，按行业标准转换明文方式长期存贮在一个数据仓库中。

当前医院各业务系统面临的最大问题：

?系统业务无统一数据标准

数据标准是指卫生信息采集表的处理过程中涉及到的标准，主要是指数据采集里的标准，定义各类数据标志的含义，规范数据采集的数据集能在不同系统之间传递的电子报文或者是电子文档。

由于医院各业务系统产生的数据需要长期保存，但建立在这些业务数据基础之上的各种字典，由于医改的需要在不断地变化，系统中各类字典也不断膨胀，为减少业务数据错误与系统维护工作，很多系统设计者只能将明文保存的基础业务数据表，造成业务系统运行效率低下，维护困难。

数据中心的建立，就是要将原各系统不能共享的孤岛信息，转换成符合国家或卫生部相关标准的数据集。为全院系统打造一个共享平台，统一字典维护，降

低业务系统标准字典维护量，为区域共享提供可进行信息统计与挖掘的标准数据集。

涉及到医院系统的主要标准有：疾病代码、科室分类、药典、非药品记费项目。

?业务系统数据接口

由于医院业务管理系统，是一个长期运行，不断完善的情况下壮大成长起来的，医疗信息技术标准没有惯彻到整个业务中。由此造成上线系统越来越多，各系统之间数据的调用频繁，数据接口也就越来越多，越来越复杂。经常出现某个业务系统升级无法到相关信息，或因某业务系统升级造成其它业务系统数据混乱的现象。

?医院业务需求扩张

各业务系统随着用户应用不断深入产生新的业务需求：如质控、CA认证、闭环医嘱等。这些应用必须建立在多个系统之上，若将这些应用需求不断加入到基础业务系统中，势必造成基础业务系统数据量不断膨胀，造成基础业务系统的可维护性与运行效率越来越差。

?病人信息综合处理

目前医院的系统是按功能进行划分的，如：HIS系统保存病人费用与医嘱内容、LIS保存病人检验数据、PACS保存病人影像信息等。医生对病人的诊断往往来源于医院各业务系统，对其数据进行综合的结果。将这些来源不同系统并标准不统一信息，整合在一个界面中进行综合处理，存在巨大的障碍与分析效率低下的问题。

将基本业务产生的数据，对其进行质量控制、清洗、转换保存到综合医疗业务数据仓库，长期海量保存。使基本业务与综合医疗业务的运行建立不同数据仓库中，实现分布式并行运行，有效地解决了高效、稳定的前台业务与多变的综合展示业务之间运行效率的矛盾，极大地提高了基础业务系统的维护性与稳定性。

4.3.2共享基础信息库

基础信息库集中了整个医院信息平台的基础信息和共享数据，是为各个子系

统提供基础信息服务的。基础信息库包括了患者的人口学信息、医疗卫生人员的注册信息、以及各种医疗卫生、公共卫生术语字典数据及流程模板数据等。

病人基本信息是基础信息数据库中的核心内容之一。无论是电子病历、医疗

业务、临床信息，还是疾病分析信息和公共卫生条线数据都是以病人基本信息为基础的。在此基础上，实现电子病历、医疗业务（含临床数据）的关联。

医护人员库是基础信息数据库中的另一个核心内容，以医护人员信息为基

础。可以建立医院诊疗资源注册库，可以作为医院管理以及绩效考核的基础。数据元字典是辅助各类医院业务、临床业务的基本数据元、代码集以及数据

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

4.3.3原始业务信息库

业务信息库是整个医院信息平台的数据基础，主要存储原始业务产生的数据，以未经过进一步加工的数据为主。包括诊疗业务流程产生的结果数据、医疗服务管理数据以及医院运营管理流程产生的结果数据。这些未经修改的数据，作为电子病历的备份存储，在以后发生任何疑问时，可调阅业务信息库中的数据进行核实。业务信息库中的数据要求在存储后不能被修改和删除，将作为系统的原始凭证被永久保留。从时效性和实际业务需求出发，业务信息库至少也要保存50 年之内在线业务操作及结果数据。

医疗机构内部的业务数据分布于不同的信息系统自身的数据库之中，因此需要接入到覆盖整个医疗机构的信息平台上，以提供对原有业务数据的整合、利用服务，并为机构之间以及业务系统之间的联动提供支持。

业务系统通过设置交换信息库作为与信息平台的接入端代理，来实现业务系统与信息平台的互联互通性。体现在数据结构层面，就是业务信息库通过交换信

息库实现数据的接入。除了在信息平台上保存即时产生的，符合临床诊疗要求的各种业务原始数据以外，还需要以患者的基本信息为基础，整合患者历次就诊的就诊履历，完善患者的医院电子病历。患者的基本信息保存在基础信息库中，电子病历保存在临床文档信息库中，也就是说，业务信息库根据基础信息库中的患者信息进行整合，并最终形成存储在临床文档信息库中的电子病历。

4.4.4交换信息库

交换信息库是信息平台的数据转换枢纽，包括中心交换库和对外交换库。中心交换库的作用主要是对医疗机构内部信息系统业务数据的采集、整合以及医疗机构内部信息系统之间业务联动。对外交换库的作用主要是实现医院信息平台与区域信息平台的数据交互。

?中心交换库

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

?对外交换库

对外信息交换库是医院信息系统与区域卫生信息平台进行数据交换的信息存储区域。为保证系统的相对独立，我们设立对外信息交换数据库。对外交换库存储要推送到区域卫生信息平台的电子病历，同时也存储着从区域平台推送来的健康档案。在对外交换库中完成电子病历与健康档案的相互转换。

4.3.5临床文档库(CDR)

电子病历存储服务具体由临床数据存储库 CDR(Clinical Data Repository)来实现。电子病历主要由临床文档组成，临床文档是电子病历中各类业务活动记录的基本形式。临床文档中的数据存在着一定的层级结构关系，其中有包含与被包含的关系，也有按同类属性相互嵌套的关系。临床文档的结构化和标准化，是

电子病历实现语义层数据交换与共享的基本要求。

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

CDR独立存在主要用于实现：

1、与复杂的业务处理流程分割

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

2、透明、一致化的数据模型

CDR的独立存在使得一个统一的、透明的、一致化的电子病历信息模型的设计与实现成为可能。这样一个模型的存在对所有应用系统的开发商、对系统集成、对医生护士对病人信息的进一步应用都十分重要。

3、应用系统升级容易

由于CDR和复杂的业务处理流程相分割，使得以后各应用系统（POS）的升级换代变得简单易行。而这种变化随着业务流程的变化和信息化水平的提高，是经常发生的，也是医院信息化发展进程中最让人头痛的问题。

4、对医生/护士更友善，效率更高

医生/护士使用物理上保存的以病人为中心的电子病历记录比起使用分散在不同应用系统中的病人记录来更得心应手、更符合他们的思维习惯，应答速度会更快。特别是简单、统一、透明的信息模型的存在使得他们有可能根据自己临床工作的需要从CDR中剪裁出自己的病人临床记录子集。

5、有利于电子病历深层次应用的开发推广

电子病历的存在不仅仅是要满足临床信息查询的需要，更重要的是要满足临床决策、教学、科研的深层次的要求，例如警告与提示系统、临床路径控制、循证医学支持等等。这些应用的开发，当面对一个数据相对稳定、信息模型简单清晰、与操作过程无关的存储库时，要简单得多。特别的，当服务点应用系统(Point of Service，PoS)发生变化时，也不会影响这些深层次的应用。