連云港市城鎮居民醫療保險信息系統設計探討

摘要：醫療保險信息系統的規劃設計，重點探討了客戶端應用軟件的自動更新、ORACLE用戶密碼的安全管理、客戶端應用軟件操作權限管理，并就定點醫療機構操作員的管理提出設想。

關鍵詞：自動更新；安全管理

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)36-3029-02

我市城鎮居民基本醫療保險計算機信息系統已經運行近一年了，目前運行高效、穩定。這與最初的系統設計的高要求、高起點是分不開的。本系統在設計時就引進很多先進開發理念，與開發實力強大的江蘇正融科技有限公司合作，采用成熟穩定的開發工具及ORACLE數據庫軟件，實現了客戶端應用軟件的自動強制更新、ORACLE用戶密碼的安全管理、客戶端軟件操作權限多層次管理，確保系統的先進性和可靠性。

1 客戶端應用軟件的自動更新

目前大型的數據庫應用采用的基本上是B/S（Browser/Server）或C/S（Client/Server）模式，當然也可能是三層結構。盡管B/S結構有很多優點，如界面友好，軟件更新簡單等，但因為它是基于網頁瀏覽的，你能瀏覽的東西，原則上別人也能瀏覽。出于安全考慮，B/S訪問本地資源，比如串口，必須借助于其他技術實現。所以在它的安全性和執行效率方面還不盡如人意。因此B/S也不是萬能的，必須考慮實際應用場合。

C/S結構是應用最久的，雖然程序的可維護性差，布置困難，升級不方便，維護成本高。但由于其穩定性好、安全性高、運行速度快，所以在我們的應用系統中還是用的C/S結構。

我們都知道，如果客戶端軟件更新不及時，可能出現嚴重問題，例如：某軟件早期版本容許字段值不填，后來版本修改了，某個站點未能及時更新，造成數據不一致，或者業務無法進行，必須后臺解決，增加數據風險。

要解決升級維護不方便的問題，首先要理清思路，本應用系統采用多種技術妥善解決了C/S結構的升級問題，整個軟件結構包括：升級數據庫服務器（數據庫的一個表，不必單獨設立）、升級代理程序、客戶端應用程序、升級服務管理程序等。升級數據庫服務器保存軟件的版本、文件名、文件內容等信息；升級代理程序負責讀取升級數據庫服務器中的最新版本信息和文件信息，完成最新版本下載和更新，并啟動客戶端應用程序；客戶端應用程序為客戶端具體應用的程序軟件，即為需要實現更新的軟件；最新版本上載程序是升級信息管理程序，用于上傳最新的版本信息和相應的文件內容。

因為更新的是主程序，那么就必須關閉主程序。可是主程序關閉了之后，誰來調用安裝補丁呢？為了解決這個問題，我們把主程序和自動更新程序分開來做。當需要校驗版本的時候，主程序調用自動更新程序。自動更新程序如果發現主程序需要更新，在下載了升級補丁之后，就會要求關閉主程序。主程序關閉之后，自動更新程序調用升級補丁進行安裝，安裝完成后再重新啟動主程序。自動更新程序自動退出，完成更新任務。

按照以上實現思路，客戶端應用程序運行之前，先啟動一個升級代理程序，該代理從升級數據庫服務器中讀取升級信息，并與注冊表中的版本升級日期比較，如果存在最新版本，提示用戶并自動下載最新版本，解壓縮，完成升級，然后自動啟動客戶端應用程序。

1) 創建應用軟件數據表，字段包括：文件名、版本、日期和文件內容等。

create table SYS_APP_UPDATE

(FILENAMEVARCHAR2(80) not 1，

FILEVER VARCHAR2(20)，

UPDATE_DATE DATE not 1，

FILEDATALONG RAW)；

2) 升級服務管理程序

服務管理程序實際就是一個維護SYS_APP_UPDATE表的應用程序，可以修改版本信息，也可以添加新的版本信息和文件內容（上傳程序），程序內容壓縮存放在該表中。

3) 客戶端升級代理程序實現

在PB中創建一個應用，在應用的實例變量中聲明:

string old_version

declare get_new_filename cursor for

select filename

from SYS_APP_UPDATE

where filever > :old_version;

在Open事件中編寫代碼，連接數據庫、判斷版本、提示升級，升級結束后寫注冊表；如不成功自動退出程序，下次進入再次自動升級，確保程序一致性。

2 ORACLE用戶密碼的安全管理

既然采用的C/S結構，客戶端應用程序中一般都會有個配置參數文件，如PB.INI：

[Database]

DBMS=O84 Oracle 8.0.4

LogId=test

LogPassword=IgRXPOh

ServerName=center

