學校門診管理信息系統

1、 河南城建學院軟件工程 項目設計設計題目： 學校門診管理信息系統 院系專業(yè)： 計算機科學與技術專業(yè) 學 號： 081411105 姓 名： 李彥霞 指導老師： 王春麗 2014年 5 月 27 日目錄目錄1第1章 緒論21.1 系統開發(fā)背景21. 2系統開發(fā)目標2第2章 需求分析42.1 需求分析過程42.2 系統的功能需求42.3 系統的非功能需求62.4 系統軟件硬件需求62.5 系統用例圖和動態(tài)模型圖8第3章 概要設計113.1 門診部門的體系結構113.2 門診業(yè)務流程113. 3 門診管理系統功能12第4章 詳細設計144.1 系統劃分144.2 門診管理子系統144.2.1 藥房管

2、理子系統154.2.2藥庫管理子系統154.2.3綜合查詢子系統154.2.4綜合管理子系統164.2.5一卡通退費管理子系統164.3 數據庫設計165.1 系統業(yè)務流程215.2 門診管理的功能實現225.3 系統測試22第6章 總結246.1 總結246.2 展望24第1章 緒論1.1 系統開發(fā)背景隨著科學技術的不斷發(fā)展，各行業(yè)競爭日益激烈，因此如何提高工作效率已成為當今面臨的主要問題。近年來MIS(管理信息系統)陸續(xù)走入了各企事業(yè)單位，成為企業(yè)管理者的得力助手。醫(yī)院是信息化程度高而且復雜的單位。其信息除具有一般的信息的特征以外，通常還有相關性、多樣性、時效性以及多類媒體、數據海量、法律

3、準則等特性。由此可見手工管理將會浪費很多的財力、物力，而HIS(醫(yī)院信息系統)的引進將為醫(yī)院解決這一難題。HIS的開發(fā)已從最初的“以財務管理為中心”為主要模式逐步向“以病人為中心、以醫(yī)療信息為主線”的全新管理模式轉變。 我國高校校醫(yī)院信息系統的研發(fā)工作，從八十年代初期算起，至今也有十多年的歷史，其中經歷了單機單任務的階段，多機多任務的階段以及微機網絡一體化的階段，應該承認這期間我們有了很大的進步。醫(yī)院對信息的需求永遠是高校校醫(yī)院管理信息系統發(fā)展的動力。在還沒有投入使用管理信息系統的校醫(yī)院，傳統的手工操作帶來了很多的問題，譬如藥庫管理經常由于管理上的不當使部分藥品失效報廢給醫(yī)院帶來了一定的經濟損

4、失，門診劃價出現的人為錯誤造成的損失和人員工作分配不合理使得勞動效率低等問題。面對這一系列的問題，校醫(yī)院管理信息系統的設計和實現是迫切的、必需的，是管理系統在醫(yī)院環(huán)境的具體應用。目前，在部分高校校醫(yī)院中也存在著各種各樣的管理信息系統，但由于軟件水平的落后和不能完全適應具體醫(yī)院的業(yè)務等原因，促使了此醫(yī)院門診管理系統的開發(fā)。本系統通過開發(fā)背景，設計、開發(fā)和實現醫(yī)院門診管理系統，提高校內醫(yī)務室的工作效率。所以，針對高校校醫(yī)院的門診管理信息系統，既要整合目前已經存在的醫(yī)院管理信息系統的弊端和不足進行修正，還要兼顧高校這一特點，滿足高校校醫(yī)院 對信息系統的需求。例如，系統功能要求可以很簡單，但是數據量特

5、別大，任何一個病人的醫(yī)療記錄都是一部不斷增長著的、圖文并茂的書，而一所高校的校醫(yī)院擁有上萬份病人的病案是常見的，而且有很強的流動性。另外，病人的身份多以學生和老師為主，他們都可以現金交費，而且學生可以通過校園一卡通，老師也可以通過劃賬方式交費等。1. 2系統開發(fā)目標 通過對醫(yī)院門診管理系統背景的分析，針對現在相關系統存在的問題，我們提出以下幾個開發(fā)目標:用全新的軟件框架設計醫(yī)療系統，從而解決醫(yī)療系統需求易變、實施成本過高、系統穩(wěn)定性與可靠性差等問題:使用全新的組件式產品交付方式，使得工程部實施或第三方OEM廠商能夠按照客戶的需求量身訂制醫(yī)院門診管理系統;采用國際、國家標準和規(guī)范，搭建穩(wěn)固的醫(yī)療

