許思特,黃子碩,馬振凱,吳 斌,劉佳興,盛 韜,戴瑞明,羅 力,張?zhí)焯?/p>

1(復旦大學 公共衛(wèi)生學院,上海 200032)

2(同濟大學 土木工程學院,上海 200092)

3(復旦大學 計算機科學技術學院,上海 201203)

4(復旦大學 軟件學院,上海 200082)

近年來,國家簡政放權治國理念逐步落實,對基本醫(yī)療保險定點醫(yī)藥機構的管理方式由“行政審批”轉向“全面實施協(xié)議化管理”.協(xié)議規(guī)定,基本醫(yī)療保險定點零售藥店(以下簡稱“定點藥店”)只要符合基本的醫(yī)保準入條件就可取得相應的醫(yī)保定點經(jīng)營資格.該項政策的實施,提升了藥店醫(yī)保資格的審批速度,全國藥店經(jīng)營者反響積極,全國定點藥店的數(shù)量呈現(xiàn)成倍增長的趨勢.

長期以來,醫(yī)保零售藥店以數(shù)量多、連鎖率低、騙保行為層出不窮等,成為醫(yī)保基金潛在的威脅和監(jiān)管難題.為解決這一醫(yī)保定點機構管理領域的癥結,國內(nèi)各地都做出了相應嘗試,將信息化手段運用于定點零售藥店管理.如西安建立的“醫(yī)保智能監(jiān)控審核系統(tǒng)”以及天津市采用的“創(chuàng)新型協(xié)議管理考核系統(tǒng)”,都以信息化手段對醫(yī)療服務行為開展了事中監(jiān)控與事后追蹤,一定程度有效監(jiān)控了醫(yī)療服務行為.

隨著信息管理系統(tǒng)的構建推廣,相關問題也隨之而來.如何將科學的機構管理理論、方法與信息技術進行有效結合,仍是當下亟待解決的難點.如今的國內(nèi)醫(yī)保領域,相關管理系統(tǒng)就普遍存在著以下兩方面的問題.

(1)隨著數(shù)據(jù)量的幾何增長,所涉及的相關部門、人員不斷增多,管理部門對信息系統(tǒng)的健壯程度、安全性、并發(fā)速度等有著越來越高的要求.而采用傳統(tǒng)技術棧構建的軟件,明顯無法滿足上述要求.

(2)隨著信息領域技術不斷革新,越來越多優(yōu)秀高效的組件庫、插件工具等應運而生.而采用傳統(tǒng)技術棧構建的軟件,受困于自身兼容性,無法對新的技術進行有效應用,造成軟件自身成長的停滯.

因而,本文從基本醫(yī)療保險的功能出發(fā),以《上海市基本醫(yī)療保險定點零售藥店服務協(xié)議》為基礎,轉化為科學的考核指標.在充分考慮了操作便捷性、數(shù)據(jù)安全性、平臺可塑性、后續(xù)的維護、未來發(fā)展性等要求,擯棄前后端一體的傳統(tǒng)網(wǎng)頁開發(fā)模式,基于Node.js與REST 風格,選取Vue.js 與Django Rest Framework框架,獨立開發(fā)了醫(yī)保定點藥店履約情況考核評估系統(tǒng).實現(xiàn)了自我評議與專家評議功能,助力醫(yī)保經(jīng)辦機構貫徹落實參保人員意志,提高醫(yī)療保險日常監(jiān)管水平,確?；踞t(yī)療保險制度穩(wěn)健運行的目的.

1 系統(tǒng)需求

鑒于考核內(nèi)容和考核結果的數(shù)據(jù)具有一定的敏感性,醫(yī)保機構需要建立一套完整、獨立、安全的考核系統(tǒng).為保證后續(xù)可塑性、兼容性、拓展性、以及多平臺的聯(lián)動性,須重新開發(fā)考核系統(tǒng)并持續(xù)維護.

本系統(tǒng)平臺作為供醫(yī)療保險經(jīng)辦機構或其他監(jiān)管部門使用的工具,用以輔助開展基本醫(yī)療保險定點零售藥店履行情況的考核.適用對象包括藥店管理者、專家考核組和行政監(jiān)管者.

1.1 模塊功能需求

主要模塊包括,自評模塊與飛行檢查模塊.主要模塊功能需求如下:

(1)自評模塊,由定點藥店使用.

