CN101340448A

CN101340448A - 一种面向数字家庭的医疗数据集成方案

Info

Publication number: CN101340448A
Application number: CNA2008100286111A
Authority: CN
Inventors: 余元龙; 罗笑南; 陈钦基; 卢林发
Original assignee: ZHONGSHAN IKER DIGITAL TECHNOLOGY Co Ltd; ZHONGSHAN AIKE DIGITAL TECHNOLOGY Co Ltd
Current assignee: ZHONGSHAN IKER DIGITAL TECHNOLOGY Co Ltd; ZHONGSHAN AIKE DIGITAL TECHNOLOGY Co Ltd
Priority date: 2008-06-10
Filing date: 2008-06-10
Publication date: 2009-01-07

Abstract

本发明主要针对数字家庭在医疗信息服务方面的空白，提出一套面向数字家庭的医疗数据集成方案，该方案能够在不对现有各医院信息***进行大改造的情况下实现对医疗数据的有效集成。本方案通过在各医院设置一个通用接口服务器***来屏蔽各个医院信息***的异构性，而其中对医疗数据的集成和交换主要由部署在该接口服务器上的消息中间件来完成。该消息中间件根据功能特点可以划分为六大模块，包括消息交换任务管理模块、消息构造模块、消息解析模块、消息传输模块、消息事务处理模块、数据库接口模块。

Description

一种面向数字家庭的医疗数据集成方案

技术领域

本发明涉及数字家庭中医疗信息服务的技术领域，具体地说，涉及一种数字医疗互动平台与各医院信息***的对接方案，该方案引入了消息中间件的方式。

技术背景

随着3C融合技术的发展，数字家庭的概念逐渐深入人心，数字家庭产业蓬勃的发展起来，它给人类带来了一种全新的生活和工作方式，在数字家庭中，人类的生活将会变得更加简单方便，更加人性化，从而使人类的生活品质得到极大的提高。

与此同时，数字化医疗也取得了一定的发展，在这个趋势下，在数字电视上开发一个数字医疗互动平台，该平台能整合各医院强大的信息资源，为病人提供如远程挂号，电子病例查询等服务，这对于丰富数字家庭的内容服务和提高数字医疗服务水平都具有重要的现实意义。

在数字医疗互动平台中，医疗数据信息主要来源于各医院信息***，如何有效地集成各个医院的医疗数据信息，建立平台与医院信息***的无缝连接，是实现该平台首先必须解决的关键问题。然而，各个医院的信息***可能由不同的厂商开发的，开发时并没有遵循统一的标准，所采用的***平台、***结构、数据接口定义等等都不尽相同，因此必须设计一种实现数字医疗互动平台与各医院信息***的对接方案，有效的实现对各医院信息***中医疗数据的集成。

虽然数字家庭是目前的热门方向，各界对其关注度很高，并且，对数字家庭方面的研究也出现了不少的成果，但大部分的研究主要涉及多媒体、网络、监控等各个方向，突出的关键词是娱乐与便利。然而，在数字家庭中，有关医疗信息服务方面目前基本上还是一片空白，本文提出的设计正好填补了这一空白。

发明内容

本发明主要针对数字家庭在医疗信息服务这方面的空白，目的在于通过引入消息中间件的方式来实现对各医院数据信息的有效集成。这种方案能够在不对医院现有信息***进行大改造的情况下，实现对医疗数据信息的集成，提高了开发的效率。

为了实现上述目的，本方案通过在各医院设置一个通用接口服务器***来屏蔽各个医院信息***的异构性，而其中对医疗数据的集成和交换主要由部署在该接口服务器上的消息中间件来完成。该消息中间件根据功能特点可以划分为六大模块，包括消息交换任务管理模块、消息构造模块、消息解析模块、消息传输模块、消息事务处理模块、数据库接口模块。

本发明的技术特点主要体现如下：

(1)基于中间件的方式解决平台与医院信息***的对接

