医疗保险异地就医一卡通系统建设

　　 随着社会保障水平的提高和社会保障覆盖面的不断扩大，基本医疗保险异地就医成为方便参保人员和提高医疗保险服务水平的重要任务。当前，医疗保险异地就医在各地开展，许多省、市正在实施医保“一卡通”项目。但是，由于基本医疗保险统筹地区众多，各统筹区的缴费和保障水平差距很大，异地就医业务量大，医保结算实时性要求高，业务管理复杂，基本医疗保险异地就医“一卡通”系统建设方案的选择对项目成功有重要的影响。

　　一、基本医疗保险异地就医的业务分析

　　在我国现有基本医疗保险体制下，实行不同的医保基金统筹区，在南方地区，统筹区大都以县为单位。在不同的统筹区，执行不同的缴费、待遇即保障规定，建立了独立的基本医疗保险信息系统，执行本统筹区医保管理和就医结算。这样的体制下医疗保险异地就医十分困难。

　　在现有实时结算业务中，医疗保险参保人员就医过程是：参保人员持医保卡（社会保障卡）到医保定点医疗机构挂号，到医生工作室看病就医，医生将人员信息、医生诊断、医嘱、处方（包括检查、治疗等项目）等录入传入医院信息系统，病人到收费窗口刷医保卡结算，这时医院信息系统将病人信息、处方（包括检查、治疗等项目）出入医保中心，医保信息系统通过待遇结算程序计算给出本人应享受的医保待遇和应付款项明细，病人付费结算，病人住院、检查等项目执行相同的处理过程，即所有的医保待遇均由本统筹区医保中心待遇结算程序完成参保人员待遇计算。

　　从医保业务的角度，实施基本医疗保险异地就医，参保人员就可以持医保卡到统筹区外的医保定点医疗机构就诊，同时，希望基本业务过程不要有过多的改变。

　　二、基本医疗保险异地就医系统框架

　　为实现医疗保险异地就医，系统框架和信息系统架构的合理选择是系统成功实现和稳定运行的重要保证，是业务顺利开展的基础。由于各统筹地区已建有本地医保结算系统，如选择建立一个跨统筹区医保异地就医中心平台，实现对异地就医业务的传输，由参保地按当地政策计算医保待遇返回到就医地定点医疗机构实现异地就医业务，实现交易中心功能，同时，中心平台记录相关业务数据以实现各统筹区资金清算和业务管理，实现结算中心功能。这样的系统框架对原有系统的冲击很小，有利于项目成功和系统稳定运行。即就医地定点医院负责接待参保人员向就医地发起就医请求，就医地把统筹区外就医信息发送到交易中心，交易中心负责传输就医信息（交易平台）和记录结算信息（结算中心），并协调管理，这样，由参保地负责实现基本医疗保险异地就医待遇计算，返回结算信息，保持原有模式不变。如图1 所示：

　　三、基本医疗保险异地就医流程设计

　　根据业务需求分析，我们参考医保统筹区内就医流程，分析异地就医业务，把整个过程分为以下几个主要业务环节：门诊挂号（住院登记）、处方（诊疗、治疗）录入、费用预结算、费用结算、门诊退号（无费用退院）、门诊退费（住院召回）、处方退方。为保证业务（交易）完整和费用结算无误，保证统筹区间正确进行费用清算，还设计了操作员签到、对账、退签、参保地对账等业务过程。在医保业务管理上设计了人员信息获取、交易明细下载、备案申报上传、费用审核扣款上传、处方明细审核扣款上传、拨付结算信息上传等业务。

　　四、基本医疗保险异地就医系统架构与方案选择

　　在整个系统中，就医信息传输或信息交换的中心平台是系统的关键。在各地医保系统中，许多系统采用交易中间件完成医保结算，金融系统广泛采用的TUXEDO 和WEBLOOGIC 中间件产品在医保结算系统中也被广泛使用。以某地区为例，所属县、市（统筹区）均采用这两种中间件。这样，可以采用TUXEDO 和WEBLOOGIC 构建交易平台和结算中心，开发交易结算接口，完成异地就医业务的交易、结算和管理功能。

　　在这样的架构下，我们需要着重分析中心平台与各统筹区的通讯要求。就医地与中心平台之间的通讯方式比较简单，即：就医地作为Client 访问结算中心的Tuxedo 服务；参保地作为待遇计算方与中心平台之间的通讯方式必须为双向访问方式，即：中心平台能够访问参保地的服务，参保地也可以访问中心平台的Tuxedo 服务。但是，每一个统筹区都同时既是参保地也是就医地，所以，各统筹区到中心平台都需要双向访问，定点医疗机构与各统筹区访问方式保持不变。

　　为满足这样的通讯要求，对于使用TUXEDO 中间件的统筹区可用Tuxedo Domain 域通讯方式实现。Tuxedo 有两种对外通讯机制：一是Tuxedo 作为服务端接受其他系统的访问，提供服务，另一种是Tuxedo 作为客户端访问其他应用系统，要求服务。由于Tuxedo Domain 即域通讯的对等性，因此该通讯方式是双工的，在系统组织上，可利用Tuxedo Domain 即域通讯方式实现不同的组织机构系统之间的访问，可组织中心平台与使用TUXEDO 中间件的各统筹区之间的交易和结算通讯。对于使用WEBLOOGIC 中间件的统筹区，可使用WTC（WeblogicTuxedo Connector）接入方式。与Tuxedo Domain 通讯方式比较相似，WTC 可以提供双向访问，即：Tuxedo 可以通过WTC 访问WebLogic 的EJB，WebLogic 也可以通过WTC 访问Tuxedo 的服务，WTC 是通过WTC 网关与Tuxedo 的域网关进行通讯的。

　　通过以上设计形成完整的系统结构：在交易和结算中心平台部署Tuxedo 中间件应用服务器，各统筹区通过Tuxedo 域通讯或WTC 的连接方式接入，如图2 所示。 

　　在中心平台上，交易平台的核心作用是提供交易服务和交易请求转发。在Tuxedo 通讯系统中，可以通过两种方式来实现Service 与Service之间的相互调用。通过tpcall 进行同步或异步调用；通过tpforword 实现交易请求的转发，如下两图所示，调用tpforward 后，后续处理与调用者脱离关系，由域网关负责数据回送。对于WebLogic Service，Tuxedo 可以通过WTC 调用WebLogic 的EJB，部署在WebLogic 上的Java 程序可以通过WTC调用Tuxedo 服务，此过程与Tuxedo 域通讯类似。 

　　结束语

　　在各地开展的异地就医系统建设中将会碰到很多技术和管理问题，本文讨论的系统结构实现了一个地区内采用Tuxedo WebLogic中间的系统间的互联互通，但异地就医还有许多业务管理问题，需要业务管理创新。当异地就医扩展到省级和全国范围，还有许多技术问题需要解决，就医交易的通讯转发仍然是系统构建的核心问题。从已有的项目经验看，我们认为，制定统一的业务交易规范是医保异地就医在全国开展需要解决的主要技术问题。