医院集成平台建设方案

医院信息系统集成平台建立方案书目1. 背景 52. 建立目标 52.1实现医疗信息资源整合和利用 62.2实现医院数据中心建立 62.3供应管理决策及临床决策支持 73. 设计原那么 7管用性和先进性 8平安性和牢靠性 8开放性、互连性和标准化 9灵敏性和可扩展性 9经济性和投资爱惜 9易管理和易操作性 9整体设计和多种应用相匹配 104. 建立方案 104.1医院信息化建立面临的问题和难题 104.2医院集成平台总体框架 144.3标准化数据中心 16建立数据中心的意义 17根底信息库 20业务信息库 21交换信息库 21临床文档库(CDR) 22临床数据中心构建方法 25操作数据存储ODS 26数据仓库 28医学学问库 294.4数据交换总线平台 324.1.1. 数据交换总线技术特点 354.1.2. 数据交换总线功能特点 364.1.3. 基于数据交换效劳总线的业务数据交互 384.1.4. 业务规那么引擎 444.1.5. 事务驱动引擎 454.1.6. 集团化医院信息交换平台 454.5公共消息效劳平台 464.1.7. 支持HL7引擎效劳部件 484.1.8. 适配器效劳部件 514.2. Ensemble集成平台中间件 534.2.1. EnsembleHIE构成组件 534.2.2. EnsembleHIE设计原那么 564.2.3. EnsembleHIE技术特点 574.2.4. EnsembleHIE功能介绍 62病人主索引〔MPI〕 654.2.5. 病人主索引功能 664.3. 统一身份认证授权平台 704.3.1. 统一身份认证授权平台主要功能 71. 单点登录 71. 身份管理 72. 授权管理 72. 平安审计 724.3.2. 统一身份认证授权实现方法 73医院决策分析平台 744.3.3. 决策支撑平台技术架构 764.3.4. 决策支撑平台数据架构 774.3.5. 指标加工逻辑架构 784.3.6. 系统工作内容及技术路途 80. 指标库构建和管理的工作内容要求 80. 指标库构建和管理的设计原那么 84. 指标库构建和管理的技术路途 85短信效劳平台 854.3.7. 短信平台架构 864.3.8. 短信平台功能模块 86. 通知功能 86. 查询功能 87. 信息管理 87. 语音信箱询问功能 87. 医院信息查询功能 87. 投诉/举报/建议受理功能 87. 自动效劳功能 88. 导医功能 88后台运维管理系统 884.3.9. 信息资源统一监控系统设计原那么 914.3.10. 信息资源统一监控系统架构及技术实现 924.3.11. 信息资源统一监控系统管理模型 93平安保障体系 944.3.12. 隐私爱惜措施 944.3.13. 网络平安保障 974.3.14. 数据保密性 984.3.15. 数据完整性 994.3.16. 恶意代码防范 1004.3.17. 性能保障措施 1014.3.18. 运行环境保障措施 1024.3.19. 信息平安和审计保障措施 1035. 平台扩展 103

