醫療保險管理信息系統建設初探

張弛

（連云港市醫療保險管理處，江蘇 連云港 222046）

為了全面貫徹落實國家這一惠及全民的大政方針，做好本市各用人單位及其職工參加基本醫療保險的有關工作，必須加大對醫療保險信息化的建設，全市市直、縣區分成不同的統籌區，各統籌區實行相似的政策，使用統一的軟件，避免各縣區重復開發而浪費大量的人力物力。本市選擇了東軟作為軟件開發商，各縣區分步實施，到2000年底實現全市醫保全部上線運行。

下面就從醫保系統目前的現狀和存在的問題出發，提出新的適應目前需求的醫療保險管理信息系統。

1 醫療保險管理信息系統的現狀以及存在的問題

1.1 醫療保險管理信息系統的發展狀況

我國醫療保險管理信息系統(MIMIS)的建設始于20世紀90年代后期。經過幾年的發展，醫療保險管理信息系統建設已經初具規模。信息系統的發展經歷了從單機系統、局部網絡系統到整個部門統一信息系統的多個階段。

在信息系統應用技術上，客戶/服務器結構的信息系統已經成為醫療保險信息系統的主流，使用Windows環境和圖形化的用戶界面是目前社會保障管理部門主要采用的客戶端環境，基于SQL語言訪問的大型數據庫在醫保中心、社會保障管理部門中也已普遍使用。

1.2 醫療保險管理信息系統目前存在的問題

醫療保險的特點決定了MIMIS存在本身的特點，醫療保險一般是以政府或社會組織舉辦，立法強制、統籌互濟，并且是非營利的性質。它是面向社會的，覆蓋面較廣，一些企業都必須強制參保，參保的人數較多。所以醫療保險管理信息系統就具有了政策性強、涉及面廣、信息量大等特點，因為數據量大且數據交換頻繁，所以醫療保險管理信息系統是一項非常復雜的系統工程。

由于醫療保險信息系統的這些特點，導致了我國醫療保險信息系統的建設中存在的問題很多。

比如業務流程不規范，網絡和數據庫設計還不夠完善，系統穩定性差。一些地方設計的系統只是手工操作的簡單翻版，系統運行一段時間后，才發現有很多業務流程需要優化，致使系統不得不進入第二次開發。另外，一些城市盲目追求一步到位、一勞永逸的目標，希望采用的技術最先進，系統最穩定，且能保持很長時間不被淘汰。但是由于醫保工作尚處于改革階段，一些管理模式、業務流程、組織機構的變化在所難免，致使“高大全”的目標難以實現。還有一些地方在系統建設之初，由于缺乏充分的需求分析，站的高度又不夠，開發的軟件不能適應醫保業務的變化要求，致使不少系統陷入了不死不活的尷尬境地。還有一些地方，僅僅從醫保的角度出發進行設計規劃，沒有充分考慮社會保險業務發展的一體化要求，系統割裂增加了運行成本，重復建設造成了巨大浪費。還有一些系統，由于各種各樣的原因，應用效果不理想，長期擱置不用，導致系統的發展后勁不足。除此之外，由于前兩年勞動和社會保障部門對醫保管理信息系統的建設市場沒有進行明確規范，而全國從事這個領域應用軟件開發和服務的公司非常多，競爭非常激烈，這些公司的業務系統標準規范不統一，缺乏統一管理，給醫保管理信息系統間的信息共享和信息交換造成了障礙。

2 適應需求的醫療保險管理信息系統所要達到的功能

醫療保險管理的計算機化是一項規模巨大的信息系統工程。它的基本模式是：以醫療保險管理中心為信息系統的中心，與全市各定點醫療機構、定點藥店聯網，構成一個龐大的覆蓋統籌地區的醫療保險計算機管理網絡系統。

2.1 基本的業務功能要求

系統的總體邏輯結構應根據系統的數據和功能需求，MIMIS主要由醫療保險管理中心業務子系統、定點醫院業務子系統、定點藥店業務子系統三個部分構成。

該系統涉及醫療保險管理中心、參保單位、定點醫院和藥店、財政部門、銀行等單位以及眾多的參保單位、參保職工。

