近 20 年来，我国医疗卫生信息化取得了突飞猛进的发展，初期的应用比较简单，仅仅是物品和简单财务的管理，所有的应用都由一个供应商提供，服务于不同的应用，包装在一个软件应用中，不需要接口引擎的开发与设计。然而，医疗卫生信息的复杂性决定了信息系统的应用越来越复杂，对信息的需求也在不断发展，任何一个厂商不可能提供所有医疗所需要的所有产品，要实现真正一体化的医疗信息系统，必须引进不同服务商的软件产品。

因此在同一家单位，集成不同厂商的产品服务就成为医疗信息化建设过程中必然遇到的问题。一开始几个厂商的产品要达到互连互通，往往是采用P2P点对点的接口方式，因为这种方式简单、成本比较高，例如，将一个医疗保险的结算系统与医院的住院及门诊病人的费用管理系统集成。然而，当医院的应用扩展到十几个乃至几十个应用系统时，问题就变得困难起来，牵一发动全身，往往还会出现BUG。

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

党中央、国务院在《中共中央国务院关于深化医药卫生体制改革的意见》中提出要大力推进医疗医药卫生信息化，加快医疗卫生信息系统建设，要以推进公共卫生、医疗、医保、药品、财务监管信息化建设为着力点，整合资源，加强信息标准化和公共服务信息平台建设，逐步实现统一高效、互联互通。

特别是 2003 年 “非典”疫情暴露出信息不通、指挥不灵、公共卫生信息系统薄弱等问题之后，卫生部及时提出了《国家公共卫生信息系统建设方案》，促进了信息化工作的发展，信息化基础建设得到加强，建立了全国疾病预防控制与突发公共卫生事件报告系统、部（省）级应急指挥与决策信息系统、卫生统计网络直报系统、新型农村合作医疗信息系统、医疗救治信息系统、卫生执法监督等系统。这些以业务应用为主线的信息系统对于提高业务效率和决策水平发挥了重要作用。随着信息化普及、网络拓展，数据采集手段越来越方便，大量数据和信息资源迅速积累，由于信息标准开发滞后，信息资源整合能力薄弱，又导致出现资源利用不足和共享成本过高等方面问题。为此在医改文件中提出要加强信息标准化和公共服务信息平台建设，逐步实现统一高效、互联互通。

尽管“信息集成平台”一词还没有精确与权威的定义，但是“信息集成平台”的概念却已经被广泛采用，其含义就是为某一具体领域内的全体用户，提供统一的数据（信息）采集、处理、分析、利用手段和技术支撑。

集成信息平台的建设目标是以“资源整合和信息共享”为目标，为卫生管理与决策人员提供高效的信息支持和服务，实现部门之间信息共享和业务协同，提高管理效率和科学决策水平，提升落实医改各项任务和应对突发公共卫生事件的能力。综合卫生管理信息平台开发是卫生信息化建设的一项重要任务。

二、设计目标

医疗信息平台建设的目标是：通过整合信息资源，开发信息标准，部署通用信息分析工具、信息安全与共享技术支撑环境，实现综合管理各部门的互联互通和信息共享，促进管理部门间的业务协同，提高卫生管理工作效率和决策水平，提高对深化医药卫生体制改革各项任务实施情况动态监测、宏观调控和科学管理能力，为各级政府部门提供及时、准确、全面的信息。

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

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

通过建设集成信息平台，将原先分布在各业务系统中的信息交换整合到信息平台，实现各个科室之间、医疗单位之间信息的互联互通，最大限度地方便用户操作，方便各类管理人员宏观分析与决策。

2.2实现管理信息支撑功能

全面、准确、及时地掌握医疗相关信息是管理科学决策的基础，要求平台具有整合与管理相关信息资源的功能，包括建立卫生指标信息库，卫生信息资源共享库，实现信息的快速存取和传递；运用信息技术、卫生经济学和管理科学知识，加强信息资源开发，将信息技术、信息内容和管理决策制度组成一个有机整体，实现对管理相关信息的收集、加工、存储、挖掘、分析和传递功能，为管理提供丰富、快捷、优质的信息服务。

2.3实现卫生管理信息辅助决策功能

医疗管理信息平台要根据医疗管理各项具体业务需要，利用现代信息分析方法和工具建立相应的辅助决策系统，包括支持各项规划、计划制定工作的各类分析预测模型，支持重大医疗政策调整预警系统、政策模拟模型，支持深化医药卫生体制改革效果评估模型等。为管理科学化服务。

2.4实现面向社会的信息服务功能

医疗卫生工作与发展关系到人民群众切身利益，综合管理信息平台在为管理决策者、业务人员、信息人员提供信息支持与服务的同时，提供向社会公众发布各种政务信息和信息反馈渠道。

2.5提高统一数据采集服务能力

过去数据采集功能都是与业务应用系统捆绑在一起，每当需要变更业务应用时，就要调整数据采集手段。因此每当突发事件出现后，业务部门就下发一个文档表格或电子表格。这种数据采集方式，既没有数据校验也没有质量控制，数据不一致问题十分严重，后期的数据清理与整合需耗费大量人力。采用开发数据录入软件的方式又存在部署困难和不灵活等问题，甚至需要通过办培训班部署数据录入采集工作。

对于基层单位，他们面对上级各种各样的数据采集要求，接口开发工作耗费大量资金投入。例如医保、新农合、医院监管部门都要医院报送数据，社区卫生、公共卫生等部门也要与医院交换数据，导致一个医院要开发多个接口，放置多台前置机。统一数据采集平台设计就是提供可满足多种形式数据采集服务能力，提供表单设计、逻辑检查、数据接口，离线采集、在线采集和数据转储等多种形式，可以用“推送”或“抓取”方式从其他系统中自动获取数据。

通过建立数据采集平台，接收和处理来自各个业务领域系统的数据，实现数据采集工作的灵活设置和快速部署，适用深化医药卫生体制改革监督和监测的工作要求，以及应对各种突发公共卫生事件处置工作。利用平台收集数据，实现了数据采集与应用系统的分离，使数据采集工作更专业化和规范化，减轻数据提供单位的负担，提高数据采集效率和质量。

2.6提高统一的数据资源管理能力

在信息化建设过程中，业务部门根据自身的情况与需要建立了各自的系统，这些系统往往是在不同时期、由不同的公司、利用不同的软件、采用不同的标准开发的，并且运行在不同的操作系统和数据库平台上，数据资源分布在各自系统中，数据库很多，经常出现重复收集和重复报送数据的情况。以信息资源共享最大化为追求设计综合卫生管理信息平台，通过提供统一的数据资源管理平台让信息资源使用者知道系统中有什么样的资源？信息内容是什么？在什么地方以什么形式存储？以及如何获取和使用这些资源。为了实现资源整合工作，一是要开发信息资源元数据标准、标识规范、分类标准，并在基础之上建立信息资源注册登记系统，实现信息资源编目管理。二是，建立信息资源目录信息采集系统，收集相关单位和下属单位的信息资源目录。三是，实现信息资源信息分发，将物理上分散的卫生综合管理信息资源，形成一个逻辑完整的整体。各个信息资源所有者按照目录体系标准,提供资源信息。四是，通过建立统一的信息资源访问控制机制，实现资源服务的共享和利用。

2.7提高信息产出能力

目前各单位业务工作人员、统计信息人员使用各自的数据处理与分析工具，独立完成相关数据清洗、汇总工作，没有专业分工，工作效率低。统一的数据加工服务平台设计目的是实现数据处理专业化与规范化，主要解决两个方面的问题。

第一，提供数据清洗、转换，排重等服务工具，积累和形成专业数据仓库和数据集市。第二，提供数据标准化服务工具，支撑数据编码，数据颗粒度等标准化工作，逐步实现相关数据指标的一致性。第三，提供统一的数据处理工具，降低各自采购软件工具的费用，保证数据格式一致性，方便统计分析。统一数据加工处理服务就是让数据加工和分析人员更方便的利用数据资源进行数据处理和分析，例如为用户提供查询、报表、多维分析和数据深度分析等工具，提高信息产出质量和效率。统一数据加工处理服务应能为业务用户提供面向业务主题的、集成的、稳定的数据加工处理服务应用，减少数据转换和整理工作负担。

2.8提高信息利用能力

医疗集成信息平台作为管理各个相关业务系统的信息枢纽，应为各种业务用户提供统一的信息服务利用支撑平台。现在很多情况下用户需要分别登录到不同的系统，访问数据和获取信息。随着应用的增加，用户操作越来越复杂，管理工作将日益困难。统一的信息服务利用支撑包括：一是统一的用户注册管理体系。用户应实现一次登录，自动获取到可访问的各种数据资源和应用服务的权限，既方便操作又保证了用户管理安全。二是统一的信息展现服务。使业务人员使用支撑工具，将信息以表格、图形和报告等形式将信息展现给上级领导。三是，统一的信息查询和管理服务。根据不同用户个性化信息服务需求，满足大家个性化的信息查询和利用要求。

三、现状分析

3.1系统集成度低

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

点对点方式

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

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

ü 接口不规范

接口间的调用方式各不相同，如有存储过程、视图、中间表、应用程序、动态库等等,无法形成统一的接口规范。数据不共享虽然现在大多数系统间均有做接口进行数据交互，但往往只做到最基础的数据采集上，信息间的共享并不充分，如急诊、危重病人的报告、异常的报告无法做到第一时间提醒医生。医生也无法主动查询病人的报告进行到哪一步。

ü 数据不一致

由于数据共享不充分，导致多数接口在重复做，往往会出现数据在不同系统间不一致的情况，如同样的检验报告，在LIS系统下看到的格式有可能与HIS看到的不一样，甚至连数据都有可能不同，这就给医生带来不小的困扰。

ü 数据入口多

由于点对点的接口方式，数据重复存在于各个系统中，无法形成统一的数据中心模式，造成同一数据多个采集入口。

ü 接口安全性差

很显然在不同供应商之间开放数据库用户进行连接视图或读写中间表，这种接口方式的安全性较低，一旦出现数据异常责任往往无法追踪。

ü 接口耦合度高

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

3.2没有采用标准化方法实现数据交换共享

医疗信息中以临床文档（CDA）为重，国际标准最新HL7 FHIR和 IHE已经发布多年，但国内由于各种原因始终没有建立起来，医疗文档数据在各级单位之间无法实现互通互联，主要原因不是上级不重视其重要性，主要在于技术门槛比较高，需要做大量的数据分析、数据建模、标准翻译（loinc、snomed等），ICD10全国都无法完全通用。各个企业不愿意在这个上面进行投入，以满足医疗机构眼前的功能为主。更不用提数据模的复用性。

3.3数据安全性低、无隐私

