我院门诊国家医保结算系统的设计与应用

陈建福

联勤保障部队第九〇九医院/厦门大学附属东南医院 信息科，福建 漳州 363000

引言

随着交通越来越发达，很多人跨省在异地长期居住，或者到省外临时就医，存在需要拿发票单据两地奔波报销、先行垫付等诸多不便。作为地区间医保信息业务交流的“通用语言”，国家医保码能破除医保信息流通的“沟通障碍”，是推进全国医保信息化建设的基础，对落实中共中央、国务院《关于深化医疗保障制度改革的意见》[1]与国务院办公厅《关于印发“十四五”全民医疗保障规划的通知》[2]中“统一医疗保障业务标准和技术标准，建立全国统一、高效、兼容、便捷、安全的医疗保障信息系统”的相关要求具有全局性意义[3]。由于医保改革和国家医疗保障局对国家医疗保障信息平台的推行，需要根据国家下发的《医疗保障信息平台定点医药机构接口规范》[4]对医院旧系统进行改造。改造前的医保收费系统存在诸多问题，如医保业务需操作员在“军卫一号”的多个子系统之间来回切换才能完成，操作繁琐，且信息切换转录过程中不可避免地会产生人为误差；另一方面，结算速度慢导致高峰期收费窗口经常排起长队，患者满意度下降。本文采用前后端分离开发技术对军卫两层架构门诊医保收费系统进行改造，实现国家医保结算、异地结算等功能，方便医保结算操作员操作，提高工作效率，使来我院就诊的异地军属、异地患者受益并直接减轻垫付的经济压力，提高患者就医满意度。

1 系统设计

开发统一接入平台以服务接口的方式提供医院数据接口服务，前端使用SunnyUI 框架开发Winform 应用程序，应用程序请求后台接口与医院信息系统（Hospital Information System，HIS）数据库进行数据交互。通过调用国家平台动态库（chs_fjs_standard.dll）的函数接口与医保端进行交互，完成医保业务。系统中数据交互格式为JSON 格式，JSON 作为JavaScript 的一个子集，是一种纯文本的数据交换格式。目前，JSON 在网络安全、气象数据、位置信息、3D 技术、物联网等领域应用广泛[5]。

1.1 前端应用程序与“军卫一号”HIS

如图1 所示，医院数据接口服务基于Spring MVC+MyBatis框架构建，使用Java语言进行开发，与数据库的持久层进行交互，框架包括控制器层、服务层和数据访问层3层。处理流程为：前端Winform应用程序通过http方式请求后台数据，服务器中Spring MVC的DispatcherServlet模块拦截请求后转给与之对应的控制器层调用对应服务层处理业务逻辑，服务层向数据访问层的MyBatis发送请求，MyBatis与数据库交互后将结果返回至服务层，服务层将处理逻辑发送至控制器层，控制器层再调用视图解析器展现数据[6]，以JSON格式将数据返回给前端应用程序，前端解析JSON数据后展现给用户。

图1 系统架构图

为了安全性，前端应用程序采用OAuth2.0 安全认证获取Access Token 的方式，所有请求都必须带有Token信息。OAuth2.0 协议为当下较流行的身份认证授权协议，该框架具有5 种模式：授权码模式、简单模式、密码模式、客户端模式和拓展模式[7]。医院数据接口服务基于授权码模式实现接口访问授权，OAuth2.0 为客户端提供了一种代表资源拥有者访问受保护资源的方法。使用授权码模式完成OAuth2.0 授权的过程包括3 个步骤：① Client请求授权服务端，获取AuthorizationCode；② Client 通过AuthorizationCode 再次请求授权服务端，获取Access Token；③ Client 通过服务端返回的Access Token 获取用户的基本信息[8]。

1.2 前端应用程序与医保端

前端应用程序通过调用国家平台动态库（chs_fjs_standard.dll）提供的函数接口方式，请求报文以JSON数据格式与医保服务进行传输交互，实现与医保的结算对接。数据传输到医保服务端之前会先进行读卡校验，校验实体卡与发送的报文是否匹配，然后对关键字段进行加密，关键字段在医保服务端进行解密，用授权码和终端特征码作为客户端与服务端数据交互的凭证。门诊医保结算数据交互图如图2 所示。

