醫療管理系統實作-以健保診所為例

(1)

逢甲大學

資訊工程學系專題報告

醫療管理系統實作

以健保診所為例

學

生：許薰任 (四甲)

指

導

教

授：謝信芳教授

中華民國九十一年十二月

(2)

(3)

(4)

圖表目錄 ...7 自序 ...13 摘要 ...14 第一章 導論...15 1.1 背景資料...15 1.1.1 動機 ...16 1.1.2 目的 ...16 1.1.3 結果 ...17 1.2 相關研究...17 1.2.1 目前業界廠商...17 1.2.2 問題重要性...17 1.3 研究主題及其價值...18 1.3.1 題目主旨...18 1.3.2 研究範圍...18 1.3.3 假設條件...18 1.3.4 期望效益...19 第二章 系統概述...20 2.1 專案對象...20 2.1.1 目標診所資料...20 2.1.2 人員組織架構...20 2.2 系統架構簡介...21 2.3 初步介紹...23 2.3.1 問題概述...23 2.3.2 初步分析...23 2.3.3 初步解決方案...24

(5)

第三章 系統開發基礎理論...26 3.1 研究開發的理念... 26 3.2 系統開發使用的方法理論 ... 26 3.2.1 系統開發過程與模型... 26 3.2.2 資料庫應用程式發展生命週期 ... 31 3.2.3 資料庫的正規化... 33 3.3 資料庫方案選擇... 34 第四章系統分析與設計 ...35 4.1 初步調查報告書... 35 4.1.1 瞭解問題... 35 4.1.2 確認專案範圍與限制... 35 4.1.3 確認效益... 35 4.1.4 估計時間與成本... 36 4.1.5 提交管理階層評估決策... 36 4.2 使用者需求報告書 ... 37 4.2.1 輸出... 37 4.2.2 輸入... 37 4.2.3 過程... 37 4.2.4 時間安排... 38 4.2.5 控制... 38 4.3 資料需求規格書... 39 4.4 醫療診所管理系統分析設計書 ... 42 4.4.1 系統簡介... 42 4.4.2 現況分析... 44 4.4.3 資訊描述... 47 4.4.4 表單分析... 50 4.4.5 功能描述... 50 4.4.6 系統確認標準... 50 第五章資料庫設計...51 5.1 概念層設計書... 54

(6)

5.1.2 以資料觀點來介紹實體與關係...62 5.2 邏輯層設計書...69 5.2.1 概念層轉邏輯層設計...70 5.2.2 正規化過程...80 5.3 實體層設計書...85 5.3.1 病患基本資料...86 5.3.2 掛號批價...89 5.3.3 看診紀錄...92 5.3.4 診所疾病藥品...95 5.3.5 健保規定...97 5.3.6 健保對照表...99 5.3.7 輔助表 ...102 5.3.8 代碼表 ...104 5.3.9 關聯表 ...107 第六章系統實作 ...108 6.0 健保診所管理系統...109 6.0.0 主框架 ...110 6.0.1 登入視窗...111 6.0.2 主畫面 ...112 6.1 掛號批價子系統...113 6.1.1 系統簡介...113 6.1.2 系統分析...116 6.1.3 系統設計...121 6.2 病歷管理子系統...134 6.2.1 系統簡介...134 6.2.2 系統分析...137 6.2.3 系統設計...141 6.3 看診輔助子系統...148 6.3.1 系統簡介...148 6.3.2 系統分析...150 6.3.3 系統設計...153

(7)

7.1 測試環境資料... 161 7.1.1 病患基本資料一類... 161 7.1.2 看診紀錄一類... 161 7.1.3 掛號紀錄一類... 162 7.1.4 掛號紀錄與看診紀錄關聯... 162 7.1.5 診所參數... 162 7.1.6 健保相關代碼參數... 163 7.1.7 健保規定藥品疾病... 163 7.1.8 其他自訂代碼... 164 7.1.9 輔助資料一類... 164 7.2 實際運行數據... 165 7.3 使用者需求審核... 166 7.3.1 掛號批價子系統... 166 7.3.2 病歷管理子系統... 167 7.3.3 診療輔助子系統... 167 第八章成果分析與討論 ...169 第九章結論 ...171 9.1 系統規劃... 171 9.2 系統分析設計... 172 9.3 資料庫設計... 172 9.4 開發過程... 173 9.5 測試階段... 174 9.6 尾聲... 175 第十章未來研究 ...176 10.1 背景資料... 176 10.2.相關研究及其優缺點 ... 176 10.3.研究主題及其價值 ... 177

(8)

10.3.2 研究範圍...177 10.3.3 假設條件...177 10.3.4 期望效益...177 10.4.結論...178 10.4.1 研究目的...178 10.4.2 研究與開發的過程...178 10.4.3 主要貢獻...178 10.4.4 進階研究...178 參考資料 ...179 附錄 ...180

(9)

圖表目錄

圖目錄

圖 2. 1 部門人員組織圖 ... 21 圖 2. 2 系統架構圖 ... 22 圖 3. 1 資料庫應用程式發展生命週期 ... 31 圖 4. 1 健保診所管理系統系統功能架構圖 ... 43 圖 4. 2 人員組織架構圖 ... 44 圖 4. 3 建議診所作業流程 ... 45 圖 4. 4 工作場所架構圖 ... 46 圖 4. 5 健保診所管理系統資料流程圖背景圖 ... 48 圖 4. 6 健保診所管理系統資料流程圖圖 0 ... 49 圖 5. 1 概念層設計使用圖形說明 ... 53 圖 5. 2 邏輯層設計使用圖形說明 ... 53 圖 5. 3 醫療系統參與人員架構圖 ... 55 圖 5. 4 實體關聯圖以病患的觀點於邏輯層設計 ... 56 圖 5. 5 實體關聯圖以櫃檯人員的觀點於邏輯層設計 ... 57 圖 5. 6 實體關聯圖以醫師的觀點於邏輯層設計 ... 58 圖 5. 7 實體關聯圖以藥師的觀點於邏輯層設計 ... 59 圖 5. 8 實體關聯圖以管理者的觀點於邏輯層設計 ... 60 圖 5. 9 醫療系統資料架構圖 ... 62 圖 5. 10 實體關聯圖全域觀點於邏輯層設計 ... 63 圖 5. 11 實體關聯圖全域觀點於邏輯層設計區一 ... 64 圖 5. 12 實體關聯圖全域觀點於邏輯層設計區二 ... 65 圖 5. 13 實體關聯圖全域觀點於邏輯層設計區三 ... 66 圖 5. 14 實體關聯圖全域觀點於邏輯層設計區四 ... 67 圖 5. 15 實體關聯圖全域觀點於邏輯層設計區五 ... 68 圖 5. 16 實體層設計實體關聯圖 ... 85 圖 5. 17 病患基本資料 ... 86 圖 5. 18 掛號批價 ... 89 圖 5. 19 看診紀錄 ... 92

(10)

圖 5. 21 健保規定 ... 97 圖 5. 22 健保對照表 ... 99 圖 5. 23 輔助表 ... 102 圖 5. 24 代碼表 ... 104 圖 5. 25 關聯表 ... 107 圖 6. 1 健保診所管理系統系統架構圖 ... 109 圖 6. 2 系統登入狀態圖 ... 110 圖 6. 3 掛號批價子系統系統功能架構圖 ... 114 圖 6. 4 掛號批價子系統資料流程圖 ... 116 圖 6. 5 掛號批價子系統現場掛號狀態流程圖 ... 117 圖 6. 6 掛號批價子系統批價收費狀態流程圖 ... 118 圖 6. 7 掛號批價子系統欠卡補單狀態流程圖 ... 119 圖 6. 8 掛號批價子系統預約掛號狀態流程圖 ... 120 圖 6. 9 掛號批價子系統輸出報表範例批價單及收據 ... 123 圖 6. 10 掛號批價子系統輸出報表範例預約聯絡清單 ... 124 圖 6. 11 掛號批價子系統現場掛號處理流程 ... 125 圖 6. 12 掛號批價子系統批價收費處理流程之一 ... 125 圖 6. 13 掛號批價子系統批價收費處理流程之二 ... 126 圖 6. 14 掛號批價子系統欠卡補單處理流程 ... 126 圖 6. 15 掛號批價子系統預約掛號處理流程 ... 127 圖 6. 16 病歷管理子系統系統功能架構圖 ... 135 圖 6. 17 病歷管理子系統資料流程圖 ... 137 圖 6. 18 病歷管理子系統基本資料維護狀態流程圖 ... 138 圖 6. 19 病歷管理子系統看診紀錄維護狀態流程圖 ... 139 圖 6. 20 病歷管理子系統病歷庫自我維護狀態流程圖 ... 139 圖 6. 21 病歷管理子系統病歷資料分析統計狀態流程圖 ... 140 圖 6. 22 病歷管理子系統基本資料維護處理流程 ... 144 圖 6. 23 病歷管理子系統看診資料維護處理流程 ... 144 圖 6. 24 診療輔助子系統系統功能架構圖 ... 149 圖 6. 25 診療輔助子系統資料流程圖圖 3.1 ... 150 圖 6. 26 診療輔助子系統資料流程圖圖 3.2 和圖 3.3 ... 151 圖 6. 27 診療輔助子系統醫師看診視窗狀態流程圖 ... 152 圖 9. 1 掛號批價子系統視窗程式繼承圖 ... 174