6、資源平臺，為產品整合醫(yī)療體系的其他業(yè)務領域提供基石;建立“以病人為中心，以服務為導向，經濟上降低成本，醫(yī)療上控制質量”的模式;采取分布式網絡結構，實現存儲分布，計算分布，顯示多樣，以便減少單服務器的負荷壓力，大大提高系統的穩(wěn)定性和響應，同時也支持多種終端設備的顯示。物理上我們將分成三層結構:數據服務器群，組件服務器群(程序服務器群)，用戶操作終端;建立在線備份及數據轉儲機制，從而減少了在線聯機事務處理系統的數據壓力并且也保證了數據的安全和可靠。徹底解決聯機事務處理與聯機事務分析之間的矛盾。第2章 需求分析2.1 需求分析過程軟件需求分析工作是軟件開發(fā)成功的前提和基礎，需要研發(fā)人員與用戶密切配合

7、，將軟件的功能和性能描述轉換成精細的軟件邏輯模型。首先研發(fā)人員需要進行細致地調查分析，認真了解用戶的需求，并澄清用戶的模糊需求，最終將用戶非形式化的需求敘述轉化為完整的需求分析文檔，進而明確系統的開發(fā)目標。需求分析的基本任務包括u 問題識別 (1)功能需求:明確待開發(fā)軟件的實現功能。 (2)性能需求:明確待開發(fā)軟件的技術性能指標。 (3)環(huán)境需求:明確軟件運行對機器的軟、硬件需求。 (4)用戶界面需求:明確軟件和用戶交互的界面形式。u 分析與綜合，導出軟件的邏輯模型 研發(fā)人員對數據流和數據結構進行詳細分析，逐步細化系統的功能，找出系統各元素之間的聯系和設計上的限制，形成系統的解決方案，建立目標

8、系統的邏輯模型。u 編寫需求分析文檔 為了對用戶的需求清晰準確地描述，開發(fā)人員需要編寫軟件需求規(guī)格說明書。u 需求分析評審 在需求分析工作的最后階段，研發(fā)人員需要對系統的功能需求、性能需求以及其他需求進行評審并給出評價。2.2 系統的功能需求我們項目組針對醫(yī)院信息管理系統的使用情況進行深入調研，發(fā)現大部分醫(yī)院根據自身特點和業(yè)務流程，進行醫(yī)院信息系統的設計與開發(fā)。比如，一些醫(yī)院把病房的床位管理中，一些醫(yī)院把門診收費模塊和信息系統分開等。我們項目組對學校醫(yī)院目前使用的信息管理系統進行詳細分析，并綜合考慮部門的職能設置以及聯網后的應用需求，結合項目開始階段完成的需求分析文檔，將目標系統劃分為以下幾個

9、模塊進行開發(fā)，如表3-1所示：表2-1 學校醫(yī)院信息管理系統的功能模塊編號系統功能功能模塊模塊介紹1門診管理門診掛號門診掛號支持一卡通掛號和現金掛號，并記錄患者的基本信息醫(yī)師門診對患者進行病情診斷，選擇項目和藥品，并開除處方病房門診對患者進行病情診斷，選擇項目和藥品，并開出處方劃價收費對項目和藥品進行劃價收費2藥房管理入藥提請藥品數量不足時，向藥庫申請藥品藥房發(fā)藥針對繳費成功的患者發(fā)放藥品藥房出藥記錄藥房中藥品的所有流向，但不包括藥房發(fā)藥方式藥房庫存管理藥品分庫存信息3藥庫管理提藥批復批復入藥提請模塊發(fā)出的提藥申請藥庫入藥對新購入的藥品進行正常入庫藥庫出藥記錄藥庫中藥品的所有流向藥庫庫存管理藥

10、品的庫存信息4綜合管理門診收費統計統計門診收費信息，便于管理和查詢藥庫出入記錄記錄藥品出入藥庫的信息藥房出入記錄記錄藥品出入藥房的信息5系統管理藥品字典負責藥品信息的管理項目字典負責項目信息的管理科室設置負責科室信息醫(yī)師字典負責醫(yī)師信息的管理出入庫字典負責藥品出入藥庫的類型設置出入房字典負責藥品出入藥房的類型設置操作員字典負責操作員信息的管理，以及對操作員的使用權限進行設置患者類別字典負責喊著類別的信息管理系統參數設置負責系統草書的管理。包括最低庫存數量、預警天數、掛號費等6一卡通退費管理對刷卡繳費的患者，執(zhí)行退費操作7修改密碼修改登陸密碼學校醫(yī)院信息管理系統實現的主要功能是:患者在門診掛號模