參保單位：定期申報本單位參保職工的變更情況；按時進行醫療保險費的申報和繳納，定期代表單位職工到醫保中心辦理報銷業務。

參保職工：按月繳納個人應負擔的醫療保險費；持醫保IC卡到各定點醫療機構就醫或購藥。

定點醫院、藥店：按照醫療保險政策和醫保中心制訂的藥品、診療、病種等醫保目錄，完成參保職工在醫療機構的治療、購藥等服務工作，允許其持醫保IC卡結算，按約定與醫保中心結算醫療費用。醫療保險管理中心：負責單位和個人基本信息(檔案)的管理工作、負責醫?；鸬恼骼U核定工作、負責管理統籌基金收支、負責完成參保職工的特殊醫療費用的報銷、負責定期與定點醫療機構進行費用結算、負責監督檢查醫保政策在各定點醫療機構的執行情況。

2.2 子系統的功能要求

由于定點藥店業務子系統的功能相對來說并不是很重要，這里就主要把醫療保險管理中心業務子系統和定點醫院業務子系統作一下介紹。

2.2.1 醫療保險管理中心業務子系統功能

醫療保險管理中心業務子系統包括：投保服務、參保管理、基金財務管理、個人賬戶管理、醫保：IC卡管理、醫療監督管理、醫療審核管理、現金報銷管理、系統管理、統計分析、領導查詢共11大類136個業務，覆蓋了參保、征繳、實繳、緩繳、分配、變動、調動、結算、報表、查詢、統計、管理和控制等各個層面上的業務。接口包括醫療機構接口、上下級經辦機構接口、勞動主管部門接口和財務接口，滿足了上下級、同級相關部門的信息交換。

2.2.2 定點醫院業務子系統功能

定點醫院業務子系統包括：門診管理、住院管理、藥房管理、系統管理共4大類業務。其中覆蓋了門診掛號、退號、掛號日結、門診收費、退處方、門診日結、科室核算、數據查詢、藥庫的出入庫管理、門診藥房的出入庫管理、病區藥房的出入庫管理、系統參數定義、操作員管理、與醫保中心的數據傳輸等醫院各層面的業務 (見圖3)。

3 對新的醫療保險管理信息系統的具體設計和思考

根據目前MIMIS的功能需求，筆者在此對醫保信息系統提出了新的設計方法，把UML技術運用到了MIMIS中，并加強和完善了醫保系統的網絡和數據庫。

3.1 UML在醫療保險管理信息系統中的應用

下面將做的就是利用UML提供的這些技術手段運用到醫療保險管理信息系統領域建模的基本過程，并與傳統面向過程的建模過程進行比較。

3.1.1 UML簡介UML是基于面象對象的建模語言，即統一建模語言(Unified ModelingLanguage，UML)，它的前身是對象建模技術(OMT)，UML的出現，則標志著面向對象技術已進入了一個發展成熟時期，UML統一了面向對象建模的基本概念、術語和圖示符號，描述了建模過程所必須遵循的基本步驟，為學者和工程師們之間研究交流提供了共同語言。UML是一種定義清晰、易于表達，適用范圍廣的建模語言，集軟件研究領域的許多新思想、新方法、新技術于一體，強有力地支持軟件開發的全過程。

3.1.2 UML建模語言采用圖形表示法，一共定義了5類模型圖。第一類是用例圖(USE CASE)從用戶角度描述系統的功能，并列出這些功能的執行者，用例圖由表示圖例的橢圓和執行這一功能的角色構成，第二類是靜態圖，靜態圖有類圖、對象圖和包圖三種圖型符號，系統中的類用類圖定義，類圖由類名、類屬性和操作三部分組成，對象圖是類圖的一個實例，表示符號和類圖完全相同，但對象圖表示的是一個具體的對象，包圖表示了一個或多個類的組合，是一個比類更大的軟件單位。第三類是行為圖，描述系統的動態模型和對象間的交互關系。第四類是交互圖，描述對象間的交互關系。第五類是實現圖，包括組件圖和配置圖。這些基本圖示符號為系統的分析、設計建模提供了十分方便的可視化手段。