(11)

畫面 0. 3 錯誤訊息 ... 111 畫面 0. 4 健保診所管理系統主畫面 ... 112 畫面 1. 2 掛號批價子系統主框架操作畫面 ... 128 畫面 1. 3 掛號批價子系統現場掛號操作畫面 ... 129 畫面 1. 4 掛號批價子系統批價收費操作畫面_1 ... 130 畫面 1. 5 掛號批價子系統批價收費操作畫面_2 ... 130 畫面 1. 6 掛號批價子系統批價收費操作畫面_3 ... 131 畫面 1. 7 掛號批價子系統批價收費操作畫面_4 ... 131 畫面 1. 8 掛號批價子系統欠卡補單操作畫面 ... 132 畫面 1. 9 掛號批價子系統預約掛號操作畫面_1 ... 132 畫面 1. 10 掛號批價子系統預約掛號操作畫面_2 ... 133 畫面 2. 1 病歷管理子系統主框架操作畫面 ... 145 畫面 2. 2 病歷管理子系統基本資料維護操作畫面 ... 146 畫面 2. 3 病歷管理子系統看診紀錄維護操作畫面 ... 147 畫面 3. 1 診療輔助子系統主框架操作畫面 ... 156 畫面 3. 2 診療輔助子系統醫師看診工作視窗操作畫面 .... 157 畫面 3. 3 診療輔助子系統待診佇列操作畫面 ... 157 畫面 3. 4 診療輔助子系統確定訊息操作畫面 ... 157 畫面 3. 5 診療輔助子系統看診中的畫面操作畫面 ... 158 畫面 3. 6 診療輔助子系統輔助主訴、症狀、檢驗操作畫面 158 畫面 3. 7 診療輔助子系統輔助針灸穴位操作畫面 ... 158 畫面 3. 8 診療輔助子系統輔助傷科處置操作畫面 ... 159 畫面 3. 9 診療輔助子系統疾病與處方輔助輸入操作畫面 .. 159

(12)

表目錄

表 1. 1 研究主題假設條件 ... 18 表 2. 1 目標診所資料 ... 20 表 2. 2 人員組織架構 ... 20 表 2. 3 硬體需求 ... 25 表 2. 4 軟體需求 ... 25 表 3. 1 系統開發生命週期 ... 26 表 3. 2 瀑布模型優缺點 ... 28 表 3. 3 資料庫應用程式發展生命週期各階段說明 ... 32 表 3. 4 正規化五階段 ... 33 表 4. 1 資料需求六類說明 ... 39 表 4. 2 資料需求（Data requirement）總表 ... 40 表 5. 1 資料庫三階段設計說明 ... 51 表 5. 2 資料庫實作設計說明 ... 52 表 5. 3 實體層設計總表 ... 85 表 5. 4 病患基本資料 ... 86 表 5. 5 病患資料 PATIENT ... 87 表 5. 6 病患特殊疾病 PAT_SP_DISEASE ... 88 表 5. 7 病患藥物禁忌 PAT_MED_BAN ... 88 表 5. 8 掛號批價 ... 89 表 5. 9 掛號記錄明細 REG_DETAIL ... 90 表 5. 10 掛號批價資料 REG_CHARGE ... 90 表 5. 11 掛號保險資料 REG_INSURANCE ... 91 表 5. 12 看診紀錄 ... 92 表 5. 13 看診紀錄明細 CURE_DETAIL ... 93 表 5. 14 看診特定治療 CURE_ITEM ... 93 表 5. 15 看診特定治療處置 CURE_ITEM_DEAL_WITH ... 93 表 5. 16 看診症候檢驗 CURE_CHECK ... 93 表 5. 17 看診診斷疾病 CURE_SICK ... 94 表 5. 18 看診處方資料 CURE_MED ... 94

(13)

表 5. 21 診所藥品 CLINIC_MED ... 96 表 5. 22 健保規定 ... 97 表 5. 23 健保規定疾病 INS_SICK_TABLE ... 97 表 5. 24 健保規定藥品 INS_DRUG_TABLE ... 98 表 5. 25 健保對照表 ... 99 表 5. 26 健保對照表_特定治療 INS_TABLE_CURE_ITEM ... 100 表 5. 27 健保對照表_就醫科別 INS_TABLE_FUNC_TYPE ... 100 表 5. 28 健保對照表_給付類別 INS_TABLE_GIVE_KIND ... 100 表 5. 29 健保對照表_案件分類 INS_TABLE__CASE_TYPE ... 100 表 5. 30 健保對照表_部分負擔 INS_TABLE_PART ... 101 表 5. 31 健保對照表_處方調劑方式 INS_TABLE_MED_TYPE ... 101 表 5. 32 輔助表 ... 102 表 5. 33 輔助關聯表_疾病對藥品 HELP_REL_SICK2MED ... 102 表 5. 34 輔助_主訴 HELP_COMPLAIN ... 103 表 5. 35 輔助_症候 HELP_SYMPTOM ... 103 表 5. 36 輔助_病理檢驗 HELP_CHECK ... 103 表 5. 37 代碼表 ... 104 表 5. 38 醫師資料 DOCTOR ... 105 表 5. 39 代碼表_保險種類 TABLE_INS_TYPE ... 105 表 5. 40 代碼表_特定治療項目分類表 TABLE_CURE_ITEM_GROUP 105 表 5. 41 代碼表_掛號狀態 TABLE_REG_STATUS ... 105 表 5. 42 對照表_製造廠 TABLE_MANUFACTURER ... 106 表 5. 43 對照表_供應商 TABLE_SUPPLIER ... 106 表 5. 44 關聯表 ... 107 表 5. 45 關聯表_掛號對看診紀錄 REL_TABLE_REG2CURE ... 107 表 6. 1 掛號批價子系統系統範圍 ... 113 表 6. 2 掛號批價子系統系統功能說明表 ... 115 表 6. 3 掛號批價子系統資料庫設計說明表 ... 121 表 6. 4 掛號批價子系統輸入設計說明表 ... 122 表 6. 5 掛號批價子系統輸出設計說明表 ... 122 表 6. 6 掛號批價子系統輸出報表格式批價單及收據 ... 123 表 6. 7 掛號批價子系統輸出報表格式預約聯絡清單 ... 124 表 6. 8 病歷管理子系統系統範圍 ... 134 表 6. 9 病歷管理子系統系統功能說明表 ... 136 表 6. 10 病歷管理子系統資料庫設計說明表 ... 141 表 6. 11 病歷管理子系統輸入設計說明表 ... 143

(14)

表 6. 13 診療輔助子系統系統範圍 ... 148 表 6. 14 診療輔助子系統資料庫設計說明表 ... 153 表 6. 15 診療輔助子系統輸入設計說明表 ... 155 表 6. 16 診療輔助子系統輸出設計說明表 ... 155 表 7. 1 測試資料病患基本資料一類 ... 161 表 7. 2 測試資料看診紀錄一類 ... 161 表 7. 3 測試資料掛號記錄一類 ... 162 表 7. 4 測試資料掛號記錄與看診紀錄關聯 ... 162 表 7. 5 測試資料診所參數 ... 162 表 7. 6 測試資料健保相關代碼參數 ... 163 表 7. 7 測試資料健保規定藥品疾病 ... 163 表 7. 8 測試資料其他自訂代碼 ... 164 表 7. 9 測試資料輔助資料一類 ... 164 表 7. 10 測試數據掛號方面 ... 165 表 7. 11 掛號批價子系統評估表 ... 166 表 7. 12 病歷管理子系統評估表 ... 167 表 7. 13 診療輔助子系統評估表 ... 167

(15)

自序

資訊發展是為了帶給人們更便捷更舒適的生活環境。目前台灣的醫療資訊管理系統隨著世界潮流及國內健保資訊化制度的影響，正突飛猛進地發展中；所謂系統有大有小，台灣目前的醫療管理系統也概分幾大類： 1. 大型醫療院所之輩：這類的系統是管理整個醫院舉凡掛號轉診，病歷管理，經營管理，人事薪資…等等，成為一完整而封閉的系統，多半是由自設的資訊部門管理。 2. 醫療業務相關：最常見的有藥品進銷存管理，醫療器材銷售管理，醫事藥事諮詢系統，多媒體病歷管理…等等，以提供專業且精確的功能服務，滿足特殊需求。 3. 套裝式系統：這類的系統多包含基本的醫療流程作業所須具備的服務，以中小診所為銷售對象，提供如掛號，收費，看診，配藥，基本財務管理，以及最重要的健保申辦等。這也是目前市場成長最大的資訊應用。 4. 產學界共同研究：由學術界和醫療業界人員共同研究，主要從事醫療環境的改善及導入資訊化於醫療體系為主，非以營利為主，而是著重於利用資訊科技提升台灣醫療品質。而本專題的定位屬第三類套裝式系統，以開發出中小型診所使用的小型管理系統，僅滿足第一線的基本服務，實際上並不能充分發揮出資訊系統強大服務功能的特性，著實有些遺憾，但這是目前能力所及的，也不能強求。未來發展，希望能繼承先進前輩們的腳步，以資訊科技的專業理論技術，應用於改善整體醫療環境，以期不負學校的教育栽培和所學的知識。