中间件方式是通过提供一个全局模式和对应各数据源的局部模式集成来自不同数据源的数据，并经由一个数据转换接口将各数据源的数据转换为一个统一的规范格式，提供给用户使用。用户的查询是基于这个全局模式的，数据源仍然分布在各本地***中。中间层提供的统一的数据逻辑视图隐藏了底层的数据细节，用户不需要知道各数据的存储位置，数据格式与组织结构等方面的性质。

(2)根据平台的具体业务需求制定多种消息类型

对于消息中间件来说，一切数据的交换都是采用消息的格式进行，一切业务流程都是基于消息驱动的方式，因此该中间件根据具体的业务需求制定了消息格式和各种消息类型。

(3)重用性和扩展性好

由于消息中间件根据功能特点分解为六大模块，这种结构划分方式具有强内聚松耦合的特点，各个模块的功能划分得非常清楚。随着业务的扩展，只需要定义相应的消息，并在事务处理模块中添加相应的处理函数即可实现该消息业务。

附图说明

图1为医疗数据集成方案的架构图；

图2为消息中间件的模块结构图；

图3为消息解析模块的流程图。

具体实施方式

下面结合附图和实施实例对本发明做进一步的说明。

图2是面向医疗数据集成的消息中间件架构图，各个模块的主要功能和实现方式具体描述如下：

(1)消息交换任务管理模块

消息交换任务管理模块主要负责消息交换任务的发起和完成，主要包括消息的查询和响应，更新和确认。当消息交换任务管理模块接受查询或主动更新任务时，首先根据消息的类型，查找该类型对应的消息类型和其他相关数据信息，调用消息构造模块将数据信息转换为相应的XML消息，通过消息传输模块发送到其他***。反之，当***接收到相应的查询后，首先调用消息解析模块进行消息的有效性验证，并从消息中提取有关字段存放到相应的数据对象中去。如果消息不合法，则返回一个错误消息，如果消息合法，则根据消息的相关属性值将消息中附带的数据信息转发消息事务处理模块，由消息事务处理模块进行业务处理。

(2)消息构建模块

消息构建/解析模块的主要功能就是使消息交换任务管理模块能够通过其提供的API函数能够将应用程序数据转换为***间传输的消息。在消息构建时，需要根据消息的定义规则进行消息的有效性验证，主要是检验消息段的性质和字段性质是否和标准定义一致，其中消息段的性质包括定义顺序、消息段可以出现的次数；字段的性质包括字段的长度、数据类型、必选/可选性、可重复性、数据映射关系。

(3)消息解析模块

消息解析模块主要负责将接收到的XML消息进行解析，采用基于DOM模型的XML分析器接口。整个消息的解析过程如图3所示，首先是建立DOM解析器工厂，并创建DOM解析器实例，解析XML输入流得到一个XML树模型，接着按照广度优先的策略遍历树结点，根据每个节点的名称与属性，将其中的数据信息存放到数据对象中。其中，每个消息段的数据对应一个数据对象，并根据消息段名和对象名称实现动态绑定。

(4)消息传输模块

消息传输模块主要负责控制***间消息的传输。由于本发明中的消息采用XML格式进行封装，因此，消息传输采用与XML协议紧密结合的SOAP(SoapObject Access Protocol)，上层使用HTTP作为传输协议。整个消息的传输交换过程是首先客户端将xml消息封装为SOAP请求，SOAP请求消息借助HTTP传送到服务器端，服务器端通过DOM接口解析消息请求，并调用相应的service处理消息请求，并将处理结果以同样的方式传回到客户端，客户端再使用dom接口提取出其中有用的数据信息。

(5)消息处理模块

消息处理模块主要是负责对消息请求进行相应处理。在该模块中，对于每一条消息，根据消息的名称，设置一个与该消息名称相同的处理函数，在该函数中完成相应的业务操作。因此，消息交换任务管理模块可以根据消息名称调用该模块中相应的处理函数。