①系統(tǒng)需將基礎信息、地理信息與數(shù)據(jù)庫聯(lián)動,確認后正式進入填報內(nèi)容.

②系統(tǒng)需能自動生成完整報告,方便填報人核查填報內(nèi)容.

③填報內(nèi)容確認后,系統(tǒng)自動評星評級,告知相關人員待整改內(nèi)容.

(2)飛行檢查模塊,由市、區(qū)級管理者使用.

①可查看所有藥店具體填報與評級情況.

②可對藥店失實的填報內(nèi)容進行更正.

③可對考核結果進行圖表展示.

④可對考核結果進行有針對性的查詢,并將考核結果進行導出.

⑤可進行跨區(qū)考核評分.

1.2 系統(tǒng)開發(fā)需求

針對模塊功能需要,對系統(tǒng)開發(fā)的技術點需求歸納如下:

(1)數(shù)據(jù)庫

①選擇含有友好的地理功能的數(shù)據(jù)庫.用以滿足地理相關信息的操作功能.

②進行數(shù)據(jù)庫表邏輯設計.用以滿足后續(xù)數(shù)據(jù)累積需要.

(2)前端實現(xiàn)

①對框架選取.選取合適的框架,用以合理實現(xiàn)系統(tǒng)開發(fā).

②參數(shù)傳輸.選擇合適的參數(shù)傳輸方式,用以實現(xiàn)藥店填報、管理者修改檢查等功能.

③統(tǒng)計圖表可視化.實現(xiàn)統(tǒng)計圖表的可視化,用以實現(xiàn)直觀展示考核結果功能.

④地理信息可視化.結合地理信息可視化,用以確認藥店地理相關基本信息功能.

⑤考核結果表格導出.方便醫(yī)保管理者對考核結果進行管理.

⑥界面的美化.用以方便使用者直觀便捷地運用本系統(tǒng).

(3)后端實現(xiàn)

框架選取.選取合適的后端,配合前端合理實現(xiàn)系統(tǒng)開發(fā).

(4)緩存與狀態(tài)管理

選取合適的方式對用戶緩存與狀態(tài)進行管理.

(5)安全性

①注冊時邏輯匹配.用以解決藥店身份確認問題.

②修改密碼時加密.用以解決用戶個人信息安全性問題.

③自定義修改密碼頁.用以保障修改密碼的過程安全.

④利用token 對訪問等操作進行校驗.用以解決涉密數(shù)據(jù)的安全性問題.

最終,整個系統(tǒng)應實現(xiàn)各數(shù)據(jù)庫的匯總、存儲與數(shù)據(jù)表反饋.根據(jù)測試上傳更新的數(shù)據(jù)庫,通過常模識別方法,調(diào)整基于考核主體的常規(guī)模式的更新.輸出多維序列數(shù)據(jù)的可視化結果,用于反饋報告.并對多維序列數(shù)據(jù)結果與常模情況做提示報告,識別異常指標.為自評考核和飛行檢查提供了可直觀、便捷、安全的信息化平臺,通過量化得分的方式輔助實現(xiàn)了醫(yī)療保險協(xié)議化管理,提出干預意見供醫(yī)保部門參考,用于有針對性的飛行檢查、聯(lián)合治理或常模算法的調(diào)整.

2 系統(tǒng)開發(fā)

本研究在進行了充分的文件查閱和探索后,擯棄了當下大多數(shù)考核系統(tǒng)的傳統(tǒng)開發(fā)模式,選取了前后端分離的網(wǎng)頁開發(fā)模式.原因如下:

常見Web 應用模式分兩種:一是前后端不分離.在前后端不分離的引用模式中,前端頁面效果由后端頁面渲染或者重定向,前后端的耦合度很高,但是后端對接APP 時,并不總需要后端返回HTML 網(wǎng)頁,而僅是數(shù)據(jù)本身[1].所以后端原本返回網(wǎng)頁的接口不再適用前端APP 應用,為了對接APP 后端還需再開發(fā)一套接口.

二是前后端分離.在前后端分離的應用模式中,后端僅返回前端所需要的數(shù)據(jù),從后端請求的數(shù)據(jù)如何加載到前端中,都由前端自己決定,后端僅需開發(fā)一套邏輯對外提供數(shù)據(jù)即可.在前后端分離的應用模式中,前端與后端的耦合度相對較低.該模式下,通常將后端開發(fā)的每一視圖都成為一個接口,或者API,前端通過訪問接口來對數(shù)據(jù)進行增刪改查[2].