“重应用、轻安全”一直中小公司医疗软件产品的通病，通常一个数据库sa(超级用户)用户密码裸跑全场。所谓用户权限往往就是界面的隐藏而已，完全没有安全而言。众多的软件应用采用的安全方法和体系也是不一而足，往往存在很大的安全漏洞，对于隐私大部分软件根本就没有相关的体系架构。

3.4多系统无统一登录管理

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

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

ü 系统维护成本高

四、网格云集成平台方案

4.1集成平台技术要求

集成平台应该以一个应用管理（APPMC）为中心，这里的应用管理中心不是一个应用程序的含义，广义的应用管理中心是包含多个应用程序(HIS,Pacs,OA…)的集合，打破应用管理的边界，同时利用业务流（BPM）和分布式事务实现对（微）服务的业务编排。单纯的技术微服务不一定具有一定的业务意义，通过业务流灵活配置流程实现业务需求的多样化和个性化。

平台从技术逻辑分层分为数据管理和服务管理。数据管理依托数据模和值集(valueSet)利用数据仓储技术实现对资源的有效管理。服务管理是把具体的操作微服务化，通过restful Api访问方式同时利用服务路由与服务适配器实现跨语言、跨平台的调用管理。

利用网格云技术实现平台级服务分布，用户只需要通过restful api连接平台服务，不必关心具体服务是在哪里实现，就可以方便的使用。同时实现服务即插即用。

4.1.1分布式海量资源数据中心

打破开发应用者这选择数据库的传统，开发者或者数据使用者直接面向基于Fhir的restful Api+Search（http://www.yunhis.net/forums/forum/fhir/fhir%e8%b5%84%e6%96%99%e7%bf%bb%e8%af%91）方式开发即可。让开发者关注自己的核心技术。

所有数据（包括服务dll/exe、数据模定义…）皆是资源，平台需要解决资源数据高效的存储和检索，并提供分布式管理，同时支持并发分布性事务。为解决海量数据的汇总检索，平台须提供“数据账套”的理念，高并发数据采用高速内存数据缓冲池。

4.1.2丰富的esb数据总线

ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通，是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：

①面向服务的架构—分布式的应用由可重用的服务组成；

②面向消息的架构—应用之间通过ESB发送和接受消息；

③事件驱动的架构—应用之间异步地产生和接收消息。

ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为低廉的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

ESB核心功能:

a、提供位置透明的消息路由和寻址服务。

b、提供（微服务、远程服务）服务注册和命名的管理服务。

c、支持多消息传递泛型（如请求/响应,发布/订阅等）。

d、支持多种广泛使用的传输协议。

e、支持多种数据格式及相互转换。

f、提供日志和监控功能。

g、支持广泛的服务路由功能。

4.1.3基于资源目录的管理(安全/权限/隐私)

打破以往对资源数据单纯表级数据增删改查安全权限设置的方式，构建全新理念的以资源目录的方式来全方位管理资源访问的安全问题，在此基础上逐步实现对隐私权的管理。

资源安全与隐私不应该是开发者考虑的问题，安全/隐私要求是以用户实际应用为依据创建的。不同的客户对同样的资源有着不同的安全需求，应该以平台服务架构的方式由客户进行合理规划后逐步建立起来的一套完整方案。

4.1.4基于Fhir的资源(ResourceType)数据模管理

大型数据中心建设必须依赖统一的数据模，数据模建立不仅是一套唯一的数据标准而且要具备真正意义的语义表达，国际组织HL7的CDA交互文档 Fhir在这方面做了大量的规范性工作，制定的医疗交互数据的规范和语义表达规范。参照其规范对平台资源数据的建设有着重大的意义。

4.1.5统一的用户信息鉴权中心

用户鉴权包括用户安全登录信息和可以相互认证的身份信息。应用管理中心中的多个应用使用access token统一访问鉴权中心进行鉴权。实现SSO(单点登录)也是以此为基础。

使用鉴权可以用来识别出非法用户。用户鉴权，是对试图接入网络的用户进行鉴权，审核其是否有权访问网络。通过用户鉴权可以保护网络，防止非法盗用；同时通过拒绝假冒合法客户的“入侵”而保护该网络中的客户。

统一的身份鉴权，对于跨应用授权相当重要。比如政府系统都需要为市长开放各种访问权，正常市长更替以往的方式就是每个系统再建立一个市长身份的用户，统一的鉴权中心，如果本系统信任组织部确认的市长，那么本系统面向一个市长身份角色的授权即可。每任市长只需要组织部的授权为市长角色，众多系统访问仅需一次授权即可。

4.1.6完善的业务流管理

让微服务组合成大的应用，让数据流动起来完全依赖于完善的BPM(业务流)。关键绩效指标（PKI）必须以业务流为依托才能完美的实现。业务流程管理（Business Process Management, BPM）不是一个新概念。它是从相关的业务流程变革领域，如业务流程改进（BPI）、业务流程重组（BPR）、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、EAI、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

从管理理论或战略的层面看，业务流程管理（BPM）就是在一个存在内部事件和外部事件的环境中，由一组相互依赖的业务流程出发，对业务进行描述、理解、表示、组织和维护。从具体实施的层面看，BPM 还可分为流程分析、流程定义与重定义、资源分配、时间安排、流程管理、流程质量与效率测评、流程优化等。

4.1.7灵活的消息中心

消息中心需支持在线或者离线模式确保消息准确推送到相应客户端。消息接口类别需要支持邮件、短信、客户端消息，消息类型需要分为任务、通知、事件。

必须保证消息的准确到达，时序图如下：

消息中心支持发布、订阅，消息要保证时效，不得出现重复。

4.1.8友好的Restful Api 访问接口

完全按照HL7 FHIR中Restful Api（http://hl7.org/fhir/http.html）定义访问接口。URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。这种模块化使RESTful应用程序更加灵活，更易于扩展。可以采用面向组件的开发方法，只要它们访问正确的REST端点，不同的客户端和服务器就可以相互交互。

4.1.9支持多语言的本地服务适配器

集成平台的服务不能限制只使用一种开发语言，否则就不能称为集成平台，平台集成应该包含三个方面的集成，一是资源数据集成，二是服务集成，三是数据与服务合并的流集成。

通过多语言的服务适配器需要支持流行的开发语言：.net，Java，Python，C++ ,C等等。服务端和客户端通过服务环境配置，便可以支持多语言运行环境。

4.1.10分布式服务事务

这里的分布式事务不单纯是数据库的事务，而是面向基于服务操作的事务物，平台服务需要编排一些微服务成一个服务，一部分业务需求微服务组合事务性。微服务可能在本地或者远程，本地服务也可能是由多个语言编写，所以需要实现分布式事务。分布式事务要求保证数据最终的一致性。

4.1.11支持多语言的注册服务与发现中心

服务注册就是将所有的服务接口注册到一个中心的分布式服务集群上（你可以考虑成apache的zookeeper服务实现的效果）。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用。

服务注册要包括本地与远程服务注册，本地服务注册需要支持多语言开发的DLL\EXE等。同时需要提供相应的本地运行环境。提供灵活的服务注册和发现接口。

4.1.12安全的数字证书管理中心

数据通讯加密和数据加密/时间戳都离不开数字证书，需要建立一套完善的数字证书管理机制，确保各种数据的传输和存储安全。对于整个平台的数据安全是相当重要的。

使用数字证书的必要性。

1、信息的保密性

交易中的商务信息均有保密的要求。如信用卡的帐号和用户名被人知悉，就可能被盗用，订货和付款的信息被竞争对手获悉，就可能丧失商机。因此在电子商务的信息传播中一般均有加密的要求。

2、交易者身份的确定性

网上交易的双方很可能素昧平生，相隔千里。要使交易成功首先要能确认对方的身份，对商家要考虑客户端不能是骗子，而客户也会担心网上的商店不是一个玩弄欺诈的黑店。因此能方便而可靠地确认对方身份是交易的前提。对于为顾客或用户开展服务的银行、信用卡公司和销售商店，为了做到安全、保密、可靠地开展服务活动，都要进行身份认证的工作。对有关的销售商店来说，他们对顾客所用的信用卡的号码是不知道的，商店只能把信用卡的确认工作完全交给银行来完成。银行和信用卡公司可以采用各种保密与识别方法，确认顾客的身份是否合法，同时还要防止发生拒付款问题以及确认订货和订货收据信息等。

3、不可否认性

由于商情的千变万化，交易一旦达成是不能被否认的。否则必然会损害一方的利益。例如订购黄金，订货时金价较低，但收到订单后，金价上涨了，如收单方能否认受到订单的实际时间，甚至否认收到订单的事实，则订货方就会蒙受损失。因此电子交易通信过程的各个环节都必须是不可否认的。

4、不可修改性

交易的文件是不可被修改的，如上例所举的订购黄金。供货单位在收到订单后，发现金价大幅上涨了，如其能改动文件内容，将订购数1吨改为1克，则可大幅受益，那么订货单位可能就会因此而蒙受损失。因此电子交易文件也要能做到不可修改，以保障交易的严肃和公正。

我们可以使用数字证书，通过运用对称和非对称密码体制等密码技术建立起一套严密的身份认证系统，从而保证：信息除发送方和接收方外不被其它人窃取;信息在传输过程中不被篡改;发送方能够通过数字证书来确认接收方的身份;发送方对于自己的信息不能抵赖。

4.1.13基于Fhir统一的Terminology (专业术语)

Terminology广义的来讲就是数据字典，就是数据规范。平台全域采用HL7 Fhir中定义的NamingSystem(命名)、CodeSystem(编码)、ValueSet(值集)等。此规范规定了完善的数据字典的定义、编码、引用来源、释义、时效、使用原则。

4.1.14完整的日志监视与管理

在一个完整的信息系统里面，日志系统是一个非常重要的功能组成部分。它可以记录下系统所产生的所有行为，并按照某种规范表达出来。我们可以使用日志系统所记录的信息为系统进行排错，优化系统的性能，或者根据这些信息调整系统的行为。在安全领域，日志系统的重要地位尤甚，可以说是安全审计方面最主要的工具之一。

4.2系统整体结构

4.2.1网格云架构

依托ESB数据总线，通过公共的服务调用接口调用各种服务，平台本身的服务包括鉴权中心、资源目录管理、资源管理、BPM流，分布式事务管理、消息中心、日志管理中心。用户服务的应用管理在服务管理的适配器下面。

服务管理：管理各种语言运行的环境配置与调用，标准化XML（Json）服务调用接口。同一平台下支持多语言同时运行与协调。远程服务接口提供了远程访问服务。实现服务的多元化管理。

服务管理提供均衡负载和路由功能，保证平台下的各种应用无缝连接和平稳运行。

BPM业务流管理:采用BPMN2.0业务流建模，完全符合业务流相关规范，用户可以灵活的自由面向平台服务表达建立自己专属的业务流。