图2 门诊医保结算数据交互图

2 门诊医保结算流程与功能

操作员通过分配的医保两定[定点医保医疗机构（医院）、定点医保零售机构（零售药房）]账号调用动态库提供的授权方法进行登录，门诊医保结算流程及操作界面分别如图3～4 所示。

图3 门诊医保结算流程图

图4 门诊医保结算操作界面

2.1 医院医保电子凭证

与传统实体卡不同，医院的医保电子凭证能够存在于任何移动终端中，因此患者不再需要携带实体卡就医，只需利用移动终端进行扫码就能够享受医保服务，办理各种业务[9]。

本研究系统中的所有医保业务都支持医保电子凭证扫码操作，参保人可通过国家医保APP 或者微信、支付宝等经由国家医保局认证授权的第三方渠道激活使用[10]。为持续推进我院医保电子凭证结算工作，系统在医保挂号前会提示收费员优先使用医保电子凭证，导诊护士在门诊各收费窗口醒目位置为患者提供微信与支付宝的医保电子凭证扫码图，引导患者使用医保电子凭证进行结算。系统提供每月电子凭证结算率排名功能，对电子凭证结算率超过50%的人员给予奖励。

2.2 医保人员建档与绑定

前端应用程序通过调用医保1101 交易获取医保人员基本信息，包含参保状态、参保日期、身份信息、单位信息等，将信息导入系统进行人员信息院内建档。如果患者是二代医保卡换三代医保卡的情况，系统会提示未绑定时无法获取医保信息，应使用医保电子凭证就诊。在实际使用医保电子凭证时，有一部分患者通过电子扫码墩读出来的信息是没有卡号或者卡号是9 个0 但有身份证信息，此时系统会通过读取到的身份证号查找院内患者数据库，通过医保卡号或身份证号找到院内患者，与患者核对后进行医保卡的绑定；如果没有找到，则进行医保人员院内信息建档。针对同一张医保卡绑定院内多个患者ID 号的情况，操作员可通过系统列表选择要结算的患者ID。

2.3 门诊挂号

通过调用医保2201A 交易进行门诊挂号，首先需通过实体卡读取卡号验证身份信息，电子凭证通过扫码墩解析获取电子凭证令牌ecToken 信息验证；挂号成功后，医保返回唯一流水号就诊ID；下一步就诊信息上传、费用上传、结算将以此就诊ID 为唯一标识。

2.4 门诊就诊信息上传

通过调用医保2203A 交易上传门诊就诊及诊断信息。若患者需要办理特殊病种，在此上传特殊病种编码。若当日就诊医生为患者开具多种特殊病种，系统提供按特殊病种分组功能，方便收费员以整个病种选择收费项目进行结算。因可能存在由于医生开具的诊断编码不规范（非国家医保的诊断编码），导致医保挂号失败，患者需要再去找医生修正诊断编码的情况，系统提供国家医保诊断编码字典库，供操作员调阅诊断名称和编码，在与医生确认后，修改诊断编码，实现让“数据多跑路，群众少跑腿”[11]。

2.5 门诊费用明细信息上传

通过调用医保2204 交易上传门诊费用明细信息。返回费用明细项符合政策范围金额、自付比例、先行自付金额等，根据医院审批标志，配合医保目录的限制使用标志使用，纳入报销处理或按自费处理；如诊断为健康查体的，不适用于统筹金不能进行医保报销即返回全自费金额。

2.6 门诊结算

通过调用医保2207A 交易进行门诊正式结算。在医保结算前，系统会自动调用医保3102 交易（明细审核事中分析服务），查询患者是否有医保违规信息。如果没有则继续结算，如果有则根据违规的内容，选择遵从或不遵从，不遵从需要填写原因，反馈至医保。

