軟件完成後將擁有字典維護、門診管理、院長查詢三大模塊，在軟件所在的應用環境中發揮高效作用。字典維護模塊存儲藥品信息和收費項目，為藥品存儲提供數據。“門診管理”模塊有四個子功能:門診掛號、門診定價、門診收費和藥房調劑；“院長查詢”模塊為醫院高層領導提供了隨時查詢科室掛號和藥品庫存的直接查詢。
本系統的開發平臺是微軟公司的開發工具——Microsoft Visual Studio 2005，並結合數據庫軟件——Microsoft SQL Serer作為系統所用數據源的支撐平臺。
關鍵詞:醫院管理系統；VC++。網；數據庫；數據庫系統
目錄
導言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
基於模型的測試24
8.3本系統的軟件測試方法25
9結論26
9.1系統功能匯總26
9.2系統的前景26
致謝辭
參考文獻28
介紹
醫院信息系統(HIS)已被國際學術界公認為新興醫學信息的壹個重要分支。美國該領域著名教授莫裏斯·科倫(Morris Collen)在1988中對醫院信息系統的定義是:利用電子計算機和通信設備，能夠為醫院各部門提供收集、存儲、處理、提取和交換患者診療信息數據並滿足所有授權用戶功能需求的能力。[4]經過多年的發展，像醫院信息系統這樣的企業級應用軟件，不僅可以提供靜態信息和交互式動態信息服務，還可以提供應用基礎設施服務(如安全、事務、傳輸、緩沖、生命周期管理等。).目前，這類軟件采用N層結構構建。N層結構的優勢在於，每壹層都可以獨立更改，而不會影響其他層，這降低了部署和維護的成本[66]
為了滿足上述問題，關鍵是不僅要重用舊代碼，而且要重用相似的分析和設計結果及架構，以降低構建新軟件系統的成本，提高軟件的可靠性。框架技術就是這樣壹種面向領域的復用技術，由於它提供了很好的復用性，被認為是最有前途的面向對象技術。雖然單個類的重用是有用的，但由於它的工作量很小，所以在生產率方面並沒有有意義的飛躍。基於框架的軟件開發過程將軟件開發視為壹個組裝過程，在軟件框架的指導下，尋找可復用的組件(並開發壹些新的組件)並組裝系統。這個發展過程是目前非常重要的研究方向。目前針對企業級應用提出了壹些解決方案。微軟的。NET框架和SUN公司的J2EE是兩種最流行和最成熟的體系結構，它們可以簡化與企業應用程序的開發、部署和管理相關的復雜問題。Microsoft.Net是微軟公司於2000年推出的新壹代Windows開發系統平臺。的。NET平臺包括以下主要功能:[10]
(1)軟件服務
(2)基於XML的* * *相同語言
(3)集成多種設備和平臺
(4)新壹代人機界面
(5)托管代碼公共語言運行時。
本文參考了軟件工程中開發壹個軟件的相關步驟，結合數據庫的相關知識，按照軟件定義、軟件開發、運維三個步驟來開發軟件。其中，軟件開發步驟有所不同，包括數據庫的概念結構設計、邏輯結構設計和物理結構設計。
1簡介
醫院信息管理系統的主要目標是建立壹個新的社會保障體系，既能保證所有員工公平地獲得基本醫療保健服務，又能有效地控制浪費，合理利用醫療資源。隨著科學技術的進步和人民生活水平的提高，醫院信息管理需要進壹步系統化和科學化，建立醫院信息管理系統是大勢所趨。同時，為了更好地落實國家、省、市醫療保險改革的各項政策，建立職工正常基本醫療和補充醫療保險的良好運行機制，經過充分醞釀、研究和論證，在吸收了各類醫院管理制度的經驗後，制定了醫院管理制度[2]。
預計該系統建成後將實現以下六個目標:
(1)標準化與開發
(2)統壹性和實用性
(3)參數化設計和靈活性
(4)安全性和可靠性
(5)普遍性
我國醫院信息系統的發展始於20世紀80年代初，醫院信息化建設大致經歷了單機運行、局部聯網和全院信息聯網三個階段。據衛生部信息中心2001統計，我國應用信息管理系統的醫院數量占醫院總數的31%，其中省級醫院投入信息管理系統高達84%，而地市級和縣級醫院僅為37%和34%。在500多家三甲醫院和1000多家縣級以上二級醫院中，已有近900家大中小醫院實施或正在實施醫院信息系統[102]。
醫院信息管理的未來:醫院信息管理的建設是壹項長期而艱巨的任務。醫院信息管理系統由多個系統組成，並不斷完善和擴展，使信息化建設覆蓋醫院的所有業務建設。隨著信息技術的發展，醫院信息化建設將更加註重人性化服務。優化和完善信息管理系統的功能、性能、人機界面和智能化建設是醫療行業發展的必然趨勢[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門診登記制度
“門診掛號系統”功能模塊用於建立和維護病人的主要指標信息，分配病人的身份證號，保證病人信息的唯壹性，為病人建立就診卡，登記或預留門診號，為門診病人的隨訪活動和門診病人的工作量統計提供信息。患者可以辦理IC卡、磁卡等。第壹次看病，從而實現壹卡通就醫。持卡患者通過刷卡代替頻繁排隊繳費，可以大大提高醫患雙方的效率，減少患者的等待時間。註冊時，電腦自動分配壹個臨時身份證號。可以選擇輸入患者姓名、掛號類型(普通號、專家號等)等信息。)和醫務科，並打印出門診登記表。掛號單上的條碼號將作為患者下壹次就醫的依據，實現定價收費、項目檢查、藥房取藥的壹體化流水作業。
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創建索引字段表
表名創建聚集字段創建非聚集索引字段
藥物信息媒體名稱
醫生信息DocIDDocName
部門信息
患者信息庫PatiIDPatiName
門診掛號病人掛號時間
門診登記類型PatiRegKID無
門診定價價格種類無
門診定價詳細信息列表列表名稱
門診收費項目種類無
藥品庫存MedIDMedName
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%左右；自動化測試的可重用性很低。
白盒測試
白盒測試是指能夠理解被測對象的結構並參考被測代碼內容的測試工作。它需要了解程序的內部設計結構和具體的代碼實現，並在此基礎上設計測試用例。下面是示例程序代碼:
HRESULT保存(char* pszFileName)
{
If (NULL= = pszFileName)
返回；
If (STATE_OPEND = =currentState)
{
save the file()；
}
返回；
}
看完代碼可以知道，首先要檢查壹個字符是否為空，然後根據文件的當前狀態執行相應的動作。設計壹些測試用例:當輸入字符串為空時會發生什麽；如果此時存儲的文件已經打開，會發生什麽情況？這些是妳在做黑盒測試時可能做不到的事情。
白盒測試的直接好處是知道設計的測試用例在代碼級別的什麽地方被忽略了。它的優點是幫助軟件測試人員增加代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。白盒測試的缺點是:程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試是基於代碼的，只能測試開發者做的是否正確，無法知道設計是否正確，可能會遺漏壹些功能需求；當系統龐大時，測試開銷會非常大。
基於模型的測試
基於風險的測試是指評估測試的優先級，先做高優先級的測試。如果沒有足夠的時間或精力，低優先級的測試可以暫時中止。有如下圖8.2.3。橫軸代表影響力，縱軸代表概率。根據壹個軟件的特點，確定:如果壹個功能出了問題，對整個產品的影響有多大，這個功能出問題的概率有多大？如果出現問題的概率很大，而且問題對整個產品的影響很大，那麽在測試的時候壹定要覆蓋。對於用戶很少使用的功能，出現問題的概率很小，即使出現問題，影響也不大，所以如果時間緊張，可以考慮不測試[15]。
圖8.1基於風險測試的兩個決定因素
基於風險的兩個決定性因素是:功能對用戶的影響有多大，出問題的概率有多大。其他影響因素包括復雜性、可用性、依賴性和可修改性。測試人員主要是根據事情的輕重緩急來決定測試工作的重點。
8.3本系統的軟件測試方法
因為這個程序是針對小醫院的，軟件比較小，功能也比較簡單，所以軟件測試方法采用黑盒測試方法。軟件初步完成後，由第三方對軟件進行了測試(這裏我讓同宿舍的同學進行了測試)。當第三方在實際使用中發現問題，比如需要補充功能，操作上的壹些錯誤等。，程序開發者根據第三方提出的意見進行修改，直到軟件功能滿足用戶(系統用戶)。
9結束語
9.1系統功能匯總
這個小型的醫院管理系統可以簡單的完成醫院門診、藥房、院長查詢的基本功能。但是沒有發票打印功能，門診管理部分不完善，沒有實現磁卡掛號病人的功能。本系統基本完成了需求分析中提到的主要功能。對於在壹種全新的開發語言背景下完成這樣壹個數據庫系統，工作量和難度還是很大的，比如如何在。NET環境下，不同模塊之間仍然存在數據操作錯誤。
由於設計系統時的起點和標準較高，所有的子功能和子模塊不可能在短時間內完善。但是在建立數據庫表結構時，我們總是遵循“壹步到位，不易更改”的原則，因為壹旦表結構發生變化，相應的邏輯結構和前臺顯示信息也必須隨之改變，這就帶來了很大的工作量。
9.2系統的前景
(1)數據結構問題
在系統功能總結中提到，沒有實現磁卡掛號病人的功能，沒有實現與硬件設備的接口。
(2)數據備份和恢復
數據備份功能的實現主要是通過SQL語句備份數據庫，數據恢復功能的實現主要是通過SQL語句還原數據庫。由於時間倉促，我沒能實現這兩個功能。
(3)對的理解。網絡語言
因為是第壹次用。NET語言來編程相關軟件，三周時間開發這樣壹個數據庫系統給了我很大的挑戰和困難，但是在謝老師的鼓勵下，我是抱著不斷學習的心態壹步步走過來的，希望這段經歷對我以後的學習有很大的影響。
(4)數據庫的訪問方法。網。
本系統是基於。NET框架。我只是參考壹些參考書中給出的方法和代碼來實現在中訪問數據庫的方法。NET，但我不太清楚為什麽。
(5)系統的可擴展性
本次開發的系統還有很多可以改進的功能，如每月或每年的財務結算，醫院員工信息庫的建立等。這是壹個完善的醫院管理系統所必需的。