3.1.3 醫療保險管理信息系統的UML建模。使用UML建模技術進行軟件開發時，一般要經過開始、細化、構造和交接4個階段。在開始階段，根據用戶提出的需求產生角色、使用案例，并采用使用案例框圖進行可視化描述，清晰表達用戶系統的真實目標；在細化階段，首先要進一步分析開始階段產生的使用案例模型，對使用案例低層要求進行詳細描述，包括使用案例的處理流程，使用案例中涉及的角色、對象，并用交互框圖描述出所有角色對象之間的詳細交互活動及對象本身的狀態變化，用類框圖顯示要建立的類對象及其相互關系；在構造階段，和細化階段類似，圍繞使用案例來進行，根據已有的工作基礎，設計出組件和組件框圖，自下而上建立一個完整的系統模型，并通過一系列迭代過程來構造實際可用的系統，每一次迭代開發都是一個小項目，每一個小項目完成后，就向用戶演示，并完成局部系統測試，證明已正確實現了用戶要求的功能，待全部小項目完成時，進行整體的測試集成，在移交階段的任務是將設計完成的軟件產品交給用戶，接受用戶的檢測，完善文檔。

醫療保險管理信息系統的UML建摸就是按上述基本過程進行的。在醫療保險系統業務流程的基礎上可以得到醫療保險系統的基本功能：實現醫療保險系統業務處理的計算機化，把定點醫療機構、定點藥店、銀行、參保單位、參保個人連接起來，通過計算機網絡提供實時參保登記、保險費收繳、醫療費用和醫藥費用支付的電子化，通過各種監控手段控制基本醫療費用使用，開拓資金來源，為醫療藥品行業的公平競爭提供支持，建立患者醫療費用負擔、病種費用、住院周期、大型設備使用、藥品使用等醫療狀況資源數據庫，并利用這些資源對醫療保險的收支情況，病種費用定額，平均住院費用定額等進行預算，建立醫保資金收入支出模型。(1)醫保系統UML建模的案例模型。(2)相關對象的順序圖、合作圖和活動圖模型。順序圖非常直觀地層示了對象之間傳送消息的時間順序，反映了對象之間的一次特定的交互過程。在本例中，就診者對象向醫院門診發送參保身份驗證的消息，門診完成身份驗證后便向醫生對象發送就診人看病的消息，醫生看病開處方單后，向處方單對象發出保存處方單的消息，處方單對象完成保存工作，并同時對處方單進行藥品準入驗證，然后向支付系統發送處方單費用計算的消息。支付系統完成處方單費用計算后，通知就診人付款，就診人插卡到pos機，pos機通知支付系統扣除應付款數，整個過程是順序完成的。(3)醫保系統的類圖模型。類圖技術已成為面向對象方法中真正的主要的技術，事實上，每種方法都含有這種技術的變化情形。賬務管理一共包含基金總帳、實收賬、應收帳、住院基金、風險基金、個人帳戶、住院費用單、門診費用單、購藥費用單、參保職工、參保單位、繳費憑證等12類對象。其中類對象實收賬和應收賬都是基金總賬的一部分，它們之間的關系是整體與部分的關系，是一種組成關系，同樣住院基金、風險基金和個人賬戶和實收賬的關系也是一種組成關系。住院基金和住院費用單是一種帶約束的一對關系，即如果費用單金額之和超過定額支付數，則只支付定額數。同樣風險基金和住院費用單的關系也是一種帶約束的關系。

3.2 UML與面向過程模型的比較

3.2.1 UML模型的特點。從需求分析到設計和實現，UML都提供了一套連續的可視化表示符號，可以實現模型之間的無縫轉換。UML在初始階段使用“USECASE”圖來刻畫用戶需求，強調了系統相關的角色和這些角色在系統中完成的主要功能，忽略了各個角色與功能之間的聯系及其它細節，通過“USE CASE”圖，用戶和開發者對系統功能一目了然，把注意力引導到弄清楚系統要干什么，而其細節則用文字詳細描述，在詳細分析階段，用交互圖，包括順序圖、合作圖和活動圖來描述“USECASE”相關對象之間的消息傳遞、協作關系，進一步經過設計，用對象模型來表示整個系統。

