我院門診國家醫(yī)保結(jié)算系統(tǒng)的設(shè)計與應(yīng)用

陳建福

聯(lián)勤保障部隊第九〇九醫(yī)院/廈門大學附屬東南醫(yī)院 信息科，福建 漳州 363000

引言

隨著交通越來越發(fā)達，很多人跨省在異地長期居住，或者到省外臨時就醫(yī)，存在需要拿發(fā)票單據(jù)兩地奔波報銷、先行墊付等諸多不便。作為地區(qū)間醫(yī)保信息業(yè)務(wù)交流的“通用語言”，國家醫(yī)保碼能破除醫(yī)保信息流通的“溝通障礙”，是推進全國醫(yī)保信息化建設(shè)的基礎(chǔ)，對落實中共中央、國務(wù)院《關(guān)于深化醫(yī)療保障制度改革的意見》[1]與國務(wù)院辦公廳《關(guān)于印發(fā)“十四五”全民醫(yī)療保障規(guī)劃的通知》[2]中“統(tǒng)一醫(yī)療保障業(yè)務(wù)標準和技術(shù)標準，建立全國統(tǒng)一、高效、兼容、便捷、安全的醫(yī)療保障信息系統(tǒng)”的相關(guān)要求具有全局性意義[3]。由于醫(yī)保改革和國家醫(yī)療保障局對國家醫(yī)療保障信息平臺的推行，需要根據(jù)國家下發(fā)的《醫(yī)療保障信息平臺定點醫(yī)藥機構(gòu)接口規(guī)范》[4]對醫(yī)院舊系統(tǒng)進行改造。改造前的醫(yī)保收費系統(tǒng)存在諸多問題，如醫(yī)保業(yè)務(wù)需操作員在“軍衛(wèi)一號”的多個子系統(tǒng)之間來回切換才能完成，操作繁瑣，且信息切換轉(zhuǎn)錄過程中不可避免地會產(chǎn)生人為誤差；另一方面，結(jié)算速度慢導(dǎo)致高峰期收費窗口經(jīng)常排起長隊，患者滿意度下降。本文采用前后端分離開發(fā)技術(shù)對軍衛(wèi)兩層架構(gòu)門診醫(yī)保收費系統(tǒng)進行改造，實現(xiàn)國家醫(yī)保結(jié)算、異地結(jié)算等功能，方便醫(yī)保結(jié)算操作員操作，提高工作效率，使來我院就診的異地軍屬、異地患者受益并直接減輕墊付的經(jīng)濟壓力，提高患者就醫(yī)滿意度。

1 系統(tǒng)設(shè)計

開發(fā)統(tǒng)一接入平臺以服務(wù)接口的方式提供醫(yī)院數(shù)據(jù)接口服務(wù)，前端使用SunnyUI 框架開發(fā)Winform 應(yīng)用程序，應(yīng)用程序請求后臺接口與醫(yī)院信息系統(tǒng)（Hospital Information System，HIS）數(shù)據(jù)庫進行數(shù)據(jù)交互。通過調(diào)用國家平臺動態(tài)庫（chs_fjs_standard.dll）的函數(shù)接口與醫(yī)保端進行交互，完成醫(yī)保業(yè)務(wù)。系統(tǒng)中數(shù)據(jù)交互格式為JSON 格式，JSON 作為JavaScript 的一個子集，是一種純文本的數(shù)據(jù)交換格式。目前，JSON 在網(wǎng)絡(luò)安全、氣象數(shù)據(jù)、位置信息、3D 技術(shù)、物聯(lián)網(wǎng)等領(lǐng)域應(yīng)用廣泛[5]。

1.1 前端應(yīng)用程序與“軍衛(wèi)一號”HIS