11、塊可使用校園一卡通繳費和現金繳費兩種掛號方式，掛號成功后選擇醫(yī)師門診或病房門診就診，醫(yī)師根據患者病情書寫電子病歷，并選擇相應的藥品或項目，最后開出并打印患者處方。門診管理員在劃價收費模塊對患者開出的藥品和項目進行劃價和收費，并打印收費發(fā)票。藥房針對繳費成功的患者，根據藥品單發(fā)放藥品，若藥品數量不足，可向藥庫發(fā)出提藥申請，藥庫根據庫存情況進行提藥批復。如果存在患者繳費成功后，退掉某一藥品或項目的情況，操作員在一卡通退費模塊針對刷卡患者執(zhí)行退費操作并開出退費憑據，患者到一卡通管理中心領取相應金額。2.3 系統的非功能需求非功能性需求，是指軟件產品為滿足用戶需求必須具有且除功能需求以外的特性。本系統

12、采用先進、成熟的軟硬件技術，以便適應醫(yī)療機構的業(yè)務發(fā)展和信息化建設的需求，比如在系統開發(fā)方面，使用Microsoft公司推出的功能強大的.NET開發(fā)平臺，此平臺包含世界上先進的程序設計理念。本系統可擴展性和可維護性良好，在結構設計方面采用C/S三層結構模式，將系統整體劃分為表示層、業(yè)務邏輯層、數據訪問層等三個部分，實現了各層在邏輯上的獨立性，降低了各個層次之間的依賴，便于開發(fā)人員對系統進行維護和后期開發(fā)。由于采用模塊化的結構設計，本系統能夠靈活配置以適應不同環(huán)境，為系統的可擴展性奠定了良好的基礎。在數據庫設計上也綜合考慮將來設計需求，采用SQL Serve:技術，把現實世界中的實體關系模式映射

13、為關系數據庫中對應表格，此技術具有高性能、可靠性和可擴充性等優(yōu)點，方便系統的功能擴展和數據庫的后期維護。我們項目組嚴格遵循軟件開發(fā)的工程思想，從系統的需求分析到設計再到實現。在開發(fā)方面嚴格遵守軟件開發(fā)流程，書寫規(guī)范代碼，在系統和數據庫設計上嚴格按照國家醫(yī)療衛(wèi)生行業(yè)的有關標準，保證系統的質量。項目完成階段書寫完整、詳細的開發(fā)文檔，為本系統的后期維護、功能擴展提供良好參考。2.4 系統軟件硬件需求我們項目組通過對需求分析文檔進行詳細分析和討論，確定了系統的架構模型，包括用戶交互界面、Windows窗體、軟件底層環(huán)境和底層數據庫等四個部分，如圖2-1所示:圖2-1 學校醫(yī)院信息管理系統架構圖 由上圖

14、可以看出，系統架構的每一部分采用不同的軟件工具進行開發(fā)，為了方便對系統的軟硬件需求進行說明，本節(jié)主要從系統的開發(fā)環(huán)境和運行環(huán)境兩個方面進行介紹。 開發(fā)環(huán)境的軟硬件配置如下所示:(1)軟件配置 操作系統:Windows 7/XP 開發(fā)和運行環(huán)境:Microsoft .NET Framework 3.5 開發(fā)工具:Microsoft Visual Studio.NET 2008 數據庫開發(fā)工具:Microsoft SQL Server 200_5(2)硬件配置 P4 1.4G或以上CPU 2G DDR 400 Memory 80G Hard Disk 聲卡、顯卡主板集成(3)網絡配置 Inte11

15、0/100M網卡 10/100M自適應交換機本系統對運行環(huán)境的軟硬件配置要求如下:(1)軟件要求 Microsoft .NET Framework 3.5 Microsoft SQL Server 200_5 Windows 2003 Server(服務器端操作系統) Windows 7/XP(客戶端操作系統)(2)硬件要求 服務器端: P4 2.0G CPU 2G DDR 533 Memory 1606 Hard Disk Intel 10/100M網卡 客戶端: P4 1.4G或以上CPU 1 G DDR 400 Memory 80G Hard Disk聲卡、顯卡主板集成2.5 系統用例圖