3.2.2 面向過程的特點。而面向過程模型一般采用數據流程圖和數據字典，來描述系統需求。分析、設計、編碼之間缺少統一的表示方法，因而各個階段之間存在較大的間隙，這種技術是面向功能的方法，即根據用戶需求的功能畫出流程圖。然后在對需求的功能進行分解以及得到系統的子功能，再繼續進行這種分解，直至得到每個子功能都是可管理的，然后把這些數據流圖變化成對應的軟件結構，這種面向過程的方法容易為開發者所接受。但這種方法所得到的軟件結構，嚴重的依賴于系統功能，在軟件開發過程中，用戶的功能需求是軟件開發過程中最不穩定的開發因素。用戶可能隨軟件開發過程的進行加深對軟件的認識，因而可能改變其需求。另外，隨時間的進行，也會加深對其應用領域的認識，因而提出新的需求，這些改變將導致軟件結構的改變，因而給軟件的開發以及其維護造成了困難。

3.2.3 UML更具優勢面向過程的方法其數據和操作是相對分開的，例如，程序中的全局變量以及多個模塊所存儲的數據文件不屬于任一單一模塊，因此，數據和操作是分離的。現假設需修改某項功能，那么必須修改數據結構的某一部分，同時修改或增加某個模塊。但是，我們不能僅改變數據字段的名字而不改變其他影響程序，如果是普通的數據文件，那么不修改全部有關程序，而單獨修改數據文件是不可能的。但是對于UML也就是面向對象的方法把數據和操作封裝在一起，實行了信息隱蔽的原則，因而程序的改變是相對容易的。像醫療保險管理信息系統這一類的計算機軟件，在開發過程中或開發工作完成之后，用戶的需求經常改變，因此這類系統的開發采用UML的技術可以適應系統功能不穩定的特點。

3.3 醫療保險系統中網絡和數據庫的完善

在MIMIS中，網絡和數據庫設計的好壞是至關重要的，這直接影響到整個MIMIS性能，所以必須要加強和完善醫保系統中的網絡和數據庫。

(1)系統的網絡結構設計。根據前面的醫療保險管理信息系統的功能，可以勾畫出系統的網絡結構的硬件平臺。醫療保險管理信息系統的硬件平臺包括醫保中心的局域網、定點局域網和網絡接入設備等構成。醫保中心局域網及其網絡接入設備是醫保系統的核心部分，負責系統的安全運行、業務管理等重要工作。定點醫院局域網是支持本系統中定點醫院管理業務子系統的硬件平臺。由于定點藥店業務子系統業務量小，不需要建局域網，可用一臺高檔PC機采用撥號方式入網。

由于傳統的二層Client/Server結構存在部分局限，因此醫療保險管理信息系比較好的方法應該采用三層Client/Serve計算模式。隨著Internet獲得愈來愈廣泛的應用，同時基于B/s結構的特點，系統采用B/s信息發布與查詢模式，即對于參保單位投保、領導查詢、決策支持、網絡掃描、信息發布等功能采用B/S結構。

（2）遠程實時通訊及數據傳輸功能。

如何將醫保中心的個人賬戶等信息傳輸到醫療機構，以及如何將參保人員在定點醫療機構的消費信息傳送到醫保中心，及時正確扣減個人賬戶，是系統數據保持一致性和正確性的關鍵，也是系統保持正常運轉的關鍵。而在以前的醫療保險管理信息系統中，對這一方面雖然也很重視但做的并不是很成功。本文在此給出了同時支持實時和定時聯機的兩種方案，一般情況下，系統采用實時聯機通訊方案，當線路出現故障或通訊條件不滿足時采用定時通訊方案。(i)采用TCP/IP的SOCKET網絡編程實現數據實時傳輸。各定點醫療機構和醫保中心需要實時傳遞的數據很多，這里只考慮參保職工個人的Ic卡如何在醫療機構實現在線劃款。由于醫保中心每月(年)在職工繳納了醫療保險基金后，為參保職工個人賬戶劃撥一次，而個人賬戶劃撥后中心數據庫的個人賬戶增加，而個人的IC卡中沒有寫入。為了做到醫保中心數據庫中個人賬戶的數據和職工個人手中的IC卡上的個人賬戶數據一致，當參保職工到醫院、藥店就診時，系統自動實現向個人IC卡中劃款。