建立背景我国医院信息系统建立已经有三十年的开展历史，早期有所谓的AllinOne的系统，全部的应用都由一个供应商供应，效劳于不同目的的应用模块，包装在一个软件包中，全部的数据库都是开放给全部的应用的，不须要接口引擎的设计。然而，医疗卫生信息的困难性确定了医院信息系统的应用越来越困难，医院对信息的需求也不断扩展，任何一个HIT厂商不行能供应医院所须要的全线产品〔也包括国外的HIS厂商〕，要实现真正一体化的医院信息系统，必需引进不同厂商的信息系统产品。因此在同一医院环境下，集成不同厂商的产品就成为医院信息化建立过程中势必遇到的问题。一起先几个厂商的产品要到达互连互通，往往是接受点对点的接口方式，因为这种方式简洁、易行且本钱低，例如，将一个医疗保险的结算系统和医院的住院及门诊病人的费用管理系统集成。然而，当医院的应用扩展到十几个乃至几十个应用系统时，问题就变得困难起来。医院信息化能够取得成功必需保证各个系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的开展需求逐步建立的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经慢慢成为制约医院数字化开展的主要障碍。而如何把这些系统连接实现各部门各专业信息共享就成了医院信息化建立中面临的一大难题。假如以传统的方式在各系统之间做接口的话就将出现众多的接口，这将给医院信息系统的稳定性、平安性、牢靠性、效率等带来巨大的隐患，同时以让医院的运行维护本钱成倍增长，假如医院要对其中一个应用系统进展升级或更换就必需再做众多数据接口。随着国家新医改政策的实施落实，以医院为单位的管理模式已不能满意广袤人民群众日益增长的医疗卫生需求，信息共享是实现信息价值最大化的重要途径之一，区域医疗信息共享是信息化开展的势必趋势，为了实现医疗信息的区域化共享，同样须要在医院内部把不同数据资源进展集成整合。在此背景下通过医院信息集成平台来代替原来数量众多的点到点数据接口，为医院信息化建立供应标准和标准，只要各应用系统都支持这些标准和标准，原那么上就能和应用信息平台进展数据交换，并能同和平台相连的应用系统进展数据交换。建立目标2.1实现医疗信息资源整合和利用为实现各业务系统信息互联互通，假如接受推倒重建的方法，就有可能将奢侈大量的资金，并引起业务震荡。通过医院信息平台的建立尽量削减不必要的重复建立。医院原有的各业务系统和信息系统通过医院信息平台供应的接口实现整合，继承已有的数据资源和效劳。通过建立医院信息平台，将原先分布在各业务系统中的信息交换整合到医院信息平台，实现医院各个科室之间、医院之间信息的互联互通，最大限度地便利病人就医、便利医院一线医护人员工作、便利各类管理人员分析决策。2.2实现医院数据中心建立为了使医疗活动可以精确、快速地进展，医疗效劳者不但要接收到清晰的医疗指令信息，还须要驾驭效劳对象相关各方面信息、记录效劳对象在医疗活动中的状况及结果；因此要保证数据信息的高效利用，到达一处采集多处利用；以病人为主线，将病人在医疗机构中的历次就诊时间、就诊缘由、针对性的医疗效劳活动以及所记录的相关信息有机地关联起来，并对所记录的海量信息进展科学分类和抽象描述，使之系统化、条理化和构造化。建立医院数据中心，通过数据中心实现不同信息系统、组织机构间信息资源整合，实现业务数据实时更新，确保信息同步；满意管理决策、临床决策、科学探究、对外信息共享；实现统一的数据仓库的设计及技术文档、元数据管理等功能。建立医院信息集成平台需制定统一的信息交换标准，统一卫生信息标准和数据字典。2.3供应管理决策及临床决策支持凭借数字化医疗信息效劳的先进技术作为强有力的支撑，利用更为先进的信息化手段，驾驭工作的主动权，把传统事后处理转为实时监控。建立医院信息平台，规划医疗资源，实现诊疗流程再造，提高医院运作效率，提升医院的整体效劳实力，有效解决就诊“三长一短”现象；建立统一的门户信息，为病人的全面医疗安康信息的保存、传递、查询供应有效的数据，对数据的快速实时查询。通过对数据进展分析和处理，对信息进展有效利用，帮助管理者进展科学管理决策，帮助医生进展基于循证的医疗决策和医疗准备的制定，支持临床应用科研的开展。设计原那么目前，大局部医院的医疗信息系统实现数据共享是接受了传统点对点通信模式的方法，这样的方式须要每两个系统之间都有专用的接口，且当有新系统添加进来的时候，也必需要单独为每个子系统开发和新系统相应的接口，工作量极大。这样的专用接口也存在很大风险，简洁导致系统崩溃，中断医院正常的医疗业务流程。因此，须要建立一个能和全院全部医疗信息系统干脆沟通的数据集成平台，以此为中介，实现各系统间的数据共享和交互。建立一个以现有信息系统和数据资源为根底，符合标准的、高牢靠的、开放式医疗卫生信息共享平台，实现区域卫生协同和诊疗信息共享；在平台上供应区域级的标准组件效劳、诊疗学问效劳，以及协同医疗、卫生监管和安康管理等应用效劳，有效提升医疗卫生效劳水平和效劳实力，支持创新具有区域特色的开放、管用、共享、持续的医疗卫生效劳模式。目前通常接受基于中间件模型和数据仓库等方法来构造集成的系统，这些技术在不同的着重点和应用上解决数据共享和为企业供应决策支持。在方案设计时遵循了以下原那么：统一性统一设计原那么统筹规划和统一设计系统构造。应用系统建立构造、数据模型构造、数据存储构造以及系统扩展规划等内容，均需从全局启程、从长远的角度考虑。管用性和先进性当今的计算机技术日新月异，因此要求选择的方法、技术、工具、设备不仅要保证具有先进性，而且要保证技术方向的正确性。设计的方案要结合考虑管用和兼顾今后开展的目的，不管在效劳器、软件及中间件等软硬件产品方面，还是在方法论、工具方面，都应选择当今国际上成熟的、主流的并领先的产品和技术来适应更高的数据处理要求，以满意医疗管理信息系统将来5-10年的需求开展，并应具有良好的扩展潜力，以适应将来业务的开展和技术升级的须要。平安性和牢靠性设计的整体方案要通过多种平安技术和防护手段，保证系统自身的平安性，保证效劳不会中断。在本工程方案中，最重要的设计启程点就是系统的平安，关键设备或设备核心部件应当接受冗余设计，能够幸免单点故障导致系统整体或重要功能的丢失，保证系统平稳运行，最大限度削减停机时间而且包括便于故障排查、复原和日常的运行维护的机制。在接受硬件备份、冗余、负载均衡等牢靠性技术的根底上，接受相关的软件技术供应较强的管理机制和限制手段，以提高整个系统和数据的平安牢靠性。开放性、互连性和标准化系统必需接受国际、国家标准、协议和接口，能和现有的和将来的系统互连和集成，支持HL7、IHE、DICOM、ICD10等标准。灵敏性和可扩展性设计的方案应当考虑系统的灵敏性和可扩展性。系统建成后要能够满意业务近期、中期甚至长期时间范围数据和业务快速增长的须要。适应目前需求的根底上，能够满意医院以及相关医疗机构不断开展的信息化须要，充分地为将来可预见和不行预见的性能扩大留有余地，并具备便利地扩展系统容量和处理实力和支持多种应用的实力，可以依据业务开展的须要进展灵敏、快速的调整，实现信息应用的快速部署，而且新功能、新业务的增加能够在不影响系统运行的状况下实现。系统要充分考虑到扩容和升级的须要，能灵敏便利地适应将来系统可能的变更。选择应用开放性标准的产品，确保设备的兼容性；通过系统构造的合理设计和适度资源冗余，为将来的系统扩大打下根底，保证需求增加时系统的平滑扩大，保证前期的投资。经济性和投资爱惜方案所选用的技术和产品应当全部遵循通用的国际或行业标准，各系统模块之间有良好的兼容性和较高的性能价格比。从长远来看，也便于系统的升级和移植或运行其他应用软件，实现整体效益，而且能以较低的本钱、较少的人员投入来维护系统运转，供应高效能和高效益的医疗信息效劳。易管理和易操作性设计方案支持全面、完善、便捷、统一的系统管理和应急处理预案，保证一旦发生问题能在最短的时间内处理解决。而且，系统应具有良好的用户操作界面、完备的帮助信息。集成完备的运行监视系统、良好的管理界面工具或远程限制台，易于管理人员对其进展管理和维护，系统参数的维护和管理通过操作界面实现。整体设计和多种应用相匹配集成平台须要进展统一设计，但是考虑到应用的多样性以及业务、部门等的差异，整体设计又不要过于制约详细的应用开发，要为各种应用开发供应灵敏的手段。可维护、可管理性通过统一网管，对信息系统平台进展统一管理，供应可视化的网络拓扑、网络状态监控、故障事务实时预警和告警、异样网络流量统计等。建立方案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日起正式实施。该标准规定了城乡居民安康档案根本数据集的数据集元数据属性和数据元书目。数据元书目包括城乡居民安康档案个人根本信息、安康体检信息、重点人群安康管理记录和其他医疗卫生效劳记录的相关数据元。适用于城乡居民安康档案的信息收集、存储和共享,以及城乡居民安康档案管理信息系统建立。标准中规定了卫生信息中标识类数据元的数据元标识符、数据元名称、定义、数据元值的数据类型、表示格式和数据元允许值内容。数据元书目包括标识信息相关数据元。按此标准建立的数据集内容涵盖了人员、医疗机构、医疗卫生术语、电子安康档案的数据集、数据元和各种代码标准的注册管理，数据标准化那么供应了在数据注册过程中基于标准化转换效劳，其囊括了区域卫生业务数据的全部数据标准标准，依据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准，并通过数据校验机制保障数据中心的数据进展标准化。标准数据完全匹配国家对全程安康档案效劳和注册效劳的要求。数据注册涵盖了人员、医疗机构、医疗卫生术语、电子安康档案的数据集、数据元和各种代码标准的注册管理，数据标准化供应了在数据注册过程中基于标准化转换效劳，其囊括了区域卫生业务数据的全部数据标准标准，依据应用领域分为数据类标准、技术类标准、管理类标准和业务类标准，并通过数据校验机制保障数据中心的数据进展标准化。依据标准建立的中心数据库数据集内容包括：根本数据字典：科室字典、员工字典、用户字典等；患者注册根本信息；门诊业务数据结果集：挂号记录、诊断记录、处方记录、结算记录等；住院业务数据结果集：住院记录、诊断记录、医嘱记录、结算记录等；安康体检数据结果集：体检登记记录、诊断记录、体格检查记录、评估报告、费用记录等；电子病历构造化数据集；决策分析数据集；医院管理指标数据集；上述局部构造主要是结果集的采集存储，为了满意不同平台之间或系统之间数据交互，涉及的业务相关数据集：住院患者信息相关表：如在院患者记录表、出入转记录表；临床路径相关表；单据记录及状态相关表：单据表、单据状态事务表等；电子申请单记录表及医技预约反响记录表；检验、检查报告记录表；系统间消息交互数据集；建立数据中心的意义数据中心是医院的业务系统和数据资源进展集中、集成、共享、分析的场地、工具、流程等的有机组合。它将不同业务系统之间须要共享的信息、综合业务系统和区域共享须要的业务数据，按行业标准转换明文方式长期存贮在一个数据仓库中。当前医院各业务系统面临的最大问题：系统业务无统一数据标准数据标准是指卫生信息采集表的处理过程中涉及到的标准，主要是指数据采集里的标准，定义各类数据标记的含义，标准数据采集的数据集能在不同系统之间传递的电子报文或者是电子文档。由于医院各业务系统产生的数据须要长期保存，但建立在这些业务数据根底之上的各种字典，由于医改的须要在不断地变更，系统中各类字典也不断膨胀，为削减业务数据错误和系统维护工作，许多系统设计者只能将明文保存的根底业务数据表，造成业务系统运行效率低下，维护困难。数据中心的建立，就是要将原各系统不能共享的孤岛信息，转换成符合国家或卫生部相关标准的数据集。为全院系统打造一个共享平台，统一字典维护，降低业务系统标准字典维护量，为区域共享供应可进展信息统计和挖掘的标准数据集。涉及到医院系统的主要标准有：疾病代码、科室分类、药典、非药品记费工程。业务系统数据接口由于医院业务管理系统，是一个长期运行，不断完善的状况下壮大成长起来的，医疗信息技术标准没有惯彻到整个业务中。由此造成上线系统越来越多，各系统之间数据的调用频繁，数据接口也就越来越多，越来越困难。常常出现某个业务系统升级无法到相关信息，或因某业务系统升级造成其它业务系统数据混乱的现象。医院业务需求扩张各业务系统随着用户应用不断深化产生新的业务需求：如质控、CA认证、闭环医嘱等。这些应用必需建立在多个系统之上，假设将这些应用需求不断参与到根底业务系统中，势必造成根底业务系统数据量不断膨胀，造成根底业务系统的可维护性和运行效率越来越差。病人信息综合处理目前医院的系统是按功能进展划分的，如：HIS系统保存病人费用和医嘱内容、LIS保存病人检验数据、PACS保存病人影像信息等。医生对病人的诊断往往来源于医院各业务系统，对其数据进展综合的结果。将这些来源不同系统并标准不统一信息，整合在一个界面中进展综合处理，存在巨大的障碍和分析效率低下的问题。将根本业务产生的数据，对其进展质量限制、清洗、转换保存到综合医疗业务数据仓库，长期海量保存。使根本业务和综合医疗业务的运行建立不同数据仓库中，实现分布式并行运行，有效地解决了高效、稳定的前台业务和多变的综合展示业务之间运行效率的冲突，极大地提高了根底业务系统的维护性和稳定性。共享根底信息库根底信息库集中了整个医院信息平台的根底信息和共享数据，是为各个子系统供应根底信息效劳的。根底信息库包括了患者的人口学信息、医疗卫生人员的注册信息、以及各种医疗卫生、公共卫生术语字典数据及流程模板数据等。病人根本信息是根底信息数据库中的核心内容之一。无论是电子病历、医疗业务、临床信息，还是疾病分析信息和公共卫生条线数据都是以病人根本信息为根底的。在此根底上，实现电子病历、医疗业务〔含临床数据〕的关联。医护人员库是根底信息数据库中的另一个核心内容，以医护人员信息为基础。可以建立医院诊疗资源注册库，可以作为医院管理以及绩效考核的根底。数据元字典是帮助各类医院业务、临床业务的根本数据元、代码集以及数据字典；以及包含了医院各种业务、流程说明模版的操作模型。流程模版库是包含了医疗机构医疗业务、临床路径、管理流程、财务结算等全部信息系统正常运转、分布协同的规那么库。通过流程模版库的流程引擎指导，能够明确患者在医疗机构内如何进展就医，临床医生如何对患者进展精确诊断，防保医生如何对疾病进展限制和分析，管理及后勤人员如何对医疗资源进展合理支配或者补充选购 、财务结算人员如何统计和限制医院的收入和开支。流程模版库是医疗机构保证正常运转的核心，对各级医疗卫生人员和患者的医疗行为起着标准和指导作用。原始业务信息库业务信息库是整个医院信息平台的数据根底，主要存储原始业务产生的数据，以未经过进一步加工的数据为主。包括诊疗业务流程产生的结果数据、医疗效劳管理数据以及医院运营管理流程产生的结果数据。这些未经修改的数据，作为电子病历的备份存储，在以后发生任何疑问时，可调阅业务信息库中的数据进行核实。业务信息库中的数据要求在存储后不能被修改和删除，将作为系统的原始凭证被永久保存。从时效性和实际业务需求启程，业务信息库至少也要保存50年之内在线业务操作及结果数据。医疗机构内部的业务数据分布于不同的信息系统自身的数据库之中，因此需要接入到覆盖整个医疗机构的信息平台上，以供应对原有业务数据的整合、利用效劳，并为机构之间以及业务系统之间的联动供应支持。业务系统通过设置交换信息库作为和信息平台的接入端代理，来实现业务系统和信息平台的互联互通性。体此时此刻数据构造层面，就是业务信息库通过交换信息库实现数据的接入。除了在信息平台上保存即时产生的，符合临床诊疗要求的各种业务原始数据以外，还须要以患者的根本信息为根底，整合患者历次就诊的就诊履历，完善患者的医院电子病历。患者的根本信息保存在根底信息库中，电子病历保存在临床文档信息库中，也就是说，业务信息库依据根底信息库中的患者信息进展整合，并最终形成存储在临床文档信息库中的电子病历。交换信息库交换信息库是信息平台的数据转换枢纽，包括中心交换库和对外交换库。中心交换库的作用主要是对医疗机构内部信息系统业务数据的采集、整合以及医疗机构内部信息系统之间业务联动。对外交换库的作用主要是实现医院信息平台和区域信息平台的数据交互。中心交换库考虑到医疗机构各个信息系统相对的独立性以及数据之间的关联性，我们在医院信息平台中设立中心信息交换数据库。中心交换库是采集医院各个业务信息系统的信息，并整合程电子病历信息的区域，也是各个业务信息系统根底信息和专业信息交换的信息存储区域。中心交换库存放各个信息系统交互的信息，包括了电子病历信息、根底信息〔患者根本信息、医疗人员信息等〕、专业信息〔医疗业务、临床数据、检验检查报告以及影像数据等〕。对外交换库对外信息交换库是医院信息系统和区域卫生信息平台进展数据交换的信息存储区域。为保证系统的相对独立，我们设立对外信息交换数据库。对外交换库存储要推送到区域卫生信息平台的电子病历，同时也存储着从区域平台推送来的安康档案。在对外交换库中完成电子病历和安康档案的相互转换。临床文档库(CDR)电子病历存储效劳详细由临床数据存储库CDR(ClinicalDataRepository)来实现。电子病历主要由临床文档组成，临床文档是电子病历中各类业务活动记录的根本形式。临床文档中的数据存在着必需的层级构造关系，其中有包含和被包含的关系，也有按同类属性相互嵌套的关系。临床文档的构造化和标准化，是电子病历实现语义层数据交换和共享的根本要求。CDR是医院为支持临床诊疗和全部医、教、研活动而以病人为中心重新构建的新的一层数据存储构造。它应当是物理存在的，而不仅仅是概念存在或者是逻辑存在。它是医院基于电子病历的信息平台的核心构件。它是否存在可以作为医院是否拥有真正电子病历系统的标记。它和干脆支持医疗操作的前台业务信息库不同，其数据来自这些业务系统，但和前台业务流程无关。它也不是通常意义上的数据仓库，因为它的内容是随着医院业务活动动态变更的，并且干脆支持医生/护士对病人临床记录的实时应用。CDR独立存在主要用于实现：1、和困难的业务处理流程分割病人的临床信息来自医院现已存在的多种多样的应用系统。一般说来，它们是面对应用过程设计的，是由不同供应商供应的，具有不同的信息模型和软硬件平台，其功能必需满意管理和临床应用不同的过程要求，例如一个试验室系统。从医生开出医嘱，到条码打印和取得样本，样本传送和承受，上化验设备，化验过程的双向限制，化验结果的自动获得，报告的产出和确认，报告的发出和承受的确是特殊困难的。应用系统的数据构造设计必需满意这些要求，数据库内的化验结果表达势必是困难多变的。而电子病历仅仅关切化验报告的最终结果。因此，假如CDR仅仅保存从检验系统传递来的化验结果，那么电子病历系统就可以和复杂的业务处理流程相分割。假如电子病历系统中的化验结果要从检验系统中干脆获得，就不得不关注上述的全部微小环节。2、透亮、一样化的数据模型CDR的独立存在使得一个统一的、透亮的、一样化的电子病历信息模型的设计和实现成为可能。这样一个模型的存在对全部应用系统的开发商、对系统集成、对医生护士对病人信息的进一步应用都特殊重要。3、应用系统升级简洁由于CDR和困难的业务处理流程相分割，使得以后各应用系统〔POS〕的升级换代变得简洁易行。而这种变更随着业务流程的变更和信息化水平的提高，是经常发生的，也是医院信息化开展进程中最让人头痛的问题。4、对医生/护士更友善，效率更高医生/护士运用物理上保存的以病人为中心的电子病历记录比起运用分散在不同应用系统中的病人记录来更得心应手、更符合他们的思维习惯，应答速度会更快。特殊是简洁、统一、透亮的信息模型的存在使得他们有可能依据自己临床工作的须要从CDR中剪裁出自己的病人临床记录子集。5、有利于电子病历深层次应用的开发推广电子病历的存在不仅仅是要满意临床信息查询的须要，更重要的是要满意临床决策、教学、科研的深层次的要求，例如警告和提示系统、临床路径限制、循证医学支持等等。这些应用的开发，当面对一个数据相对稳定、信息模型简洁清晰、和操作过程无关的存储库时，要简洁得多。特殊的，当效劳点应用系统(PointofService，PoS)发生变更时，也不会影响这些深层次的应用。临床数据中心构建方法广义的电子病历覆盖了患者过去、此时此刻、将来全部的医疗安康相关的数据，这些数据的生成和利用涉及到了整个医疗过程的各个环节。即使在一个医疗机构内部，电子病历也是往往建立在各类临床信息系统充分开展的根底之上，临床信息系统构成了电子病历的信息源。明显，一个共享的电子病历逻辑信息模型对于构建临床数据中心以及最终实现共享的电子病历来说都具有特殊重大的意义。目前，我国大多数医疗机构都已经在不同程度上实现了信息化，建成了各种不同规模的临床信息系统。在这种状况下，不变更各个已有系统的底层信息模型，接受仅在逻辑上集中的方案构建临床数据中心比拟具有现实意义。遵照这种方案，各种类型的电子病历数据仍由相应的临床信息系统负责管理和维护，保持原有的物理分布特性；在此之上，接受必需的技术手段将这些分散存储的数据在逻辑上集中起来，为上层的各种电子病历应用供应统一的数据访问接口，使得在这些上层系统看来，它们所面对的就是一个集中式的临床数据中心。为了实现对这些多模态电子病历数据的逻辑上的集中，通常有两种技术方案：基于面对效劳架构〔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〔含数据采集和数据发布查询更新〕，同时供应相应的适配器效劳来处理不同供应商系统和集成平台标准接口的数据交互。通过数据交换平台，使整个临床业务活动能基于医院集成平台更为充分的实现信息的共享和交换。实现各项临床业务活动在信息运用层面上最大程度的业务协同。使实际临床业务工作在充分的信息利用条件下实现提高业务效率、削减临床过失、降低业务本钱、提高临床效劳满意度。通过开放平台供应的标准化接口，帮助第三方供应商通过运用和组装平台接口及第三方效劳接口产生新应用，允许第三方实现扩展应用功能，同时供应统一便捷的接入方式保证新应用基于平台环境的统一管理和运行。ESB〔EnterpriseServiceBus，企业效劳总线〕是传统中间件技术和XML、Web效劳等技术结合的产物。ESB供应了网络中最根本的连接中枢，是构筑企业神经系统的必要元素。企业效劳总线ESB就是一种可以供应牢靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web效劳标准和和公认的牢靠消息协议接口。ESB产品的共有特性包括:连接异构的MOM、利用Web效劳描述语言接口封装MOM协议，以及在MOM传输层上传送简洁对象应用协议(SOAP)传输流的实力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现干脆对等沟通。ESB接受了“总线”这样一种模式来管理和简化应用之间的集成拓扑构造，以广为承受的开放标准为根底来支持应用之间在消息、事务和效劳的级别上动态的互连互通。ESB是一种在松散耦合的效劳和应用之间标准的集成方式。它可以作用于：面对效劳的架构－分布式的应用由可重用的效劳组成面对消息的架构－应用之间通过ESB发送和承受消息事务驱动的架构－应用之间异步地产生和接收消息应用集成管理效劳用于对各种根本效劳和应用程序进展统一的管理和监控。通过开放平台供应的标准化接口，帮助第三方开发者通过运用和组装平台接口及第三方效劳接口产生新的应用，允许第三方实现扩展应用功能，同时供应统一、便捷的接入方式保证新应用基于平台环境的统一管理和运行。应用集成管理效劳通过开放的合作方式，利用共享资源相互交换形成平台供应商及应用开发商的共赢，是实现平台应用丰富多元的重要根底，促进了平台产业安康开展的良性循环。主要功能和特点：开放式根底工作环境，通过可持续运营模式最大限度爱惜现有投资;供应实时预警方式确保平台应用不连续运行；支持电脑、手机、平板等多种终端设备，满意效劳供应方式的灵敏性；通过集成统一视图技术确保第三方应用的无缝快速集成；供应标准的开发支撑组件，有效支撑第三方应用供应商参和到医疗平台应用开发和持续性建立。数据交换层总线技术特点医院集成平台的数据交换效劳总线具有以下技术特点：SOA支持方面，遵循SOA设计原那么和技术标准，能够构建标准的企业效劳总线平台，供应松耦合模式，将业务逻辑和应用逻辑、数据逻辑等分别开，供应一个满意企业的应用集成和信息调解需求的解决方案；Web效劳支持方面，支持最新WebServices标准，包括SOAP1.1/1.2、WSDL1.1、MTOM/XOP、WS-IBasicPro等，支持WebServices自有的平安性WS-Security和寻址功能WS-Addressing，可以实现WebServices同步和异步不同形式的调用；智能路由方面，灵敏的消息路由方式，支持基于消息内容的处理和路由；而且还可以执行一系列方式的消息交互，包括了过滤、充溢、监视、分发、关联、拆分〔一对多〕和合成〔多对一〕等；XML格式转换方面，标准XML数据的格式转换，并且可以通过图形化映射组件、XSLT、等多种方式实现转换功能；非XML格式转换方面，非标准XML数据的格式转换，实现XML消息格式和其他数据格式之间的映射，同时也要支持自定义数据格式；发布/订阅方面，供应发布/订阅功能，支持队列和主题两种订阅模式，主题订阅模式支持树状构造，即支持多级主题模式，支持主题模糊的匹配方式，同时支持跨越多节点的发布订阅实力；图形化开发工具方面，供应图形化界面开发工具，实现简洁和困难的数据流程设计，供应图形化界面的数据映射和拖拽方式，以及配置功能的开发。供应多种内置功能组件和节点，功能涵盖协议接入、路由、转换、监控、例外处理等，同时要支持自定义的处理节点，供应多种编程语言的实现接口；通讯协议支持方面，供应牢靠的数据或消息传输，确保消息传输的最简化连接方式，支持灵敏和开放的协议支持，包括HTTP/HTTPS、JMS、、Socket、SMTP、SOAP/HTTP等；数据库支持方面，实现和关系数据库实现无缝的集成，同时支持JDBC和ODBC两种数据库连接方式，支持数据库要涵盖主流数据库；在数据交换和流转的过程中，支持业务逻辑中对不同数据库的存储操作，支持对不同数据库实现不同的用户和密码支持。管理方面，供应图形化性能监控工具，支持统计和分析的功能；性能方面，具备高性能处理实力，尤其对于XML数据的校验和解析、XSLT解析、非XML报文的处理、路由和过滤、数据库操作、WebServices调用等都要满意高性能要求，供应动态的缓存机制，保证数据能够在内存中最快速的处理；可用性方面，供应高可用性，保证平台7*24小时的运行；供应高稳定性，保证在数据量或应用连接数顶峰运行时的系统运行正常，保障许久化系统运行；平安性方面，供应多种平安机制，用户级别的认证、授权，支持标准的LDAP效劳器；访问级别的SSL传输机制；数据内容级别的数字签名等机制。数据交换总线功能特点医院集成平台的数据交换效劳总线具有以下功能特点：数据汇总支持各个分支数据源汇总数据到数据中心。采集公共数据的过程可以看成是一个数据汇总的过程，通过信息共享交换平台将各业务部门的公共数据采集回来，聚集到数据中心的缓存数据库。经过数据管理系统的比对、校验、转换得到一样的数据。数据分发数据分发是从数据中心的角度，主动向各数据运用方供应数据的过程。通过公开数据效劳，依照数据运用权限的规那么，从数据中心把数据分发到各个数据运用部门，实现数据共享、信息联动。数据存取访问信息共享交换平台供应实时按需的数据存取访问效劳，通过统一标准的数据接口，以XML作为标准数据格式，通过标准的Web效劳对各种技术平台供应访问支持。优化业务流程实现利用现有的软件系统，通过集成平台产品，重新组织医院的业务流程和工作流，配置业务规那么，包括可能跨跃不同的软件系统的业务流程整合。各个系统和平台的平滑连接、各个子系统之间数据平滑流转、各个系统工作站功能整合〔病人主索引、分布式资源索引、综合统计报表编辑和发布平台、数据仓库和数据挖掘的、内部网络查询和管理综合门户、基于全部系统的人员及部门权限管理、平安管理等〕,业务流程定制提高了系统的灵敏性和适应性，确保了整个业务系统能够很快的适应实际业务流程的变更，为医院将来业务开展供应支撑。数据转换数据交换效劳可以把某个数据库的数据转换成标准XML数据集。通过数据转换模块，实现对各种异构数据转换到统一标准标准、具有一样性和完整性的公共数据。任务定制数据接口系统应当允许用户自己配置和管理相关的效劳，如：数据提取效劳、数据发送效劳、数据接收效劳、数据存储效劳等。支持用户自定义数据接口系统应当是一个开放的系统，要供应一些可扩大的接口以及二次开发接口，支持用户基于这些接口来定义自己的特色效劳。支持业务行为监控能实时掌控整体业务运行。能够对关键的业务行为以及相关的事务做出实时反响，以及自动反响并执行分支业务流程。支持平台监控管理对数据效劳进展监控管理，用户权限管理，运行日志查看，性能统计。通过数据效劳日志可以记录、跟踪数据交换的微小环节。对数据交换节点进展管理，供应平安策略指南、效劳器平安管理配置。基于数据交换效劳总线的业务数据交互应用集成管理效劳用于对各种根本效劳和应用程序进展统一的管理和监控。通过开放平台供应的标准化接口，帮助第三方开发者通过运用和组装平台接口及第三方效劳接口产生新的应用，允许第三方实现扩展应用功能，同时供应统一、便捷的接入方式保证新应用基于平台环境的统一管理和运行。应用集成管理效劳通过开放的合作方式，利用共享资源相互交换形成平台供应商及应用开发商的共赢，是实现平台应用丰富多元的重要根底，促进了平台产业安康开展的良性循环。通过统一的业务交换效劳平台标准，可以实现以下业务数据交互：支持集团化医院业务，解决各成员医院间的远程数据交换，主要包括病人档案信息共享、病人诊疗信息共享、跨院检验检查、药品、易耗品等物资一体化功能。HIS和检验系统信息交互，通过业务效劳平台获得检验单据信息、患者住院信息、病历信息，记录完整的检验单据处理过程，标本送检过程处理和单据费用自动处理，检验报告构造化存储，实现多系统统一的报告调阅接口；HIS和医技检查系统信息交互，放射检查、病理检查、心电、B超、内镜检查业务通过业务效劳平台获得检查单据信息、患者住院信息、病历信息，记录完整的检验单据处理过程，检查图文报告构造化存储，实现多系统统一的报告调阅接口；并支持统一影像阅读及处理。HIS和电子病历系统信息一体化，完善以电子病历为中心的临床信息系统，供应电子病历分级评价标准实现。临床路径信息查询,可通过数据交换效劳总线，实现路径表单、知情通知书、路径评估单等信息查询。建立多途径的消息机制，实现各系统间关键医疗信息自动提示〔如急诊异样报告〕、预警功能；字典同步：同步各系统间的根底字典〔如科室、员工字典〕，歼灭重复数据。和区域市民安康档案标准化无缝对接，实现区域市民安康一卡通、双向转诊、远程医疗、检查检验结果互认、预约诊疗、区域卫生安康门户等区域卫生信息共享和协同效劳应用；

