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

陳建福

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

引言

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

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

開(kāi)發(fā)統(tǒng)一接入平臺(tái)以服務(wù)接口的方式提供醫(yī)院數(shù)據(jù)接口服務(wù)，前端使用SunnyUI 框架開(kāi)發(fā)Winform 應(yīng)用程序，應(yīng)用程序請(qǐng)求后臺(tái)接口與醫(yī)院信息系統(tǒng)（Hospital Information System，HIS）數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互。通過(guò)調(diào)用國(guó)家平臺(tái)動(dòng)態(tài)庫(kù)（chs_fjs_standard.dll）的函數(shù)接口與醫(yī)保端進(jìn)行交互，完成醫(yī)保業(yè)務(wù)。系統(tǒng)中數(shù)據(jù)交互格式為JSON 格式，JSON 作為JavaScript 的一個(gè)子集，是一種純文本的數(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)一號(hào)”HIS

如圖1 所示，醫(yī)院數(shù)據(jù)接口服務(wù)基于Spring MVC+MyBatis框架構(gòu)建，使用Java語(yǔ)言進(jìn)行開(kāi)發(fā)，與數(shù)據(jù)庫(kù)的持久層進(jìn)行交互，框架包括控制器層、服務(wù)層和數(shù)據(jù)訪問(wèn)層3層。處理流程為：前端Winform應(yīng)用程序通過(guò)http方式請(qǐng)求后臺(tái)數(shù)據(jù)，服務(wù)器中Spring MVC的DispatcherServlet模塊攔截請(qǐng)求后轉(zhuǎn)給與之對(duì)應(yīng)的控制器層調(diào)用對(duì)應(yīng)服務(wù)層處理業(yè)務(wù)邏輯，服務(wù)層向數(shù)據(jù)訪問(wèn)層的MyBatis發(fā)送請(qǐng)求，MyBatis與數(shù)據(jù)庫(kù)交互后將結(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 安全認(rèn)證獲取Access Token 的方式，所有請(qǐng)求都必須帶有Token信息。OAuth2.0 協(xié)議為當(dāng)下較流行的身份認(rèn)證授權(quán)協(xié)議，該框架具有5 種模式：授權(quán)碼模式、簡(jiǎn)單模式、密碼模式、客戶端模式和拓展模式[7]。醫(yī)院數(shù)據(jù)接口服務(wù)基于授權(quán)碼模式實(shí)現(xiàn)接口訪問(wèn)授權(quán)，OAuth2.0 為客戶端提供了一種代表資源擁有者訪問(wèn)受保護(hù)資源的方法。使用授權(quán)碼模式完成OAuth2.0 授權(quán)的過(guò)程包括3 個(gè)步驟：① Client請(qǐng)求授權(quán)服務(wù)端，獲取AuthorizationCode；② Client 通過(guò)AuthorizationCode 再次請(qǐng)求授權(quán)服務(wù)端，獲取Access Token；③ Client 通過(guò)服務(wù)端返回的Access Token 獲取用戶的基本信息[8]。

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

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

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

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

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

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

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

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

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

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

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

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

2.3 門診掛號(hào)

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

2.4 門診就診信息上傳

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

2.5 門診費(fèi)用明細(xì)信息上傳

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

2.6 門診結(jié)算

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

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

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

2.7 醫(yī)保退費(fèi)

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

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

2.8.1 醫(yī)保手工沖正

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

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

2.8.2 收費(fèi)員手工退票

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

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

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

2.10 實(shí)時(shí)日志記錄

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

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

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

3 應(yīng)用效果

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

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

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

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

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

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

4 討論

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

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