根據(jù)不同模式的特點,我們選取前后端分離模式,該模式具有以下優(yōu)勢:前端靜態(tài)資源與后臺API 分流,互不影響;前后臺同步開發(fā),減少溝通成本;方便開發(fā)調(diào)試,不影響工作進度;易于維護擴展.

本文針對項目需求,提煉關鍵技術點進行系統(tǒng)開發(fā),從數(shù)據(jù)庫、前端、后端、緩存、安全性5 個方面著手解決對關鍵技術點的要求.

2.1 數(shù)據(jù)庫

(1)數(shù)據(jù)庫選用

本履約考核系統(tǒng)的數(shù)據(jù)庫選用了PostgreSQL,PostgreSQL 是一個功能強大的開源對象關系數(shù)據(jù)庫系統(tǒng),它結合了許多安全存儲以及擴展復雜數(shù)據(jù)工作負載的功能,使用和擴展了SQL 語言[3].

PostgreSQL 憑借其經(jīng)過驗證的架構,可靠性,數(shù)據(jù)完整性,強大的功能集,可擴展性,使得PostgreSQL 在所有主要操作系統(tǒng)上運行,自2001年以來一直是符合ACID 標準的,并且具有強大的附加功能,例如流行的PostGIS 地理空間數(shù)據(jù)庫擴展器[4].

(2)數(shù)據(jù)庫邏輯設計

基于PostgreSQL 的特點,我們對數(shù)據(jù)庫進行了邏輯設計,見圖1.

authorization_rolecode 表和shdistrict 表用以確定市級、區(qū)級、藥店的角色與權限.authorization_user 表用以儲存用戶注冊信息,包含藥店注冊信息和市區(qū)級信息.繼而根據(jù)角色分為自評表Yd_in 表與區(qū)評表Shdistrict_in 表,由藥店自評填入與區(qū)級管理者區(qū)評填入.最終各表匯總于Yd_show 表.

經(jīng)驗證,該數(shù)據(jù)庫設計滿足巴斯范式,在正常使用中不存在修改異常、插入異常和刪除異常.

2.2 前端實現(xiàn)

(1)Node.js

整個系統(tǒng)前端基于Node.js 完成,Node.js 的官方說明,介紹其是一個JavaScript 的運行環(huán)境.采用了一個事件驅(qū)動設計,并且它是非阻塞式I/O 模型,這樣使得它不僅變得輕量而且愈發(fā)高效.它的最初設計的目標,是實現(xiàn)高性能的Web,能夠高并發(fā)地處理網(wǎng)絡請求的連接,快速地進行可擴展互聯(lián)網(wǎng)應用的搭建.

(2)Vue 框架特點

基于Node.js 環(huán)境,本文選擇Vue.js 框架進行開發(fā).在多個方面,Vue.js 都與其它主流框架有著差異以及優(yōu)勢.以框架體積為例,相比較React 的43 kb 和Angular 的143 kb,只有23 kb 的Vue.js 明顯是更為的精簡[5].

此外,組件化是Vue 的主要特點之一.在前端開發(fā)中,組件就是視UI 樣式和對應功能為獨立的小整體.無論該小整體在哪個模塊被調(diào)用,它都可以具備一樣的功能和樣式,從而實現(xiàn)靈活性以及復用性.

Vue 將前端的HTML+CSS+js 文件都放到一個文件中.vue 里面.

封裝格式如下:

HTML (結構):被Vue 封裝在＜template>中,

CSS(樣式):對應＜style>,

JavaScript:對應＜script>.

數(shù)據(jù)綁定是Vue 的另一大特點.以往的應用開發(fā)中,前端狀態(tài)數(shù)據(jù)、文檔結構數(shù)據(jù)的管理存儲是相當復雜和棘手的一個部分.Vue 將底層數(shù)據(jù)與視圖進行對應,進入頁面時會參照el 屬性將掛載的DOM 元素進行實例化,轉為成Vue 實例.數(shù)據(jù)與文檔DOM 結構綁定在一起,在數(shù)據(jù)和結構UI 之間建立響應式的映射關系.使用特殊的v-model 指令,實現(xiàn)雙向綁定關系.將開發(fā)者對DOM 的操作性大大降低,避免客戶端壓力的同時,將開發(fā)者的工作經(jīng)歷重心集中于邏輯的處理.

關鍵代碼如下:

(3)前后端交互傳參