应用管理中心：为用户虚拟化一个应用管理单元，定义和初始化一个用户使用哪些版本的资源、服务、安全的资源边界、业务流。

鉴权中心：服务于全域的用户，本身可以跨平台访问，安全的用户信息、统一的登录、标准的身份信息。给平台提供唯一的安全认证。采用OAuth2安全系统，使用restful Api 访问方式。

资源目录管理：建立一个应用管理中心后，平台就需要通过资源目录管理开始规划资源的访问权限和范围。

消息中心：采用supersocket 的webSocket技术，实现实时的P2P消息通讯。

分布式事务：分布式事务根据操作特性（确认、补偿、取消）自动支持SAGA和TCC两种模式，同时支持手工启动事物和Buddle中自动事务。

日志中心：平台可实时监控系统的工作状态和记录相应错误信息，实现对日志的监控和分析。

资源管理中心：基于HL7 FHIR的数据建模方式和表达，采用MySql8.0数据库，根据数据模定义自动生成相应的资源索引数据，同时支持海量数据的分布式数据库，实现了根据用户面向资源自定义的运行数据、临时数据、历史数据自动进行表横切技术。

4.2.2医院集成平台系统结构

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

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

4.2.3病人主索引功能

注册服务中的患者注册一般通过建立患者主索引 MPI(Master Patient Identifiers)来实现。

4.2.3.1 患者主索引和机构级患者主索引（EMPI）

患者主索引 MPI，是指在特定域范围内，用以标识该域内每个患者实例并保持其唯一性的编码。患者唯一标识是指用于临床实际业务并且能够辅助进行患者信息唯一性识别，在该域或跨域各涉众均可见的患者唯一编码。患者主索引服务是指为保持在多域或跨域中用以标识患者实例所涉及的所有域中患者实例的唯一性，所提供的一种跨域的系统服务。各地可采用身份证、社保卡、医保卡、市民卡、健康卡等来进行唯一标识的加载与识别。

MPI 是一个十分宽泛的概念，但它通常是和患者主 ID 域的建立联系在一起的。这个主 ID 域相对其他的 ID 域，通常可以在更大的范围内适用，是一个“机构级别”的 ID 域。将多个患者 ID 域分级包含入一个“患者主 ID 域”中的方法，可以被看作是交叉索引的一个特殊用法，其中的各个 ID 域中的 ID 都和主 ID 域中的 ID 建立交叉索引关系。下图描述了两种可能采用的配置方式。

图： PIX 集成规范与 MPI 的关系

4.2.3.2患者标识交叉索引

不同医疗机构采用不同的标识码标识同一个患者，当患者在不同医疗机构间转诊需要交换转诊或协作信息进而共享医疗文档时，首先要求能够准确识别患者的身份，这就需要一个交叉索引系统，把患者在不同医疗机构的标识码通过索引联系起来，在需要访问某个系统时可以提供患者在该系统的识别码。下图展示不同系统通过交叉索引系统注册和提供患者标识，从而顺利完成跨机构信息访问的任务。

图 5-9 交叉索引注册和使用

1） A 医院向交叉索引管理系统输入患者标识信息。

2）交叉索引系统将输入的信息与系统中的现有患者进行匹配，形成 A 医院患者标识与现有患者的交叉索引。

3） B 医院向交叉索引管理系统输入患者标识信息。

4）交叉索引系统将输入的信息与系统中的现有患者进行匹配，形成 B 医院患者标识与现有患者的交叉索引。

5） A 医院系统需要访问一位患者在 B 医院的资料，向 B 医院系统发送请求。

6） A 医院的请求中只有 A 医院的患者标识，因此 B 医院收到请求后首先到交叉索引管理系统查询该患者在本院的标识。

7） B 医院系统获得请求的患者在本院的标识后可以在本院系统查找该患者的资料。

8） B 医院系统将结果回复给请求的 A 医院系统。

如上面的一般场景所述，交叉索引系统主要提供索引注册和索引查询服务，另外还有一些保证系统运转的系统管理和维护需求。

上述内容描述了患者标识交叉索引在跨机构业务上的应用，而在一个机构内跨应用系统（不同开发商的产品）间的业务上也可参考使用，此时不同的域就是指不同的应用系统，可根据实际情况确定如何使用患者标识交叉索引。

4.2.3.3 MPI 服务功能

患者标识交叉索引系统服务用例

患者信息注册

业务系统希望把一个患者的索引加入到交叉索引系统时，向交叉索引系统传送请求注册消息，消息中包含待注册的患者信息，主要元素包括：业务系统 ID、患者 ID、姓名、性别、出生日期、出生地、民族、母亲姓名、婚姻状况、身份证号、住址、电话等。

交叉索引系统通过匹配规则检查系统中是否已存在该患者的索引，按照新增索引或更新索引两种情况分别处理。新增索引需要在交叉索引系统中记录业务系统的索引，同时产生主索引。如果该患者在交叉索引系统中有潜在重复的记录，还需要记录潜在重复信息。更新索引需要更新匹配的业务系统的索引，同时更新主索引。主索引更新时，需要对订阅主索引的系统发布更新的主索引。

登记患者流程图示如下：

患者信息匹配

接收到外部系统登记患者的请求信息后，交叉索引系统首先使用业务系统号＋患者局部 ID（LID）查找，如果存在精确匹配的索引，只需要对原索引信息进行更新即可，如果没有找到精确匹配的患者索引，则需要根据患者的其它信息和系统中的记录进行匹配。交叉索引匹配引擎首先通过预定义的匹配条件选定一批相近的记录，对每个记录计算匹配度，再根据这组记录的匹配度确定请求登记的信息属于新患者、现有患者或者潜在重复患者。这里所说的潜在重复是指两个患者的信息匹配度比较高但还不足以判定为同一个人。

更新主索引

在交叉索引系统新增或更新一个患者的索引信息后，同时需要对主索引进行更新。向交叉索引提供患者信息注册的系统可能拥有不同的信息可信度，因此其提供的信息对主索引的影响有所不同。更新操作根据新的信息对主索引每个字段记录的信息进行评价，确定该字段的最佳值。

记录潜在重复

匹配引擎检测到申请登记的患者和现存索引存在潜在重复时，需要对潜在重复的情况进行记录，并返回给业务系统或系统管理员进行处理。

发布主索引

业务系统可以向交叉索引系统订阅主索引，便于在以后的应用中加快应用，提高信息准确性，交叉索引系统在对一个患者的主索引更新或增加新索引后，需要向订阅主索引的业务系统发布更新。

记录操作日志

交叉索引系统业务记录发生的变化都需要记录操作日志，并能实现回退。

需要记录的业务操作：

新增局部索引	更新局部索引	合并索引

新增主索引	更新主索引	取消索引合并

索引自动匹配	取消自动匹配

获取患者交叉索引

交叉索引系统的主要功能是为业务系统提供业务系统交叉索引表，业务系统可以通过两种方式获取交叉索引：通过全局标识获取、通过患者信息获取。

如果业务系统中记录了患者全局标识，交叉索引系统可以直接检索到该患者的交叉索引表。

当业务系统仅提供患者本地信息向交叉索引系统检索交叉索引时，交叉索引系统首先要进行患者信息匹配，在交叉索引库中查找可以匹配的病人。如果能够精确匹配，则返回该患者的交叉索引；如果仅能匹配到潜在重复，则返回潜在重复信息，由业务系统进一步选择；如果匹配失败，则返回空记录。

获取患者主索引信息

交叉索引系统存储了患者在多个系统中的标识信息，并由此维护一个主索引，记录最准确的患者基本信息，该信息可以提供给业务系统使用，提高业务系统中患者信息的质量。

获取患者主索引信息的使用方法要求与获取患者交叉索引类似，可以由业务系统提供全局标识获取，也可以由业务系统提供患者本地信息获取。

4.2.4数据资源目录管理

针对数据资源及其标准的管理需求，平台管理信息平台提供了相应的系统功能，以便管理者对数据资源进行有效的配置和管理，从而使用户能够得到方便、快捷的信息服务。

一、使用与管理需求

（一）使用者的需求：信息资源发现与定位

由于信息资源数量多、门类广、分布分散、信息不对称的特性，造成信息资源共享中的困难。通过建立信息资源目录体系可以在使用者和各部门之间搭建起一个桥梁和纽带，首先方便使用者发现所需要的信息资源，并且根据信息资源元数据中的定位信息获取实际的数据。具体使用模式包括：

（1）信息资源目录以多种不同的分类形式提供给使用者。

（2）使用者可以使用适合自己业务领域的信息资源目录查找关心的信息资源。

（3）使用者可以通过搜索找到所关心的资源。信息资源目录能够提供多种查找方式，如提供名称、属性等查找条件查找信息资源。

（4）使用者能够浏览对信息资源的描述，从而获取信息资源的途径。

（二）管理者的需求：卫生信息资源管理

医疗信息资源作为生产要素、无形资产和社会财富是重要的卫生战略资源，加强医疗信息资源管理，提高其开发利用水平有利于推动经济社会全面发展，有利于推动部门转变职能以便更好地履行医疗资源调节、市场监管和公共卫生服务职能。加强医疗信息资源管理最基础的工作是要掌握卫生信息资源的数量、质量、分布等具体情况。通过医疗信息资源目录体系的建设，形成信息资产的注册登记和管理制度对于及时掌握动态的医疗信息资源的现状、规划医疗信息资源的建设具有非常重要的作用。具体管理内容包括：

（1）管理者能够对信息资源目录进行管理，建立目录、增加目录节点、修改节点名称等。

（2）管理者能够对注册的信息资源进行审核，规范化注册内容，统一信息资源名称及唯一合法出处。

（3）管理者能够对信息资源做发布、作废等管理处理。

二、目录体系管理

本部分描述了信息资源目录体系的建立和管理工作，主要包括管理总体架构、管理角色及其职责、目录体系建立活动等管理要求。

（一）管理框架

信息资源目录体系管理架构包括信息资源目录体系使用和管理的三个角色和六项活动。

三个角色是信息资源目录的提供者、管理者和使用者。六项活动包括规划、编目、注册、发布、维护、查询。如下图所示。

提供者负责信息资源目录内容的规划和编目，管理者负责信息资源目录内容的注册、发布以及系统维护，使用者可以查询信息资源目录内容。

（二）管理职责

(a) 提供者负责信息资源的编目；向管理者注册目录内容并负责更新；对信息资源目录内容设置使用权限；负责提供与目录内容相关联的信息资源。

(b) 管理者

按照目录标准及相关管理办法进行资源标识符的分配、管理和使用；负责信息资源目录内容的注册、发布与系统的维护；提供信息资源目录内容的查询服务。

(c) 使用者

对获取的目录内容在授权范围内使用。

（三）管理活动

信息资源目录体系管理角色及其活动见下图。

1. 规划

按照管理范围和职责权限梳理、规划信息资源的内容和目录、数据元的内容和目录。

