門診製作規章制度內容

① 求個體診所的規章制度。

診斷室工作制度

1、遵守工作紀律，不遲到，不早退，工作時間不脫崗。
2、認真填寫門診日誌，按規定建立各類檔案，要求管理規范化。
3、遵守無菌操作規程，堅持查對制度。
4、保持環境整潔，落實消毒措施。
5、開展便民服務，服務熱情、耐心，樹立良好醫德。

治療室工作制度

1、經常保持室內清潔，凡做完一項處置，要隨時清理。每天消毒一次，除工作人員及治療患者外，不許在室內逗留。
2、器械物品放在固定位置，各種葯品分類放置，標簽明顯，字跡清楚。
3、嚴格執行無菌技術操作，進入治療室必須穿工作服、戴工作帽及口罩。
4、無菌持物鉗浸泡液每天更換1次(器械消毒液)，頭皮針、靜脈導管酒精浸泡液經常保持75%的濃度。
5、已用過的注射用具要隨手清理、清點，每日更換。
6、無菌物品須註明滅菌日期，超過1周者重新滅菌。

處置室工作制度

1、凡各種注射應按處方或醫囑執行。對過敏的葯物必須按規定做好注射前的過敏試驗。
2、嚴格執行查對制度，對患者熱情、體貼。
3、密切觀察注射後的情況，發生注射反應或意外，應及時進行處置，並報告醫師。
4、嚴格執行無菌操作規定，操作時應戴口罩、帽子。器械要定期消毒和更換。保證消毒液的有效濃度。注射應做到每人一針一管。
5、准備搶救葯品器械，放於固定位置，定期檢查，及時補充更換。
6、室內每天要消毒，定期采樣培養。
7、嚴格執行隔離消毒制度，防止交叉感染。
8、換葯時除固定敷料外(綳帶等)，一切換葯物品均需保持無菌，並註明滅菌日期，超過1周者重新滅菌。無菌溶液超過3日要重新消毒。
9、器械浸泡液每周更換2次。
10、換葯時，先處理清潔傷口，後處理感染傷口。
11、特殊感染不得在處置室內處理。

傳染病疫情報告管理制度

1、診所負責人為責任疫情報告人。責任疫情報告人發現法定傳染病病人、疑似病人、病原攜帶者應在規定的時限內，向縣衛生行政部門報告。
2、診所人員要認真學習《傳染病防治法》、《突發公共衛生事件應急處理條例》等法律、法規和傳染病防治知識，熟練掌握傳染病診斷、報告、隔離消毒及疫情處理的程序，切實增強傳染病疫情報告意識，發現傳染病例要認真做好傳染病登記，填寫傳染病報告卡，在規定時限內向縣衛生行政部門報告。
3、任何單位和個人對突發事件和傳染病疫情，不得隱瞞、緩報、謊報或者授意他人隱瞞、緩報、謊報，否則將依法追究責任。
4、任何單位和個人發現甲型H1N1流感病人、傳染性非典型肺炎病人或者疑似病人時，必須在2小時內以最快的方式向衛生行政部門報告。

② 診所的醫療規章制度

請哪位好友幫忙把這幾個也發一下《消毒隔離制度》，《感染管理制度》，《醫療廢物處理制度》《注射室制度》《處置室制度》不勝感激，謝謝

③ 資料庫管理制度、樣本採集等SOP制定是什麼意思該怎麼寫啊急急急！！

醫院信息系統（Hospital Information System，HIS），指利用電子計算機和通信設備，為醫院所屬的各部門提供病人診療信息和行政管理信息的收集、存儲、處理、提取和數據交換的能力，並滿足所有擁有授權的用戶的功能需求 [1]。該系統的開發符合醫療保險各項政策的要求和規范；文中對系統的三個子模塊功能做了詳細的說明；本系統採用了多層客戶機/伺服器（C/S）模型，利用Visual C++.NET開發語言完成系統的製作。
軟體完成後將擁有「字典維護」、「門診管理」、「院長查詢」三個模塊，它針對軟體所處的應用環境而發揮軟體的高效作用，「字典維護」模塊存儲了葯品信息和收費項目，以供葯品的進存提供數據；「門診管理」模塊擁有門診掛號、門診劃價、門診收費、葯房發葯四個子功能；「院長查詢」模塊則提供了一個供醫院高層領導直接查詢醫院任何時間的科室掛號量和葯品庫存量。
本系統的開發平台為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)系統的可擴展性
這次開發的系統還存在著許多可以完善的功能，例如每月或每年一次的財務結算，醫院在院職員的信息庫的建立等，這都是一個完善的醫院管理系統所必須的。

④ 醫院規章制度包括那些

