第十章 未來研究
畫面 3. 9 診療輔助子系統 疾病與處方輔助輸入 操作畫面
第七章 系統測試與評估
本章主要針對兩大部分作討論和批判：診所管理系統程式的測試 結果，以及系統運行的實際價值。將對於本系統的可用性、效能和可 靠度等等來評估系統現有價值，同時也作為成果分析討論和反省的依 據。
本章架構說明如下所示：
7.1 測試環境資料
說明測試資料的資料筆數與來源。
7.2 實際運行數據
表列進行過實測的子系統其測試結果數據。
7.3 成品使用者評估
表列分析使用者對本系統設計項目的需要性與使用習慣。
至後續的效能評估與可靠度測試，因時間人力的關係，尚未整合 主系統完成，而不讓使用者作全面長期的測試，故目前暫缺。
7.1 測試環境資料
PAT_MED_BAN0 建祥中醫診所之前並無此機 制，無實際資料。
1-3 病患特殊疾病 PAT_SP_DISEASE
0 建祥中醫診所之前並無此機 CURE_DETAIL
395 由建祥中醫診所提供的病歷 資料轉化而成，藉以測試看 診紀錄查詢效率與健保申辦 的正確性。
2-2 看診診斷疾病 CURE_SICK
395 同上 2-3 看診處方資料
CURE_MED
1269 同上 2-4 看診症候檢驗
CURE_CHECK
0 因屬選擇性資料，建祥中醫 診所並無切實記錄，沒有實 際資料。
2-5 看診特定治療 CURE_ITEM
0 建祥中醫診所無傷科針灸等 特殊治療，沒有實際資料。
2-6 看診特定治療處置 CURE_ITEM_DEAL_WITH
0 同上
表 7. 2 測試資料 看診紀錄一類
7.1.3 掛號紀錄一類
序號 表格名稱 筆數 備註
3-1 掛號記錄明細 REG_DETAIL
395 由建祥中醫診所提供的資料 轉化而成，藉以測試掛號處 理查詢效率與健保申辦的正 確性。
3-2 掛號批價資料 REG_CHARGE
395 同上 3-3 掛號保險資料
REG_INSURANCE
395 同上
表 7. 3 測試資料 掛號記錄一類
7.1.4 掛號紀錄與看診紀錄關聯
序號 表格名稱 筆數 備註
4 關聯表_掛號對看診紀錄 REL_TABLE_REG2CURE
395 自行設計轉換
表 7. 4 測試資料 掛號記錄與看診紀錄關聯
7.1.5 診所參數
序號 表格名稱 筆數 備註
5-1 診所藥品 CLINIC_MED
236 由建祥中醫診所提供的資料 轉化而成，藉以測試醫事藥 事作業。
5-2 診所疾病 CLINIC_SICK
669 同上 5-3 醫師資料
DOCTOR
1 建祥中醫診所僅一位主治醫 師。
表 7. 5 測試資料 診所參數
7.1.6 健保相關代碼參數
序號 表格名稱 筆數 備註
6-1 健保對照表_案件分類 INS_TABLE_CASE_TYPE
5 由健保局提供的規定轉化而 成。
6-2 健保對照表_特定治療 INS_TABLE_CURE_ITEM
29 由健保局提供的規定轉化而 成。
6-3 健保對照表_就醫科別 INS_TABLE_FUNC_TYPE
1 由健保局提供的規定轉化而 成，針對專案對象，故只輸 入中醫科。
6-4 健保對照表_給付類別 INS_TABLE_GIVE_KIND
5 由健保局提供的規定轉化而 成。
6-5 健保對照表_處方調劑方式 INS_TABLE_MED_TYPE
7 由健保局提供的規定轉化而 成。
6-6 健保對照表_部分負擔 INS_TABLE_PART
9 由健保局提供的規定轉化而 INS_DRUG_TABLE
7709 由健保局網站相關資料轉換 而成。
7-2 健保規定疾病 INS_SICK_TABLE
669 因健保局提供的疾病種類繁 雜且無特分中醫科，故暫且 移植診所疾病表格資料。
表 7. 7 測試資料 健保規定藥品疾病
7.1.8 其他自訂代碼
序號 表格名稱 筆數 備註
8-1 代碼表_特定治療項目分類 表
TABLE_CURE_ITEM_GROUP
6 為方便查詢，故將健保局提 提供的特定治療再依性質分 類。
8-2 代碼表_保險種類 TABLE_INS_TYPE
4 診所提供的病患資料其保險 種類分類。
8-3 對照表_供應商 TABLE_SUPPLIER
1 正規化後的自訂表格，將資 料項外移。
8-4 對照表_製造廠 TABLE_MANUFACTURER
11 同上 8-5 代碼表_掛號狀態
TABLE_REG_STATUS
8 正規化後的自訂表格，分類
7.2 實際運行數據
7.2.1 就掛號方面
項目 人工 系統測試
調閱病歷 一般 30 至 50 秒不等，偶而 費時一分中以上，取決於病 歷分類準確度，依照病人敘 述前次看診的概略日期來 找尋病歷。
查詢基本資料約 5 秒，加上 調閱病歷不到 10 秒。
掛號登記 單就登記作業，約 20 至 30 秒不等，時間多花在填寫日 期身分證號等。
單只要填入身分份證號，其 他已由系統參數設定完 畢，不到 5 秒的操作即可完 成。
表 7. 1 測試數據 掛號方面 0
註：以上皆加入人為操作因素
其他子系統則尚未進行實際作業測試，測試數據將於報告時再附 於附錄上。
7.3 使用者需求審核
7.3.2 病歷管理子系統
其他子系統，因時間與人力關係，尚未完全完成並實測，恕待發 表時再附於附錄上。
第八章 成果分析與討論
而且現在最大的主因在於，經濟不景氣，失業率攀升，健保費用 又調漲，導致民眾生病時就醫意願也大幅降低，除非迫不得已，否則 不會馬上就醫。根據協助開發的兩診所「朱益生中醫診所」和「建祥 中醫診所」醫師說法，現在的單月的就診人次僅約從前的五六成，在 這樣的大環境因素下，更別提小診所對預約作業的需求性，因而給予 使用者診所有種「殺雞焉用牛刀」的想法。
關於本專案發，原先規劃出 7 個子系統，但在人力因素與時間調 配上未能完善，導致最後的完成度不甚理想，7 個子系統中僅僅先開發 出三的子系統，「掛號批價子系統」、「病歷管理子系統」以及「診 療輔助子系統」。
論「掛號批價子系統」，此系統以滿足「掛號」與「批價」作業 需求為主，分別訂出「現場掛號」、「批價收費」、「欠卡補單」和
「預約掛號」四大主功能。而最受使用者贊同的為「現場掛號」和「批 價收費」，因為其能滿足目前現行作業需求；至於「欠卡補單」，稍 跟他們現行作業方式有些差異，但仍能接受此新概念。最後，「預約 掛號」此一功能，經評估與討論後，發覺其實範圍有些設定失敗，起 因在於需要預約掛號的時空環境，通常產生在：
1. 大型醫療院所，如醫院或多人主治的診所，因病患就診人次繁 多，不僅病患先以預約方式就診較為省時方便，也可舒緩院所 的掛號人潮。
2. 牙醫等極需耗時的治療，所以多半在牙醫診所有需要如此機 制，如此，診所可較精確掌握各時段就診人次，病患也可免去 空等的時間浪費。
論「病歷管理子系統」，雖然並非作業頻率高的子系統，也不會 有民眾主動索取病歷影本，但仍有其高價值的存在意義，在病歷管理 上可以取代從前紙本式作業的種種不便，如保存不易、查詢調閱不便，
尤其是其中的特殊統計功能，更是傳統紙本式作業無法達成的作業，
這也是資訊化作業和資料庫的強項，輕鬆就可以設計出符合需求的統 計報表。
先進和軟體開發公司發展過，而且如何建立豐富完整的醫療提示資料 庫，那可不是一件小的工程，在專業資料蒐集與分析設計的工作量，
足可媲美一件大型系統的開發工作了，目前限於學生專業學養以及實 作能力有限，無法充分完成此一概念，待日後努力再嘗試。
論「藥事輔助子系統」，對於使用者診所而言，藥師視同虛設的 角色，起因於中醫診所可以由醫師親自調配藥劑而無需藥師參與，而 處方箋的列印和藥品消耗也由醫師端全權處理了，在無實質存在價值 和需求的情況下，故暫略開發。
論「健保申辦子系統」，這也是一般中小型診所之所以如此需要 資訊化的主因；為了健保給付申辦業務的直接需求，必須假手資訊系 統的協助，整合掛號紀錄、保險紀錄以及看診紀錄，經過處理成為申 報資料，以符合健保局的審查格式。雖然此項業務可以算是整個系統 最富商業價值的部分，但正所謂事有先後，在基礎建設尚未完成前，
進階功能就得先擱置；在專案開發過程中，將其擺在後段作業裡，而 目前專案進度與人力資源考量下，只能完成三個子系統，故選擇先就 基本作業需求著手，待前三子系統告一段落後，再來開發此子系統。
「營運管理子系統」則為現階段非必要性的服務，目前使用者以 人工處理和判斷解決藥品庫存採購作業行之多年未曾有礙，且中醫的 藥品（多稱為科學中藥）以粉劑居多，耗損管理上也亦有誤差，庫存 量的現限定等也有待考量。而薪資管理也非使用者提出的需求之一，
若僅是薪資計算等數值處理，那已被微軟的 Excel 套裝軟體解決了，
而要做的完整些，在外界開發的營運管理與薪資管理系統眼中，也非 一個小子系統可以完成的。在多重考量下，此子系統也被閒置下來。
「系統管理子系統」，一開始的概念是提供較簡單親和的介面來 從事系統維護和更新，取代掉直接透過開發環境系統或資料庫管理系 統進行直接操控。個人認為這是一個很重要的觀念，在此機制下不僅 能提供一單純的環境供服務人員作維護，也可交由使用者從事簡單的 設定或操作；最重要的，可以維持在分析階段時設立的種種限制考量，
讓此系統操作皆在掌控中，不會發生意料外的錯誤操作，完全保持系 統一致性和安全性。但目前在未完成全部系統前，這個最後的子系統 也理所當然的被擱置下來，等待完成的一天。
第九章 結論
這個專案開發過程中，很遺憾的只有一個人進行，無法體會團隊 合作的過程，不僅在開發過程中沒有集思廣益的機會，有沒有爭執激 烈的互動，有的只是一個人默默的研究，這也造成了眼界不夠廣的缺 憾，而人力調度上更是一大考驗。
不過，卻有也另外一番風味，從專案的起頭、構思、客戶訪談、
規劃、分析、設計、撰寫程式、測試除錯、整合、及報告文件撰寫全 都經歷過，舉凡接待人員、專案經理、系統分析師、系統設計師、資 料管理師、資料庫設計師、程式設計師、測試人員和操作人員等角色，
全部都扮演過，也是一種奇特的經驗。
然而到頭來，開發的系統未依預期進度全部完成，也無法於診所 實際上場運作，這對開發者來說，實在是一個蠻大的挫折，在距專題 發表的期限越近，這種挫折感與失落感就更加強烈。本想延後發表以 待整個系統完成，但在老師鼓勵與幫助下，決定先在這學期發表部份
然而到頭來，開發的系統未依預期進度全部完成，也無法於診所 實際上場運作，這對開發者來說，實在是一個蠻大的挫折，在距專題 發表的期限越近，這種挫折感與失落感就更加強烈。本想延後發表以 待整個系統完成，但在老師鼓勵與幫助下，決定先在這學期發表部份