如圖1 所示，醫(yī)院數(shù)據(jù)接口服務(wù)基于Spring MVC+MyBatis框架構(gòu)建，使用Java語言進行開發(fā)，與數(shù)據(jù)庫的持久層進行交互，框架包括控制器層、服務(wù)層和數(shù)據(jù)訪問層3層。處理流程為：前端Winform應(yīng)用程序通過http方式請求后臺數(shù)據(jù)，服務(wù)器中Spring MVC的DispatcherServlet模塊攔截請求后轉(zhuǎn)給與之對應(yīng)的控制器層調(diào)用對應(yīng)服務(wù)層處理業(yè)務(wù)邏輯，服務(wù)層向數(shù)據(jù)訪問層的MyBatis發(fā)送請求，MyBatis與數(shù)據(jù)庫交互后將結(jié)果返回至服務(wù)層，服務(wù)層將處理邏輯發(fā)送至控制器層，控制器層再調(diào)用視圖解析器展現(xiàn)數(shù)據(jù)[6]，以JSON格式將數(shù)據(jù)返回給前端應(yīng)用程序，前端解析JSON數(shù)據(jù)后展現(xiàn)給用戶。

圖1 系統(tǒng)架構(gòu)圖

為了安全性，前端應(yīng)用程序采用OAuth2.0 安全認證獲取Access Token 的方式，所有請求都必須帶有Token信息。OAuth2.0 協(xié)議為當下較流行的身份認證授權(quán)協(xié)議，該框架具有5 種模式：授權(quán)碼模式、簡單模式、密碼模式、客戶端模式和拓展模式[7]。醫(yī)院數(shù)據(jù)接口服務(wù)基于授權(quán)碼模式實現(xiàn)接口訪問授權(quán)，OAuth2.0 為客戶端提供了一種代表資源擁有者訪問受保護資源的方法。使用授權(quán)碼模式完成OAuth2.0 授權(quán)的過程包括3 個步驟：① Client請求授權(quán)服務(wù)端，獲取AuthorizationCode；② Client 通過AuthorizationCode 再次請求授權(quán)服務(wù)端，獲取Access Token；③ Client 通過服務(wù)端返回的Access Token 獲取用戶的基本信息[8]。

1.2 前端應(yīng)用程序與醫(yī)保端

前端應(yīng)用程序通過調(diào)用國家平臺動態(tài)庫（chs_fjs_standard.dll）提供的函數(shù)接口方式，請求報文以JSON數(shù)據(jù)格式與醫(yī)保服務(wù)進行傳輸交互，實現(xiàn)與醫(yī)保的結(jié)算對接。數(shù)據(jù)傳輸?shù)结t(yī)保服務(wù)端之前會先進行讀卡校驗，校驗實體卡與發(fā)送的報文是否匹配，然后對關(guān)鍵字段進行加密，關(guān)鍵字段在醫(yī)保服務(wù)端進行解密，用授權(quán)碼和終端特征碼作為客戶端與服務(wù)端數(shù)據(jù)交互的憑證。門診醫(yī)保結(jié)算數(shù)據(jù)交互圖如圖2 所示。

圖2 門診醫(yī)保結(jié)算數(shù)據(jù)交互圖

2 門診醫(yī)保結(jié)算流程與功能

操作員通過分配的醫(yī)保兩定[定點醫(yī)保醫(yī)療機構(gòu)（醫(yī)院）、定點醫(yī)保零售機構(gòu)（零售藥房）]賬號調(diào)用動態(tài)庫提供的授權(quán)方法進行登錄，門診醫(yī)保結(jié)算流程及操作界面分別如圖3～4 所示。

圖3 門診醫(yī)保結(jié)算流程圖

圖4 門診醫(yī)保結(jié)算操作界面

2.1 醫(yī)院醫(yī)保電子憑證

與傳統(tǒng)實體卡不同，醫(yī)院的醫(yī)保電子憑證能夠存在于任何移動終端中，因此患者不再需要攜帶實體卡就醫(yī)，只需利用移動終端進行掃碼就能夠享受醫(yī)保服務(wù)，辦理各種業(yè)務(wù)[9]。

