【文章內容簡介】 掛號管理包含的功能有現(xiàn)場掛號、退號、患者基本信息 維護、日結以及門診掛號相關的查詢，如科室收入匯總查詢、掛號員工作量查詢、掛號情況查詢等等。掛號實現(xiàn)了患者的基本信息錄入，門診掛號等待看診；患者掛號了但是想離開時可進行退號；患者基本信息維護能夠對患者的基本信息進行修改；日結則是對掛號員上次日結到本次日結時間內發(fā)生的掛號進行結賬，繳款。 圖 門診掛號模塊結構圖 門診收費包含的功能有門診收費、門診退費、門診結賬 日結 以及門診收費相關的查詢。門診收費是對藥房劃價對患者產生的處方進行收費；門診退費是當患者已經到藥房進行退藥后進行退費操作；門診結賬則是對收款 員上次結賬日期到本次結賬日期期間發(fā)生的收費進行結賬，繳款。 圖 門診收費模塊結構圖 門診藥房包含的功能有藥品管理、門診劃價 收費 、門診退費、門診配藥、門診發(fā)藥、門診退藥以及藥房內的相關查詢。藥品管理可對藥品信息進行增加或者修改；門診劃價相當于醫(yī)生為患者開處方；門診配藥是配藥員預先給已經收費患者進行配藥，方便患者取藥；門診發(fā)藥是發(fā)藥員把藥品發(fā)到患者手中；門診退藥則是患者已經拿到藥品后，在有效條件下進行退藥的操作。 圖 門診藥房模塊結構圖 3 門診系統(tǒng)概要設計 這部分主要描述了系統(tǒng)功能設計 ，首先講述了本系統(tǒng)的整體結構，系統(tǒng)包括基本信息維護、門診掛號、門診收費、門診藥房四個主要模塊，然后仔細描述了各模塊的數(shù)據(jù)流程，跟蹤各模塊的業(yè)務處理流程，最后描繪了各模塊內主要的實體類之間的聯(lián)系。 系統(tǒng)功能設計 系統(tǒng)功能結構 圖 是本系統(tǒng)的功能結構圖，描述了系統(tǒng)登陸到各個子模塊可進行操作的功能。用戶首先進入系統(tǒng)登錄界面，輸入用戶名、密碼進行身份驗證，再進入模塊選擇，根據(jù)該用戶的模塊權限選擇登錄的模塊，再進行操作，如果該用戶沒有任何一個模塊的登錄權限，則無法進入功能操作界面。 圖 系統(tǒng) 功能結構圖 系統(tǒng)狀態(tài)流程 如下圖是本系統(tǒng)的狀態(tài)流程圖，簡要描繪了系統(tǒng)及模塊間的操作流程。用戶可以登陸不同的子模塊，更改登陸可登陸進入其它模塊。 用戶先輸入用戶名，密碼，進入登陸模塊界面，選擇要登陸的模塊，然后再進行該模塊進行相關操作。系統(tǒng)提供注冊功能，可以在用戶登錄進入系統(tǒng)的情況下，把該用戶注銷，同時用其它的用戶名、密碼登錄。 圖 系統(tǒng)狀態(tài)流程圖 系統(tǒng)數(shù)據(jù)流程設計 掛號模塊數(shù)據(jù)流程 患者首先到患者基本信息登記處索取“患者基本信息登記表”，填寫完整后交給基本信息錄入員錄入電腦，患者帶 著基本信息登記表到掛號處進行掛號，掛號員收取掛號各種費用，同時打印掛號收據(jù)，發(fā)放“初診病歷”，如果患者想退號，患者提交掛號收據(jù)，掛號員判斷是否可以退號（只能退當天的號、已經醫(yī)生看診的不允許退號、預約掛號不允許退號），如果可以退號，則進行退號操作，并把掛號費退給患者。 圖 掛號數(shù)據(jù)流程圖 收費模塊數(shù)據(jù)流程 醫(yī)院門診收費處的主要業(yè)務是門診收費和門診退費，下面介紹了這兩個主要業(yè)務流程的執(zhí)行過程。 1. 門診收費流程 門診收費處可以進行劃價操作，需要進行劃價的，那么進行劃價操作，否則進行收費操 作。門診收費處可以根據(jù)劃價信息進行收費，也可以直接進行收費，門診收費處收費時，確定支付方式（信用卡、支票等），確定分發(fā)票要求，最后打印統(tǒng)一門診收費發(fā)票。 圖 門診收費流程圖 門診退費流程 如果患者收費項目沒有執(zhí)行，那么可以直接退費，否則需要填寫《退費申請單》，并且經過領導審核 ,如果患者的發(fā)票是隔日的，那么一定需要執(zhí)行科室填寫《退費申請單》，退費前需要財務領導進行審核，收費員根據(jù)收費申請單和發(fā)票進行退費 ,如果是交叉退費，也需要財務領導進行審核，才可以退費。如果收費時間很久的發(fā)票退費，軟件不予以處理， 直接到財務科手工退費。 當患者收費項目已經執(zhí)行了再進行退費時，應該先在藥房退還藥品，再到門診收費處退藥品費用。本系統(tǒng)的內部處理是把原來劃價的處方單作廢，再生成一條新的處方，這樣做有利于醫(yī)院統(tǒng)計、管理，也可減少不必要的醫(yī)療糾紛，避免醫(yī)生開錯藥、亂開藥和患者亂退藥的情況。 圖 門診退費流程圖 藥房模塊數(shù)據(jù)流程 1. 門診藥房發(fā)藥流程 門診收費接受患者電子處方或手工處方進行收費；扣除庫存藥品虛庫存。門診藥房系統(tǒng)接受收費信息，自動刷新待取藥患者列表，顯示患者處方信息；患者送方到藥房取藥。配藥人員在配藥 臺模塊內，根據(jù)設置進行配藥標簽或配藥清單補打 如已自動打印則不需補打，提前撿藥 。配藥人員對處方做配藥確認，記錄配藥人員工作量信息。已配藥患者信息發(fā)送發(fā)藥臺，同時大屏幕刷新已配好藥的患者列表?；颊吒鶕?jù)當前大屏幕的待取藥患者信息，排隊取藥。發(fā)藥人員在發(fā)藥模塊內，對患者處方進行確認，扣除庫房實庫存，還虛擬庫存。記錄發(fā)藥人員工作量信息。對于當日未取藥患者，在虛擬庫存管理模塊內，對該處方單獨進行虛擬庫存還庫操作。 圖 門診藥房發(fā)藥流程圖 2. 門診藥房退藥流程 判斷是否已超過允許退費時間，如果已超過則不允 許退費，患者需要得到醫(yī)生開據(jù)藥品退費說明，避免患者無故退藥的情況，然后經過門診藥房負責人簽字確認，此時軟件生成一條退費信息，門診收費根據(jù)病歷號得到該退費信息，然后患者再進行退費。 圖 門診藥房退藥流程圖 系統(tǒng)概念結構設計 該部分描繪了各個模塊的 ER 圖，各實體的一些主要屬性及聯(lián)系。 ER 方法是實體 聯(lián)系方法（ EntityRelationship Approach）的簡稱。它是描述現(xiàn)實世界概念結構模型的有效方法。實體型 Entity 具有相同屬性的實體具有相同的特征和性質，用實體名及其屬性 名集合來抽象和刻畫同類實體 屬性 Attribute ：實體所具有的某一特性，一個實體可由若干個屬性來刻畫。 聯(lián)系 Relationship ：聯(lián)系也稱關系，信息世界中反映實體內部或實體之間的聯(lián)系。實體內部的聯(lián)系通常是指組成實體的各屬性之間的聯(lián)系；實體之間的聯(lián)系通常是指不同實體集之間的聯(lián)系。 圖 基本信息維護 ER 圖 掛號模塊概念結構設計 掛號子模塊中有一些基本數(shù)據(jù)的維護，如掛號級別維護，合同單位維護。掛號級別是患者想掛號的級別，如專家號 +病例、?？铺?、普通號，不同的掛號級別對應的掛號費也不相 同；合同單位是對患者采取的收費標準，如現(xiàn)金、醫(yī)保、市保、退休等等。 圖 掛號 ER 圖中的掛號實體是掛號模塊中的核心結構，記錄了患者的信息、掛號信息等等、是否日結等等。掛號實體的合同號、掛號級別分別與掛號級別實體的掛號級別編號跟合同單位實體的合同編號相關聯(lián)。 收費模塊概念結構設計 如圖 所示，收費子模塊中發(fā)票實體是整個模塊的核心，它關聯(lián)著發(fā)票明細、項目明細、支付方式、費用明細、日結等等許多信息，甚至處方實體中的發(fā)票號也是與發(fā)票實體關聯(lián)著。 發(fā)票實體中維護著發(fā)票號、患者病歷號、金額、是否有效 、是否日結等等非常重要的信息，它門診財務管理、核對的主要管理對象。 發(fā)票明細是一張發(fā)票對應的一些收費信息，費用明細則是門診流程中對收費項目進行動態(tài)跟蹤與管理的實體。 本系統(tǒng)支持多支付方式，可用銀行卡、醫(yī)?？ǖ鹊冗M行刷卡收費。 藥房模塊概念結構設計 圖 中的處方實體是在藥房劃價或者門診劃價時產生，它是醫(yī)生給患者開的一張?zhí)幏?，其中包括處方號、病歷號、處方狀態(tài)、處方金額、配發(fā)藥人等等屬性。 處方明細是一張?zhí)幏街嗅t(yī)生為患者開的藥品明細或者項目明細，像開的哪個藥品、藥品數(shù)量、用法、頻次、每次劑量、處方號、是 否退藥、擺藥人等等信息。 處方與處方明細實體是通過處方號相關聯(lián)的，即一個處方包括多個處方明細，通俗的說，一個患者到醫(yī)院就醫(yī)，醫(yī)生開了一張?zhí)幏絾?，這就相當于一個處方實體，而處方單上的多個項目明細及處方明細。 圖 掛號 ER 圖 圖 收費 ER 圖 圖 藥房 ER 圖 4 門診系統(tǒng)詳細設計 本節(jié)是對醫(yī)院門診管理信息系統(tǒng)的詳細設計，本系統(tǒng)采用三層架構，因此先講述了三層架構的特點，采用三層架構對設計本系統(tǒng)的好處，然后再對系統(tǒng)進行了數(shù)據(jù)和界面上的設計。 項目架構設計 三 層架構說明 本系統(tǒng)采用三層架構：數(shù)據(jù)訪問層 DAL ，邏輯業(yè)務層 BLL ，表示層 UI 。在軟件體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務邏輯層（又或成為領域層）、表示層。三層結構原理： 3 個層次中，系統(tǒng)主要功能和業(yè)務邏輯都在業(yè)務邏輯層進行處理所謂三層體系結構，是在客戶端與數(shù)據(jù)庫之間加入了一個“中間層”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不僅僅有 B/S 應用才是三層體系 結構，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。三層體系的應用程序將業(yè)務規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過 COM/DCOM 通訊與中間層建立連接，再經由中間層與數(shù)據(jù)庫進行交互。表示層位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用戶提供一種交互式操作的界面。 業(yè)務邏輯層（ Business Logic Layer）無疑是系統(tǒng)架構中體現(xiàn)核心價值的部分。它的關注點主要集中在業(yè)務規(guī)則的制定、業(yè)務流程的實現(xiàn)等與業(yè)務需 求有關的系統(tǒng)設計，也即是說它是與系統(tǒng)所應對的領域（ Domain）邏輯有關，很多時候，也將業(yè)務邏輯層稱為領域層。例如 Martin Fowler 在《 Patterns of Enterprise Application Architecture》一書中，將整個架構分為三個主要的層：表示層、領域層和數(shù)據(jù)源層。作為領域驅動設計的先驅 Eric Evans，對業(yè)務邏輯層作了更細致地劃分，細分為應用層與領域層，通過分層進一步將領域邏輯與領域邏輯的解決方案分離。業(yè)務邏輯層在體系架構中的位置很關鍵，它處于數(shù)據(jù)訪問層與表示層中間 ，起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那么這種向下的依賴也應該是一種弱依賴關系。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正因為如此，業(yè)務邏輯層的設計對于一個支持可擴展的架構尤為關鍵，因為它扮演了兩個不同的角色。對于數(shù)據(jù)訪問層而言，它是調用者；對于表示層而言，它卻是被調用者。依賴與被依賴的關 系都糾結在業(yè)務邏輯層上，如何實現(xiàn)依賴關系的解耦，則是除了實現(xiàn)業(yè)務邏輯之外留給設計師的任務。 數(shù)據(jù)訪問層：有時候也稱為是持久層，其功能主要是負責數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是 XML 文檔。簡單的說法就是實現(xiàn)對數(shù)據(jù)表的 Select， Insert， Update， Delete 的操作。如果要加入 ORM 的元素，那么就會包括對象和數(shù)據(jù)表之間的 mapping，以及對象實體的持久化。 開發(fā)人員可以只關注整個結構中的其中某一層； 可以很容易的用新的實現(xiàn)來替換原有層次的實現(xiàn)； 可以降低層與層 之間的依賴； 有利于標準化； 利于各層邏輯的復用。 圖 系統(tǒng)三層架構簡圖 其 中 數(shù) 據(jù) 庫 處 理類 包 括 ， base ， ， 四個類。 Database 類是連接數(shù)據(jù)庫的接口，可根據(jù)不同的數(shù)據(jù)庫進行連接， DataAccess 類提供對數(shù)據(jù)庫進行讀取和保存數(shù)據(jù)的操作。對于系統(tǒng)中的每個實體，都維護了一個實體類，便于讀取和管理，每個子模塊都有一個自己的業(yè)務處理類，處理與它相關的一些業(yè)務。界面層則是面向用戶，提供用戶操作的界面。 界 面設計 界面設計初期，就定義了界面 UI 規(guī)范，無論是控件使用，提示信息措辭，還是顏色、窗口布局風格，遵循統(tǒng)一的標準，做到真正的一致。使用戶使用起來能夠建立起精確的心里模型，使用熟練了一個界面后，切換到另外一個界面能夠很輕松的推測出各種功能，語句也不需要費神理解降低培訓成本，人員不費力逐個指導。給用戶統(tǒng)一感覺，不覺得混亂，心情愉快，支持度增加 BaseForm 窗體，查詢類窗體又統(tǒng)一繼承了 BaseQueryForm 窗體，如此重用性很高，也便于系統(tǒng)后期維護。 圖 BaseQueryForm 界面 數(shù) 據(jù)庫設計 此系統(tǒng)的數(shù)據(jù)庫設計是根據(jù)實際需求，結合本人以往經驗進行設計，雖然有些設計不是十分理想，但是能實現(xiàn)基本功能需求。數(shù)據(jù)表分為四個模塊：基本信息維護、掛號管理、門診收費、門診藥房?；拘畔⒕S護中的表是對一些基本信息的維護，如員工、系統(tǒng)用戶、登陸科室、權限、系統(tǒng)功能模塊等等的維護；掛號管理包含掛號、退號、日結、患者等信息；門診收費主要是進行財務上的收費、核算等，其中需用的表有發(fā)票信息、費用明細、收費方式、日結等表結構；門診藥房主要是跟藥品的發(fā)放關聯(lián)，相關的表有處方主表、處方明細、藥品信息等等。 基本信 息維護表設計 用戶表里主要包括用戶編號、用戶名稱、用戶密碼三個字段，其中用戶編號是主鍵，該表中的用戶能登陸系統(tǒng)，進行系統(tǒng)操作，表結構如表 所示。 表 用戶表 Name Type Nullable Default Comments USER_CODE VARCHAR2 6