集成平台技术需求方案.docx

集成平台技术需求方案.docx

《集成平台技术需求方案.docx》由会员分享，可在线阅读，更多相关《集成平台技术需求方案.docx（15页珍藏版）》请在冰豆网上搜索。

集成平台技术需求方案

1、建设思路

1.1基于信息平台的业务整合与数据共享机制

医疗健康信息服务平台是一个集成各类应用系统以及日常运营的平台，实现信息的整合再利用，在此平台之上可有效整合医院内部业务应用系统，最终形成一个互联互通的医院业务协作网络。

医疗健康信息平台是为医疗行业特别量体定做的，可以很好支持不同系统之间的医疗数据的整合，快速实施应用程序节点部署以及各医疗子系统之间的协同通讯。

在医院信息系统中的各子系统中，比如HIS、LIS、RIS、OA等，传递和展现整个医疗过程中的相关信息。

通过医疗健康信息服务平台建设，一方面可以规避“点对点”式的信息共享与交换，并使得医院可以基于信息平台整体上进行业务管理，对内提高管理水平，对外以统一的方式接入区域卫生协同网络，更好地为患者健康服务。

1.2以电子病历为核心载体的患者诊疗数据集成与共享

电子病历是健康档案在医疗机构的特定表现方式，标准化的电子病历是区域卫生信息化和健康档案建设的关键问题。

医院信息系统是从简单的收费系统发展起来的，电子病历是医院信息系统进入临床信息发展阶段的产物。

在区域卫生信息化的要求下，必须达到以患者个人健康档案为主线的临床信息共享，新一代医院信息系统建设就必须以电子病历为核心，全面疏理医院的各个业务与管理流程，使之满足医院内部的信息资源共享需要，还要满足区域医疗业务协同的需要。

以电子病历为核心载体强调以病人为中心，将病人全部的诊疗资料以统一的形式组织起来，通过医疗健康信息平台以统一的方式向外展示，并使之成为电子健康档案的有机组成部分，形成以电子病历基本架构与数据标准为基础的病人诊疗数据标准化、规范化共享与利用。

医院管理分为医疗管理与运营管理。

医疗管理通过对医院诊疗活动各个方面的直接与间接管理来保障临床服务工作的质量；而针对医院人、财、物的运营管理是为医院临床工作进行后勤保障工作的，其最终目标依然是为临床服务的。

医疗管理与运营管理需要同临床服务交换各类数据，以实现相应的管理目标，促进临床服务质量的改善。

在这个过程中，需要交换的数据种类繁多，几乎涵盖医院信息系统的各个部分，因此基于统一的医疗健康信息平台的数据交换与共享机制是实现这类需求的有效手段。

1.3通过消息驱动的医院业务流程整合与再造

在完成数据整合的同时，医院管理与医疗服务在业务流程上也需要有机地结合起来，才能提高信息的利用价值。

例如，药品从采购到患者服用是一个逻辑非常严密的过程，流程上的差错有可能最终导致医疗差错甚至是医疗事故的发生。

因此，如何将医院管理与临床服务的业务流程有机地结合起来，建设这两方面工作的协同机制，是医疗健康信息集成平台的核心目标之一。

通过消息驱动的医院业务流程整合与再造，就是要在各个异构系统的不同模块之间，建立消息通道，通过统一的消息机制来控制数据的流传路径、系统权限和界面执行，消弭个异构系统间的通讯障碍。

2.平台主要技术路线

医疗健康信息服务平台的实现既要考虑适合于现有需求，又考虑未来发展的总体技术要求，从而保证系统的可持续发展的需求。

医疗健康信息服务平台采用面向服务的体系结构（SOA+WebService）的总体技术路线。

依赖由SOA和WebService组成的总体技术路线，为医疗健康信息平台及应用实现提供技术支撑。

其中所涉及的主要技术如下描述：

2.1SOA架构

SOA（Service-OrientedArchitecture），面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

SOA可以看作是B/S模型、XML/WebService技术之后的自然延伸。

SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

2.2ESB服务

ESB（企业数据总线）具有以下的一些特点：

满足大量应用的需要；运行于多种硬件和OS平台；支持分布式计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能；支持标准的协议；支持标准的接口。

程序员通过ESB实现异构环境的通讯，从而屏蔽异构系统中复杂的操作系统和网络协议。

针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。

由于标准接口对于可移植性和标准协议对于互操作性的重要性，ESB已成为许多标准化工作的主要部分。

对于应用软件开发，ESB远比操作系统和网络服务更为重要，ESB提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将ESB升级更新，并保持集成交换工具对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。

ESB是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。

