熱門論文
最新論文
醫院信息管理系統 的設計與實現
發布時間：2023-07-25 09:24
1緒論 1
1.1選題的背景和意義 1
1.1.1選題的背景 1
1.1.2選題的意義 2
1.2主要研究內容 2
1.3框架結構 3
2醫院信息管理系統綜述 5
2.1醫院信息管理系統的構成要素 5
2.2相關理論和技術基礎 6
2.3關于HIS國內外研究現狀 7
2.3.1國內研究現狀 7
2.3.2國外研究現狀 8
3醫院信息管理系統需求分析 10
3.1系統需求分析 10
3.1.1需求分析的過程 10
3.1.2需求分析 10
3.2系統開發及運行環境分析 12
3.3系統目標分析 14
4醫院信息管理系統的設計 16
4.1系統總體架構的設計 16
4.1.1系統設計原則 16
4.2數據庫設計 18
4.2.1數據庫的建立 20
4.2.2數據庫結構的設計 21
4.2.3數據庫視圖的設計 25
4.3系統模塊功能劃分設計 26
4.3.1門診管理模塊的設計 31
4.3.2繳費管理模塊的設計 32
4.3.3住院管理模塊的設計 32
4.3.4藥品管理模塊的設計 33
4.3.5婦幼保健管理系統的設計 34
436綜合查詢系統的設計 35
5醫院信息管理系統的實現 36
5.1門診管理模塊的實現 36
5.1.1掛號分診系統的實現過程 36
5.1.2門診醫生站的實現過程 37
5.2繳費管理模塊的實現 39
5.2.1門診繳費管理模塊的實現過程 39
5.2.2住院繳費管理模塊的實現過程 40
5.2.3自助繳費管理模塊的實現過程 42
5.3住院管理模塊的實現 44
5.3.1病人入出轉管理系統的實現過程 44
5.3.2住院護士站的實現過程 44
5.3.3住院醫生站的實現過程 45
5.4藥品管理模塊的實現 46
5.4.1藥房管理系統的實現過程 46
5.4.2藥庫管理系統的實現過程 48
5.5婦幼保健管理系統的實現 49
5.5.1圍產保建管理模塊的實現過程 49
5.5.2分娩管理模塊的實現過程 50
5.5.3兒童保健管理模塊的實現過程 50
5.6綜合查詢系統的實現 52
6系統測試 53
7結論 56
參考文獻 58
致謝 60
攻讀學位期間發表的學術論文 61
1 緒論
1.1選題的背景和意義
1.1.1 選題的背景
醫院信息管理系統最早是上世紀 70 年代初在國外發展起來的，美國的醫院 率先在預訂和排房的業務a上使用信息管理系統。醫院信息管理系統的開發與利 用發展到鼎盛時期是在上世紀九十年代，國際上知名醫院的醫院信息管理系統 相繼出現。它實現了醫院效益的最大化，同時醫院科學的管理、高品質的服務 對其發展也起到促進作用。
由于醫院信息管理系統已經出現了幾十年的時間，隨著計算機和通信技術 的不斷發展，現有的系統在技術的應用和框架選擇方面與過去相比差別很大。 從具體模式上看，國內外的醫院管理系統經歷了一個由單機系統，到以操作系 統為運行平臺的可視化系統方向發展。在互聯網日益普及的今天，基于數據處 理的醫院信息管理系統越來越多。對于大型醫院而言，通常釆用自主開發或委 托軟件開發商開發的方式來建設信息管理系統，或者選擇直接采購市場上比較 成熟但也比較昂貴的醫院管理系統。然而，對于很多中小型醫院而言，由于資 金、人員等多方面原因，尚沒有完全使用醫院管理類軟件，只能通過手工記錄 的方式來管理信息，從而導致管理效率低、易出錯、存在安全隱患等問題。另 外，目前市場上出現的各類醫院管理軟件基本上都是為綜合型大醫院專門設計 的，許多功能對于中小型醫院無法完全適用。因此，有必要為中小型醫院設 計、開發一套價格低廉、服務完善、功能齊全并能結合醫院具體情況的信息管 理系統。
通過對醫療衛生行業相關文獻資料的研究發現，我國醫院信息化建設處于 高速發展的狀態，其發展的主要目的是為了提高業務效率，創造更好的服務流 程。現代醫院，無論從管理角度，還是從資源角度，都比以往更多地利用信息 獲取競爭優勢。作為知識密集型組織，醫院不僅是設備信息化、管理流程信息 化、環境網絡化，醫院的工作人員更多是運用信息進行工作，并將信息獲取、 處理和加工作為產品來提供服務。醫院信息化不僅能簡化工作程序、降低勞動 強度、提高工作效率，更重要的是信息化能帶來醫療手段的重大變革和服務方 式的徹底改變。
1.1.2選題的意義
當今時代是飛速發展的信息時代。在各行各業中離不開信息處理，利用計 算機能夠進行更有效地和更安全地信息管理。使用計算機進行信息管理與控 制，不僅能提高工作效率，更能提高安全性。尤其對于復雜的信息管理，計算 機能夠充分發揮它的優越性。本文所開發的醫院信息管理系統就是為了能更好 地管理醫院門診、住院、藥品等部門的信息。目前，在中小型醫院有很多部門 信息都是初步開始使用計算機進行處理，甚至有些基層鄉鎮醫院尚未使用計算 機進行信息處理。根據調查得知，許多基層中小型醫院目前對信息管理的主要 方式是基于文本、表格等紙介質的手工處理，龐大的病歷數據信息都是用人工 處理、手抄記錄。人工處理存在著以下問題：第一，數據信息處理工作量大， 人工效率低；第二，數據繁多，容易造成數據丟失，且不易查找；第三，由于 數據處理手工操作，出錯后不易更改。綜上所述，中小型醫院非常缺乏系統、 規范的信息管理手段，因此，建立信息管理系統是非常有必要的。該系統可以 使醫院管理工作規范化、系統化、程序化，避免醫院信息管理的隨意性。
在未實現信息化的中小型醫院，經常會遇到掛號排隊的困難，嚴重的情況 甚至會引起糾紛。同樣，在檢查、繳費、取藥這些環節也存在許多問題。通過 查閱相關的數據發現，在縣級醫院，患者的平均就診流程超過兩個小時，這其 中排隊的時間占據了一半。如果醫院建立了完備的信息管理系統，在各個就診 環節合理安排分診叫號，門診效率就可以大幅提高。
應用醫院信息管理系統對于醫院的決策也可以提供科學的數據支撐。建立 在數據庫之上的醫院信息管理系統可以利用統計分析、數據挖掘等技術匯總分 析醫院積累的數據，從中挖掘出相關的規律，從而支持醫院決策。
綜上所述，醫院信息管理系統是目前中小型醫院所迫切需要的，通過節省 大量時間、提高工作效率，從而提高醫院的收益。隨著我國經濟的發展以及科 學技術水平的提高，相信醫院信息管理系統能夠在我國絕大多數中小型醫院得 到普及。從長遠的眼光來看，醫院信息管理系統的建設是非常有意義的。
1.2 主要研究內容
本文對醫院管理信息系統的設計和實施方案進行了深入的研究，主要的研 究內容如下：
（1）通過分析系統相關技術，研究了基于 B/S 的應用實現模式，并根據醫 院業務管理的要求設計出系統的結構模型。
（2） 在MVC架構的基礎上設計并實現了醫院管理信息系統，主要涉及門診 部門和住院部門這兩大部門的信息管理，重點解決了人工管理醫院方式的缺 陷、病房信息的及時反饋等問題以及系統訪問安全性等難題。
（3） 釆用了瀑布開發模型，詳細分析了醫院信息管理系統的開發背景、研 究現狀、系統需求、系統架構設計、數據庫設計、安全設計，給出了核心功能 模塊的界面實現和代碼實現過程，并對系統做了較為詳細的功能測試和性能測 試，保證了系統的正確性。
（4） 通過模塊化設計方法，對醫院信息管理系統進行模塊化設計，并對各 個模塊的設計方法進行了詳細解析。尤其結合婦幼保健院的國家公共衛生服務 業務，設計了婦幼保健管理系統，利用信息化手段實現了婦幼公共衛生業務的無 紙化和電子信息記錄。
（5） 研究了醫院信息管理系統設計中的關鍵技術，并結合系統的實際情 況，給出了相應的解決方法。
1.3 框架結構
本文首先對醫院信息管理系統的相關研究背景以及意義作出簡要的介紹； 然后，對于醫院信息管理系統的體系結構以及相關的國內外研究現狀以及未來 發展趨勢做出了簡要分析，并對本系統的實用價值進行了概述；最后，對于我 國醫院信息管理系統在多個階段（如：需求分析、設計以及實現等階段）的主要 工作以及未來的發展趨勢都進行了敘述與展望。
第一章是本文的概述部分，對于醫院信息管理系統的研究背景以及意義進 行了闡述，進而描述了本文的主要研究內容以及創新點。
第二章對相關概念進行了簡要介紹，并對醫院信息管理系統的體系結構進 行了詳細分析，另外，對國內外關于HIS的相關研究現狀進行了詳細介紹。
第三章給出了本文的理論以及相關技術基礎，另外，對信息管理系統的運 行模式進行了分析，并對我國醫院信息管理系統的功能需求以及性能要求進行 了詳細論述，從而使得本系統的功能模型逐漸被確定下來。
第四章是本文的主體部分，首先對本系統在整體上進行了設計，為了將系 統的應用功能進行分層，我們采用了 B/S三層結構模式，從而使得系統分為：表 示層、數據訪問層和業務邏輯層這三個部分。我們分別對這三個部分進行了設 計與開發。對于數據庫的設計，本章將進行重點闡述。
第五章是醫院信息管理系統的實現，首先闡述了整個系統的業務流程，然 后對各個子系統的功能實現進行了論述。
第六章是系統的測試過程，我們采用了多種測試方法對系統的功能和響應 進行了詳細測試，并給出了測試的方法和結果。
第七章對本文工作進行了總結與展望，首先對本文各個部分的內容進行了 回顧與總結，然后對本文下一步的工作進行了展望。
2醫院信息管理系統綜述
2.1醫院信息管理系統的構成要素
醫院信息管理系統是指在醫院管理和醫療活動中進行信息管理和聯機操作 的計算機應用系統［1］，英文全稱為Hospital Information Management System，英文 縮寫HIS。對于醫院而言，其服務宗旨應當是為了讓病人能夠享受卓越的醫療服 務，因此，我們在設計醫院信息管理系統時，首先應考慮的因素是患者。通過 查閱相關文獻并結合我國的實際情況，我們發現醫院信息管理系統通常可以劃 分為 22 個相對比較獨立的子系統，其中比較有代表性的子系統包括：醫院收費 管理子系統、醫院門診醫生工作站子系統、醫院住院護士工作站子系統、藥房 藥庫管理查詢子系統等。這22個子系統按照功能模塊種類可以劃分為五個部分， 分別是：臨床診療部分、藥品管理部分、財務管理部分、綜合查詢部分以及對 外接口部分。詳細信息如表 2-1 所示。
表 2-1 醫院信息管理系統
Tab.2-1 Hospital Information Management System
臨床診療部分 門診醫生工作站 住院醫生工作站 住院護士工作站 臨床檢驗系統 病理管理系統 醫學影像系統 手術麻醉系統
藥品管理部分 藥房管理系統
藥庫管理系統 合理用藥分析系統
財務管理部分 門診掛號分診系統 門診收費系統 住院收費系統 物資管理系統 設備管理系統
綜合查詢部分 院長查詢與決策分析系統 信息查詢系統（面向患者） 醫療數據統計分析系統
醫保接口
微信支付寶接口
遠程醫療接口
區域衛生接口
醫院信息管理系統設計的原則是適用性，所以在進行系統設計時應根據中 小型醫院的實際情況有選擇性地開發合適的功能子模塊。在進行系統設計時， 應充分了解醫院的規模體系，考慮醫院投入的財力資金情況，并遵循醫院的實際 業務流程或實際需求等因素來設計各個模塊的功能。
2.2相關理論和技術基礎
(一) B/S結構
B/S結構是隨著Internet技術的興起，對C/S結構的一種變化或者改進。它能 為企事業單位內部交換信息提供服務，同時還具有鏈接 Internet 的功能和防止外 界入侵的安全措施。在這種結構下，用戶工作界面是通過 WWW 瀏覽器來實現 的，極少部分事務邏輯在前端(Browser)實現，主要事務邏輯都在服務器端 (Server)實現，形成了所謂的三層(3-tier)結構。B/S結構對于系統的生命周期包括 開發使用以及維護等階段都有一定的簡化作用。客戶端隨著該模式的出現被大 大簡化了，服務器也集中了核心的系統功能，通過Web Server數據庫進行數據 的交換只需要瀏覽器支持如SQL Server、Oracle、MYSQL這類數據庫即可，由于 數據庫具有強大的數據存儲和管理能力，并且能夠動態地進行數據輸入與輸出， 把數據庫應用于 Intranet 上，不僅可以實現大量信息的網上發布，而且能夠為廣 大用戶提供動態地信息查詢和數據處理服務。
B/S結構出現的主要原因是由于原本的C/S結構存在很多問題，所以人們通 過不斷改進C/S結構，進而提出了 B/S結構。B/S結構有三層模式，從本質上來 說， B/S 結構是屬于 C/S 結構的，這是因為 B/S 結構就是在原本傳統的二層 C/S 結構上發展變成三層架構并在Web上應用。B/S結構最大的優勢在于由于利用了 日漸成熟的 Web 瀏覽器技術，并且借鑒很多先進的腳本語言以及技術，比如 ActiveX 技術。原本必須要借助專用軟件才能夠實現的功能，在 B/S 結構下只需 要通過瀏覽器就可以實現，開發的成本大大降低。
B/S 結構的操作不需要安裝軟件客戶端，系統的拓展也更加容易。隨著越來 越多的人使用B/S結構，需求的擴大在一定程度上推動了 AJAX技術的發展。在 客戶端電腦上也可以處理程序，一方面可以降低服務器的負擔，另一方面也增 加了系統的交互性，實現了數據的實時刷新［2］。
（二）SQL Server
作為微軟公司所開發的一種關系型數據庫管理系統，SQL Server具有很多優 點，在大型的多處理器平臺中得到了廣泛的應用。SQL Server數據庫集成度高、 伸縮性較好。應用 SQL Server 開發醫院信息管理系統，可以保證系統日常管理 數據存儲的安全性和可靠性。同時由于該數據庫集成了商業智能分析工具，加之 其關系型和結構化的數據存儲模式，從而保證了使用其構建高性能應用程序的 可行性［3］。
本系統應用SQL Server的一個重要原因是由于該數據庫系統集成了 Web服 務。使用SQL Server2008可以使軟件開發人員能夠在數據庫層面上開發Web服 務，此時的 SQL Server 就作為一種超文本傳輸的協議，這樣基于該服務之下的 醫院信息管理系統就可以擁有讀取以及存儲數據的功能。另外，在該軟件之 下，服務器編碼功能也得到了增強，其靈活性比較高，相關查詢也更加迅速和 精準［4］。
本系統的開發以及運行除了運用上述技術之外，還包括了三層體系結構， MVC架構以及C#語言和數據庫語言等。
2.3關于HIS國內外研究現狀
2.3.1 國內研究現狀
國內關于醫院信息管理系統的研究及開發開始于上世紀八十年代。隨著規 模逐漸地增大，由原本的小型機逐漸擴展為微型機，操作系統沒有發生太大的 變化，都是以 DOS 系統為主。采用的數據庫有所不同，當時采用的是 dBASE， 該數據庫所使用的編程語言是過程化語言，如 PASCAL、 BASIC 等。 80 年代后 期是我國醫療信息管理系統發展速度比較快的時期，隨著第一屆全國醫院管理 計算機應用學術會議于 1988年11月份召開，醫院各個信息子系統的開發應用廣 泛地發展起來，網絡也逐漸地向西方國家學習，采用 TCP/IP 協議，數據庫也越 來越先進和多樣化。使用的數據庫有：Oracle、SQL Server以及Informix等。服 務器系統主要采用UNIX或NT, —般使用Delphi、VB以及PowerBuilder等作為 系統開發工具［5］。
我國的醫院信息管理系統總體上經歷了三個階段，分別是：單項的業務應 用、部分與方面級別的應用以及比較完整的醫院信息管理系統。目前，我國中 小型醫院信息化管理水平所處的階段是第二階段，雖然部分中小型醫院已經有 不少事務應用信息化系統，但是醫院整體業務和行政管理并未完全應用信息 化，更沒能實現全院信息化建設。所以對于當前中小型醫院的現代化建設來 說，十分重要的任務就是開發與應用醫院信息管理系統 ［6］。
從上世紀 70 年代末開始，國內醫院開始實施信息化建設，其中以南京軍區 醫院用 DJS-313 小型機開發的醫院信息系統軟件作為我國建設醫院信息系統的開 端。 80 年代后期開始研究和開發醫院信息管理系統，并自 90 年代起在國內為數 不多的醫院探索使用。 20 世紀 90 年代初期國內關于醫院綜合信息系統的研究項 目正式起步， 1993年國家撥款100萬元下達國家“八五”重點攻關課題，即醫院 信息系統。在經過不斷的創新與發展后取得了較多成就，同時隨著各類突發公 共衛生事件的不斷增多，醫院信息化建設已經成為了醫院改革發展的重要方 向。現階段國內大部分三級醫院的醫院信息管理系統已經形成較為完善的體系 模式。國內很多規模較大和實力較強的機構開始尋求醫療工作信息化，開始在 某些地區實施信息共享，當前醫院信息化發展的重要領域主要集中在患者檔 案、醫療和移動醫療等概念上，這也是今后發展的趨勢。但是由于醫療行業發 展具有專業性強且復雜的特點，不同醫院對于醫療的需求矛盾不同，醫療信息 化在不斷進步的同時也面臨很多的困難。
2.3.2 國外研究現狀
國外醫院信息化起步于上世紀60年代，發展于 80年代，成熟于 90年代， 目前正在向縱深領域擴展。美國 HIS 軟件從病房護理系統入手，逐漸擴展到財務 收費系統、輔助檢查系統、行政事務處理系統， 90 年代電子病歷系統已經成 熟。上世紀六十年代初，享譽全世界的麻省理工學院總醫院在 COSTAR 醫院系 統的研發上投入了大量的金錢和精力，發展到現在為止，在美國眾多的管理系 統之中已經是杰出代表之一。隨著七十年代科學技術的發展，尤其是計算機技 術快速發展，計算機網絡的運用也越來越廣泛，不僅局限于之前的軍方和實驗 室，同時在各個機構以及醫院中都有了廣泛的應用。西方不少國家在醫院信息 管理系統的研發上投入了大量的資金，引進專業人才，對醫院信息管理系統進 行改進和創新［7］。
20 世紀六十年代開始研發醫院信息管理系統到如今已經有五十多年了。在 全球HIS產品中，美國的實力是十分超前的。調查數據顯示，美國超過90%的醫 院使用醫院信息管理系統進行業務操作和日常管理。美國醫療衛生信息與管理 系統協會（HIMSS）是美國醫學信息學界一個重要的學術組織。從1998年開始， HIMSS 每年進行一次美國醫療機構 IT 技術應用情況的問卷調查。調查結果顯 示，以前，美國醫院的應用系統主要靠醫院自主開發，尤其是大型醫院，美國 醫院的IT技術人員通常會達到幾十個。隨著HIS產業化發展，越來越多的醫院 采取購買市場成熟產品。近年來，循證醫學、臨床診療指導(Clinical Guideline)＞臨床路徑(Clinical Pathway)等臨床診療決策技術實現了重大進展，用 藥咨詢系統發展成為臨床醫師的重要工具。Medline(美國國家醫學圖書館建設的 醫學文獻檢索系統)已成為全球醫務工作者的基本工具。
日本從20世紀60年代開始對醫院信息管理系統進行研究。 70年代日本部分 中大型醫院開始廣泛使用HIS產品，在一些小型醫院也開始推廣使用HIS產品。 日本HIS系統的發展得益于日本所推行的E-Japan以及U-Japan等政策［8-10］。
3醫院信息管理系統需求分析
3.1系統需求分析
3.1.1需求分析的過程
軟件開發過程中，需求分析過程是開發能否成功的前提和基礎。需求分析 的成功與否取決于研發人員和用戶兩者之間能否配合密切。對于研發人員來 說，最先需要做的事情是對軟件的功能以及性能進行描述，繼而用邏輯模型展 現出來，形成需求說明書，并請用戶和管理者對需求進行評審。需求分析的過程 需要對軟件進行仔細的調查研究，對相關用戶的需求明確把握，在收集到的數 據基礎上進行分析，即對軟件系統的開發目標進行確定。需求分析過程一般分 為四個階段：問題的識別、分析與模型的導出、需求文檔的編寫、需求分析的 評審［11］。具體過程為：
( 1 )問題的識別
①功能的需求：確定軟件所實現的功能。
②性能的需求：確定軟件的各項性能指標。
③環境的需求：確定軟件在開發和運行的過程中軟硬件的需要。
④用戶界面的需求：確定軟件的用戶使用界面的形式。
( 2 )分析與模型的導出
通過對收集到的信息進行整理分析，確定需求信息所呈現的數據結構，從 而對軟件的功能進行細化，找出軟件各個元素之間的聯系，形成系統解決方 案，最終建立系統邏輯模型。
( 3 )需求文檔的編寫
在研發軟件過程中，為了將用戶需求能夠表述的更加清晰，減少失誤，對 軟件的需求規格進行詳細的介紹，形成需求說明書，編制需求文檔。
( 4 )需求分析的評審
該階段是軟件需求分析工作的最后一個階段，軟件研發人員和項目管理人 員以及用戶對上述三個階段進行評審并根據具體的情況作出評價。
3.1.2需求分析
通過對多家中小型醫院，特別是婦幼保健院進行調查，了解他們的信息管 理系統的使用情況，并進行細致的調研，進而通過數據的收集與分析，發現大 多數醫院的信息管理系統都是在考慮自身實際情況并結合自身實際業務流程的 前提下來設計與開發的。因此，各個醫院信息管理系統的模塊設計是不一樣
的。例如，有的醫院其信息管理系統之中包含了床位管理模塊，但是有的醫院
并沒有將該模塊劃分入系統之中，再比如有的醫院將門診收費模塊和信息系統
兩者之間完全分開，但是有的醫院又將其放置一起。通過對濰坊市的一家婦幼
保健醫院的信息管理系統進行詳細的分析之后，將各個方面的因素進行綜合考
慮，并且結合之前所編寫的需求分析文檔，從而對軟件目標系統劃分為如下幾
個功能部分， 如表 3-1 所示。
表 3-1 系統需求功能分析
Tab.3-1 System Requirement Function Analysis
系統功能 功能模塊 模塊介紹
掛號門診 該模塊支持現金掛號或刷卡掛號，對于病患的相關信息進行
記錄
門診的管理 醫生門診 對于患者的病情進行診斷，根據具體的情況開出藥方
病房門診 對于患者的病情進行診斷，根據具體的情況開出藥方
收費定價 對于患者所花費用進行收費
提請增補藥品 當醫院的藥品數量不足時，提請劃撥藥品
藥房的管理 藥房發藥 向已繳費患者發放藥品
藥房撥藥 對用藥科室提出的增補藥品申請進行查明之后撥出藥品
庫存結算 藥房庫存藥品數量定時結算與管理
批復提藥 對藥房管理模塊中的提請藥品進行批復
藥庫的管理 藥物入庫 醫院新購入藥品入庫
藥物出庫 藥庫藥品劃撥出庫并進行信息記錄
藥庫庫存 藥庫庫存藥品數量定時結算與管理
門診收費記錄 對門診收費信息進行統計、管理以及查詢
綜合的查詢 藥庫出入記錄 對藥品出入藥庫的信息進行記錄和查詢
藥房出入記錄 對藥品出入藥房的信息進行記錄和查詢
藥品管理 對于醫院藥品信息進行管理和維護
系統的管理 項目管理 對于科室所負責的項目進行管理
科室的設置 對于醫院科室信息進行設置和維護
醫生信息設置 對于院內醫生信息進行管理和維護
患者類別管理 系統參數設置 操作員管理 出入庫設置 出入房設置 對于患者類別信息進行記錄與管理 對于系統的參數進行設置和管理 對于系統操作員信息進行管理和維護 對于藥品出入藥庫方式進行設置和維護 對于藥品出入藥房方式進行設置和維護
繳費退費管理 對于患者選擇刷卡消費給予支持，并且可以執行退費操作
婦幼保健管
理 圍產保健管理
分娩管理 兒童保健管理 對圍產期婦女的信息進行管理 對分娩期間產婦和新生兒信息進行管理 對 0-6 歲兒童信息進行管理
修改登錄密碼 用戶能夠修改登錄密碼
對于一家現代化的婦幼保健醫院來說，其服務是為了滿足社會上更多的人 對于高質量的醫療衛生服務的需求，尤其是婦女兒童這個群體對于醫療和保健 服務的需求。在這樣的背景下，醫院要想能夠為患者提供優質、高效的服務， 只追求先進的醫療設施和優秀的醫務人員是不夠的，還需要一個好的醫院信息 管理系統發揮輔助作用，這樣才能更好的讓醫院服務于患者。由上表可以看 出，一個適合中小型醫院特別是婦幼醫院的信息管理系統應包括上述八個模 塊。本文將上述八個模塊進行改進分類，將某些有重合的模塊進行合并，從而 變成主要的六大模塊。
這六大模塊分別是門診管理系統、住院管理系統、藥品管理系統、收費管 理系統、婦幼保健管理系統以及綜合查詢系統，這六個模塊彼此之間是相互獨 立的，但數據是互聯互通的。
3.2系統開發及運行環境分析
通過對軟件需求文檔進行細致的分析，確定了系統的架構模型，主要有以 下四個部分：用戶交互界面、Windows窗體、軟件底層環境以及底層數據庫。 由于系統架構的獨立性要求，其中每一部分的開發采用不同的軟件工具進行。 系統開發所需要的環境配置如下：
軟件操作系統： Windows10/8/7/XP 均可
軟件開發以及軟件運行環境： Microsoft.NET Framework 3.5
軟件開發工具： Microsoft Visual Studio 2010
數據庫的開發工具： Microsoft SQL Server 2008
軟件開發工具使用Visual Studio，主要是由于動態鏈接庫文件在界面層的文 件夾之中，該工具會自動生成一系列控件，開發用戶界面能夠更加簡潔美觀。 本系統中會與提供自助刷卡服務的第三方軟件進行對接，C#語言在執行過程之 中不能對C++進行直接調用，而是要借助于.NET所提供的操作服務對動態數據 庫進行封裝后進行調用，綜合考慮多方面的因素后通過使用AIO、APL、DLL文 件，在完成封裝后，將其轉化為可以直接進行調用的編程語言［12］。
系統上線后要求醫院對信息機房進行改造建設，實現硬件與網絡的配置要 求，為保障醫院信息管理系統的運行，醫院的服務器配置需要滿足于以下幾個要 求，即處理器2.0GHz以上頻率，內存需要大于16G,硬盤的容量需要大于 500G,如果條件能夠允許的情況下，安裝兩個服務器是更優選擇，可做雙機熱 備，保證服務器的穩定性。服務器需要配置數據處理系統或操作系統，數據處 理系統可以選擇SQL Server 2008或者IIS （也就是所謂的Internet Information Service），操作系統可以選擇 WINDOWS server 2008。
機房建設作為系統上線的基礎，另外由于該系統的應用涉及醫院各個科室， 在中小型醫院調研時發現在許多醫院使用的計算機配置較低而且使用年限較 長，所以在本系統設計之初就考慮到硬件配置要求等多方面的因素，對系統進 行簡潔以及優化，盡可能降低硬件配置要求，使該系統運行對硬件的最低配置 要求為：
CPU要求主頻1.4GHZ或是以上
2G DDR 內存
80G 硬盤空間
聲卡以及顯卡主板集成
上述就是該系統對軟硬件配置的需求分析，本系統對配置的要求并不高， 而大多數醫院都有中等配置級別的電腦以及系統，本系統可以流暢運行。除了上 述對于軟硬件的配置需求，對網絡配置也有一定的需求，網絡不穩定會對系統 的運行造成影響 ［14］。
由于系統的運行涉及多個部門，所以醫院信息管理系統在正式開始運行之 前會有專業的軟件實施工作人員進行系統運行的相應準備工作，并且協調各個 部門之間的配合，以保證系統的業務流程正常運作，此外在系統上線之后，專業 人員還需要對各個部門的主要負責人培訓，軟件實施人員會收集醫院的所有基礎 信息，對其進行標準化打包和數據處理，在系統上線之后根據實際情況還需對 信息數據進行補充。
3.3 系統目標分析
建設完善科學的醫院信息管理系統，需要對信息以及計算機理論進行細致的 分析，對具體的管理信息進行深入研究，從而在具體的實踐探索過程中找到有 效的信息處理的方法，根據具體的情況以及科學的理論來制定出一系列的計劃。 這表明了醫院信息管理系統主要有兩方面的功能，即：醫院日常管理以及決策 分析支持。
在中小型醫院業務尚未實現科學化和智能化，所以建立一套醫院信息管理系 統有助于提升服務質量和業務水平。門診部分致力于打造面向患者的優質服務。 患者到醫院就診時多數會面臨的一個問題就是排隊等待時間過長，長時間的等待 會降低醫院的門診效率，同時也降低患者的滿意度。通過微信和支付寶的支付方 式、自助機一卡通的就醫模式等讓患者實現自主就醫。此外院內系統在門診設 自助繳費、分診叫號、自助報告打印、門診醫生站等構建完整的門診就診環， 簡化患者就診步驟，提高患者滿意度，構建以病人為中心的醫院信息化管理體 系。
在住院業務部分，著重改善患者的就診體驗，并輔助提高治療水平和服務質 量。建立完善的患者健康檔案，合并患者的歷史就診記錄，以此做到可以保證來 院患者的多周期健康監測。醫生可以根據健康檔案給出科學的治療方案，患者住 院期間可以獲得全方位的監測，從體征監測、風險評估、治療監測、護理監 測、宣教查詢等方面讓患者無后顧之憂。利用隨訪機制，建立客服中心，為出院 患者提供健康咨詢。通過信息化的方式解決醫院存在的三短一長問題，縮短病人 等待時間，提高患者滿意度，做到以病人為中心開展醫療護理工作。
中小型醫院在發展過程中，其經濟核算和財務業務也愈加復雜。醫院的經濟 運營管理，需要以會計為核心、預算為主線、物流和成本為基礎、績效薪酬為杠 桿的醫院運營管理目標決策理論與方法，實現醫院運營管理中“物流、資金 流、業務流”的統一，全面提升醫院運營管理效率。這就要求引入醫院資源規 劃(Hospital Resource Planning， HRP)的思路，實現財務、物流和業務信息的一 體化，人力資源管理的集成化和動態化，為全院綜合績效管理提供更加全面的 數據支持。
本系統的應用幫助中小型醫院建立基于數據庫的決策分析支持應用體系。 該體系的建立可實現以管理對象為主線，集成整合分散在醫院不同模塊中的各 類數據，通過數據分析，借助專業的數據分析工具對近年的數據進行分析，總 結數據分析報告，以大數據的方式幫助醫院進行戰略決策。為醫院領導決策提供 支持，提升醫院的管理和決策水平。
實現醫院數據互聯互通的目標，多數中小型醫院應用的業務模塊間信息的 交換往往是采用點對點的方式來實現，這種方式使得模塊間的關系線形成網狀 結構，而實際上不同模塊間很多交互信息是可復用的，本系統的數據結構設計 充分考慮到信息的交互這個需要，有效的降低接口數量及復雜度。
綜上所述，我們可以看出對于醫院來說，采用醫院信息管理系統的目的就 是為了使醫院日常的管理以及工作更加的規范化、標準化，解決管理混亂、工 作內容復雜等問題，節約時間，提高效率。通過標準化的存儲使得醫院的各個 部門之間的信息能夠整理結合在一起，對信息數據進行分析更加便捷有效，并 且降低通訊過程的用時，保證信息傳遞的完整性與準確性，醫院可以借助準確 的數據分析結果進行輔助決策，提高決策正確率 [13]。
4醫院信息管理系統的設計
4.1系統總體架構的設計
醫院信息管理系統的設計總體要求比較嚴格，所以要求在實際操作之中， 對使用該系統的用戶需求情況進行及時的了解，另外該信息管理系統在中小型 醫院的實際操作情況也需要正確獲知，在遵守原則的基礎上，為了更好地滿足 需求對系統進行設計。
該系統所采取的結構模式為 B/S 三層結構，系統的應用功能劃分為三個部 分，分別是數據訪問層、表示層以及業務邏輯層。程序可以以不同的形式展現 出來，數據訪問層指的是通過與數據庫的交互繼而對于數據文件進行操作從而 進行相關查詢、更改或者刪除等操作。表示層主要是對用戶的請求進行接受， 并且將相關數據顯示出來，這樣客戶端就能夠進行相應的操作。軟件系統的核 心部分是業務邏輯層，該層與表示層所不同的是該層負責對數據文件進行操作 以及邏輯處理。各個層次在邏輯上的獨立性通過B/S三層模式實現，各層次間的 獨立性確保其依賴性較低，從而軟件后期的維護以及開發就會更加簡易方便， 下面將會使用該模式對于系統進行層次劃分 ［15］。
數據訪問層又稱 DAL 層，其功能主要是負責數據庫的訪問。是實現對數據 表的Select （查詢）‘Insert （插入），Update （更新），Delete （刪除）等操作。 通過 SQL 語句使業務邏輯層進行數據調用，即作為業務邏輯層中各個方法的具 體實現。
表示層使用 WEB 方式，是設計本系統需要建立的核心功能，負責系統各個 功能的操作界面的內容。表現層的定義和更改是基于邏輯層提供服務。對數據 的操作訪問和對數據庫的執行操作都是間接地通過調用業務邏輯層來進行的。
業務邏輯層主要是針對具體的問題的操作，也可以理解成對數據層的操 作，對數據業務邏輯處理。所有的操作都是面向于對象的，由于 DAL 項目之中 包含著相應SQL語句，因而該層不包含SQL語句的實現，在業務邏輯層之中， 所有的操作同時也都是對 Net Lab.Model 中的相關對象操作，可以進行查詢、修 改、刪除或是其他等等操作［16］。
4.1.1系統設計原則
由于系統設計的嚴苛性要求，系統的設計需要遵循相應原則，在此基礎上 對于系統進行設計，才能滿足大多數用戶的具體需求，主要設計原則如下：
（1）學習使用高新技術
因為高新技術的涌現，對系統設計提供了許多便利，系統軟件研發人員使 用更加先進的技術，系統的性能得以延伸，使系統不僅更加簡潔，容易操作， 還具有美觀性和實用性，對用戶來說操作與學習也更加簡單。學習高新技術包 括學習在醫院信息管理系統的開發方面比較先進的體系結構和開發方式，借鑒其 他行業管理系統開發所用的科學的合理的管理辦法。
（2）規范化、標準化系統內部連接 該原則能有效降低系統的開發成本，以最低的成本來開發最高效的系統， 提高信息資源的利用效率，將系統內部連接及系統與外部接口進行標準化的設 計，能提高信息傳遞效率，實現信息共享，系統設計是有方向性的，為了使醫 院各項工作能夠通過信息管理系統有條不紊地進行，具有立體感，業務流程的 執行更加快速有效，需要完善的系統設計。
首先將整體系統進行細化，細分為各個模塊，劃分模塊后，確定所有模塊 的功能，找出各個模塊之間聯系性以及關系，特別是信息在各個模塊之間傳遞 的方式，最后確定各個模塊與系統之間的關系［17-19］。
判斷一個系統的性能好壞，是否能夠實現設計之初所立的目標，取決于系 統是否具有良好的設計，所以在系統的研發過程之中，總體設計是十分重要的 環節之一，系統的各個模塊設計決定了系統總體設計的結果以及影響力，所以 從整體上來說，系統的設計不僅需要單一的模塊布局，還需要從整體上達到完 整性和關聯度的要求，本文中的系統的功能如圖 4-1 所示：
圖 4-1 醫院信息管理系統功能圖
Fig.4-1 Hospital Information Management System Functional Diagram
通過對多家中小型醫院實際情況的了解，本文對醫院信息管理系統中所存 在的重點問題進行了分析和研究：當醫院藥庫中庫存藥品數量非常少時，負責采 購的部門就會根據所收集到的相關數據信息統計出需要采購的藥品數量，從而 制定藥品采購計劃。一般來說，醫院在進行藥品采購時，負責部門為了使采購 計劃能夠高效進行，通常會在多個供應商之中選擇，分別在不同供應商所提供 的不同藥品報價之間進行比較，從而進行篩選，最終藥品的采購會在眾多的供 應商之中選擇。信息管理系統在確定醫院相關藥品的貨源方面發揮著重要的作 用 [20-22]。醫院的報表管理經常會有各種新的數據要求提出，如果系統數據庫設計 太過復雜，關系不夠清晰就會造成醫院在設計新的報表時難以關聯到相應的數 據，所以系統設計應當充分考慮到這方面的需求，在設計關系型數據庫時明確各 個表之間的聯系，設計好數據庫視圖。
在醫院信息管理系統中各個模塊之間彼此是密切相連，不可分割的，醫院 的信息管理系統正是由于門診管理、藥品管理、住院管理以及收費管理和綜合 查詢等各個模塊之間的互相合作才得以正常運轉，所以說各個模塊缺一不可， 醫院信息管理系統的各個模塊之間聯系程度比較高，盡管各個模塊之間具有高 度獨立性，但是縱觀整體而言，一套完整的操作流程下來，每個模塊之間都關 系緊密[23]。
4.2 數據庫設計
醫院信息系統的設計重點之一即數據庫的設計，由于醫院大量的信息數據 是儲存在數據庫中的，數據庫中儲存的數據對醫院的有效管理以及正常運行發 揮著尤為重要的作用，另一方面數據庫的優化設計能使查詢數據信息更為快速 便捷，醫院的工作效率隨之得到提升，通過對于濰坊市的一所婦幼保健院的數 據文件進行分析，對醫院相關的業務和字典信息進行整理，主要包括科室信 息、醫生信息、患者信息以及藥品信息，在實際情況中這些內容是實體的關 系，所以我們選擇建立關系數據庫，對于醫院管理信息系統建立了 E-R模型，對 于數據庫的關系模式進行一定的轉化，數據庫平臺選擇采用微軟的 SQL Server [24]
O
數據庫概念結構用于信息世界的建模，具有較強的語義表達能力，而且簡單、 清晰易于用戶理解，根據數據庫概念結構的這些特點。在概念設計這一階段利用 E-R圖的方式對于各個實體信息進行具體描述。
其中比較具有代表性的如與掛號流程有關的患者信息E-R圖如圖4-2所示。
圖 4-2 掛號 E-R 圖
Fig.4-2 Registration E-R Chart
門診醫生信息E-R圖如圖4-3所示。
圖 4-3 門診醫生 E-R 圖
Fig.4-3 Clinic Doctor E-R Chart
藥品信息E-R圖如圖4-4所示。
圖 4-4 藥品信息 E-R 圖
Fig.4-4 Drug Information E-R Chart 本數據庫系統設計的表分為多個部分，其中比較具有代表性的數據表如表4-1 所示。
表 4-1 數據表名及用途
Tab.4-1 Table Name And Use
分類 數據表名 數據表的用途
ZD-YW 藥物字典，對于相關藥物信息進行存儲-
ZD-HZ 患者字典，對于患者相關信息進行存儲
ZD-JX 劑型字典，對于藥物劑型的相關信息進行存儲
包裝字典，對于藥物包裝的相關信息進行存儲
收費字典，對于相關收費項目的信息進行存儲
科室字典，對于相關科室的基本的信息進行存儲
項目字典，對于相關項目的基本的信息進行存儲
醫師字典，對于醫師的基本信息進行存儲
出入庫字典，對于藥品出入藥庫的信息進行存儲
出入房字典，對于藥品出入藥房的信息進行存儲
CZYQX 操作員權限字典，對于操作員的使用權限進行存儲
XTCS 系統參數，對于該系統的基本信息進行存儲
GHXX 掛號信息，對于掛號信息進行存儲
處方信息，對于患者就診的相關信息進行存儲
處方藥物，對于醫生所開出的藥物信息進行存儲
劃價收費，對于藥物及治療項目收費信息進行存儲
匯總收費，對于收費信息類別匯總進行存儲
YFRYK 藥房返回藥庫，藥房返回藥庫的藥品信息進行存儲
藥庫出入流，對于藥品出入藥庫的信息進行存儲
藥品出入存儲，對于藥品出入藥房信息進行存儲
RYTQ 入藥提請，對于藥房向藥庫申請藥品信息進行存儲
YFKC 藥房庫存，對于藥品在藥房中的庫存信息進行存儲
YKKC 藥庫庫存，對于藥庫中藥品的庫存信息進行存儲
YKCR 藥庫出入流，對于藥物出入藥庫的信息進行儲存
YKCRCC 藥庫出入儲存，藥品出入藥庫的臨時信息進行儲存
4.2.1 數據庫的建立
本文的數據庫開發工具采用Microsoft SQL Server 2008，為了使得其記載儲 存的數據更加準確，根據不同的數據種類設計了獨立的數據表，為了提高醫院 信息管理系統的處理運行的速度，所以將數據庫連接代碼放入項目中 Hospital 目錄下的bin文件夾中，文件名為property.config，為了使相關數據更為簡潔， 在系統中一個主表附有多個子表，各個數據表之間遵循了主表以及從表的關 系，提升數據庫的運行效率，減少在服務器資源上的投入，在運行過程中相關 項目在加載的時候自動地與數據庫建立連接，并不需要系統開發人員對于數據 庫代碼進行重新編寫，大幅度提升系統的開發效率，并且后期階段系統的維護 也會更加方便［25］。
醫院信息管理系統中業務操作需要與數據庫建立連接，連接代碼如下所 示：
Data Source=.;Initial Catalog=hospital;Persist Security Info=True;User ID=sa;Password= etoak
由于“Data Source”的別名是“Server”、“Address”、所以其中“Data Source=;” 指的是使用本地數據庫，如果用本地數據庫對于實例名進行定義，可以將上述 代碼變為“Data Source=（local）\實例名”，如果是于服務器數據庫建立連接，那么 可以將上述代碼的"local”換為服務器名稱或者是IP地址，上述代碼中“Initial Catalog=hospital;”含義指的就是使用的數據源是“hospital”數據庫，在這其中由 于 “Initial Catalog” 別名為“Database”。“Persist Security Info=True;”表示數 據庫連接成功后是否保存密碼信息，“True”是默認保存，如果是“False”表示不保 存。“User ID=sa;Password=etoak;”指的是連接數據庫的驗證用戶名和密碼。
4.2.2 數據庫結構的設計
本系統的數據庫包含的內容十分豐富，不僅包含了醫生、患者以及藥品費 用情況，而且還包括一些如財務的支出以及相關的醫療設備的維護信息等。數 據庫的設計有六個階段，分別是：需求分析、概念設計、邏輯設計、物理設 計、驗證設計以及數據庫的運行與維護［26］。
（1）需求分析
調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范 圍、數量以及它們在業務活動中交流的情況，確定用戶對數據庫系統的使用要 求和各種約束條件等，形成用戶需求規約。
（2）概念設計
根據用戶描述的現實世界，通過對其中諸處的分類、聚集和概括，建立抽 象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流 動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求 等。所建立的模型應避開數據庫在計算機上的具體實現細節，用一種抽象的形
式表示出來。以擴充的實體一（E-R模型）聯系模型方法為例，第一步先明確現 實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件 等，從而給出各部門內所用信息的局部描述。第二步再將前面得到的多個用戶 的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。
（3）邏輯設計
主要工作是將現實世界的概念數據模型設計成數據庫的一種邏輯模式，即 適應于某種特定數據庫管理系統所支持的邏輯數據模式。與此同時，可能還需 為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂 “邏輯數據庫”。
（4） 物理設計
根據特定數據庫管理系統所提供的多種存儲結構和存取方法等依賴于具體 計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結 構（包括文件類型、索引結構和數據的存放次序與位邏輯等）、存取方法和存取路 徑等。這一步設計的結果就是所謂“物理數據庫”。
（5） 驗證設計
在上述設計的基礎上，收集數據并具體建立一個數據庫，運行一些典型的 應用任務來驗證數據庫設計的正確性和合理性。一般，一個大型數據庫的設計 過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回 到前面去進行修改。因此，在做上述數據庫設計時就應考慮到今后修改設計的 可能性和方便性。
（6）運行與維護設計
在數據庫系統正式投入運行的過程中，必須不斷地對其進行調整與修改。
在本小節中選擇有代表性的數據表的設計展示出來，病人信息表是醫院信 息檔案的基礎，具體設計如表 4-2 所示。
表 4-2 病人信息表
Tab.4-2 Patient Information Table
Int 序號
varchar 科室號
Datetime 入院的日期
varchar(20) 住院的號碼
varchar(20) 患者
varchar(200) 主訴
標識 是否允許控制 數據類型 說明
ID 否
StudyNo 否
ryrp
zyh 否
patient
gwbs varchar(200) 過往病史
xbs varchar(200) 現病史
yxzd varchar(200) 印象診斷
zdjh varchar(200) 診斷計劃
zdyj varchar(200) 診斷依據
doctor varchar(20) 主治醫生
DoctorID Int 醫生編號
jlrp Datetime 記錄的日期
txr varchar(20) 填寫人
remark varchar(200) 備注
Xmlstudy Xml Xmlstudy
在醫院信息系統數據庫中，藥品的字典表也是一個非常重要的設計要素，
要考慮到藥品信息的各個方面，結合醫院在藥品維護方面的要求，設計一個適 合醫院藥庫管理和藥房應用的字典表。藥品的劑型和包裝與藥房發藥過程中能 否拆分使用有關［27］。藥品字典表設計如表4-3所示。
表 4-3 藥品字典表
Tab.4-3 Drug Dictionary Table
列名 數據類型 默認值 說明
ID int 編號
MC varchar(30) 名稱
DM varchar(10) 代碼
JX varchar(20) 劑型
BZ varchar(20) 包裝
SP varchar(20) 規格
KD varchar(20) 中藥等 類別
CI varchar(20) 收費項目
XFBL int 100% 自費的比例
XE bit T或F 是否限額
ZDXL int 最低限量
ZGXL int 最高限量
PF bit T或F 價格浮動
掛號信息表是記錄來源掛號的病人信息，與病人信息表相關聯，設計了掛
號狀態字段用來區分病人掛號后是否已就診，具體設計如表4-4所示。
表 4-4 掛號表
Tab.4-4 Register Table
列名 數據類型 默認值 說明
HB_id int 1 號別 ID
KH varchar(20) 卡號
ZYH varchar(20) 住院號
HZXM varchar(20) 病人姓名
XB varchar(2) 性別
NL int 年齡
DWMC varchar(200) 單位名稱
SFZH varchar(30) 身份證號
TZ float 體重
KS_id int 科室 ID
YS_id int 醫生 ID
ZT int 狀態
GHY_id int 操作員 ID
RQ datetime SystemData 記錄時間
JE money 金額
JZSJ datetime 接診時間
JZYS_id int 接診人
WCSJ datetime 完成時間
WCR_id int 完成人
收費業務作為醫院的關鍵業務，病人費用明細表的設計師非常重要的，具體
設計如表 4-5 所示。
表 4-5 費用明細表
Tab.4-5 Charge Details Table
列名 數據類型 默認值 說明
PD_id
KH int
varchar(20) 費用憑單 ID
卡號
ZYH varchar(20) 住院號
HZXM varchar(20) 病人姓名
XB varchar(2) 性別
NL int 年齡
SFZH varchar(30) 身份證號
KS_id int 科室 ID
YS_id int 醫生 ID
SFLB int 收費類別
XMBM varchar(20) 收費項目編碼
SFXM varchar(30) 收費項目名稱
DJ money 單價
SL int 數量
JE money 金額
GHY_id varchar(20) 操作員 ID
RQ datetime SystemData 記錄時間
4.2.3 數據庫視圖的設計
為了讓本系統的各個功能模塊能夠正常高效的運行，必須實現多張數據表的 信息同時獲取，在設計醫院信息管理系統時需要對系統的相關查詢功能進行優 化，確保能夠在最短時間內找到最有價值的信息，對于相關的數據表進行視圖 設計［28］，從而更為簡潔與美觀，本系統數據庫的視圖如表4-6所示。
表 4-6 數據庫視圖設計
Tab.4-6 Database View Design
編號 視圖名 視圖說明
1 V_FHYK 該視圖由兩個數據表組成，YKKC的主鍵ID是FHYK的外
鍵 KCBH
2 V_CFYP 由ZD_YP數據表和CFYP數據表組成，前者的主鍵ID是后
者的外鍵 YPBH
3 V_YFCRHC 由 YFCRHC 和 ZD_YP 兩個數據表組成，后者的主鍵 ID 是
前者的外鍵 YPBH
4 V_YFCRL 由YFCRL和ZD_YP兩個數據表組成，后者的主鍵ID是前
者外鍵 YPBH
包含RYTQ和ZD YP兩個數據表，后者的主鍵ID是前者外
5 V_RYTQ 鍵 YPBH
由YKCRL和ZD_YP兩個數據表組成，后者的主鍵ID是前
6 V_YKCRL
者外鍵 YPBH
由 YFKC、YKKC 和 ZD_YP 這三個數據表組成，第三個的
7 V_YFKC 主鍵ID是第二個外鍵YPBH，第二個的主鍵ID是第一個外鍵 YKKCBH
由YKCRHC和ZD_YP兩個數據表組成，后者的主鍵ID是
8 V_YKCRHC
前者外鍵 YPBH
由YKKC和ZD_YP兩個數據表組成，后者的主鍵ID是前者
9 V_YKKC
外鍵 YPBH
在這些數據庫的視圖之中，值得注意的幾個視圖即是：藥品出入庫視圖以 及藥品庫存視圖，使用編程語句創建這些視圖，查詢視圖時勾選的字段如果沒 有特別說明的話，那么就是默認的輸出字段。
4.3系統模塊功能劃分設計
通過對于醫院部門的設置以及相關業務流程的了解，將本文所研究的醫院 信息系統劃分如下六個子功能系統［29］：門診管理系統、住院管理系統、繳費管 理系統、藥品管理系統、婦幼保健系統以及綜合查詢系統，各個功能模塊的設 計開發是根據不同部門的職能以及相應的需求來實現的，各個子系統分別又有 不同的功能模塊，本系統功能模塊結構圖如圖 4-5 所示。
Fig.4-5 System Function Module Structure Diagram
如上所示就是本系統具體模塊之下所別對應的各個功能模塊，由于系統包 含的模塊多，所以在系統設計時采用用例建模方式來確定不同用戶的功能。這里 以門診管理、費用管理和藥品管理為例做詳細說明。第一層用例圖如圖 4-6 所示。
Fig.4-6 First Layer Use Case Diagram
（1）門診系統 門診系統負責病人掛號、醫囑、處方。費用管理負責收費、退費。藥品管理 中分為藥房管理和藥庫管理，藥房管理通過門診管理和費用管理系統傳來的已收 費處方進行核對發藥。費用管理系統通過接收醫生處方進行劃價收費，或病人退 藥退費處理。其用例圖如圖 4-7 所示。
病人首先是通過掛號，領取掛號憑證，然后醫生接診，開具醫囑或處方，然 后做相應治療拿藥。
工作人員分為醫生和收費員，醫生負責開方并把處方傳給費用管理系統，收 費員負責收取掛號費、藥費、退費等工作。
Fig.4-7 Outpatient Service Management System Use Case Diagram
（2）藥房系統 藥房管理系統負責根據門診管理系統藥品申請/申退信息及費用管理系統的 收據進行發藥和退藥處理，核算每天盤存。其用例圖如圖 4-8 所示。
門診管理系統主要通過開處方來完成藥品申請和申退。 藥房管理員負責通過核對藥品申請和申退信息及收據進行發藥和退藥。并進 行盤存/報損把數據傳給藥庫管理系統。
藥庫管理系統主要通過藥品發放及盤存核算監控藥品庫存量，當庫存小于預 警值時及時組織采購。
系統
藥庫管理了系統
圖 4-8 藥房管理系統用例圖
Fig.4-8 Pharmacy Management System Use Case Diagram
（3）藥庫系統 藥庫管理系統主要負責藥品信息維護，采購管理，入庫出庫管理，報損，庫 存核算等業務。其用例圖 4-9 所示。
藥房管理系統把每天保存及盤存數據傳給藥庫管理系統，藥庫管理系統通過 這些數據檢查庫存量，及時采購。
業務管理員對藥庫管理系統各個功能進行操作。
圖 4-9 藥庫管理系統用例圖
Fig.4-9 Drug Store Management System Use Case Diagram
4.3.1 門診管理模塊的設計
在門診管理系統之中，主要功能模塊為掛號分診系統和門診醫生工作站， 該子系統設計目標是為了更好地服務于患者。對于每一位患者而言，掛號、排 號以及檢查檢驗等流程需要花費大量的時間，尤其是在一些大城市的大醫院， 問題更加突出。建設門診管理子系統能使患者在掛號和分診服務方面的體驗度 提升，能方便醫生快速開具相關檢驗檢查的醫囑和藥方，患者能夠在最短時間 內解決從掛號到取藥的一系列流程。在縮減患者的就診時間的同時也提高了醫 院的效率與服務的質量［30-31］。
掛號分診系統的功能設計如下：
（1）患者憑身份證或者醫院一卡通或者社保卡進行掛號。
（2）患者掛號后，手持掛號條、就診卡等有效憑證在護士分診臺報到，護 士根據患者掛號科室進行分診。
（3）護士可以對患者進行就診優先級調整、預檢錄入、就診醫生分配，并 支持二次分診。
門診醫生工作站的功能設計如下：
（1）根據排隊情況進行叫號接診。
（2）門診醫生處理醫囑：檢查、檢驗、藥品等。
（3）門診醫生可以設置自己的常用模板。
（4）門診醫生可以查詢某個患者的個人信息和歷史就診信息。
4.3.2繳費管理模塊的設計
繳費管理系統與門診管理系統以及住院管理系統都有著密切的聯系。該系 統所包括的三個子模塊分別是：門診繳費、住院繳費以及自助繳費，其中，門 診繳費與門診管理系統相關、住院繳費與住院管理系統相關。患者在門診醫生 使用門診管理系統操作完成后，就需要到繳費管理系統進行門診繳費。如果需 要住院的患者，在門診管理系統中開具入院申請單后，將進入住院管理模塊， 進行住院繳費。住院繳費時將相關患者的信息登記入庫，以便于后續相關信息 的查詢。繳費管理系統還包括一個子模塊，即自助繳費模塊，自助繳費模塊的 設立大大降低了繳費管理系統的壓力，不用所有患者都排在窗口進行人工繳 費，讓一部分患者通過自助繳費的方式在自助繳費機上進行繳費，可以有效減 少患者排隊等候的時間，同時也極大提高了醫院的工作效率［32-34］。
門診繳費系統功能設計如下：
（1）通過刷患者就診卡提取繳費明細，收費記賬并打印發票。
（2）支持現金、銀行卡、微信或者支付寶等記賬類別。
（3）支持退費。
住院繳費系統功能設計如下：
（1）住院預交費管理，打印住院預交費單。
（2）支持現金、銀行卡、微信或者支付寶等記賬類別。
（3）住院結算，可與醫保系統對接實現醫保統籌結算。 自助繳費系統功能設計如下:
（1）患者通過刷卡得知自己的繳費金額和明細。
（2）支持銀行卡、微信或支付寶等繳費方式。
（3）門診繳費完成后自動打印小票，如果需要發票可憑小票到窗口打印發 票。
4.3.3住院管理模塊的設計
住院管理系統所包括的三個子模塊分別是：病人住院管理、住院護士工作 站和住院醫生工作站。該系統可以實現病人入院信息管理、出院核查和召回管 理、病人轉科管理、住院醫囑管理等功能。如果病人經過門診診斷需要住院治 療，在其主治醫生開具入院申請單后，病人需前往住院處辦理住院手續。另 外，病人入院登記、建立首頁信息等功能則由病人入出轉模塊來完成，系統將 32
對需要住院的患者信息進行記錄，從而可以更好地進行相關信息的管理和查 詢。
在入院登記完成之后，就需要在住院護士工作站模塊進行分床操作。該模 塊主要對科室的床位信息、病人護理信息、住院費用情況等進行管理。當病人 入住病房時，需要進行入住登記，另外，當病人離開病房時，也需要進行相關 登記，當其他的病人需要入住的時候就可以通過系統查詢，找出空余的床位， 安排病人入住即可，實現在最短的時間內安排病人入住，查詢相關信息的時候 也更加方便快捷。病人在院期間的各種護理記錄單可以通過電子化的形式進行 記錄，并在最后整理病歷的時候可以統一打印出來［35］。
住院管理系統還包括一個模塊，即住院醫生工作站。住院醫生工作站是集 成住院醫生日常工作的綜合平臺，包括對患者診療處理并完成醫療文書，以及 其他日常管理、查詢、維護工作。對患者醫囑處理包括用藥、檢查、檢驗、治 療、手術、護理、會診、轉科、出院等信息。
在整個工作流程中，住院管理系統數據庫中收集所有相關數據，可以選出 有價值的數據進行分析，可以的到決策支持信息，比如患者對于醫院住院服務 的評價數據，通過收集大量患者對于住院服務的評價，將這些數據進行分類解 析，從而得出結論，以此對于醫院進行一定的改進，完善醫院的服務，提高醫 院服務的質量［36］。其中住院醫護的用例圖如圖
病人住院管理系統功能設計如下：
（1）辦理入院登記、建立首頁信息。
（2）錄入病人信息后，系統自動根據身份證號檢索是否有歷史記錄，并合 并住院號。
（3）讀取門診醫生開具的入院申請單信息，自動填入入院登記表單。
（4）支持病人轉科管理。
住院護士工作站功能設計如下：
（1）床位管理：分床、清空床位、包床。
（2）執行醫生下達的醫囑。
（3）管理患者的費用。
住院醫生工作站功能設計如下：
（1）醫生處理醫囑：檢查、檢驗、處方、治療等。
（2）編輯病案首頁內容并打印。
4.3.4藥品管理模塊的設計
該系統包括藥房管理以及藥庫管理，當患者拿著醫生所開出的處方來抓藥 時，藥房工作人員根據醫師所開藥方發藥給患者。藥房工作人員在結賬日對藥品 進行盤點，并會對藥物數量階段性的進行統計，根據患者用藥數據進行分析， 從而對各種藥品的需求量進行統計。如果發現某一藥物的數量不足的話，即在幾 天之內可能滿足不了患者對該藥品的需求數量，藥房的管理人員就在入藥提請 模塊里面向藥庫發出申請，當藥庫管理子系統接收申請后，在提藥批復這一模 塊中對藥房的申請給予回復，并將相應藥品撥給藥房［37］。
為了方便患者取藥，設計了藥房發藥功能，對患者的基本信息以及所需領 取的藥品信息進行記錄，包括藥品的規格和劑型等，另外庫存管理記錄藥房藥 品的庫存。在藥庫管理模塊中，維護藥品的基本信息包括藥品定價，對庫存不足 的藥品提起采購申請，每個結賬周期對藥房和藥庫中藥物的信息進行匯總后以 形成報表。
藥房管理系統功能設計如下：
（1）門診發藥功能：接收醫生處方并執行發藥操作。
（2）門診退藥功能：接收退藥申請并執行退藥，在退藥操作執行后方可進 行退費。
（3）住院發藥功能：接收住院護士站藥品申請并向住院護士站發藥。
（4） 住院退藥功能：接收住院護士站退藥申請并執行退藥操作。
（5） 藥房庫存盤點：有庫存不足藥品時向藥庫發送補充藥品申請。 藥庫管理系統功能設計如下：
（1）錄入藥品規格價格等信息。
（2）藥品入庫和藥品退貨：采購藥品并生成入庫單；不合格藥品退貨給供 應商。
（3）藥品出庫和藥品退庫：藥品出庫撥給藥房并生成出庫單；藥房發現有 不合格藥品退庫給藥庫。
4.3.5 婦幼保健管理系統的設計
該系統包括圍產期保健管理，分娩管理以及兒童保健管理三個模塊。圍產 期管理主要是從懷孕初期的建立孕婦檔案一直到分娩這期間的歷次產檢信息進 行記錄，并讓主治醫生根據這些信息可以提供健康指導報告。分娩管理的功能 是記錄產婦分娩信息以及新生兒信息，并根據出生日期生成新生兒查體計劃。 兒童保健管理主要是記錄兒童 0-6 歲期間的查體記錄信息［38-39］。
圍產保健管理系統設計功能如下：
（1）孕婦建檔：建立孕婦信息檔案。
（2）產前檢查項目及檢查結果錄入，生成檢查結果報告。
（3）查詢功能：查詢孕婦信息和孕婦檢查結果信息。
分娩管理系統設計功能如下：
（1）產婦分娩信息錄入。
（2）新生兒出生信息錄入。
（3）生成新生兒查體計劃（0-6 歲周期）。
兒童保健管理系統設計功能如下：
（1）兒童建檔：建立兒童健康信息檔案。
（2）兒童歷次查體信息及結果錄入，可生成查體結果報告。
（3）查詢功能：查詢兒童信息和查體結果信息。
4.3.6 綜合查詢系統的設計
該系統包括查詢門診就診信息，住院患者信息，收入信息，藥品信息等各 種報表查詢。
醫院系統管理系統的管理員以及院領導等就可以通過綜合查詢這一系統來 將醫院的患者相關的信息進行一定的查詢，包括患者費用相關信息的查詢，藥 品使用情況的查詢，院領導要想查詢全部或者是某一特定的患者的相關的信息 的時候，只需要在查詢條件中輸入需要查詢的患者的姓名或者卡號等就可以查 詢得到了，或者是想要查詢醫生所診斷患者的相關信息，只需要輸入主治醫師 的姓名可以查詢到所有的患者的信息。在藥品信息查詢這一功能之中，要想查 詢某一種流入或者是流出的某種藥品的相關的信息，只需要輸入藥品的名稱或 者是藥品的出入的日期即可。
綜合查詢系統功能設計如下：
（1）掛號查詢：查詢某時段掛號信息情況。
（2）患者信息查詢：查詢住院患者個人信息和治療情況。
（3）收入查詢：查詢院內收入情況。
（4）藥品信息查詢：查詢用藥情況和藥品出入情況。
5醫院信息管理系統的實現
通過對于系統六個子功能模塊的劃分以及設計，對于門診管理模塊、繳費 管理模塊、住院管理模塊，藥品管理模塊、婦幼保健管理模塊以及綜合查詢模 塊的設計工作已經基本完成 ，這部分對各個模塊的實現過程做出介紹。
5.1門診管理模塊的實現
門診管理模塊對患者在門診過程中相關活動的數據信息進行記錄和維護。 門診管理模塊涉及的患者活動有掛號、開具醫囑以及處方等，患者從掛號開始 至離院這期間所有流程信息的操作和記錄。
5.1.1 掛號分診系統的實現過程
掛號分診系統功能設計包括：將病人等候就診信息放入掛號庫；已掛號患者 的分診和排隊；查詢掛號的歷史信息。
在掛號分診管理中，病人到掛號臺進行掛號，如果是持醫院就診卡病人通 過刷卡獲取卡號字符串，之后連接數據庫檢索對應的病人信息；如果病人無 卡，則需要進入辦卡流程，輸入病人姓名、性別、年齡、聯系地址、電話信息 后添加入數據庫對應的病人信息表。獲取到病人信息后，將該信息寫入掛號 表，表中就診狀態字段默認為FALSE,即未就診狀態。并將病人信息加入到對 應科室的候診隊列表。掛號分診系統流程圖如圖 5-1 所示。
I*合同單位 身份證號 EJ年齡
圖 5-2 掛號分診系統界面
Fig.5-2 Registration Triage System Interface
5.1.2 門診醫生站的實現過程
門診醫生工作站的用戶為醫生，其登錄有相應的權限驗證機制。通過刷卡獲 取病人的姓名、年齡、性別和地址等信息，接診病人后可填寫診斷，開具醫囑或 處方。如果有患者二次就醫的話，由于系統已經有了相關記錄，醫師可以檢索到 歷史就診信息，并根據病人以往的診斷情況和檢查結果做出快速準確的判斷。
數據的收集與記錄不僅可以提高就醫的效率，對于病人來說，也能夠快速 地接受治療，可以減少病人就診的時間，也能夠得到更好的服務。
門診醫生工作站只有系統賦予相應權限的用戶才能夠登錄，其登錄驗證的 代碼如下所示：
Private Sub cmdok_Click()
Dim value As String;
errom sg As String;
servername=txtserver.Text;
Zhangtaoname=1xtzhangtao.Text;
datab ssename=tx1dbname.Text;
Dbuser=tx1dblogin.Tex1;
dbpassword=txtd bpsw.Text;
Dbport=tx1port.Text;
value=Trim(1xtdblogin.Text);
If Write PrivateProfilcString(
“scction_dbuser”,”user”,value,App.Path+”dpass.ini”)=0
Then MsgBox ”寫入失敗”
Exit Sub
End If
value=encode(Trim(1xtdblogin.Text)
If Write PrivateProfilrString(
“section_dbuser”,”password”,value,APP.Path+”dbpsaa.ini)=0
Then
MsgBox ”寫入失敗”
Exit Sub
End If
Exit Sub
圖 5-3 即為門診醫生工作站系統的界面。
5.2繳費管理模塊的實現
繳費管理模塊對患者的收費記錄進行保存，并且將賬目以及收據根據財務 要求進行分類，從而生成財務報表，這些報表可以是年度報表，也可以是月度 報表，或者按照財務要求出具明細賬目報表，收集與記錄費用數據，提供查詢 窗口，可以按照不同的查詢依據進行分賬期查詢。
5.2.1門診繳費管理模塊的實現過程
門診繳費管理模塊的功能主要是劃卡收費以及根據退費流程進行退費。門診 收費的流程設計為：刷卡獲取患者卡號字符串，檢索收費字典和劃價收費表獲取 患者的費用明細并自動計算費用總額，收取費用后執行收費操作并打印發票或者 收據。圖 5-4 展示門診繳費管理模塊流程圖。
Fig.5-4 Outpatient Charge Management Flow Chart 圖 5-5 展示門診繳費管理模塊界面。
＜無數據顯示〉
5.2.2住院繳費管理模塊的實現過程
住院收費流程是比較繁瑣，所以在設計系統的時候需要考慮的要素也比較 多，具體的流程如下：住院護士站系統確定病人辦理出院，然后傳送相關的醫 囑，將病人的狀態進行設定，繼而與病區系統核對醫囑、撤銷或補充費用，然后 補充發藥，再之后對于交款通知單進行打印，核對預交金并結算金額，將費用 按分類進行統計，按照結算金額多退少補，將結算的記錄保存到數據庫，打印 住院結算發票，作為結算的依據。結算操作完成后將病人的狀態設定為出院狀 態，并在出入院的記錄之中對于患者的出院時間以及所在的科室進行登記。其 流程圖設計如圖 5-6 所示。
Fig.5-6 Hospitalization Charge Management Flow Chart
住院繳費管理模塊主要的功能就是對于患者在醫院的消費進行一定的記 錄，醫院提供多種的繳費方式，患者可以使用現金、也可以刷卡，或者可以使 用微信或支付寶，醫院不但有人工繳費的窗口，同時也有自助繳費的設備，由 于該模塊涉及到醫院以及患者相關利益問題，所以在記錄數據的時候十分嚴 謹，保證絕對正確，對患者住院的單號、所服用的藥品、病床號以及患者所對 應的主治醫師都需要進行詳細的記錄，記錄病人住院預交金，患者住院花費的 總金額，當患者出院時結算，多退少補。患者住院期間各項治療費用及用藥品費 用都要明確記錄，提供簡明格式和明細格式的報表以方便查詢。
費用清單生成的方式是通過將不同費用類別進行匯總，在表的 Order Cost 以及tmp Order Cost之中對住院期間的費用進行統計，將其設為報表形式，采用 專業的報表工具，將報表打印出來。圖 5-7 展示住院收費管理模塊界面。
圖 5-7 住院繳費管理界面
Fig.5-7 Hospitalization Charge Management Interface
5.2.3自助繳費管理模塊的實現過程
自助繳費管理模塊是結合銀行投放的自助設備進行設計的，本系統的設計重 點在于數據傳輸部分。
該模塊的功能是將門診收費檢索到的費用總額傳輸到銀行系統進行銀行卡 或者其他記賬方式的扣款行為，銀行系統將扣款成功的標志返回到本系統進行執 行收費確認并打印票據。圖 5-8 展示該模塊的流程圖設計。
Fig.5-8 Self-service Charge Management Flow Chart
自助繳費管理所使用的自助機界面如圖 5-9 所示。
圖 5-9 自助繳費管理界面
Fig.5-9 Self-service Charge Management Interface
5.3住院管理模塊的實現
5.3.1 病人入出轉管理系統的實現過程
病人入出轉管理模塊的具體規劃是結合病人從入院到出院的信息管理流程 進行的，包括辦理入院的手續，填寫病案首頁病人基本信息，在院期間有轉科治 療需要的則需要辦理轉科手續，轉科后其原來所在治療科室的醫囑全部停止。
如果患者被診斷的結果是需要住院，那么就需要患者或者是家屬拿著醫生 開的相關的證明來辦理手續，如果此時相應科室已經有了空余的床位的話，那 么管理人員對于該信息進行一定的記錄之后，就可以將該患者安排入住該科 室，從而及時地為相關患者提供更好的服務。
一般情況而言，對于醫院信息系統的數據庫來說，大部分的內容都是住院 病人的相關的信息。由于在院病人出院和新病人需要住院，這就要求我們數據庫 的數據需要及時地進行更新，對于已經出院病人的資料進行一定的歸檔，對于 已經辦理入院的病人的信息進行記錄。
在入院登記表單界面，由操作人員錄入病人的基本信息。表格中的信息則寫 入到數據庫中，這里會對身份證有一個比對，如果該病人有歷史住院信息，則將 此次住院號與歷史住院號合并。
比對身份證的數據庫操作 sql 語句：
select ZYH from ZD-HZ where DFZH = '**'
病人入出轉管理模塊的入院登記表單界面如圖5-10所示。
卡號 入院登記 住院號I
費 別 二□合同單位［ 二0病人證號［ 二|姓名 匚
身份證號匚 口性別 匸 二0年齡 口3芝衛］出生日期匚
出生地壽光市 ■民族I漢族 W國籍I中國 21婚姻I~~H職業
工作里位 聯系電話 郵政編碼
戶口地址匚 □聯系電話［ □郵政編碼匸
聯系人 地址 □聯系電話「 關系 廠
人員類型 起付線*03 卡余飆岸0.00 擔保人 擔保關系
入院科室匚 | “ |入院時間|加毎P3-16 * ||陽:23 2 |入院方式|直接住院 丨司入院情況
門診醫師匚 二□入院診斷匚 二|病人來源匚 二0主院坎數~~［I］
內部卡余額|¥q.qq 二|可用金飆 刊皿
預交款金額|¥q.qq 交款方式"Hxl收將號
|讀卡® I顧藥病人(B) I I二代身份證閱 —I I確定(Q) I占閉図I
住院護士站的功能核心是對病人的醫囑執行，費用核對，以及對科室床位的 維護和安排病人床位等方面的信息管理［40］。
在院病人的費用清單會在匯總表格中呈現，患者在出院結算之后其住院流 程就結束了，在患者出院后醫院為了使患者所花費用更加透明化，會給患者提 供費用信息表單，在這份表單之中涉及到多種信息，包括病人診斷信息，住院 治療的相關信息和花費，以及所使用的藥品的名稱、種類以及價格，患者所做的 檢查和檢驗項目的名稱價格等等，所以在這份表單之中，可以看到明細的價格 費用，即為患者出院清單。該存儲過程的部分 SQL 語句為：
select patient_name,item_name,amount,total_fee
from HZSF where case_no =‘@case_no'
住院護士站模塊的部分代碼如下所示：
Private Sub DataGrid1_RowColChange(LastRow As Variant,ByVal LastCol As
Integer)
If rsGHLB.Recordset.RecordCount=0
Then DeptNo.Enabled = False
DeptName.Enabled = False
If rsGHLB.Recordse.Fields(0).value <> “”
Then DeptNo.Text = rsGHL B.Recordset.Fileds(1).value
End If
isModify=True
End Sub
住院護士站費用管理功能界面如圖5-11所示。
住院號［ 口病人ID ［ 二□費別 二|床位號 二|天數匚
姓名 二|性別|―齡「口科室 二|入院日期匚
診斷預交款費用合計I ~|余頷
科室匚 "T7!醫生匚
費用名稱 規格 丨單位丨 單價 丨數量丨 金額
V無數據顯示》
對于該模塊來說，其實其中最為重要的部分就是對于病人的治療信息進行 管理，本系統的運行使得調取患者相關的信息更為容易，并且可以隨時地對于 某些治療信息進行一定的修改。
由于在該管理模塊之中需要對于數據進行適時地更新和修改，所以要想實 現在相關數據得到改變的情況下系統仍然能夠正常地對于數據進行查詢，并且 要保證這種查詢的正確性，這要求我們在數據庫操作中要保證適時更新，在本 系統模塊之中所使用的更新方法是在 DataGrid 的表格之中，找到需要修改的患 者的信息，在信息更改完成后點擊修改按鈕即可，這樣才能保證相關患者的信 息在任何特殊的情況下及時地得到一定的修改。
在住院醫生工作站模塊中，醫生需要將其使用的藥品，做的治療項目及檢 查檢驗項目進行記錄，這樣在患者出院的時候，就可以通過打印出院清單進行 查看。如果患者的病情已經好轉或治愈，醫生下達出院醫囑，那么該患者就可 以辦理出院手續了。
住院醫生工作站的醫囑管理界面如圖5-12所示。
床位：42床 住院號：1800495 姓名：于子皓性別:男 年齡：5歲 費別：居民保險〔住 藥占比=0.00% 全部 長期
入院日期；2018-01-02 09:05 總費用：14604.00 余額：-9604.00 診斷；精神發肓遲滯 •醫囑本 臨時
|類型|類別|開始醫師|開始時間| BBAS J量單位 途徑|頻次|_結束時間_ 注意事項 狀態費用扌備異帳戶|開始護士丨結束護士
長期護理楊炳濤 2018-01-02 09小兒內科護理常規
長期護理楊炳滂 2018-01-02 09 ]]級護理
長期膳食楊炳濤 2018-01-02 09普食
長期護理暢炳濤 2018-01-02 09留陪人
長期洽療楊炳淸 2018-01-02 09引導式教育訓練 次
長期治療楊炳濤 2018-01-02 09言語訓練 30.1.1.
長期泊療楊炳濤 2018-01-02 09構音障礙訓練 次
長期治療楊炳濤 2018-01-02 09作業療法 45mir
丨類別I類型I開始日期 丨時間I 醫囑內容 I劑量I單位丨途徑丨頻次 丨注青事項丨費用標志丨備用丨醫師丨領量丁範
＜無數據顯示〉
|導入⑧|廝E囑@）||子醫喔⑴||刪除（吵| |保存（3）11提交（①11打印（E）11關閉熾|
圖5-12醫囑管理界面
Fig.5-12 Doctor's advice Management Interface
5.4藥品管理模塊的實現
藥品管理模塊的功能主要是對醫院藥品和衛生材料的管理，藥房是面向病 人的取藥窗口，藥庫則是面向醫藥公司的進貨部門。藥房管理系統能提供更科 學的配藥發藥流程和核對體系，使得病人的取藥過程更加便捷和準確；藥庫管 理系統則重點規劃藥品的入庫出庫流程，使醫院在藥品的采購和領用上更加規 范。
藥房管理系統的功能主要有發藥、退藥和盤點這幾個方面。退藥的流程根 據不同醫院的要求會有一個退藥審批的過程，通常需要相應的分管院長許可才 可以通過審批進行退藥操作。盤點則是藥房在每個結賬日對藥品的庫存和使用 量進行盤點，并對面臨缺貨的藥品向藥庫發起領用申請。藥房最重要的部分是 發藥，本系統對于發藥的設計流程圖如圖 5-13 所示。
圖 5-13 藥房發藥流程圖
Fig.5-13 Pharmacy Drug Delivery Flow Chart
本系統發藥功能的界面如圖 5-14 所示。
Fig.5-14 Pharmacy Drug Delivery Interface
5.4.2 藥庫管理系統的實現過程
藥庫管理系統的功能主要有入庫和退貨、出庫和退庫及藥品信息維護這三 個方面。藥品的信息維護主要是針對醫院有新的藥品種類入庫時需要將新藥的 編碼、名稱、劑型、價格這些信息進行維護，在藥品字典表中進行添加，添加 完成后方可進行入庫出庫等操作。藥品基本信息維護的界面截圖如圖 5-15 所 示。
基本信息包裝/價格
藥品2扁碼 11001a 醫囑編碼11001
藥品名稱 1
藥品別容 1-1
收費類別 西藥 批準文號［
藥理類別 I- 藥品劑型衛生材料
毒理類別 卜 藥品級別1
發藥類別 其他 預警天數90
生產商 卜 +抗生素分級
徉儲條件 抗生素分類
職工醫保 卜 居民醫保匚
門診自付比例 0 衛 住院自付比例 。
助記碼 醫保編碼
農合編瑪 其他編瑪
圖 5-15 藥品信息維護界面
Fig.5-15 Drug Information Maintenance Interface
藥品信息維護是對數據庫中表的更新操作，本系統中添加新的藥品時數據庫
SQL 語句為：
Insert into ZD-YW values (@bianma,@mingcheng,...)
藥庫管理中有一部分功能是關于藥品分級管理的，其中一個比較重要的功能 是抗菌藥物使用率的統計，本系統中抗菌藥物使用有一個專門的統計表格，其在 數據庫中進行查詢統計的存儲過程為：
ALTER PROCEDURE ［dbo］.［門診抗菌藥物查詢］
@begin_date datetime,
@end_date datetime
AS
set nocount on;
create table #tmp_p(dep_name varchar(50),zongshu int)
create table #tmp_c (dep_name varchar(50),kangjun int)
insert into
#tmp_p(dep_name,zongshu)
select ZD-KS.department_name,count(distinct(patient_no))
from ZD-KS,HJSF left join ZD-YS on HJSF.doctor_id = ZD-YS.person_id where patient_source=1 and is_drug = 1 and operate_date between @begin_date and @end_date
group by ZD-KS.department_name
insert into
#tmp_c(dep_name,kangjun)
select ZD-KS.department_name,COUNT(distinct(patient_no))
from ZD-KS,HJSF left join ZD-YS on HJSF.doctor_id = ZD-YS.person_id
where patient_source=1 and item_no in (select item_no from ZD-YW where isnull(antibiotics_flag,0) != 0) and operate_date between @begin_date and @end_date group by bse_department.department_name
select *
from #tmp_p left join #tmp_c on #tmp_p.dep_name = #tmp_c.dep_name
drop table #tmp_p
drop table #tmp_c
set nocount off
5.5婦幼保健管理系統的實現
婦幼保健管理系統的功能分為三大塊，分別是圍產期保健管理，分娩管理 和兒童保健管理。該系統將原先手工記錄的紙質化數據變為大量的信息化電子 數據，將婦幼保健院原有的被動服務模式變為主動服務模式，利用電子化的數 據可以實現孕婦產婦兒童的在線管理，對于國家規定的婦幼公共衛生服務內容 可以及時的提醒孕產婦和兒童到院檢查，同時又可以通過定期的推送通知提高 醫院的其他業務量。
5.5.1 圍產保建管理模塊的實現過程
本模塊將數據庫中病人信息數據表和門診處方表等多個數據表聯合使用， 記錄孕婦檔案和孕婦檢查開方信息。提供多種查詢，比如孕婦檔案查詢、孕婦 就診明細查詢、孕婦復診查詢等。其中孕婦檔案查詢中查詢全部孕婦檔案的 SQL 語句為：
select * from ZD-HZ where is_preg = 1
本系統中查詢孕婦就診明細的界面截圖如圖 5-16 所示。
的曰期：2017-3-1 ”至2017-9-8 亍 姓名： 身份證號： 二 編號: 手機號： 三更多
當前孕周： 預?哦： 至 ▼ 高危：缽▼ 狀態：全逆二 [""”範…]衛重置
呂孕婦編號
I84 姓名
圧娟 年齡 當前 孕周
38" 2017-09-17 咼危因素
瘢痕子宮；年齡235歲 蠟
12 H2R 終止 分娩 斫到診
2017-09-01 電話
13864347617 戶籍地址
山東譽荷澤地區成武縣
1- 朱圓圓 34 39" 2017-09-11 子宮 12 2017-08-30 18754356192 山東省濱州地區博興縣
[86 弓越 36 42" 2017-08-20 廁8子宮 6 2017-08-07 13371586909 山東省淄博市張店區馬尚鎮豹 的166號
y 阮阿方 29 39” 2017-09-09 7 2017-07-31 18654350390 湖南省邵陽市隆回縣
|&8 張 26 41-5 2017-08-27 糖M 9 2017-08-27 15275436322 博興
89 劉敏敏 22 2017-06-08 1 2017-03-13 18766639118 山東省博疼純化鎮劉前村174號
90 朱明媛 27 39" 2017-09-14 8 2017-09-03 15223003103 山東背濱州地區博興縣
|91 義海霞 31 42" 2017-08-20 5WK子宮 9 2017-08-09 15965538971 山東省桓臺縣果里鎮養坊村4組176號
I92 32 3T2 2017-11-08 1 2017-03-13 18766992291 山東省淄博市桓臺縣
93 李臓 41 2017-08-08 年齡235歲;妊娠期糖關 7 2017-07-19 18754346475 山東省博興縣博昌辦事處王木村24晦
95 張麗霞 29 37“ 2017-09-23 瘢痕子宮 11 2017-09-02 18753378506 山東背桓臺•縣少海街道辦事處趙家村1組
96 李換 25 397 2017-09-12 糖銅 6 2017-08-29 18954360444 山東省博興縣興福鎮中李村15皤
97 胡秀芝 39 37* = 2017-09-24 年齡2 3 5歲 11 2017-09-07 13686306133 山東省博興縣湖髙H孟橋村清湖路5 54號
〔98 険工麗 39 40+4 2017-09-04 6 2017-08-22 13589585413 注園
]99 咼 36 40" 2017-09-06 年齡2 35歲 12 2017-09-04 13675338228 王莊
|l00 高秋梅 38 39七 2017-09-12 年齡2 3 5歲 8 2017-08-22 13563076730 博7T7T福城夕卜于
|l01 遜群 29 38 2017-09-22 礪子官 8 £ 2017-08-03 18265895111 山東省淄博臺縣
6799
圖 5-16 患者列表界面
Fig.5-16 Patient List Interface
5.5.2分娩管理模塊的實現過程
本模塊是將孕婦分娩的信息進行記錄，同時記錄新生兒信息。可以根據既
定的方案生成檢查周期。本系統添加新生兒記錄的界面截圖如圖 5-17 所示。
圖 5-17 添加新生兒記錄界面
Fig.5-17 Add New Baby Account Interface
5.5.3兒童保健管理模塊的實現過程
兒童保健管理的功能主要是兒童建檔，兒童健康查體信息記錄以及各種報 表查詢，包括兒童檔案查詢和兒童查體明細查詢。本系統提供支持在本院分娩 出生的兒童信息可以從分娩管理模塊調取過來生成兒保檔案，該功能界面截圖 如圖 5-18 所示。
圖 5-18 兒童建檔界面
Fig.5-18 Add Child File Interface 兒童檔案的檢索可以根據多個條件進行查詢，比如保健手冊編碼，兒童姓 名，母親姓名，身份證號等。該查詢的數據庫SQL語句為：
select * from ZD-HZ where file_no = @file_no 兒童健康檔案的建立是根據兒童 0-6 歲階段的長周期、多方面的查體數據而 來，電子化的健康檔案可以在兒童入托、上學、出國等多個階段起到關鍵輔助 作用，同時有條件的醫院也可以利用數據分析的手段提升區域保健服務和醫院 整體效益。
5.6綜合查詢系統的實現
綜合查詢系統是依據 FastReport.Net 工具的功能實現的。該工具能創建獨立 于應用程序的報表。也就是說， FastReport.Net 能作為一款獨立的報表工具進行 運用。所以本系統只需要將數據庫中的數據連接上 FastReport.Net 工具則可以利 用該工具編輯各種形式的報表，也可以添加各種公式。
在本系統實現過程中，添加FastReport工具的過程是利用Index()方法，首先 創建一個 webReport 類實例，創建一個變量來存儲包含報表的文件夾的路徑。對 于該報表所需的數據，我們創建一個數據集并加載xml數據庫，使 用 RegisterData () 方法在報表對象中注冊數據源。該過程的代碼實現如下：
public ActionResult Index(){
WebReport webReport = new WebReport();
string report_path = "@path";
System.Data.DataSet dataSet = new System.Data.DataSet(); dataSet.ReadXml(report_path + "nwind.xml"); webReport.Report.RegisterData(dataSet, "NorthWind"); webReport.Report.Load(report_path + "Simple List.frx");
ViewBag.WebReport = webReport;
return View(); } 本綜合查詢系統查詢的內容包括掛號查詢，收入查詢，患者信息查詢，藥
品業務查詢等。其中門診掛號統計的系統界面截圖如圖 5-19 所示。
統計時間
O掛號日期 起始日期1^)17-03-01 ■
@日結日期 結束日朗2C1T-03-02 v
統計類型
@科室(掛號科室C醫生
O費別 掛號員―匚顯示費別明細
門診掛號科室統計報表
圖 5-19 掛號統計界面
Fig.5-19 Registered Statistics Interface
6系統測試
系統開發完成后要利用測試工具按照測試方案和流程對開發完成的產品進 行功能和性能測試，執行測試用例后，跟蹤故障，排除問題，以確保開發的產 品適合需求。
本系統采用經典的系統測試經常會使用兩種方法，白盒測試以及黑盒測 試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的 是盒子是可視的，你清楚盒子內部的東西以及里面是如何運作的。通過檢查軟 件內部的邏輯結構，對軟件中的邏輯路徑進行覆蓋測試；在程序不同地方設立 檢查點，檢查程序的狀態，以確定實際運行狀態與預期狀態是否一致。本系統 采用的白盒測試的測試方法有代碼檢查法、靜態結構分析法、邏輯覆蓋法、基 本路徑測試法、路徑覆蓋。通過白盒測試檢測代碼中的每條分支和路徑、揭示 隱藏在代碼中的錯誤。黑盒測試也稱功能測試，通過測試來檢測每個功能是否 都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮 程序內部結構和內部特性的情況下，在程序接口進行測試，只檢查程序功能是 否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產 生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主 要針對軟件界面和軟件功能進行測試。以用戶的角度，從輸入數據與輸出數據 的對應關系出發進行測試。
相對應的測試的內容以及結果如表 6-1 所示。
表 6-1 系統測試表
Tab.6-1 System Test Table 測試類型 測試的內容
1、界面錯誤
2、功能措施或者遺漏
黑盒測試
3、數據結果訪問錯誤
4、初始化錯誤
1 、測試的目的是為了使模塊中的獨立的路徑至少被使用過一次
2、對于邏輯進行 true 或者是 false 的測試
白盒測試
3、在一定的可以操作的范圍之中對所有的循環進行一定的操作
4、為了保證數據的有效性查詢相關的數據結構
上述就是白盒測試和黑盒測試的具體內容，我們分別對該系統的各個模塊
進行測試，預期測試的內容以及實際測試的結果如表 6-2 所示。
表 6-2 系統測試結果表
Tab.6-2 System test results table
測試內容 測試方法 預期測試的結果 實際測試結果
門診管理 等價類劃分法 頁面顯示是否正常，相關數據是
否可以快速便捷查詢 通過測試
繳費管理 邊界值分析法 頁面是否顯示正常，數據的導入 與輸入是否正確 頁面是否顯示正常，增加、修改、 通過測試
住院管理 因果圖法 刪除等等操作是否可以正常進 通過測試
行
藥品管理 錯誤推測法 頁面的顯示是否正常，打印導出
操作是否可以正確的進行 通過測試
圍產保健管 理 使用各類測試
用例進行 頁面顯示是否正常，輸出結果是
否符合要求 通過測試
綜合查詢 使用各類測試
用例進行 頁面的顯示是否正確，各個模塊
的相關數據的查詢是否可以進
行 通過測試
本文采用上述的方法對于各個模塊進行了測試，實際測試結果為通過測 試，在系統上線運行之后仍可能會出現預想不到的問題，所以在系統開發完成 后需要不斷優化，不斷再進行測試，并適時地對系統進行功能性檢測，及時發 現問題并解決問題。在第一次測試過程中，發現系統是存在一些問題的，通過 對問題進行分析，發現主要原因有以下三點：
（1） 在系統分析的時候就對于該系統的需求描述不明確，導致結果與用戶 需求有偏差。
（2） 在進行系統設計時，由于系統功能中有部分輸出的報表設計不太全面 導致軟件測試的時候出現問題。
（3） 各個模塊之間的協調度不是特別高，雖然單個模塊功能達到預期效 果，但是從整體上看，彼此之間的聯系卻并沒有達到需求，所以總體來說其功 能會有一定的降低。
在測試過程中出現的問題在經過修改以及完善之后，又一次針對這些方面 的問題設計了測試，最終全部通過測試。
在經過軟件系統測試之后，系統就要正式投入運營之中，運營系統的重點 在于對其日常的維護。值得注意的一點是，系統維護并不是一成不變的靜態過 程，而是處于不斷變化的動態過程中。進行系統維護的目的是使系統在日常運行 中能夠保持良好的狀態，發揮系統的促進作用。
7 結論
隨著我國醫療衛生行業的不斷改革和發展，信息化在醫院服務方面發揮著 越來越重要的作用。正是因為信息化的發展，以及人工智能等技術的出現，醫 療技術也不斷地發展，各種醫學疑難雜癥隨之出現新的治療方式。醫院管理問 題也因為信息化建設變得越來越科學。但是，多數中小型醫院其信息系統都是 不完善的，在日常業務流程中不能快速高效地解決問題。因此，如果要想提高 中小型醫院的服務質量，為更多老百姓提供更好的服務，勢必要開發一套適合 中小型醫院的信息管理系統。醫院提供良好的服務其實不僅是運用高超的醫術 為病人治病，還包括對病人就診流程提供便捷，建立健康檔案，并且利用醫學 和計算機科學對病人檔案進行整理分析。有了數據支撐，醫師能夠為病人提供 更加合適的治療方案。如果僅是通過人工方式記錄業務數據，需要大量的精 力，難免容易出錯。使用醫院信息管理系統可以將比較繁瑣、復雜的流程通過 計算機處理，并將數據存儲在關系型數據庫中，從而可以實現無紙化辦公并且 建立醫學知識庫。
本文通過對醫院的就診流程以及現有的醫院信息管理方法進行分析，設計 并開發了一個高效、便捷的醫院信息管理系統。在整個設計與開發過程中，遵 循了軟件工程思想。首先，對該系統的需求進行分析，繼而對各個模塊的功能 以及系統數據庫進行設計，最后，實現了基于 B/S 三層架構之下的醫院信息管理 系統。對于系統開發過程以及所運用的技術也都進行了深入、細致的研究。
本文對醫院信息管理系統的研究背景以及意義進行了闡述，對于本課題的 主要研究工作以及創新之處也進行了詳細說明。另外，還對國內外相關研究的 現狀進行了論述，并且揭示與分析了目前在中小型醫院信息管理系統中所存在 的問題，從而為本課題的研究以及論文的撰寫奠定了基礎。
為了使系統的設計以及軟件開發能夠正常進行，本文一開始就對用戶需求 進行了詳細分析，確定了醫院信息管理系統的功能需求，并設計了系統的功能 模型。另外，本文對在系統設計與開發過程中所使用的技術進行了詳細介紹， 例如，數據庫以及 B/S 架構等。
在醫院信息管理系統的設計過程中，我們對系統架構、用戶界面都進行了 優化設計，并且把設計的重點放在系統功能模塊上，從而確定了系統的六個大 功能模塊。最后，我們對醫院信息管理系統的各個模塊功能的實現進行了介 紹，并采用多種方法，設計了多個測試用例進行軟件測試。測試過程中所發現 的系統問題逐一進行了修復。
醫院信息管理系統是一個非常復雜的綜合信息管理系統，由于時間以及技術 水平等因素，本文還存在一些地方需要進一步完善。從目前系統的實際運行情況 來看，主要在以下方面可以進一步改進：（1）系統的用戶界面還有待進一步補充 或完善，例如，在某些查詢的使用上應該更加符合用戶的使用習慣，頁面的顯示 內容和樣式應更容易調整、界面也應該更人性化一些。（2）為了幫助醫院提高業 務水平，還可以添加一些輔助功能，例如，用藥參考信息、優秀病案資料參考等 功能。
參考文獻
[1]S. Bennett. Object-Oriented System Analysis and Design Using UML[M]. Mc Graw-Hill International Limited, 2011.
[2]A.Wood. Predicting Client/Server Availability[J]. Computer, 1995, 28(4): 41-48.
[3]段會龍，呂旭東.醫療信息系統發展現狀及趨勢[J].中國醫療器械信息,2004,10(2): 1-6.
[4]E. J. Braude. Software Engineering-An Object-Oriented Perspective[M]. New York: John Wiley &Sons Press, 2001.
[5]商斌，王虹.基于Web醫院故障網上報修系統的設計與實現J].中國數字醫學，2013, 11:
43-45.
[6]姚建根，吳雪嬌.關于新建大型綜合醫院信息化建設思考J].現代醫院管理，2011, 9(1):
44-46.
[7]Y. Tsumoto, S. Hirano, S. Tsumoto. Quantitative Estimation of Software Quality in Hospital Information System[J]. Neuroscience and Biomedical Engineering, 2016, 4(1): 57-66.
[8]B. Bernd, H. Martin. CORBA security services for health information systems[J]. International Journal of Medical Informatics, 2016, 52: 29-37.
[9]C. Britton. Object-Oriented System Development: a gentle introduction[M]. Mc Graw-Hill International Limited, 2011.
[10]S. Kel, B. Armstrong, P. Vitale. System Optimization for OLTP Workloads[J]. IEEE Micro, 2011, 11(3): 56-64.
[11]G. Yucel, S. Cebi, B. Hoege, et al. A fuzzy risk assessment model for hospital information system implementationJ]. Expert Systems with Application, 2012, 39(1): 1211-1218.
[12]J. D. Engquist. Client-server computer system and method utilizing a local client disk drive as a data cache[P], US Patent 5802297, 2013: 150-185.
[13]F. Pinciroli, M. Marchente, C. Combi, et.al. A communication architecture for hospital information systems[J]. Computer Methods and Programs in Biomedicine, 2000, 62(1): 59-68.
[14]T. M. Connolly, C. E. Begg. Database systems: a practical approach to design, implementation, and management[M]. Addison-Wesley Longman, 2012.
[15]J. Richter. Applied Microsoft .NET Framework Programming[M]. World Book Publishing House, 2002.
[16]A. Turtschi. C# .NET Web Development Guide (US)[M]. Mechanical Industry Press, 2003.
[17]張海藩. 軟件工程(第四版) [M]. 北京: 清華大學出版社, 2009.
[18]佩佐爾特.SQL Server程序設計[M].北京：機械工業岀版社,2008.
[19]楊宏偉, 李晶. SQL Server 程序員開發手冊. 北京: 科學出版社, 2010.
[20]王凌.基于.NET的放射科信息管理系統的設計與實現[D].江西財經大學碩士學位論文, 2016.
[21]李燦.軍隊醫院心臟導管室信息系統的設計與實現[D].天津大學碩士學位論文,2016.
[22]周岳亮.手寫簽名身份認證技術在HIMS的研究和應用[D].廣西大學碩士學位論文, 2016.
[23]S. Bennett. Object-Oriented System Analysis and Design Using UML[M]．Mc Graw-Hill International Limited, 2011.
[24]薩師煊, 王珊. 數據庫系統概論(第三版). 北京: 高等教育岀版社, 2010.
[25]Pezzolt. SQL Server programming. Mechanical Industry Press, 2008.
[26]D. M. Kroenke. Database processing: Fundamentals, Design, and Implementation[M]. Electronic Industry Press, 2001.
[27]A. L. Costa, M. M. B. D. Oliveira, R. D. O. Machado. An information system for drug prescription and distribution in a public hospital[J]. International Journal of Medical Informatics, 2004, 73(4): 371-381.
[28]J. S. Bowman, S. L. Emerson, M. Darmovsky. SQL utility reference manual[M], Beijing: Tsinghua University Press, 2002.
[29]朱甬倩，劉云，王忠民，蔡碧.數字化醫院信息門戶集成的設計與實現J].中國數字醫 學, 2013, 8(11): 31-33.
[30]范文超.基于PHP的醫院掛號系統的設計與實現[D].北京林業大學碩士學位論文,2016.
[31]顏廷偉.基于物聯網的智慧醫院信息控制系統[D].曲阜師范大學碩士學位論文,2016.
[32]A. Gadbury. Design and implementation of outpatient registration subsystem of hospital information system[D]. Master of Engineering, Beijing University of Posts and Telecommunications, 2011.
[33]趙姝.銀川市金鳳區社區醫院信息管理系統的設計與實現[D].電子科技大學碩士學位 論文, 2016.
[34]賈理君.SCU校醫院信息管理系統的設計與實現[D].天津大學碩士學位論文,2016.
[35]谷伯濤.病區整體管理系統建設實踐[J].中國數字醫學,2013, 8(12): 106-107.
[36]張春艷.醫學本科生“雙導師制”管理系統平臺構建研究[D].昆明理工大學碩士學位論 文, 2016.
[37]周穎.醫院信息系統上建立藥品管理系統[J].科技風,2013, (21): 267-268.
[38]陳曉燕.醫藥企業客戶關系管理系統的設計與實現[J].現代計算機(專業版)，2013, (28): 77-80.
[39]明宏偉.醫院信息系統研究與應用[D].浙江海洋大學碩士學位論文,2016.
[40]鄭英, 陳科羲. 住院護士站網絡管理系統在臨床護理實際應用及體會. 基層醫學論壇, 2007, 11(24): 1124-1125.
下一篇：沒有了
相關標簽:
