社区健康档案管理系统的数据集成方案设计

2011-03-10徐洪华王艳春董光师为礼

长春理工大学学报（自然科学版） 2011年1期

徐洪华，王艳春，董光，师为礼

（长春理工大学计算机科学技术学院，长春 130022）

国家在“全国信息化发展规划纲要”中已明确指出“要开展以地（市）范围为单元的区域卫生信息化建设试点和研究工作，建立区域卫生信息化示范区”。SARS以后中央对全国的医疗卫生系统建设更加重视，希望走出一条适应我国国情的将公共卫生、医疗、保健、紧急救助等融为一体的以城市为中心的统一指挥系统。

社区健康档案管理系统解决方案的核心是个人健康档案的建立。个人健康档案数据［1］的采集重心在社区卫生服务机构。采集居民从出生、发育、结婚、生育、患病、老年直至死亡的全过程中所有的健康活动数据。通过数字化、信息化、网络化技术，以个人健康档案为基础、家庭档案为单位、社区档案为范畴，建立连续、完整、动态的个人健康信息数据库。临床医生可以根据及时准确地掌握患者的相关资料，对患者进行相应治疗；公共卫生人员可以根据档案信息了解威胁群众健康的疾病特征和规律。准确而完善的档案信息可以使患者、医生、公共卫生人员和决策者都从中收益。

为实现合保系统和医保系统向社区卫生服务机构倾斜，建立社区卫生服务首诊制奠定基础，社区健康档案管理系统需要实现与合保和医保的数据共享交换接口；为实现社区与医院的双向转诊，社区健康档案管理系统需要与医院HIS、妇幼保健系统、儿童计划免疫系统、计划生育系统之间建立数据共享交换接口，定期交换就诊记录，拼接完整的个人健康档案。在数据快速传输的基础上，保证数据在不同系统之间进行完整而准确的交换，才能够实现不同系统间信息的互联互通。因此，对不同数据源的异构数据［2-5］进行数据整合就是一项重要而又具有挑战的任务。

1 使用XML实现异构数据集成方法

目前，医疗领域的各个部门都建立了不同的信息管理系统，建设初期由于各种资源和技术的限制，这些系统的数据库系统可能都存在很大差异，导致数据无法共享，从而形成了信息孤岛现象。社区健康档案管理系统的解决方案需要考虑平台兼容性、数据异构性、穿越防火墙的方便性和成本等问题。针对其中的数据异构问题，本文提出采用XML格式对不同数据源的异构数据可以实现数据整合的方法。

XML作为SGML的一个子集，保留了SGML的强大功能，降低了SGML的复杂性。使用XML可以将来自不同数据源的数据很容易地集成在一起，然后以XML格式发送给客户端或者其他服务器，接收到数据以后，可以通过数据解析对数据做进一步的处理。XML文档中的DOM模型允许使用脚本或者其他程序设计语言来处理数据，使得数据的转换具有更好的灵活性，从而有利于解决网络中繁重的异构数据交换问题。

本系统中，需要交换的数据具有多个数据源，不同数据源的数据模式可能也不相同，导致数据源和目标数据在结构上存在差异。在进行数据查询时，用户的查询指令会被作为全局事务经过处理后分解成对应各自数据源的子事务，子事务的处理结果将数据模式以统一的XML格式来描述，这就需要使用XML的DTD或者XMLSchema来定义文档的结构，DTD定义XML文档的基本结构，但不涉及到任何有关的实际数据，通过定义适当的 DTD将源数据库中的数据转换成XML文档，然后使用DOM技术来合并XML文档，这样就可以将XML文档中的数据打包返回给用户，从而实现了异构数据的交换和集成。

2 数据集成结构框架

本框架结构采用层次结构，包括应用层、中间层和数据层。这种层次结构具有很好的可移植性，可以在不同的平台上使用。本框架结构的构成如图1所示。