ESB在分布式服务之间扮演着承上启下的角色，如事务管理、负载均衡以及基于Web的计算等。

利用这些技术有助于减轻开发者的负担，使他们利用现有的硬件设备、操作系统、网络、数据库管理系统以及对象模型创建分布式应用软件时更加得心应手。

由于集成交换工具能够保护企业的投资，保证应用软件的相对稳定，实现应用软件的功能扩展；同时ESB产品在很大程度上简化了一个由不同硬件构成的分布式处理环境的复杂性，所以它的出现正日益引起用户的关注。

2.3WebService技术

WebService是解决程序之间互相通信的一项技术。

严格地说，WebService是描述一系列操作的接口。

它使用标准的、规范的XML描述接口。

这一描述中包括与服务进行交换所需要的全部细节，包括消息格式、传输协议和服务位置。

而在对外的接口中隐藏了服务实现的细节，仅提供一些列可执行的操作，这些操作独立于软、硬件平台和编写服务所用的编程语言。

WebService模型的解决方案中共有3种工作角色，包括服务提供者、服务请求者和服务注册中心。

它们之间的交互和操作构成了WebService的体系结构。

服务提供者定义并实现WebService，然后将服务描述发布到服务请求者或服务注册中心;服务请求者使用查找操作从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用WebService。

图

（一）-1WebService模型的3种角色及它们之间的操作关系。

要实现互操作性，WebService平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。

目前这些协议有：

SOAP：

即简单对象访问协议（SimpleObjectAccessProtocol），它是用于交换XML编码信息的轻量级协议。

它有三个主要方面：

XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用（RPC）的约定。

SOAP可以运行在任何其他传输协议上。

例如，你可以使用SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。

在传输层之间的头是不同的，但XML有效负载保持相同。

WebService希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

WSDL：

WebService描述语言WSDL　就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述WebService及其函数、参数和返回值。

因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

UDDI：

UDDI是一套基于Web的、分布式的、为WebService提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的WebService注册，以使别的企业能够发现的访问协议的实现标准。

2.4XML技术

可扩展的标记语言（XML）是Webservice平台中表示数据的基本格式。

除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。

无关性是比技术优越性更重要的：

软件厂商是不会选择一个由竞争对手所发明的技术的。

XML可以存取多种数据源，根据具体的应用，大致可以分为下面三种：

一种是XML纯文本文档，第二种是关系型数据库，第三种则来源于其他各种应用数据，如邮件、目录清单、商务报告等。

其中，第一种来源，即XML纯文本文档是最基本的也是最为简单的，将数据存储于文件中，其最大的优点在于可以直接方便地读取，或者加以样式信息在浏览器中显示，或者通过DOM接口编程同其他应用相连。

第二种数据来源是对第一种来源的扩展，其目的是便于开发各种动态应用，其优点则在于通过数据库管理系统对数据进行管理，然后在利用服务器端应用进行动态存取。

这种方式最适合于当前最为流行的基于三层结构的应用开发。

第三种数据由于来源广泛，因此需要具体情况具体对待。

数据接口是连接业务部门内部的MIS系统和数据交换平台的“桥梁”，而各业务部门之间的数据交换主要是以文件形式存在的。

因此，数据中心应用XML技术存取的数据源主要为前两种，即XML纯文本文档和关系型数据库。

数据接口通过XML的数据解析，将各业务数据库中的数据生成XML纯文本文档，再经过数据交换平台进行传递。

2.5跨数据库设计

由于医疗数据具有法律效应，对安全性要求非常高，和传统数据库应用中的普通数据，有非常大的差别，因此，在数据存储方面，不能够按照传统数据管理和应用的模式进行管理。

在平台设计必须支持各种主流数据库系统的应用，由系统提供的脚本文件可以自动生成支撑平台运行的数据库系统。

主流的数据库系统包括：

Oracle，SQLServer，DB2等。

平台的数据库模型设计独立于特定的数据库产品，我们通过xml技术实现跨数据库，平台数据可通过数据传输工具实现在不同数据库间的迁移。

保证了数据存储的独立性和灵活性。

2.6Portal

portal是一种web应用，通常用来提供个性化、单点登录、聚集各个信息源的内容，并作为信息系统表现层的宿主。

聚集是指将来自各个信息源的内容集成到一个web页面里的活动。

3.平台设计特点

（1）遵循国家最新标准和规范，包括但不限于：

卫生部最新发布的《电子病历基本架构和标准》、《基于电子病历的医院信息平台建设技术解决方案》以及卫生部《电子病历管理办法》。