制定医疗信息资源目录体系建设计划。

依据医疗信息资源要求的要求，结合数据中心信息资源特点定义元数据。依据信息资源标识符编码方案的要求标识目录中的资源。

2. 编目

提供者(信息资源管理者)按照规划中设定的元数据对共享信息资源和标准数据元进行目录编辑，并形成目录内容。按照主题分类、行业分类、服务分类或者资源形态四种分类设置信息资源分类，其中必须设置主题分类，也可依据应用需要设置其他一种或多种分类。提供者对信息资源目录内容设置使用权限。

3. 注册

提供者向管理者注册目录内容，包括信息资源目录和数据元目录，管理者对注册的目录内容进行审核校验和管理，管理者向提供者反馈错误的目录内容注册信息。

提供者提交注册的目录内容遵循数据中心制订的核心元数据标准，并且必须包含核心元数据的必选项。

4. 发布

管理者发布信息资源目录和数据元目录。发布的信息资源目录可以以主题分类为主，发布的数据元目录可以选用主题分类或部门分类等。

5. 查询

管理者提供信息资源目录内容的查询服务，满足使用者检索信息资源目录内容，并定位信息资源的需求。

6. 维护

管理者保存、备份、恢复与注销信息资源目录内容，目录内容的更新维护由提供者负责，目录系统的更新维护工作由管理者承担。

三、基本功能

信息资源目录管理的系统功能需求包括目录结构管理、目录内容编目、注册、发布、查询、维护。

（一）目录结构管理

提供对目录类别及各类目下目录结构的管理功能，具体包括：

√定义：新增或某目录类别下的目录节点，定义目录类别或节点的名称、类别描述。节点应是多级的。

√修改。修改已有的目录类别名称或目录节点或目录节点。

√调整。目录子节点能够根据需要调整层级。

（二）编目

提供信息资源核心元数据的编辑功能，包括：

√信息资源相关特征信息，形成信息资源核心元数据；

√资源核心元数据中的分类信息进行赋值；

√提供者可在编目时对信息资源进行唯一标识符的赋码。

（三）注册

1、信息资源注册

信息资源目录提供者向信息资源目录管理者注册信息资源核心元数据。注册的功能包括：

√提交

通过管理者和提供者之间的信息资源元数据汇交平台，实现信息资源元数据的提交。

√审核

通过建立相应的审核系统，管理者确认提供者提交的信息资源元数据是符合标准要求的。未通过审核的元数据应返回给提供者修改。

对于提供者已经对信息资源唯一标识符赋码的情况，管理者对信息资源的唯一标识符进行审核，检查提供者所提交的唯一标识符是否符合标准的要求。如果不符合，管理者则根据标准对该标识符进行修订，并将对该标识符的赋码返回给提供者。

对于提供者未对信息资源唯一标识符赋码的情况，由管理者对信息资源的唯一标识符进行赋码。

√入库

对于通过审核的元数据，实现元数据的入库管理，形成正式的目录。这里的库指的是管理者向使用者提供信息资源目录服务的核心元数据库。

2、数据元注册与审批信息资源的提供者能根据符合资源类型的元数据注册数据元。然后将注册的数据元指定其所在的目录节点。具有以下功能：

√数据元注册。提供者能够针对某元数据定义结构注册数据元，并提交数据元。

√数据元修改。提供者能够对没有提交的数据元进行修改，但是已经提交或已发布的数据元不能再修改。

√数据元删除。提供者能够对没有提交的数据元删除，但是已经提交或已发布的数据元不能删除。

管理者能够对信息资源提供者提交的数据元内容进行审批，主要目的是要统一

信息资源的唯一来源，统一术语等工作，以及判断分类是否正确，为信息资源的真实性、可利用性、合法性做好基础管理。包括功能如下：

数据元审批。管理员对已提交的数据元内容进行审批，可以填写审批结果。

信息资源的提供者能够浏览到审批意见，并可以对审批没有通过的数据元做修改操作。审议结果修改。管理员可以对没有发布的数据元的审批结果做修改。

（四）发布

1、信息资源目录发布

管理者发布目录内容，包括信息资源核心元数据。管理者通过目录服务器，把信息资源核心元数据库的内容发布到资源目录服务系统中。发布具备的基本功能包括：

√发布服务管理

发布服务管理的管理对象是目录服务器，它控制目录服务器的运行。并通过目录服务器的相关管理功能，实现特定部分的元数据是否可对外服务。

√发布网站管理

实现信息资源目录网站的基本管理，包括网站的运行、网页程序的更新等内容。

2、数据元发布

已经审批通过的数据元可以被管理员发布。发布后的数据元将能够被信息资源的使用者所查看与使用。包括功能如下：

√数据元发布。管理员可以对审批通过的数据元做发布处理，并提供相关说明。

√数据元作废。管理员可以根据实际情况对数据元做作废处理。作废后的数据元将不在门户中体现。

（五）查询

为应用系统提供标准的调用接口，支持信息资源核心元数据和数据元元数据的查询。

提供人机交互方式的目录内容的查询功能，单位用户提供信息资源核心元数据的查询检索功能。

√按标准中的各种分类方式，为用户提供目录查询；

√提供单条件查询功能；

√提供组合条件查询功能。

4.2.5服务适配器

接入服务部件：以Adapter的方式实现对被集成平台的集成接入，按照SOA和微服务的设计理念，被集成系统需要与集成平台交互的功能组件将被封装成“服务”，屏蔽被集成系统所采用的具体技术及其实现方式，以单一的接口方式与集成平台衔接。平台接入服务部件可以灵活部署，可以部署在被集成系统内，也可以部署在集成平台上实现远程接入。

Ø Adapter：可以提供多种Adpter供用户选择使用，可选择最适合医院的Adapter连接被集成系统封装的“数据服务”；

Ø XML消息队列：“服务”之间的信息交互载体为XML，通过消息机制建立XML的交换通道。

各个应用系统通过与消息交换中心实现消息交互。通过在业务系统端安装相应的软件适配器，实现与消息交换中心的信息交互。适配器由软件模块、软件配置文件、应用编程接口等组成。消息交换的模型如下图所示：

消息交换模型

在消息总线系统的整体设计架构中，各个具体的业务系统通过Adapter连接到消息消息交换平台收发业务数据。Adapter起着耦合消息交换平台与具体业务系统的作用。

在我们的解决方案中有三种适配器：标准适配器、专用适配器和商用适配器。标准适配器是由标准的Adapter Kernel和API组成。Adapter Kernel实现和消息交换中心的消息交互和对消息的实时监控，并提供将消息分发到应用系统的功能。API是为应用系统提供的一套标准的接口，具有足够的扩展性，可以灵活地嵌入到业务流程中，同时将与业务无关的通讯配置定义与业务代码隔离。

具体地，Adapter实现以下的功能：

· 实现消息的安全、可靠传递；

· 实现消息的透明传递，Adapter的实施者不必关注传递技术细节；

· 接口通用化，降低因开发架构不同导致的业务应用侧编程复杂性；

· 实现具有共同性的消息封装、变换、接收功能。例如，加解密/校验/字符集变换及HCN-XML标准协议；

· 简单的远程安装配置方法，适配器的函数调用库可以平滑升级而不影响业务应用；

可以与消息交换平台交互管理信息，实现流量控制、报文蓄积、本地日志等功能。

4.2.6鉴权中心

4.2.6.1 SSO单点登录

通过单点登录用户不再需要每次输入用户名称和用户密码，也不需要牢记多套不同供应商的系统用户名称和用户密码，从而改善用户使用应用系统的体验。根据不同的使用者可以分为：

Ø 工作人员：针对相关的工作人员，提供应用的统一入口，医务人员所有的医院应用在该门户或者其应用上使用。

Ø 管理人员：针对管理人员，提供应用的统一入口，管理人员所有的医院应用在该门户上使用。特别是提供统一的管理辅助决策和临床辅助决策应用。

Ø 信息管理员：针对信息管理员，提供统一的用户管理入口，提高效率。

4.2.6.2 身份管理

统一数字身份管理的核心，负责对各类实体信息进行数字身份的定义和标识，管理用户信息、部门信息、角色信息、信息系统、用户与角色关系信息的维护，实现数字身份流程化管理，控制数字身份的整个生命周期，具备以下功能：

Ø 保证用户具有唯一的标识，并采用统一的数据库对用户身份信息进行管理；

Ø 采用数字证书+USB KEY的双因素认证方式实现强身份鉴别，并对其进行安全存储与管理；

Ø 支持用户能够进行统一的身份鉴别；

Ø 支持用户访问权限的统一管理；

当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket（2）；用户再访问别的应用的时候（3，5）就会将这个ticket 带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4，6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

4.2.6.3 安全审计

对用户所有登录认证操作及授权访问行为的全面记录和监控，确保所有操作处于可控和可审计状态，实现以下功能：

Ø 基本的行为审计记录功能，支持访问医院信息平台各类行为的安全审计；

Ø 基于网络数据流的安全审计；支持审计自动转储和审计在线查询；

Ø 具备对医院信息平台内部数据访问行为的安全审计；

Ø 支持授权用户通过审计查阅工具进行审计数据的查询，审计数据应易于理解；

Ø 具备审计日志数据的完整性保护;

Ø 可实现各种安全设备审计数据的集中管理。

4.2.7医疗资源数据中心

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

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

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

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

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

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

2) 患者注册基本信息；

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

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

5) 健康体检数据结果集：体检登记记录、诊断记录、体格检查记录、评估报告、费用记录等；

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

7) 决策分析数据集；

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

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

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

2) 临床路径相关表；

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

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

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

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

4.2.7.1建立数据中心的意义

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

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

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

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

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

数据中心的建立，就是要将原各系统不能共享的孤岛信息，转换成符合国家或卫生部相关标准的数据集。为全院系统打造一个共享平台，统一字典维护，降低业务系统标准字典维护量，为区域共享提供可进行信息统计与挖掘的标准数据集。

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

Ø 业务系统数据接口

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

Ø 医院业务需求扩张

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

Ø 病人信息综合处理

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

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

4.2.7.2共享基础信息库

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

统提供基础信息服务的。基础信息库包括了患者的人口学信息、医疗卫生人员的

注册信息、以及各种医疗卫生、公共卫生术语字典数据及流程模板数据等。

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

业务、临床信息，还是疾病分析信息和公共卫生条线数据都是以病人基本信息为

基础的。在此基础上，实现电子病历、医疗业务（含临床数据）的关联。

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

础。可以建立医院诊疗资源注册库，可以作为医院管理以及绩效考核的基础。

数据元字典是辅助各类医院业务、临床业务的基本数据元、代码集以及数据

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

4.2.7.3原始业务信息库

业务信息库是整个医院信息平台的数据基础，主要存储原始业务产生的数