16、和動態(tài)模型圖統一建模語言(Unified Modeling Language ,UML)是一種面向對象的建模語言，使用標準化、統一的定義和標記對軟件系統進行描述和建模3s o UML的主要內容可由下面五類圖定義:第一類是用例圖，主要描述用戶所理解的系統功能;第二類是靜態(tài)圖，包括類圖、對象圖和包圖;第三類是行為圖，包括狀態(tài)圖、活動圖、順序圖和協作圖，主要描述系統在時間和順序上與組成對象的關系;第四類是交互圖，主要描述系統對象之間的關系;第五類是實現圖。UML建模語言提供的用例圖描述了系統開發(fā)者和用戶基于系統功能所達成的共識，是進行需求分析的強有力工具。用例圖是由參與者、用例以及用例之間的關系構成

17、的，用來描述系統的功能需求，但不涉及系統功能的具體實現36。參與者是指系統使用者在與系統交互時所扮演的角色，比如管理員、操作員等，并不特指人或事物本身。用例是指參與者對系統的操作，表示一系列動作。用例之間的關系主要包括擴展和使用，擴展關系是指一個用例通過向前一個用例添加一些動作構成的，因而繼承了前一個用例的行為。使用關系是指一個用例通過對其他用例的使用構成的，這兩種關系描述了幾個用例的相同行為。通過以上介紹，我們可以得到系統的用例圖。圖2-2 門診管理用例圖1圖2-3 門診管理用例圖2圖2-4 藥品管理用例圖圖 2-5 綜合查詢用例圖第3章 概要設計3.1 門診部門的體系結構高校校醫(yī)院是專門為

18、高校的學生和教職工提供相關服務的機構，其服務的范圍是人們在醫(yī)院看病活動的整個過程，因此校醫(yī)院包括了醫(yī)院門診部門的所有科室:門診掛號、醫(yī)務處、門診收費、門診藥房，醫(yī)護人員護理等。醫(yī)院門診部門的體系結構圖如圖3-1所示。圖3-1 門診部門體系結構圖3.2 門診業(yè)務流程醫(yī)院是以病人為中心、以病人醫(yī)療信息為核心的一個機構，所以病人的信息貫穿了整個業(yè)務流程中。以病人就醫(yī)為起點，門診部門業(yè)務流程如圖3-2所示。圖3-2 門診部門業(yè)務流程圖就診病人來到醫(yī)院，根據情況來確定是否先掛號，如果情況比較緊急，直接送入急診室進行檢查，根據病人情況判斷是否使用急救車送入附近較大醫(yī)院。否則病人首先在掛號門診進行掛號，購買

19、病歷本，生成掛號憑證，在這里類似于就醫(yī)排隊的道理。然后憑借掛號憑證到相關診室就診，在就診過程醫(yī)生通過查看和詢問病人情況決定是否開立處方或申請單。病人憑借醫(yī)生開立的處方或申請單到收費門診進行劃價交費，門診收費部門是整個醫(yī)院的財務重點，所以把收費工作進行了劃分，分成劃價和收費兩個部分，提高醫(yī)院賬務的準確性。待病人交費之后，即可憑借交費單據到門診藥房進行拿藥或者到檢查治療部門執(zhí)行醫(yī)囑，最后就診結束。另外，在就診過程中，還存在著退藥、退費、藥品數量查詢等業(yè)務，具體功能的需求將在后面的功能需求中重點描述。3. 3 門診管理系統功能門診管理系統功能流程圖，在這個流程圖中，包含病人就診和退費退藥流程，實現了

20、醫(yī)院門診的所有基本工能，如圖3-3所示。圖3-3 門診管理系統功能流程圖第4章 詳細設計4.1 系統劃分組根據學校醫(yī)院的部門設置和業(yè)務流程，將本系統劃分為六個子功能系統進行設計與開發(fā)，包括門診管理子系統、藥房管理子系統、藥庫管理子系統、綜合查詢子系統、系統管理子系統、一卡通退費管理子系統和修改密碼子系統。每個功能子系統根據部門職能和用戶需求，又劃分為相應的功能模塊進行設計與開發(fā)。其中門診管理子系統包括:門診掛號、醫(yī)師門診、病房門診、劃價收費等四個功能模塊，藥房管理子系統包括:入藥提請、藥房發(fā)藥、藥房出藥、藥房庫存等四個功能模塊，藥庫管理子系統包括:提藥批復、藥庫入藥、藥庫出藥、藥庫庫存等四個功

