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