(16)

摘要

本專題報告著眼於解決一般中小型醫療診所日常業務的資訊化問題，以提供電子資料處理與資料庫管理的服務為主，這類的系統在目前業界已經是相當普遍的，然而產品仍有優劣之分，造成使用者不便的系統也不在少數。學生依循專案開發的基本步驟，透過瞭解問題，分析、評估、決策以至解決問題的過程，來學習開發經驗與驗證所學知識。本報告架構共分十章，主要依照開發過程順序撰寫，並以大量圖表輔助說明，希冀能以此記載專案開發中的點滴經驗和知識。第一章導論，以介紹研究主題為主，同時簡述目前醫療資訊化情況。第二章系統概述，初步討論系統架構與使用者的目前遭遇的問題，以及解決的方向。第三章系統開發基礎理論，稍微說明如何以在校所學的知識運用於目前專案的開發。第四章系統分析與設計，則藉由開發的說明文件來說明整個系統架構。第五章資料庫設計，以圖文及表格方式說明整個資料庫的開發過程。第六章系統實作，將分析和設計的結果以程式實際撰寫出來，輔以視窗介面以利使用者操作。第七章系統測試與評估，則表列測試資料和使用者審核結果。第八章成果分析與討論，第九章結論，則用自省討論的角度撰寫，同時輔以心得。第十章未來研究，以目前的現況分析，期許自我在學習更多背景知識後能夠從事的研究方向，不再只是解決基本需求問題，而能對大環境的改善有所貢獻。

(17)

第一章導論

全民健保的施行造就醫療管理系統的重大發展。

1.1 背景資料

21 世紀是資訊爆炸的世紀，無可置疑現代生活舉手投足間都是資訊流，而且隨著網路的快速發展，資訊已成平民化的現代產物，只要花點心思，任何資訊都垂手可得。更有人大膽的預言：「現今商業市場中，資訊的提供和管理，將會成為一大商機；能掌握此商機的人，就能掌握 21 世紀。」而在此龐大的資訊市場中，已不乏有先進的企業投入，如下所列： 1. 私人化的資訊管理，電子秘書、通訊錄等。 2. 生活化、大眾化資訊提供，食衣住行育樂資訊查詢等。 3. 公司企業政府機關行政管理，人事薪資系統等。 4. 商業活動資料處理，股市控管、進銷存系統等。 5. 進階應用，專家系統、企業運作系統、交易處理系統等。 6. 其他資訊系統。所有的應用，都脫離不了『提供資訊』和『管理資訊』的範疇，想在這激烈的競爭市場中生存並佔一席之地，必須著眼於以下兩點： 1. What to present 提供有價值、被需要的資訊。 2. How to present 提供更便捷有效率的資訊取得服務。目前台灣實行全民健保，帶動了另一批資訊產業的發展──醫療相關的管理系統，舉凡各種病歷管理、診所管理、藥品物流、健保給付申辦等等都包括在內，這也帶給了各家資訊公司另一商業契機。由（http://www.nhi.gov.tw/01intro/intro_file/2-1.xls）全民健康保險局提供的資料顯示，至民國 91 年八月止全民健康保險特約醫事服務機構共計 16740 家。換句話說，有將近一萬六的立即性市場和隨之衍生的潛在市場，將之稱為台灣 21 世紀的醫療金礦也不為過。也因此，眾多的廠商諸如：「展望亞洲科技股份有限公司」、「杏翔

(18)

公司爭相開發套裝軟體搶食此龐大市場。所以說：「全民健保的施行造就醫療管理系統的重大發展」，一點也不為過。

1.1.1 動機

學生於大二修習「系統分析」時所作之學期報告為「牙醫診所管理系統」，也因此觸摸到此一有趣之醫療管理系統的領域，整合當初研究之牙醫診所和親戚之中醫診所，發覺他們所面臨的問題居然如出一轍，更讓學生想要探究一二。當大三修習【資料庫系統】時，發覺目前的資訊管理系統幾乎都是資料庫的實際應用；換句話說，提供業界服務的資訊系統，其實就是提供資料處理與資料儲存管理的軟體系統。在大學四年間，學得許多資訊專業能力，但多偏重技術導向；老師也曾指出過大部分的畢業學長出社會後幾乎都選擇程式設計師的工作，然而程式設計並不能成為一輩子的工作，而且也很容易被取代，最後必升級到系統分析師或管理階層。既然如此，學生決定先在大學就培養專案開發與管理的能力，增加自己畢業後在就業市場中的競爭力，成為資訊系統開發專案中不可或缺的人物。此專題報告不僅是一科必修課結果，同時也是學生邁向業界挑戰的開始。

1.1.2 目的

實作此專題主要目的，在於增進自己專案開發能力，藉由親身執行資訊系統開發中各階段的工作，來測試目前所具備的知識和技術和評估自己未來研究的方向。另一個目的為，身為資訊人，既然能靠所學解決問題，又何需假手他人而在旁觀看，既然知道問題癥結所在，就盡一己之力徹底拔除問題。大學四年來的學習過程，如果不能對社會有所助益，那不算是教育的成功；一位不能分擔社會工作，解決大眾問題的，也不算是個成功的實業家；唯有發揮所能，協力改善社會現況，才是人類未來的身

(19)

1.1.3 結果

預期目標是完成能功能齊全且可實際運行於現行診所的成品，但依人力及時間的考量，只能先在期限內完成部分重要的子系統，剩下的部分有待未來再繼續努力。

1.2 相關研究

1.2.1 目前業界廠商

大型醫療院所的資訊系統，一般來說為了穩定與安全考量，都採取資訊部門自行研發的策略；相較之下，中小型的醫療診所，則大部分採用各資訊公司所販售的套裝軟體。既然是套裝軟體，自然擺脫不掉套裝軟體的必然缺點：「沒有量身訂做來的順手。」而且，自由市場中，各家廠商接研發、推出自己的產品，良莠不齊，只能靠使用者慎選。涉及此範疇的廠商，透過網路擊可查到許多，諸如： 1. 銓眾科技－－預約掛號管理系統。 http://www.callin.to/wanna/ 2. 展望亞洲－－醫療相關產業產品整合。 http://www.vision.com.tw/ 3. 美斯可－－藥局自動化之管理。 http://www.misc.com.tw/ 4. 杏翔公司－－醫院管理系統。 http://www.these.com.tw/ 還有許多同性質的資訊公司，在此不予詳述。

1.2.2 問題重要性

實際上，醫療管理系統並不單單只是提供資訊化服務來解決傳統作業上的不便，也不僅是提供低階管理工作的功能，只要有創意和縝密的分析設計，其實，還可以做出更大的貢獻。舉例來說，除了一般的掛號看診、藥品庫存和營運管理等等作業

(20)

1. 分析患者病歷，提供未來預防疾病和強化抵抗力的建議。 2. 提供各時期各種類的疾病看診關係，協助院所決策實施醫療行為與人力分佈的方案，也可預知疾病爆發的周期而加以提前準備。 3. 建立自動化智慧化的分析掛號記錄及病歷資料，查出可能的作假與不合理申報資料，藉以防堵醫療資源浪費、不實申報請領補助的情形，解決目前健保政策面臨的最大危機。（雖然可能造成院所客戶拒絕使用的窘境，但此概念也可移到健保局的申報資料審核機制上。）以上種種，只要有創意就會出現更好的解決方式，解決目前醫療保險業務弊病與資源分配的問題。

1.3 研究主題及其價值

1.3.1 題目主旨

以軟體系統開發領域的方法論，實地演練，驗證理想與實際研發的差異。以現有的理論技術為基礎，發展並實作解決醫療工作問題的方法。

1.3.2 研究範圍

主要圍繞在系統分析與設計、資料庫應用、人機介面實作以及些許資料挖掘技術。

1.3.3 假設條件

參數診所規模健保規定病歷人數民眾就診頻率現行環境主治醫師 1 人櫃檯人員 1 人健保 IC 卡明年起試辦 4200 人每月 700 人次每日 20~30 人次假設環境 1 位醫師 1 位藥師 1 位櫃檯人員暫且忽視健保 IC 卡規定，採原申報規定 4500 人每月 900 人次每日 30 人次

(21)

1.3.4 期望效益

希冀此系統能輔助櫃檯人員掛號批價、調閱病歷等行政工作，減輕使用者工作負擔和加速作業流程；輔助醫師看診，增加醫師專注診療患者的時間；解決醫師藥師間傳遞病歷（處方箋）的時間，方便藥師即時開藥；協助經營者藥品庫存管理、健保申報、營運統計以及進階的資料分析以獲取病患看診趨勢。除了對產品使用者業務需求上有所助益，更希望能藉此瞭解醫療系統相關流程和解決問題的步驟，培養專案開發的經驗。