（2）基于数据映射的异构数据集成机制，适应国内目前医院信息化数据标准尚未完全统一的现状，可自动进行数据采集、清洗、映射和格式转换，不需要第三方系统修改程序，极大地降低了实施阻力和项目风险。

（3）形成从医疗、服务到管理的立体纵深网络，各类数据实现规范化、标准化管理，实现多维度的数据分析统计，为医院的管理决策提供支持。

（4）不仅是为了医院各应用系统的互联互通、资源共享，同时基于组件的设计，可以支持快速、流畅、高效地构建新的应用系统,从而缩短新系统的建设周期，降低建设成本，保障系统质量，促进医院信息化建设的健康、可持续性发展。

（5）自主研发的集成交换工具，能够适应国内医疗信息化行业的现状及发展需求，能够根据医院的实际情况进行个性化的定制开发。

4.基础平台建设

医疗健康信息服务平台作为医疗行业的一个应用集成平台。

该平台以无缝的分层的体系结构为医院提供数据及应用程序的集成，它将推动基础设施技术的进步，以灵活可靠的基础设施代替点对点的接口开发，形成全面的集成解决方案，连接应用程序、数据库和其他系统，例如：

HIS、LIS系统（实验室系统）、PACS、财务系统，通过集成不同的信息标准，如XML技术，HL7和电子数据交换，这种多样性使得该平台成为与第三方业务软件相连接。

4.1基于ESB服务的集成平台

集成能力是医院信息平台必备的核心能力，为了降低集成的难度和管理的复杂度，采用专有的医疗信息集成平台来解决国内医院系统之间的集成问题。

医疗健康信息平台要基于SOA思想，能够以SOA的方式将医院的各个业务系统集成在一起，具备面向服务、面向消息、事件驱动的特性，是一个在SOA架构中充当服务间智能化集成与管理中介的灵活敏捷的基础平台。

通过专有的医疗信息集成平台针对目前国内的系统不标准、异构度高、医疗健康信息平台实施难以落地等实际现状，实现学校医院应用系统所需的所有同第三方系统集成的接口，均建立在该集成平台上。

在项目实施中尽量避免修改原有各个软件系统中的任何部分，包括数据库结构、应用程序代码等。

全部采用SOA架构重新进行抽象和封装。

4.1.1设计概述

在目前的市场上，主要有两种技术方式来实现集成平台的各项服务于应用。

一是基于ESB（什么是ESB，就是企业数据总线的意思，他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换）、二是基于服务注册（什么是服务注册，就是将所有的服务接口注册到一个中心的分布式服务集群上，各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用）。

两者之间的优缺点对比：

ESB一般采用集中式转发请求，适合大量异构系统集成，并且压力不大的情况。

（代表性的项目有：

JBOSSESB,Mule,Camel以及一些其他的esb项目）

服务注册管理，采用的是分布式调用，注册中心只记录地址信息，然后直连调用，适合并发及压力比较大的情况。

（代表性开源项目有：

阿里的dubbo，淘宝的HSF）

从对比中可以明显看出，基于ESB适合大量异构系统的集成，便于业务编排等应用，但并发压力相对较弱。

服务注册管理在业务编排和协议转换方面需要靠底层系统改造，但能够承受较大的并发压力。

综合上述的情况及根据医疗行业的特性，首先医疗行业在并发处理上面相对较小，与淘宝之类的并发量是不能一提的，另外医院系统众多、在集成时应尽量避免底层系统的接口改造，应该做到快速部署、快速集成的理念。

因此，综合上述情况，构建基于ESB服务的集成平台，能够为学校医院实现个性化需求、二次修改、共同开发等提供快速的响应。

基于ESB服务的集成平台，与相关在医疗市场上推广的国外产品相对比，厂商自主开发的平台公用服务将能够为学校医院未来的发展带来以下更好的帮助：

自主开发的平台公用服务

通用中间件

标准适应性

基于国内十年的行业服务经验，能够适应国内医院的标准现状，尤其在应对中文病历的标准化处理方面有独特的建设之道

很难适应国内的标准，即使医院今后系统可能会按照标准去建设，但是在处理中文的能力方面，通用中间件也是束手无策。

紧密程度

可根据医院的实际业务要求进行个性化改造、个性化定制实现等方面的支持

通用的中间件的源代码是基本不开放，这也导致不能够很好的去实现医院后续多元化的业务要求（公共服务）

安全性

厂商需为国内相关政府部门重点扶持的科技企业，自主开发的平台公用服务的相关产品能够符合国家的战略发展要求，是政府大力的扶持自主创新科技企业，厂商所提供自主开发平台公共服务得到了国家科技主管部门的测评与鉴定

