國立台東大學資訊管理學系 碩士論文
Department of Information Science and Management Systems
National Taitung University Master Thesis
應用 HL7 開發框架於居家健康照護需求 塑模-以脊髓損傷患者為例
Applying HL7 Development Framework to Home Healthcare Requirements Modeling for Patients with Spinal Cord
Injury
鄭龍富 Lung-Fu Cheng
指導教授：謝明哲 博士 Advisor: Ming-Che Hsieh, Ph.D.
中華民國九十九年七月
July, 2010
誌謝辭
在台東大學讀了四年的大學部後，在家人的鼓勵下又唸了兩年的碩士班，
現在要離開這個我生活了六年的地方，很多的感觸頓時湧上心頭。在這兩年的 研究生涯，遇見很多人，也經歷很多事，在這裡僅以此誌謝辭聊表心意。
首先要感謝的是我的指導教授 謝明哲教授，從我加入研究團隊、參與國科 會計畫、參加全國電子設計創意競賽、以及發表國際健康資訊管理研討會、到 最後的碩士論文撰寫， 謝明哲教授總是不遺餘力的指導我，在我迷惘的時候指 引我方向，並在我失去動力的時候及時給予我鼓勵。另外還要感謝 鍾青萍教授 和 黃恊弘教授，無論是在論文計畫書的審查或是畢業論文的口試，都給予我修 改的建議及寶貴的意見，讓本論文的內容更加完備。
而在碩士班這兩年所認識的好伙伴們，更是支持我前進的動力，因為有你 們，在做研究的時候才不會空虛寂寞覺得冷。我要感謝我的學長姊 維昇、紹永、
宜澤、智鴻、信宏、佳慧，在我一年級的時候，引領我進入這學術殿堂；再來 要感謝相處兩年的好同學 聖熙、弘侑、冠廷、延錄、文翔、牧隴、慧文、千秦，
在研究遇到瓶頸時可以互相討論；感謝學弟妹 人杰、仁俊、家政、名哲、俊穎、
雅雯，為枯燥乏味的生活帶來許多意想不到的歡樂。
此外仍要感謝國科會的經費補助、研究個案 慶鴻及其家人的參與、台東基 督教醫院護理長 宜珍及營養師 靜芬的專家諮詢，使得本研究可以順利進行。
最後要感謝的是我的爸媽，因為台東跟台南距離遙遠而較少回家，而每次 我回到家總是能感受到家庭的溫暖，多虧有你們的支持和諒解，我才能無後顧 之憂的取得碩士學位。
摘要
在健康照護資訊系統的開發過程中，最重要的是如何將使用者的需求完整 地表達出來，並且符合標準與互操作性，以提高照護的安全與品質，進而能夠 提供健康照護的決策支援。本研究之目的在於探討：當進行居家健康照護需求 塑模時，應用 HL7 開發框架是否有助於需求及規格的表達? 本研究是以 HL7 開 發框架 (HL7 Development Framework) 的領域分析模 型 (Domain Analysis Model) 作為本研究之需求塑模方法論，並以一名脊髓損傷患者做為本研究之個 案，經由訪談及觀察的方式得知該病患在居家健康照護上的需求，主要有：健 康狀況評估、營養攝取評估、復健績效評估、用藥資訊管理、緊急異常通知等；
接著以其中兩個案例展示實際的需求塑模過程，最後再針對產出文件進行可用 性評估。結果顯示此一需求塑模方法論可以有效地表達使用者的需求，而其中 參考資訊模型 (Reference Information Model, RIM) 的導入，更可有效地解決不 同系統間互操作性的問題。本研究最後針對此一需求塑模方法論提出一些結論 和建議，可以作為後續相關研究的參考。
關鍵詞：健康資訊交換第七層協定、需求分析、健康資訊管理、居家照護、脊 髓損傷
Abstract
In the information system development process of home healthcare, the most important thing is how to express the requirements from users, and meet the standards and interoperability to improve safety and quality of care, thus able to provide health care decision support. Therefore, requirements modeling played a key role. The purpose of this study is to investigate : Is this feasible that applying HL7 development framework to home healthcare requirements modeling. This study is using the Domain Analysis Model (DAM) of HL7 Development Framework (HDF) as our requirements modeling methodology, and inviting a spinal cord injury patient as a case study. Through the way of interview and observation, we know that the patient’s requirements in home healthcare are health assessment, nutrition assessment, rehabilitation assessment, drag information management, emergency warning. And then used two cases to show the actual requirements modeling process, also take feasibility test to artifact. The results show that by using this requirements modeling methodology can express user’s requirements with advantage, and import the Reference Information Model (RIM) can solve interoperability problem between different systems efficiently. Implications follow these results are offered.
Keywords: HL7, Requirements Analysis, Health Information Management, Home Healthcare, Spinal Cord Injury.
目次
摘要... I ABSTRACT ...II 目次... III 圖次...V 表次... VI
第一章 前言 ... 1
1.1 研究個案介紹... 1
1.2 研究背景與動機 ... 2
1.3 研究目的與範圍 ... 4
1.4 論文架構 ... 5
第二章 文獻探討 ... 7
2.1 脊髓損傷患者... 7
2.1.1 脊髓損傷發生的原因 ... 7
2.1.2 脊髓損傷造成的影響 ... 7
2.1.3 脊髓損傷患者的健康問題... 8
2.2 健康資訊管理... 9
2.2.1 健康資訊管理的發展 ... 9
2.2.2 電子病歷的發展 ...10
2.3 健康資訊交換機制 ...11
2.3.1 國際健康資訊標準 ...11
2.3.2 健康資訊交換第七層協定 (HL7) ...13
2.4 健康照護需求塑模 (HEALTHCARE REQUIREMENTS MODELING ARCHITECTURE) ...14
2.4.1 資訊需求塑模 (Information Requirements Modeling)...15
2.4.2 健康照護資訊塑模架構 (Healthcare Information Modeling Architecture) ...16
2.4.3 健康照護塑模方法 (Healthcare Modeling Method) ...18
2.4.4 健康照護開發框架 (Healthcare Development Framework)...19
2.5 領域分析模型...26
2.5.1 背景 ...27
2.5.2 角色和工作...27
2.5.3 程序和任務...28
2.5.4 需求塑模產生文件 ...31
第三章 研究方法 ...38
3.1 設計科學研究法 ...38
3.2 研究流程 ...40
第四章 居家健康照護需求塑模 ...45
4.1 居家健康照護需求塑模方法論...45
4.2 個案介紹 ...47
4.3 應用案例塑模...49
4.3.1 應用案例一：健康狀況評估...49
4.3.2 應用案例二：緊急異常通知...60
第五章 評估與溝通...68
5.1 專家效度評估...68
5.2 可用性評估...73
第六章 結論 ...74
6.1 研究成果 ...74
6.2 研究貢獻 ...75
6.3 研究限制 ...75
6.4 未來研究方向...76
參考文獻...77
中文部分 ...77
英文部分 ...78
附錄一...80
附錄二...86
圖次
圖 1.1 研究架構圖 ... 6
圖 2.1ZACHMAN企業架構 ...17
圖 2.2HDF 程序圖...21
圖 2.3 領域分析流程 ...29
圖 2.4 領域分析模型文件 ...32
圖 3.1 設計科學研究法之流程...38
圖 3.2 研究流程...40
圖 3.3 可用性評估流程...43
圖 4.1 居家健康照護需求模型...46
圖 4.2MCTIN嘴控摩斯碼文字輸入系統 ...48
圖 4.3 居家健康照護需求概念圖...49
圖 4.4 健康狀況評估之使用案例分析 ...53
圖 4.5 新增健康記錄之處理流程...54
圖 4.6 修改健康記錄之處理流程...55
圖 4.7 刪除健康記錄之處理流程...55
圖 4.8 評估健康狀況之處理流程...56
圖 4.9 健康狀況評估之流程順序...57
圖 4.10 健康狀況評估之資訊模型...58
圖 4.11 健康狀況評估之事件觸發分析 ...59
圖 4.12 緊急異常通知之使用案例分析 ...62
圖 4.13 偵測生理訊號之處理流程...63
圖 4.14 監控維生設備之處理流程...64
圖 4.15 發出異常通知之處理流程...64
圖 4.16 緊急異常通知之流程順序...65
圖 4.17 緊急異常通知之資訊模型...66
圖 4.18 緊急異常通知之事件觸發分析 ...67
表次
表 2.1 健康照護中的標準分類...12
表 2.2 領域分析內容 ...29
表 4.1 產出文件表示方法 ...47
表 4.2 健康狀況評估之故事板...50
表 4.3 新增健康記錄使用個案...50
表 4.4 修改健康記錄使用個案...51
表 4.5 刪除健康記錄使用個案...51
表 4.6 評估健康狀況 ...52
表 4.7 健康狀況評估之詞彙表...58
表 4.8 緊急異常通知之故事板...60
表 4.9 偵測生理訊號使用個案...60
表 4.10 監控維生設備使用個案...61
表 4.11 發出異常通知使用個案...62
表 4.12 緊急異常通知之詞彙表...66
表 5.1 領域專家基本資料 ...69
表 5.2 個案需求解說之故事板...69
表 5.3 專家效度問卷指標 (第一版)...70
表 5.4 專家效度檢核表結果摘要表 ...71
表 5.5 專家建議整理表 ...71
表 5.6 專家效度問卷指標 (第二版)...72
第一章 前言
根據統計，台灣地區的脊髓損傷病例以每年 1200 例逐年增加，而其中有百 分之五十以上皆為交通事故造成，其次為高處摔下及職業傷害，每一年齡層都有 可能發生，尤其以 20 歲到 29 歲的年輕族群發生率最高 (脊髓損傷患者通報系 統，2009) 。所謂「脊髓損傷」是指急性外傷性傷害侵入脊髓與神經，造成運動、
感覺及大小便功能失常。這通常是因巨大的外力，如車禍事故、高處墜落、重物 壓傷、運動傷害等原因所造成。如果受傷的部位在頸部脊髓，會造成四肢癱瘓，
約佔所有脊髓損傷患者的半數；若傷及胸部脊髓、腰部或薦部脊髓，則會造成下 半身癱瘓。除了運動與感覺機能障礙外，脊髓損傷還會造成排尿、排便困難及性 功能障礙，而呼吸問題、自主神經機能異常，也是常見的後遺症 (王秋雯，2005;
詹瑞棋，2004) 。
1.1 研究個案介紹
本研究個案描述一名重度脊髓損傷患者，個案於 1997 年正值高中二年級 時，在一次跳水競賽中不幸發生意外造成頸部脊髓嚴重的損傷，導致全身四肢癱 瘓，只剩下頸部以上可以自由活動。他在出院後便返回家中接受居家照護，因此 所有的生活起居都需要依靠家人的幫忙。由於個案是位重度的脊髓損傷患者，為 了改善抽痰痛苦而進行了氣切手術，這個手術使得個案無法像正常人一樣講話，
只能發出微弱的氣音。
為了提升個案在生活上的自主性，目前陽光輔具研發團隊為個案發展出智慧 型居家服務代理人系統 (Hsieh, Hung, Lin, & Luo, 2009; Liang, Hung, Hsieh, Wu,
& Luo, 2008) ，讓個案可以使用摩斯碼嘴控輸入系統 (吳崇民，2004) 來操作電 腦和輸入文字，並藉由文字和口語對話代理人進行交談來達到更有效的居家服 務，包括家電控制、電話通訊、簡訊發送、和睡眠管理等。
目前個案是由指定醫院的醫療團隊提供醫療服務，胸腔科醫師每兩個月到個 案家中探訪並做血液和尿液的抽樣檢查；另外，還有居家護理師和呼吸治療師每 半個月替個案更換呼吸道內管。
個案的媽媽是其主要照顧者，在每天的 8 時、12 時、16 時、20 時、24 時為 個案做生理參數量測和記錄，包含血壓、心跳、體溫、血氧、尿液量、和排便量。
另外，也記錄每天的飲食，希望能更有效掌握個案的健康狀況。
身體的肌肉關節符合「用進廢退」的原則，如果一段時間沒有運動會逐漸僵 硬萎縮；此外，長期躺在病床上不動也會造成很多其他的問題，例如：免疫系統 功能下降、加速骨質疏鬆症、泌尿道容易發炎、排便不順暢等 (王秋雯，2005) ， 而勤做復健更可以避免褥瘡、肌肉萎縮或關節攣縮等併發症的發生 (詹瑞棋，
2004) 。為了讓個案維持良好的生理機能，個案的家人每隔兩個小時幫他做復 健，每次約 20 分鐘。
1.2 研究背景與動機
目前世界衛生組織 (World Health Organization, WHO) 正極積推動「健康促 進 (Health Promotion) 」的概念，意指增加人類控制與改善自己健康的能力，包 括養成健康的個人生活方式 (例如營養狀況、免疫力、體適能、穩定情緒、調適 壓力、衛生知識與生活習慣等等) 以及創造有利的健康環境 (林妍如，2007) 。 隨著資訊科技的進步，醫療產業導入資訊系統後大量的降低人力和資源的浪 費，自動化的技術取代了原本的人工記錄，電子化過程更是減少了許多醫療記錄 的紙本作業，在講求服務導向的二十一世紀，如何提升對病患的服務品質將是未 來競爭的重要關鍵。
學者 Bemmel 和 Musen (1999) 認為：「醫學資訊學是指將資訊學應用在醫 學、健康照護以及公共醫療等方面」，而學者 Burke 和 Weill (2000) 則認為：「醫 學資訊學是使用電腦科技於健康照護以及其傳遞上，而資訊學在醫療上的使用則 分為管理、臨床及其它特殊用途」，由此可知過去的醫學資訊學是以醫護人員的 角度來看資訊科技在醫療院所的運用，特別是在醫療行為的支援。
然而近年來消費者意識抬頭，目前健康照護服務也從顧客需求面來探討，強 調的是「以人為本」的概念，也就是以病患為中心 (patient-centered) 來設計健康 服 務 系 統 ， 將 人 類 的 健 康 願 景 導 向 個 人化的 健 康 照 護 服 務 (individualized healthcare service) 。消費者已經從過去被動地接受醫療的服務，轉變成主動地管
理自己的健康，這個轉變帶給醫療業者一個巨大的衝擊，如何從消費者的角度來 提供適合的健康服務變成一個重要的議題 (林妍如，2007) 。
因為大多數民眾對於自己的健康狀況和醫療資訊不了解，未來衛生醫療資訊 政策的重點在於保障民眾的健康資訊權，強調醫療病歷 (健康資訊) 透明化、保 護個人健康資料的安全性和隱私權、確保正確的照護醫療及就醫資訊。電子病歷 也逐漸演變成電子健康資訊，除了傳統的醫療照護資訊之外，尚包括其他相關照 護記錄，甚至個人的相關行為、用藥習慣、生活習慣、飲食及運動等資訊，構成 一個完整的健康資訊系統。
本研究個案是一名四肢癱瘓的脊髓損傷患者，在受傷後失去了運動和感覺能 力，因此日常生活起居都需要依賴家人幫忙，對逐漸年邁的父母而言是相當大的 負擔。個案因為四肢癱瘓而長期躺在床上，加上不能像正常人一樣可以自由活 動，因此身體脂肪容易屯積而形成肥胖問題，同時也增加了許多慢性病發生的風 險。健康會出現問題通常是沒有去注意到身體發出的警訊，所以在居家照護的時 候要特別注意日常生理資料的記錄和管理，而居家照護導入資訊管理的方法將可 以有助於個案健康的管理。
在與個案訪談的過程中，我們發現個案雖然有專門的醫療團隊提供醫療照護 的服務，但是也僅限於定期的到個案家訪視，平時還是由個案的家人提供居家照 護的服務；而個案的家人缺乏像醫護人員一般的專業健康照護知識，平時只能為 個案記錄日常的生理資料以及做簡單的復健，無法詳細了解個案的健康狀況並做 進一步的處理，因此本研究想透過資訊科技結合資訊管理的方法協助個案的家人 進行健康資訊的管理，減輕他們在記錄管理上的負擔，讓他們可以專心的為個案 提供健康照護服務。
觀察目前國內健康資訊管理相關的研究 (吳睿庭，2004; 林媛媛，2008; 黃 恊弘，2002) ，大多是著重在醫院之間醫療資訊交換的設計，或是遠距醫療照護 系統的開發，而本研究則希望從健康照護的根本做起，將重心放在居家照護服務 的需求分析上，經由需求分析產生的文件可以提供相關領域人員開發健康照護服 務，而不用受限於標準和技術的實作。
1.3 研究目的與範圍
本研究希望針對脊髓損傷患者在居家照護上的需求，例如健康狀況評估、營 養攝取評估、復健績效評估、緊急異常通知…等，並整合患者、照護者以及醫療 團隊的觀點，進行居家健康照護服務的需求塑模，經由需求分析所產生的文件可 做為開發居家健康照護服務的基礎；另一方面，為了跟醫療團隊建立健康資訊交 換機制，並解決不同系統之間的互操作性問題，本研究採用目前多數國家採用的 國際健康資訊標準 HL7 (Health Level 7，健康資訊第七層協定) ，並依據 HL7 開 發框架 (HL7 Development Framework, HDF) 進行需求塑模。一方面可以符合國 際健康資訊標準 HL7 交換協定，一方面還可以將居家照護的需求以 UML (Unified Modeling Language, 統一塑模語言) 的方式來描繪，可以達到需求分析表達的一 致性，以及提升開發團隊溝通的效率。在需求塑模完成後，本研究進一步針對應 用 HDF 於居家健康照護需求塑模進行可用性評估，並提出可改進的方向，可以 提供後續相關領域人員作為參考。
本研究個案是一名脊髓損傷患者，在身體機能和行動自主性方面不能像正常 人一樣有高度的自主性；而且個案是屬於四肢癱瘓的重度患者，因此在身體功能 的限制上又比一般的脊髓損傷患者還多。正因為個案的獨特性和複雜性，在居家 照護的考量上就需要從更多的層面去探討，個案身體行為的限制加深了本研究的 困難度。
一般健康資訊管理的研究都是將重點放在建立資訊交換的標準，或是以資訊 科技來實現遠距健康照護，而本研究則是著重於健康照護的根本，針對一名脊髓 損傷患者進行個案研究，將重點放在健康資訊管理的需求塑模，根據個案的居家 健康照護需求進行分析。而在概念模型完成後，需要找相關的醫護人員以及領域 專家來進行專家效度評估，並根據評估的結果及意見做進一步的修改，如果專家 效度評估沒問題，之後再考慮應用在其它類似個案。
1.4 論文架構
本論文分為六章，論文架構如圖 1.1 所示，以下簡單描述各章內容：
第一章為前言，首先簡單介紹研究個案，再進而說明本研究之背景及動機，
接著指出研究目的為何，最後說明本研究涵蓋的範圍。
第二章為文獻探討，先瞭解脊髓損傷發生的原因及造成的影響，並整理目前 健康資訊管理相關的文獻，再針對本研究涉及的健康資訊交換標準及塑模方法 論，包含 HL7 標準協定、HL7 開發框架 (HDF) 、居家健康照護需求塑模方法論 (HHRM) 等進行說明。
第三章為研究方法，本研究是採用設計科學研究法，接著說明此方法在需求 塑模之研究流程，包含確認問題與動機、定義解決方案的目標、設計與開發、展 示、評估、溝通，以及詳細說明每個步驟的工作內容。
第四章為居家健康照護需求塑模，主要是以訪談和觀察的方式蒐集個案的需 求，再參照 HDF 的領域分析模型作為本研究之需求塑模方法論，並且以本研究 個案為例，進行應用案例塑模與說明。
第五章為評估與溝通，分為兩個部分，其一是針對需求塑模方法論進行可用 性評估，證明此方法論是可以有效表達個案的需求；其二是針對個案需求進行專 家效度評估，驗證研究者歸納出的個案需求是否正確及有需要，最後對測試結果 進行說明並提出建議。
第六章為結論，說明本研究之成果、貢獻、限制以及未來研究方向，以作為 後續研究之參考依據。
第一章 前言
第二章 文獻探討
第三章 研究方法
第四章 居家健康照護需求塑模
第五章 評估與溝通
第六章 結論
圖 1.1 研究架構圖
第二章 文獻探討
本章經由蒐集國內外文獻探討脊髓損傷患者的健康問題，並透過實際訪談了 解患者的居家照護情形，同時探討目前健康資訊管理的發展趨勢，找出適合患者 的健康資訊管理模式；在醫療資訊方面的特定規範請見 2.2，一般塑模的理論請 見 2.4，而 HDF 在 2.4.4 會有詳細描述。
2.1 脊髓損傷患者
本研究個案是一名脊髓損傷患者，為了增進對個案的認知，首先需要從人體 脊髓的構造和功能去探討脊髓損傷發生的原因，以及對於不同部位和程度的損傷 進行分類，進而了解脊髓損傷後會造成怎樣的影響。
2.1.1 脊髓損傷發生的原因
人體的脊椎是由一系列的椎骨與椎間板組成，脊椎主要的功能為支撐身體、
聯繫身體的運動以及保護根管內的神經組織等，當脊髓或神經組織受到損傷時，
就會造成不同程度的身體機能障礙。所謂「脊髓損傷」，是指急性的外傷或傷害 傷及脊髓與神經，因而造成運動、感覺及大小便功能失常。通常是由於巨大的外 力，如車禍、墜落、重物壓傷、運動傷害等，使脊柱移位或骨折造成。有些癱瘓 的病人，並不是外傷性傷害造成，而是由於腫瘤、脊血管、發炎等因素，這些脊 髓疾病的表現，常與外傷性脊髓損傷相似 (王秋雯，2005) 。
近來台灣跳水運動逐年盛行，常造成頸椎嚴重及持久性的傷害，此類病例皆 造成頸椎受傷導致四肢癱瘓，最常發生脊椎骨受傷部位為 C5 (50.0%) ，其次為 C4 與 C6 (Tu et al., 2006) 。本研究個案即是因為跳水運動的意外造成四肢癱 瘓，由此可見跳水運動潛藏著許多危機。
2.1.2 脊髓損傷造成的影響
脊髓依照頸部、胸部、腰部和薦部等部位經由脊髓神經來支配人的肢體及內 臟，每一節神經都有其主要的代表功能，而每節神經所支配的感覺區域也有所不 同， 所以脊髓受傷時會因為受損部位的高低以及嚴重程度而有不同的症狀，例
如頸椎受傷會造成四肢癱瘓而且呼吸困難，胸椎以下的受傷則大多是下半身癱 瘓，當然所謂的癱瘓不只是動作的癱瘓，還包括感覺系統、中樞控制系統以及自 主神經系統等，會造成全部或部分失去功能的影響 (詹瑞棋，2004) 。
如果受傷的部位在頸部脊髓，會造成四肢癱瘓，大約佔所有脊髓損傷患者的 半數；若傷及胸部脊髓、腰部或薦部脊髓，則會造成下半身癱瘓。除了運動與感 覺機能障礙外，脊髓損傷還會造成排尿、排便困難及性功能障礙，而呼吸問題、
自主神經機能異常，也是常見的後遺症 (王秋雯，2005) 。
脊髓受傷的嚴重度也影響到症狀的表現以及功能的恢復，根據美國脊髓損傷 協會 (American Spinal Injury Association, ASIA) 所制訂的「ASIA 機能損傷等 級」分為 A 到 E 五級，A 級最嚴重，所有受損部位的運動以及感覺功能都消失，
E 級則最輕，代表運動以及感覺功能都恢復 (王顏和、林光華，1994) 。
2.1.3 脊髓損傷患者的健康問題
脊髓損傷患者因為身體癱瘓而長期缺乏活動、飲食沒有適當的管制以及疾病 本身之影響，發生肥胖的機率比正常人還要高，下半身癱瘓者發生肥胖的機率更 是正常人的 2.5 倍 (Santiago & Coyle, 2004) 。
脊髓損傷患者一旦出現肥胖的問題，身體除了會發生與肥胖相關的併發症 外，比一般人更容易導致肌肉無力、關節變形及心肺功能下降等問題，對生活品 質及日常生活功能造成很大的影響，並且與肥胖相關疾病的危險因子也比一般人 高 (Gawne & Wells, 2003) 。
脊髓損傷患者在受傷後身體脂肪會開始出現堆積的現象，而且體脂肪率比一 般人還高，缺乏活動的脊髓損傷患者體脂肪率甚至達到高危險 (at-risk) 的程 度。這些細微變化對於脊髓損傷患者而言皆具有潛在傷害性，特別是因為肥胖導 致的相關慢性疾病 (Blackmer & Marshall, 1997) 。
肥胖是脊髓損傷患者一個很嚴重的問題，隨著體脂肪的上升會增加心血管疾 病的風險 ， 像是高血壓 、心臟病和代謝症候群 (Gupta, White, & Sandford, 2006) 。而且患者因為長期躺在床上，肌肉萎縮和相對肥胖會造成碳水化合物和 脂肪代謝異常，而慢性脊髓損傷患者的腹部肥胖 (abdominal obesity) 問題又跟代
謝症候群有很大的關係，有研究指出大約 43%的脊髓損傷患者符合代謝症候群的 標準 (Maruyama et al., 2008) 。
2.2 健康資訊管理
過去醫療資訊管理的發展主要是配合醫院在管理上的需求，然而隨著時代的 變遷，醫療資訊必須能夠支援專業的醫療管理需求；此外隨著民眾對於醫療需求 的改變，醫療資訊服務的對象也從醫院轉變成一般民眾，預防醫學和健康促進的 導入便逐漸形成現代的健康資訊管理。
2.2.1 健康資訊管理的發展
健康照護產業在各方面的運作都需要使用資料與資訊，而大量的資料都是在 缺乏固定結構的紙本環境下產生，因此在健康照護的支援上就顯得相當有限。目 前資訊科技正不斷地改變健康照護處理資料 (data) 、資訊 (information) 和知識 (knowledge) 的方法，同時也改變了醫護人員工作的方式。
健康資訊 (Health Informatics, HI) 被定義為電腦科學、資訊科學及健康科學 的總合，我們用它來協助分析和管理資料、資訊和知識，以及支援健康照護與其 運作 (IMIA, 2002) 。現在常常會看到，當資訊學和其他領域科學的名稱連在一 起時，就表示電腦科學與資訊學被用在該領域的資訊管理上。大部分健康照護的 產業都會定義他們自己資訊學的分支，例如公共衛生資訊學，就是指將資訊與電 腦科學應用於公共衛生的研究與學習 (NLM, 2001) 。
健康資訊管理 (Health Informatics Management) 是一種需要規劃、決策與運 用各種資訊科技的過程。健康資訊管理所探討的議題包括：
1. 確保資料的隱私性和安全性 (privacy and security) 。 2. 一般民眾與醫護人員的身分鑑別 (identification) 。
3. 資訊交換的標準和基礎架構 (standards and infrastructure) 。
4. 系統和應用程式間的互操作性與整合 (interoperability and integration) 。 5. 在進行臨床決策、規劃與研究時，能夠提供使用者即時地存取具有品質
的資料 (quality data) 。
電子病歷 (electronic record) 的介入，讓健康照護人員可以存取更多即時 的、可信的及正確的資料。電子病歷必須包含使用者所有過去的照護、治療和實 驗的記錄，包含整個照護過程。目前的紙本病歷無法做到這一點，因為除了國際 疾病分類碼 (International Classification of Disease, ICD) 及一些實驗外，大部分 的紙本病歷都缺乏固定的結構，而且很難取得完整的資料 (Walker, Frean, Scott,
& Conrick, 2003) 。
我們常會聽到許多的專家及健康照護人員常會遺失或放錯紙本病歷，就安全 性的考量，電子病歷可以解決現存的紙本病歷的問題，事實上電子病歷的限制更 多、更安全，再者電腦的錯誤也比人為的錯誤還要少，因此紙本病歷電子化已經 是未來的趨勢。
2.2.2 電子病歷的發展
近年來由於資訊科技的發展 ，電子病歷也迅速的發展起來。 電子病歷 (Electronic Health Record) 是指將一個人的健康或醫療資訊藉由電腦加以儲存的 集合，並可由個人識別碼加以連結。美國病歷協會 (Medical Record Institute, MRI) 將電子病歷的發展，區分為以下五個階段：
第一階段：病歷自動化 (Automated Medical Records, AMR)
病歷自動化階段仍是以紙本病歷為主，藉由電腦協助使部分醫療資料可以自 動產生，將資料列印出後黏貼在紙本病歷上。而此階段的醫療資訊系統是依不同 的工作目的來設計，大多是個別發展，並未進行整合。
第二階段：病歷電腦化 (Computerized Medical Record, CMR)
由於紙本病歷的傳送和儲存對醫療作業而言是一個很大的負擔，此階段是將 病歷系統電腦化，也就是將紙本病歷文件轉換成電子檔的格式，個別的系統有逐 漸地整合和規劃，邁向病歷無紙化的目標。
第三階段：病歷電子化 (Electronic Medical Record, EMR)
與上一個階段不同的地方，在於 CMR 的基本架構與紙本病歷相同，只是將 紙本轉為電子檔；而 EMR 的資料是經過重新整理與安排的，可以在電腦上使用 各種病歷資訊。因此電子病歷是根據不同需求，建立可以提供不同醫療人員運用 的作業環境，以及做為醫療決策的參考依據。
第四階段：電子病患資料系統 (Electronic Patient Record System, EPRS) 相較於 EMR 只專門提供一個機構或系統給自己使用，EPRS 則是一種以病 患為中心的資訊架構，它包含了所有與病患醫療照護有關的資訊，因此比較強調 跨醫院或跨機構的整合平台，建立全國性或全球性的共同資訊交換標準及架構。
第五階段：電子健康資訊 (Electronic Health Record, EHR)
電子健康資訊系統所包含的病患資訊，除了傳統的醫療照護資訊之外，還包 含其他相關照護記錄，甚至個人的相關行為、用藥習慣、生活習慣、飲食及運動 等資訊，構成一個完整的健康資訊系統，這個資訊系統則必須由個人、醫療照顧 提供者以及其它相關人員來共同維護 (張慧朗等，2009) 。
2.3 健康資訊交換機制
目前的健康資訊系統，若是採用特別的健康資訊蒐集方式或是獨特的健康照 護系統，在以後都會漸漸地失去其重要性。對於健康資訊模型的塑模 (modeling) 及資料蒐集的方法，未來把重點放在電子健康記錄的表示方法，以及將電子健康 記錄結合雲端運算 (ubiquitous computing) 來進行資料分享。如此一來才能夠讓 臨床醫護人員對病人進行有效率、有效能且更安全的照護；然而，目前最重要的 是要能夠提昇跨平台及技術的標準需求。
2.3.1 國際健康資訊標準
ISO (International Organization for Standardization， 國際標準組織) 是主要的 國際標準發展組織，它是由一百四十八個國家所組成的網狀國際標準協會，而每 個國家都是基本成員，它有一個隸屬於非政府單位的中央秘書處來協調及聯繫國 家和私人單位。ISO 所扮演的角色，便是帶領組織，使之能夠達到企業的要以及 與日俱增的社會需求 (ISO, 2005) 。
其 他 的國 際 標準 協會 ， 像 是 醫學 數位 影 像及 通 訊標 準 委員 會 (Digital Imaging and Communications in Medicine Standards Committee, DICOM) ，它使用 數位影像及相關資料，來建立及維持專業生物醫學診斷和治療資訊在溝通上的國 際標準。DICOM 的目標是在全球的健康照護系統中，讓影像系統與其他的資訊 系統達到一致性並且改善人工流程，藉此提升系統的效率。
歐洲經濟共同體 (European Economic Community, EEC) 中的國家標準組織 和歐洲自由貿易聯盟 (European Free Trade Association, EFTA) 的國家，都資助歐 洲標準委員會 (European Committee for Standardization, CEN) 。CEN 對這些團體 的貢獻，在於提供自動化的技術標準，包括促進自由貿易、工作安全、網路互操 作性、環境防護、研究開發與程式建立，並讓這些標準公開讓所有人可以自由取 得 (CEN, 2005) ，像澳洲標準的發展也是跟 CEN 的發展同步。
澳洲健康連結策略 (Australian Health Policy Links) 推動了國家電子健康記 錄摘要的發展，突顯澳洲舊有系統間缺乏互相溝通性的問題，並且逐漸成為推動 重要標準開發工作的動力。他也突顯出跨系統間要互動及共同的標準功能如下：
1. 當資訊被建立、被毀壞或被修改時，通知其他系統。
2. 當資訊被新增、被刪除或被改變時，會收到相關訊息。
3. 系統之間可以互相請求資訊。
4. 回應來自其它資訊系統的資訊需求。
表 2.1 健康照護中的標準分類 (張慧朗等，2009)
系統標準
互操作性、整合性能表現以及實用性 所需
IT 系統以及網路運作
設備互操作性
系統互操作性
資訊溝通交流
詞彙標準
將臨床資料以資訊管理與有意義的方 式來蒐集、交換、儲存以及重複使用
資料：資料的描述與結構
分類
詞彙
術語：分為界面術語以及參考術語
訊息標準
在傳輸中建立資料的格式與先後次序
用於資料互換的標準
IT 系統與網路的運作
安全性標準
於實際運作時加以辨識驗證，以及維 護健康資訊的機密性、完整性與適當 的可使用性
資料儲存：電子化健康資訊的結構與
內容
穩私權、認證以及存取控制
將蒐集健康資訊的分類方式進行標準化可以：
1. 提供臨床照護在績效上的衡量，以及支持進行臨床評估的實證方法。在 國家和私人單位提供多樣的服務設置下，評估照護的績效需要有能力去 整合以病人為主的資訊。
2. 導入個案管理和決策支援的系統，以便協調各部分的照護需求 (例如急 性照護、急診、其它社區健康設置、非急性照護設置)
3. 改善病人在健康照護上的安全和品質的監控。
4. 能夠進行統計分析和提供決策制定、政策發展、服務管理、財務管理和 健康研究等方面的健康資訊報告 (Walker et al., 2003) 。
2.3.2 健康資訊交換第七層協定 (HL7)
健康資訊交換第七層協定 (Health Level Seven, HL7) ，它是由國際標準組織 (ISO) 和國際健康照護訊息標準所制定的。HL7 名稱的由來是從開放系統 (Open System Interconnection, OSI) 的 ISO 通訊模型中的七層式架構，而健康照護的臨
床資訊就在第七層 (或是稱為應用層) 中進行處理。HL7 考量應用面上交換資料 的定義、時效以及某些錯誤的傳送，因而支援一些像是安全性檢驗、使用者身分 識別、有效性檢驗、交換協商機制，以及最重要的資料交換結構等功能。
HL7 的應用領域在於臨床和行政方面相關的資料，並且致力於提供交換的標 準，來支援健康照護的資料交換、管理和整合，以及健康照護服務的管理、傳送 和評估。具體來說，期望能創造有彈性且具成本效益的方法、標準、指引、方法 論，以及讓相關的服務在健康照護資訊系統之間能相互的溝通 (HL7, 2010) 。
參考資訊模型 (Reference Information Model, RIM) 是 HL7 第三版開發過程 的基礎，它是一個大型的物件導向式臨床資料模型，它定義了相關訊息所要傳達 的事件之生命週期。它也是一個橫跨健康照護領域的共享模型，更是可以在所有 領域建立自有訊息的模型。RIM 主要在於明確地表示存在於 HL7 訊息範疇裡的 資訊傳送與連結，因此對於提升健康照護服務開發的效率與降低其成本是不可或 缺的工具 (HL7, 2010) 。
HL7 第二版已廣泛的被全球所接受，因為它提供在所有的系統之間做訊息的 交換。第三版已發表但目前並未被廣泛接受，比如說在英國、荷蘭和加拿大，政 府明文規定在開發國有的電子健康資訊系統時使用 HL7 第三版，而在國內目前 也持續的在進行 HL7 第三版文件的翻譯工作。
2.4 健 康 照 護 需 求 塑 模 (Healthcare Requirements Modeling Architecture)
本章節於 2.4.1 先介紹何謂塑模，再於 2.4.2 導入企業架構的觀點，來解釋健 康資訊塑模的階層觀念，健康照護塑模方法於 2.4.3 有初步的解說，而 2.4.4 為本 研究之重點，詳細說明健康照護開發框架(HDF)的每個階段之步驟與表達重點，
最後在 2.4.5 針對領域分析模型進行深入探討，並以此做為本研究之需求塑模方 法論。
從 1980 年代開始，健康照護塑模 (Healthcare Modeling) 已經成為一個關鍵 性的角色，它定義了呈現、儲存、補救與移動健康照護資料的處理過程。在健康 照護資訊系統的設計中，採用過去各種健康照護資訊塑模的方法，已建立今日塑
模方法的基礎。想瞭解如何運用塑模方法，將健康照護資料和資訊進行概念化的 動作，其中最重要的就是要瞭解這些塑模方法以及所使用的塑模語言，也就是統 一塑模語言 (Unified Modeling Language, UML) 。
當澳洲在第五代計算機計畫實施時採用具有潛能的解決方法，使健康照護資 訊得以蒐集、儲存和取得，這個經驗協助國家健康照護計畫在使用資訊技術改良 健康照護的過程中扮演重要角色 (Frean, 2006) 。當健康照護系統面臨發展一致 性的需求，英國資訊管理中心 (Information Management Centre, IMC) 於 1990 年 提倡共同基本規格模型 (Common Basic Specification Model, CBSM) 。這是一個 全面性的資訊模型和程序，而英國資訊管理中心打算讓共同基本規格模型，成為 國民健康保險服務局 (National Health Service, NHS) 在系統開發上的標準 (Jones, 1998) 。
CBSM 試圖為發展藍圖提供指導原則，讓後續的 NHS 或類似的國內及國際 相關計畫實施時，可以依據它來建造。在 1990 年代早期，國際之間透過使用共 同性的原則和方法，使健康照護資訊模型發展得到良好的一致性。今天要達到跨 機構間健康照護資訊互通的目標，也就是要確保電子健康記錄可以有效的傳送，
必須藉由整合這些資訊模型的概念，使它們能夠互補進而達到一致。
2.4.1 資訊需求塑模 (Information Requirements Modeling)
塑模 (modeling) 指的就是一種使用概念性的架構或模型來定義真實世界的 過程，而模型就是被發展來讓大家瞭解哪些工作是解決方案所需的。因此，塑模 可以提供我們達到四個目標：
1. 將系統的樣子以我們所希望的樣子顯現化。
2. 明確地說明系統的架構或系統的行為。
3. 提供一個框架來引導整個系統的架構。
4. 用文件來記錄系統開發時的決策。
設計師通常會用模型將他的構想塑造出外形來，像台北捷運的地圖或是健康 資訊系統的說明圖。在上面的例子當中，模型提供使用者藉由不斷向下分解成更
簡單的各個部分，來描繪出系統複雜的細節或是所涉及的個體。因此，很少有一 個簡單的模型就可以描述出任何真實世界上的事物。
模型可以幫助我們記錄看似複雜的詞彙，或是定義全國性健康體系的健康資 訊需求所需的觀念。另一方面，不同形式的模型也可以用來幫助描述定義系統中 個體的責任所需的單一資料組成。四個塑模的原則確認如下，沒有一個模型足以 描述真實世界中事件或流程的架構 (Booch, Rumbaugh, & Jacobson, 1999) 。
1. 選擇建立何種模型，對於問題如何著手和解決方案如何成形，會有很深 的影響。
2. 每一個模型可能會以不同角度的層次來表達。
3. 最好的模型是能與現實狀況結合。
4. 沒有任何一個模型是充足的，所有有意義的系統都是透過相近的獨立模 型所組成的小集合來達成的。
在研究資訊塑模的時候，通常是用架構 (architecture) 這個名詞來描述處理 的流程和功能，但是健康資訊系統的架構又包含了模型，所以這個名詞被廣泛地 定義一個資訊系統的組織架構 (Rumbaugh, Jacobson, & Booch, 2004) 。因此，以 國家衛生署的架構為例，他大概的描述系統組成元件的結構，和這些元件彼此間 如何連接，以及反映和系統相關的決策。關於系統架構的決定，可以透過模型 (models) 、子系統 (subsystems) 、套件 (packages) 和元件 (components) 來獲得 (Rumbaugh et al., 2004) 。
2.4.2 健 康 照 護 資 訊 塑 模 架 構 (Healthcare Information Modeling Architecture)
為了定義何時 (when) 、何地 (where) 、為何 (why) 與做了何事 (what) 的跨企業資訊管理，而且跟企業規模的大小無關，健康資訊管理和系統設計所在 意的是組織結構的層級或是架構。對組織結構來說，它們的元件部分與關聯部 分，都是以模型與其他物件 (如套件跟元件) 來表示。總和起來，它們形成了企 業架構 (Enterprise Architecture, EA) 。
企業架構提供了一個企業的全域觀點，它們包含了經過包裝而成的互連模 型，而且目的是為了確保企業的任務，從企業的交易、企業程序與系統流程，直 到資訊科技策略與企業的投資。這些模型可以用來描述目前與未來的企業驅動 力，用來支援企業的商業發展。特別是在大規模的發展活動被設計時，像是發展 國家電子健康資訊基礎建設，企業模型就顯得非常的重要。
目前，健康照護資訊的模型大部分採用 Zachman 在 1987 年所提出的企業架 構。之後，ISO 的健康資訊技術委員會 (Health Informatics Technical Committee, HITC) 也接受這套架構做為健康照護塑模方式 (AIHW, 2003) 。Zachman 的矩陣 型架構反映了專案關係人參與的重要性，也包含不同抽象層級的相關模型，來反 映六個關鍵專案關係人的觀點，包含規劃者、擁有者、設計者、建設者以及承包 商和整個工作系統的標準方面塑模 (Zachman, 2010) 。
Zachman 把他企業架構的重點放在連繫各層的模型，希望產生的系統能夠傳 達出企業原始的目標和原則。圖 2.1 提供了一個企業結構方法的概觀圖，以此來 說明一個現代的健康照護模型。
圖 2.1 Zachman 企業架構 (Zachman, 2010)
在這個抽象概念圖的最頂層是情境模型 (context models) ，它從一個較高的 觀點來定義那些和企業相關且尚未決定的整體性概念。在健康照護系統中，這些 模型將會用來表示事件 (events) 、人員 (people) 、環境 (environment) 、管理 (goverance) 、資源 (resources) 等概念。情境模型並不會注重在階層的細節，而 是確認它們關心的概念、情境模型之間的關係，以及系統詞彙。這樣一來，這些 概念可以清楚且一致地被整個企業體系所定義和瞭解。
而第二層的概念模型 (conceptual models) 則是從企業現有的情境模型或策 略計劃所衍生而來的，透過詳細描述這些組成元件之間的關係，來補足情境模型 所缺乏的細節，使得企業概念可以變得更加完整。概念層是為了系統設計，由專 案關係人共同製作而成，而這些人員應該包含技術人員、領域專家以及最終使用 者 (臨床醫護人員) 。
而 邏 輯 資 料 模 型 (logical data models) 和 實 體 資 料 模 型 (physical data models) 則提供了軟體開發者去實現概念層的目標中所需要的細節。它們透過詳 細描述這些對企業而言有意義的組成元件細節以及彼此間的關係，來補足概念層 所欠缺的細節。邏輯和資料模型則是由塑模人員 (系統分析師) 負責，希望可以 和最終使用者更緊密地合作。
在健康照護塑模的過程中，系統塑模者應該完全符合醫護人員的意見以及實 際的工作流程。在 Zachman 的發表中，採用企業架構來進行健康照護資訊的塑 模是非常貼切的，因為準確而詳細地表達健康照護資訊需求在整個技術系統中是 非常重要的。事實上，許多參與資訊塑模的人員同時也具有臨床醫護人員的身 分，他們希望建構出一套確保安全性及準確性的模型。
邏輯資料模型和應用程式彼此間是獨立的，它們對健康照護領域的概念或詞 彙，以及結構 (靜態的) 和行為 (動態的) 方法的具體化及文件化都扮演非常重 要的角色。實體資料模型也是和應用程式相互獨立的，然而它他卻和執行系統的 實體、可替換的部分以及元件的塑造有關。
2.4.3 健康照護塑模方法 (Healthcare Modeling Method)
目前在簡化國家整體企業結構發展的方法中，都把重點放在發展健康照護塑
模的標準化方法。 最近的一個例子就是 HL7 發展框架 (HL7 Development Framework, HDF) ，也就是正式定義健康照護訊息需求，並對這些符合國際標準 規範的訊息進行塑模的方法 (HL7, 2004) 。
HDF 在 HL7 通訊標準發展中定義了七個階段，分別為：
1. 專案開始階段 (Project Initiation Process, PIP) 2. 領域分析階段 (Domain Analysis Process, DAP) 3. 規格設計階段 (Specification Design Process, SDP) 4. 規範描繪階段 (Specification Profiling Process, SPP) 5. 技術描繪階段 (Technology Profiling Process, TPP) 6. 變更控制階段 (Change Control Process, CCP) 7. 出版階段 (Publication Process, PP)
HDF 定義了每一個階段的方法、輸出和輸入，而上述許多階段已使用 UML 的圖形。為了支援這些程序，HL7 發展了一系列的塑模工具，這些工具是可以免 費取得的，而且符合 HL7 通訊標準的發展規範。HL7 已經被用於 HDF 的最終文 件，包含了最近幾年的開發者使用指南。
資訊模型可以依據其他模型做校正和資訊交換，以增加整體健康照護系統的 一致性，它們也提供了知識管理的準則。共同概念性資料模型 (HL7、RIM、CEN、
EN13606-1 和 openEHR ) 和共同概念性元素 (CMETs 和 GPICs) 的出現將會增進 健康照護系統之間的資訊蒐集、儲存、分析、傳遞以及跨平台的資料交換。UML 在模型的連結上扮演一個關鍵的角色，它為最終使用者及系統開發者提供了一個 表示系統需求的方法。一旦健康照護系統架構和標準的開發者，同意將此方法應 用於這些新興的共同概念，就有可能去思考語義互操作性的實現問題。
2.4.4 健 康 照 護 開 發 框 架 (Healthcare Development Framework)
健康照護開發框架 (Healthcare Development Framework, HDF) 規範是由
HL7 的塑模與方法論工作小組 (Modeling and Methodology work group, M&M) 所制定，其目的是分析 (analyze) 、設計 (design) 並記錄 (document) 所有與 HL7 標準相關的程序 (processes) 、政策 (policies) 、文件 (artifacts) ，以及在 HDF 開發手冊中的工作成果 (Singureanu et al., 2009) 。HDF 是一套塑模和管理程序、
政策和資訊傳遞的開發框架，並使用 HL7 標準制定規範，讓不同的健康照護資 訊系統具有互操作性 (interoperability) 。
訊息開發框架 (Message Development Framework, MDF) 是由 HL7 標準在 1997 年所創立，用來描述產生 HL7 第三版訊息 (HL7 Version 3.0) 規範的模型驅 動 (model-driven) 開發方法論。然而這將被 HDF 所取代，因為由 HL7 所產生的 規範開始面臨到互操作性 (interoperability) 多層面的挑戰。包含以下幾點：
1. 資訊模型 (information models) 、資料型別 (data types) 以及詞 彙 (vocabularies) 的規範、
2. 訊息的傳送 (messaging) 、 3. 臨床文件 (clinical documents) 、
4. 情境管理標準 (context management standards) 、
5. 實作技術 (implementation technology) 、檔案 (profile) 以及一致的規範 (conformance specifications) 。
儘管 HL7 標準在深度和廣度上有相當大的差異，但其共同點是使用一個通 用參考模型 (a common set of reference models) 的模型驅動方法論 (model-driven methodology) 、推導規範 (derivation of specifications) 、臨時工作產品 (interim work products) 。
HDF 開發方法論是使用 UML (Unified Modeling Language, 統一塑模語言) 的塑模方法，讓 MDF 使用 UML 來管理基本元件模型，可以更加貼切並呈現良 好的結構，並且採用模型驅動程序 (model-driven process) 到所有由 HL7 創造的 技術規範，而不單單只有在訊息上。HDF 包含多個開發階段和一些預期的成果 (deliverables) ，其中兩個成果就是 HDF 方法論規範以及 HDF 元件模型 (由 UML 方式呈現) ，HDF 參考其它相關的文件並且隨著專案的持續而定期更新。
HDF 的概觀主要包含以下部分：
(1) 產 品 開 發 的 專 案 生 命 週 期 (Project Life Cycle for Product Development, PLCPD)
(2) 專案開始階段 (Project Initiation Process, PIP) (3) 領域分析階段 (Domain Analysis Process, DAP) (4) 規格設計階段 (Specification Design Process, SDP) (5) 規範描繪階段 (Specification Profiling Process, SPP) (6) 技術描繪階段 (Technology Profiling Process, TPP) (7) 變更控制階段 (Change Control Process, CCP) (8) 出版階段 (Publication Process, PP)
HDF 包含了一些完成 HL7 技術和標準所需的文件，以及範例和參考文獻來 支持教學文件和設計指南，圖 2.2 提供了一個高層次的觀點來看 HDF 方法論規 範，並說明了在產品生命週期中以及正在進行變更控制 (例如：技術的更正、增 強的要求、新標準的建立) 的關鍵程序，以下就 HDF 內容進行說明。
act 2: HDF Process Ov erv iew
Change Control Process
Analysis (.7) Design (.8) Specification
Profiling
Technology Specification Project Initiation/
Approval (.5)
8.4 Publication
圖 2.2 HDF 程序圖 (Singureanu et al., 2009)
一、 產品開發的專案生命週期
產品開發的專案生命週期 (PLCPD) ，包含了專案的開始核准 (initiation/
approval) 、分析 (analysis) 、設計 (design) 、規範 (specifications) 。PLCPD 是 反覆循環的處理流程，詳細的描述 HL7 協定規格的開發、擴大和管理，以及 HDF 方法論中每一個階段的細節。
HDF 詳細的描述了 PLCPD 的步驟和文件，此外也提供了範例文件來支持 HL7 標準的開發，下圖提供了深入的觀點來看程序的輸入 (input) 、輸出 (outputs) 以及觸發條件 (triggers) ，HL7 標準的開發在專案核准後開始並遵循以下的步 驟：
1. 任何專案的第一個階段是需求分析，其詳細的步驟都定義在領域分析階 段 (Domain Analysis process) ，需求主要在確認那些自動化的工作流 程 ， 它 們 具 體 的 描 述 可 以 在 不 同 的 系 統 之 間 共 享 的 資 訊 (shared information) 和編碼術語 (coded terminology) ，以及用來交換資訊和展 現系統能力的具體操作。從需求分析產生的文件包括領域分析模型 (Domain Analysis Model, DAM) ，使用 UML 提供了資訊和行為需求的 結合。
2. 領域分析模 型 (DAM) 是規範設計 的基礎 ，也許是一 個功能模 型 (functional model) 、服務規範 (service specification) 或是訊息的定義 (message definition) ，根據專案針對的類型標準而定。標準規範的設計 可直接以參考資訊模型 (Reference Information models, RIM) ，以及 DAM 的內容 (資訊和操作) 為基礎。DAM 和其產生的標準是依靠模 型 (models) 和圖表 (diagrams) 來管理它的內容，以及提供在不同系統 間的資訊和互動的觀點。
3. 標準規範經歷了一個轉變為具體技術文件的過程 (例如：XML schema, Web Service Description Language files, Java code) 。
4. 標準的描繪 (Profiling) 是適應 (adapting) 、定位 (localizing) 或延伸 (extending) 標準規範去實作專案標準的過程。
二、 專案開始階段
在 HL7 專案開發的第一個階段就是專案開始階段 (Project initiation) ，專案 開始和接下來的持續管理有助於確保 HL7 團體可以追蹤哪些規範被開發，以及 他們是如何發展的。專案範圍說明書 (Project Scope Statement, PSS) 明確定義出 工作的需求，以及包含一個對專案的高層次描述。PSS 是一種溝通的工具，可以 讓 HL7 的合作成果達到最佳化，其目的是避免重複的工作，激勵在相同領域的 工作者合作，並確保產生的規範可以跟 HL7 的產品保持連貫性。當 PSS 被核准 後，專案之後的開發狀態會記錄在 HL7 的專案管理軟體 (Project Insight) ，讓其 它人可以在線上看到目前的進度。
三、 領域分析階段
領域分析 (Domain Analysis) 產生一系列的文件，清楚的定義健康照護工作 中該領域的專業人員所熟悉的詞彙，這些文件被包含在領域分析模型 (Domain Analysis Model, DAM) 。HL7 工作小組使用這些文件開發第三版的標準規範，
DAM 中的文件必須明確的讓負責開發規範的領域專家和 HL7 會員可以很清楚地 了解文件的內容。
這部分呈現了一系列內部一致性的過程和技術，分析和記錄互操作性的需求 (interoperability requirements) ，它可以讓領域專家明確的以符合 HL7 標準的方 式來記錄需求，這些過程廣泛使用 UML 2.1 標準的符號和工具。這個階段讓開 發團隊把重點放在健康照護資訊的根本以及標準開發前的程序需求，雖然這個階 段的重點是在標準開發的互操作性需求，但是我們同時也可以分析其它目的或專 案的需求。
需求 (領域) 分析是由那些領域專家和工作分析師來進行，他們代表著使用 者並且了解系統之間的互操作性需求，而且是由健康照護傳送或管理領域的專案 關係人員 (stakeholders) 來定義問題，這部分包含那些健康照護專案關係人員之 間的資訊共享，可能需要收集 (collection) 、匯總 (aggregation) 、報告 (reporting) 和分析 (analysis) 跟工作相關的臨床 (clinical) 、管理 (administrative) 和財務 (financial) 的資料。
DAM 用於開發標準規範，為了達到一致性引用了 HL7 的參考訊息模型
（Reference Information Model, RIM）、結構性詞彙 (structural vocabulary) 以及應 用程序角色 (application roles) 。
四、 規範設計階段
規範設計階段 (SDP) 主要在設計 HL7 標準的規範，規範的需求和參考模型 是規範設計和包裝程序的輸入，而較早或現有的規範也是這個階段的輸入，這個 階段產生的文件主要有：
1. 統一資訊模型 (Harmonized Information Models) 2. 統一動態模型 (Harmonized Dynamic Models) 3. 功能模型 (Functional Models)
4. 詞彙規範 (Vocabulary Specifications)
以上在規範設計階段產生的文件被票選為標準 (例如：資訊的、標準的、試 用的草案) ，但有些專案只公佈文件作為參考規範，有些規範則是根據先前設計 規範做進一步調整或改編，所有的規範都是針對需求而產生，而且會參照 HL7 的參考模型以及早期的設計工作。
五、 規範描繪階段
實作人員為了充分利用 HL7 標準規範，被預期使用一個共同的程序來制定 和澄清 HL7 標準的文件，HL7 提供了豐富的構造來支持在各種不同健康資訊平 台的互操作性，HL7 標準面臨到以下兩個挑戰：
1. 為了提供一個更精確的解決方案到一個特定的要求，它總是可以變得更 具體。
2. 它不會包含所有在各種環境所需要的資料，特別是考慮到國際性需求的 時候。
這些挑戰導致兩個互補性需求的產生： (1) 能夠限制更詳細的標準、 (2) 能夠在控制方式上去延伸標準。為了達到實作上的需求，我們需要兩個關鍵的能
力：
1. 能夠建立一個跟 HL7 標準一致，而且是可以測試的說明書 (testable statement) 。
2. 能夠建立標準的藍圖 (profile) ，並正式定義標準如何使用特定的設定 來實作。
而藍圖和一致性聲明可以透過以下方式去精鍊其標準：
1. 限制和延伸。
2. 定義藍圖的限制和定位。
3. 對於建立一個符合的聲明有明確的界定標準。
4. 解釋 HL7 標準要如何去延伸。
就如同使用許多限制來開發標準一般，我們設計應用程式來實作那些架構，
對於一致性要求和定位規範的定義，都是從基本的標準去限制和延伸。
在分析的過程，模型會進一步的精鍊，而規範也使用相同的設計規則、協定 和準則做進一步的限制，我們應用在規範的開發並且產生規範的藍圖，將可以被 使用者所定義的團體運用在特定的環境。
主要的成果經由規範分析產生一系列的規範藍圖和一致性說明，而規範分析 包含以下步驟：
1. 辨識出藍圖中相關的專案關係人和團體。
2. 進 一 步 的 精 鍊 、 限 制 或 延 伸 規 範 設 計 模 型 (specification design models) 。
3. 發佈規範藍圖並且隨時維護規範。
六、 技術描繪階段
技術描繪階段 (Technology Specification Process) 詳細的敘述在設計規範的 過程中所產生的開發工具和程序，這個階段應用在標準的設計和藍圖的描繪，主
要在描述基於 HL7 標準的特定技術文件的開發程序，這些文件包含 XML Schema Descriptions 以及 Web Service Descriptions。
七、 變更控制階段
當 HL7 會員在開發產品的時候，如果有要求或管理變更的需求就會使用變 更控制程序，這個程序將會：
1. 有助於 HL7 專案關係人員在要求變更時的溝通方便。
2. 提供一個共同的程序來解決要求變更和報告的問題。
3. 減少因工作要求而變更的存在、狀態和結果所帶來的不確定性。
HL7 提供他們的會員一個入口網站，名為「HL7 Project Homebase」，它支援 變更控制、任務管理、調查、發布管理、文件管理和來源控制。HL7 Project Homebase，顧名思義就是可以用來作為 HL7 標準的專案網站，在某種程度上跟 Sourceforge.net 很像，它是目前最成功的開放源始碼專案入口網站。
八、 出版階段
在出版階段的背景、角色及責任、程序及任務、以及最後的出版物都是由各 自的出版工作小組所定義，在 HDF 1.5 中並沒有詳細的定義出來。
2.5 領域分析模型
本研究將 HDF (Singureanu et al., 2009) 應用在居家健康照護需求塑模，對應 到 企 業 架 構 的 概 念 層 ， 我 們 把 重 點 放 在 領 域 分 析 階 段 (Domain Analysis Phase) ，在進行實際的居家健康照護需求塑模後，我們再進行可用性評估，探 討 HDF 在居家健康照護需求塑模上的可用性。
領域分析 (Domain Analysis) 產生一系列的文件，清楚的定義健康照護工作 中該領域的專業人員所熟悉的詞彙，這些文件包含領域分析模型 (Domain Analysis Model, DAM) 。HL7 工作小組使用這些文件開發第三版的標準規範，
DAM 中的文件必須明確的讓負責開發規範的領域專家和 HL7 會員可以很清楚地 了解文件的內容。
這部分呈現了一系列內部一致性的過程和技術，分析和記錄互操作性的需求 (interoperability requirements) ，它可以讓領域專家明確的以符合 HL7 標準的方 式來記錄需求，這些過程廣泛使用 UML 2.1 標準的符號和工具。這個階段讓開 發團隊把重點放在健康照護資訊的根本以及標準開發前的程序需求，雖然這個階 段的重點是在標準開發的互操作性需求，但是我們同時也可以分析其它目的或專 案的需求。
需求 (領域) 分析是由那些代表使用者並且了解系統間互操作性需求的領 域專家和工作分析師來進行，而且是由健康照護傳送或管理領域的專案關係人員 (stakeholders) 來定義問題，這部分包含那些健康照護專案關係人員之間的資訊 共享，可能需要收集 (collection) 、匯總 (aggregation) 、報告 (reporting) 和分 析 (analysis) 跟 工 作 相 關 的 臨 床 (clinical) 、 管 理 (administrative) 和 財 務 (financial) 的資料。
DAM 用於開發標準規範，為了達到一致性引用了 HL7 的參考訊息模型
（Reference Information Model, RIM）、結構性詞彙 (structural vocabulary) 以及應 用程序角色 (application roles) 。
2.5.1 背景
健康照護是由多角度所定義的複雜問題領域所組成，這將導致對於整合臨 床、管理和財務資訊系統的持續性需求，人們普遍同意健康照護專家所說，有效 整合資訊系統是提昇健康照護的效率及品質所必須的。HL7 致力於產生會促進可 計算之語意互操作性 (promote computable semantic interoperability) 的需求文 件。互操作性的範圍必須跨越各種不同的背景，包含臨床上 (clinical) 、管理上 (administrative) 、財務上 (financial) 、個別病人 (individual patient) 、聚集的團 體 (aggregated populations) 、 無 人 式 照 護 (non-human care) 、 社 區 照 護 (community care) 、多償還模型 (multiple reimbursement model) ，並且被定義在 科技中立的格式 (technology-neutral format) 。
2.5.2 角色和工作
這部分在描述需求規範開發的過程中所涉及的角色，然而在能力和計畫許可
之下，一個人有可能同時具備其它角色。
(1) 領域專家
領域專家 (Domain Expert) 是指在相關領域中擁有詳盡的知識以及實務的 經驗的人，他不需要對 HL7 很瞭解，但是他需要對互操作性的概念有高度的認 知。在需求分析的過程中，領域專家會掌握 UML 的工作知識，可以跟工作需求 分析師 (Business Requirements Analyst) 進行有效的溝通。領域專家想像他們在 所進行活動中的角色，具體指出在什麼時候進行，以及思考哪些資訊是需要的。
他們提供在適當的情況下，資料的組成定義以及詞彙的定義。
(2) 工作分析師
工作分析師 (Business Analyst) 對於某些領域及所涉及系統的互操作性需求 是有見識的，他們必須對工作流程有足夠的知識，並且瞭解如何使用整合性系統 來進行工作流程自動化。工作分析師和領域專家合作，進行共享資料的分析以及 所需的商業流程來達到專案的需求。
(3) 塑模推動者
HL7 塑模推動者 (HL7 Modeling Facilitator) 對於應用 HL7 需求分析程序有 相當程度的瞭解，他們負責指導需求規範的開發，以及負責協調所有跟專案需求 分析有關的活動。他們在需求分析階段，很熟練的使用 UML 工具建立模型和觀 點，
2.5.3 程序和任務
在領域分析的過程中，通常需要一些重複性的說明來定義額外的模型和需 求。在需求分析階段，首先定義領域問題，接著建立領域分析模型，包含靜態和 動態的模型文件。圖 2.3 表示領域分析中的主要元素，每個步驟很詳細的用個別 的區塊和活動圖來表示。雖然活動是序列式的，但是領域分析的程序是反覆式 (iterative) 的，而不是像傳統的瀑布式 (waterfall) 先收集需求再進行設計和實 作。
在領域分析活動進行的過程中，也許會出現需要修改或擴大先前文件的情 況。即使在這個程序完成了需求規範 (領域分析模型) ，在 HDF 後續的階段發 現問題時，通常還是需要再回去修改需求文件，可能是需求文件遺失、模糊不清 或是不一致。雖然在模型開發前確立需求是重要的，但是當發現問題時更新領域 分析模型也是很重要的，這個階段的需求文件開發在設計與實作過程應該是可回 溯的 (traceable) 。
act 3: Domain Analysis Ov erv iew
Analyze Business Context
(from 3.4.1 Business Context Analysis) Analyze Use
Cases
(from 3.4.2 Use Case Anal ysis)
Analyze Process Flow (from 3.4.3 Process Analysi s)
Analyze Information Exchanged
(from 3.4.4 Information Anal ysis)
Analyze Business Rules (from 3.4.5 Busi ness Rules Anal ysis)
Story board (from 3.7 Arti facts) Use Case Analysis
(from 3.7 Artifacts)
Process Flow (from 3.7 Artifacts)
Information Model (Analysis) (from 3.7 Artifacts)
Glossary
(from 3.7 Arti facts)
«opti onal»
Business Rules Description (from 3.7 Arti facts)
Business Trigger Analysis (from 3.7 Artifacts)
DAM Approv al Publish DAM
Project Approved Business
Requirements
«outcome»
«outcome»
圖 2.3 領域分析流程 (Singureanu et al., 2009)
表 2.2 領域分析內容
工作需求 工作需求是根據原先計畫章程及後續變更需求進行修改，這些 需求文件記錄使用者的功能性需求，經過分析之後，這些需求 文件可以使用 UML 來描述並精鍊。
發布 DAM 當 DAM 文件完成就可以釋放出來，每個專案都有使用入口網 站來管理文件、模型以及其它文件。
DAM 批准 DAM 的批准需要經過專案團隊、負責小組的同儕審查，這個規 範沒有具體的審查方法，但是確實需要批准 DAM 並發布給 HL7 會員進行最終設計 (標準) 的票選。
(1) 健康照護情境分析
需求文件的第一個階段，經由分析健康照護的健康照護情境來找出具體問題 或需求，可以進一步透過開發新的軟體或是基於 HL7 標準的互操作性來改善，
我們使用一個或多個故事板 (storyboard) 來實現。故事板是藉由描述具代表性的 情節 (scenario) 來說明問題或需求、資訊交換的定義、以及所牽涉的行為者。
這個階段的目的是使用簡單的方式擷取領域專家的知識，以及記錄健康照護 情境的訊息交換。健康照護情境分析是為了確立一個象徵性的情節 (故事板) ， 可以描述程序讓我們自動化地使用專案的開發標準。
(2) 使用案例分析
使用案例分析是用來定義那些支持整合方案的專案或文件，使用案例模型 (Use Case Model) 正式地定義故事板的角色和使案案例，並且將各個角色和他們 所參與的使用案例連結在一起。它可以讓專案或委員會去清楚定義系統將涵蓋的 功能性區域以及所牽涉的角色，使用案例模型是由許多不同的使用案例和角色所 組成。
(3) 程序分析
處理流程 (Process Flow) 用來表示健康照護工作程序自動化所必須的資訊 交換， 在 UML 中，活動圖 (Activity Diagrams) 是針對使用案例圖所描述的健
康照護工作程序，對於其活動和流程進行視覺化 (visualize) 的工具，每個活動 圖都是使用處理流程的方式來表示。
(4) 資訊分析
需求分析最重要的一個部分，便是開發資訊分析文件，讓使用者可以清楚地 了解相關工作目標、它們的相關性 (associations) 及屬性 (attributes) 。這個階段 的目的是記錄系統之間共享的資訊，並以此支援健康照護工作程序。UML 的類 別圖 (class diagrams) 是用來描述出現在訊息中所需的資訊，特定工作程序的結 構文件是使用資訊模型，並以 UML 類別圖來表示，以及由領域專家來撰寫領域 內容的詞彙 (glossary) 並定義程序中的靜態元素。
(5) 健康照護規則分析
這個程序的主要目的，是描述專案或委員在制定像是訊息觸發的訊息規範 時，會如何來記錄額外的健康照護規則。我們使用「對象/實例」 (object/instance) 圖解方式，將此一結構加入到活動圖。健康照護規則分析產生重要的資訊來描述 觸發 (trigger) 資訊交換的任何事件。
2.5.4 需求塑模產生文件
在領域分析和需求描述的過程中會產生一系列的文件，如圖 2.4 所示，包含 了領域分析模型、使用案例分析、故事板、資訊模型分析、詞彙表、處理流程、
工作事件觸發分析、健康照護規則說明。