確定前后端分離的開發(fā)模式后,整個系統(tǒng)的藥店填報、區(qū)級改查、跨區(qū)互評大多是基于前端往后端接口傳輸交互.以post 接口為例.

關鍵代碼如下:

(4)V-charts 實現(xiàn)統(tǒng)計圖

在使用 echarts 進行圖表的生成時,常常無可避免地進行數(shù)據(jù)類型的繁瑣轉化、復雜配置項的修改,而V-charts 的出現(xiàn)解決了這個問題.基于Vue2.0 和echarts封裝的 V-charts 圖表組件,只需要統(tǒng)一提供一種對前后端都友好的數(shù)據(jù)格式設置簡單的配置項,便可輕松生成常見的圖表.V-charts 已經(jīng)處理了關于echarts 依賴引入的問題,保證所使用的圖表,都是最小的文件.

本文借助Vue 組件化開發(fā),封裝echarts 的圖表庫,抽象出標題、系列數(shù)據(jù)、圖例、坐標軸、背景顏色、系列顏色、字體顏色等配置信息,實現(xiàn)可復用的圖表組件.

關鍵代碼如下:

(5)Leaflet 實現(xiàn)地理定位

Leaflet 是一個為移動設備設計的交互式地圖的開源的Javascript 庫,并只有38 k,涵蓋了大多數(shù)情況下需要的地圖特點.根據(jù)藥店經(jīng)緯度坐標返回的Geo-JSON 編碼,利用Leaflet 插件將藥店坐標打點,并渲染至前端.

關鍵代碼如下:

(6)表格導出與篩選

下載Blob.js 和Export2Excel.js,在src 目錄下新建Excel 文件夾,里面放入Blob.js 和Export2Excel.js兩個JS 文件,并在main.js 引入文件.

組建中使用methods 添加.tHeader 是表頭,filterVal中的數(shù)據(jù)是表格的字段,tableData 中存放表格里的數(shù)據(jù),類型為數(shù)組,里面存放對象,表格的每一行為一個對象[6].

關鍵代碼如下:

(7)界面UI 美化

選取Element.UI,該UI 庫是一套為開發(fā)者、設計師和產(chǎn)品經(jīng)理準備的基于 Vue 2.0 的桌面端組件庫,簡約美觀,能滿足大多數(shù)前端開發(fā)者的需求.

關鍵代碼如下:

2.3 后端實現(xiàn)

(1)后端框架選取

本系統(tǒng)后端選擇Django Rest Framework 框架.它是一個強大且靈活的工具包,用以構建Web API.Django REST Framework 可以將Django 為基礎,快速實現(xiàn)REST 風格API,并且自身還帶有WEB 的測試頁面,可以便捷地測試自己的API.

(2)DRF 應用

Django Rest Framework 的流程大致如下:

建立 Models;依靠 Serializers,Parse 數(shù)據(jù)庫取出的數(shù)據(jù)為API 的數(shù)據(jù);ViewSet 是一個 views 的集合,根據(jù)客戶端的請求,進而返回 Serializers 處理的數(shù)據(jù);權限 Premissions 也在這一步做處理;ViewSet 可在Routers 進行注冊,注冊后會顯示在API Root 頁上;在urls 里注冊 ViewSet 生成的 view,指定監(jiān)聽的 URL[7].

關鍵代碼如下:

2.4 緩存與狀態(tài)管理

Store.js 是一個localStorage 的包裝器,兼容所有的瀏覽器,并不需要借助Flash 或是Cookie.store.js 會根據(jù)瀏覽器自動選擇使用userData、globalStorage 或者localStorage 來實現(xiàn)一個本地存儲功能[8].

Vuex 通過state、mutation、getter 進行狀態(tài)管理.

Vuex 與Globalbus 類似,但在條理性上優(yōu)于后者.以將需要用的信息存入localStorage 中,并根據(jù)不同情況判斷是否清除這些信息為例.

關鍵代碼如下:

2.5 安全性

(1)注冊時邏輯匹配

根據(jù)不同情況向前端返回不同的HTTP 狀態(tài)碼.

注冊成功:若是數(shù)據(jù)庫中有信息的老藥店,則返回201,接著進入基本信息確認、地理信息確認,繼而進入填報系統(tǒng);若是數(shù)據(jù)庫中沒有信息的新藥店,則返回202,并直接進入填報系統(tǒng).