(22)

第二章系統概述

2.1 專案對象

2.1.1 目標診所資料

項目說明診所名稱朱益生中醫診所設立日期民國 73 年 7 月歷史沿革原位於員林鎮中山路 8、9 號，後遷至現址。座落位置員林鎮民權街 43 號看診項目中醫治療，傷科治療，特殊治療門診時段上午 9：00~12：00 下午 14：30~18：00 晚間 19：00~21：00 每日人次 30 人次上下表 2. 1 目標診所資料

2.1.2 人員組織架構

項目說明醫師一名，全職，為前來病患提供治療服務。希望系統協助看診，簡化重複性行為（如填寫病例，決定處方藥品），縮短非醫療行為時間，提供更多時間讓病患諮詢、加速診療效率和提高醫療品質。櫃檯人員一名，處理掛號，協助看診。注重掛號行為之改進，方便的病歷查詢調閱，簡潔的掛號預約處理。藥師一名，為醫師所開出的處方箋抓藥。首重醫師處方之傳遞效率。經營者管理診所營運概況，藥品採購事宜。協助管理診所收支營運，藥品存量和採購需求，健保給付申辦，其他經營概況報表。表 2. 2 人員組織架構

(23)

2.2 系統架構簡介

以下使用「組織圖」來介紹各階層人事及相關業務範疇。管理層院長藥劑部 IT部行政部診療部處理掛號事宜處理預約、複診事宜處理缺卡補卡事宜批價收費新病患資料登錄調閱病歷診療病患開立處方特殊治療依照處方箋配藥列印藥品包裝袋其用要說明掛號總表匯整商業統計報表健保給付申報藥品庫存管理藥廠供應商採購事宜藥師 IT工程師櫃檯人員 (護士) 醫師總務部經理系統維護設定故障排除系統參數更新直接維護資料庫圖 2. 1 部門人員組織圖

(24)

再以組織圖的方式介紹此「醫療診所管理系統」各子系統的名稱及其所負責的作業。健保診所管理系統掛號批價子系統病歷管理子系統藥事輔助子系統健保申辦子系統營運管理子系統系統管理子系統診療輔助子系統掛號批價預約掛號欠卡補卡管理病患個人基本資料管理病患看診紀錄協助看診新增看診紀錄新增處方箋，列印處方箋自定症狀病名關係、病名處方關係、處方藥品關係接收處方箋列印藥事說明設定處方藥品關係彙整當月醫事藥事紀錄表產生申報資料營運統計分析設定藥品資料，紀錄庫存，庫存預警，藥品採購結算，處理當月掛號、批價、看診資料薪資管理資訊設備維護網路架構維護資料庫維護、備份設定系統參數系統更新及最佳化圖 2. 2 系統架構圖

(25)

2.3 初步介紹

2.3.1 問題概述

以專案對象朱益生中醫診所為例，使用著兩三年前設計之系統，而醫療人員對電腦操作和軟體使用又不甚熟悉；不友善的人機介面加上不熟悉的使用者，使得醫療資訊化系統對朱益生中醫診所而言，是一件既費時又無實值效應的作業。該診所平日工作流程如下： 1. 病患上門求診。 2. 護士登記掛號、尋找病歷（傳統作業方式，紙式病歷表）。 3. 護士將病歷遞至醫師處，醫師使得開始診療。 4. 診療結束後，醫師將處方傳至藥師處，藥師開始配藥。 5. 病患接過藥包後，步出診所，醫療行為第一階段結束。 6. 護士將看診結束病患之病歷暫時放至「代處理夾」內。 7. 一天結束看診後，由醫師或護士統一以人工批次處理之方式一一將今日看診病患之資料輸入至電腦中，一日看診之工作方告結束。 8. 月初固定為上個月之看診紀錄作總處理，方傳健保局申請給付。乍看之下似乎很平常，連醫療人員都習以為常；但仔細一看即可發現，相同性質之工作重複的兩次（人工作業和電腦處理交替發生），此一現象增加醫療從業人員額外的工作負擔，也直接抹煞掉資訊化所應帶來的好處。

2.3.2 初步分析

經過初步訪談，大致上整理出以下幾處該診所所面臨之困難和問題： 1. 原醫療管理系統功能太多，徒增操作的困難。

(26)

3. 用電腦幫助掛號，光是輸入就來不及，病患多的時候根本處理不來，用原來熟悉的方式找傳統紙式病歷，不一會兒就找得著。 4. 醫師看診時，把所有精力花在病患上，哪有時間和精神對著電腦慢慢輸入，還不如用手工直接寫在病歷上方便。 5. 為了配合健保局要求，使用了醫療管理系統。當初花費幾萬元，並不方便使用，而且每升級一次又要好幾千元。 6. 月初結算時，將健保給付申請資料做好，送到健保局；有時健保局會抽查，再從電腦中列印出來繳交。這就是此系統最大的用處。 7. 每天都要額外花時間將看診結果和病歷資料輸入電腦，麻煩但又不可避免之工作。上述諸多問題，確實帶來許多阻力而非助力，而醫療管理系統的開發公司和醫療從業人員似乎也面臨著認同這個問題。

2.3.3 初步解決方案

解決前述所提出之問題，和增加醫療人員的使用意願，大致整理出初步計劃： 1. 人機介面簡單化，力求貼近使用者需求，額外的功能端看使用者意願予以顯示或隱藏。 2. 適當的資料備份工作，或依需求轉換成紙本式儲存，免除資料保存安全性疑慮。 3. 教導使用者基本電腦操作，熟悉新的作業方式，不久就可領會新的作業方式帶來的便捷。 4. 掛號行為由電腦輔助，調病例或新增病患資料，就在彈指之間完成。 5. 掛號費、自付額、健保給付款項，皆在批價時自動依據預設值算出，由櫃檯人員做最後檢查。 6. 對病患看診時，此系統亦可協助醫師診斷和製定處方，以方便醫師使用和簡化輸入為要務。 7. 因應網路發展，醫療服務上 WEB 也是潮流，可在診所網頁上掛號、預約，乃至相關醫療諮詢。

(27)

2.4 軟硬體設備需求需求

2.4.1 硬體方面伺服器一台個人電腦客戶端三台個人電腦客戶端供櫃檯人員、藥師及醫師使用。列表機兩台供醫師、藥師及櫃檯人員使用，主要用於報表與收據列印。申報資料列印，紙本式實體備份(Hard Copy)。 IC 卡讀卡機專案開發目前無此硬體表 2. 3 硬體需求 2.4.2 軟體方面項目目前建議未來建議伺服器 Windows 2000 或 XP LINUX 系列客戶端 Windows98 以上 LINUX 系列程式執行環境資料庫端為 Sybase SQL Anywhere 客戶端為 Window 視窗介面 MySQL 搭配 PHP 網頁介面，操作直接透過瀏覽器。表 2. 4 軟體需求 2.4.3 網路方面為加強和病患之間的交流互動，架設專屬網站之必要已無法避免；網頁提供基本預約、掛號相關作業，醫事諮詢…等等功能。需一寬頻網路，及網路實體位址，網頁空間和相關開發環境。

(28)

第三章系統開發基礎理論

3.1 研究開發的理念

以簡單的操作，親和的介面，有效率的資料處理，和提供必要功能為導向。改變將資料庫單純作為儲存工具的一般做法，而加入諸如多功能的查詢、交互運算以及資料整理、決策提供等運用概念，以發揮資料庫的真正貢獻。

3.2 系統開發使用的方法理論

3.2.1 系統開發過程與模型

系統開發生命週期(System Development Life Cycle)是公司用來建立一資訊系統的一系列步驟，在「系統分析」課程仲介紹以下五階段：階段目的和工作工具輸出系統規劃明確辨認問題的性質與範圍問卷甘特圖初步調查報告 Problem Spec 系統分析瞭解現有系統如何運轉和使用者需求，資料和處理的分析。系統流程圖狀態流程圖資料流程圖資料辭典決策樹系統需求紀錄系統分析規格書系統設計規範並完成以下工作：輸出，輸入，檔案和資料庫，系統結構，人機介面設計。資料流程圖資料流程圖資料辭典假碼演算法狀態轉移圖系統設計規格書系統建置程式撰寫，測試，完成說明和操作文件。建置後系統評估。程式開發工具程式原始碼可執行程式說明和操作文件系統評估報告系統運行與支援維護和更新以符合新的需求。更新報告維護報告

(29)