這里可能存放連接數據庫的用戶名和密碼，可以是明碼，當然也可以加密存儲。在應用程序中打開此文件，讀取連接參數，實現各種業務功能。

但這里存在一個很嚴重的問題：我們都知道，一個數據庫應用一般都是一個ORACLE用戶名，密碼在客戶端本地存放，不論加密與否，安全都是問題；更麻煩的是如果系統修改了密碼，各客戶端的配置參數無法自動同步，會造成數據庫連接失??；密碼的定期與不定期更改是安全制度，而每次更改密碼都需要對所有客戶端參數修改一遍，工作量之大難以想象，真是令人頭疼。

是否有什么好的辦法呢？答案是肯定的！

我們可以建立ORACLE中間用戶過渡一下，客戶端本地的參數文件存放過渡用戶的帳戶（密碼可以固定在程序內），而把真正的ORACLE應用的用戶及密碼加密存放在數據庫的某個表中。

create user user-pass identified by baomi;

create table SYS_DB_CONN

( DATABASE_NAME VARCHAR2(40) not 1，

DBMSVARCHAR2(80)，

LOGID VARCHAR2(40)，

LOGPASSWORD VARCHAR2(40)，

OPERATEDATE DATE);

該表由系統用戶創建，過渡用戶僅有只讀權限，正常工作用戶對此表無權限，確保安全。

程序執行后，先連接到過渡用戶，讀取密碼表獲得連接用戶名及密碼，再次連接數據庫，開始后續工作。如果更改數據庫密碼，只需修改數據庫表中的字段，無需到各客戶端更改參數，極大地減輕維護的工作量，也可以做到經常性地更改密碼，增強了數據庫安全性。

3 客戶端應用軟件操作權限管理

應用軟件操作權限管理通常不太被重視，或者做的很簡單。其實對一個大的應用系統，特別是跨地區、業務分工明確、業務權限復雜、分布廣泛的應用至關重要。

我們的城鎮居民基本醫療保險信息系統包含四縣四區，中心端涉及窗口近兩百個，定點醫療機構近百家。用戶管理采用按級別、分層次管理，分為系統管理員，縣區管理員，操作員三大類；操作員分為縣區級、街道、社區等，每一級可對下一級進行管理。

正如一個人在社會上有各種角色：可以是領導，同時也可以兼做業務；既可以是父親，也可以是老公，還可以是兒子。我們的系統設計中也引入角色的概念，每個角色就是擁有同樣權限的一類人，完成一類工作，有自己的業務或管理權限；同時每個用戶也可以扮演多個角色。

系統可以實現角色的創建、授權；然后創建用戶，再根據用戶的工作需要給用戶授予各種角色（當然也可以專為某個用戶創建角色）；用戶用某個角色登錄系統后，就具有相應的權限，修改密碼時僅修改本角色的密碼，不同角色可以設置不同的密碼（例如：不會因為告訴別人業務密碼導致管理密碼泄密）。大致結構如右圖所示。

盡管本系統具備很多優點，但也并非盡善盡美。因為需求是不斷變化的，軟件的發展潛力是巨大的，這里我想就其中一個問題與大家探討一下：

隨著醫療覆蓋面的擴大，定點醫療結構也成倍增加，對定點結構的監管也提出更高的要求。但畢竟醫療監管工作量大，人員少，力量有限，定點醫院違規操作的事情時有發生。增加違規成本（罰款、停業等）固然是個辦法，但執行起來難度不小。

基于此，我們設想是否可以在軟件程序上做些事情，配合監管以期達到更好的效果呢？

我們知道：定點結構的結算都是通過操作員完成的，加強對操作員的學習培訓，實行操作員的準入制度，并發給操作卡，要求操作員持證上崗，進入系統需要刷卡，對操作員實行記分管理，積分達到一定值，取消操作卡。

這就如同駕駛員的管理，駕駛過程中不會說領導叫違章就違章，他還需要考慮個人違章成本，即使罰款可以報銷，但吊銷駕駛證可沒幾人原意。這種做法表面上是對操作員不利，其實對他們更是一種保障。能取得操作卡就是一種資格，單位聘用后憑合同到中心備案，并在數據庫中與該定點機構關聯，進入收費系統時要先刷卡，系統可自動識別用戶名，再配合密碼，實現多重安全保障。即使卡被別人拿走，也需要密碼才能進入系統。

當然這僅是個人的一點設想，還不夠成熟，未能在本系統實現，在此拋磚引玉，希望有志之士共同完善此設想并早日實現。我衷心祝愿我們的城鎮居民基本醫療保險信息系統更加完善，功能更加強大，更好地服務于醫療保險。

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。”