本研究系統(tǒng)中的所有醫(yī)保業(yè)務(wù)都支持醫(yī)保電子憑證掃碼操作，參保人可通過國家醫(yī)保APP 或者微信、支付寶等經(jīng)由國家醫(yī)保局認證授權(quán)的第三方渠道激活使用[10]。為持續(xù)推進我院醫(yī)保電子憑證結(jié)算工作，系統(tǒng)在醫(yī)保掛號前會提示收費員優(yōu)先使用醫(yī)保電子憑證，導(dǎo)診護士在門診各收費窗口醒目位置為患者提供微信與支付寶的醫(yī)保電子憑證掃碼圖，引導(dǎo)患者使用醫(yī)保電子憑證進行結(jié)算。系統(tǒng)提供每月電子憑證結(jié)算率排名功能，對電子憑證結(jié)算率超過50%的人員給予獎勵。

2.2 醫(yī)保人員建檔與綁定

前端應(yīng)用程序通過調(diào)用醫(yī)保1101 交易獲取醫(yī)保人員基本信息，包含參保狀態(tài)、參保日期、身份信息、單位信息等，將信息導(dǎo)入系統(tǒng)進行人員信息院內(nèi)建檔。如果患者是二代醫(yī)?？〒Q三代醫(yī)?？ǖ那闆r，系統(tǒng)會提示未綁定時無法獲取醫(yī)保信息，應(yīng)使用醫(yī)保電子憑證就診。在實際使用醫(yī)保電子憑證時，有一部分患者通過電子掃碼墩讀出來的信息是沒有卡號或者卡號是9 個0 但有身份證信息，此時系統(tǒng)會通過讀取到的身份證號查找院內(nèi)患者數(shù)據(jù)庫，通過醫(yī)?？ㄌ柣蛏矸葑C號找到院內(nèi)患者，與患者核對后進行醫(yī)?？ǖ慕壎?；如果沒有找到，則進行醫(yī)保人員院內(nèi)信息建檔。針對同一張醫(yī)保卡綁定院內(nèi)多個患者ID 號的情況，操作員可通過系統(tǒng)列表選擇要結(jié)算的患者ID。

2.3 門診掛號

通過調(diào)用醫(yī)保2201A 交易進行門診掛號，首先需通過實體卡讀取卡號驗證身份信息，電子憑證通過掃碼墩解析獲取電子憑證令牌ecToken 信息驗證；掛號成功后，醫(yī)保返回唯一流水號就診ID；下一步就診信息上傳、費用上傳、結(jié)算將以此就診ID 為唯一標識。

2.4 門診就診信息上傳

通過調(diào)用醫(yī)保2203A 交易上傳門診就診及診斷信息。若患者需要辦理特殊病種，在此上傳特殊病種編碼。若當日就診醫(yī)生為患者開具多種特殊病種，系統(tǒng)提供按特殊病種分組功能，方便收費員以整個病種選擇收費項目進行結(jié)算。因可能存在由于醫(yī)生開具的診斷編碼不規(guī)范（非國家醫(yī)保的診斷編碼），導(dǎo)致醫(yī)保掛號失敗，患者需要再去找醫(yī)生修正診斷編碼的情況，系統(tǒng)提供國家醫(yī)保診斷編碼字典庫，供操作員調(diào)閱診斷名稱和編碼，在與醫(yī)生確認后，修改診斷編碼，實現(xiàn)讓“數(shù)據(jù)多跑路，群眾少跑腿”[11]。

2.5 門診費用明細信息上傳

通過調(diào)用醫(yī)保2204 交易上傳門診費用明細信息。返回費用明細項符合政策范圍金額、自付比例、先行自付金額等，根據(jù)醫(yī)院審批標志，配合醫(yī)保目錄的限制使用標志使用，納入報銷處理或按自費處理；如診斷為健康查體的，不適用于統(tǒng)籌金不能進行醫(yī)保報銷即返回全自費金額。

2.6 門診結(jié)算

通過調(diào)用醫(yī)保2207A 交易進行門診正式結(jié)算。在醫(yī)保結(jié)算前，系統(tǒng)會自動調(diào)用醫(yī)保3102 交易（明細審核事中分析服務(wù)），查詢患者是否有醫(yī)保違規(guī)信息。如果沒有則繼續(xù)結(jié)算，如果有則根據(jù)違規(guī)的內(nèi)容，選擇遵從或不遵從，不遵從需要填寫原因，反饋至醫(yī)保。