醫院的工作站完成個人IC卡劃款的程序設計過程：判斷個人IC是否需要劃款；如需要，向中心的通訊前置機發起個人IC卡劃款請求；接受請求結果，正確，向IC卡中寫入個人賬戶最新數據；向中心返回IC卡劃款成功標志。醫保中心的通訊前置機監聽進程中關于個人IC卡劃款的程序設計過程：監聽端口信息，得到請求后，判斷請求類別(驗證請求的正確性、申請最新個人賬戶數據、返回在醫院的劃款結果)；根據請求對醫保中心的數據庫進行操作；將結果寫回端口。(ii)采用TCP/IP的FTP編程來實現數據包傳輸。針對醫保中心和各醫療機構之間需要定時傳輸的數據，系統采用TCP/I P的FTP編程實現。系統需要傳輸的數據均由各醫療機構來完成，包括醫保中心需要下傳和醫院需要上傳的信息。各醫療機構的數據傳輸程序用DELPHI編寫，利用DELPHI提供的NMFTP控件類。實現的設計過程如下：醫保中心和各醫療機構需要傳輸的數據打包、加密后，存放在規定的目錄中；通過醫院端運行傳輸文件包程序，將數據傳送到對方規定的目錄中；雙方運行相應數據庫中相應的數據。

（1）數據庫技術的規范

醫保中心的參保人數一般較多，數據量很大，像兩江試點之一的鎮江目前其參保人數就達30萬。如果數據庫設計不合理就會明顯的使系統的性能降低，查詢數據的時間延遲，因在醫保工作人員工作時較高的響應率還是很重要的所以醫療保險管理信息系統的數據庫的設計必須使用正確的設計方法分步進行。具體來看就是按照下面數據庫設計的生命周期的四個階段來進行。

需求分析：在系統分析階段，收集用戶需求，明確地了解有用數據及管理對象，進行需求分析，反復權衡制定初步方案，這些為數據庫的進一步設計打下了基礎。概念設計：這個階段是從用戶觀點來描述數據庫，即對現實世界(醫療保險信息系統)，包括人員、機構、概念、事件等進行描述，進而抽象出系統管理的基本模式。對已有的存儲文件(臺帳、報表)、原始憑證等進行分析，若不需變動的則視為一個實體，如需要變動的再進一步地分解、組合，最后將每一個數據存儲視為一個實體，分析實體之間的聯系和實體的屬性，導出符合用戶要求的模型一-概念模式。

邏輯設計：這一步的目標是精確地表示出數據的關系，其結果為一系列的表格和數據字典。具體做法是對數據存儲(如表格等)和上級報表經過修改(如增、減項目，分解表格等)即可得到數據庫的二維表格：采用下述轉換規則轉換成二維表格。

每個實體集作為一個關系模型(二維表格)，實體的屬性作為關系的屬性，實體的關鍵字作為關系的關鍵字。

實體間的聯系，對應一個關系，其屬性由參加這個聯系的所有關系的關鍵字和本聯系的屬性組成。

用上述方法得到數據庫模型之后，還必須提高規范化程度。由于管理中的信息表格化程序很高，經過分析設計的關系模型(表格)就一目了然，數據之間的依賴關系很容易發現，所以，我們從實際出發，不斷改進，盡量使其達到第三范式(3NF)的要求，但是也感覺到雖然提高數據庫模式的規范化程度可以減少冗余和引起更新數據庫時的異常現象，但由此而導致的數據庫增多，使得解決一個問題常常需要打開多個數據庫進行連接等操作，這樣事必造成降低速度和產生不必要的麻煩。

[1]徐銘.城鎮居民醫療保險管理信息系統研發[J].山東大學，2009-04-15.

[2]劉宏宇.社會醫療保險網絡管理信息系統設計和實現[J].電子工程師，2001-11-30.

[3]陽輝.醫療保險管理信息系統[J].四川大學，2001-05-07.