医保结算支持本地结算、省内异地结算、跨省异地结算。医保结算成功后，再进行院内结算时，如果患者的预交金不足，系统自动弹出预交金充值界面让患者充值。医保结算如果交易失败，系统则显示结算失败的详细原因（如门诊特殊病种未备案、病种类型不属于国家门诊慢特病种、患者住院期间不允许结门诊等），省外患者由系统自动发起医保冲销2208 交易，省内患者则发起医保冲正2601 交易，省内省外通过读取患者参保地进行判别。

系统提供医保两定网址查询功能，用于操作员再次确认患者医保结算信息。系统发起医保冲正交易前，首先通过医保结算ID 号以及患者ID 号，查询院内HIS 是否已经结算过，如果院内HIS 结算成功，则不允许冲正，必须走医保退费流程。否则，会造成单边账即医保端没有结算数据、医院端有数据，医保不拨付，使医院蒙受经济损失。

2.7 医保退费

首先调用医保2208 交易进行门诊结算撤销，再调用医保2205 交易撤销门诊费用明细信息。交易成功后再执行院内HIS 退费操作，将退款的金额充入患者的预交金。如果是跨笔冲销则提示收费员应逐笔冲销，以及应先冲销的医保结算ID 号。

2.8 医保单边账处理

2.8.1 医保手工冲正

通过调用医保2601 交易进行手工冲正，即当定点医药机构发起某项交易时，因网络中断或超时等原因导致无法获取接收方状态，导致多方数据不一致或已确认接收方数据多时，可通过冲正取消接收方相应数据，保持双方数据一致。

当医保端结算成功、但院内结算失败时，系统提供手工冲正功能，冲正成功后，再重新进行结算。操作流程为：录入欲冲正的医保结算ID 号、人员编号（通过读卡器读取）、msgid 等信息进行冲正；系统将冲正操作的医保结算ID 号、操作员编号记录成日志文件上传至院内服务器。每月与医保对账时，如果发生因收费员操作失误，冲正到正常的结算ID，医保不拨付款，导致医院少收费，则日志文件成为责任追查的依据。同时，为降低操作失误率，在操作前加入主管口令进行验证。

2.8.2 收费员手工退票

若由于收费员输错ID 号等误操作，对正常结算的医保ID 号进行了冲销，导致院内单边账。此时医保端已冲销（医保端金额为一正一负）、院内结算成功，系统提供收费员手工退票功能，将院内结算的费用进行退票，费用退回患者预交金中，实现与医保端两边对账一致。

2.9 医疗保障基金结算清单信息上传

通过调用医保4101A 交易上传医疗保障基金结算清单信息，系统根据门诊结算数据，生成医疗保障基金结算清单信息，提交医保中心进行审核。

2.10 实时日志记录

在医保结算过程中，为了方便查询医保结算过程中的信息，将每次与医保端交互的请求报文、输出报文、接口返回状态值等信息，以结算患者的院内ID 号为一级索引、结算日期为二级索引的文件目录方式，生成日志文件。

使用Microsoft Windows 服务能够创建在其Windows会话中可长时间运行的可执行应用程序。这些服务可以在计算机启动时自动启动，可以暂停和重新启动而且不显示任何用户界面[12]。客户端运行自主开发的Windows系统服务（服务名：医保日志上传），定时将客户端本地与医保交互的日志文件上传至院内日志服务器指定目录，见图5。在出现结算金额不一致，或者项目金额对不上等异常的情况时，通过患者的院内ID 号查找对应的日志文件进行分析与查询HIS 数据，从而找到问题的原因并解决。

图5 上传的医保交易日志

3 应用效果

系统自2022 年4 月上线以来，门诊医保结算日平均结算量2800 笔左右，平均结算速度为0.8 s，每月电子凭证结算率保持在52%以上，受到地方医保局的表扬。随机抽取新系统2022 年5 月期间10 d 的数据作为研究样本，旧系统2021 年5 月期间10 d 数据作为对照样本，比较两组样本的患者等候时间、医保结算完成时间、差错率的差异。其中，患者等候时间：通过统计各医保结算窗口患者排队叫号时间间隔，汇总等待时间除以人数得出平均等候时间；医保结算完成时间：统计患者医保挂号交易到医保结算交易成功的两个交易日志产生的时间间隔，汇总各患者医保结算完成时间求出平均结算时间。