醫(yī)保結(jié)算支持本地結(jié)算、省內(nèi)異地結(jié)算、跨省異地結(jié)算。醫(yī)保結(jié)算成功后，再進行院內(nèi)結(jié)算時，如果患者的預(yù)交金不足，系統(tǒng)自動彈出預(yù)交金充值界面讓患者充值。醫(yī)保結(jié)算如果交易失敗，系統(tǒng)則顯示結(jié)算失敗的詳細原因（如門診特殊病種未備案、病種類型不屬于國家門診慢特病種、患者住院期間不允許結(jié)門診等），省外患者由系統(tǒng)自動發(fā)起醫(yī)保沖銷2208 交易，省內(nèi)患者則發(fā)起醫(yī)保沖正2601 交易，省內(nèi)省外通過讀取患者參保地進行判別。

系統(tǒng)提供醫(yī)保兩定網(wǎng)址查詢功能，用于操作員再次確認患者醫(yī)保結(jié)算信息。系統(tǒng)發(fā)起醫(yī)保沖正交易前，首先通過醫(yī)保結(jié)算ID 號以及患者ID 號，查詢院內(nèi)HIS 是否已經(jīng)結(jié)算過，如果院內(nèi)HIS 結(jié)算成功，則不允許沖正，必須走醫(yī)保退費流程。否則，會造成單邊賬即醫(yī)保端沒有結(jié)算數(shù)據(jù)、醫(yī)院端有數(shù)據(jù)，醫(yī)保不撥付，使醫(yī)院蒙受經(jīng)濟損失。

2.7 醫(yī)保退費

首先調(diào)用醫(yī)保2208 交易進行門診結(jié)算撤銷，再調(diào)用醫(yī)保2205 交易撤銷門診費用明細信息。交易成功后再執(zhí)行院內(nèi)HIS 退費操作，將退款的金額充入患者的預(yù)交金。如果是跨筆沖銷則提示收費員應(yīng)逐筆沖銷，以及應(yīng)先沖銷的醫(yī)保結(jié)算ID 號。

2.8 醫(yī)保單邊賬處理

2.8.1 醫(yī)保手工沖正

通過調(diào)用醫(yī)保2601 交易進行手工沖正，即當定點醫(yī)藥機構(gòu)發(fā)起某項交易時，因網(wǎng)絡(luò)中斷或超時等原因?qū)е聼o法獲取接收方狀態(tài)，導(dǎo)致多方數(shù)據(jù)不一致或已確認接收方數(shù)據(jù)多時，可通過沖正取消接收方相應(yīng)數(shù)據(jù)，保持雙方數(shù)據(jù)一致。

當醫(yī)保端結(jié)算成功、但院內(nèi)結(jié)算失敗時，系統(tǒng)提供手工沖正功能，沖正成功后，再重新進行結(jié)算。操作流程為：錄入欲沖正的醫(yī)保結(jié)算ID 號、人員編號（通過讀卡器讀取）、msgid 等信息進行沖正；系統(tǒng)將沖正操作的醫(yī)保結(jié)算ID 號、操作員編號記錄成日志文件上傳至院內(nèi)服務(wù)器。每月與醫(yī)保對賬時，如果發(fā)生因收費員操作失誤，沖正到正常的結(jié)算ID，醫(yī)保不撥付款，導(dǎo)致醫(yī)院少收費，則日志文件成為責任追查的依據(jù)。同時，為降低操作失誤率，在操作前加入主管口令進行驗證。

2.8.2 收費員手工退票

若由于收費員輸錯ID 號等誤操作，對正常結(jié)算的醫(yī)保ID 號進行了沖銷，導(dǎo)致院內(nèi)單邊賬。此時醫(yī)保端已沖銷（醫(yī)保端金額為一正一負）、院內(nèi)結(jié)算成功，系統(tǒng)提供收費員手工退票功能，將院內(nèi)結(jié)算的費用進行退票，費用退回患者預(yù)交金中，實現(xiàn)與醫(yī)保端兩邊對賬一致。

2.9 醫(yī)療保障基金結(jié)算清單信息上傳