而在「軟體工程」課程所學習的，軟體開發共程中必要的相關活動與產生結果稱之為軟體程式（Software Process），一般而言分成以下四階段（時期）： 1. 發展規格（Software specification）以制式規格文件來記載和說明軟體的功能設計和操作限制等等，相當於系統分析與設計時期。產生的結果文件如：需求分析書、系統分析規格書、系統設計規格書…等等。 2. 軟體開發（Software development）此時，系統依照上階段產生的規格書予以實作，再來所需考量的就屬開發環境實作技術選擇和程式設計的範疇了。相當於系統實作或系統建置時期。 3. 軟體確認（Software validation）除了驗證達到程式執行無誤的正確性外，更重要的是必須符合並滿足客戶的需求。這時期主要的工作稱為測試（test），除了由資深工程師負責測試系統運行正確性、整合一致性外，還必須邀請末端使用者（end user）來測試使用以瞭解客戶的滿意度、系統功能的完成度和使用者介面友善與否。這個階段的不變定律是：「不能滿足客需求的軟體系統，就只是一堆垃圾。」 4. 軟體演進（Software evolution）世上沒有絕對的是非，也沒有不變的事物，客戶的需求亦如是。為了維持滿足客戶多變的需求及跟上政令規定和科技潮流，軟體系統也必須不斷的演進變化。這個階段又稱為維護時期（maintain）或「系統支援與運行工作」，以隨時支援客戶需求為第一要務。至於這個階段的工作要屬於售後服務或有價更新，端看軟體開發公司的商業文化以及合約內容。但根據市場慣例，這階段的活動通常才是軟體公司主要收入來源。其實，這兩種規劃並非絕對性，只是著眼點以及開發系統範圍大小的差異，在這次的系統開發中，也同時運用這兩種開發階段的時程規劃，分別運用於個別子系統開發和診所管理系統開發上。而在軟體開發流程模型（Software Process Model）中，本專案共採用三種模型方案，「瀑布模型（Waterfall Model）」、「演化模型（Evolutionary Development）」和「螺旋開發（Spiral Development）」，於下頁中

(30)

3.2.1.1 瀑布模型（Waterfall model）

以優缺點來介紹瀑布模型：優點缺點統一的步驟，嚴謹標準的開發程式。確保開發的系統品質。每一階段完成後，才能進行下一階段。系統沒開發完成前，看不到成果。提供良好專案管理控制。如有某一階段錯誤，可能導致專案重新來過。清楚階段劃分，易於分工和管理。一但某一階段工作無法如期完成，將導致後續階段工作停擺。系統開發人員可選擇熟悉適合的工具、方法來進行系統開發。並透過各階段輸出文件來互相溝通。過多的紙上模型和工具，可能造成額外的負擔和溝通上的誤解。表 3. 2 瀑布模型優缺點選擇原因：針對本系統開發而言，已有眾多現存系統可以參考，主要目的為重新實做並改進原系統。此外，因原系統已運行多年，使用者需求已大致定型，減少因額外需求造成重新開發的問題。以階段性的開發流程步驟，清楚地定義目前該從事的工作及應有的結果，如果開發小組配合得宜，即可確保開發的系統品質。在本專案中主要用於整個系統的規劃設計，作業範疇區分，功能服務歸屬和各子系統交互關係溝通介面上；簡而言之，凡是牽涉到整個系統的主題，不論是一致性或是整合問題，皆需要通盤的考量與遠見，這也是「瀑布模型」最主要的優點。

(31)

3.2.1.2 演化模型（Evolutionary Development）

演化模型即是在「開規格（Specification）」、「發展（Development）」和「確認（Validation）」三項活動中不斷的來回交替執行，藉以發展出切合需求的程式與清楚明確的問題解決方案。演化模型包含兩種形式，如以下介紹： 1. 勘探發展（Exploratory Development）以試探性的手法，將服務功能由小到大的漸進組合而成，不斷地擴張需求帶動不斷地演進，產生最後符合使用者需求的系統。 2. 拋棄式雛型發展（Throw-away Prototyping）以一代代的程式雛型來引導出使用者的潛在需求，藉以定義出更精確的系統需求規格﹔著重於查證出使用者自身也不明的需求。而其最主要的缺點則有以下三點： 1. 無整體性的說明：對於迅速又頻繁的演進頻率，難以要求對每一代的發展皆撰寫說明文件，導致整個開發過程的紀錄不祥，造成無法詳細瞭解開發過程所留下的經驗與知識。 2. 系統架構混亂難以理解：每次的演進，不僅只是提升功能切合性，同時也造成了架構的混亂而無法保持一致性，導致系統最後整合的困難。 3. 需要專門的技術與開發平臺：開發平臺要能提供可快速發展的環境，通常只有某些特定的工具以及技術支援。基本上，是適合中小型系統開發使用。而本專案中，主要採取此演化模型於操作介面設計和子系統個別功能方面，一來可以持續試誤性的開發，二來也因範疇小而不易有整合方面的問題產生。

(32)

3.2.1.3 螺旋開發（Spiral Development）

由四階段行為模式組合而成：目標設立（Objective setting）、風險評估和削減（Risk assessment and reduction）、發展與確認（Development and validation）、計畫決策（Planning），以一再地循環此迴圈來開發出近乎無誤的系統。明確的風險考量是它與眾不同的地方，藉著不斷循環來一再提高系統的可靠性和使用價值，同時降低外部風險的影響。而風險的主要起因不外乎以下幾點： 1. 技術風險：開發平臺變換、現行技術已退流行和新崛起的技術風潮等。 2. 人員風險：開發團隊人員間的整合問題與穩定性，和關鍵人物的去留。 3. 組織風險：開發公司的營運問題，專案移轉 4. 專案發展：進度延遲，成本驟升等。「螺旋開發」是針對範圍較大、複雜度較高以及風險較大的系統開發之用，憑藉不斷的輪循四個階段來進行專案，持續的小量驗證以有效的降低風險，對於使用者需求導向的系統開發而言，是最佳的開發模式。雖然「螺旋開發」擁有許多優點，但本專案礙於時間與人力考量上，並無法徹底執行此反覆的發展過程，更切確的說法是，能走完一圈（輪）就算理想了。

(33)

3.2.2 資料庫應用程式發展生命週期

理論簡介資料庫系統是資訊系統中的一個基礎元件，傳統系統分析設計是將其併在系統設計中的一環，但隨著時代變遷資訊需求複雜化，資料庫的分析設計也隨之自成一重要的環節，也產生一獨立的分析設計方法論。 D atabase planning System definition R quirem ents collection and analysis

C onceptual design Logical design Physical design A pplication D B M S selection Prototyping Im plem entation

D ata loading and conversion Testing O perational m aintainance D atabase design 圖 3. 1 資料庫應用程式發展生命週期

(34)

而此「資料庫應用程式發展生命週期」，主要包含 11 個階段，由下表介紹：階段工作輸出資料庫規劃 Database planning 組織人員，選擇開發工具，定義各階段相關工作，可行性評估。工作分配表甘特圖系統定義 System definition 界定資料庫程式的應用範圍，使用者族群。組織圖功能圖需求收集和分析 Requirements collection and analysis 詳述使用者需求，資料規則，處理方式，輸出輸入的要求。問題規格書需求規格書資料庫設計 Database design 包括 Conceptual, Logical, Physical design 實體關係圖資料庫欄位規格書選擇資料庫管理系統 DBMS selection 選擇適宜的 DBMS，以符合設計需求和程式撰寫環境。 DBMS 的規格說明選擇原因說明應用程式設計 Application design 建立使用者介面，以及使用和處理資料庫的應用程式。演算法假碼程式碼雛型化（建立雛型） Prototyping 建立雛型供設計者及使用者測試和評估該系統將來的應有功能和操作介面。供評估的程式雛型建置 Implementation 建立資料庫表格，資料規則，SQL code，使用者介面和應用程式。可執行程式建置完成之資料庫資料轉換和載入

Data conversion and loading 將舊系統的資料轉移載入到新系統，調整資料符合新系統的規則。測試 Testing 資料處理正確性，效率和是否符合需求。測試紀錄操作維護 Operational 監控和維護，機動更新以符合新的規則和需操作說明維護紀錄

(35)

3.2.3 資料庫的正規化

目前現行的資料庫系統多為關連式資料庫（Relational Database），而為了精準正確無誤地表示資料及其關係，產生了正規化（Normalization）的方法論，來降低資料重複性，評估並修正資料表格（Table）和關係（Relation）。換言之，透過正規化使得關係規則（Relational Schema）成為特定型式，來防止可能發生之更新的異常現象（Update Anomalies）。目前發展出來的正規化為以下所列五階段為主：正規劃程度規則說明１ＮＦ表格中所有欄位元都是單一值（atomic，純量）。２ＮＦ所有非主鍵欄位都完全功能相依（Fully functional dependent）於主鍵。３ＮＦ表格中沒有遞移相依（Transitive dependency）的情形。ＢＣＮＦ表格內的決定子（Determinant）都是候選鍵（Candidate key）。４ＮＦ消除表格內多值相依性（Multivalued dependency）。表 3. 4 正規化五階段雖然正規化發展到第五正規化，但一般業界資料庫大多只達到第三或 BC 正規化，除非有特殊需求才發展到第四正規化，而第五正規化則更趨於理論化而鮮少應用於實務上。

(36)

3.3 資料庫方案選擇