跨医院信息交换平台伴随着医院集团的出现，医院信息系统的集团化成为新时期的医院信息系统建立的重要方向，为了使浩大而又分散的经营体系内部的各类机构能步调一样，有效地运转，集团总部及各成员医院都需建立相应的信息系统，并用远程通讯网络将整个集团构成一个有机的整体，大型的医院集团假如没有一个强健的电脑化集团信息系统，就难以实施有效的管理，也就难以获得经营的效益。集团化医院较之单体医院的最大特征在于资源在必需程度上实现了共享，但目前大局部的集团化仍未到达充分的资源共享，比方：集团下属各家医院一般都有独立运用自己的LIS系统，LIS数据仅存在本医院内部，当病人跨院就诊时，往往须要重新检验，造成大量的人力、财力的奢侈。因此，集团化医院信息系统的一个根本任务在于解决各成员医院间的远程数据交换，主要包括病人档案信息共享、病人诊疗信息共享、跨院检验检查、药品、易耗品等物资一体化功能。通过在总院建立中心数据共享平台，中心数据共享平台依据须要通过各医院的子系统收集并存储患者信息，全部授权和整合的医院都可以访问。这样资源和患者能够有效地在各个医院之间流淌，各家医院之间的报告信息、设备、人才可以共享，报告结果互认，当病人跨院就诊时就不再须要重新检验，幸免了人力、财力的奢侈，便利了患者，提高了效劳质量，必需程度上缓解了“看病难、看病贵”的问题。4.5公共消息效劳平台医疗数据交换效劳主要用于实现医疗信息系统之间的消息路由、过滤和转换。通过该效劳可以将异源异构系统的信息，遵照“以病人为中心”的原那么进展数据的交换和共享。医疗数据交换效劳支持多种技术环境下的数据交换，支持多种传输协议和数据库读写方式，并支持多种数据传输格式，同时，在系统数据未遵循相应传输格式的状况下，供应发送、接收、组装和解析该格式消息的适配功能。集成平台消息总线主要是为了连结HIS不同业务系统，供应统一标准的数据接口来进展信息互联互通，集成平台外部系统都通过标准接口发布和接收消息，一般不允许干脆读取消息数据集。消息处理效劳接口基于数据库和.Net的内部实现，内部核心组件引入业界通用的互联互通消息沟通产品，且支持HL7消息引擎。可扩展标记语言(ExtensibleMarkupLanguage，XML)目前正在成为各种数据特殊是文档传输的首选格式。运用它，就可以简洁定义一样的数据格式和传送数据，包括HL7V3，MML协议也都是以XML语言为根底。医院信息集成平台的消息交换标准框架应具备以下特点：共享语义和内容构造两个应用程序之间为了通信，必需共享数据构造。例如，假如一个应用用单个字符串处理一个病人的地址，另一个应用程序用街道、城市、州、国家来处理地址，这两个应用程序很难进展通信。消息模型须供应规那么化的方法，保证唯一的语义和内容构造，当两个应用程序关于通信地址进展通信时，它们针对以下内容达成一样：含义、包含的数据、和其它概念的相关关系。构造可扩展XML是可扩展的。消息效劳架构须保持这种可扩展性，用户可以利用根本内容并且扩展、客户化这些以使它支持它们的需求。 数据交换可监控假如只是简洁地容纳外部协议的数据格式进入总线进展数据交换，那么对中心监控来说，由于协议之间的差异，对每一种数据交换协议产生的离散的数据内容，都要定制相应的监控程序，这将大大增加数据中心的困难度和维护本钱，并由于多重监控的系统资源消耗，将紧要地影响中心数据交换吞吐量，在实际应用中是不行行的。只有基于统一的总线数据协议，才可能对日常交换的数据进展监视和限制，才可在中心进展消息过滤，平安限制等困难操作。集成平台消息效劳由以下两个根底功能部件组成：支持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〕将各个效劳之间的接口逻辑标准、简化到和总线的一套接口逻辑上来，