一、"燙火爐"原則與醫院制度建設：
制度規范是醫院的"法"，是"燙火爐"。"燙火爐"的主要原則體現在：不碰不燙、一碰即燙、誰碰燙誰、哪碰燙哪這四個方面。
1、不碰不燙：不容忍一點點的疏忽，嚴格遵守規章制度。
2、一碰即燙：違背了規章制度，及時進行處罰。（降職、降薪、開除）
3、誰碰燙誰：絕對一視同仁，制度規范無差別對待。
4、哪碰燙哪：制度不搞誅連、遷怒、對事不對人、懲罰適度。
二、規章制度分三大部分：
第一部分：行政管理制度
第二部分：醫療工作制度
第三部分：崗位責任制
第一部分 行政管理制度（共19章）
第一章 工作人員行為准則
第二章 醫德規范要求
第三章 會議制度
第四章 請示報告制度
第五章 文書檔案、管理制度
第六章 硬體的使用管理
第七章 辦公用品的管理
第八章 微機、復印機、傳真機的使用和管理制度
第九章 葯品采購制度
第十章 葯品、物品、器械管理制度
第十一章 物資、庫房管理制度
第十二章 員工的住宿、交通制度
第十三章 食堂的管理制度
第十四章 車輛服務制度
第十五章 維修組的工作制度
第十六章 安全、保衛制度
第十七章 衛生、清潔制度
第十八章 洗衣房的管理制度
第十九章 咨詢中心的管理制度
工作人員的行為准則：
1、服務理念：患者的滿意是我們最大的追求，患者的健康是我們共同的心願，用親情服務，用愛心施術。
2、儀表、儀容：美觀、整潔、大方、得體。
3、服務語言：
（1）稱謂：按職業、職位、統稱。
（2）要尊重患者和患者家屬；吐字准確（講普通話）；要有情感性，快慢適中；要有保護性（注意患者的隱私、缺點）。
（3）常用的謙語。
（4）禁忌的語言：推理性的語言，頂撞性語言，傷害性語言。
4、行為規范：
（1）服從領導，聽從指揮。
（2）嚴於職守，認真工作。
（3）優質服務，禮貌待人。
（4）打電話時，要時間適宜，一般不得超過3分鍾，語言簡練。
5、勞動紀律：按時上崗，工作時不準干私活，不能串崗、換崗、離崗、聊天。
6、職業紀律：醫務人員書寫要符合要求，不能亂開證明文件，不能開展特殊醫療服務，不能隨便評價他人的醫療技術，不能私收財物，不能私自轉院，不能推薦葯品、生活用品、保健品、辦公用品等。
7、安全守則：嚴格遵守醫院各項規章制度。
第二部分 醫療工作制度（共44章）
第一章 行政總值班制度
第二章 病例書寫制度
第三章 查房制度
第四章 查對制度
第五章 醫囑制度
第六章 會診制度
第七章 轉院、轉科制度
第八章 病例討論制度
第九章 病房管理制度
第十章 護理工作制度
第十一章 分級護理制度
第十二章 護理文件書寫
第十三章 護理差錯事故登記
第十四章 值班、交接班制度
第十五章 消毒、隔離制度
第十六章 處方制度
第十七章 病案管理制度
第十八章 差錯事故登記報告糾紛制度
第十九章 醫療登記統計制度
第二十章 探視陪伴制度
第二十一章 病人出入院管理制度
第二十二章 賠償制度
第二十三章 抗生素使用制度
第二十四章 醫院感染管理制度
1、醫院感染登記報告制度
2、監控示意圖
第二十五章 門診工作制度
第二十六章 治療室工作制度
第二十七章 注射室工作制度
第二十八章 換葯室工作制度
第二十九章 腹瀉病門診工作制度
第三十章 掛號室收費工作制度
第三十一章 急診科工作制度
第三十二章 搶救室工作制度
第三十三章 麻醉科工作制度
第三十四章 理療科工作制度
第三十五章 檢驗科工作制度
第三十六章 功能檢查科工作制度
第三十七章 住院處工作制度
第三十八章 手術室工作制度
第三十九章 葯劑科工作制度
第四十章 供應室工作制度
第四十一章 一次性醫療衛生用品管理制度
第四十二章 放射科工作制度
第四十三章 麻醉葯品的管理工作制度
第四十四章 精神葯品的管理工作制度
第三部分 崗位責任制（共52章）
第一章 院長的崗位職責
第二章 業務副院長的崗位職責
第三章 辦公室主任的崗位職責
第四章 首診醫師負責制
第五章 三級醫師責任制
第六章 各級護理人員的崗位職責
第七章 掛號員、收費員崗位職責
第八章 臨床科主任崗位職責
第九章 臨床主任或副主任醫師崗位職責
第十章 臨床主治醫師崗位職責
第十一章 葯劑科主任崗位職責
第十二章 中葯師崗位職責
第十三章 葯劑士崗位職責
第十四章 檢驗科主任崗位職責
第十五章 主管檢驗師、士崗位職責
第十六章 放射科主任崗位職責
第十七章 放射科醫師、士崗位職責
第十八章 理療科醫師、士崗位職責
第十九章 功能檢查科醫師、士崗位職責
第二十章 麻醉醫師崗位職責
第二十一章 住院醫師崗位職責
第二十二章 門診部護士長崗位職責
第二十三章 門診護理人員崗位職責
第二十四章 門診注射室護理人員崗位職責
第二十五章 手術室護士崗位職責
第二十六章 治療室醫護人員崗位職責
第二十七章 病房護士長崗位職責
第二十八章 病房護士崗位職責
第二十九章 供應室護士崗位職責
第三十章 急診室護士崗位職責
第三十一章 巡迴護士崗位職責
第三十二章 洗手護士崗位職責
第三十三章 器械護士崗位職責
第三十四章 病案管理人員崗位職責
第三十五章 計算機室工作人員崗位職責
第三十六章 後勤保障部人員崗位職責
第三十七章 汽車駕駛員崗位職責
第三十八章 廚師崗位職責
第三十九章 洗衣工崗位職責
第四十章 維修人員崗位職責
第四十一章 保安人員崗位職責
第四十二章 導醫崗位職責
第四十三章 庫管人員崗位職責
第四十四章 醫療統計人員崗位職責
第四十五章 人事科科長崗位職責
第四十六章 人事科幹事崗位職責
第四十七章 醫院感染管理領導小組崗位職責
第四十八章 醫院感染管理兼職人員崗位職責
第四十九章 醫院質量管理小組崗位職責
第五十章 醫院醫療事故簽定小組崗位職責
第五十一章 咨詢中心工作人員守則
第五十二章 咨詢中心工作人員職責