基于面向服务架构的异地医保系统研究

1 引言

医疗保险一直是我国社会保险的重要组成部分，医疗保险信息管理系统也是社会保险信息管理系统的重要组成部分。

由于各地的医保待遇政策的差异，各地医保系统的核心算法各不相同，必须通过在各地的服务之间交换数据才能准确地完成异地就医待遇计算。可是各个独立的系统采用的技术不同，采用的接口方式也不相同，所以无法简单地采用网络把这些独立的系统连接起来。为了实现这些独立的系统之间的通信，可以重新制作一个可以适应各地医保待遇算法的统一的程序框架，把各地的医保待遇算法“填充”进去；也可以封装现有的系统，通过统一的接口和互操作协议使原有系统可以互相理解。面对服务的架构才能够适应这种需求。

2 设计

2.1 面向服务架构

总的来说面向服务开发具有以下特点：

（1）重用：创建能够被各种应用重用的服务，提高服务的适应性。

（2）效率：较少改变原有系统，集中精力于数据共享，组合现有服务以达到快速创建新的服务与应用的目的。

（3）低复杂度：较少关心底层实现、执行环境，通过对服务建模和建立接口契约来连接系统。

（4）高操作性：将业务问题和技术问题尽量分离，使业务人员和技术人员通过服务契约进行高效协同。

开发服务与开发对象不同：因为一个服务，是由它与其他服务交换的信息而不是由一个方法的结构来定义的；服务定义所在的抽象层次必须比对象定义所在的抽象层次要高，因为这样可以把一个服务的定义映射到某种面向过程的语言、消息排队系统或面向对象系统上。理解服务定义的粒度也同样重要。一般来说，服务都会定义粗粒度的接口。相对于对象的调用来说，对服务的单次调用会接收更多的数据，消耗更多的计算资源，因为它需要进行执行环境的映射和xml处理等工作，而且对服务的访问通常都是远程的。当然，对象接口也可以是粗粒度的。关键在于，服务是用来解决应用的互操作问题以及用于组合新应用或者应用系统，而不是为应用创建具体业务逻辑。通过进行Web服务的聚合，可以封装了多个其他服务的Web服务。这样，可以将一个粗粒度的接口分解为多个细粒度的服务，或者，用多个细粒度的服务组合为一个粗粒度的接口。粗粒度的服务更适合用于，而细粒度的服务则更适合作为仅供前者使用的“私有”服务。

结合目前的医保系统，医保中心对医院端提供了许多功能，如门诊和住院登记、交易结算、药品目录下载、对账报表生成等。这些交易中有的在中心端和客户端之间的数据交换量很大，不适合作为实时系统的一部分进行封装。考虑到异地医保业务中，只有属地的医保中心待遇核心算法对异地的医保系统有意义，所以我们只要封装属地的医保中心待遇核心算法部分，作为我们新系统的服务。向异地提供一些如待遇审批、待遇结算等医保待遇核心功能即可，其它不涉及到账户消费的功能就不需要加入实时系统部分。

在努力减小业务中交换的数据量的同时，也要减少每次业务在属地和异地医保系统之间的往来次数。

2.2 结算中心

将各地的系统进行封装之后，还需要建立一个结算中心。其目的有二：

(1)由于医保业务的特殊性，每个业务请求都必须要被处理，所以系统不能采用自动发现服务的方式，需要有一个模块来登记和维护这些已知服务的信息，进行数据的调度。

(2)各地的医保的结算系统是独立结算的，异地之间的业务的结算信息要被记录，然后通过银行系统对这些结算记录进行冲减，这为保证数据一致提供了依据。

为了实现以上这两个目的，结算中心需要至少具备以下几个功能：服务登记、数据转发、保证事务完整性、保存交易记录。通过在已知的服务地址列表中检索某个描述，找到对应的地址作为请求的目的地址。如要进行异地医保垫付给用结算，可根据保存的请求数据记录，通过调用银行提供的接口来完成。

2.3 层次结构

实时系统可以在医院客户端和医保中心端之间加入一个中间层，通过这个中间层来完成对原有医保系统的封装，同时也利用这个中间层来完成对异地医保系统请求的转发。如果发现一个请求的属地信息不是本地，则直接请求转给结算中心。同时还要完成本地医保中心的数据和异地之间传输的xml之间的数据格式转换。

3 实现

3.1 各地医保系统改造

异地就医业务发生时由异地医疗保险系统要多传入一个异地的区域编号，这个编号可以是全国统一编制的，也可以是局部的结算中心可以识别的，然后调用上一级结算中心进行交易。属地医保中心要提供接口给结算中心调用。每一个医保中心都具备异地和属地的双重角色。具体改动如下表：

表1 原系统改动列表

3.2 结算中心功能