据，以未经过进一步加工的数据为主。包括诊疗业务流程产生的结果数据、医疗

服务管理数据以及医院运营管理流程产生的结果数据。这些未经修改的数据，作

为电子病历的备份存储，在以后发生任何疑问时，可调阅业务信息库中的数据进

行核实。业务信息库中的数据要求在存储后不能被修改和删除，将作为系统的原

始凭证被永久保留。从时效性和实际业务需求出发，业务信息库至少也要保存50

年之内在线业务操作及结果数据。

医疗机构内部的业务数据分布于不同的信息系统自身的数据库之中，因此需

要接入到覆盖整个医疗机构的信息平台上，以提供对原有业务数据的整合、利用

服务，并为机构之间以及业务系统之间的联动提供支持。

业务系统通过设置交换信息库作为与信息平台的接入端代理，来实现业务系

统与信息平台的互联互通性。体现在数据结构层面，就是业务信息库通过交换信

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

4.2.7.4交换信息库

交换信息库是信息平台的数据转换枢纽，包括中心交换库和对外交换库。中

心交换库的作用主要是对医疗机构内部信息系统业务数据的采集、整合以及医疗

机构内部信息系统之间业务联动。对外交换库的作用主要是实现医院信息平台与

区域信息平台的数据交互。

Ø 中心交换库

考虑到医疗机构各个信息系统相对的独立性以及数据之间的关联性，我们在

医院信息平台中设立中心信息交换数据库。中心交换库是采集医院各个业务信息

系统的信息，并整合程电子病历信息的区域，也是各个业务信息系统基础信息和

专业信息交换的信息存储区域。中心交换库存放各个信息系统交互的信息，包括

了电子病历信息、基础信息（患者基本信息、医疗人员信息等）、专业信息（医

疗业务、临床数据、检验检查报告以及影像数据等）。

Ø 对外交换库

对外信息交换库是医院信息系统与区域卫生信息平台进行数据交换的信息

存储区域。为保证系统的相对独立，我们设立对外信息交换数据库。对外交换库

存储要推送到区域卫生信息平台的电子病历，同时也存储着从区域平台推送来的

健康档案。在对外交换库中完成电子病历与健康档案的相互转换。

4.2.7.5临床文档库(CDR)

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

CDR是医院为支持临床诊疗和全部医、教、研活动而以病人为中心重新构建

的新的一层数据存储结构。它应该是物理存在的，而不仅仅是概念存在或者是逻

辑存在。它是医院基于电子病历的信息平台的核心构件。它是否存在可以作为医

院是否拥有真正电子病历系统的标志。它与直接支持医疗操作的前台业务信息库

不同，其数据来自这些业务系统，但与前台业务流程无关。它也不是通常意义上

的数据仓库，因为它的内容是随着医院业务活动动态变化的，并且直接支持医生

/护士对病人临床记录的实时应用。

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

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

病人的临床信息来自医院现已存在的多种多样的应用系统。一般说来，它们是面向应用过程设计的，是由不同供应商提供的，具有不同的信息模型和软硬件平台，其功能必须满足管理与临床应用不同的过程要求，例如一个实验室系统。

从医生开出医嘱，到条码打印和取得样本，样本传送与接受，上化验设备，化验

过程的双向控制，化验结果的自动获取，报告的产出与确认，报告的发出与接受

确实是十分复杂的。应用系统的数据结构设计必须满足这些要求，数据库内的化

验结果表达必然是复杂多变的。而电子病历仅仅关心化验报告的最终结果。因此，

如果CDR仅仅保存从检验系统传递来的化验结果，那么电子病历系统就可以和复

杂的业务处理流程相分割。如果电子病历系统中的化验结果要从检验系统中直接

获取，就不得不关注上述的所有细节。

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

CDR的独立存在使得一个统一的、透明的、一致化的电子病历信息模型的设

计与实现成为可能。这样一个模型的存在对所有应用系统的开发商、对系统集成、

对医生护士对病人信息的进一步应用都十分重要。

3、应用系统升级容易

由于CDR和复杂的业务处理流程相分割，使得以后各应用系统（POS）的升级

换代变得简单易行。而这种变化随着业务流程的变化和信息化水平的提高，是经

常发生的，也是医院信息化发展进程中最让人头痛的问题。

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

医生/护士使用物理上保存的以病人为中心的电子病历记录比起使用分散在

不同应用系统中的病人记录来更得心应手、更符合他们的思维习惯，应答速度会

更快。特别是简单、统一、透明的信息模型的存在使得他们有可能根据自己临床

工作的需要从CDR中剪裁出自己的病人临床记录子集。

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

电子病历的存在不仅仅是要满足临床信息查询的需要，更重要的是要满足临

床决策、教学、科研的深层次的要求，例如警告与提示系统、临床路径控制、循

证医学支持等等。这些应用的开发，当面对一个数据相对稳定、信息模型简单清

晰、与操作过程无关的存储库时，要简单得多。特别的，当服务点应用系统(Point

of Service，PoS)发生变化时，也不会影响这些深层次的应用。

4.2.7.6临床数据中心构建方法

广义的电子病历覆盖了患者过去、现在、未来所有的医疗健康相关的数据，这些数据的生成和利用涉及到了整个医疗过程的各个环节。即使在一个医疗机构内部，电子病历也是往往建立在各类临床信息系统充分发展的基础之上，临床信息系统构成了电子病历的信息源。显然，一个共享的电子病历逻辑信息模型对于构建临床数据中心以及最终实现共享的电子病历来说都具有十分重大的意义。

目前，我国大多数医疗机构都已经在不同程度上实现了信息化，建成了各种不同规模的临床信息系统。在这种情况下，不改变各个已有系统的底层信息模型，

采用仅在逻辑上集中的方案构建临床数据中心比较具有现实意义。按照这种方案，各种类型的电子病历数据仍由相应的临床信息系统负责管理和维护，保持原有的物理分布特性；在此之上，采用一定的技术手段将这些分散存储的数据在逻辑上集中起来，为上层的各种电子病历应用提供统一的数据访问接口，使得在这些上层系统看来，它们所面对的就是一个集中式的临床数据中心。为了实现对这些多模态电子病历数据的逻辑上的集中，通常有两种技术方案：基于面向服务架构（SOA）和基于集中索引。SOA 是一种将应用程序的不同功能单元（称为服务）通过定义一些接口和契约联系起来的软件系统架构，数据访问服务是SOA 架构中最常见、使用最广泛的服务。基于SOA构建逻辑集中的临床数据中心就是指面向各个异构临的床信息系统开发一系列的数据访问服务，上层应用通过这些服务访问电子病历数据。在这种技术方案中，所有对于服务接口的调用都会涉及到访问一个或多个临床信息系统数据库，整体效率比较低。集中索引是指在各个临床信息系统之上，根据上层应用的需求，为那些经常被访问到的电子病历数据建立一个集中的索引，基于索引实现对电子病历数据的访问。在这种技术方案中，由于大部分的数据访问操作不需要直接连接具体的临床信息系统数据库，提高了

数据访问效率。但是，为了确保医护人员能够随时获取到患者最新的电子病历数据，索引必需与原始数据保持同步更新。采用这种逻辑集中的方案时，由于原始数据仍存在于各自临床信息系统的服务器中，同样的数据可能同时在不同系统中存在多个备份，因此，如何确保数据的一致性、以及在出现数据不一致时系统的容错能力是在开发服务和建立索引过程中需要关注的问题。相对于基于共享信息模型的技术方案而言，逻辑集中的方式可以保持已经建立的各个临床信息系统不变，或仅需要为了支持数据交换开发少量的基于标准的消息通讯接口，是一个比较适合我国当前阶段医院信息化需求的构建临床数据中心的方法。

4.2.7.7ODS（操作数据存储）

CDR存储库的组织形式以患者电子病历为核心展开，其存储结构方式更多的以个人基本索引模式组织展开，以结果数据为主体，这样的组织形式在以个人视角所见的电子病历中能够完整迅速的定位，但对纵向条线业务的支持却明显缺乏有力的索引组织，不能完全满足业务的需求。所以很多业务数据并不都在CDR存储库中存储，为了完成某些特定业务上的流程要求，可能产生很多中间数据，而这些中间数据都有赖ODS数据库实现其存储方式。ODS数据库主要涵盖临床和管理数据，对数据即席查询、数据仓库、面向患者的公众信息服务以及区域卫生提供数据层支持。同时，ODS数据库支持整个医院范围内各业务系统的协同，可以与CDR结合作为院内临床及其他业务驱动的数据，为医院内平台级别的应用（非POS应用），如统一调阅等提供信息支撑。ODS数据库主要是作为CDR存储库外的业务需求的补充。除了电子病历外，医院信息平台还需要支持一些其他业务，比如说妇幼保健等具体医疗业务。这些业务所需的一些信息可以从电子病历中抽取，但是同时另一部分信息可能和健康信息毫无关系只是为业务统计分析时使用，他们也有一定的业务流程，ODS就成为此类数据的存放场所。ODS数据库还包含对这些业务数据的汇总、展现、统计查询等功能的支持，他不仅仅是一个单纯的存储服务，他可以依赖LRS实现共享和使用CDR存储库中已经存储信息的展示。ODS、数据仓库和业务信息库的区别在于：业务信息库一般针对实时性非常强的事务性操作和这些操作所对应的业务数据。其特点是数据实时性很强，但数据规模不大。数据仓库一般针对很大规模的数据量。但是其数据为历史数据，时效性不强。ODS则介于二者之间。

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

4.2.7.8数据仓库

数据仓库是在临床数据、医院管理类数据以及财务类数据采集的基础上对各

类数据进行归类整合并加以利用。按其数据的性质大致可分为三类：卫生资源信息、临床诊疗信息、卫生业务信息。其中卫生资源信息可作为卫生资源分布的基础数据；临床诊疗中与费用相关的信息可作为卫生资源消耗的基础数据；临床诊疗中的疾病数据和卫生业务信息可作为卫生资源需求的基础数据，医院的管理与决策可利用这些数据所产生的信息为相关的卫生决策进行支撑。为快速的展示各种业务统计分析的报表及结果，必须首先对不同来源的数据按照主题的方式来进行组织和处理，按照业务统计分析的需求搭建数据仓库，实现对数据的多维管理。数据仓库包括相应的事实表和维度表，基于上述业务统计分析的要求，可采用多个面向不同主题的事实表共享维度表的“星型”数据仓库模型。数据仓库的建立，有利于后期对数据的高效应用。ODS库是医院医疗信息原始业务数据库的镜像库，定时与医疗信息业务数据库进行同步，为后面的数据转换、数据仓库建立提供稳定、可靠的数据源。ODS库的设置，缓解了ETL过程中频繁访问生产数据服务器产生的大批量数据交换对医院信息平台及网络造成的压力，并最大限度降低数据数据仓库对原有业务系统的影响。数据仓库是数据整合汇总中心，以业务需求为基础创建ODS库数据的抽取整理规范及流程，抽象出满足业务分析主题的度量和维度，区分事实表与维度表，按照“星型模型”、“雪花模型”的方式建立事实表与维度表之间的关联关系，将原有的二维数据表转换成以分析主题为中心的多维表。数据仓库的建立，可以有效地管理业务数据，为数据展示、挖掘利用奠定基础。数据仓库的数据主要供管理决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。因为数据仓库只进行数据查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，它要求采用各种复杂的索引技术；同时由于数据仓库面向的是高层管理者，他们会对数据查询的界面友好性和数据展示提出更高的要求。