通過調(diào)用醫(yī)保4101A 交易上傳醫(yī)療保障基金結(jié)算清單信息，系統(tǒng)根據(jù)門診結(jié)算數(shù)據(jù)，生成醫(yī)療保障基金結(jié)算清單信息，提交醫(yī)保中心進行審核。

2.10 實時日志記錄

在醫(yī)保結(jié)算過程中，為了方便查詢醫(yī)保結(jié)算過程中的信息，將每次與醫(yī)保端交互的請求報文、輸出報文、接口返回狀態(tài)值等信息，以結(jié)算患者的院內(nèi)ID 號為一級索引、結(jié)算日期為二級索引的文件目錄方式，生成日志文件。

使用Microsoft Windows 服務(wù)能夠創(chuàng)建在其Windows會話中可長時間運行的可執(zhí)行應(yīng)用程序。這些服務(wù)可以在計算機啟動時自動啟動，可以暫停和重新啟動而且不顯示任何用戶界面[12]?？蛻舳诉\行自主開發(fā)的Windows系統(tǒng)服務(wù)（服務(wù)名：醫(yī)保日志上傳），定時將客戶端本地與醫(yī)保交互的日志文件上傳至院內(nèi)日志服務(wù)器指定目錄，見圖5。在出現(xiàn)結(jié)算金額不一致，或者項目金額對不上等異常的情況時，通過患者的院內(nèi)ID 號查找對應(yīng)的日志文件進行分析與查詢HIS 數(shù)據(jù)，從而找到問題的原因并解決。

圖5 上傳的醫(yī)保交易日志

3 應(yīng)用效果

系統(tǒng)自2022 年4 月上線以來，門診醫(yī)保結(jié)算日平均結(jié)算量2800 筆左右，平均結(jié)算速度為0.8 s，每月電子憑證結(jié)算率保持在52%以上，受到地方醫(yī)保局的表揚。隨機抽取新系統(tǒng)2022 年5 月期間10 d 的數(shù)據(jù)作為研究樣本，舊系統(tǒng)2021 年5 月期間10 d 數(shù)據(jù)作為對照樣本，比較兩組樣本的患者等候時間、醫(yī)保結(jié)算完成時間、差錯率的差異。其中，患者等候時間：通過統(tǒng)計各醫(yī)保結(jié)算窗口患者排隊叫號時間間隔，匯總等待時間除以人數(shù)得出平均等候時間；醫(yī)保結(jié)算完成時間：統(tǒng)計患者醫(yī)保掛號交易到醫(yī)保結(jié)算交易成功的兩個交易日志產(chǎn)生的時間間隔，匯總各患者醫(yī)保結(jié)算完成時間求出平均結(jié)算時間。

選擇SPSS 26.0 軟件進行數(shù)據(jù)統(tǒng)計分析，計量數(shù)據(jù)以±s的形式表示，行獨立樣本t檢驗，以P＜0.05 為差異有統(tǒng)計學意義。

新系統(tǒng)上線后，患者等候時間、醫(yī)保結(jié)算完成時間、差錯率均明顯低于舊系統(tǒng)，且差異均有統(tǒng)計學意義（P＜0.05），見表1。

表1 新舊系統(tǒng)各項參數(shù)對比結(jié)果（±s）

表1 新舊系統(tǒng)各項參數(shù)對比結(jié)果（±s）

組別患者等候時間/s 醫(yī)保結(jié)算完成時間/s 差錯率/%舊系統(tǒng) 181.05±3.00119.63±2.001.31±0.02新系統(tǒng)88.45±2.0058.57±1.000 t值227.941116.013478.021 P值0.0100.0100.010