结算中心是一个独立的新增模块，要在省级或部级进行开发。结算中心负责连接各地的医保中心，接收并转发各地的异地医保请求，将这些请求保存起来而不保存返回的处理结果。同时还要和银行接口连接，根据保存的请求数据，完成异地医保垫付。

3.3 结算中心接口

结算中心对外接口由Tuxedo编制的服务程序提供。主要完成两个任务：向结算中心数据库内保存请求数据、解析请求串并转发到指定的医保中心服务器。对于数据库操作由Tuxedo自动完成事务控制。使用Tuxedo主要原因是Tuxedo支持C语言编制的服务，执行效率较高；而且Tuxedo的并发性能很好，可以满足大量数据交换的需要。

结算中心提供给各医保系统的是一个jar，无用户界面，要求输入输出必须遵守接口规范。程序文件名：ddb_interface.jar。此接口完成远程服务接口调用，用于医保中心java程序调用jar的相应接口，完成调用Tuxedo服务：将此jar在医保中心WebLogic服务器部署为EJB，完成医保中心处理Tuxedo调用。

在这个jar中一共有5个消息类和2个功能类。5个消息类分别为MessageRequest：与Tuxedo交互过程中使用到的交互消息请求对象；MessageResponse：与Tuxedo交互过程中使用到的交互消息回应对象；MessageBody：交互消息休；MessageRequestHeader：交互消息请求头信息；MessageRequestHeader：交互消息回应头信息。2个功能类为RemoteTusedoServiceClient：远程Tuxedo服务客户端接口，负责调用Tuxedo服务；DDBException：接口异常类。由于目前只是一个原型系统，所以没有异常类的具体实现。

3.4 数据封装

对数据的封装采用xml的格式，在信息头中包括了：数据来源地、数据目的地、请求类型、交易编号、交易响应码、错误措述等几个部分。信息体中又分为参数和数据项，数据项中有多个数据元素。设置数据项是因为WebLogic和Tuxedo进行数据格式转换时，不支持xml的元素属性，所以要把元素属性转化成元素。根据需要，这些xml的内容可以加密后传输，来提高安全性。

针对具体业务，以住院异地结算为例，请求方必须发送包括请求业务类型、住院流水号、个人编号、医疗费总额、符合基本医疗费用总额、自费金额、自付金额、结算日期等项，应答方必须发送包括应答业务类型、执行成功标识、统筹支付金额、个人账户支付、个人现金支付等项。这些数据项都是选取出的待遇计算所必须的重要数据项。

4 测试

4.1 测试环境

测试模拟同一省内两城市医保中心，通过省级办理异地业务，其中属地医保中心为两台Sun V20z，每台机器上安装WebLogic，建立一个Server，2个Server形成Cluster。异地医保中心的系统搭建方式与属地医保中心相同。省级交换中心为两台SumV20z搭建的Tuxedo Cluster。属地医保中心、异地医保中心和省级交换中心分别建立用户，共用一个数据库，数据库服务器机型为Hp4640。

4.2 测试软件

监控工具：

操作系统vmstat /mpstat/iostat/netstat/prstat、中间件WebLogic8.1.4Console、数据库Oracle9.2OEM、statspack。

负载生成工具：

模拟负载场景Loadrunner v8.0。

4.3 测试数据及分析

在测试这个场景时，通过处方数量一定（300条处方），逐步增加并发人数；并发人数达到100个用户时，逐步增加处方量进行分别测试。跟踪后台的出错信息，根据这些错误信息分析、定位原因。通过调整中间件配置、应用等，最终达到并发100个用户、每人处方量达到500条的要求。详细数据见表2。

通过观察表2中列出的数据看到，所有的交易请求都能得到响应，说明系统有效。随着并发用户数的增加，交易请求的最小响应时间变化不明显，最大响应时间逐渐增加，说明这个实验环境中，系统的并发处理能力有限，交易请求要在队列中等待，但最后还是可以成功被处理的。每种业务的最小响应时间和最大响应时间都有一定差距，随着并发用户数的增加这种差距明显增加，这种增加也不是线性的，主要由于测试服务器只有一台，没有进行负载均衡，在后台处理时采用随机抢先机制造成的。

5结语

面向服务的架构概念和J2EE、web service、xml、中间件的结合使其更实用有效，通过面向服务的架构来重组现有的医疗保险系统，对原系统改动小，而且技术复杂度低，可以降低开发和维护成本。利用结算中心进行调度，利用交易中间件来进行消息的转发，保证了系统的可靠和效率。实验证明方案切实可行，但在性能优化方面仍有提升空间。

参考文献

[1]Thomas Erl.. PRENTICE HALL PTR，2006.

[2]徐涵.《Understanding SOA with Web Serices中文版》.电子工业出版社，2006.