图1 异构数据集成框架结构Fig.1 Framework of heterogeneous data integration

应用层是本框架的最高层，它由网络客户端组件构成。在网络环境中，他的主要功能是通过图形化的用户接口直接实现用户操作。客户端通过提交用户请求和接收中间层返回的XML形式的结果数据与中间层进行通讯［6-8］。这样，系统间的交互性就可以通过XML数据模式得以实现。

中间层是本框架的核心层。本层包括四个组成部分，即用户接口、管理器、查询器和元数据库。这一层的主要功能是实现数据层和应用层之间的连接。数据集成的过程也是基于“动态集成”的思想，也就是说在操作之前，不提供数据的预定义模式或者全局模式。为了实现用户视图，需要创建一个虚拟模式。这个虚拟模式由元数据库中存储的来自不同数据源的数据来共同实现。用户的查询处理会被分解成数据源对应的子查询，每个查询器负责处理一个子查询，实现用户信息与数据层的关联。查询器同时与封装器进行通讯，负责接收和传送从数据层到中间层的数据结果。这种处理机制使得在整体框架结构不变的情况下，允许用户添加或者删除数据源。这种方法具有很好的伸缩性，数据异构的问题也可以得以解决。

数据层包括异构数据源和封装器。每个封装器直接与数据源相连接，它们的主要任务是服务于来自查询器的请求，把数据源返回的结果转换成统一的XML数据模式，并将结果包装后返回给查询器，再由查询器将其传递给管理器。

这种基于层次结构的框架可以在任意两个相邻的层面之间发送和接收数据，实现了系统的可扩展性和交互的灵活性。

2.1 应用层

应用层位于框架结构的最上层，网络客户端组件为用户提供数据位置和结构的透明性，这使得系统具有极大的灵活性。用户可以在不用获知数据模式和查询语言等相关知识的情况下，发出用户查询请求。应用层主要的功能包括：

1.实现对图形化用户接口的支持。

2.查看不同数据源的全局模式，为用户提供统一的查询模式，创建用户视图。

3.确保用户的查询请求能够准确无误地传递给中间层。显示从中间层反馈回的XML模式的数据结果。

2.2 中间层

中间层包括用户接口、管理器、查询器和元数据库，是本框架的核心层。其具体构成如图2所示。

图2 中间层工作过程Fig.2 Working process of the middle layer

2.2.1 元数据库

元数据库［9，10］存储来自不同数据源的数据的描述信息。元数据库中存储的信息提供给用户接口和管理器组件使用并实现用户接口和管理器组件之间的数据关联。元数据库提供用户级别的事务处理，具体功能描述如下：

1.对用户的合法请求和全局事务的创建提供虚拟数据。

2.对不同数据源的用户操作权限进行控制和分配。

3.提供查询创建和优化所需要的必要信息，如存储路径、数据分配等。

4.提供物理数据和虚拟数据之间的消息映射，为全局事务的转换提供便利。

5.为用户的请求提供虚拟数据，实现数据集成，消除存在的异构问题。

元数据库中包含以下几类信息：

1.数据源信息。数据的描述信息和不同数据源的数据约束信息；数据源中的实际实体和属性同虚拟数据的实体和属性的对应关系；每种数据源的数据模式信息；每个数据源的域名，主机名和物理地址等信息。

2.相关的操作权限信息。用户的存取权限；查询所需要的认证信息。

3.事务优化需要的信息。创建事务和产生子事务所需要的优化信息。

2.2.2 用户接口

用户接口的主要功能是负责向用户展示各种数据源的全局模式，产生与用户请求相关的全局事务。全局事务可以是一个标准SQL查询请求。SQL查询中使用虚拟的属性和关系，这些虚拟的属性和关系可能来自一个或者多个不同的数据源。用户信息（名字，地址等），用户种类（本地或远程）和全局事务将会被打包成一个用户信息包，然后传递给管理层。用户接口随即将从管理器得到的结果提交给客户端。