此外，資料庫應用程式架構的，也隨著時代及電腦科技演進，發展出以下三類： 1. 傳統 Main-Frame 架構終端機只負責作資料的輸入與輸出，所有資料處理都必須集中在同一台主機。 2. 兩層式（2-Tier）Client-server 主從架構改進主機負擔過重及價格昂貴等問題。由伺服器上讀取資料至客戶端做運算處理，當資料處理完畢後，再將資料存回伺服器。 3. 多層式（Multitier）架構解決客戶端應用程式管理與維護上的困難。將原來在客戶端執行的邏輯運算處理部份獨立出來到應用程式主機（Application Server），同時更加強了資料安全性的考量。資料庫管理在資訊系統中佔有非常重要的地位，資料庫的分析和設計也因為電腦科技演進、資料複雜化和特殊資料運算需求，漸漸脫離傳統系統設計的範疇而自成一門學問，也衍生出資料庫自行的開發流程。「資料庫應用程式發展生命週期」傳承了「軟體生命週期」的層級分工外，資料庫設計的三步驟概念層、邏輯層、實體層設計

（Conceptual, Logical, Physical design）更是現行資料庫發展最有效的方法，依其規則建好實體關聯模型（ER Model），將之化成關係（Relation）和實體表格（Table），則已符合第三正規化，甚至是 BC 正規化（BC Normal Form）。此專案考量之，資料的複雜度和資料處理運算的需求並不特殊困難，故以「資料庫應用程式生命週期」為開發方法已符合需要，且工作環境為中小型診所，資料庫及資料處理規模不大，在成本和實際需求考量下，選用兩層式的主從架構就很適宜了。

(37)

第四章系統分析與設計

4.1 初步調查報告書

4.1.1 瞭解問題

改善傳統作業與電腦化作業的衝突與合作關係，減輕醫療從業人員操作的工作複雜度，並提供更便捷的電子資料處理服務。

4.1.2 確認專案範圍與限制

專案定位於中小型診所，產品使用目標為符合現行健保體制需求及使用者實際業務協助，使用者定位為診所內部之櫃檯人員、醫師、藥師、管理階層和 IT 人員。以提供醫療從業人員行政工作和醫療協助為第一優先。專案開發及實作時期，健保 IC 卡的政策尚未試行，且學生無法取得相關詳細規格及軟硬體，故此專案開發之系統暫不支援 IC 健保卡。

4.1.3 確認效益

評估傳統作業與加入電腦輔助作業的差距，主要集中在以下幾點： 1. 利用資料庫查詢，減少尋找和調閱病歷的時間。 2. 使用電子資料儲存方式降低傳統紙式病歷的收藏成本，並提高資料保存的可靠度。 3. 將繁瑣又單調的批次慣例作業和計算工作交由電腦程式代為處理，減少行政人員的工作負擔並加強資料數據正確性。 4. 銜接醫療相關體系的電子化策略，降低來往資料的轉換工作成本。以上幾點所提供的服務方針，將徹底改善尚未進化到資訊化處理或未完全轉移電子化的醫療診所工作效能，以及降低醫療行為外的工作複雜度。此外，附加目標為加入更人性化智慧型的醫療輔助概念，提供輔助看診、給藥、以及相關數據統計和提示功能。

(38)

4.1.4 估計時間與成本

目前專案由一人扮演專案經理、系統分析師、系統設計師、程式設計師以及資料庫管理人員，而相關資料來源由專案對象、中央健保局網站，及相關醫療系統開發廠商的網站資料取得。專案時限初定為一年，採漸進式發展，先著手開發基本功能，滿足第一線需求後再評估所剩時間及人力發展進階應用。開發環境所需成本不計，因使用試用版的開發軟體及 Case 工具，不同於現行廠商需先花費建構開發環境的成本。

4.1.5 提交管理階層評估決策

由專案經理評估並予以分析設計，開始集結相關技術人員共同協力開發。

(39)

4.2 使用者需求報告書

此報告書僅以概略性述說整體健保診所管理系統的使用者需求分析，詳細的系統功能將留待各子系統的報告書中再說明。

4.2.1 輸出

1. 掛號資料：當日掛號總表，隔日預約掛號清單，備查掛號歷史資料。 2. 病患資料：病患個人基本資料，昔日看診紀錄，治療與服藥紀錄。 3. 金流資料：批價表單，診療金額明細，營收統計數據。 4. 物流資料：藥品器材庫存及採購清單，藥品明細和藥廠資料。 5. 審查資料：全民健保申報所需資料及報表。 6. 輔助資料：協助診療及處方開立的提示資料。

4.2.2 輸入

1. IC 卡：目前無讀卡機與相關資源可供分析設計研究之用。 2. 健保局相關規定：補助給付之藥品清單、國際疾病病碼等，可用資料庫轉換的方式或透過自行設計的轉換程式輸入；必要時由 IT 人員手動輸入。 3. 病患病歷資料：除少部分需自行輸入外，盡量採用自動提示選擇的方式減少使用者文字輸入工作。 4. 金額、營業數據等：由選取和系統自動運算所得為主。

4.2.3 過程

過程請直接參照系統分析書中的資料流程圖和狀態流程圖，在此不再贅述。

(40)

4.2.4 時間安排

1. 掛號批價作業為處理當天看診掛號事宜，每日約 30 人次。 2. 初診病患需新增病患資料（病歷中的基本資料），發生頻率不高。 3. 月底檢查一次當月批價掛號資料，並且轉換成健保申報的資料格式，至少一個月一次，也可隨意抽查。 4. 病患病歷每月檢查一次，將超過一年內未就診的病患資料移至歷史檔，固定一個月一次。 5. 藥品庫存一但超過預警數量，即時報告低存藥品的項目及數量。

4.2.5 控制

1. 醫師於診療室操作，系統主要作為病歷紀錄與醫療輔助之用。 2. 藥師於領藥處操作，系統主要作為藥方配製與處方箋用藥說明列印之用。 3. 櫃檯人員於櫃檯（掛號處，批價處）操作，系統主要作為掛號登記批價結算，以及印製報表之用。 4. 經理於辦公室操作，系統主要作為營運相關金額計算，健保申報資料審查與製作，藥品庫存管理之用。 5. IT 人員無限制場所，系統主要作為系統維護，程式更新，資料庫維修備份，系統參數更新之用。

(41)

4.3 資料需求規格書

本報告書為提供系統設計之用，以說明資料實體的交互關係為主。由系統分析師和資料管理師撰寫，交由系統分析師、資料管理師、系統設計師、資料庫管理師、資料庫設計師及使用者閱讀。依照各子系統的資料需求分成六大類，由下表敘述說明：分析資料儲存體作業性質主要範疇相關人員外部實體作業領域相關報表掛號批價掛號作業批價作業印製掛號單印製批價單印製預約清單印製待補卡清單櫃檯人員民眾掛號總表批價總表個人掛號單個人批價收據明日預約聯絡清單待補卡清單病歷病歷管理調閱病歷櫃檯人員看診醫師個人基本資料表看診紀錄明細診療協助看診編寫看診紀錄看診醫師病患病歷（看診紀錄）協助診療選單處方箋藥品協助藥品配製印製藥品說明藥師診所藥品清單健保申辦處理健保申報申請給付業務管理者經理門診處方及治療明細檔門診處方醫令明細檔門診費用申請總表主檔營運管理營運資料藥品庫存管理者經理藥品庫存管理清單表 4. 1 資料需求六類說明

(42)

接著，再詳細描述各資料實體（報表）的性質、作用與需求。分析表單名稱意義作業需求主要資料群組使用頻率附註掛號總表紀錄診所當日掛號作業，每一筆看診作業都應對應一筆掛號作業。掛號資料保險資料批價資料醫療明細一天一份存於電子式媒體中，透過電腦來操作，也可印製簡表。批價總表計算診所當日批價作業，每當掛號看診結束後，皆須執行批價作業，一方面為計算醫療費用，二方面為提供日後健保申報相關資料。同上一天一份批價總表也就是掛號總表，只是在不同作業下名稱不相同。個人掛號單民眾完成掛號手續後可由櫃檯處取得一個人掛號單，其上詳註如診別序號等名眾應知的掛號訊息。掛號資料一人一份民眾可選擇是否索取。個人批價收據民眾結束看診後，至櫃檯完成批價作業和繳費動作，將可領取一張個人批價收據以資存查。掛號資料保險資料批價資料醫療明細一人一份民眾可選擇是否索取。明日預約聯絡清單每日固定產生一份明日的預約清單，提供櫃檯人員聯絡電話提示有預約民眾。預約名單聯絡電話一天一份只有醫療相關人員可取閱。個人基本資料表民眾初次前往診所就醫時，必填寫基本資料表以作紀錄，留存診所內。私人資料一人一份只有醫療相關人員可取閱。表 4. 2 資料需求（Data requirement）總表

(43)