相較于新系統(tǒng)使用前，操作員的工作效率大大提高，患者等待時間平均縮短了50.8%。對于操作員，原先需要在軍衛(wèi)一卡通收費程序、掛號程序與醫(yī)保收費程序3 個程序建檔、綁定、結(jié)算時來回切換操作，繁瑣且耗時耗力容易出錯，新系統(tǒng)上線后在1 個系統(tǒng)就可以完成所有操作，大大降低了操作員的工作強度，簡化了操作流程。早期軍衛(wèi)系統(tǒng)是C/S 架構(gòu)，直接與數(shù)據(jù)庫服務(wù)器相連，造成服務(wù)器負擔重、反應(yīng)慢。新系統(tǒng)上線后，停用客戶端的多個C/S 程序（一卡通收費程序、掛號程序與醫(yī)保收費程序等），減少500 多個數(shù)據(jù)庫連接數(shù)（目前醫(yī)院各個系統(tǒng)數(shù)據(jù)庫連接數(shù)約3000 個左右），大大緩解了數(shù)據(jù)庫服務(wù)器的壓力，推進了醫(yī)院信息系統(tǒng)往更合理的架構(gòu)方向發(fā)展。本系統(tǒng)也為“軍衛(wèi)一號”的其他擴展性開發(fā)提供了新的思路。

4 討論

以往的研究多是將整個項目改造成Winform 應(yīng)用程序，如武警廣西總隊醫(yī)院HIS 的改造開發(fā)工具采用Sybase PowerBuiIder 11.0（簡稱PB）[13]；解放軍聯(lián)勤保障部隊北戴河康復(fù)療養(yǎng)中心用PB 9.0 研發(fā)了一套醫(yī)保智慧互聯(lián)平臺系統(tǒng)，實現(xiàn)軍衛(wèi)系統(tǒng)與醫(yī)保系統(tǒng)的對接[14]。但其缺點是與后臺數(shù)據(jù)庫交互都是兩層C/S 架構(gòu)，數(shù)據(jù)庫服務(wù)器負載重、擴展性差，不如Spring MVC 框架靈活、可擴展性好、性能高。也有研究將整個項目改造成Web項目，前端代碼和后端代碼混合在一起，如ASP、JSP技術(shù)等，這種開發(fā)模式存在代碼可讀性差、開發(fā)效率低等問題[15]。本研究結(jié)合兩者的優(yōu)點，前端采用SunnyUI框架開發(fā)Winform 應(yīng)用程序進行數(shù)據(jù)渲染，后端采用Spring MVC+MyBatis 框架Java 設(shè)計，前后端解耦，并行開發(fā)，節(jié)約開發(fā)時間，使得開發(fā)變得清晰明了。后期業(yè)務(wù)擴展通過增加后端服務(wù)器提高系統(tǒng)的處理能力和負載能力，系統(tǒng)性能更好。本系統(tǒng)是“軍衛(wèi)一號”系統(tǒng)的創(chuàng)新應(yīng)用，將“軍衛(wèi)一號”系統(tǒng)中的身份登記子系統(tǒng)、門診掛號子系統(tǒng)、門診醫(yī)保收費子系統(tǒng)以及一卡通收費子系統(tǒng)的功能集成到新系統(tǒng)[16]，滿足門診收費信息管理和醫(yī)保結(jié)算的需要，摒棄了原來多個子系統(tǒng)切換的工作模式，大大提高了工作效率，減少和避免了信息轉(zhuǎn)錄過程中的人為誤差，使數(shù)據(jù)錄入更加便捷，數(shù)據(jù)安全性、完整性和規(guī)范性得到全面提高。

目前系統(tǒng)已在我院門診穩(wěn)定運行，醫(yī)保結(jié)算速度快，操作方便，大大緩解了收費窗口的工作壓力。通過系統(tǒng)的上線，推進了我院醫(yī)保標準化信息化的建設(shè)，順利完成軍衛(wèi)HIS 改造與地方醫(yī)療保障信息平臺對接工作。由于醫(yī)保結(jié)算速度快，方便來院患者醫(yī)保就診，減少結(jié)算等待時間，深受就醫(yī)患者好評。該系統(tǒng)具備極強的可行性與實用性，為操作員、醫(yī)護人員、患者提供便捷化、信息化的醫(yī)保結(jié)算平臺。目前系統(tǒng)也在不斷完善中，難點是軍衛(wèi)一卡通收費程序的發(fā)票打印功能是通過票控盤控制，要移植到新系統(tǒng)需要進一步研究與評估。下一步，將從重構(gòu)代碼提高性能、增加功能模塊這兩方面來進一步完善系統(tǒng)，提高用戶的使用體驗，使本系統(tǒng)具有更大的現(xiàn)實意義與使用價值。