1、第三篇 醫療資訊系統開發第 10 章資訊系統分析第一節 開發方式（自行、委外、合約）第二節 專案團隊成員組織與職掌第三節 使用需求訪談1. 分析醫院資訊系統自行或委外開發的優缺點與考量，及合約的訂定。2. 學習分析專案團隊組織成員架構與執掌分配。3. 暸解使用者需求訪談的內容與進行方式。3. 前言醫院資訊系統專案在建置過程中，須考量醫院現有人力與資源情況，採用自行或委外開發等方式進行。如醫院選擇委外開發方式，則在遴選合適廠商及簽訂合約後，須盡速成立專案團隊，以分派組織成員與執掌；同時開始依據各系統規劃進行使用者需求訪談，此為系統建置的首要步驟。良好的系統規劃及建置，倘若缺乏明確的使用者需求與規
2、格，則無法在專案進行初期奠立良好的發展基礎，因此不可不慎。第一節開發方式（自行、委外、合約）由於一般醫院資訊系統涵蓋門診、住院、急診與管理等架構，因此系統範圍與項目均較為繁雜，因此目前醫院所採取的系統建置方式一般可區分為自行開發與委外兩種。一、自行開發自行開發係由醫院資訊部門依院內使用者需求，經分析、訪談後自行設計程式以符合使用者業務上的需求。但在醫院在決定是否採用自行開發時，一方面須考量資訊科技日新月異且不斷複雜化，針對醫院大型與複雜系統，往往在人力資源提供與先進技術教育上的投資所費不眥；另一方面，由於醫院資訊工作較為繁瑣與工作量沉重，因此不容易留住優秀資訊人才。所以目前除了幾所較具資訊人員
3、規模的大型醫學中心或區域醫院外，較少採用自行開發方式進行；而目前較普遍採用模式為先以委外方式進行系統基礎架構開發與建置後，再由院內資訊人員接手進行後續功能面的增強或使用者新需求建置的開發模式。二、委外開發醫院資訊系統委外開發為目前廣被醫院採用的一種模式。一般在評估醫院資源局限，且掌控管理需求大於資源配置時，採行委外開發仍是最合當的模式。但在選擇委外廠商過程中，必須考量廠商專業、經驗與規模，及同時評估醫院本身資源與人員的配合程度，同時透過審慎的評選標準，方得選擇最適當的委外廠商。Quin, Doorley 和 Paquette 認為科技的改變已帶來新的商機，運用最先進科技和工業標準的服務性資訊供
4、應商已然成形。這些供應商以較廉價的成本，提供優越的服務給客戶，其品質通常均優於公司自身所提供的服務。一般來說，委外的優點包括有：(一)規模1.廠商因為擁有為數眾多的客戶，而具有一般醫院所無法達到的規模。2.大型廠商不但有能力購買大型、功能強大、有效率的設備外，並且能充分利用這些設備，這些是規模較小的客戶較難做到的。3.大型廠商在與設備、軟體供應商議價的時候，比較占優勢。4.大型廠商所擁有的專業人員類別，遠比任何客戶來得廣泛、深入。這是因為他們擁有眾多類別不同的客戶群，他們必須能夠隨客戶的彈性需要，充分有效率地運用這些技術。5.大型廠商主管可以把重心放在專業上，並經由不同的專案，累積重複經驗，而
5、一般資訊部門主管則僅有該部門的單一經驗。由此可知大型廠商主管們的技巧及經驗會比較老道。(二)經歷因為廠商遇到的客戶及情況比較多，因此其所累積的經驗，無論是廣度或深度，均為一般客戶所不及，廠商可以不斷重複地教授、溝通。然而在自身醫院組織內，像這樣的經歷可能僅有一次。這就像最優秀的外科醫生，通常是那些日以繼夜、歷經多次同類型手術經驗者。同樣的道理，比起那些僅有單次或少數經驗者，委外廠商則不斷在同類困難的工作裡，累積有利的經驗。(三)專業化所謂專業能力尚包括涉獵新科技在內。醫院人員遇到轉換新系統或主從架構（client-server architecture）的機會只有一次，但是廠商卻不同。他們經常
6、和許多不同的客戶往來，因此在知識、速度和效率上，能夠累積許多實際有利的經驗。因此在選擇委外開發的過程中，除審慎遴選廠商外，醫院也應以積極態度來參與專案建置並支付可與廠商投入價值相抗衡的建置價金。否則僅以有限價金而要求廠商超出能力範圍建置，在巧婦難為無米的炊的困境下，廠商對於醫院系統發展投入的熱忱與品質低落情形自然可以預期，而此雙輸局面自非大家所樂見，此為目前委外開發須特別注意的處。三、合約醫院與委外廠商間應建立合約以釐清雙方的權益與義務，因此合約訂定必須清楚明確，以防止日後醫院與廠商間產生爭執、不歡而散或無法收尾的現象。合約的訂定係為確保醫院與廠商間權利與義務的執行規範。因此專案合約的內容方面
7、，除必須將重點條例式說明外，更必須盡可能地將模糊、灰色地帶明確指出，以避免造成往後爭議的焦點。茲將合約內容重點簡單闡述如下：(一)合約範圍合約中應明訂專案所包含的工作範圍與階段類別。例如：應用系統開發、軟硬體、網路等工作範圍與其細部完成階段分類。若專案為購買資訊廠商現有已開發完成的醫療套裝軟體，為避免往後模糊地帶的爭議情形發生，也最好將合約範圍內的系統畫面、功能說明、軟硬體、網路組件等型錄，按類別以附件方式夾註於後，以作為將來進行驗收程序的依循標準。(二)工作時程泛指劃分合約範圍工作內容的各階段詳細時程。包括開工日期、完工日期、監控日期、檢核點、項目文件、工作產品產生點等實際時程內容與繪製的時
8、程表。並同時將歸咎於任何一方所導致的時程延誤情形，訂立適度的罰則與工期補償方式。(三)合約價金與付款方式訂立合約範圍內容的總價金、款項支付階段、數目與給付方式。並同時描述若有歸咎於醫院方面的拖欠情形，所引發的罰則事項。(四)合約執行組織與方式將雙方專案負責組織架構成員名單表列，並描述其執行工作項目、方式與協助配合的範圍事項。(五)系統分析與系統設計審查在廠商完成系統分析與系統設計工作後，即應將相關完成文件送交醫院方面進行審核的程序。如果醫院方面有任何異議，則必須於限期內以書面文件通知廠商，待修改或補充完竣後，再送請院方審核。(六)專案文件明訂廠商於專案進行過程中，應送交醫院方面的相關文件種類、
9、格式與份數。同時應說明雙方有異議產生時的處理方式。(七)驗收標準與程序訂立專案工作內容範圍完成後的驗收標準與程序進行方式，內容包含應用系統、軟硬體、網路等部分。(八)教育訓練規定資訊廠商所應提供的教育訓練課程項目、內容、人次、時數等事項。(九)保固維護在驗收完成後，廠商應負責提供應用系統、軟硬體、網路等後續保固服務方式、規範與期限。並明訂保固維護範圍、消耗性材料項目，與回復正常作業的修復時間限制等。(十)機密資料的保護雙方除了依資料保護法法規，不得隨意將病患個人資料洩露的規定外，更應條例雙方視為機密或專屬資料項目的處理原則與方式，及相關的違約罰則。(十一)智慧財產權歸屬訂立合約範圍內的設備與文
10、件，其智慧財產權的歸屬方式及相關的違約罰則。(十二)履約保證金訂定廠商所應繳付予醫院方面的履約保證金款項，以作為廠商對醫院方面所應負擔損害賠償責任的擔保。同時也必須闡述履約保證金歸還的程序與方式。(十三)合約的終止條列雙方發生終止合約的可能狀況，及規範合約終止後，雙方所應負擔的責任與義務。(十四)合約的修改明訂說明合約與附件的修改或增減應以書面約定為主，其他口頭、書面約定均為現行合約所取代。此外，未列載於合約者，對雙方均不生效力。(十五)爭議的解決闡述當雙方對合約解釋或未明文規定的事項有所疑義或爭議訴訟時，所共同承認的準據與仲裁單位。上文所列，僅簡單描述合約規範的注意事項，當正式訂立契約的詳細
11、內容，仍須依據雙方的實際需求產生。第二節專案團隊成員組織與職掌在醫院資訊系統建置過程的專案管理基礎上，首先最主要的工作係界定專案團隊的組織架構與任務職掌。一般在組織架構中，醫院方面必須成立醫院資訊系統建置專案推動委員會（簡稱推動委員會），主任委員為院長或副院長，推動委員為各部門的主管或副主管等擔任（圖 10-1）。其職掌內容主要為推動與制定整體專案目標、範圍，並且任命團隊相關組織成員與其所擔負的權責（見表 10-1）。圖 10-1 專案團隊組織架構圖表 10-1 專案團隊組織成員職掌分類表職稱 醫院 廠商 共同 職掌內容推動委員會 指導審議專案發展方向、目標、範圍，協議各相關部門單位於專案規劃
12、建立的權責，協調溝通相關機專 案 負 責 人專 案 負 責 人系 統 總負 責 人 醫 務 流 程規 劃 顧 問醫 務 流 程規 劃 顧 問各 子 系 統負 責 人各 子 系 統負 責 人 資 料 庫 管 理負 責 人資 料 庫 管 理負 責 人 硬 體 工 程負 責 人硬 體 工 程負 責 人教 育 訓 練負 責 人教 育 訓 練負 責 人行 政 支 援負 責 人行 政 支 援負 責 人 推 動 委 員 會推 動 委 員 會註 :虛 線 部 份 為 醫 院 或 資 訊 廠 商 單 方 面 所 需 組 成 單 位 斜 線 部 份 為 醫 院 與 資 訊 廠 商 可 共 同 組 成 的 單 位品
13、 質 控 制小 組品 質 控 制小 組構不同意見及合作連繫事宜，評估規劃成果與推動執行專案負責人 統籌時程、品質、成本等總體控制與規劃監督。對外協調溝通整合、維持良好關係。對內明訂專案管理章程制度，有效排解紛爭、賞罰分明、控制進度醫務流程規劃顧問 規劃、評估作業流程管理的合理性與可行性，並協助各系統負責人的間對流程的溝通協調品質控制小組 監督整體專案品質流程、問題維護處理程序審核、提供意見與成果評估系統總負責人 制定系統發展程序、品質規範與時程規劃，並統籌、監督、處理各系統間的相關溝通協調事宜與支援管理各子系統負責人 依據系統發展程序、品質規範與時程規劃，協調訪談、系統分析、設計、程式撰寫、測
14、試、上線、維護與品質管制等作業。並製作相關系統文件與使用者手冊等事務資料庫管理負責人 統籌資料庫規劃、轉檔、建檔、上帶、清檔、備存、核對、運作與執行效率統計評估等工作硬體工程負責人 協調相關軟硬體架設、配合、維護工作與網路工程的監督、維護與執行作業教育訓練負責人 協調安排訓練課程項目、時程、內容、講義、講師與上課學員等事務行政支援負責人 協調行政人員，處理資料繕打、影印、整理等一般行政事務服務此外，專案負責人為領導整個專案進行的重要靈魂人物，也被視為醫院與廠商雙方間統籌、溝通的正式對等的單一窗口。一切的決策作法論斷或溝通協議結果，均由專案負責人代表對內或對外正式發布。因此專案負責人所具備的溝通
15、處理方式、專業經驗與人格成熟度，也就相對地影響專案進行的順利成敗關鍵。一般而言，醫院方面的專案負責人選，通常由該院資訊中心主管擔任；而資訊廠商方面，則應推派出負責此案的專案經理；雙方面專案負責人的主要職責為相互溝通、協調，而非彼此對立。此外，最好能在雙方主導專案進行的最高指導當局充分授權下，正式發布人事行政命令，使專案負責人能握有充分的權限執行主導權與決定權。再由雙方專案負責人根據專案所包含的範圍內容，提出專案團隊組織成員名單，例如：顧問管控方面的醫務流程規劃顧問、品質控制小組成員；規劃執行方面的系統總負責人（整體規劃）、各子系統負責人（各系統規劃）、資料庫管理負責人（Database Adm
16、inistrator; DBA）、硬體工程負責人（含主機、網路、PC、印表機等相關軟硬體）；教育支援方面的教育訓練負責人，或行政支援負責人等重要負責人選與所安排的成員後，送交推動委員會與廠商決策管理最高階層通過，即正式確定專案團隊組織成員架構名單與任務職掌，並依此正式行文或發函知會對方，以完成專案團隊成員任命的工作。值得一提的是，組織各項目負責人可根據專案範圍或實際狀況相互兼任，唯專案負責人不得兼任上述其他工作項目，以避免將來發生顧此失彼、得不償失的窘態。尤其，在專案進行過程中，各項目負責人員若有任何變動發生時，需於離開該負責項目二週前，正式行文或發函通知對方，以盡到充分告知的義務。進一步由雙
17、方接手負責人員與原負責人員，一起正式安排會議報告與討論截至目前為止的工作內容，及所遭遇的困難或必須注意事項等，並進行未來進度的修正與人員交接工作。同時，準備相關的文件（如訪談記錄、流程規劃、畫面說明等），以防止影響往後專案建置的時程進度，與可能面臨的規劃前後不一致的問題。此為專案進行過程中，最容易導致時程延宕與系統規劃爭議的根源所在。第三節使用需求訪談（一）使用需求訪談的目的使用需求訪談的目的在於透過與使用者訪談的互動過程中，詳細了解使用者單位的作業流程內容與執行範圍，以協助在未來系統分析階段，能將使用者腦海中較為抽象而籠統的使用需求概念，以正規化的規範語言方式，直接將這些需求轉換成系統功能的
18、作用。（二）需求訪談時的注意事項系統分析師（SA）所必須注意的是，要利用使用者看得懂的語言或圖形進行溝通，而不是以資訊科技人員看得懂的 DFD 圖，讓不懂技術文件的使用者確認，避免系統分析師和使用者彼此溝通的誤差。當系統分析師前往與使用者正式進行使用需求訪談前，系統分析師應該盡可能地對所負責的系統流程與內容進行通盤性的了解，而這也是系統分析師所應具備專業能力的重要表徵。然而若對此系統相當陌生或從未接觸過時，也應該盡力收集相關資料，或找尋適當的溝通管道進行了解、研究。尤其千萬要注意的一點，系統分析師絕對不能毫無準備地空手前往，而一意地只想藉由與使用者的直接訪談過程中，了解系統的整體面貌與內容架構
19、。因為這是相當不明智、缺乏專業技巧且自暴其短的作法。此種作法的缺點，不僅將系統開發主導工作經由系統分析師移轉給使用者，甚至會引發使用者對系統分析師專業信心指數降低的重大缺陷，而倍增以後系統建置的困擾。此外，在第一次拜訪使用者時，系統分析師也必須與使用者暫時敲定往後的訪談次數、時間、內容與參加人員等，並排定訪談時間表（見表 10-2）交予使用者認可，以便雙方妥善做好事前的準備工作，達到每次訪談均能獲得具體結論的有效目標。並且在往後的訪談過程中，雙方除了應該避免遲到而影響訪談會議的進行外，系統分析師必須有效地主導訪談的進行方向與時間控制，以防止結果流於浪費時間的空談。除此的外，若因特殊情事而必須取
20、消該次訪談作業時，也務必預先知會對方，另外訂立訪談時間，避免對方翹首等待、浪費時間或白走一遭、無功而返，因而在對方心中留下不良的印象。表 10-2 專案訪談時程表製表日期： 年 月 日日期 時間 訪談人員 受訪者 部門單位 訪談主題 備註在使用需求訪談階段所必須產出的文件，除了訪談記錄內容務必於訪談後 3 天內送交使用者確認外，一般描述詳實作業流程內容、作業細則與其他流程關聯性目標的事務流程圖（見圖 10-2），也應於此階段一併產生。圖 10-2 事務流程圖專案名稱 頁次系統名稱 日期子系統名稱 填表人課後復習問答題1. 請說明醫院資訊系統委外開發所必須考量的重點為何？2. 請說明醫院資訊系統
21、專案建置的主要組成結構為何？請繪圖加以描述。 3.試請擬妥一份醫院資訊系統委外建置合約，並考量其主要可能衝突點為何？情況題在醫院資訊系統建置過程中，您今天將第一次對掛號系統使用者進行訪談需求，請說明您將進行的方式，並請考量主要應對技巧，及您對使用者的承諾，同時請擬妥相關文件，以供後續專案建置進行參考，試行的。參考書目王慶富(1996)專案管理台北：聯經。季延平、郭鴻志(1995)系統分析與設計台北：華泰。Arbor, A. (1990). Foundation of the American collage of healthcare executives. MI: Health Administration Press.Pressman, R. S. (1992). Software engineering a practitioners approach. New York: McGraw-Hill.Martin, J. B. (1990). The environment and future of health information system. Journal of Health Administration Education, 8, 19.