分析表單名稱意義作業需求主要資料群組使用頻率附註看診紀錄明細每次看診後，必產生一份看診紀錄，存於診所內部，可供診所處理及民眾查詢。看診資料症狀檢驗醫師處置疾病診斷處方資料每次看診一份只有醫療相關人員以及患者本身可取閱。病患病歷（看診紀錄）提供醫師看診時，病患的昔日看診紀錄。同上醫師看診需要時看診紀錄明細簡化版。協助診療選單提供醫師看診相關協助，簡化醫師於診療時的電子化作業，提高診療品質與效率症狀診斷治療處置疾病判定處方開立醫師看診需要時處方箋於看診結束後，由「看診紀錄」中的「處方資料」整理出的「處方箋」，交由藥師來配製藥品。藥品資料數量服用資訊每份開立的處方電子式資料或列印出的表單。診所藥品清單提供診所目前所有的藥品其代號和名稱，供醫師開藥、藥師給藥之用。藥品資訊一份，動態更新由藥品庫存管理清單中節錄資訊出來。門診處方及治療明細檔屬健保給付申請文件每月一份門診處方醫令明細檔屬健保給付申請文件每月一份門診費用申請總表主檔屬健保給付申請文件每月一份於健保申辦子系統系統分析書中再詳加說明。藥品庫存管理清單儲存清單、單價、庫存數量、聯絡藥廠等等。藥品資訊庫存資訊藥廠資訊一份，動態更新提供醫師開藥，藥師給藥，以及藥品庫存等資料管理。表 4.2 資料需求（Data requirement）總表（續上表）至此，至於詳細的各表單說明，將列於附錄供對照。

(44)

4.4 醫療診所管理系統分析設計書

4.4.1 系統簡介

1. 系統簡述此系統以資料庫為主要核心開發出相關的應用軟體，將醫療診所相關工作人員行政工作複雜度減低以及輔助看診給藥等醫療行為。 2. 系統目標設計的基本理念為各子系統清楚分工處理各自領域的工作，配合適當的資料流與資料轉移介面達到統合的目的。明確的工作分界可強化本系統的系統特性並易於對個別子系統維護與除錯。第一階段為病歷管理與掛號批價作業等系統功能。第二階段為輔助看診與協助藥物管理等系統功能。第三階段為健保給付申請與營運管理等系統功能。第四階段為建構診所內部網路架構與架設網站提高和病患的互動。 3. 系統範圍工作場所為中小型醫療診所，使用者為櫃檯人員、醫師、藥師、經理及 IT 人員。系統服務以醫療相關工作為主，診所營運等為附加功能。考慮到性質不同的工作人員對於電腦操作的需求不同，故對系統服務功能的設計也得予以不同設計考量，如櫃檯人員操作以簡單步驟為目標，醫師藥師則因作業需要而有稍繁重的操作技巧及專業需求，對於經理則以提供統計資料、協助決策、管理物流金流等資料管理與報表印製為主，而 IT 人員基於資訊專業知識，操作則無需因考慮簡潔而導致功能不全。

(45)

4. 系統主要功能以系統功能架構圖來說明，如下圖健保診所管理系統掛號批價子系統病歷管理子系統藥事輔助子系統健保申辦子系統營運管理子系統系統管理子系統診療輔助子系統掛號批價預約掛號欠卡補卡管理病患個人基本資料管理病患看診紀錄協助看診新增看診紀錄新增處方箋，列印處方箋自定症狀病名關係、病名處方關係、處方藥品關係接收處方箋列印藥事說明設定處方藥品關係彙整當月醫事藥事紀錄表產生申報資料營運統計分析設定藥品資料，紀錄庫存，庫存預警，藥品採購結算，處理當月掛號、批價、看診資料薪資管理資訊設備維護網路架構維護資料庫維護、備份設定系統參數系統更新及最佳化圖 4. 1 健保診所管理系統系統功能架構圖 5. 系統軟硬體需求硬體：讀卡機（現無硬體支援，暫略），雙硬碟，列表機軟體：作業系統 Windows 平臺，資料庫後端程式(SQL Anywhere) 6. 系統設計限制條件硬體方面無讀卡機可供使用，暫時考量為忽視 IC 卡。軟體方面，SQL Anywhere 為版權軟體，架構 Client Server 有困難。

(46)

4.4.2 現況分析

1. 組織與職務分析以組織架構圖予以說明，見下圖：管理層院長藥劑部 IT部行政部診療部處理掛號事宜處理預約、複診事宜處理缺卡補卡事宜批價收費新病患資料登錄調閱病歷診療病患開立處方特殊治療依照處方箋配藥列印藥品包裝袋其用要說明掛號總表匯整商業統計報表健保給付申報藥品庫存管理藥廠供應商採購事宜藥師 IT工程師櫃檯人員 (護士) 醫師總務部經理系統維護設定故障排除系統參數更新直接維護資料庫圖 4. 2 人員組織架構圖

(47)

2. 建議現行作業流程以下以作業流程圖和工作場所分配圖來表達作業流程。配合系統主要需求，著重於民眾看診的作業流程。掛號作業批價作業看診給藥看診民眾等待看診要求掛號掛號完成排隊等候等待領藥看診結束排隊領藥等待批價領藥完成排隊批價批價完成新增病歷初次就診新增完成病人看診結束離開登記預約時段預約掛號預約成功結束離開完成預約圖 4. 3 建議診所作業流程

(48)

以作業流程搭配上工作場所架構圖加強說明： 1. 民眾先至櫃檯處辦理掛號作業。 2. 至待診處等待看診順序輪至自己的掛號序號。 3. 等櫃檯人員呼叫到自己的號碼後前往診療室接受治療。 4. 至櫃檯窗口完成批價繳費動作。 5. 至藥劑部領藥口領藥。 6. 民眾看診行為結束，此為醫療行為的基本流程。櫃檯掛號作業批價作業藥劑部領藥口藥櫃診療室特殊治療室待診處圖 4. 4 工作場所架構圖

(49)

4.4.3 資訊描述

1. 資料流程圖下頁背景圖（圖 4.5）為突顯本系統與外界實體的資料交流情況，由圖中可看出此系統中計有病患、櫃檯人員、醫師、藥師、經理、藥廠、中央健保局以及 IT 人員共 8 種外部實體，16 條概略的資料流。在此處所指定的資料流名稱皆為代表性的資料項，待分析至各子階段時才會一一細分。資料流程圖之圖 0（圖 4.6）為背景圖中「Process 0 醫療診所管理系統」的拓展，此時不僅顯示外界實體和系統的關係，更將系統以功能化區分為七大子系統，著明瞭外界實體、各子系統以及 data store 間的互動關係。 2. 資料流描述留待各個子系統規格書再詳加敘述。 3. 資料元素描述留待各個子系統規格書再詳加敘述。 4. 資料庫描述於資料庫設計再詳加敘述。 5. 資料結構圖留待各個子系統規格書再詳加敘述。 6. 系統與外界介面說明留待各個子系統規格書再詳加敘述。

(50)

Factory 藥廠 BNHI 中央健保局 Attendant 櫃檯人員 Doctor 醫生 Dispenser 藥師 Manager 經理 0 健保診所管理系統 df_1 健保卡基本資料 df_2 看診結果適當醫療掛號序號批價收據 df_9 藥品清單購買收據 df_10 藥品訂單 df_12 申報資料 df_11 審核結果 df_3 掛號批價操作 df_4 掛號表批價單 df_13 金額變數 df_14 營業相關統計報表 df_6 醫令診斷 df_5 輔助看診資料 df_7 使用設定 df_8 開藥明細 df_15 系統參數 df_16 系統報告健保診所管理系統背景圖 Background Diagram Patients 病患 IT IT人員圖 4. 5 健保診所管理系統資料流程圖背景圖

(51)

開藥明細 Dispenser 藥師健保卡 Patients 病患申報資料 BNHI 中央健保局使用設定診斷 Doctor 醫生掛號批價操作 Attendant 櫃檯人員審核結果輔助資料掛號表批價表 1 ---掛號批價子系統 2 ---病歷管理子系統 3 ---診療子系統 4 ---藥事子系統 5 ---健保申辦子系統 6 ---營運管理子系統 7 ---系統管理子系統 ds_1 掛號批價資料儲存體 ds_2 病歷資料儲存體 ds_4 藥品資料儲存體 ds_3 診療資料儲存體 ds_5 健保申報資料儲存體 ds_6 營運資料儲存體基本資料查詢的掛號資料待寫入的掛號資料掛號序號批價結果待寫入的病例預讀取的病歷新增的看診紀錄調閱的病歷提示選項診療建檔資料 IT IT人員系統設定系統回報處方箋看診紀錄藥事紀錄單月掛號資料整理完成的報表藥品使用量庫存資料備查申報資料藥品訂單 Factory 藥廠藥品清單購買收據營業相關統計報表 Manager 經理細目資料藥品建檔資料藥品進貨數量營運設定備查資料原始申報資料圖 4. 6 健保診所管理系統資料流程圖圖 0

(52)

4.4.4 表單分析

1. 輸入單據分析 2. 輸出單據分析 3. 輸入輸出表單交互參考圖留待資料需求分析和子系統設計中再加以詳述。

4.4.5 功能描述

留待各子系統設計中再加以詳述。

