我院門診國家醫保結算系統的設計與應用

陳建福

聯勤保障部隊第九〇九醫院/廈門大學附屬東南醫院 信息科，福建 漳州 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 交易獲取醫保人員基本信息，包含參保狀態、參保日期、身份信息、單位信息等，將信息導入系統進行人員信息院內建檔。如果患者是二代醫?？〒Q三代醫?？ǖ那闆r，系統會提示未綁定時無法獲取醫保信息，應使用醫保電子憑證就診。在實際使用醫保電子憑證時，有一部分患者通過電子掃碼墩讀出來的信息是沒有卡號或者卡號是9 個0 但有身份證信息，此時系統會通過讀取到的身份證號查找院內患者數據庫，通過醫?？ㄌ柣蛏矸葑C號找到院內患者，與患者核對后進行醫?？ǖ慕壎?；如果沒有找到，則進行醫保人員院內信息建檔。針對同一張醫?？ń壎ㄔ簝榷鄠€患者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 改造與地方醫療保障信息平臺對接工作。由于醫保結算速度快，方便來院患者醫保就診，減少結算等待時間，深受就醫患者好評。該系統具備極強的可行性與實用性，為操作員、醫護人員、患者提供便捷化、信息化的醫保結算平臺。目前系統也在不斷完善中，難點是軍衛一卡通收費程序的發票打印功能是通過票控盤控制，要移植到新系統需要進一步研究與評估。下一步，將從重構代碼提高性能、增加功能模塊這兩方面來進一步完善系統，提高用戶的使用體驗，使本系統具有更大的現實意義與使用價值。