选择SPSS 26.0 软件进行数据统计分析，计量数据以±s的形式表示，行独立样本t检验，以P＜0.05 为差异有统计学意义。

新系统上线后，患者等候时间、医保结算完成时间、差错率均明显低于旧系统，且差异均有统计学意义（P＜0.05），见表1。

表1 新旧系统各项参数对比结果（±s）

表1 新旧系统各项参数对比结果（±s）

组别患者等候时间/s 医保结算完成时间/s 差错率/%旧系统 181.05±3.00119.63±2.001.31±0.02新系统88.45±2.0058.57±1.000 t值227.941116.013478.021 P值0.0100.0100.010

相较于新系统使用前，操作员的工作效率大大提高，患者等待时间平均缩短了50.8%。对于操作员，原先需要在军卫一卡通收费程序、挂号程序与医保收费程序3 个程序建档、绑定、结算时来回切换操作，繁琐且耗时耗力容易出错，新系统上线后在1 个系统就可以完成所有操作，大大降低了操作员的工作强度，简化了操作流程。早期军卫系统是C/S 架构，直接与数据库服务器相连，造成服务器负担重、反应慢。新系统上线后，停用客户端的多个C/S 程序（一卡通收费程序、挂号程序与医保收费程序等），减少500 多个数据库连接数（目前医院各个系统数据库连接数约3000 个左右），大大缓解了数据库服务器的压力，推进了医院信息系统往更合理的架构方向发展。本系统也为“军卫一号”的其他扩展性开发提供了新的思路。

4 讨论

以往的研究多是将整个项目改造成Winform 应用程序，如武警广西总队医院HIS 的改造开发工具采用Sybase PowerBuiIder 11.0（简称PB）[13]；解放军联勤保障部队北戴河康复疗养中心用PB 9.0 研发了一套医保智慧互联平台系统，实现军卫系统与医保系统的对接[14]。但其缺点是与后台数据库交互都是两层C/S 架构，数据库服务器负载重、扩展性差，不如Spring MVC 框架灵活、可扩展性好、性能高。也有研究将整个项目改造成Web项目，前端代码和后端代码混合在一起，如ASP、JSP技术等，这种开发模式存在代码可读性差、开发效率低等问题[15]。本研究结合两者的优点，前端采用SunnyUI框架开发Winform 应用程序进行数据渲染，后端采用Spring MVC+MyBatis 框架Java 设计，前后端解耦，并行开发，节约开发时间，使得开发变得清晰明了。后期业务扩展通过增加后端服务器提高系统的处理能力和负载能力，系统性能更好。本系统是“军卫一号”系统的创新应用，将“军卫一号”系统中的身份登记子系统、门诊挂号子系统、门诊医保收费子系统以及一卡通收费子系统的功能集成到新系统[16]，满足门诊收费信息管理和医保结算的需要，摒弃了原来多个子系统切换的工作模式，大大提高了工作效率，减少和避免了信息转录过程中的人为误差，使数据录入更加便捷，数据安全性、完整性和规范性得到全面提高。

目前系统已在我院门诊稳定运行，医保结算速度快，操作方便，大大缓解了收费窗口的工作压力。通过系统的上线，推进了我院医保标准化信息化的建设，顺利完成军卫HIS 改造与地方医疗保障信息平台对接工作。由于医保结算速度快，方便来院患者医保就诊，减少结算等待时间，深受就医患者好评。该系统具备极强的可行性与实用性，为操作员、医护人员、患者提供便捷化、信息化的医保结算平台。目前系统也在不断完善中，难点是军卫一卡通收费程序的发票打印功能是通过票控盘控制，要移植到新系统需要进一步研究与评估。下一步，将从重构代码提高性能、增加功能模块这两方面来进一步完善系统，提高用户的使用体验，使本系统具有更大的现实意义与使用价值。