(6)数据库接口模块

数据库接口模块主要负责消息中间件与数据库的连接以及对数据库中数据的存取操作。可以使用JDBC作为驱动，通过驱动直接与业务应用层打交道，为应用层组件完成逻辑处理提供必要的数据，以及响应由应用层组件触发的对数据操作的事件。如果对于存取效率要求比较高，可以降低访问数据库的频率，把需要经常被访问的业务数据存放在缓存中，并且通过特定的机制来保证缓存中的数与数据库中的数据同步。这可使用Hibernate来实现，它可以把对象模型表示的对象映射到关系型数据库中，同时提供了数据查询和获取的方法，提高了存取的效率。

下面将详细的介绍该***的应用实例。

以***中查询某科室医生的值班情况的消息为例，查询医生值班情况的消息定义格式如下所示：

/*查询医生值班情况消息的定义规则*/

QryDocWTime：MSH DocWTimeDef

MSH

20 String REQ NO_OPT MsgID /*消息序列号*/

DocWTimeDef

20 String REQ NO_OPT HspID /*医院编号*/

20 String REQ NO_OPT DptID /*科室编号*/

10 String REQ NO_OPT DayRange /*时间范围*/

/*查询医生值班情况返回消息的定义规则*/

RespDocWTime：MSH MSA [DocWTime]MSH

20 String REQ NO_OPT MsgID /*消息序列号*/

MSH

20 String REQ NO_OPT PreMsgID /*确认消息的序列号*/

32 Integer REQ NO_OPT State /*确认状态*/

80 String REQ OPT Detail /*消息信息*/

DocWTime

20 String REQ NO_OPT DocID /*医生的工号*/

30 WTime REQ NO_OPT WTime /*医生的值班时间*/

查询医生值班情况消息分为三个消息段MSH、DocTimeDef，MSH是消息头段，DocTimeQRD是科室具体信息消息段，首先由消息构造模块构造查询消息QryDocWTime，如下表所示：

</DocWTimeDef>

</QryDocWTime>

将XML消息封装为SOAP请求，利用http协议传输到服务器端，服务器端利用Dom接口将接收到的消息进行解析，提取出数据信息，并根据消息的名称调用消息事务处理模块中的DocTimeQRD处理函数，该函数利用数据库接口模块从数据库中获取查询部门的医生值班信息，利用消息构造模块封装为以下回应消息：

<MSH>

</MSH>

<MSA>

<WTime>

</WTime>

</DocWTime>

<WTime>

</WTime>

</DocWTime>

</RespDocWTime>

再利用http消息传送到客户端，客户端再利用DOM分析器从中提取出其中的数据信息。

Claims

1.一种面向数字家庭的医疗数据集成方案，其特征在于该方案引入消息中间件的方式，通过在各个医院设置通用接口服务器来屏蔽各个医院信息***的异构性。

2.根据权利要求1的医疗数据集成方案，其特征在于该通用接口服务器具有两方面的功能，一是数据集成功能，由部署在接口服务器上的消息中间件来完成，二是网络安全隔离功能，接口服务器使医院信息***不直接暴露在公网上，减少了医院信息***受到攻击和入侵的可能性。

3.根据权利要求2的医疗数据集成方案，其特征在于部署在接口服务器中的消息中间件划分为如下模块：消息交换任务管理模块、消息构建模块、消息解析模块、消息传输模块、消息事务处理模块、数据库接口模块。

4.根据权利要求3的消息中间件，其特征在于消息的定义规则以文本的形式存储在文件中，并且随着业务的增加，可以自定义扩展消息的定义规则。

5.根据权利要求3的消息中间件，其特征在于消息使用XML格式封装，并且在消息传输过程中，使用SOAP协议和HTTP协议来实现消息的传输。

6.根据权利要求3的消息中间件，其特征在于消息处理模块中，每个处理函数的名称与对应的消息名相一致。