【正文】 財富，并能使醫(yī)院其他人員共享。 2. 支持并改進臨床醫(yī)生，護理人員及管理人員的工作流程。 3. 節(jié)省花費在其他部門或科室尋找書面圖表，臨床數據，醫(yī)療歷史，以及其它書面記錄的時間。 4. 通過對以往由科室或醫(yī)生所進行的診療活動的便捷回顧，幫助醫(yī)師診斷與治療。減少了不必要或冗余的操作。 5. 進行醫(yī)療質量統計，病歷檢索。 對于醫(yī)護人員 1. 及時的接受來自醫(yī)生的診斷和醫(yī)囑信息，在一段時間內 ，形成病人的治療和護理計劃。 2. 及時的接受來自醫(yī)生 的 申請單，在一段時間內，形成 執(zhí)行申請單 計劃。 3. 直接管理醫(yī)囑執(zhí)行及護理業(yè)務。 4. 幫助醫(yī)護人員理解病人康復所需要的看護活動。 5. 對護理人員的工作量記錄。 對于管理人員 14 1. 通過監(jiān)控，分析，總結資源，最好地利用醫(yī)院的資源。 2. 保證了病人掛號、拿藥等業(yè)務的迅速、井然有序 。 3. 醫(yī)療必要的回顧、統計和查詢， 為 以后 的決策提供詳細數據支持。 醫(yī)院門診管理系統 需求獲取模式 需求分析描述系統的需求，通過定義系統中的關鍵域類來建立模型。分析的根本目的是在開發(fā)者和提出需求的人之間建立一種理 解和溝通的機制，因此，醫(yī)院管理信息系統的需求分析也應該是開發(fā)人員和用戶或者客戶一起完成的。 分析需求的第一步描述醫(yī)院管理信息系統的功能，即定義用例，以此確定系統的功能需求。 醫(yī)院門診管理系統 的用例分析主要涉及規(guī)格說明的閱讀和分析，需要和 醫(yī)院門診管理系統 的潛在用戶進行討論 [7]。 第二步，對第一步中確定的所有用例 進行 分析 ， 可以用用例圖進行描述 。通過對每個用例的分析，確定系統需要實現的功能， 劃分系統的 子系統 大致范圍，明確系統的目標。 第三步， 調研每個子系統所需的工作流程、功能與處理規(guī)則，收集 掛號 、收費單據、申請單 等原始資料，分析 如何用數據流來實現業(yè)務處理過程中的信息傳遞 。 第四步，對調研的內容事先準備 ， 針對不同管理層次的用戶詢問不同的問題，列出問題清單。將操作層、管理層、決策層的需求既聯系又區(qū)分開來，形成一個金字塔，使下層滿足上層的需求。 第五 步 ， 對與用戶溝通的情況及時總結歸納 ， 整理調研結果 ， 找出新的疑點，初步構成需求基線。 第六 步 ， 若基線符合要求，則需求分析完畢。反之返回到第一步或第二或以上其它幾 步 ,如此循環(huán)多次，直到需求 分析使雙方滿意為止。 山東大學碩士學位論文 15 醫(yī)院門診管理系統 需求問題描述 醫(yī)院門診管理系統 功能性需 求 通過對 醫(yī)院門診管理系統 的終端用戶和客戶進行調研后，我們了解到投入使用的醫(yī)院體系結構分為門診掛號、 醫(yī)師 工作站、門診收費、藥房、護士工作站五個部門， 具體體系結構圖如圖 21 所示。各個部門的主要職責如下描述。 門診掛號：完成病人的掛號工作，由 掛號 員 完成。 醫(yī)師 工作站： 對已掛號持有掛號單據的病人進行就診，確定是否開立醫(yī)囑有醫(yī)生完成。 門診收費：根據需要拿藥或者申請醫(yī)務護理的病人的醫(yī)囑進行劃價收費，由 門診收費 人員完成。 藥房：給已交費持有醫(yī)囑單和交費單據的病人拿藥，有門診藥房 藥劑師 完成。 護士工作站： 根據病人的醫(yī) 囑和交費單據對病人進行必要的護理，有護士人員完成。 根據以上對醫(yī)院各部門的分析，我們形成系統模塊圖如圖 23 所示。 醫(yī) 囑 處 理門 診 病 歷 管 理門 診 掛 號門 診 收 費門 診 醫(yī) 師 工 作 站門 診 藥 房門 診 護 士掛 號 員收 費 員醫(yī) 師藥 劑 師病 人 圖 23 系統模塊圖 經過調研和整理，我們將系統分成六個模塊，依次為：門診掛號、門診病 16 歷管理、門診醫(yī)師工作站、門診收費、門診藥房、醫(yī)囑處理。這六個部分涵蓋了 醫(yī)院門診管理系統 的多有部分，在每個部分中還可以延伸多個功能的實現，每項業(yè)務的操作人員不同，實現各負其職，職責分明。 醫(yī)院的角色是醫(yī)生、護士、病人和管理人員。 其中管理人員包括醫(yī)院管理人員和系統管理人員。醫(yī)生、護士和醫(yī)院管理人員是系統的用戶、而系統管理人員是信息系統的管理者，雖然系統管理員可能也是一個醫(yī)生或護士，但這并不影響本系統的功能。同樣，醫(yī)生或者護士也可能是一個病人，但這也不影響系統的功能。我們首先分析一下整個醫(yī)院信息系統的用例圖，然后再重點看一下門診掛號收費系統的用例分析。 醫(yī)院門診管理系統 的用例主要包括如下內容 [7]。 門診掛號 建立病歷 門診收費 藥房 拿藥 診斷病人 查詢病歷 設定醫(yī)囑 執(zhí)行醫(yī)囑 上面所列的用例中沒有退號退費 退藥、系統維護和信息的統計查詢等，具體的用例將在后面 描述功能需求 時詳細列出。使用 visio 軟件進行 UML 建模，如圖 24 所示。 山東大學碩士學位論文 17 門 診 掛 號建 立 病 歷門 診 收 費藥 房 拿 藥查 詢 病 歷診 斷 病 人設 定 醫(yī) 囑執(zhí) 行 醫(yī) 囑醫(yī) 院 管 理 員醫(yī) 生護 士 圖 24 醫(yī)院門診管理系統 用例圖 這是對 醫(yī)院門診管理系統 的分析通過用 UML 的用例圖來描述，從這個用例圖中我們可以看出系 統包括的所有用例以及用例與角色交互信息 [7]。 1. 門診掛號 記錄 掛號信息→查詢病例→建立病歷。 2. 建立病歷 增加病歷信息。 3. 門診收費 查看醫(yī)囑→處方劃價→處方收費。 4. 藥房拿藥 查看醫(yī)囑→查看單據→發(fā)藥。 5. 診斷病人 查詢病人病歷→設置診斷內容→記錄診斷結果。 6. 查 詢病歷 輸入病歷查詢條件→查詢病歷。 7. 設定醫(yī)囑 18 查詢病歷→查詢診斷信息→設定醫(yī)囑。 8. 執(zhí)行醫(yī)囑 查詢病歷→查詢診斷信息→查詢醫(yī)囑→執(zhí)行醫(yī)囑。 我們重點講述一下醫(yī)院門診掛號系統的功能需求。 醫(yī)院門診管理系統 的掛號 子系統的業(yè)務由醫(yī)院管理人員完成實現，相應的操作人員稱掛號員。 經分析 ，掛號部分的業(yè)務需求如下。 1. 記錄就診病人的基本信息，包括：病人姓名、性別、年齡、地區(qū)、電話、職業(yè)等信息，并與 醫(yī)院門診管理系統 的其它子系統相連，及時提供醫(yī)療臨床業(yè)務，醫(yī)院管理分析、統計所需的病人基本資料。 2. 借助共享病人基本信息，避免資料的重復 輸入，病人就診后續(xù)的各種業(yè)務都共享此信息，提高工作效率，同時也保證了數據的一致性。 3. 提供就診卡管理業(yè)務，使病人賬戶系統與整個信息管理系統很好地結合在一起，改變現有的醫(yī)療收費方式，提高收費工作效率，減少病人排隊次數和時間。 4. 建立符合醫(yī)院財務制度掛號收費流程和退費流程。 5. 統計與查詢。包括醫(yī)院門診工作量的統計等。 醫(yī)院門診管理系統 的掛號部分 的用例包括。 門診掛號 建立病歷 查詢病歷 門診退號 門診退費 掛號查詢 磁卡管理 系統設置 使用 visio 軟件進行 UML 建模，如圖 25 所示。 山東大學碩士學位論文 19 門 診 掛 號建 立 病 歷查 詢 病 歷門 診 退 號門 診 退 費掛 號 查 詢磁 卡 管 理系 統 設 置掛 號 員 圖 25 掛號系統用例圖 門診掛號系統 不是獨立的，建立在整個 醫(yī)院門診管理系統 基礎之上，以及和醫(yī)院系統中其他業(yè)務也存在著一定的聯系，掛號系統與其他系統之間的關系示意圖如下圖 26 所示。 20 掛 號 系 統病 人 管 理病 人 信 息 就 診卡資 源排 班 表病 人 管 理醫(yī) 療 收 費財 務 管 理病 人 帳 戶病 人 訪 問掛 號 信 息 病 人醫(yī) 院 管 理 人 員業(yè) 務 財 務門 診 醫(yī) 生 圖 26 門診系統與其他系統之間的關系示意圖 病人在醫(yī)院門診就診，第一步驟是進行掛號登記，繳納一定掛號費用，獲取掛號單。病人需要提供病人姓名，病人類型，就診科室或者專家名稱等基本信息，系統確定病人的掛號費用、科室序號等數據，并打印掛號單 據（報核聯、發(fā)票聯），并對病人產生門診流水號。病人在醫(yī)院就診過程中，可能出現就診異常中止的情況，例如，所選的醫(yī)生不在，所掛科室錯誤，掛號員操作失誤等情況，都需要進行退號，退號操作并非將已有的掛號信息刪除，而是進行標記，表示該掛號單作廢，以便于將來進行統計。同時對退回病人的掛號費用，可以選擇性地收取一定額度的手續(xù)費。另外，掛號 系統還需要實現對病人病歷和掛號記錄的查詢、實現對就診磁卡的查詢和管理，方便病人的就診和對醫(yī)院對病人的管理、實現系統的登錄維護功能，管理人員可以添加刪除掛號員，設置登錄權限。掛號員可以對登 錄密碼進行更改等。 醫(yī)院門診管理系統 非功能性需求 除了 系統 所需要實現的基本業(yè)務功能需求外， 醫(yī)院門診管理系統 還應具有以下非功能性需求 。 1. 系統 運行 參數 管理 山東大學碩士學位論文 21 系統運行參數是整個系統維護和監(jiān)測的重要依據，必須進行管理。 2. 數據 字典 管理 數據庫的重要部分是數據字典。它存放有數據庫所用的有關信息，對用戶來說是一組只讀的表。數據字典內容包括數據庫中所有模式對象的信息，如表、視圖、簇、及索引等 關鍵信息， 是必須進行管理的部分。 3. 組織機構、權限等信息 管理 整個 醫(yī)院門診管理系統 包括多個子系統，而且各個功能使用需要一定的權限，保證數據的安全可靠，所以需要對醫(yī)院的組織機構及其權限和信息系統的功能模塊進行對應，實現真正意義上的安全、可靠、滿足用戶需求。 4. 硬件配置的需求 硬件配置主要包括客戶端硬件的選擇和服務器端硬件的選擇。 醫(yī)院門診管理系統 的硬件配置要根據用戶對系統的穩(wěn)定性要求、系統的容量、系統的吞吐量以及用戶的維護水平來確定。 客戶端硬件選擇：可以根據穩(wěn)定性要求選擇不同的客戶端。一般情況下，對客戶端的不高。其中醫(yī)生和護士客戶端穩(wěn)定性要求低，可以選用pentiumCPU/64MB/4G 配置的客戶端，掛號門診客戶端穩(wěn)定性要求中，可以 選用 pentiumⅢ /256MB/20GB 配置的客戶端。 服務器端硬件選擇：可以根據數據量和吞吐量的大小選擇不同的服務器硬件。設施完備的小型醫(yī)院如校辦醫(yī)院每秒數據庫并發(fā)數據訪問記錄數在 50~500之 間 ， 穩(wěn) 定 性 要 求 中 ， 維 護 水 平 一 般 ， 可 以 選 用 XEON(Xeon) 雙CPU/1GB/RAID53 72GB 配置的服務器。 5. 網絡配置的需求 可以根據用戶情況選擇不同的網絡配置，可以使用單擊模式， 即服務器和客戶端在一臺計算機上，也可以采用百兆模式、千兆模式。設施完備的小型醫(yī)院如校辦醫(yī)院可以選用百兆模式，即計算機網絡的速度要 求百兆 [7]。 22 第 3 章 醫(yī)院門診管理系統 概要設計 醫(yī)院門診管理系統 目標和原則 在現有國情下，一種成功、可行的醫(yī)院信息系統必須滿足以下條件：能滿足醫(yī)院外部不斷變化的政策需求；能滿足醫(yī)院內部不斷增長的信息化管理需求；既能規(guī)范醫(yī)院管理，又能最大限度地滿足不同醫(yī)院個性化管理需求；能真正有效地挖掘醫(yī)院的潛在需求和提供長遠服務保障；醫(yī)院 HIS 系統的建設過程不是簡單的買賣、安裝過程，公司與醫(yī)院的關系不是主動與被動的關系，而是互動與緊密合作的關系。 要滿足以上條件，醫(yī)院信息系統軟件的設計、開發(fā)思路必須進行重大調整 ，必須具備非常大的靈活性和可塑性，以滿足 無休止 的管理需求變化及管理流程改變。所以，新的 醫(yī)院門診管理系統 建設必須具備以下目標和原則 。 首先，軟件設計思路的變革。 醫(yī)院門診管理系統 不能被設計成一個固定的、難以修改的最終產品，而應是一個信息資源平臺。該平臺應具有良好的開放性、標準性、規(guī)范性和可塑性，能根據不同醫(yī)院的不同需求，快速生成滿足醫(yī)院要求的個性化 信息 系統。 整個平臺采用面向對象的設計。在醫(yī)院管理領域中，深層次的挖掘管理內涵與業(yè)務本質，不再是從當前醫(yī)院表面的管理流程入手來設計。通過對業(yè)務領域的分析，識別出醫(yī)院 業(yè)務管理概念及其關系即對象及其層次關系。當醫(yī)院的管理流程變化時，平臺將會很快地適應其變化。保證了用戶系統強勁的持續(xù)力和很高的穩(wěn)定性和可靠性。這樣用戶的應用模塊系統實現了迭代增量的系統發(fā)展過程。 其次， 在實現上采用 Rational Rose 或 visio 完成組件平臺設計，采用PowerBuilder 完成組件平臺建設，后端數據存儲可以是當前流行的各種數據庫，Oracle,SQL Server 等。在部署上采取分布式網絡結構，實現存儲分布，計算分布，顯示多樣。以便減少單服務器的負荷壓力，大大提高系統的穩(wěn)定性和響應，同時也支持多種終端設備的顯示。物理上我們將分成三層結構：數據服務器群，組件服務器群（程序服務器群），用戶操作終端。組件系統的對象層次與應用模山東大學碩士學位論文 23 塊系統部署無關，醫(yī)院用戶可以是動態(tài)實時的選擇系統部署模式，可以是單機結構、客戶機 /服務器結構和多層結構。 再次， 在醫(yī)院強調投入與產出，收益與分配的改革管理思想指導下，醫(yī)院應該建立 “以病人為中心，以服務為導向，經濟上降低成本，醫(yī)療上控制質量 ”的管理模式 ，醫(yī)院用戶可以充分利用信息平臺所帶來的優(yōu)勢，根據自己的管理目的，按照平臺所倡導的策略建立起應用覆蓋面廣，功能全面，真正意 義上的醫(yī)院門診管理系