注冊失敗:若是基本信息不匹配,如許可證號與交易代碼不對應,或是用戶已注冊過,則返回401 并在前端alert;若是角色不匹配,則返回402 并在前端alert.

關鍵代碼如下:

(2)修改密碼時加密

若用傳統(tǒng)update 接口修改密碼,會造成密碼直接暴露的隱患,因而需要再次序列化加密.

關鍵代碼如下:

(3)自定義修改密碼頁

將Django 自帶的密碼相關html 封裝出來并引入.切不可直接改庫文件,以免在部署時出現(xiàn)問題.可在settings 引入用以替代.

關鍵代碼如下:

關鍵代碼如下:

可利用Django 本身防止XSS 注入攻擊和防止CSRF 跨站攻擊的特性防止相應攻擊.需要加密的數(shù)據(jù)也會提交到處理與加密部分減少由于數(shù)據(jù)泄露造成的二次危害.

另外,還可以根據(jù)情況自定義jwt 的返回值并封裝.

關鍵代碼如下:

另外可通過與當前時間的對比,對Token 按需進行更新、清除等操作.

關鍵代碼如下:

繼而可通過var interTime=newCurtimePlus - jwt["exp"]判斷是否需要對Token 進行操作[9].

除了在headers 中加Token 進行驗證外,也可設置白名單.在切換白名單外的URL 路徑時,往Django 自帶的后端驗證接口進行post 操作,驗證localStorage 中的CsrfToken.若密鑰過期,則需重新登陸.

關鍵代碼如下:

3 系統(tǒng)展示

對系統(tǒng)關鍵環(huán)節(jié)進行截圖展示,敏感信息已被打碼.

3.1 藥店填報

(1)登錄注冊

注冊后,用戶會跳至基本信息確認界面.通過Leaflet定位藥店位置,進行位置信息確認,見圖1.如若出現(xiàn)基本注冊信息不匹配現(xiàn)象,后臺數(shù)據(jù)庫會返回警示提醒.

(2)信息填報

左側導航欄是各項填報內(nèi)容,從上到下依次點擊不同的問題組件填寫,可隨時保存與重置,見圖2.全部項目填報完成后,可進行結果核查.最終系統(tǒng)根據(jù)考核權重進行計算得出自評星級與分數(shù),見圖3.

圖2 藥店定位

圖3 信息填報

3.2 管理界面

(1)總體情況

輸入管理員賬號,進入管理界面.賬號不同,權限不同,分為市、區(qū)兩級.

登錄后,數(shù)據(jù)統(tǒng)計了所有醫(yī)保定點藥店(醫(yī)保協(xié)議化管理藥店)、完成考核醫(yī)保定點藥店以及未完成考核醫(yī)保定點藥店的數(shù)目.點擊“完成考核醫(yī)保協(xié)議化管理藥店總數(shù)”,可查看完成醫(yī)保協(xié)議化管理藥店的星級以及詳細名單,見圖4.(市、區(qū)級操作相同)

(2)統(tǒng)計結果可視化

左側導航欄是功能導航欄.點擊“圖表結果”,再“點擊切換圖表類型”可以切換可視化類型.見圖5.

(3)飛行檢查

點擊“詳細結果”,會將所有醫(yī)保協(xié)議化管理藥店列出.可根據(jù)需要進行條件篩選.點擊“導出excel”可將醫(yī)保協(xié)議化管理藥店名稱,醫(yī)保交易代碼和履約考核分數(shù)導出.可進行快速搜索、詳細信息查看、填報信息查看.區(qū)級管理部門點擊“修改填報結果”,可對藥店進一步飛行檢查,進入修改界面進行不實內(nèi)容修改.見圖6.

圖4 打分評級

圖5 總體情況

圖6 結果可視化

(4)關鍵扣分項甄別

點擊“問題詳情”,可以查詢每道問題的填報結果,區(qū)分為滿分和非滿分兩類進行統(tǒng)計,甄別關鍵扣分項.見圖7和圖8.

4 結果

