張弛

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

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

下面就從醫(yī)保系統(tǒng)目前的現(xiàn)狀和存在的問題出發(fā)，提出新的適應(yīng)目前需求的醫(yī)療保險管理信息系統(tǒng)。

1 醫(yī)療保險管理信息系統(tǒng)的現(xiàn)狀以及存在的問題

1.1 醫(yī)療保險管理信息系統(tǒng)的發(fā)展?fàn)顩r

我國醫(yī)療保險管理信息系統(tǒng)(MIMIS)的建設(shè)始于20世紀(jì)90年代后期。經(jīng)過幾年的發(fā)展，醫(yī)療保險管理信息系統(tǒng)建設(shè)已經(jīng)初具規(guī)模。信息系統(tǒng)的發(fā)展經(jīng)歷了從單機系統(tǒng)、局部網(wǎng)絡(luò)系統(tǒng)到整個部門統(tǒng)一信息系統(tǒng)的多個階段。

在信息系統(tǒng)應(yīng)用技術(shù)上，客戶/服務(wù)器結(jié)構(gòu)的信息系統(tǒng)已經(jīng)成為醫(yī)療保險信息系統(tǒng)的主流，使用Windows環(huán)境和圖形化的用戶界面是目前社會保障管理部門主要采用的客戶端環(huán)境，基于SQL語言訪問的大型數(shù)據(jù)庫在醫(yī)保中心、社會保障管理部門中也已普遍使用。

1.2 醫(yī)療保險管理信息系統(tǒng)目前存在的問題

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

由于醫(yī)療保險信息系統(tǒng)的這些特點，導(dǎo)致了我國醫(yī)療保險信息系統(tǒng)的建設(shè)中存在的問題很多。

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

2 適應(yīng)需求的醫(yī)療保險管理信息系統(tǒng)所要達(dá)到的功能

醫(yī)療保險管理的計算機化是一項規(guī)模巨大的信息系統(tǒng)工程。它的基本模式是：以醫(yī)療保險管理中心為信息系統(tǒng)的中心，與全市各定點醫(yī)療機構(gòu)、定點藥店聯(lián)網(wǎng)，構(gòu)成一個龐大的覆蓋統(tǒng)籌地區(qū)的醫(yī)療保險計算機管理網(wǎng)絡(luò)系統(tǒng)。

2.1 基本的業(yè)務(wù)功能要求

系統(tǒng)的總體邏輯結(jié)構(gòu)應(yīng)根據(jù)系統(tǒng)的數(shù)據(jù)和功能需求，MIMIS主要由醫(yī)療保險管理中心業(yè)務(wù)子系統(tǒng)、定點醫(yī)院業(yè)務(wù)子系統(tǒng)、定點藥店業(yè)務(wù)子系統(tǒng)三個部分構(gòu)成。

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

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

參保職工：按月繳納個人應(yīng)負(fù)擔(dān)的醫(yī)療保險費；持醫(yī)保IC卡到各定點醫(yī)療機構(gòu)就醫(yī)或購藥。

定點醫(yī)院、藥店：按照醫(yī)療保險政策和醫(yī)保中心制訂的藥品、診療、病種等醫(yī)保目錄，完成參保職工在醫(yī)療機構(gòu)的治療、購藥等服務(wù)工作，允許其持醫(yī)保IC卡結(jié)算，按約定與醫(yī)保中心結(jié)算醫(yī)療費用。醫(yī)療保險管理中心：負(fù)責(zé)單位和個人基本信息(檔案)的管理工作、負(fù)責(zé)醫(yī)保基金的征繳核定工作、負(fù)責(zé)管理統(tǒng)籌基金收支、負(fù)責(zé)完成參保職工的特殊醫(yī)療費用的報銷、負(fù)責(zé)定期與定點醫(yī)療機構(gòu)進行費用結(jié)算、負(fù)責(zé)監(jiān)督檢查醫(yī)保政策在各定點醫(yī)療機構(gòu)的執(zhí)行情況。

