【正文】 As String Dim rs_login As New Dim conn As New Provider=。 39。 amp。 39。 amp。 39。 amp。 39。 amp。Initial Catalog=mzglxt。Integrated Security=SSPI。 39。 amp。Initial Catalog=mzglxt。Integrated Security=SSPI。 表 41IPO 表 系統(tǒng)名稱 可可門診管理系統(tǒng) 模塊名稱 驗證用戶身份 模塊編號 作者 日期 模塊簡述 用于對登錄系統(tǒng)的用戶進(jìn)行身份驗證 調(diào)用模塊 被調(diào)模塊 輸入 項目 用戶名 ，密碼 格式 用戶 名 ： 8 位數(shù)的字符串 密碼： 0～ 12 位的字符串 處理 驗證用戶輸 入的用戶 名 和密碼： 獲得登錄用戶輸入的用戶 名 和密碼： 訪問數(shù)據(jù)庫的用戶賬戶表： 查詢匹配的用戶和密碼，若查詢到或 不匹配，返回結(jié)果到登入窗口，提示錯誤，相反登錄成功。 體 設(shè)計 一 . 整個軟件系統(tǒng)結(jié)構(gòu)圖 可 可 門 診 管 理 系 統(tǒng)系 統(tǒng) 設(shè) 置 資 料 查 詢 門 診 收 費密碼修改用戶管理收費項目查詢藥品信息查詢醫(yī)生信息查詢病人信息查詢驗證用戶門 診 掛 號 藥 品 庫 存 查 詢掛號退號修改更新查詢打印 圖 31 系統(tǒng)結(jié)構(gòu)圖 19 模塊 1）模塊 IPO： （輸入 —處理 —輸出）用來 描述分層圖中一個模塊的輸入，輸出和處理內(nèi)容。 故障處理要求 在輸入不符合定義格式的數(shù)據(jù)時，要求軟件應(yīng)能夠出現(xiàn)提示信息，而不是司機(jī)或者是刪除已經(jīng)輸入的信息，然后再彈出重新輸入界面。 17 掛 號 界 面 [ 輸 入 數(shù) 據(jù) ]更 新 數(shù) 據(jù) 庫[ 撤 銷 ]確 認(rèn) 輸 入[ 確 認(rèn) ][ 退 號 ]報 表[ 生 成 報 表 成 功 ] 圖 29 掛號狀態(tài)圖 檢 索[ 輸 入 看 診 序 號 ][ 存 在 ]顯 示 詳 細(xì)[ 不 存 在 ] 請 求 確 認(rèn)記 錄 并 計 算[ 輸 入 收 費 項 目 ]收 費[ 顯 示 總 和 ] 報 表[ 生 成 報 表 成 功 ] 圖 210 收費狀態(tài)圖 對性能的規(guī)定 時間特性的要求 1) 系統(tǒng)的更新處理時間應(yīng)該在可接受的范圍內(nèi)； 2）系統(tǒng)的數(shù)據(jù)查詢、修改時間應(yīng)該在可接受的范圍內(nèi)； 3）系統(tǒng)的數(shù)據(jù)打印時間應(yīng)該在可接受的范圍內(nèi) 靈活性 1）操作方式上應(yīng)該能夠滿足鼠標(biāo)和鍵盤任意切換的需要 2）能夠支持 windows95/98/2021/Me/XP 的運行環(huán)境 18 3）留有與其他系統(tǒng)的接口 對輸入輸出的要求 對“姓名”的輸入要求不超過 4個漢字或者是 8 個英文字符；當(dāng)鍵入編號時可以自動顯示相應(yīng)信息不用再輸入。 登 陸 界 面 驗 證 用 戶數(shù) 據(jù)[ 輸 入 密 碼 ][ 合 法 賬 戶 ][ 增 加 / 刪 除 / 修 改 ][ 不 合 法 賬 戶 ]報 表[ 生 成 報 表 成 功 ] 圖 28 登錄界面狀態(tài)圖 外部實體條目 名稱：病人 總編號： 說明： 編號： 輸入數(shù)據(jù)流： 個數(shù)： 輸出數(shù)據(jù)流： 病人 處理條目 名稱：掛號登記 總編號： 說明：病人來就診時提交病歷登記個人和就診信息。 4）門診收費數(shù)據(jù)流圖 D 2 檢 查 項 目 表P 4繳 費 登 記收 據(jù)處 方 單D 1 掛 號 單掛 號 員 病 人D 2 藥 品 信 息 表D 2 收 據(jù) 圖 27 門診收費 數(shù)據(jù)流圖 病人憑借繳費單到掛號部門進(jìn)行繳費然后根據(jù)是檢查還是配藥進(jìn)行相應(yīng)的操作。查詢用戶用于對用戶相關(guān)信息的查詢。 系統(tǒng)頂層數(shù)據(jù)流圖 D 1 掛 號 單門 診 管 理 系 統(tǒng)病 歷 卡繳 費 單D 2 收 據(jù)病 人掛 號 處人 員掛 號 單收 據(jù) 圖 23 門診管理系統(tǒng)頂層數(shù)據(jù)流圖 門診管理系統(tǒng)又可以分為系統(tǒng)設(shè)置、基本資料查詢、門診掛號和門診收費四個主要的模塊，下面分別介紹這四個模塊的數(shù)據(jù)流圖： 1）通過需求分析，可知系統(tǒng)設(shè)置有用戶修改的功能，可以得到系統(tǒng)設(shè)置的數(shù)據(jù)流圖，如圖24 所示： 13 P 1 . 1驗 證用 戶D 3 賬 戶 數(shù) 據(jù)用 戶 數(shù) 據(jù)P 1 . 2用 戶修 改P 1 . 3查 詢用 戶用 戶數(shù) 據(jù)用 戶 數(shù) 據(jù)用 戶 數(shù) 據(jù)操 作 員 圖 24 系統(tǒng)設(shè)置數(shù)據(jù)流圖 驗證用戶用于對進(jìn)行系統(tǒng)登錄的用戶進(jìn)行合法性身份驗證，從而確定此用戶是否 能夠使用相關(guān)的資源。圖 22 是上述經(jīng)過分析過后的門診就診的流程圖。相關(guān)部門可以通過查詢門診掛號表得到病人的就診信息，可以知道病人的具體的就診科室，也可以查看病人的基本信息（如果之前在此處就診過）了解病人之前的病史。 11 圖 21 門診管理 的大致業(yè)務(wù)流程圖 接下來對圖 21 中的黑匣子（門診系統(tǒng)）的內(nèi)容進(jìn)行分解。然后根 據(jù)醫(yī)生的指示是先檢查對應(yīng)的項目還是直接去配藥，然后根據(jù)要求先去交費，然后去檢查或者直接去藥房拿藥，對于是檢查的病人，檢查完后拿著檢查單再去醫(yī)生那咨詢，根據(jù)檢查結(jié)果醫(yī)生開藥，一般認(rèn)為門診不實施手術(shù)的行為。 數(shù)據(jù)流圖 通過查詢相關(guān)資料以及切身體驗，可以知道在在門診就診的大致過程。 對藥品和收費功能的收費，提供集成的收費方式，統(tǒng)一界面實現(xiàn)兩類收費的操作。 主要是對系統(tǒng)用戶進(jìn)行管理，包括登錄、退出和操作記錄等，其中可以依據(jù)要求可以查詢、添加和刪除用戶，修改密碼等。 對功能的規(guī)定 通過分析得到“門診管理系統(tǒng)”應(yīng)該具備以下主要的功能 : 1 科室信息、病人信息等基本資料的查詢、修改、打印 2 實現(xiàn)門診的掛號、退號的功能 3 實現(xiàn)對收費項目、藥品的收費 4 實現(xiàn)對用戶的修改刪除、密碼的修改等系統(tǒng)設(shè)置 5 對藥品的簡單的管理功能 因此，可以大致的將系統(tǒng)分 為四大主要模塊：基本資料管理、系統(tǒng)設(shè)置、門診掛號和門診收費。對于門診掛號處的人員，因為工作量大以及病人的流動性大，所以要提供盡可能簡單的操作，減少鍵盤的操作實現(xiàn)鼠標(biāo)的使用。盡量采用最簡單的環(huán)境要求和系統(tǒng)要求實現(xiàn)系統(tǒng)的開發(fā)和實施。 設(shè)備 運行本軟 件要求處理器在奔騰三以上，內(nèi)存在 256M 以上的計算機(jī)。 背景 （ 1）本系統(tǒng)的名稱：可可門診管理系統(tǒng) （ 2）本項目的任務(wù)提出者是 **企業(yè)，開發(fā)者是南京工業(yè)大學(xué)管理科學(xué)與工程學(xué)院電子商務(wù)專業(yè)的丁燕艷、曹云龍和張輝同學(xué)。 編寫目的 軟件需求說明書的編制目的是為 了使用戶和軟件的開發(fā)者對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作地基礎(chǔ)。門診劃價收費取藥三合一模塊的主要功能包括錄入處方及檢查治療單、核算病人的費用、完成現(xiàn)金收費并打印發(fā)票、完成取藥等功能。病人必須先到門診掛號，取得掛號單后找醫(yī)生看病，然后拿處方劃價，最后取得藥品或接受治療。 最終方案 可可門診信息系統(tǒng)是基于 VB 語言，數(shù)據(jù)庫利用了 SQL Server 2021作為數(shù)據(jù)源來設(shè)計本系統(tǒng)，在 數(shù)據(jù)連接采用了 ADO連接。因此，推薦方案的依據(jù)有以成本最低為優(yōu)先原則，也有以技術(shù)最新、用戶最方便為優(yōu)先原則的，還有以工期最短為優(yōu)先原則，因此，應(yīng)該根據(jù)用戶的具體情況確定合適的依據(jù)。推薦方案的依據(jù)應(yīng)該來源于用戶的現(xiàn)實需求、技術(shù)現(xiàn)狀、經(jīng)濟(jì)條件、工期以及其他的局限性因素等。 推薦方案 可行性研究的主要內(nèi)容之一是推薦系統(tǒng)開發(fā)的最適合的方案，或者是經(jīng)過排序的方案序列。系統(tǒng)對硬件設(shè)備的要求居中，特別適合在網(wǎng)絡(luò)的環(huán)境下使用，操作方便。 方案 B：以 大型數(shù)據(jù)庫管理系統(tǒng)為后臺數(shù)據(jù)庫，前臺操作與數(shù)據(jù)庫分離，前臺、后臺可以分別進(jìn)行開發(fā)管理， 能夠?qū)崿F(xiàn)多層應(yīng)用系統(tǒng)。系統(tǒng)對硬件設(shè)備的要求低，不需要網(wǎng)絡(luò)支持，在單機(jī)環(huán)境下也能夠運行，在局域網(wǎng)絡(luò)環(huán)境下也可以使用。其特點是：前臺操作與數(shù) 據(jù)庫分離，便于實現(xiàn)多層結(jié)構(gòu)的應(yīng)用系統(tǒng)，操作界面統(tǒng)一，特別適合在網(wǎng)絡(luò)環(huán)境下使用。 開發(fā)方案 B：采用大型數(shù)據(jù)庫管理系統(tǒng) Oracle、 DB或 Sybase 等作為后臺數(shù)庫， 采用 7 Microsoft VB 或 VC，或者 Delphi來開發(fā)前臺的操作部分。最后，不需要保留帳戶的患者到交費窗口清戶。病人到藥房憑條形碼信息確認(rèn)取藥，并自動完成劃賬結(jié)算。需要住院的發(fā)送信息給住院系統(tǒng)并回傳是否有床位信息；不需住院者直接開藥方，系統(tǒng)自動回傳藥品信息，以備因藥房無藥進(jìn)行換藥的需要，同時自動提示劃價金額和帳戶余額，經(jīng)患者同意后發(fā)送給藥房管理系統(tǒng)、門診護(hù)士工作站。一項檢查完成后提示應(yīng)再做哪項檢查，各項檢查完后，病人回候診區(qū)候診。對需要做多項檢查的患者系統(tǒng)根據(jù)各檢查科室排隊人數(shù)，計算最優(yōu)路線，提示應(yīng)先去做哪一項檢查。患者進(jìn)入候診區(qū)候診。首次來就 醫(yī)者提示交費建立預(yù)備金帳戶發(fā)放帶有條形碼的病歷、忘帶病歷和身份證者憑身份證號碼和密碼掛號領(lǐng)取帶有條形碼的病歷。通過利用排隊算法，對就診過程進(jìn)行優(yōu)化，可以減少患者排隊的盲目性，避免因此帶來無謂的時間浪費。 （ 6） 排隊的優(yōu)化算法 需要多項檢查的患者，按優(yōu)化排隊算法提供的信息排隊。（ 3）病人可以了解診斷和治療情況，也便于病人攜帶保存。相對于醫(yī)生完成電子病歷的過程，這種錄入方式有以下優(yōu)點：（ 1）醫(yī)生可以避免錄入信息的煩惱，節(jié)省時間。針對錄入困難，本方案采用電子病歷與傳統(tǒng)病歷相結(jié)合的方法，由醫(yī)生書寫傳統(tǒng)的病歷內(nèi)容（病況、檢查內(nèi)容、藥方、治療方案），書寫內(nèi)容最后由候診護(hù)士利用掃描方法轉(zhuǎn)化為電子病歷的一部分；檢查單、藥方信息的錄入通過模版 完成。 （ 5） 電子病歷與傳統(tǒng)病歷相結(jié)合 無論對于門診醫(yī)生還是患者來說，病歷都是很重要和必需的，因此一些電子病歷最終還是要打印，然后由醫(yī)生簽名確認(rèn)，送給患者保存。 （ 4） 條形碼為識別方式 掛號后產(chǎn)生一條形碼作為候診、預(yù) /補交費，檢查、取藥、治療等的身份識別。帳戶編碼以身份證編號為編碼外加密碼確認(rèn)形式，即使不用條形碼，只要記得身份證號碼和密碼仍然可以使用帳戶，方便易用，又可實現(xiàn)保密的要求。一是可以 長期重復(fù)使用，對于就醫(yī)地點相對固定的患者、需要長期或多次治療的患者十分方便。 （ 3） 建立門診預(yù)交金賬戶 國內(nèi)比較成功的門診模式是建立門診預(yù)交金賬戶和應(yīng)用現(xiàn)金充值 IC 卡?？焖贉?zhǔn)確，這樣不僅可以有效地節(jié)約錄入時間，還可以使身份證具有更多功能?？梢宰鳛殇浫氡４?zhèn)€人信息的先進(jìn)方法。 （ 2） 患者信息采用身份證錄入方式 在現(xiàn)有錄入方式的基礎(chǔ)上，采用身份證錄入方式為主。在龐大復(fù)雜的系統(tǒng)內(nèi)部，應(yīng)該建立貫穿各局部系統(tǒng)的信息主線，每個局部系統(tǒng)都必須按照信息主線的要求與整體建立接口。 5 （ 1） 信息集成的方法與原則 醫(yī)院門診信息系統(tǒng)覆蓋了病人在院期間的各個診斷治療環(huán)節(jié)，各部分之間信息高度共享。這樣會簡化信息錄入，方便掛號交費。給患者帶來不便和產(chǎn)生丟失錢財?shù)奈ｋU，同時醫(yī)院本身也會遇到找零，識別假鈔的問題。 （ 4） 多次交費問題 如目前多數(shù)醫(yī)院就診必須經(jīng)過掛號收費、檢查收費、取藥或治療收費一系列過程，一個患者少則排 3 次隊，多則 6 次，用于排隊過程的時間大多在 1 小時以上，等候時間長、秩序混亂。常規(guī)的診斷問題可以使用模版，但總會有需要文字錄入的部分，漢字錄入的特點又會給醫(yī)生帶來不便，延誤診療時間，成為電子病歷普及的障礙，也成為門診醫(yī)生工作站系統(tǒng)中的一個瓶頸。 （ 3） 電子病歷錄入困難 電子病歷數(shù)據(jù)必須保證病歷信息的完整性、面向完整病案的數(shù)字化。會出現(xiàn)一邊排隊等候，一邊空閑得很，往往一圈檢查下來，等到報告出來一上午都完成不了。不同的檢查所用的時間也不一樣。 （ 2） 排隊程序沒有優(yōu)化 對于就診人數(shù)不多的醫(yī)院，做檢查時可能不需要排隊。 （ 4） 處方確認(rèn)管理 顯示病人已劃價的處方，打印病人擺藥單，并按病人處方實際情況發(fā)藥；處方統(tǒng)計、查詢，按科室和病人統(tǒng)計處方量及處方金額，根據(jù)病人信息以及處方信息查詢處方并打??；藥房出庫統(tǒng)計，分別按照出庫時間、出庫對象統(tǒng)計出庫數(shù)量及出庫金額。自動向有關(guān)部門傳送檢查、檢驗、診斷、處方、治療處置、手術(shù)、收住院等診療信息以及相關(guān)的費用信息，保證醫(yī)囑指令順 利執(zhí)行。打印掛號單，并指明就診科室位置。 （ 1） 多種掛號方式管理 可以任意掛號、限額掛號、預(yù)約掛號、磁卡掛號、 Inter