在国务院关于印发《国家知识产权战略纲要》中“（16）以国家战略需求为导向，在生物和医药、信息、新材料、先进制造、先进能源、海洋、资源环境、现代农业、现代交通、航空航天等技术领域超前部署，掌握一批核心技术的专利，支撑我国高技术产业与新兴产业发展。

”政府在医疗上面也是鼓励国内的自主产权。

通用的中间件相应的核心技术、数据安全等方面主要在国外的部分公司手中，尤其在医疗领域中，医疗数据的安全尤为重要。

因此，从长远发展角度来看，并不适合。

4.1.2框架设计

在医疗健康信息平台建设中，医用信息集成平台作为信息系统和平台应用的中间层，原封不动地保持医院业务系统，不需要进行改造，减少集成难度。

集成平台和业务系统之间是相对独立的，如果需求发生改变，那么只需要修改平台的一些相应配置，这样可以最大限度地减少开发成本和延长医院业务系统生存周期。

图

（一）-1集成平台框架图

（6）消息格式定义

在集成平台中预定义数据结构的XML文档架构，从而规定了输入端口接受的消息实例类型，外部应用程序输入消息的数据类型。

平台接收端口将根据该文档建构，验证上传的XML文档是否符合配置架构，如果非法，返回相应的错误信息。

（7）流程编排

通过医疗健康信息服务平台的BPM流程管理，在医院内各个业务系统之间建立起符合真正业务需求的流转关系。

集成平台在基于安全、稳定、可靠的一次性不漏、不重、不丢、不错的数据传输的前提下，通过引入流程引擎，以流程化的方式进行数据路由规则的订制，使业务逻辑和集成逻辑分离解耦，大大提高了整个平台的可扩展性。

当需求发生变化的时候，不再需要厂商、集成商的参与，用户自身就可以根据新的需求进行调整。

（8）消息生成

医疗健康信息服务平台其核心是基于消息机制实现业务系统之间的应用集成，通过平台来监控业务系统产生一些消息通知，这些消息通知也是通过消息交换中心来进行统一管理，通过各个软件系统响应各种消息通知来达到业务协同的效果。

消息服务于第三方软件的接口有两种方式：

一种是Web服务方式，即提供封装了标准接口的Web服务供第三方软件调用，这种方式要求第三方软件增添接口代码，好处是运行效率高；另一只方式是轮询第三方系统数据库相关字段形成中间表，通过监测中间表来触发消息，好处是第三方系统无需修改代码，弊端是对硬件网络资源的消耗有所增加，但是可控。

实际应用中，上述两种接口方式根据具体情况混合应用将达到最佳效果。

（9）消息映射

信息映射主要是解决系统之间数据格式不一致问题，即将从各业务系统数据库中所提取到的数据信息转换为标准XML结构形式。

通常，数据库中的关系数据到XML文档的映射规则为：

表—元素、列—属性或子元素、值—属性值或子元素值。

通过使用元素标记和属性标记，使XML文档的内容具有可识别性。

元素标记和属性标记是集成平台统一定义的，他们的描述都存放在Schema文件中。

元素标记和属性标记在XML文档中呈<>和配对出现。

例如下图所示，对于一个人员的描述，在业务数据库中表名、字段名和集成平台数据库中都不一样，需要把它们一一对应起来。

AESB提供“字段影射”适配器，通过配置的方式，解决部门业务数据库和前置数据库之间表名、字段名不一致的问题。

（10）XML封装、解析

XML封装器：

对数据按照一定转换而成的XML文件，采用SOAP格式进行封装，同时在SOAP头中加入相关的属性，例如数据类型和身份认证信息等。

XML解析器：

分析XML文档的语法和格式是否正确，这里需要用到XML的一个关键技术：

XMLSchema，利用此技术我们可以严格检查接受的XML数据，确保在传输过程中没有数据丢失和错误。

（11）信息传输

通过HTTP协议传输SOAP消息，按照流程编排BPM中的定义将消息发送到不同系统。

（12）信息队列处理

把通过验证的XML文档送入处理队列，等候系统进行进一步存储处理，该队列对于信息交换相当于一个缓冲器，起到一个数据缓存和系统运行能力调节的功能。

4.2平台基础组件

4.2.1注册服务

注册服务应包括对患者、医疗服务人员、医疗卫生机构（科室）、医疗卫生术语和字典的注册管理服务。

平台应对这些实体提供唯一的标识。

针对各类实体形成各类注册库（如患者注册库、医疗服务人员注册库、机构注册库、术语和字典注册库）。

（13）个人注册服务