2.2 子系統(tǒng)的功能要求

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

2.2.1 醫(yī)療保險管理中心業(yè)務(wù)子系統(tǒng)功能

醫(yī)療保險管理中心業(yè)務(wù)子系統(tǒng)包括：投保服務(wù)、參保管理、基金財務(wù)管理、個人賬戶管理、醫(yī)保：IC卡管理、醫(yī)療監(jiān)督管理、醫(yī)療審核管理、現(xiàn)金報銷管理、系統(tǒng)管理、統(tǒng)計分析、領(lǐng)導(dǎo)查詢共11大類136個業(yè)務(wù)，覆蓋了參保、征繳、實繳、緩繳、分配、變動、調(diào)動、結(jié)算、報表、查詢、統(tǒng)計、管理和控制等各個層面上的業(yè)務(wù)。接口包括醫(yī)療機構(gòu)接口、上下級經(jīng)辦機構(gòu)接口、勞動主管部門接口和財務(wù)接口，滿足了上下級、同級相關(guān)部門的信息交換。

2.2.2 定點醫(yī)院業(yè)務(wù)子系統(tǒng)功能

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

3 對新的醫(yī)療保險管理信息系統(tǒng)的具體設(shè)計和思考

根據(jù)目前MIMIS的功能需求，筆者在此對醫(yī)保信息系統(tǒng)提出了新的設(shè)計方法，把UML技術(shù)運用到了MIMIS中，并加強和完善了醫(yī)保系統(tǒng)的網(wǎng)絡(luò)和數(shù)據(jù)庫。

3.1 UML在醫(yī)療保險管理信息系統(tǒng)中的應(yīng)用

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

3.1.1 UML簡介UML是基于面象對象的建模語言，即統(tǒng)一建模語言(Unified ModelingLanguage，UML)，它的前身是對象建模技術(shù)(OMT)，UML的出現(xiàn)，則標(biāo)志著面向?qū)ο蠹夹g(shù)已進入了一個發(fā)展成熟時期，UML統(tǒng)一了面向?qū)ο蠼５幕靖拍?、術(shù)語和圖示符號，描述了建模過程所必須遵循的基本步驟，為學(xué)者和工程師們之間研究交流提供了共同語言。UML是一種定義清晰、易于表達(dá)，適用范圍廣的建模語言，集軟件研究領(lǐng)域的許多新思想、新方法、新技術(shù)于一體，強有力地支持軟件開發(fā)的全過程。

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

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

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

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

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

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

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

3.3 醫(yī)療保險系統(tǒng)中網(wǎng)絡(luò)和數(shù)據(jù)庫的完善

在MIMIS中，網(wǎng)絡(luò)和數(shù)據(jù)庫設(shè)計的好壞是至關(guān)重要的，這直接影響到整個MIMIS性能，所以必須要加強和完善醫(yī)保系統(tǒng)中的網(wǎng)絡(luò)和數(shù)據(jù)庫。

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

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

（2）遠(yuǎn)程實時通訊及數(shù)據(jù)傳輸功能。

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

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

（1）數(shù)據(jù)庫技術(shù)的規(guī)范

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

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

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

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

實體間的聯(lián)系，對應(yīng)一個關(guān)系，其屬性由參加這個聯(lián)系的所有關(guān)系的關(guān)鍵字和本聯(lián)系的屬性組成。

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

[1]徐銘.城鎮(zhèn)居民醫(yī)療保險管理信息系統(tǒng)研發(fā)[J].山東大學(xué)，2009-04-15.

[2]劉宏宇.社會醫(yī)療保險網(wǎng)絡(luò)管理信息系統(tǒng)設(shè)計和實現(xiàn)[J].電子工程師，2001-11-30.

[3]陽輝.醫(yī)療保險管理信息系統(tǒng)[J].四川大學(xué)，2001-05-07.