21、能模塊，綜合查詢子系統包括:門診收費統計、藥庫出入記錄、藥房出入記錄等三個功能模塊，系統管理子系統包括:藥品字典、項目字典、科室設置、醫(yī)師字典、出入庫字典、出入房字典、操作員字典、患者類別字典、系統參數設置等九個功能模塊。如圖4-1所示:圖4-1 系統劃分圖 4.2 門診管理子系統 門診管理子系統包括門診掛號、醫(yī)師門診、病房門診和劃價收費等功能模塊。遵循“一切以病人為服務中心”的管理原則，針對患者就診環(huán)節(jié)，使患者掛號、就診、項目檢查、藥品和項目繳費這一系列活動在門診管理子系統中形成一個整體。患者通過門診掛號模塊掛號成功后，根據自身的病情需要選擇醫(yī)師門診或病房門診模塊進行就診，醫(yī)師對患者的病情診

22、斷后，選擇藥品或項目，書寫診斷結果并開出處方，患者持處方到劃價收費模塊進行藥品和項目繳費。 4.2.1 藥房管理子系統根據藥品出入藥房的流程，藥房管理子系統劃分為入藥提請、藥房發(fā)藥、藥房出藥和藥房庫等四個功能模塊，藥房管理員通過藥房管理子系統可以實現藥房管理。藥房中如果存在藥品數量不足的情況，藥房管理員通過入藥提請模塊向藥庫發(fā)出提藥申請，藥庫管理子系統中開發(fā)提藥批復模塊對應此功能，藥庫同意藥房提藥請求后，由藥庫出藥模塊發(fā)放藥品，藥房中藥品的數量得到相應增加。藥房發(fā)藥模塊是針對患者拿藥設計的，此模塊可記錄患者的基本信息和領取的藥品信息。藥房出藥模塊記錄了藥品流出藥房的信息，包括藥品基本信息、藥品

23、去向和出藥類型，如個人提藥、藥房返回藥庫等。藥房庫存模塊管理藥房中藥品的庫存信息，比如盤點藥品數量，針對數量不足的藥品及時向藥庫申請?zhí)崴?，隱藏藥品功能可在醫(yī)師門診和病房門診模塊，不顯示此類藥品的信息。4.2.2藥庫管理子系統 藥房中的藥品是由藥庫發(fā)放的，因此藥庫管理子系統的設計應對應藥房管理子系統的功能模塊，包括提藥批復、藥庫入藥、藥庫出藥和藥庫庫存等四個功能模塊，藥庫管理員通過藥庫管理子系統來管理藥庫中的藥品。提藥批復模塊對應藥房管理中的入藥提請模塊，對藥房發(fā)過來的提藥申請進行批復，如果同意藥房提藥，藥庫出藥模塊會發(fā)放相應的藥品給藥房。此功能模塊可以顯示提藥的信息，既可以單條批復藥品申請也可

24、以一次性批復全部藥品申請。 藥庫管理員通過藥庫入藥模塊記錄藥品進入藥庫的信息，包括藥品的基本信息、藥品來源以及入庫類型，比如系統初始、采購入庫和藥房返回等。藥庫出藥模塊和藥房管理中的藥房出藥模塊功能相似，出庫類型略有不同，包括公益活動和返回藥房等。藥庫庫存模塊和藥房管理中的藥房庫存模塊功能相似，此模塊可查看即將過期和數量不足的藥品，以便對藥品管理和及時補充，庫存藥品列表中的藥品信息可生成EXCEL表格，方便藥庫管理員對藥品的庫存信息進行記錄并存檔。4.2.3綜合查詢子系統 綜合查詢子系統包括門診收費統計、藥庫出入記錄和藥房出入記錄等三個功能模塊，通過綜合查詢子系統，系統管理員可以查看患者繳費的

