軟件完成後將擁有“字典維護”、“門診管理”、“院長查詢”三個模塊，它針對軟件所處的應用環境而發揮軟件的高效作用，“字典維護”模塊存儲了藥品信息和收費項目，以供藥品的進存提供數據；“門診管理”模塊擁有門診掛號、門診劃價、門診收費、藥房發藥四個子功能；“院長查詢”模塊則提供了壹個供醫院高層領導直接查詢醫院任何時間的科室掛號量和藥品庫存量。
本系統的開發平臺為Microsoft公司的開發工具——Microsoft Visual Studio 2005，以及結合了數據庫軟件——Microsoft SQL Serer作為系統中所用到的數據源的支撐平臺。
關鍵字：醫院管理系統；VC++.NET；數據庫；數據庫系統
目 錄
引言 6
1 緒論 7
2 可行性分析 8
2.1 經濟可行性 8
2.2 技術可行性 8
2.3 政策可行性 8
3 需求分析 9
3.1 業務流程 9
3.2 系統層次方框圖 9
3.3系統中各模塊層次圖 10
3.3.1系統字典維護 10
3.3.2門診掛號系統 11
3.3.3門診劃價管理 11
3.3.4藥房管理系統 11
3.3.5院長綜合查詢系統 12
3.4 系統流程圖 12
3.5 系統數據流圖 13
3.5.1頂級流圖 13
3.5.2 0層流圖 13
3.6 數據字典 14
3.6.1數據流條目 14
4 概念結構設計 15
4.1 系統全局實體圖 15
4.2 系統各實體圖 15
4.3 系統表及其用途 17
5 邏輯結構設計 18
5.1 邏輯設計規範 18
5.2 邏輯結構表 18
6 物理結構設計 19
6.1 數據存儲 19
6.2 創建索引 19
7 編碼 20
7.1 前臺功能設計 20
7.1.1字典維護 20
7.1.2門診管理 21
7.1.3院長查詢 21
8 系統測試 23
8.1 軟件測試概述[5] 23
8.2 常用的軟件測試方法[6] 23
8.2.1黑盒測試 23
8.2.2白盒測試 24
8.2.3基於模型的測試 24
8.3本系統的軟件測試方法 25
9 結束語 26
9.1系統功能總結 26
9.2對系統的展望 26
謝 辭 27
參考文獻 28
引言
醫院管理系統（Hospital Information System，HIS）在國際學術界已經被公認為新興的醫學信息學（Medical Information）的重要分支。美國該領域的著名教授Morris Collen於1988年曾著文為醫院信息系統下了如下定義：利用電子計算機和通訊設備，為醫院所屬各部門提供病人診療信息和行政管理信息的收集、存儲、處理、提取和數據交換的能力，並滿足所有授權用戶的功能需求。[4]經過多年的發展，如今類似醫院信息系統這樣的企業級應用軟件不僅能提供靜態的信息和交互式的動態信息服務，還能提供應用程序的基礎設施服務（如安全、事務、傳輸、緩沖、生存期管理等），目前這樣的軟件所采用N層結構進行構建，N層結構的優點是每壹層可以被單獨改變，而不影響到其它層，降低了部署與維護的開銷[11]。
為了滿足以上所述的問題，關鍵在不僅要重用舊的代碼，而且要重用相似的分析設計結果和體系結構，來減少構造新軟件系統的代價並提高軟件的可靠性。框架技術就是這樣壹種面向特定領域的重用技術，框架由於提供了大力度的重用而被認為是壹種最有前途的面向對象技術。單獨的類的重用盡管有用，但由於重用力度小而不具備有意義的生產力的飛躍。基於框架的軟件開發過程，把軟件的開發看作壹個組裝過程，在軟件框架的指導下尋找可復用構件（及開發壹些新構件）並進行系統組裝，這種開發過程是目前很受重視的研究方向。目前，針對企業級的應用提出了壹些解決方案。微軟的.NET框架和SUN公司的J2EE就是兩個目前最為流行和成熟的可以簡化企業應用中與開發、部署和管理相關復雜問題的體系結構。其中Microsoft.Net由微軟在2000年開始推出，是新壹代的Windows開發系統平臺。.NET平臺包含了以下主要特征：[10]
(1) 軟件變服務
(2) 基於XML的***同語言
(3) 融合多種設備和平臺
(4) 新壹代的人機界面
(5) 托管代碼公***語言運行庫
本文參照軟件工程中開發壹款軟件的相關步驟，結合數據庫的有關知識，按照軟件定義、軟件開發、運行維護的三步驟進行軟件的開發。其中軟件開發步驟中有所不同，由數據庫的概念結構設計、邏輯結構設計、物理結構設計組成。
1 緒論
醫院信息管理系統的主要目標是建立壹種新型的既能保障全體員工公平地獲得基本醫療保健服務，又能有效調控浪費，合理利用醫療資源的社會保障制度。隨著科學技術的進步，人民生活的提高，醫院信息管理需要進壹步的系統化、科學化，醫院信息管理系統的建立已經是大勢所趨。同時也為了更好的認真貫徹執行國家、省、地市醫療保險改革各項政策，建立職工正常基本醫療和補充醫療保險良好運行機制，經充分醞釀、研究論證，在吸取了各種式樣的醫院管理系統的經驗後，開發了醫院管理系統[2]。
預期系統完成後將達到以下六個目標：
(1) 標準化和開發性
(2) 統壹性和實用性
(3) 參數化設計和靈活性
(4) 安全性和可靠性
(5) 通用性
我國醫院信息系統研制始於20世紀80年代初，醫院信息建設大致經歷了單機操作、局部網絡化、全院信息網絡化建設3個階段。據衛生部信息中心2001年統計，我國應用信息管理系統的醫院占醫院總數的31%，其中省級醫院投資信息管理系統高達84%,地市級和縣級醫院僅為37%和34%。在全國500多家三甲醫院及1000多家縣市以上二級醫院中，有近900家大中小醫院已經實施或正在實施醫院信息系統[12]。
醫院信息化管理的未來：醫院信息化管理建設是壹項長期艱巨的任務。醫院信息管理系統是由多方面的系統組成，並不斷地完善和擴大，使信息化建設覆蓋醫院各項業務建設。隨著信息化技術的發展，醫院信息話建設將更註重人性化服務，優化及提高信息化管理系統功能、性能、人機界面及智能化建設是醫療行業發展的必然趨勢[13]。
醫院信息化建設的根本目的是以病人為中心，實現醫院的網絡化管理，為臨床醫療、經營和管理提供便捷有效的管理手段和管理模式[8]。醫院信息化建設的內容包括醫療行為、行政組織、後勤保障等全方位管理模塊，涉及掛號、收費、藥庫、藥房、醫生工作站、護士工作站、手術、麻醉、財務結算、檢查、檢驗、病案處理、醫保、自助信息查詢等業務。只有對醫院業務流程的優化和重組，進壹步強化信息資源的加工、挖掘，才能不斷提高醫院的醫療服務質量和管理水平，以實現滿意的經濟效益和社會效益[14]。
2 可行性分析
2.1 經濟可行性
鑒於現在的計算機設備價格的逐年下降，在各大中小型的醫院中已經具備配備計算機及計算機操作人員的能力。此外，使用壹個良好的醫院管理系統不僅能提高醫院的管理效率、在很大程度上帶給就醫群眾許多方便，最重要的是能使使用醫院在未來兩到三年內收回成本，從而進壹步的盈利。綜上幾點，說明開發這樣壹個醫院信息管理系統在經濟上是可行的。
2.2 技術可行性
技術可行性又可以分為兩類：開發本系統的技術可行性以及系統使用者的技術的可行性。本系統是使用.NET高級程序語言開發，基於Microsoft Visual Studio 2005為開發平臺，結合Microsoft SQL Server 作為數據源的提供者，所以在系統的開發技術上是可行的；在系統使用者的技術的可行性方面，當今的大學本科畢業生基本上能夠熟練掌握WINDOWS 操作系統的使用，作為壹名醫學類本科畢業的使用者，只要結合用戶說明書就可以熟練地掌握本管理系統的使用方法。可以說在技術上也是可行的。
2.3 政策可行性
衛生部於1997年印發公布的《醫院信息系統基本功能規範》，對於加快醫院信息化基礎設施建設，規範管理，提高醫院信息系統軟件質量，保護用戶利益，推動醫院計算機應用的健康發展起到了重要的指導作用。隨著計算機網絡技術的迅速發展，衛生部重大醫改政策的實施及醫療模式的轉變，給開發本醫院管理系統提供了堅強的政策可行性保障[9]。
3 需求分析
3.1 業務流程
醫院管理的基本業務流程如圖3.1所示：
圖 3.1 醫院管理中的業務流程圖
3.2 系統層次方框圖
該系統由“字典維護”、“門診管理”、“院長查詢”三個壹級子模塊，“字典維護”子模塊由“藥品信息維護”、“收費項目維護”兩個模塊組成；“門診管理”子模塊由“掛號管理”、“劃價管理”、“收費管理”、“藥房發藥”四個模塊組成；“院長查詢”子模塊由“科室掛號量”和“庫存統計”兩個模塊組成。層次方框圖如圖3.2所示。
圖3.2 醫院管理系統層次方框圖
3.3系統中各模塊層次圖
3.3.1系統字典維護
“系統字典維護”功能模塊用於設置醫院管理系統中的常用字典信息，包括了如圖3.3所示的子功能模塊。
圖3.3 系統字典維護模塊
3.3.2門診掛號系統
“門診掛號系統“功能模塊用於建立和維護病人的主索引信息，分配病人的ID號，確保病人信息的唯壹性，為病人建立就診卡，對門診病人進行掛號或者預約號處理，為門診病人的後續活動以及門診工作量統計提供信息。病人首次就醫時可辦理IC卡、磁卡等，實現壹卡通看病，持卡病人就診時通過刷卡代替頻繁的排隊交費，可以大大提高醫院和病人雙方的效率，減少病人的等待時間。掛號時計算機自動分配臨時ID號，可選擇輸入病人姓名，掛號類型（普通號、專家號等）及就診科室等信息，打印產生門診掛號單，掛號單上的條碼號將是病人接下來各環節就醫的依據，這樣將實現劃價收費、項目檢查、藥房取藥的壹體化流水作業。
3.3.3門診劃價管理
“門診劃價收費系統”功能模塊用於在門診收費處記錄病人的繳費信息，並執行相應的統計核算功能，所包含的自功能模塊如圖3.4所示。
圖3.4 “診劃價收費系統”功能模塊
“門診劃價”用於完成門診病人各種處方、檢查申請、治療申請等診治費用的計價工作，各種藥品、檢查的價格信息在字典管理中維護。
“門診收費”用於完成門診病人各種診治費用的收取工作，能依據劃價單（或其他方法）查詢病人劃價信息，進行費用收取、收據打印處理，並保存操作記錄以備查詢。
“藥品發放”用於藥房預先打印需要發貨的藥品明細，並將藥品準備好，這樣病人取藥時就可以直接給病人，避免醫生拿到病人的繳費單後再去找相應的藥品。
3.3.4藥房管理系統
“藥房管理模塊”功能用於管理醫院藥房的采購、入庫及出庫等業務，包含的子模塊如圖3.5所示。
圖3.5 藥房管理模塊
3.3.5院長綜合查詢系統
“院長綜合查詢系統”功能模塊用於從醫院信息系統加工處理出有關醫院管理的醫、教、研和人、財、物分析決策信息，以便院長及管理者決策提供依據。
3.4 系統流程圖
醫院管理系統的系統流程圖如圖3.6所示。
圖3.6 系統流程圖
3.5 系統數據流圖
3.5.1頂級流圖
根據圖3.1的醫院管理的基本業務流程圖可以首先得出系統的頂級數據流圖，如圖3.7所示。
圖3.7 醫院管理系統頂級流圖
3.5.2 0層流圖
根據圖3.7所示的醫院管理系統的頂級流圖，由軟件工程知識：在對數據流圖分層細化時必須保持信息連續性，也就是說，當把壹個處理分解為壹系列處理時，分解前和分解後的輸入/輸出數據流必須相同。[3]可以對頂級數據流圖進行映射，從而得到醫院管理系統的0層流圖，如圖3.8所示。
圖3.8 醫院管理系統0層流圖
3.6 數據字典
3.6.1數據流條目
表3.1描述了系統中所用到的大部分的數據流條目，該表提供了對數據流名字、使用地點與方式、內容和補充信息的說明。
表3.1 數據流條目表
名字 使用地點與方式 內容描述
藥品名稱 藥品信息查詢，輸入名稱 如青黴素
藥品編碼 藥品信息查詢，輸入編號 如1001
項目名稱 收費項目查詢，輸入名稱 如肝功能
項目編碼 收費項目查詢，輸入編碼 如8000
開始時間 科室掛號量查詢，輸入時間 如1998-7-15
結束時間 科室掛號量查詢，輸入時間 如2008-7-15
庫房 藥品庫存量查詢，輸入庫名 如西藥房
藥品編號 藥品庫存量查詢，輸入藥名 如四環素
掛號類型 門診掛號， 系統已定 分為普通號和專家號
費用類型 門診掛號， 系統已定 分為公費，自費，離休三種
掛號科室 門診掛號， 系統已定 分為中醫科等16種
醫生 門診掛號，輸入醫生姓名以記入檔案 在院醫生的姓名
姓名 門診掛號，記錄病人的姓名 就診病人的姓名，如張三
性別 門診掛號，記錄病人的性別 就診病人的性別，如男
年齡 門診掛號，記錄病人的年齡 就診病人的年齡，如36
民族 門診掛號，記錄病人的民族 就診病人的民族，如瑤族
4 概念結構設計
4.1 系統全局實體圖
系統的的全局實體圖如圖4.1所示。
圖4.1 系統全局實體圖
4.2 系統各實體圖
根據圖4.1 系統的全局實體圖，分析系統即可得到系統的各個實體圖，如下列圖所示。
圖4.2 病人實體圖
圖4.3 醫生實體圖
圖4.4 醫生處方實體圖
圖4.5 藥品實體圖
圖4.6 藥房實體圖
4.3 系統表及其用途
系統***需要10張表，用途分別如表4.1所示
表4.1 系統表及其用途
表名稱 表用途
藥品資料 保存醫院藥品的基礎信息，包括售價等
醫生資料 保存醫生信息，包括醫生所屬的科室
科室資料 保存科室分類信息，如分為內科、外科等
病人信息庫 保存病人的基本信息，以後可以重復使用
門診掛號 保存門診病人掛號的信息
門診掛號類型 保存門診掛號類型分類信息及其掛號價格，如普通號、專家號等
門診劃價 門診劃價信息（主表）
門診劃價明細 門診劃價明細信息（從表）
門診收費項目 保存門診的收費項目及其價格信息，內容包括名稱、類型、費用等
5 邏輯結構設計
5.1 邏輯設計規範
數據庫邏輯設計就是將E-R圖轉換成關系模型的過程，即將所有實體和關系轉換成壹系列的關系模式，轉換過程中常見規則有：
(1)壹個實體型轉換成壹個關系模式。
(2)壹個壹對壹的關系模型可轉換成壹個獨立的關系模式，也可與任意壹端對應的關系模式合並。
(3)壹個壹對多的聯系可以轉換成壹個獨立的關系模式，也可與多的那壹端對應的關系模式合並。
(4)壹個多對多的聯系可以轉換成壹個關系模式。
5.2 邏輯結構表
經過數據庫系統分析和邏輯設計後，數據庫的結構已經非常清晰，首先在Microsoft SQL Server 2000 中建立壹個數據庫HisBook。然後，分別建立10個表：藥品資料表、醫生資料表、科室資料表、病人信息庫表、門診掛號表、門診掛號類型表、門診劃價表、門診劃價明細表、門診收費項目表、藥品庫存表，每個表與邏輯設計中壹種的關系模式相對應。
表5.1 系統邏輯結構表
6 物理結構設計
6.1 數據存儲
數據庫采用的是微軟MSSQL Server 數據庫,安裝的版本是:簡體中文個人版,數據庫文件名稱為: hisbook_Data.MDF和日誌文件hisbook_Log.LDF,分別存儲於系統的默認文件夾下面。
6.2 創建索引
建立索引是加快查詢速度的有效手段。用戶可以根據應用環境的需要，在基本表上建立壹個或多個索引，以提供多種存取路徑，加快查找速度。[7]MSSQL Server的兩種索引的類型是:聚集索引和非聚集索引,使用索引的優點是：加快查詢的速度,不足之處是：它將占用磁盤空間，並且降低添加、刪除和更新行的速度，故在使用索引的時候，需要慎重考慮。
針對本系統所涉及到數據庫表，所創建的索引是：
表6.1 創建索引字段表
表名 創建聚集字段 創建非聚集索引字段
藥品資料 MedID MedName
醫生資料 DocID DocName
科室資料 OffID OffName
病人信息庫 PatiID PatiName
門診掛號 PatiRegID PatiRegTime
門診掛號類型 PatiRegKID 無
門診劃價 PriceKind 無
門診劃價明細 ListID ListName
門診收費項目 KindID 無
藥品庫存 MedID MedName
7 編碼
7.1 前臺功能設計
系統的主要功能有三類：字典維護，門診管理，院長查詢。字典維護功能中主要負責藥品信息和收費項目的維護，這是醫院為患者提供的最主要的兩個服務項目。門診管理中有門診掛號、門診劃價、門診收費、藥房發藥四個功能，這與平時去醫院看病的時候在門診處經歷的過程是壹樣的，這四個功能處理患者從掛號直到取藥離開的整個功能。院長查詢主要包括醫院各個科室掛號量和當前藥品庫存量的查詢，這兩個功能主要用於對醫院總體狀態的統計。
7.1.1字典維護
單擊字典維護|藥品信息命令，可以進入藥品信息功能窗體，如圖7.1所示。在其中可以管理醫院目前所有的藥品信息。通過單擊工具欄上的新增、修改、或刪除按鈕可以新增藥品，修改某個藥品的規格，單位或者單價等信息。對數據記錄的編輯和輸入都是在窗體下方面板中的文本框中進行的，除編輯或新增記錄時，窗體下方面板中的文本框都是不可編輯的。
圖7.1藥品信息管理功能窗體
進行藥品信息維護之後，單擊字典維護|收費項目命令則可以進入醫院收費項目的管理窗體，如圖7.2所示。該窗口和藥品信息很類似，它主要管理醫院中所有收費項目的信息。同樣通過上面工具欄的按鈕，可以對該表進行新增、修改、刪除等操作。這個表與藥品信息表中數據的標編號是相連的，藥品的四位編號首位從1到7，而收費項目編號首位是8開始，這是為了在後面的收費中方便進行處理，因為患者經常同時開藥和接受壹些檢查。因此，在新增編號的時候，用戶可以根據患者接受的醫療項目來確定首位編號。
圖7.2收費項目功能窗體
7.1.2門診管理
完成字典維護功能後，點擊門診管理可以進行門診掛號、門診劃價、門診收費、藥房發藥四項功能，這也是按照壹個病人到醫院就診時的基本步驟設計的。
7.1.3院長查詢
在解決方案資源管理器中，添加壹個新的窗體，並將名稱改為“RegQuery”，在其上放置控件如圖7.3所示。
圖7.3 科室掛號量窗體
同樣的， 添加壹個新的窗體，命名為“MedQuery”，在其上放置空間如圖7.4所示。
圖7.4 藥品庫存量窗體
8 系統測試
8.1 軟件測試概述[5]
軟件測試是軟件開發過程的重要組成部分，是用來確認壹個程序的品質或性能是否符合開發之前所提出的壹些要求。軟件測試的目的，第壹是確認軟件的質量，其中壹方面是確認軟件做了妳所期望的事情，另壹方面是確認軟件以正確的方式來做了這個事件。第二是提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。第三軟件產品開發完成之後發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發過程是高質量的。
軟件質量是由幾個方面來衡量的：壹、在正確的時間用正確的方法把壹個工作做正確。二、符合壹些應用標準的要求，比如不同國家的用戶不同的操作習慣和要求，項目工程的可維護性、可測試性等要求。三、質量本身就是軟件達到了最開始所設定的要求，而代碼的優美或精巧的技巧並不代表軟件的高質量。四、質量也代表著它符合客戶的需要。作為軟件測試這個行業，最重要的壹件事就是從客戶的需求出發，從客戶的角度去看產品，客戶會怎麽去使用這個產品，使用過程中會遇到什麽樣的問題。只有這些問題都解決了，軟件產品的質量才可以說是上去了。
測試人員在軟件開發過程中的任務：
(1)尋找Bug
(2)避免軟件開發過程中的缺陷
(3)衡量軟件的品質
(4)關註用戶的需求
總之，測試總的目標是確保軟件的質量以達到用戶所要求的水平。
8.2 常用的軟件測試方法[6]
8.2.1黑盒測試
黑盒測試，顧名思義就是將被測系統看成壹個黑盒，從外界取得輸入，然後再輸出。整個測試基於需求文檔，看是否能滿足需求文檔中的所偶要求。黑盒測試要求測試者在測試時不能使用與被測系統內部結構相關的知識或經驗，它適用於對系統的功能進行測試。黑盒測試的優點有：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關；從用戶角度出發，能和容易地知道用戶會用到哪些功能，會遇到哪些問題；基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低大概只能達到總代碼量的30%；自動化測試的復用性較低。
8.2.2白盒測試
白盒測試是指在測試時能夠了解被測對象的結構，可以查閱被測代碼內容的測試工作。它需要知道程序內部的設計結構及具體的代碼實現，並以此為基礎來設計測試用例。如下例程序代碼：
HRESULT Save(char* pszFileName)
{
If (NULL= = pszFileName)
Return;
If (STATE_OPEND = =currentState)
{
SaveTheFile();
}
Return;
}
讀了代碼之後可以知道，先要檢查壹個字符是否為空，然後再根據文件當前的狀態來執行相應的動作。設計這樣壹些測試用例：當輸入字符串為空時會出現什麽情況；如果此時存儲著的壹個文件已經被打開，會有什麽情況。這些是在做黑盒測試時不壹定能做到的事情。
白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉，它的優點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉壹些功能需求；系統龐大時，測試開銷會非常大。
8.2.3基於模型的測試
基於風險的測試是指評估測試的優先級，先做高優先級的測試，如果時間或精力不夠，低優先級的測試可以暫時先不做。有如下壹個圖8.2.3，橫軸代表影響，豎軸代表概率，根據壹個軟件的特點來確定：如果壹個功能出了問題，它對整個產品的影響有多大，這個功能出問題的概率有多大？如果出問題的概率很大，出了問題對整個產品的影響也很大，那麽測試時就壹定要覆蓋到。對於用戶很少用到的功能，出問題的概率很小，就算出了問題的影響也不是很大，那麽如果時間比較緊的話，就可以考慮不測試[15]。
圖 8.1 基於風險測試的兩個決定因素
基於風險的兩個決定因素就是：該功能出問題對用戶的影響有多大，出了問題的概率有多大。其它壹些影響因素還有復雜性、可用性、依賴性、可修改性等。測試人員主要根據事情的輕重緩急來決定測試工作的重點。
8.3本系統的軟件測試方法
由於本程序是針對小型醫院的，軟件較小，功能比較簡單，所以軟件測試方法采用了黑盒測試方法。軟件在初步完成後，交由第三者進行測試（這裏我讓同宿舍的同學進行了測試），第三者在實際使用中發現問題：如需補充功能，運行中出現的壹些錯誤等等，程序開發人員根據第三者提出的意見進行修改，直至軟件功能符合用戶（系統使用者）為止。
9 結束語
9.1系統功能總結
這個小型的醫院管理系統能夠簡單地完成醫院的門診、藥房、院長查詢基本功能。但是還沒有發票打印的功能，在門診管理部分還不夠完善，沒有實現用磁卡對病人進行登記的功能。本系統大致完成了需求分析中所提及的主要功能，對於在壹種全新的開發語言的背景下完成這樣壹個數據庫系統，工作量和難度還是非常大的，例如如何在.NET環境下連接數據庫，不同模塊之間還存在數據操作的錯誤問題等。
由於在對系統進行設計時的起點和標準過高，在短暫的時間內未能完善全部的子功能、子模塊，但是在建立數據庫表結構時，始終按照壹步到位、不輕易改動的原則，因為壹旦表的結構變動了，相應的邏輯結構、前臺的顯示信息都必須跟著改動，這樣帶來的工作量是十分大的。
9.2對系統的展望
(1)數據結構問題
像在對系統功能總結中提及到的：沒有實現用磁卡對病人進行登記的功能，還未能實現與硬件設備實現連接的接口。
(2)數據的備份和恢復
數據備份功能的實現主要是通過SQL語句BACKUP DATABASE完成的，數據恢復功能的實現主要是通過SQL語句RESTORE DATABASE完成的。由於時間倉促，我沒能實現這兩個功能。
(3)對.NET語言的認識
因為是第壹次使用.NET語言進行相關軟件的編程，在三個星期內開發這樣壹個數據庫系統給了我很大的挑戰和困難，但在謝老師的鼓勵下我本著不斷學習的心態，壹步步的走了過來，希望這次經歷在我以後的學習中將會產生很大的影響。
(4).NET中訪問數據庫的方法
這個系統是基於.NET框架設計與實現的，在.NET中訪問數據庫的方法我只是參照壹些參考書給出的方法和代碼來實現，自己卻不是十分清楚它其中的原由。
(5)系統的可擴展性
這次開發的系統還存在著許多可以完善的功能，例如每月或每年壹次的財務結算，醫院在院職員的信息庫的建立等，這都是壹個完善的醫院管理系統所必須的。