4.2.7.9医学知识库

医学知识库用来存放各种规划、专家的经验、有关知识和因果关系等，主要包括事实库、规则库和约束库三部分。事实库存放求解问题的说明性知识、构成信息实体的事实等；规则库中的主要内容是特定领域构规则、定理、定律等过程性知识及说明模型库中各个模型的使用范围、方法及关系的规则信息。约束库主要是说明知识的使用范围和使用条件。知识库管理系统的主要功能是在决策过程中，通过人机交互作用，使系统能够模拟决策者的思维方法和思维过程，发挥专家的经验、推测和判断，从而使问题得到一个满意而又具有一定可信度的解答,同时可以根据知识库的知识和经验生成建议以支持决策。由此可见，医学知识库是临床决策支持系统中的另一个重要元素。知识库应包含词库、术语字典、模型结构、知识仓库四个部分。

4.2.7.10疾病数据库

疾病数据库是一种将疾病按病种或术种进行分类，使数据标准化，存放在计算机数据库中，以备研究使用的数据管理与分析系统。包括：疾病名、英文名、缩写、别名、ICD疾病代码、概述、流行病学、病因、发病机制、临床表现、并发症、实验室检查、其他辅助检查、诊断、鉴别诊断、治疗、预防、预后及循证医学证据等项目。通过疾病分析统计数据库，可以将科室多年积累的病例全部存入计算机，根据需要随时调出，计算统计结果。只有利用数据库技术，通过科学分类，归纳疾病知识体系，建立系统化专科疾病统计数据库，才能获取高质、完整研究资源，进而取得广泛研究成果。

4.2.7.11药品数据库

提供药品信息，包括药名、英文名、别名、剂型、药理作用、药动学、适应证、禁忌证、注意事项、不良反应、用法用量、药物相互作用、专家点评等项目。

Ø 药品相互作用审查

提示两种药物给一个患者时可能出现的药理学效应，这些相互作用可能导致毒性增强、药效降低等，使药物的实际使用效果发生改变，或导致不良反应。

Ø 药物过敏预警

主要对药品的禁忌症、副作用、老年人用药、儿童用药、妊娠期、特殊药物剂量的审查和预警。

Ø 合理用药监控

提供药师在药品调配时对患者处方或医嘱进行合理用药自动和人工审查功能，将发现的问题进行记录并反馈给责任医师的功能。

Ø 用药研究

用药研究模块是提供给医生研究药品资料的入口，在该模块中医生可以查询和组合审查药品知识库中全部几万种药品，也可将当前下达的用药医嘱导入用药研究中与另外的药品组合测试，在用药研究平台中所有信息都不会被保存，也不会影响医生工作站正常的医嘱。

辅助检查数据库

提供各类检查项目信息，每一种检查项目涉及名称、缩写、正常值、临床意义等内容。

循证医学数据库

主要包括：临床实践指南、系统评价和临床科学研究，其中临床科学研究包括：随机对照试验、对照临床试验、非随机对照临床试验、病例对照研究、队列研究、病例报告、病例分析及横断面研究等研究证据。以统一的数据规范存储成全文数据库。循证医学数据库的建立，有利于提高医疗质量和临床科研水平。实施循证医学将会不断淘汰现行无效的医学干预措施，防止新无效的措施进入

医学实践，从而不断提高医疗卫生服务质量和效率，充分利用有限医学资源。通过对医学信息的挖掘、整理，进行知识的重新组织，实现从信息服务向知识服务转变。

医学资料参照库

提供具有代表性权威临床研究论文、医学期刊和临床医学学会的全文文献。提供各科权威临床医学教科书全文。针对特定主题做导览式查询，并提供相关图书、期刊文献、药物信息、临床指引、卫教信息等参考列表。

临床辅助诊断

主要提供辅助诊断治疗，根据病人的症状，通过分析决策引擎，推断出患者的疾病，并提供合适的治疗方案，供医生参考。在医生确诊并开出处方或处置以后，对疾病、处方以及处置进行分析，与知识库中的规则进行比对，确认处方、处置的安全可靠性，如果有异常，则发出警报，对医生提醒，从而提升医疗服务质量，减少或避免医疗事故的发生。

4.2.8跨医疗单位信息交换

伴随着医院集团的出现，医院信息系统的集团化成为新时期的医院信息系统建设的重要方向，为了使庞大而又分散的经营体系内部的各类机构能步调一致，有效地运转，集团总部及各成员医院都需建立相应的信息系统，并用远程通讯网络将整个集团构成一个有机的整体，大型的医院集团如果没有一个健壮的电脑化集团信息系统，就难以实施有效的管理，也就难以获得经营的效益。

集团化医院较之单体医院的最大特征在于资源在一定程度上实现了共享，但目前大部分的集团化仍未达到充分的资源共享，比如：集团下属各家医院一般都有独立使用自己的LIS 系统， LIS 数据仅存在本医院内部，当病人跨院就诊时，往往需要重新检验，造成大量的人力、财力的浪费。因此，集团化医院信息系统的一个基本任务在于解决各成员医院间的远程数据交换，主要包括病人档案信息共享、病人诊疗信息共享、跨院检验检查、药品、易耗品等物资一体化功能。

通过在总院建立中心数据共享平台，中心数据共享平台根据需要通过各医院的子系统收集并存储患者信息，所有授权和整合的医院都可以访问。这样资源和患者能够有效地在各个医院之间流动，各家医院之间的报告信息、设备、人才可以共享，报告结果互认，当病人跨院就诊时就不再需要重新检验，避免了人力、财力的浪费，方便了患者，提高了服务质量，一定程度上缓解了“看病难、看病贵” 的问题。

4.2.9医院决策分析平台

医院管理辅助决策的内容极其广泛，贯穿医院经营活动的始终，是整个医院管理的核心。经营决策的正确与否，关系到医院能否健康发展，甚至关系到医院的生死存亡。如何将来自医院的多个数据源的数据整合到一起，并将数据转化为关键洞察力来支持战略决策制定、推动持续的业务流程改进和促进整个医院协调一致，是医院发展方向上的战略性问题。

医院管理辅助决策的数据来源于不同的信息管理系统，有临床诊疗、医疗管理及后台运营管理等，数据以不同的格式保存。从总体看，数据是无组织的，需要对数据进行数据清理，继而对预处理过的数据进行转换，再按某分析主题进行组织和展示。可以获取任意时间的任意即时数据，即实时分析处理数据，使用者可以随时了解到医院当时的各种情况，同时系统能从不同角度对数据进行分析，并快速高效的获得结果，有助于全面了解隐藏于数据中的有用信息，方便领导决策。

医院管理决策分析是一种典型的基于集成平台的应用，基于集成平台积累的大量数据为医院管理提供辅助决策。基于BI智能化数据系统，通过集成平台数据仓库对接实现指标数据的实时、自动抓取，并对数据进行预处理后，运用BI工具的数据钻取和报表的灵活展现功能，为医院管理者决策分析提供及时、准确的量化数据和深入分析，帮助管理者找到影响医院发展的深层原因，为医院管理的提升，乃至整个医院战略目标的实现提供分析。

基于BI智能化数据系统，通过集成平台数据仓库对接实现指标数据的实时、自动抓取，并对数据进行预处理后，运用BI工具的数据钻取和报表的灵活展现功能，为医院管理者决策分析提供及时、准确的量化数据和深入分析，帮助管理者找到影响医院发展的深层原因，为医院管理的提升，乃至整个医院战略目标的实现提供分析。

1) 统一设计原则

按照医院信息化规划统一设计系统架构。特别是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，从规划的全局出发、从长远的角度考虑。

2) 先进性原则

系统构成采用成熟、具有国内先进水平、并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时还将保证技术的稳定、安全性。

3) 高可靠/高安全性原则

系统设计和数据架构设计中将充分考虑系统的安全可靠。

4) 标准化原则

建立共同系统统一标准的数据系统，分析业务开展、横向的信息扩展和宏观管理的要求。系统对操作的标准化，即系统有检入检出的机制，确保数据维护的一致性和版本控制的可操作性。

5) 成熟性原则

在开发工具的选型阶段，将尽量选择成熟的产品和规范，如.NET、XML等已经成为标准的、被大量实践所采用的技术。选用具有成熟性，可持续发展性的开发工具。系统采用国际主流、成熟的体系架构来构建，实现跨平台的应用。

4.2.9.1决策支撑平台技术架构

整个技术架构分为三层结构，分别为：

1) 数据层：即“医院决策分析系统”所需要的原始数据来源，其中包括了HIS业务系统、临床信息系统、物质设备系统、财务系统、成本核算系统、其他相关业务系统，也包含了如手工填报数据和基础配置数据等；

2) 应用层：这是整个“医院决策分析系统”的核心应用部分，从功能结构上，包含了指标库管理、指标数据采集（自主研发）、KPI分析和主题分析三大模块。对于“医院决策分析系统”而言，应用层是整个系统建设的核心，后续的数据架构、指标加工逻辑架构、集成应用架构、网络及服务器部署架构、安全架构，主要是针对“应用层”进行细化描述和说明。

3) 展现层：这是整个“医院决策分析系统”的业务访问入口。主要的方式是通过IPAD和网站web两种方式登录医院决策分析系统。整个展现层，为用户提供的是完全的B/S模式，无需任何客户端、插件或控件下载。

4.2.9.2决策支撑平台数据架构

“医院决策分析系统”的数据分层结构如下图所示，除去数据源之外，主要的数据层次结构包括：接口数据层、操作级数据表、数据集市层、立方体数据层和指标库。

接口数据层：主要用于从“采集接口”直接获得所需的原始数据和指标数据，其主要的功能包括数据采集、数据质量控制（数据清洗）、校准时间戳、数据结构重整等等，其定位相当于“数据集结区”（Data Staging Area），存储在数据总线平台，一般需要数据采集平台处理软件和处理服务器进行支撑，其数据存储形式使用关系数据库。

操作级数据表：来自不同外部数据源的交易级数据经过“接口数据层”的集结处理之后，按照某种规范化的模式存储在关系数据库中，定期与外部数据源保持更新，这是整个“医院决策分析系统”最稳定和最主要的数据来源。