4.4.6 系統確認標準

系統功能由未來使用者親自測試以瞭解是否切實符合需求。使用者介面由非開發人員及未來使用者測試以瞭解操作是否順手。健保補助申報部份交由中央健保局提供的申報資料檢查程式給予測試。

(53)

第五章資料庫設計

資料庫設計階段採用實體關聯資料模型（Entity-relationship Data Model）為理論基礎，依其三階段設計來分析實作，三階段中主要工作說明如下：階段名稱工作輸出概念層設計以個別使用者的觀點來看待資料實體與關係，此時設計與資料庫管理系統或應用程式完全無關，單純表達實體與關係以供後續階段分析。資料需求交易需求實體關聯圖實體型態定義關聯型態定義實體屬性定義實體屬性值域定義邏輯層設計將概念層設計階段的實體關聯表示轉換成資料庫的邏輯結構，此時設計有許多準則可供參考，如正規化等。正規化過程實體關聯圖實體關係屬性描述與定義實體關聯表實體層設計將概念層設計階段的輸出，實體關聯表，依資料庫規劃、程式設計以及商業文化的考量，將其轉換至最後型態，以 SQL 指令表示，並須描述資料存取方法和讀取效率設定。實體關聯圖 SQL 指令操作各表格鍵值設定、限制條件與索引設定。表 5. 1 資料庫三階段設計說明

(54)

然而，在此份規格報告書中，為求簡化報告轉寫與實作方便上，如已在『資料需求規格書』中出現的資料將不再予以重複敘述，分析過程也將會更加簡潔流暢。此份文件撰寫大概如下表所述階段名稱工作輸出概念層設計區分各使用者的觀點，對資料的需求。實體關聯圖實體關聯圖_局部觀點實體關聯圖_全觀邏輯層設計將概念層設計階段的實體關聯表示轉換成資料庫的邏輯結構，以降低資料重複性和更新異像為主。正規化過程實體關聯圖_全觀實體層設計考量獨特的商業文化、交易需求和處理效率，對以上表格予以重新規劃。實體關聯圖 SQL 指令操作各表格鍵值設定、限制條件與索引設定。表 5. 2 資料庫實作設計說明

(55)

附註

本章規格書中使用大量實體關聯圖，在此先說明所使用圖示的意義。

強實體 The strong entity

Independent

弱實體 The weak entity

Dependent 關係 Relationship 主鍵屬性 Primary Key Attribute 弱關係 Weak relationship 多重值屬性 Multi-value Attribute 屬性 Attribute 圖 5. 1 概念層設計使用圖形說明關聯Relationship1 關聯Relationship_2 實體Entity1 實體Entity2 實體Entity3 強實體弱實體一對一 Total 多對一 Partial 圖 5. 2 邏輯層設計使用圖形說明

(56)

5.1 概念層設計書

在概念層設計中，最主要的工作是以實體關係圖表現出現實世界中的實體關係和交易關係，重點在表達各個使用者對資料的需求與觀點，以及定義重要的實體和關係型態。在此是採用使用者觀點的局部觀點和資料觀點的全域觀點來描述和分析，且為了簡化規格書撰寫，將部份工作移到邏輯層時再詳加敘述。基本上，概念層資料庫設計依循以下法則步驟來進行：建立各使用者觀點的局部概念層模型步驟 1 界定實體型態步驟 2 界定關係型態步驟 3 界定並整合實體或關係型態的屬性步驟 4 確定屬性的值域步驟 5 確定主鍵與候選建的屬性步驟 6 對實體型態作特殊化或一般化步驟 7 繪製實體關係圖步驟 8 重新檢視每個使用者的局部概念層資料模型但為了報告撰寫的簡潔，故省略繁雜步驟說明，直接陳述階段性設計結果。

(57)

5.1.1 以使用者觀點來介紹實體與關係

醫療系統健保診所醫師藥師櫃檯人員管理者病患圖 5. 3 醫療系統參與人員架構圖在整個醫療系統中，主要的參與者可分為 1. 病患，就診的民眾，提供和接收自身相關的醫療資訊。 2. 櫃檯人員，掛號批價業務人員，掛號批價等工作所需的資訊。 3. 醫師，看診的大夫，以診斷相關資料和病患的病歷為主要資料需求。 4. 藥師，處理藥品配製的人員，以處方箋和用藥說明為主要資料實體。 5. 管理者，經營管理整個醫療系統的運作，需要營運相關的數據報表。

(58)

5.1.1.1 以病患的觀點

1 病患留於診所 1 病患病歷接受醫療看診記錄 1 1 記錄 M 1 掛號紀錄登記掛號 M 1 計算 1 批價收據 1 排列看診佇列 M 1 藥品領取藥品 N M 疾病診斷疾病 N M 個人基本資料 1 圖 5. 4 實體關聯圖以病患的觀點於邏輯層設計病患在就醫過程中同時扮演著資訊提供者和接收者的角色，會涉及掛號批價作業、看診治療和領取藥品等部份，因此，病患這個外部實體在整個系統中同時也扮演著強實體的地位。

(59)

5.1.1.2 櫃檯人員的觀點

1 病患留於診所 1 病患病歷看診記錄記錄 M 1 掛號紀錄登記掛號 M 1 計算 1 批價收據 1 排列看診佇列 M 1 處方箋包含 N M 診療過程 N 個人基本資料 1 配製藥品 N M 1 圖 5. 5 實體關聯圖以櫃檯人員的觀點於邏輯層設計櫃檯人員主要負責病患的掛號作業以及批價收費，在新病患到來時新增該病患的病歷（基本資料）；關於掛號批價與看診紀錄的關係，基本上是一對一的關係，然而，櫃檯人員並無牽涉到看診的作業，只能藉借處方箋資料來決定批價費用。

(60)

5.1.1.3 以醫師的觀點

病歷 1 1 記錄看診紀錄 M 1 藥品名稱開立 M N 疾病名稱診斷 N M 治療名稱接受 N 症候檢驗 N 基本看診資料登記 1 M M 1 病患留於診所個人基本資料 ₁ 圖 5. 6 實體關聯圖以醫師的觀點於邏輯層設計醫師在系統中的扮演的角色只是個單純的醫療提供者，對於諸如掛號批價或健保申辦的業務應不予理會，同時，因為對直接面對面對病患進行治療，所以病歷（或看診紀錄）在醫師眼中有著不同的詮釋方式。

(61)

5.1.1.4 以藥師的觀點

處方箋看診紀錄診所現有藥品藥廠經銷商開立 M 1 M 消耗 N 購買自 M 1 健保用藥品項符合規定 1 1 用藥說明印製 1 1 圖 5. 7 實體關聯圖以藥師的觀點於邏輯層設計藥師在整個醫療體系中，扮演著最後作業的角色──依照處方箋調配藥品。上述為一般醫藥分業診所的情況，然而，健保局規定中允許中醫師親自調劑；因此，在大部分的小型中醫診所中，並無藥師這個體制（本專案的對象即是如此），然而，為了增加系統的一般性，仍然把藥師因素加入。

(62)

5.1.1.5 以管理者的觀點

掛號表經過看診 1 1 醫事收費藥事收費 1 M 1 1 M 醫療明細紀錄 M 1 病患登記掛號接受醫療 1 1 M 看診紀錄 M 對照醫療費用 1 處方用藥 M 對照藥品費用 1 1 醫療費用索價 1 索價掛號手續 M 掛號收費對照掛號費用 1 1 批價表批價收費 1 1 索價 1 1 圖 5. 8 實體關聯圖以管理者的觀點於邏輯層設計

(63)

診所現有藥品藥廠經銷商購買自 M 1 健保用藥品項符合規定 1 1 藥品存量記錄數量 1 1 掛號表保險資料登記 1 1 健保給付申請書彙整健保申請 1 M 月營業報表每月整理 M 1 圖 5.8 體關聯圖以管理者的觀點於邏輯層設計（續上圖）管理者著重於診所的經營狀況和醫療人次金額等相關數據，以及月營業報表和健保給付申請報表。因此，對掛號紀錄和病歷（或看診紀錄）有著不同的認知和需求；也必須處理藥品的庫存控制和採購相關的業務，所以關於藥品的資料需求也不同其他人員。

(64)

5.1.2 以資料觀點來介紹實體與關係

醫療系統健保診所醫事藥事病患病歷健保申辦掛號批價圖 5. 9 醫療系統資料架構圖而主要的資料表格，有以下數項： 1. 掛號批價，及其衍生的掛號單、批價收據…等等。 2. 病患病歷，包含病患資料和看診紀錄等。 3. 醫事相關的資料表，如病碼、治療項目規定之類。 4. 藥事相關的資料表，如診所藥品、藥品庫存之類。 5. 健保申辦相關的資料表，如門診處方及治療明細檔…等。註：因為建保申辦的資料皆為資料處理過後的結果，而非實際儲存於資料庫內的資料實體，所以不予以加入實體關聯圖中。

醫療管理系統實作-以健保診所為例

逢 甲 大 學

資 訊 工 程 學 系 專 題 報 告