医院信息系统集成平台建设方案
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：规范化、标准化程度低
我国医院信息化建设的过程中，采用的标准、规范很少，信息的共享与交换主要以“点对点”的方式进行，这种方式个性化极强,往往会因为系统升级、更换厂商而带来严重后果.
word/media/image1.png
传统点对点模式
基于传统“点对点”直连数据接口方式来集成系统，如果另一个应用程序系统 A（第 n+1 个）必须集成进来,将需要产生、文档化、测试和维护 2n 个新的接口。而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将增加大量的成本和复杂度.：
点对点集成方式存在以下问题：
✓接口不规范
接口间的调用方式各不相同，如有存储过程、视图、中间表、应用程序、动态库等等，无法形成统一的接口规范。
✓数据不共享
虽然现在大多数系统间均有做接口进行数据交互，但往往只做到最基础的数据采集上，信息间的共享并不充分,如急诊、危重病人的报告、异常的报告无法做到第一时间提醒医生.医生也无法主动查询病人的报告进行到哪一步.
✓数据不一致
由于数据共享不充分，导致多数接口在重复做，往往会出现数据在不同系统间不一致的情况，如同样的检验报告，在LIS系统下看到的格式有可能与HIS看到的不一样,甚至连数据都有可能不同，这就给医生带来不小的困扰。
✓数据入口多
由于点对点的接口方式，数据重复存在于各个系统中，无法形成统一的数据中心模式，造成同一数据多个采集入口。
✓接口安全性差
很显然在不同供应商之间开放数据库用户进行连接视图或读写中间表,这种接口方式的安全性较低，一旦出现数据异常责任往往无法追踪。
✓接口耦合度高
点对点集成方式导致接口耦合度高，不利于后期的扩展及维护。
各系统界面、用户分散，无统一管理机制
word/media/image2.png
✓用户必须来回切换登录不同系统
✓用户必须记住不同系统的不同用户及密码
✓系统维护成本高
4.2医院集成平台总体框架word/media/image3.png
医院集成平台总体架构图
如上图所示，本平台中医院信息平台信息交换层，主要用于实现全院级应用系统互联互通的需求，主要任务以满足临床信息、医疗服务信息和医院管理信息的共享和协同应用为目，标采集相关业务数据，并对外部系统提供数据交换服务;提供支持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)发生变化时，也不会影响这些深层次的应用.
word/media/image4.png
4.3。6临床数据中心构建方法word/media/image5.png
广义的电子病历覆盖了患者过去、现在、未来所有的医疗健康相关的数据，这些数据的生成和利用涉及到了整个医疗过程的各个环节。即使在一个医疗机构内部，电子病历也是往往建立在各类临床信息系统充分发展的基础之上，临床信息系统构成了电子病历的信息源。显然，一个共享的电子病历逻辑信息模型对于构建临床数据中心以及最终实现共享的电子病历来说都具有十分重大的意义。
目前，我国大多数医疗机构都已经在不同程度上实现了信息化，建成了各种不同规模的临床信息系统。在这种情况下,不改变各个已有系统的底层信息模型,
采用仅在逻辑上集中的方案构建临床数据中心比较具有现实意义。按照这种方案,各种类型的电子病历数据仍由相应的临床信息系统负责管理和维护,保持原有的物理分布特性;在此之上,采用一定的技术手段将这些分散存储的数据在逻辑上集中起来，为上层的各种电子病历应用提供统一的数据访问接口，使得在这些上层系统看来，它们所面对的就是一个集中式的临床数据中心.为了实现对这些多模态电子病历数据的逻辑上的集中，通常有两种技术方案：基于面向服务架构（SOA）和基于集中索引.SOA 是一种将应用程序的不同功能单元（称为服务）通过定义一些接口和契约联系起来的软件系统架构,数据访问服务是SOA 架构中最常见、使用最广泛的服务。基于SOA构建逻辑集中的临床数据中心就是指面向各个异构临的床信息系统开发一系列的数据访问服务，上层应用通过这些服务访问电子病历数据.在这种技术方案中，所有对于服务接口的调用都会涉及到访问一个或多个临床信息系统数据库，整体效率比较低。集中索引是指在各个临床信息系统之上,根据上层应用的需求，为那些经常被访问到的电子病历数据建立一个集中的索引，基于索引实现对电子病历数据的访问。在这种技术方案中，由于大部分的数据访问操作不需要直接连接具体的临床信息系统数据库，提高了
数据访问效率。但是，为了确保医护人员能够随时获取到患者最新的电子病历数据，索引必需与原始数据保持同步更新。采用这种逻辑集中的方案时，由于原始数据仍存在于各自临床信息系统的服务器中,同样的数据可能同时在不同系统中存在多个备份，因此,如何确保数据的一致性、以及在出现数据不一致时系统的容错能力是在开发服务和建立索引过程中需要关注的问题。相对于基于共享信息模型的技术方案而言,逻辑集中的方式可以保持已经建立的各个临床信息系统不变，或仅需要为了支持数据交换开发少量的基于标准的消息通讯接口，是一个比较适合我国当前阶段医院信息化需求的构建临床数据中心的方法。
ODS(操作数据存储）CDR存储库的组织形式以患者电子病历为核心展开，其存储结构方式更多的
以个人基本索引模式组织展开，以结果数据为主体，这样的组织形式在以个人视
角所见的电子病历中能够完整迅速的定位,但对纵向条线业务的支持却明显缺乏
有力的索引组织，不能完全满足业务的需求。所以很多业务数据并不都在CDR存
储库中存储,为了完成某些特定业务上的流程要求，可能产生很多中间数据，而
这些中间数据都有赖ODS数据库实现其存储方式。
ODS数据库主要涵盖临床和管理数据，对数据即席查询、数据仓库、面向患
者的公众信息服务以及区域卫生提供数据层支持。同时，ODS数据库支持整个医
院范围内各业务系统的协同，可以与CDR结合作为院内临床及其他业务驱动的数
据，为医院内平台级别的应用（非POS应用），如统一调阅等提供信息支撑。
ODS数据库主要是作为CDR存储库外的业务需求的补充。除了电子病历外,医
院信息平台还需要支持一些其他业务，比如说妇幼保健等具体医疗业务。这些业
务所需的一些信息可以从电子病历中抽取，但是同时另一部分信息可能和健康信
息毫无关系只是为业务统计分析时使用，他们也有一定的业务流程，ODS就成为
此类数据的存放场所。
ODS数据库还包含对这些业务数据的汇总、展现、统计查询等功能的支持，
他不仅仅是一个单纯的存储服务，他可以依赖LRS实现共享和使用CDR存储库中已
经存储信息的展示。
ODS、数据仓库和业务信息库的区别在于：业务信息库一般针对实时性非常
强的事务性操作和这些操作所对应的业务数据。其特点是数据实时性很强，但数
据规模不大.数据仓库一般针对很大规模的数据量。但是其数据为历史数据，时
效性不强。ODS则介于二者之间.
ODS数据来源于在线业务系统的实时映像。映像数据保存周期为数据集市或数据仓库的装载周期.利用ODS系统，我们即可以允许历史数据在保存周期中进行更新，又可以随时对现有监测数据进行分析，满足应急性分析需求.数据从业务库抽取出来装载到ODS后，从ODS系统中进行数据清洗和转换从而完成在建立数据仓库/数据集市之前的数据准备工作。为了不影响业务数据库的性能，一般ODS的数据库结构和业务数据库是完全一致的，这样数据可以高效的从业务数据库中抽取出来.ODS和数据仓库的数据库结构则往往区别较大。ODS的数据需要进行数据转换方可进入数据仓库。
数据仓库数据仓库是在临床数据、医院管理类数据以及财务类数据采集的基础上对各
类数据进行归类整合并加以利用。按其数据的性质大致可分为三类：卫生资源信
息、临床诊疗信息、卫生业务信息.其中卫生资源信息可作为卫生资源分布的基
础数据;临床诊疗中与费用相关的信息可作为卫生资源消耗的基础数据；临床诊
疗中的疾病数据和卫生业务信息可作为卫生资源需求的基础数据，医院的管理与
决策可利用这些数据所产生的信息为相关的卫生决策进行支撑。
为快速的展示各种业务统计分析的报表及结果,必须首先对不同来源的数据
按照主题的方式来进行组织和处理,按照业务统计分析的需求搭建数据仓库,实
现对数据的多维管理.数据仓库包括相应的事实表和维度表，基于上述业务统计
分析的要求，可采用多个面向不同主题的事实表共享维度表的“星型”数据仓库
模型。数据仓库的建立，有利于后期对数据的高效应用。
ODS库是医院医疗信息原始业务数据库的镜像库,定时与医疗信息业务数据
库进行同步，为后面的数据转换、数据仓库建立提供稳定、可靠的数据源.ODS
库的设置，缓解了ETL过程中频繁访问生产数据服务器产生的大批量数据交换对
医院信息平台及网络造成的压力，并最大限度降低数据数据仓库对原有业务系统
的影响。
数据仓库是数据整合汇总中心，以业务需求为基础创建ODS库数据的抽取整
理规范及流程，抽象出满足业务分析主题的度量和维度，区分事实表与维度表，
按照“星型模型”、“雪花模型”的方式建立事实表与维度表之间的关联关系，
将原有的二维数据表转换成以分析主题为中心的多维表。数据仓库的建立，可以
有效地管理业务数据，为数据展示、挖掘利用奠定基础。
数据仓库的数据主要供管理决策分析之用，所涉及的数据操作主要是数据查
询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间
内历史数据的内容,是不同时点的数据库快照的集合，以及基于这些快照进行统
计、综合和重组的导出数据，而不是联机处理的数据.因为数据仓库只进行数据
查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库
管理系统中许多技术难点,如完整性保护、并发控制等等，在数据仓库的管理中
几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提
出了更高的要求，它要求采用各种复杂的索引技术；同时由于数据仓库面向的是
高层管理者,他们会对数据查询的界面友好性和数据展示提出更高的要求。
医学知识库医学知识库用来存放各种规划、专家的经验、有关知识和因果关系等，主要包括事实库、规则库和约束库三部分。事实库存放求解问题的说明性知识、构成信息实体的事实等；规则库中的主要内容是特定领域构规则、定理、定律等过程性知识及说明模型库中各个模型的使用范围、方法及关系的规则信息。约束库主要是说明知识的使用范围和使用条件。
知识库管理系统的主要功能是在决策过程中，通过人机交互作用，使系统能
够模拟决策者的思维方法和思维过程，发挥专家的经验、推测和判断，从而使问
题得到一个满意而又具有一定可信度的解答,同时可以根据知识库的知识和经验生成建议以支持决策。由此可见，医学知识库是临床决策支持系统中的另一个重要元素。知识库应包含词库、术语字典、模型结构、知识仓库四个部分。
疾病数据库疾病数据库是一种将疾病按病种或术种进行分类，使数据标准化,存放在计算机数据库中，以备研究使用的数据管理与分析系统。包括:疾病名、英文名、缩写、别名、ICD疾病代码、概述、流行病学、病因、发病机制、临床表现、并发症、实验室检查、其他辅助检查、诊断、鉴别诊断、治疗、预防、预后及循证医学证据等项目。通过疾病分析统计数据库，可以将科室多年积累的病例全部存入计算机，根据需要随时调出，计算统计结果。只有利用数据库技术，通过科学分类，归纳疾病知识体系，建立系统化专科疾病统计数据库,才能获取高质、完整研究资源，进而取得广泛研究成果。
药品数据库提供药品信息，包括药名、英文名、别名、剂型、药理作用、药动学、适应证、禁忌证、注意事项、不良反应、用法用量、药物相互作用、专家点评等项目。
药品相互作用审查
提示两种药物给一个患者时可能出现的药理学效应,这些相互作用可能导致毒性增强、药效降低等,使药物的实际使用效果发生改变，或导致不良反应。
药物过敏预警
主要对药品的禁忌症、副作用、老年人用药、儿童用药、妊娠期、特殊药物剂量的审查和预警.
合理用药监控
提供药师在药品调配时对患者处方或医嘱进行合理用药自动和人工审查功能，将发现的问题进行记录并反馈给责任医师的功能.
用药研究
用药研究模块是提供给医生研究药品资料的入口，在该模块中医生可以查询和组合审查药品知识库中全部几万种药品，也可将当前下达的用药医嘱导入用药研究中与另外的药品组合测试，在用药研究平台中所有信息都不会被保存,也不会影响医生工作站正常的医嘱。
辅助检查数据库提供各类检查项目信息，每一种检查项目涉及名称、缩写、正常值、临床意义等内容。
循证医学数据库主要包括:临床实践指南、系统评价和临床科学研究,其中临床科学研究包括：随机对照试验、对照临床试验、非随机对照临床试验、病例对照研究、队列研究、病例报告、病例分析及横断面研究等研究证据.以统一的数据规范存储成全文数据库。循证医学数据库的建立，有利于提高医疗质量和临床科研水平。实施循证医学将会不断淘汰现行无效的医学干预措施，防止新无效的措施进入
医学实践,从而不断提高医疗卫生服务质量和效率，充分利用有限医学资源。通过对医学信息的挖掘、整理，进行知识的重新组织，实现从信息服务向知识服务转变。
医学资料参照库提供具有代表性权威临床研究论文、医学期刊和临床医学学会的全文文献.提供各科权威临床医学教科书全文。针对特定主题做导览式查询,并提供相关图书、期刊文献、药物信息、临床指引、卫教信息等参考列表.
临床辅助诊断主要提供辅助诊断治疗，根据病人的症状，通过分析决策引擎，推断出患者的疾病,并提供合适的治疗方案,供医生参考。在医生确诊并开出处方或处置以后，对疾病、处方以及处置进行分析，与知识库中的规则进行比对,确认处方、处置的安全可靠性，如果有异常，则发出警报，对医生提醒，从而提升医疗服务质量，减少或避免医疗事故的发生。
4。4数据交换层医院集成平台核心是数据交换总线，这解决当前大部分医院最关注的电子病历与移动医疗等业务系统接口交互共享及消息数据状态同步（消息一体化机制)等问题。集成平台主要包括业务数据集并提供相应的标准处理接口API（含数据采集与数据发布查询更新),同时提供相应的适配器服务来处理不同供应商系统与集成平台标准接口的数据交互。
通过数据交换平台，使整个临床业务活动能基于医院集成平台更为充分的实现信息的共享与交换。实现各项临床业务活动在信息使用层面上最大程度的业务协同。使实际临床业务工作在充分的信息利用条件下实现提高业务效率、减少临床差错、降低业务成本、提高临床服务满意度。
通过开放平台提供的标准化接口，帮助第三方供应商通过运用和组装平台接口及第三方服务接口产生新应用,允许第三方实现扩展应用功能，同时提供统一便捷的接入方式保证新应用基于平台环境的统一管理和运行。
word/media/image6.jpeg
ESB（Enterprise Service Bus,企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息协议接口.ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议(SOAP）传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。
ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态的互连互通。ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：
面向服务的架构－分布式的应用由可重用的服务组成
面向消息的架构－应用之间通过ESB发送和接受消息
事件驱动的架构－应用之间异步地产生和接收消息
应用集成管理服务用于对各种基本服务和应用程序进行统一的管理与监控。通过开放平台提供的标准化接口，帮助第三方开发者通过运用和组装平台接口及第三方服务接口产生新的应用，允许第三方实现扩展应用功能，同时提供统一、便捷的接入方式保证新应用基于平台环境的统一管理和运行.应用集成管理服务通过开放的合作方式,利用共享资源相互交换形成平台提供商及应用开发商的共赢,是实现平台应用丰富多元的重要基础，促进了平台产业健康发展的良性循环。
主要功能与特点：
开放式基础工作环境,通过可持续运营模式最大限度保护现有投资；
提供实时预警方式确保平台应用不间断运行；
支持电脑、手机、平板等多种终端设备，满足服务提供方式的灵活性；
通过集成统一视图技术确保第三方应用的无缝快速集成;
提供标准的开发支撑组件，有效支撑第三方应用供应商参与到医疗平台应用开发与持续性建设。
word/media/image7.png
4.1.1.数据交换层总线技术特点医院集成平台的数据交换服务总线具有以下技术特点:
SOA支持方面,遵循SOA设计原则和技术标准，能够构建标准的企业服务
总线平台，提供松耦合模式，将业务逻辑和应用逻辑、数据逻辑等分离开，提供一个满足企业的应用集成和信息调解需求的解决方案；
Web服务支持方面，支持最新WebServices标准，包括SOAP1。1/1。2、
WSDL1。1、MTOM/XOP、WS-I Basic Profile 1.1等,支持WebServices自有的安全性WS-Security和寻址功能WS-Addressing，可以实现WebServices同步和异步不同形式的调用；
智能路由方面，灵活的消息路由方式,支持基于消息内容的处理和路由；
而且还可以执行一系列方式的消息交互,包括了过滤、充实、监视、分发、关联、拆分（一对多)和合成(多对一）等;
XML格式转换方面,标准XML数据的格式转换，并且可以通过图形化映射
组件、XSLT、等多种方式实现转换功能;
非XML格式转换方面,非标准XML数据的格式转换，实现XML消息格式和
其他数据格式之间的映射，同时也要支持自定义数据格式;
发布/订阅方面，提供发布/订阅功能，支持队列和主题两种订阅模式，
主题订阅模式支持树状结构，即支持多级主题模式，支持主题模糊的匹配方式,同时支持跨越多节点的发布订阅能力；
图形化开发工具方面，提供图形化界面开发工具,实现简单和复杂的数
据流程设计，提供图形化界面的数据映射和拖拽方式，以及配置功能的开发。提供多种内置功能组件和节点，功能涵盖协议接入、路由、转换、监控、例外处理等，同时要支持自定义的处理节点，提供多种编程语言的实现接口；
通讯协议支持方面，提供可靠的数据或消息传输，确保消息传输的最简
化连接方式，支持灵活和开放的协议支持，包括HTTP/HTTPS、JMS、FTP/File、
Socket、SMTP、SOAP/HTTP等;
数据库支持方面,实现与关系数据库实现无缝的集成，同时支持JDBC和
ODBC两种数据库连接方式,支持数据库要涵盖主流数据库;在数据交换和流转的过程中，支持业务逻辑中对不同数据库的存储操作，支持对不同数据库实现不同的用户和密码支持。
管理方面,提供图形化性能监控工具，支持统计和分析的功能；
性能方面，具备高性能处理能力，尤其对于XML数据的校验和解析、XSLT
解析、非XML报文的处理、路由和过滤、数据库操作、WebServices调用等都要满足高性能要求，提供动态的缓存机制，保证数据能够在内存中最快速的处理；
可用性方面,提供高可用性，保证平台7＊24小时的运行；提供高稳定性，
保证在数据量或应用连接数高峰运行时的系统运行正常，保障持久化系统运行；
安全性方面,提供多种安全机制，用户级别的认证、授权，支持标准的
LDAP服务器；访问级别的SSL传输机制；数据内容级别的数字签名等机制。
4.1.2.数据交换总线功能特点医院集成平台的数据交换服务总线具有以下功能特点：
数据汇总
支持各个分支数据源汇总数据到数据中心。采集公共数据的过程可以看成是一个数据汇总的过程，通过信息共享交换平台将各业务部门的公共数据采集回来,汇集到数据中心的缓存数据库。经过数据管理系统的比对、校验、转换得到一致的数据。
数据分发
数据分发是从数据中心的角度，主动向各数据使用方提供数据的过程.通过公开数据服务，依照数据使用权限的规则，从数据中心把数据分发到各个数据使用部门，实现数据共享、信息联动。
数据存取访问
信息共享交换平台提供实时按需的数据存取访问服务，通过统一标准的数据接口，以XML作为标准数据格式，通过标准的Web服务对各种技术平台提供访问支持。
优化业务流程
实现利用现有的软件系统，通过集成平台产品，重新组织医院的业务流程和工作流，配置业务规则，包括可能跨跃不同的软件系统的业务流程整合。各个系统与平台的平滑连接、各个子系统之间数据平滑流转、各个系统工作站功能整合（病人主索引、分布式资源索引、综合统计报表编辑和发布平台、数据仓库和数据挖掘的、内部网络查询和管理综合门户、基于所有系统的人员及部门权限管理、安全管理等），业务流程定制提高了系统的灵活性和适应性，确保了整个业务系统能够很快的适应实际业务流程的变化，为医院未来业务发展提供支撑。
数据转换
数据交换服务可以把某个数据库的数据转换成标准XML数据集。通过数据转换模块,实现对各种异构数据转换到统一标准规范、具有一致性和完整性的公共数据.
任务定制
数据接口系统应该允许用户自己配置和管理相关的服务，如:数据提取服务、数据发送服务、数据接收服务、数据存储服务等。
支持用户自定义
数据接口系统应该是一个开放的系统,要提供一些可扩充的接口以及二次开发接口，支持用户基于这些接口来定义自己的特色服务。
支持业务行为监控
能实时掌控整体业务运行。能够对关键的业务行为以及相关的事件做出实时反应，以及自动反馈并执行分支业务流程。
支持平台监控管理
对数据服务进行监控管理，用户权限管理，运行日志查看,性能统计。通过数据服务日志可以记录、跟踪数据交换的细节。对数据交换节点进行管理，提供安全策略指南、服务器安全管理配置.
4.1.3.基于数据交换服务总线的业务数据交互应用集成管理服务用于对各种基本服务和应用程序进行统一的管理与监控。通过开放平台提供的标准化接口，帮助第三方开发者通过运用和组装平台接口及第三方服务接口产生新的应用,允许第三方实现扩展应用功能，同时提供统一、便捷的接入方式保证新应用基于平台环境的统一管理和运行.应用集成管理服务通过开放的合作方式，利用共享资源相互交换形成平台提供商及应用开发商的共赢，是实现平台应用丰富多元的重要基础,促进了平台产业健康发展的良性循环。通过统一的业务交换服务平台标准，可以实现以下业务数据交互：
1)支持集团化医院业务，解决各成员医院间的远程数据交换,主要包括病人档案信息共享、病人诊疗信息共享、跨院检验检查、药品、易耗品等物资一体化功能。
2)HIS与检验系统信息交互,通过业务服务平台获取检验单据信息、患者住院信息、病历信息,记录完整的检验单据处理过程，标本送检过程处理与单据费用自动处理，检验报告结构化存储,实现多系统统一的报告调阅接口；
3)HIS与医技检查系统信息交互，放射检查、病理检查、心电、B超、内镜检查业务通过业务服务平台获取检查单据信息、患者住院信息、病历信息，记录完整的检验单据处理过程，检查图文报告结构化存储，实现多系统统一的报告调阅接口；并支持统一影像浏览及处理。
4)HIS与电子病历系统信息一体化，完善以电子病历为中心的临床信息系统,提供电子病历分级评价标准实现。
5)临床路径信息查询,可通过数据交换服务总线，实现路径表单、知情通知书、路径评估单等信息查询.
6)建立多途径的消息机制，实现各系统间关键医疗信息自动提醒(如急诊异常报告）、预警功能；
7)字典同步：同步各系统间的基础字典（如科室、员工字典），消灭重复数据。
8)与区域市民健康档案标准化无缝对接,实现区域市民健康一卡通、双向转诊、远程医疗、检查检验结果互认、预约诊疗、区域卫生健康门户等区域卫生信息共享与协同服务应用；word/media/image8.png
4.1.4.跨医院信息交换平台伴随着医院集团的出现，医院信息系统的集团化成为新时期的医院信息系统建设的重要方向，为了使庞大而又分散的经营体系内部的各类机构能步调一致，有效地运转,集团总部及各成员医院都需建立相应的信息系统,并用远程通讯网络将整个集团构成一个有机的整体,大型的医院集团如果没有一个健壮的电脑化集团信息系统，就难以实施有效的管理，也就难以获得经营的效益。
集团化医院较之单体医院的最大特征在于资源在一定程度上实现了共享，但目前大部分的集团化仍未达到充分的资源共享，比如：集团下属各家医院一般都有独立使用自己的LIS 系统,LIS 数据仅存在本医院内部，当病人跨院就诊时，往往需要重新检验，造成大量的人力、财力的浪费。因此，集团化医院信息系统的一个基本任务在于解决各成员医院间的远程数据交换，主要包括病人档案信息共享、病人诊疗信息共享、跨院检验检查、药品、易耗品等物资一体化功能.
通过在总院建立中心数据共享平台，中心数据共享平台根据需要通过各医院的子系统收集并存储患者信息，所有授权和整合的医院都可以访问。这样资源和患者能够有效地在各个医院之间流动，各家医院之间的报告信息、设备、人才可以共享，报告结果互认，当病人跨院就诊时就不再需要重新检验，避免了人力、财力的浪费，方便了患者，提高了服务质量，一定程度上缓解了“看病难、看病贵”的问题。
4.5公共消息服务平台医疗数据交换服务主要用于实现医疗信息系统之间的消息路由、过滤和转换。通过该服务可以将异源异构系统的信息，按照“以病人为中心”的原则进行数据的交换与共享。医疗数据交换服务支持多种技术环境下的数据交换，支持多种传输协议和数据库读写方式，并支持多种数据传输格式，同时,在系统数据未遵循相应传输格式的情况下,提供发送、接收、组装和解析该格式消息的适配功能。
集成平台消息总线主要是为了连结HIS不同业务系统，提供统一标准的数据接口来进行信息互联互通，集成平台外部系统都通过标准接口发布与接收消息,一般不允许直接读取消息数据集。
消息处理服务接口基于数据库与.Net的内部实现，内部核心组件引入业界通用的互联互通消息交流产品，且支持HL7消息引擎.可扩展标记语言（Extensible Markup Language ，XML）目前正在成为各种数据特别是文档传输的首选格式.使用它，就可以容易定义一致的数据格式和传送数据,包括HL7 V3，MML协议也都是以XML语言为基础。
医院信息集成平台的消息交换标准框架应具备以下特点:
共享语义和内容结构
两个应用程序之间为了通信，必须共享数据结构.例如,如果一个应用用单个字符串处理一个病人的地址，另一个应用程序用街道、城市、州、国家来处理地址，这两个应用程序很难进行通信。消息模型须提供规则化的方法，保证唯一的语义和内容结构，当两个应用程序关于通信地址进行通信时，它们针对以下内容达成一致:含义、包含的数据、与其它概念的相关关系。
结构可扩展
XML是可扩展的.消息服务架构须保持这种可扩展性，用户可以利用基本内容并且扩展、客户化这些以使它支持它们的需求.
数据交换可监控
如果只是简单地容纳外部协议的数据格式进入总线进行数据交换，那么对中心监控来说，由于协议之间的差异,对每一种数据交换协议产生的离散的数据内容，都要定制相应的监控程序，这将大大增加数据中心的复杂度和维护成本，并由于多重监控的系统资源消耗，将严重地影响中心数据交换吞吐量，在实际应用中是不可行的。
只有基于统一的总线数据协议，才可能对日常交换的数据进行监督与控制,才可在中心进行消息过滤，安全控制等复杂操作。
集成平台消息服务由以下两个基础功能部件组成：
4.1.5.支持HL7引擎服务部件HL7 是医疗领域不同系统之间电子数据传输的协议，是由HL7 组织制定并由ANSI 批准实施的一个行业标准。它主要的目的是发展各种类型医疗信息系统（如：临床、保险、管理、行政）及各项电子资料的标准.在HL7 通讯协议中,消息(message）是数据交换的基本单位。HL7 的消息是自动生成的，HL7 标准是一个文本结构的文档.
HL7 消息定义规则：
（1）消息(Message）： HL7 共归纳了八十多种信息类型,用于定义消息目的和用途,每条消息由若干消息段组成.
（2)消息段（Segment）： HL7 共有110 个消息段，消息段由数据字段组成，消息段都有相应的名称，用语界定其内容或功能。
（3）字段（Field）:是一个字符串。需定义其位置、长度、数据类型、选择类型、重复性.
(4）消息分隔符（Delimiters):在消息的构成中,要用到一些特殊字符来分隔消息的组成元素.
HL7消息接口实际是一组标准的API 接口，这样可以大大简化不同厂家同类应用程序接口的复杂度和工作量。HL7 采用消息传递方式实现不同模块之间的互联，十分类似于网络的信息包传递方式，可分别在发送和接收端设定发送和接收信息数据传输前自动检测接收端的状态,接收端按约定内容和格式接收信息后自动判定接收信息的质量，并根据情况分别返回接收正确、错误和拒绝3 种信息，后两种情况下通知信息发送端重新发送.HL7接口引擎是一类通用信息转换中间件，作为标准化的数据转换工具,通过HL7 接口引擎,把非HL7 格式的数据转换成符合HL7 的标准数据，然后在HL7 网络上进行通信传输，而只需在系统的边界增加作为通讯处理模块的HL7 接口引擎，对系统间的数据进行转换和通信，达到数据共享的目的。HIS厂商与PACS 厂商分别开发各自系统接口引擎，并在双方服务器各开两个端口，分别发送和接收HL7 消息。
HL7引擎服务：一个企业服务总线在整个SOA架构中核心的部分，与原来的面向接口的架构设计不同，面向服务的体系结构（SOA）将各个服务之间的接口逻辑规范、简化到与总线的一套接口逻辑上来，极大的简化了集成的复杂程度，避免未来由于接口规范发生变化导致的系统建设风险。
word/media/image9.png
XML消息队列：衔接被集成系统的XML消息队列，接收和发送各个“服务”之间的XML;
HL7解析：集成平台的核心功能之一,实现非标准XML与标准HL7XML之间的自动解析，实现非标准于标准之间的自动转换。
业务流程定义（路由）:按照业务流程定义被集成“服务”之间的交互流程，定义非标准信息和HL7标准信息的交换路由，自动控制流程的流转；并可通过出错流程的定义实现异常控制；
HL7标准消息队列：本项目中，被集成的应用系统可能均为非HL7标准的系统，但考虑到未来的扩展，在集成平台中预留了HL7标准的消息队列，任何系统都可以从该队列中获取本项目中全部的标准HL7信息流。其对未来系统的集成扩展的意义非常重大;
4.1.6.适配器服务部件接入服务部件：以Adapter的方式实现对被集成平台的集成接入，按照SOA的设计理念，被集成系统需要与集成平台交互的功能组件将被封装成“服务”，屏蔽被集成系统所采用的具体技术及其实现方式，以单一的接口方式与集成平台衔接。平台接入服务部件可以灵活部署，可以部署在被集成系统内，也可以部署在集成平台上实现远程接入。
Adapter:可以提供多种Adpter供用户选择使用，可选择最适合医院的Adapter连接被集成系统封装的“数据服务”；
XML消息队列:“服务”之间的信息交互载体为XML，通过消息机制建立XML的交换通道。
各个应用系统通过与消息交换中心实现消息交互。通过在业务系统端安装相应的软件适配器，实现与消息交换中心的信息交互。适配器由软件模块、软件配置文件、应用编程接口等组成。消息交换的模型如下图所示：
word/media/image10.jpeg
消息交换模型
在消息总线系统的整体设计架构中，各个具体的业务系统通过Adapter连接到消息消息交换平台收发业务数据。Adapter起着耦合消息交换平台与具体业务系统的作用.
在我们的解决方案中有三种适配器：标准适配器、专用适配器和商用适配器.标准适配器是由标准的Adapter Kernel和API组成。Adapter Kernel实现和消息交换中心的消息交互和对消息的实时监控,并提供将消息分发到应用系统的功能.API是为应用系统提供的一套标准的接口，具有足够的扩展性，可以灵活地嵌入到业务流程中,同时将与业务无关的通讯配置定义与业务代码隔离。
具体地，Adapter实现以下的功能：
∙实现消息的安全、可靠传递；
∙实现消息的透明传递，Adapter的实施者不必关注传递技术细节；
∙接口通用化,降低因开发架构不同导致的业务应用侧编程复杂性；
∙实现具有共同性的消息封装、变换、接收功能。例如,加解密/校验/字符集变换及HCN—XML标准协议;
∙简单的远程安装配置方法,适配器的函数调用库可以平滑升级而不影响业务应用；
可以与消息交换平台交互管理信息，实现流量控制、报文蓄积、本地日志等功能。
4.2.Ensemble集成平台中间件Ensemble HIE（健康信息交换）是InterSystems公司一个新的产品,它采用了一种全新的解决方案，是一个强大的应用软件整合平台,它包括了为医疗信息交换预先开发好的组件,使用Ensemble可以快速地整合和开发复合应用程序。Ensemble在增强现有软件功能、协调新的商业过程和集中企业数据等方面非常出色.
为了满足每一个交换系统的实际需要,它还提供了一个为客户化和扩展这些组件功能的完整的开发环境.Ensemble HIE 是为降低成本，缩短开发周期以及降低健康信息交换系统构建运营风险而设计的。Ensemble HIE 是Ensemble集成系统的一个新的版本，专门为医疗信息组织和其它医疗信息交换应用设计。
4.2.1.Ensemble HIE 构成组件Ensemble HIE 包括三个组件,它们共同来解决每一个跨机构的健康信息交换系统实施的端到端的需求。
✓Ensemble HIE Hub 作为病人的中心索引，通过“指针"指向包括病人临床数据的医院和医生的办公系统。
✓Ensemble HIE 网关把参与医疗场所和用户连接到交换平台。
✓Ensemble HIE Viewer 是一个成熟的基于浏览器的门户,医生和其它的临床医生可以通过它来访问病人的人口统计学和临床数据。
word/media/image11_1.png
如上图所示，这三个组件的任务可以通过一个简单的例子来展示。假设一名医生想要得到一个病人的临床数据，这样的处理过程便会开始：首先，医生查询Hub来“找到"病人。接着，在确认了病人之后,医生需要从一个或者多个站点获取数据。请求被发送到这些站点的网关，数据从每个站点的本地应用系统中被取出,之后网关再把这些回应汇集起来.这些回应被送回到最初的网关以供使用Ensemble HIE Viewer的医生使用。
Ensemble HIE Hub
Ensemble HIE Hub 提供了一个中央病人索引，存储了病人统计信息的摘要，这些信息和存储在医生办公室、医院或者其它护理和检测场所的系统中的医疗记录相连.当一个站点加入到信息交换系统，病人的索引信息就会被成批导入.之后，如果在护理场所出现变化，也可以持续更新—-例如,增加了一个新的病人，或者现有的病人信息被更新,或者两个病人记录被发现属于同一个病人，需要现有的记录合并。
word/media/image12_1.png
Ensemble HIE网关
Ensemble HIE网关负责所有的在医护场所和Hub之间或者医护场所之间网关到网关的通信。网关同时也连接到每一个地点已有的应用，使之间的信息可以双向流动.特别的，这些应用会通知网关一些需要反馈给Hub的病人索引的事务，例如,一个新的病人注册或者更新一个现有病人的人口统计学信息。在另一方面，网关给医护场所已有的应用系统发送需要临床信息的请求。网关和每个医护场所的应用系统之间的通信是通过Ensemble的适配器来进行的。
每个网关包括一个同意管理架构,被用来记录病人同意的声明并加以执行。网关也包含了一些成熟的工具来进行本地的集成。这些可以用来处理现有的临床应用系统查询社区病人索引或者向其它的机构获取病人数据。
word/media/image13_1.png
Ensemble HIE 浏览器
Ensemble HIE浏览器和Hub联接，使平台范围内的病人搜索成为可能,而且它使分布在多个机构和多个医疗事件中的数据统一到一个以病人为中心的综合视图。它为大范围内的不同的信息提供了一个直观的显示,包括病人的人口统计学信息、过敏、用药、诊断、实验结果(结果范围，累计和图形的格式）、放射检查结果（文本和影像）、家庭病史、临床发现、病程记录等等.作为一个纯Web产品，浏览器可以非常容易地实施和支持，仅仅需要一个浏览器，在客户端不需要安装组件.让我们看一个讨论的示例以了解Ensemble HIE浏览器的强大。我们到社区医疗信息交换平台的Web站点并登录开始。
4.2.2.Ensemble HIE设计原则Ensemble HIE 是基于6种主要的设计原则构建：
可用性：临床医生需要通过同一个应用系统来把临床数据（也就是除了他自己的系统或者工具中的数据）当成本地数据来浏览。遗憾的是，现在大多数电子病历系统缺乏这一功能，如果要增加这一功能需要非常多的时间，获得这点的最好途径就是在系统中增加一个临床数据浏览器，成熟却简单易用，高度客户化却配置简单，功能丰富却非常直观，可以在任何支持浏览器的机器上使用。
安全和保密：系统必须严格符合隐私和安全标准。严格的授权,基于角色的访问，细致的安全政策以及不可更改的所有用户的活动记录，都是实现这一目标的要素。
性能、可伸缩性和可靠性:系统需要提供对临床数据接近于实时的访问:不管是用于几十个用户的测试系统或者几千用户的州或者国家范围的系统.并且需要做到24*7的稳定运行。
基于标准：标准是互操作性的关键。通过在数据交换的每一个阶段采用相关标准——HL7 V2、HL7V33、Web Services以及CDA——系统可以确保不仅能够和新的或现有的临床系统互通而且和其它的医疗信息交换解决方案互通.
灵活性和快速的客户化：虽然信息交换系统的功能和标准在快速的发展,但是仍然属于刚刚起步的阶段。许多实施架构正在被考虑，例如：集中式，分散式以及混合式.所以系统需要能够有非常高的灵活性并可以快速改变，以适应不断发展的需要和用户反馈。
易管理：作为一个“系统的系统”，一个健康信息交换系统对于系统管理和维持系统高可用性来说挑战是非常大的。系统需要支持不同角色的管理员，易于维护,为管理所有的组件以及使用系统所有的管理功能提供端到端的基于Web的管理门户.
4.2.3.Ensemble HIE技术特点医院集成平台必须能够以最小的成本可靠的与数量庞大的现存的临床应用系统互联。通过Ensemble HIE，这项工作可以由三项强大的技术来完成:适配器，数据转换，业务流程。
《医院集成平台建设方案》相关文档：
医院竞聘演讲稿(14篇)09-01
医院竞聘演讲稿(通用6篇)09-01
2023年医院导医台工作计划09-02
2023医院年度工作计划10篇09-02
2023年关于医院年度工作计划汇总六篇09-02
2023医院检验科年度工作计划7篇09-02
2023医院检验科年度工作计划(7篇)09-02
2023年医院整体工作计划（精选8篇）09-03
医院购销合同09-07
医院保洁服务合同范本09-07