数据集市层：从操作级数据表取数，并对这些数据按照维度模型的方法进行建模，是专为BI工具提供的数据源。“数据集市层”一般使用关系数据库作为主要的存储模式。

立方体数据层：根据所选用的BI工具的不同，“立方体数据层”的形式既可以是数据文件，也可以是逻辑结构存在的虚拟立方体，还可以是内存级立方体数据。整体而言，立方体数据层面对的是综合报表、多维分析报表等应用层（而非指标库）。因此，在系统架构上，“立方体数据层”的定位是提高前端报表和分析的速度和便捷性，有时也称为“报表数据层”；值得注意的是，“立方体数据层”的加工逻辑通常不是由ETL过程，而是由BI工具的映射逻辑模型来控制的。详见下一节“指标加工逻辑架构”的描述。

指标库：与前面的数据层主要使用开放格式的文件或关系数据库存储不同，指标库存储的内容是指标的加工逻辑、定义、权限等内容，是整个“医院决策分析系统”的逻辑核心，类似于BI系统中的“业务元数据”。指标库可以以开放的XML文件存储，也可以使用关系数据库存储（但其存储访问结构往往是不开放的）。

在上图中，“决策分析”业务应用，都是通过专门的BI工具直接访问集成平台“指标库”来实现的，而不是直接访问各数据层。

4.2.9.3指标加工逻辑架构

下图描述的是物理的数据存储与业务上的指标库之间的映射关系。事实上，整个“指标库”建立和管理的核心问题就是，业务人员所使用的指标与物理的数据之间通过怎样的有效方式建立映射和连接关系。

如下图所示，图中的作伴部分代表了物理数据的加工和存储过程，右边描述的是我们为“医院决策分析系统”设计的“面向对象的分层指标库”结构。

整个的指标库是由五种类型的分层对象构成的，其中：

框架对象层：以逻辑映射的方式将数据库中的物理数据（库、表、字段、记录等等）转变成为逻辑对象，我们称之为“框架对象”（Schema Objects）。框架层对象构成了后续的“分析指标”定义的最基本元素。一般而言，“框架对象层”的定义相当的稳定，只与基础的物理数据库结构有关，尤其是“操作级数据表”和“数据集市层”。通过稳定的“框架对象层”的“隔离”，最终业务人员自定义或修改指标定义时无需考虑后台的数据库结构。

业务对象层：也就是“基础指标库”，以“框架对象”为基础，按照业务要求和口径的需要，对“框架对象”进行计算和定义。需求中的多数指标都可以以这种方式加工和定义。

衍生对象层：也就是“衍生/复合指标库”，很多业务指标是由多个基础指标复合而成，或者同样的一个基础指标，经由不同的加工方式会有完全不同的业务含义，这类指标，我们称之为“衍生/复合指标”。

注意：业务对象层、衍生对象层和主题对象层的定义过程，都与物理数据库无关，完全是是以“框架对象层”为基础定义出来的。

主题对象层：应对的主要需求是“多指标综合报表”、“主题分析仪表盘”和“多维度分析”。“主题对象层”是以“业务对象层”和“衍生对象层”为基础来构造出来的，但与它们不同的是，“主题对象层”会将完整的的加工逻辑传回到数据库或其他物理存储，然后构造出单独的物理存储，以提高报表和分析的速度和便捷性。

公共/配置对象层：以面向对象的方式定义了“指标库”的层次结构、访问权限、分组关系等等，是“指标库管理”的核心。

4.2.9.4系统工作内容及技术路线

“医院决策分析系统”需求主要包括五部分工作内容：数据库设计、指标库的构建、指标数据的采集、指标分析及展现。

1.1.1.1. 指标库构建与管理的工作内容要求

指标库是基于医院决策分析指标体系，搭建的便于不同科室不同角度调用的诸多指标模型的集合。指标模型的构建是为了使指标从概念实现“落地”，与真实的数据环境打交道。

指标模型的设计至少应包括以下内容：1）指标识别；2）适用对象；3）分析维度；4）指标评价方式；5）计算公式；6）计量单位；7）数据来源；8）数据取数方式；9）数据管理单位；10）数据审核单位；11）指标分析标准；12）指标取值范围。

指标库需要实现以下业务及管理功能：1）调用分析指标；2）配置分析指标；3）新建/删除指标。

典型主题：

门诊人次分析

门诊费用构成分析

住院费用构成分析

患者构成分析

门诊诊断排名

4.2.9.5指标库构建与管理的设计原则

指标库的要素、指标库的组合原则、指标的合成原则和权重设计、指标基准的确立、指标的深入分析能力。

可计算原则、对比原则、合成原则、分解原则。

指标库的确定方式：访谈、基准域的调研；

基础指标模型、指数模型、主题模型

4.2.9.6指标库构建与管理的技术路线

通过“面向对象的分层映射”技术，将技术层面的基础数据映射成为业务层面的指标库。而对于指标库的管理机制，实质就是“分层映射对象”（或是分层映射关系）本身的管理，其中既包括了对于“分层映射关系”的编辑、增加、删除、复制、分组等基本操作，也包含了更复杂的版本管理、一致性管理。同时，所有的“分层映射对象”和“分层映射关系”都可以以开放格式的XML文档在不同应用之间传递和调用。

4.2.10安全保障体系

4.2.10.1隐私保护措施

隐私保护及信息安全是医院信息平台所要重点解决的问题，应从患者同意，匿名化服务，依据病种、角色等多维度授权，关键信息（字段级、记录级、文件级）加密存储等方面展开。电子病历等医疗数据进行调阅时，包括强身份认证需求、角色授权需求、责任认定需求、电子签名及时间戳等方面的需求。同时，应用系统应通过交互数据加密、集中授权、应用审计等功能来确保患者的隐私安全。各医院根据要求不同，采用相应的适宜技术保护隐私，按照《电子病历基本规范（试行）》以及相关法规，可以采取的技术手段包括如下几方面，：

Ø 身份保护和鉴别服务

医院信息系统应当为患者建立个人信息数据库（包括姓名、性别、出生日期、民族、婚姻状况、职业、工作单位、住址、有效身份证件号码、社会保障号码或医疗保险号码、联系电话等），授予唯一标示号码并确保与患者的医疗相应记录。医院信息系统应当为操作人员提供专有的身份标识和识别手段，并设置相应权限；操作人员对本人身份标识的使用负责。

Ø 身份管理服务

为更高层次服务提供基础服务，例如用户注册、认证、授权，其中包括用户的唯一标识、查找用户的标识、挂起/取消用户访问权。

Ø 访问控制服务

对操作人员的权限实行分级管理，保护患者的隐私。医院信息系统应当设置医务人员审查、修改的权限和时限、实习医务人员、试用期医务人员记录的病历等医疗数据，应当经过在本医疗机构合法执业的医务人员审阅、修改并予电子签名确认。医务人员修改时，医院信息系统应当进行身份识别、保存历次修改痕迹、标记准确的修改时间和修改人员信息。

Ø 加密服务

加密服务包括密钥管理、数据库加密以及数据存储加密三方面内容。其中，密钥管理是指创建和管理数据存储的加密密钥；数据库加密指加解密数据库表中的数据字段（列）和记录（行）以保护电子病历以及医院信息平台中处于试用状态的其它保密的关键系统数据；数据存储加密指加解密文件和其它数据块，用于保护在联机存储、备份或长期归档中的数据，从而实现关键信息（字段级、记录级、文件级）加密存储。

Ø 数字签名服务

医务人员采用身份标识登录电子病历等业务系统完成各项记录等操作并予确认后，系统应当进行电子签名。数字签名由用户创建，以确保临床数据的不可否认性，包括数据文件、诊疗报告、记录中的字段域、安全声明、XML文档以及被转换为XML文档的HL7消息或对象中的元素。

Ø 匿名化服务

包括患者的隐私和安全，确保在信息平台中以及提供正常医疗服务以外的（例如医疗保险等）传递中使用的资料不向非授权用户透露患者的身份。

Ø 应用审计服务

该服务提供对每个事务所涉及到的系统、用户、医护工作者、患者/居民、医疗数据等等的报告功能。这些服务对于满足其他业务需求，如系统管理、事务监控、记录重要的与隐私和安全有关的事件等，也是至关重要的。

Ø 许可指令管理服务

许可指令管理服务转换由立法、政策和个人特定许可指令带来的隐私要求，并将这些需求应用到医院信息平台环境中。在提供访问或传输患者电子病历等医疗数据之前，该服务应用于电子病历以确定患者或个人的许可指令是否允许或限制这些医疗数据的公开。

4.2.10.2网络安全保障

随着医院信息化进程的深入，共享与交换已经成为医院信息化建设的主题。这意味着，医院信息平台的运行将越来越依赖基础网络的建设。网络上承载的流量从最初的单一流量，逐渐过渡到非常复杂的流量，各种涉及公民隐私、医院关键数据的信息在网络上进行交互和传递，一旦发生故障，将对医院造成巨大的经济、信誉以及名誉损失，甚至可能会导致医疗事故及医患纠纷的产生。医院的信息化对网络的可靠性也提出了新的要求，在医院平台的建设过程中，需考虑网络架构的冗余性设计。近年来，新的医院业务系统不断上线，医学影像系统不断普及，医院网络流量呈加速递增趋势，这对网络的性能也提出了更高的要求。个人电脑的普及，以及医院网络上涉及个人及医院秘密的信息越来越多，网络信息安全问题也成为了在建设医院信息平台过程中非常重要的一环，需要特别关注。随着新应用（如无线查房、无线巡诊、无线监护等）的发展以及以802.11n 为代表的新一代无线网络标准的产生，使得无线网络的建设成为医院信息化建设的一个重要的方面，在构建医院信息平台的时候应充分考虑到网络的无线扩展性。

网络、安全设备是信息流通的必然结点，每个网络设备都会产生相应的日志信息，通过对日志信息的全面、深入分析，可以了解设备的工作状况，网络状况以及安全事件等信息。要对各类系统产生的安全日志实现全面、有效的综合分析，就必须为网络安全管理员建立一个能够集中收集、管理、分析各种安全日志的安全审计管理中心，把管理员从庞杂的日志信息分析中解放出来，提供一个方便、直观、高效的审计平台，大大提高了安全管理员的工作效率和质量，更加有效地保障了网络的安全运行，通过部署安全审计系统实现的如下策略来保证网络的安全性。网络安全审计系统主要用于监视并记录网络中的各类操作，侦察系统中存在的现有和潜在的威胁，实时地综合分析出网络中发生的安全事件，包括各种外部事件和内部事件。在网络交换机处旁路部署网络行为监控与审计系统，形成对全网网络数据的流量监测并进行相应安全审计，同时和其它网络安全设备共同为集中安全管理提供监控数据用于分析及检测。