个人注册服务用于对前来医院就诊患者的基本信息进行管理。

通过对个人基本信息的统一管理，实现对个人信息最完整的保存，可以为医疗健康信息平台上的各应用系统提供一致的个人信息。

基本功能包括：

♦具备新增个人注册功能；

♦具备个人信息更新功能；

♦具备个人身份失效功能；

♦具备个人身份合并功能；

♦具备个人信息查询功能。

（14）医疗卫生人员注册服务

医疗卫生人员注册服务用于对医疗卫生机构内部所有医疗服务人员的基本信息进行注册和管理。

医疗服务人员包括医生、护士、医技人员、药事人员等全部提供医疗卫生服务的医务人员。

通过对医疗卫生人员基本信息、专业信息的管理，可以为医疗健康信息平台上的各应用系统，提供完整、统一的医疗卫生人员信息。

基本功能包括：

♦具备新增医护人员注册功能；

♦具备医护人员信息更新功能；

♦具备医护人员身份失效功能；

♦具备医护人员身份合并功能；

♦具备医护人员信息查询功能。

（15）医疗卫生机构（科室）注册

医疗卫生机构（科室）注册用于对医疗卫生机构（科室）的基本信息进行管理。

通过对医疗卫生机构（科室）基本信息的统一管理，可以为医疗健康信息平台上的各应用系统、患者提供完整、统一的医疗卫生机构（科室）信息。

基本功能包括：

♦具备新增医疗卫生机构（科室）注册功能；

♦具备医疗卫生机构（科室）信息更新功能；

♦具备医疗卫生机构（科室）停用功能；

♦具备医疗卫生机构（科室）信息查询功能。

（16）术语和字典注册

术语和字典注册用于从数据定义层次来解决各系统的互操作问题。

术语和字典的范围包括医疗卫生领域所涉及到的各类专业词汇，以及所遵循的数据标准。

建立术语和字典注册库，用来规范医疗卫生事件中所产生的信息含义的一致性问题。

术语应由平台管理者进行注册、更新和维护。

字典既可由平台管理者又可由机构内各应用系统来提供注册、更新和维护。

基本功能包括：

♦具备术语和字典的批量导入导出功能；

♦具备术语和字典的分类浏览功能；

♦具备术语和字典的关系维护功能；

♦具备术语和字典的版本管理功能；

♦具备术语和字典的映射关系维护功能；

♦具备向其他系统同步术语和字典功能。

4.2.2配置管理

医疗健康信息平台通过组件都实现医院所有业务流程和事务的灵活定制，在配置管理方面实行统一配置统一管理。

（17）用户管理

能过机构/用户管理可以规范用户对集成平台的使用行为，可以根据用户的组织机构设置相应的用户组和对应的用户。

用户管理应该能够对用户进行全面的管理，包括用户组的增加、修改和删除；用户的增加、修改和删除；用户与用户组之间的对应；以及其于角色的权限管理安全可靠的密码管理功能。

（18）权限管理

在集合平台中权限管理至关重要，不同的用户具有不同的权限，使用不同的信息路由路径，对各应用节点的接口调用进行身份验证。

这样保证了系统的安全性、可靠性和稳定性。

系统应从不同的角度进行相应的权限管理，功能权限指对接入平台的各个应用以及功能服务的访问权限；数据集权限即数据项权限，是指用户对传输中的信息各数据项的访问权限；管理范围及记录权限，是作为共享数据信息内容的访问权限。

当用户所具有的信息，符合通过管理范围设定出的特殊匹配条件时，允许用户访问相应管理范围所规定信息内容；权限方案允许用户导出和导入。

便于权限管理信息的分发和设定；用户还可对自己相应的权限信息进行打印。

（19）节点管理

由于信息集成平台是一个复杂的、分布式网络结构，单靠人工进行管各个传输节点是很困难的一件事。

当前的网络系统中都有哪些节点，它们运行状态如何，有哪些是新增加的节点，是否有非法节点加入都是难于解决的问题。

因此，系统必须引入节点管理功能。

它通过配置各个节点的参数和属性，构建整个数据交换环境。

在监控端，以图形方式显示所有的网络段和节点并自动检测各个节点的状态，使管理人员能够一目了然地发现问题节点。

（20）密钥管理

在数据交换过程中，数据文件发送和接收双方都需要对对方的密钥进行认证，以保证数据的防抵赖、防否认和防篡改。

安全、周密、有效的对密钥进行管理是数据交换安全设计的一个重要方面，通过对各种密钥进行管理，能够确保整个数据交换系统的安全。

（21）日志审计

为了更好的使系统管