本系統(tǒng)界面友好簡潔,操作方便,所需功能一目了然,實現(xiàn)了基本的信息管理功能,使得考核數(shù)據(jù)的篩選、統(tǒng)計與分析工作等信息管理工作變得簡單便捷.相較于以往人力上門檢查,通過紙質(zhì)或Excel 等辦公軟件來管理填報信息的方式,免去了大量人力、信息更新與查詢統(tǒng)計等繁瑣復雜的操作,也為其他非專業(yè)人士省去了大量學習時間.經(jīng)測試及試運行顯示系統(tǒng)魯棒性強,運行良好,不僅為藥店管理者、專家考核組和行政監(jiān)管者提供了工作上的輔助,更使得能便捷且全面的了解各種考核指標履行情況的信息,為自評考核和飛行檢查提供了可直觀、便捷、安全的信息化平臺,通過量化得分的方式輔助實現(xiàn)了醫(yī)療保險協(xié)議化管理.同時,也為人民群眾享受醫(yī)療保險帶來的權利提供幫助.

圖8 關鍵扣分項甄別

具體而言:

(1)將往日繁瑣的數(shù)據(jù)填報信息化,通過簡潔的評分、排名、圖表等形式將大量信息進行直觀的表達,助力決策者快速把握全局.同時,數(shù)據(jù)可以快捷地導出.

(2)針對醫(yī)保協(xié)議化管理藥店的考核標準進行了清晰的定義,包括打分原則、權重.不僅以傳統(tǒng)醫(yī)保協(xié)議化管理藥店視角進行自查,更以實際需求為導向,對決策者進行分級,可輔助決策者實現(xiàn)更為精準的管理目標.

(3)方便二次開發(fā),適應各類考核系統(tǒng).技術上,系統(tǒng)采用Python 為基本編程語言,應用PostgreSQL 數(shù)據(jù)庫系列技術,選用Django 框架,采用面對對象的分析方法設計,用Spring MVC 框架搭建網(wǎng)站構架,完成后端的邏輯處理.以集成系統(tǒng)為核心,采用MVC、MVVM、多層、ORM 等開發(fā)框架搭建系統(tǒng),實現(xiàn)功能.采用Node.js 和Vue.js 進行Vue 腳手架組件化開發(fā),將前端渲染的簡潔有效,并在輔助與UI 設計,使網(wǎng)站更加美觀增加其實用性,提高用戶體驗.保證了對履約情況的考核評估實現(xiàn)科學化、規(guī)范化、信息化[10].

5 討論

5.1 應用效果

本系統(tǒng)已完成上海市16 個區(qū)881 家的2018年度零售藥店履約考核.參加零售藥店履約考核自評藥店881 家.其中880 家藥店完成自評考核,1 家藥店未能完成自評考核.在完成自評考核的藥店中,5 星藥店(≥95 分)652 家,4 星藥店167 家(≥90 分),3 星藥店(＜90 分)61 家

在此基礎上,各區(qū)級單位也通過本系統(tǒng)順利進行了飛行檢查工作,完成了全市履約數(shù)據(jù)庫構建,并出具了全市醫(yī)保定點零售藥店履約考核情況報告,助力醫(yī)保工作順利開展.在本次零售藥店履約考核專家抽查評審中,共涵蓋163 家藥店.其中163 家藥店完成專家考核,占所有參加考核藥店的18.5%,108 家藥店接受跨區(qū)專家考核,占所有參加考核藥店的12.3%.在完成區(qū)評考核的藥店中,5 星藥店(≥95 分)77 家,4 星藥店58 家(≥90 分),3 星藥店(＜90 分)28 家.

本輪考核周期由原先的4 周縮短至1 周,減少行政人力128 人月/年,考核結果總體良好,識別出服務質(zhì)量不合格藥店(非5 星藥店)228 家,占全部藥店總量的25.9%.在所有的扣分項的履約考核指標中,有9 項扣分最多,單項涵蓋藥店總數(shù)超過600 家.具體見表1.

5.2 存在問題

在本系統(tǒng)運作期間,經(jīng)各區(qū)反饋,部分藥店出現(xiàn)無法提交的情況.經(jīng)查,由于部分藥店設備老舊,仍在使用Win7 系統(tǒng)或低版本瀏覽器,導致系統(tǒng)部分功能失效.因而,本系統(tǒng)兼容性尚有改善空間.

綜上所述,搭建定點藥店履約考核填報管理系統(tǒng)平臺已初具成效.在未來,本履約考核系統(tǒng)可以作為常態(tài)化履約監(jiān)管手段,進行常態(tài)化縱向數(shù)據(jù)積累.繼而在與各方,包括政府部門與民間組織的合作中,逐步推進多平臺聯(lián)動運行,最終建成可以面向政府、企業(yè)、公眾的完善系統(tǒng)平臺.

表1 涵蓋藥店總數(shù)最多的指標