网络行为监控和审计系统将独立的网络传感器硬件组件连接到网络中的数据会聚点设备上，对网络中的数据包进行分析、匹配、统计，通过特定的协议算法，从而实现入侵检测、信息还原等网络审计功能。网络行为监控和审计系统采用旁路技术，不用在目标主机中安装任何组件。同时网络审计系统可以与其它网络安全设备进行联动，将各自的监控记录送往安全管理安全域中的安全管理服务器，集中对网络异常、攻击和病毒进行分析和检测。

4.2.10.3数据保密性

医院集成平台承载着患者电子病历等隐私数据以及诸多业务操作的中间数据，其保密性要求极高。在保密性方面，主要需要考虑数据丢失和数据泄漏两方面的威胁，数据丢失主要依靠数据备份等机制完成，在本文其它章节有详细描述。

数据泄漏造成的根源来自外部黑客攻击和内部数据泄漏，而就医院信息平台的实际情况而言，内部威胁占据主要比例。不论是内部蓄意泄漏，还是外部黑客攻击，大部分通过以下几个渠道完成：

物理途径——从桌面计算机、便捷计算机和服务器拷贝数据到移动存储介质；通过打印机打印带出医院或者通过传真机发送。

网络途径——通过局域网、无线网络、FTP、HTTP、HTTPS发送数据，这种方式可以是黑客攻击“穿透”计算机后造成，也可能是内部员工故意从计算机上发送。

应用途径——通过电子邮件、IM即时信息、屏幕拷贝，P2P（Peer-to-Peer，点对点）应用或者“特洛伊木马”窃取信息。

综上所述，医院信息平台的数据保密性主要从以下几方面解决：

Ø 防信息泄漏

防信息泄漏技术通过对安全计算环境内部敏感信息输出的各种方式进行控制，目的是防止内部敏感信息被有意或无意外漏。通过在客户端使用防信息泄漏类技术实现数据保护，并完成统一管理；通过数据保护客户端对用户的网络行为进行检测，阻断数据泄漏行为；通过数据保护客户端对具体应用进行检测，阻断数据泄漏行为；通过客户端程序，有效的审计各类数据调用行为，并记录全部用户行为；

Ø 设备控制

对接入计算机的各类外置设备进行控制，防止机密信息通过这类外接设备发生泄漏；针对网络打印机、U盘等各类高危外设的使用进行审计并记录；一旦发现非法使用，可以第一时间阻断数据泄漏行为；

Ø 磁盘和数据加密

包括文件加密、整盘加密以及移动介质加密等。文件加密类技术用于防御攻击者窃取存储于文件中的数据，目的是保障文件中存储数据的安全。整盘加密类技术通过对整盘数据进行整体加密来实现数据保密，目的是在数据整盘存储层面保障数据安全。移动介质加密类技术通过对U盘等移动介质进行加密处理，防止意外丢失造成的数据泄漏。通过以上技术手段，能够对特定的文件进行加密和控制，并通过管理平台设定统一的管理策略，就算数据由于无意的合法行为造成泄漏，非授权用户也无法进行访问。

4.2.10.4数据完整性

医疗数据被视为敏感信息，检验检查等医疗数据作为诊断结果的重要依据，其内容一旦发生改变，将造成严重的医疗事故，对医院和患者带来重大的损失。《电子病历基本规范》（试行）要求：“具备对电子病历创建、编辑、归档等操作的追溯能力”，因此医院信息平台中涉及到医疗数据的传输、存储，可以采用电子签名及时间戳等相关技术来保证医疗数据的完整性以及可追溯性。

目前公认的可靠的电子签名是通过基于PKI和消息摘要技术的数字签名技术实现的，通过数字签名和验证服务能够保障数据本身的完整性，实现相关业务操作的抗抵赖。

4.2.10.5恶意代码防范

各类恶意代码尤其是病毒、木马等是对网络的重大危害，病毒在爆发时将使路由器、三层交换机、防火墙等网关设备性能急速下降，并且占用整个网络带宽。

针对病毒的风险，建议将病毒消灭或封堵在终端源头。在所有终端主机和服务器上部署网络防病毒系统，加强终端主机的病毒防护能力并及时升级恶意代码软件版本以及恶意代码库。

在安全管理中心，可以部署防病毒服务器，负责制定和终端主机防病毒策略，在网络内网建立全网统一的一级升级服务器，在下级节点建立二级升级服务器，由管理中心升级服务器通过互联网或手工方式获得最新的病毒特征库，分发到数据中心节点的各个终端，并下发到各二级服务器。在网络边界通过防火墙进行基于通信端口、带宽、连接数量的过滤控制，可以在一定程度上避免蠕虫病毒爆发时的大流量冲击。同时，防毒系统可以为安全管理平台提供关于病毒威胁和事件的监控、审计日志，为全网的病毒防护管理提供必要的信息。

主要执行以下安全策略：

Ø 在应用服务器上安装服务器版的防病毒软件，可以捍卫服务器免受病毒、特洛伊木马和其它恶意程序的侵袭，不让其有机会透过文件及数据的分享进而散步到整个用户的网络环境，提供完整的病毒扫描防护功能；

Ø 文件系统对象的实时保护策略：服务器防病毒系统通过对文件系统所有需要的模块进行分析，以及阻止恶意代码的执行，为文件服务器的文件系统提供实时的防病毒保护。具体包括：

Ø 监听对文件系统的访问；

Ø 使用反病毒引擎对可疑对象和染毒对象进行探测；

Ø 当检测到可疑对象和染毒对象时执行预设：阻止染毒对象或可疑对象；在清除病毒之前将其保存在备份区域；启动反病毒引擎以清除或删除染毒对象；将可疑对象放置在隔离区或将其删除；

Ø 在程序运行过程中，向用户和本地管理员通报所发生的与其有关的事件；

Ø 收集被检查过的对象的数据；

Ø 隔离可疑对象策略：服务器防病毒系统隔离与备份组件隔离任何可疑对象，为了使防病毒厂商对其进行进一步的分析，该组件对恶意代码进行安全隔离。这个组件也可以使恶意代码的安全检测和清除方法得到发展。

Ø 隔离和备份组件执行以下策略：

Ø 保存或按要求保存检测到的可疑对象；

Ø 按要求发送可疑对象到防病毒厂商进行分析，同时允许其发展检测及清除病毒的安全方法；

Ø 在接受防病毒厂商针对病毒的更新后，重新检测存储在隔离区的对象，用于确定对象的状态及清除病毒的必要性；

Ø 按要求恢复隔离区的对象。

Ø 通过集中隔离工具，可将感染病毒档案集中隔离到一台服务器；

Ø 通过病毒追踪工具，当有病毒通过网络共享扩散时，可侦测到感染病毒的机器；

Ø 实现强大、完善的日志管理策略。

4.2.10.6性能保障措施

集成平台的性能要求如下：

最大在线用户数：5000人；

业务用户数：1000人；

最大并发用户数：100人；

响应时间：一般业务小于3秒，复杂业务小于5秒；

性能：7×24运行，应用系统故障率<=0.1%

为满足此要求，建议服务器及网络部署规格：

其中，主要的服务器（数据库服务器、BI服务器、Web应用服务器）均采用双机组成群集，可保障“7×24运行，应用系统故障率<=0.1%”的性能要求；

实践证明，影响用户访问性能的主要参数是“最大并发用户数”，为保障“一般业务小于3秒，复杂业务小于5秒”的访问性能要求，BI服务器和Web服务器的配置规格建议为“2～4CPU，4GB内存”，这样的配置可以保障50～100并发用户的高速访问。

为了经一步提高性能的保障，我方开发的系统将提供缓存、调度等功能，最大程度的减少对于数据库的访问瓶颈，经验证明，通过这样的手段，一般可以提高100%～200%的性能规格。

4.2.10.7运行环境保障措施

网络：全部的服务器均部署在医院的数据中心，服务器间的数据传输均由局域网承载；分行用户对于系统的访问均使用浏览器通过纯Web界面访问，并且访问的均为结果数据而非中间数据，数据传输量极小（一般报表的传输量小于50KB），4M的干线足以分析30用户并发访问。

物理服务器：我们推荐使用IBM或HP服务器，重要的服务器均采用双机备份。

应用服务器：我方开发的应用均IIS等在内的主流应用服务器平台之上。

集成平台：我方系统均采用SOA标准提供对外接口，可以很好的与其它系统集成。

应用平台架构：可以直接使用医院HIS现有的用户管理和认证系统，并提供了与门户的SSO解决方案。

4.2.10.8信息安全与审计保障措施

用户认证：我方开发的系统可以与AD和LDAP认证服务器集成。

信息安全审计：我方推荐使用的商业数据库服务器、BI工具，均提供了完善的信息安全审计信息。

用户及权限管理：医院决策分析系统采用基于角色的用户授权，数据访问权限分为“权限”、“访问控制列表”和“安全筛选”三级，可以实现对于数据的单元格及控制；同时，通过授权管理，既可以实现分级授权，也可以控制用户的访问模式和访问地点。

灾备：对于核心服务器，我方推荐使用双机热备，即可实现负载均衡，同时具备“失败恢复”功能；同时对于核心数据库服务器中的数据，增加离线备份功能。

无关性：本系统均采用复合业界标准的网络传输标准，用户端的访问均使用通用的Web开发技术，与客户的操作系统和浏览器类型及版本无关。

数据备份：医院决策分析系统的所有核心数据均单一存储于关系数据库，缓存文件和立方体文件等均可由关系数据库中的数据即时生成。在实践中，此部分内容完全采用数据库的备份技术和流程。

2. 核心价值

通过建立集成信息平台，集成各类应用系统以及日常运营的业务，通过该平台整合医院内部业务应用系统，形成一个互联互通的医院业务协作网络。

医院信息集成平台可以很好支持不同系统之间的医疗数据整合、业务整合与数据共享，快速实施应用程序节点部署以及各医疗子系统之间的协同通讯。在医院信息系统中的各子系统中，比如HIS,LIS,RIS,OA等，传递和展现整个医疗过程中的相关信息。同时，集成信息平台为临床数据中心的数据来源提供了技术基础和保障，通过信息标准、交换原则的制定，对业务系统提供标准的信息交换服务，确保数据交换过程的安全性、可靠性，实现数据在系统平台范围内自由、可靠、可信的交换。

通过医院信息平台建设，一方面可以规避“点对点”式的信息共享与交换，

并使得医院可以基于信息平台整体上进行业务流程优化与管理，对内提高管理水平，对外以统一的方式接入区域卫生协同网络，更好地为人民健康服务。另一方面利于医院信息系统建设的持续性发展，以适应未来的需求变化，避免信息化建设的大范围的推倒重来；另外，持续性发展还必须要有一套合适的实施和服务模式作支撑。