25、信息、藥房中藥品出入信息和藥庫中藥品出入信息。在門診收費統計模塊，通過輸入患者姓名、醫(yī)師姓名或收費口期，既可以查詢某一患者繳費的詳細信息，也可以查看全部患者繳費的詳細信息。在藥房出入記錄模塊，通過輸入藥品出入藥房的方式、出入類型或出入口期，既可以查看流入或流出藥房的某一種藥品信息，也可以查看全部藥品出入藥房的信息。藥庫出入記錄模塊和藥房出入記錄模塊功能相似，可以查看藥品流入或流出藥庫的詳細信息。4.2.4綜合管理子系統 綜合管理子系統包括藥品字典、項目字典、科室設置、醫(yī)師字典、出入房字典、出入庫字典、操作員字典、患者類別字典和系統參數設置等九個功能模塊，系統管理員通過綜合管理子系統對醫(yī)院的基本

26、信息進行管理。藥品字典模塊管理藥品的基本信息，可以對藥品信息進行增加、修改和刪除等操作。藥品字典模塊優(yōu)化了其他功能模塊在選擇藥品時的使用，比如醫(yī)師門診和病房門診，在選擇藥品時不需要輸入藥品的信息，只需要在藥品代碼編輯框中輸入或選擇某一藥品代碼，下面的編輯框會自動顯示此藥品的信息。項目字典模塊和藥品字典模塊功能相似，可增加、修改和刪除項目信息，優(yōu)化了其他功能模塊在選擇項目時的使用?？剖以O置模塊的功能和藥品字典、項目字典模塊的功能相似，系統管理員通過此模塊可以增加、修改和刪除醫(yī)院的科室信息。醫(yī)師字典模塊管理醫(yī)師的基本信息，可通過此模塊進行增加、修改和刪除操作。出入庫字典模塊可以對藥品出入藥庫的類型

27、進行增加、修改和刪除操作，并在列表中顯示藥品出入類型的信息。出入房字典和出入庫字典模塊功能相似，記錄和管理藥品出入藥房和藥庫的信息。操作員字典模塊實現操作員基本信息的管理，如操作員姓名、登錄的用戶名和密碼以及隸屬科室等，可以對其進行增加、修改和刪除操作，此外，通過此模塊可以對操作員的操作權限進行設置?；颊哳愋妥值淠K管理患者的基本信息，通過此模塊可以對其進行增加、修改和刪除等操作。系統參數設置界面可以對系統的基本參數，如藥品最低庫存、預警天數、醫(yī)師庫存差額和掛號費等進行設置。4.2.5一卡通退費管理子系統一卡通退費管理子系統是針對持校園一卡通進行刷卡繳費的患者設計的。如果存在患者繳費成功后，退

28、掉某一藥品或項目的情形，系統管理員在一卡通退費管理子系統執(zhí)行退費操作并開出退費憑據，患者持退費憑據到一卡通管理中心領取相應金額。4.3 數據庫設計數據庫設計包含需求分析、概念結構設計、邏輯結構設計、物理結構設計、數據庫實施、數據庫運行與維護等六個階段。概念結構設計是依據需求分析階段完成的說明文檔，將系統涉及的數據和信息抽象為獨立的數據模型，即概念模型。常用的概念模型為E-R圖，即實體一聯系圖，用來描述現實世界的數據模型。E-R圖的基本元素包括:實體、屬性和聯系，實體是對系統軟件中具有一系列不同屬性事物的抽象，在E-R圖中用矩形表示;屬性定義了實體的性質，用橢圓或圓角矩形表示;聯系是指實體之間的

29、關系，包含一對一聯系、一對多聯系、多對多聯系等三種類型，用菱形框表示。由于篇幅限制，本系統E-R圖中只顯示了部分實體的屬性，使用Microsoft Visio 2010畫圖工具進行繪制， 如圖所示。圖4-2 系統E-R圖下面為本系統中涉及到的幾個重要數據表在字段結構和數據類型的方面進行說明。表4-1 處方信息表表4-2 藥品字典表表4-3 項目字典表表4-4 藥房庫存表表 4-5 藥庫庫存表第5章 系統的實現和測試5.1 系統業(yè)務流程我們項目組研發(fā)的學校醫(yī)院信息管理系統是一套自成體系能夠獨立運行的信息化管理系統，本系統不但能夠滿足醫(yī)院各部門的需求，同時也適用于醫(yī)院具體數據的管理工作。系統需要實

30、現的主要目標是:整體化的設計、共享化的數據、相對獨立的業(yè)務處理、簡便靈活的操作和友好的交互界面。校醫(yī)院各個部門可以通過本系統及時掌握各環(huán)節(jié)的工作情況，方便自身工作高效展開。學校醫(yī)院信息管理系統主要由下圖所示業(yè)務流程組成，操作員輸入用戶名和密碼，登錄成功后根據權限加載子系統，即可進入其權限下的功能模塊。圖 5-1 系統業(yè)務流程圖5.2 門診管理的功能實現我們項目組根據門診部門的機構設置和應用需求，將門診管理子系統劃分為門診掛號、醫(yī)師門診、病房門診和劃價收費等四個模塊進行開發(fā)?；颊咄ㄟ^門診掛號模塊掛號成功后，根據病情需要選擇醫(yī)師門診或病房門診模塊就診，醫(yī)師對患者的病情診斷后，選擇藥品和項目，書寫診

31、斷結果并開出處方，患者持處方到劃價收費模塊進行藥品和項目繳費，繳費成功后持收費發(fā)票領取藥品或項目檢查。門診掛號模塊支持患者使用校園一卡通掛號和現金掛號兩種掛號方式。 校園一卡通功能在本系統中的應用主要體現在門診管理子系統中的門診掛號和劃價收費模塊，門診掛號模塊通過讀卡器讀取患者的基本信息以及收取掛號費，劃價收費模塊是患者通過刷卡方式對所購藥品和檢查項目進行繳費。另一個重要應用是通過刷卡方式進行繳費的患者，可以退回所購藥品和項目，系統管理員在一卡通退費管理模塊核查患者信息，然后退還相應金額。 本系統和校園一卡通第三方服務器建立連接，在測試和運行方面需要進行的必要設置: (1)運行第三方代理sio

32、s ，sios是脫機流水狀態(tài)代理服務器監(jiān)測工具。 (2)增加系統代碼syscode，這個系統代碼在TA_ init3)中需要用到。步驟:右擊sios-子系統維護一增加子系統代碼一退出。 (3)設置商戶和終端編號對應關系，即商戶和TerminalNo的對應關系，這個終端編號在TA_ init3)需要用到。步驟:右擊sios一商戶設置一設置商戶一存盤一退出。(4)退出sios，重新啟動sios 。然后連接動態(tài)數據庫，實現數據信息的存儲，從而實現學校門診管理信息系統。5.3 系統測試 系統測試是管理信息系統開發(fā)周期中一個十分重要而漫長的階段。其重要性體現在它是保證系統質量與可靠性的最后關口，是對整個

33、系統開發(fā)過程包括系統分析、系統設計和系統實現的最終審查。系統測試的對象是軟件，其目的是找出軟件中的錯誤 在進行系統測試時應遵循以下基本原則：1測試工作應避免由原開發(fā)軟件的個人或小組來承擔;2設計測試方案時，不僅要包括確定的輸入數據，而且應包括從系統功能出發(fā)預期的測試結果; 3測試用例不僅要包括合理、有效的輸入數據，還要包括無效的或不合理的輸入數據;4不僅要檢驗程序是否做了該做的事，還要檢查程序是否同時做了不該做的操作; 5軟件中仍存在的錯誤的概率和己經發(fā)現錯誤的個數是成正比的; 6保留測試用例，作為軟件文檔的組成部分。系統測試采用的方法是普遍引用的“黑盒”測試和“白盒”測試法。白盒測試也稱結構

34、測試，即將軟件看作一個透明的白盒子，按照程序的內部結構和處理邏輯來選定測試用例，對軟件的邏輯路徑及過程進行測試，檢查它與設計是否相符。白盒測試是通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要發(fā)現內部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。而“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤 在掌握一定測試用例設計方法的基礎上，可以設計出比較全面、合理的測試用例。以下是對在使用黑盒測試方法時對系統進行測試的用例的簡單舉例介紹。用例一:測試輸入用戶密碼客戶端的反應輸入內容:口令長度為3-6位。操作步驟:12345回車。預期結果:彈出錯誤提示窗口:密碼輸入錯誤，三次輸入錯誤將鎖定用戶。請正確輸入!用例二:測試首次掛號不輸入項為空的反應輸入內容:病人首次掛號界面中不輸入姓名，直接掛號。操作步驟:空出病人姓名文本框，直接掛號。預期結果:彈出提示窗口:姓名不能為空，請重