國 立 交 通 大 學
資訊學院 資訊學程
碩 士 論 文
設計與實作
一個具有即時產生診療記錄能力的多媒體註解工具
-以健康檢查為例
A Multimedia Annotator Design with Real-time Medical Records
Generator ─ Health Examination Perspective
研 究 生：洪世耀
指導教授：陳登吉 教授
設計與實作
一個具有即時產生診療記錄能力的多媒體註解工具
-以健康檢查為例
A Multimedia Annotator Design with Real-time Medical Records
Generator ─ Health Examination Perspective
研 究 生：洪世耀
Student：Shr-Yao Hong
指導教授：陳登吉
Advisor：Deng-Jyi Chen
國 立 交 通 大 學
資訊學院 資訊學程
碩 士 論 文
A ThesisSubmitted to College of Computer Science National Chiao Tung University in Partial Fulfillment of the Requirements
for the Degree of Master of Science
in
Computer Science July 2012
Hsinchu, Taiwan, Republic of China
設計與實作
一個具有即時產生診療記錄能力的多媒體註解工具
- 以健康檢查為例
學生：洪世耀
指導教授：陳登吉 博士
國 立 交 通 大 學 資 訊 學 院 資 訊 學 程 碩 士 班
摘要
由於醫療資訊的快速發展，目前許多國際組織正致力於發展各種醫療資訊標準，例 如醫療影像上的 DICOM 標準、HL7(Health Level Seven)是醫療資訊科技上共通性標準， 在臨床病歷上定義了 CDA(Clinical Document Architecture)醫療資訊系統間交換電子病歷 格式的標準等。 病人在醫院進行檢查時，會需要經過許多精密的醫療設備檢查，最後產生數位化的 醫療影像，醫生會根據這些檢查結果進行診斷，並簡單的在病歷上記下診斷結果，看診 完後有時間才會使用醫療影像註解系統在醫療影像上進行詳細的註解。由於需要花費額 外的時間去做註解工作，導致醫師使用醫療影像註解系統的意願降低。且醫師在病歷上 所記錄的內容與向病患講解的內容並不一致，因此保留最完整的看診內容將可保障醫病 雙方的權益。 由於目前的註解系統缺乏即時記錄的能力，為了能使醫師在看診當下便能即時將過 程記錄，並在看診完後將看診過程記錄下來產生一份醫學內容，作為醫療影像上的註解 或是看診過程中的完整紀錄，以替醫師省下事後註解的時間，並提升醫師使用註解工具 的意願。因此特別在註解工具的功能上新增畫面錄影及錄音的能力，並於本論文中說明 如何使用此工具配合醫師看診 S.O.A.P.四個階段來使用，使每一次的看診都能詳實的記 錄下看診過程。 醫師替病人安排檢查時，時常需要新增或刪除一些檢查項目，本論文考量此需求， 亦提供樣版抽換的能力，將每個檢查項目樣版化，醫師可以利用此功能客製化病人的檢 查表，快速制定出適合病人的檢查內容，以便日後評估病人的狀況。 本研究所產生的診療紀錄檔格式是依照 HL7-CDA 標準所制定，CDA 是目前國內外 臨床醫療資訊系統所通用的格式，因此本研究所產生的診療紀錄檔具有可被國內外的臨 床醫療系統所共用，以提升本研究的可用性。A Multimedia Annotator with DICOM Compatibility on Digital Medicine Image
Student：Shr-Yao Hong
Advisor：Dr. Deng-Jyi Chen
Degree Program of Computer Science
National Chiao Tung University
ABSTRACT
The rapid development of medical information leads many international organizations committed to develop a variety of medical information standards. Such as DICOM standard is developed for medical imaging. HL7 (Health Level Seven) is a standards of health information technology and CDA (Clinical Document Architecture) defines the standards of health care information systems to exchange electronic medical record in clinical medical records.
Patients are examined through lots of sophisticated medical examinations in the hospital. After those procedures, the digitized medical images would be eventually produced. The doctor would diagnose the patient`s health based on these examination results and write down the diagnostic results on medical records briefly. After then, he has to spend more time to annotate on medical images in detail by using medical image annotator. Time problem described above leads the doctor to decline the willingness of using the medical image annotator, which causes the inconsistence between what the doctor writes down on medical records and what he explains to the patient. Therefore, to retain the most complete medical records would protect the rights of doctors and patients.
The main purposes of this study are saving time for doctors and enhancing the willingness of doctors to use the annotator, and generate the complete medical record while seeing patients, since the annotator in present lacks of the ability of real-time recording. The medical records annotator provides the ability for doctors to record the process of seeing patients at the same time, and produce a medical content as medical image annotation or a complete record of medical records. In this study, the real-time screen recording and audio recording functions are attached in the medical records annotator, and presents about how a doctor uses it in four stages of S.O.A.P. every time to record the process of seeing patient in detail.
The annotator provides templates for each medical examination for doctors to switch examination easily to generate different medical records for patients, such ability fulfill the demand for quickly arranging personalized examinations for patients.
The format of medical record file produced by the annotator in this study is followed by HL7-CDA , which is a general format of clinical information system in present. Hence, the medical records produced by the annotator could be applied to the clinical medical system all over the world to enhance the usability of this study. Key words:HL7, CDA, Annotator, Medical records, DICOM, Screen recording
誌謝
對於此篇論文的完成，首先要感謝指導教授陳登吉老師的指導和教誨，除了在研究 方向及內容的指正，更針對發現問題及解決問題的方法上，時時給予正確的建議。陳教 授不僅在學術上給予我充分的指導，在待人處事、做研究的態度上更是盡心盡力的指引 我，讓我在論文目標上有更明確的方向。同時特別感謝口試委員孔崇旭老師、黃世昆老 師、蔡明志老師，在百忙之中抽空蒞臨指導我的論文，給予寶貴的建議，使得論文內容 更加完備。 此外，要感謝研究室博士班李鎮宇學長的協助，在忙著自己博士論文的同時，犧牲 寶貴的時間，針對我的研究細節一一討論修正。以及在研究過程中，一起同甘共苦的實 驗室夥伴們：佑安、品宏、智華，因為有你們的互相勉勵、分享與討論，讓論文更完整。 感謝公司長官及同事，有你們的支持與後援，我才得以在兼顧工作與課業的情形 下，無後顧之憂的完成學位。 最後必須感謝養育我、栽培我的父母親在背後的大力支持，及新婚老婆-麗芳的體諒 及支持，你們在我求學期間的全心支持與鼓勵，是我努力的原動力，在此致上我最大的 感謝。目錄
摘要 ... i ABSTRACT ... ii 誌謝 ...iii 目錄 ... iv 表目錄 ... vi 圖目錄 ... vii 一、 緒論 ... 1 1.1 研究背景 ... 1 1.2 研究動機 ... 2 1.3 研究目標 ... 3 1.4 章節概要 ... 4 二、 背景知識與相關研究 ... 5 2.1 背景知識 ... 5 2.1.1 SOAP 簡介 ... 5Learning to write case notes using the SOAP format.(subjective, objective, assessment, and plan) ... 5
2.1.2 Health Level Seven(HL7) ... 5
2.1.3 Data Types ... 6
2.1.4 Referenced Information Model(RIM) ... 15
2.1.5 HL7 Development Framework(HDF) ... 16
2.1.6 Clinical Document Architecture(CDA) ... 17
2.2 相關研究 ... 18 三、 註解系統分析、設計與實做 ... 19 3.1 看診時配合多媒體註解系統之過程分析 ... 19 3.1.1 現實世界中的看診流程 ... 19 3.1.2 Subjective 流程 ... 21 3.1.3 Objective 流程 ... 22 3.1.4 Assessment 及 Plan 流程 ... 23 3.2 診療記錄檔設計(CDA 格式) ... 24 3.2.1 健康檢查表的 CDA 文件框架設計 ... 24
3.2.2 Objective Component 設計(CDA 格式) ... 28
3.2.3 Subjective、Assessment 與 Plan Component 設計(CDA 格式)... 29
3.3 註解系統架構說明 ... 32
3.4 各子系統說明 ... 33
3.4.2 註解工具子系統 ... 34 3.4.3 診療記錄儲存子系統 ... 35 3.4.4 診療記錄編輯器 ... 36 3.5 診療記錄編輯器 ... 37 3.5.1 檢查項目選擇器與診療記錄產生器 ... 37 3.5.2 診療記錄輸入工具與診療記錄產生器 ... 39 3.6 實做說明 ... 41 3.6.1 實做使用工具 ... 41 3.6.2 實做結構說明 ... 41 四、 討論 ... 45 4.1 擴充 CDA 格式探討 ... 45 4.2 直接匯入功能 ... 45 4.3 以健康檢查為例之誘因 ... 45 五、 實做展示 ... 46 5.1 展示說明 ... 46 5.2 系統功能展示 ... 47 5.2.1 開啟多媒體註解系統 ... 47 5.2.2 開啟診療紀錄檔 ... 48 5.2.3 選擇檢查樣板 ... 49 5.2.4 儲存螢幕錄影檔案作為註解 ... 51 5.2.5 儲存診療紀錄檔 ... 52 5.2.6 匯入診療紀錄檔 ... 56 5.2.7 診療紀錄導覽功能 ... 57 5.2.8 新增/刪除 診療紀錄檔上註解或檢查項目以及診療紀錄檔上傳 ... 58 5.3 播放螢幕錄影及錄音檔 ... 59 5.4 醫療影像多媒體註解工具 ... 60 六、 結論 ... 61 6.1 總結 ... 61 6.2 未來發展方向 ... 61 REFERENCES ... 62
表目錄
表 1 註解工具功能比較表 ... 2
表 2 Overview of HL7 version 3 data types ... 8
表 3 Domain media type ... 12
表 4 健康(體格)檢查表... 24 表 5 CDA 文件樣板 ... 28 表 6 Objective Component(CDA 格式) ... 29 表 7 Subjective Component(CDA 格式)... 30 表 8 Assessment Component(CDA 格式)... 30 表 9 Plan Component(CDA 格式) ... 31 表 10 Subjective 階段產生的診療紀錄檔範例 ... 52 表 11 本論文特色比較表 ... 61
圖目錄
圖 1 SOAP 簡介 ... 5
圖 2 UML Overview of Data Types ... 6
圖 3 最新版 RIM 圖 ... 15
圖 4 RIM 六個核心物件間的關係 ... 16
圖 5 HL7 Message Development and Framework ... 17
圖 6 CDA R2 之 RMIM ... 18 圖 7 看診流程 ... 20 圖 8 SOAP 流程 ... 20 圖 9 Subjective 流程 ... 21 圖 10 Objective 流程 ... 22 圖 11 Assessment/Plan 流程 ... 23 圖 12 系統架構 ... 32 圖 13 診療記錄顯示子系統 ... 33 圖 14 註解工具子系統 ... 34 圖 15 診療記錄儲存子系統 ... 35 圖 16 診療記錄編輯器 ... 36 圖 17 檢查項目選擇器 ... 37 圖 18 診療記錄產生器(角色:註解系統) - Objective 部分新增/刪除檢查項目 ... 38 圖 19 診療記錄輸入工具 ... 39 圖 20 診療記錄產生器(角色：註解系統) - S.O.A.P.更新診療記錄 ... 40 圖 21 使用者介面示意圖 ... 42 圖 22 註解系統 Class Diagram... 42
圖 23 textAnnotations Class 及 fileChooserSet Class... 43
圖 24 PatternPanel Class 及 SAPPatternPanel Class ... 44
圖 25 PatternSelecterPanel Class ... 44 圖 26 系統開啟初始畫面 ... 47 圖 27 開啟診療紀錄檔 ... 48 圖 28 開啟檢查樣板選擇器 ... 49 圖 29 插入檢查樣版後的畫面 ... 50 圖 30 將螢幕錄影及錄音檔作為多媒體註解 ... 51 圖 31 儲存檔案 ... 52 圖 32 匯入診療紀錄檔 ... 56 圖 33 匯入歷史資料後之畫面 ... 57 圖 34 診療記錄導覽器 ... 57 圖 35 開啟選擇器以新增/刪除診療紀錄檔上的註解或檢查項目 ... 58 圖 36 螢幕錄影及錄音檔播放器 ... 59
一、緒論
1.1 研究背景
全球的醫療產業已隨著資訊科技與網路技術的進步，漸漸地從傳統的作業模式朝向 數位化的方向轉變，醫療院所開始積極開發各類醫療系統，同時為了使醫療資源能不受 時間與空間的限制而能被快速的被分享，各醫療系統間透過網路交換大量資訊，其交換 過程透過彼此都能了解的資料及傳輸上的協定以進行通訊及解讀的動作。因此，為了能 順利整合各醫療系統及資源，國際團體開始制定各種醫療系統間資料及交換上的標準， 例如 HL7[1][2][3]是為了醫療資訊系統而設計的標準、CDA[4][5]是依照 HL7 標準制訂 出來對於電子病歷格式的標準、DICOM[6]是為了醫療影像系統能在網路上交換醫療影 像及醫療影像上其他相關資訊而設計的標準，此外還有 LONIC[7]、SNOMED CT[8]臨 床紀錄編碼的標準等…諸如此類。 由於醫療資訊系統的發展，以及政府大力推展「病歷無紙化」與「醫療影像無片化」， 現今許多醫生已直接將看診的資料直接輸入在電腦裡，而非記錄在紙本上；而醫療影像 目前也可透過醫療影像註解工具進行註解，醫生可透過這些註解工具所提供的功能，以 文字、圖片、聲音或影像完整的在醫療影像上加上自己專業的意見，俾供日後參考使用。目前已經有許多註解工具的相關研究，例如 F. Wang,、C. Rabsch, 及 P. Liu 所於 2008 年所提出的「Native Web Browser Enabled SVG-based Collaborative Multimedia Annotation for Medical Images」[9]，乃利用 Web2.0 技術在網路上分享醫療資訊及 HTML 可以跨平 台的特性，結合 Scalable Vector Graphics(SVG)及 Asynchronous JavaScript and XML(AJAX) 等技術，建立一個能供使用者能不限平台，在任何平台上皆可透過瀏覽器來觀看、共同 分享醫療影像上的註解，並可合作在醫療影像進行註解的工具。I. F. Amaral, F. Coelho, J. F. P. da Costa, 及 J. S. Cardoso 於 2010 年提出「Hierarchical Medical Image Annotation Using SVM-based Approaches」[10]，目的在於將一部分註解的過程自動化，使醫療影像 能快速的被分類，減少繁瑣的人工註解所花費的時間。 在醫療實務上，醫生會依據病人所描述的情況去安排檢查項目，透過一些精密的儀 器，如核磁共振(MRI)、電腦斷層攝影(CT)、正子斷層攝影(PET)及 X-ray 等不同醫療器 材，去得到更多的訊息。醫生根據這些檢查結果綜合病人先前的主觀描述進行病情分析 診斷，之後再向病人解說病情，這時除了徒手向病人講解外，亦可在醫療影像圖上向病 人進行解說。因為看診時間比較匆促，解說完畢後，醫生大都只會在電子病歷上以文字 進行簡單的註記後結束看診。而一些較為詳盡的註解，往往是醫生另外找時間利用註解 工具提供的各類功能，事後將自身專業的意見補充上去。因此在目前註解工具的開發 上，是否提供足夠的註解能力好讓使用者能更便利的產生註解，成為使用者是否願意使 用註解工具的主要原因。
目前市面上已有許多醫療影像註解工具，這些工具所提供的功能大致上都包含：
1. 註解編輯：提供基本的文字註解能力並以箭頭指向註解點。
2. 影像處理：影像模糊化、銳利化、邊緣偵測及刮痕去除…
3. 支援各類影像格式：可顯示及匯出 JPEG, TIFF, GIF, PNG, BMP 等影像格式。
4. 支援 DICOM 影像處理及傳輸：能顯示 DICOM 醫療影像及所包含之資訊，並 支援 DICOM 傳輸協定的功能。 5. 影像調整：可調整亮度、大小、旋轉影像… 我們可以發現目前所有註解工具都缺少即時記錄看診內容以成為本次看診註解的能 力。 目前市面上的醫療影像註解工具，所提供的功能整理如下表：
1.2 研究動機
綜合上述，我們可歸納註解產生的過程如下： 1. 醫師根據醫療影像及各種檢查後的資料進行診斷。 2. 將診斷結果告知病患，並將診斷結果以文字方式記錄在電子病歷上。 3. 醫師在診斷後另外花時間利用各種註解工具，根據其診斷內容，在醫療影像上 加上更詳細的註解。 目前醫療影像註解系統主要是提供上述第三點有關看診後進行註解的能力，並提供 許多實用的功能供醫師使用，只是在實際作業面上，我們可以發現以下問題： 1. 現存的醫療影像註解工具沒有即時記錄的功能 2. 醫師需要花費額外時間在醫療影像上註記，導致醫師使用醫療影像註解工具的 表 1 註解工具功能比較表意願降低。 3. 醫師於看診時向病人解說的病情和記錄於電子病歷上的內容不一致。 由於醫師本身工作就已經很忙，如果在看診後還需要犧牲自己的休息時間替每一位 病患做詳細的病情註解，對醫師而言將會是一項沉重的負擔，因此大部分的醫師都不太 願意去使用醫療影像註解工具，但是目前的醫療影像註解工具對此問題卻並未提供一個 好的解決方案，導致醫療影像註解工具的實用性大為降低。此外由於醫師記錄於電子病 歷上的內容和他向病人解說的內容可能不一致。此時對病人的權益而言，他需要的是看 診時的完整內容；對醫生而言，情況可能是醫生已向病人解說過，而病人也回答了醫生 的問題，但是出問題時病人卻否認醫生有說過，或是病人曾回答過該內容。此時即時記 錄看診過程的內容將可證明醫師是否已盡了告知並善盡了解的義務，保護了醫病雙方的 權益。
1.3 研究目標
本論文發現上述問題存在，希望能設計出一個具有「即時產生診療記錄」能力的多 媒體註解工具(以下簡稱「多媒體註解工具」)，目的是當醫師使用這套多媒體註解工具 時，能在看診完後就即時產生出一份診療記錄，這份診療記錄記載了醫師完整的看診過 程，包含 Subjective、Objective、Assessment 及 Plan 等過程[11][12](簡稱 S.O.A.P.，參考 2.1.1)，並簡化註解產生的流程，使註解工作能在向病患解釋病情時就能順便完成，以 減輕醫師事後進行註解的負擔。 本研究在功能上亦提供醫師及時抽換檢查項目的能力，醫師可隨時依據病人情況決 定檢查項目，或新增/刪除註解項目。 在產生的診療紀錄檔上，符合 HL7 所制定出臨床電子病歷的架構，能適用於各醫 院的電子病歷系統，快速的在各醫院間傳遞資訊。 依據上述內容，本論文之目的為研究出一種具有「即時產生診療記錄」能力的多媒 體註解方法，使滿足以下需求，條列如下： 1. 提供可調性(Flexible)的 SOAP 樣板 2. 即時記錄樣板化之 SOAP 各階段看診過程 3. 可儲存到診療記錄伺服器 4. 可提供醫療人員或病患存取診療記錄 5. 診療記錄相容於 HL7-CDA 格式1.4 章節概要
本論文的章節內容摘要如下： 第一章「緒論」，說明本論文的研究背景與動機，以及研究的目標。 第二章「背景知識與相關研究」，說明欲了解本論文所需的知識與相關研究之規格及 文獻。 第三章「系統分析、設計與實做」，說明本研究的設計及實做。 第四章「討論」，對本研究面臨的問題進行討論及說明。 第五章「實作展示」，透過範例的展示，說明如何在看診時搭配多媒體註解工具產生 診療記錄，以及多媒體註解工具所提供的編輯診療記錄的能力。 第六章「結論」，本研究的總結，並建議未來可以繼續發展的方向。二、背景知識與相關研究
2.1 背景知識
2.1.1 SOAP 簡介
SOAP(Subjective、Objective、Assessment 及 Plan 的縮寫)是一個醫療人員撰寫病歷 記錄的方法，在病歷的格式上大都以此種格式為依循，是根據醫師看診的實際流程所歸 納出來的方法，以此格式撰寫的病歷被認為能完整的記錄病人的背景資料、看診的過 程、檢驗的結果與醫師的專業的意見等。 圖 1 SOAP 簡介 資料來源：How To Write A History/Physical Or SOAP Note On The WardsLearning to write case notes using the SOAP format.(subjective, objective, assessment, and plan)
2.1.2 Health Level Seven(HL7)
HL7 是一個國際組織的名稱，也是一種用於醫療照護領域方面的標準，其命名的 意義來自於 OSI 七層模型[13]，意指此標準是架構在 OSI 模型第七層 Application Layer 上。其主要目的是提供醫療資訊系統間交換訊息的標準、優化資訊系統開發流程以及減 少醫療資訊上的歧義，並提升醫療提供者、政府及相關團體在有關醫療知識轉移上的效 率。使所有醫療資訊能有效地互通與分享，並且管理與整合相關的健康資訊，藉此提高 醫療照護品質，並提升病人安全。 HL7 組織的主要策略如下： 1. 制定連貫的，可擴展的標準。並允許結構化，以及照顧病人方面的健康保 健訊息的編碼方式，使應用程式在交換訊息時能保持原有的含意。 2. 制定一個正式的方法來支援以 HL7 Reference Information Model（RIM）進
3. 向醫療行業，決策者和一般公眾有關醫療衛生信息標準化的好處及 HL7 標準。 4. 通過建立 HL7 國際聯盟組織，使世界各地參與發展 HL7 標準和所需要的 本地化的 HL7 標準以推廣 HL7 標準。 5. 刺激，鼓勵和促進醫療保健行業的利益相關者組織領域的專家，參與制定 其專業領域的 HL7 醫療信息標準。 6. 與其他標準制定組織及國家和國際認可的機構（如 ANSI 和 ISO）在醫療 和信息基礎設施領域合作，以促進支持性和兼容性的標準的使用。 7. 與醫療信息技術用戶合作，以確保 HL7 標準滿足現實世界的要求，並且由 HL7 發起適當的標準制定工作，以滿足緊急需求。
2.1.3 Data Types
HL7 v3 為了在表現力(representation)及實作技術(implementation technology)上提供 開放性的特性，因此設計成抽象語意的資料型態(abstract semantic data type)[14][15]。所 有 HL7 v3 的規格都被認為是獨立於任何特定的表現及實作技術的形式。HL7 標準主要 是針對醫療照護領域的資訊，它並不會與醫療技術相依，而是獨立於技術之外去表現醫 療照護上的資訊，其目的是在於就算未來有更新穎的技術出現，這樣的資料型態定義仍 可適用於新技術上。 有別於 HL7，其他的實作技術上，在資料型態的定義方面往往太過於彼此相依， 這會導致一定程度的危險性，HL7 嘗試去克服此問題，才將資料型態定義成抽象的。 圖 2 是一張以圖形表示 Data Type 之間的相互關係的 UML 圖。Data Type 的 class 以縮寫名稱在 UML 上表示。Type 的屬性以 UML 上的 operation 表示。圖 2 UML Overview of Data Types
資料來源：Data Types - Abstract Specification - HL7 Org UML Overview of Data Types - HL7 Org
下表 2 列出 HL7 所有 data types，大致上可分為下列七類： 1. Fundamental Data Types
(1) DataValue (ANY): 所有資料值的最基本屬性。就好像物件導向中的 object 類別。
(2) Boolean (BL): 二元值。BL 可能的內容值為 true 或 false，或者其他內容 值，但都視為 NULL
(3) BooleanNonNull (BN): BN 是限制 Boolean 不可為 NULL。 2. Quantity Data Types
(1) Physical Quantity (PQ): 量測的數量型態。
(2) Physical Quantity Representation (PQR): 量測的數量型態，但是其單位是遵 循某編碼系統。可作為 PQ 另一種表達方式。
(3) Monetary Amount (MO): 貨幣數量型態。 (4) Integer Number (INT): 整數。
(5) Real Number (REAL): 實數。 (6) Ratio (RTO): 比率。
(7) Point in Time (TS): 某時點。 3. Generic Data Types
(1) Interval (IVL): 某排序資料型態的區間值集合。 (2) Sequence (LIST): 已排序之項目集合。
(3) Set (SET): 未排序之項目集合
(4) Bag (BAG): 未排序之項目集合，但每個項目又可以包含更多項目。 4. Timing Specification Data Types
(1) Periodic Interval of Time (PIVL): 週期性發生的區段時間。
(2) Event-Related Periodic Interval of Time (EIVL): 基於某活動所引發之特殊性 周期性時間區間。.
(3) General Timing Specification (GTS) ：概念性任意時間區間集合。(last
Tuesday of each month)
5. Text and Multimedia Data Types
(1) Binary Data (BIN): BIN 一組位元之集合。
(2) Encapsulated Data (ED) :主要目的是可讓人直接解析，或者進一步讓機器 處理之。(是非常重要的資料型態)
(3) Character String (ST): 字符串資料型態是文字資料，提供給機器處理 (sorting, querying, indexing)
6. Demographic Data Types
(1) Postal Address (AD): 郵寄、住家或辦公室地址。 (2) Entity Name (EN): 人、組織、地方或事物之名稱。 (3) Trivial Name (TN): 具限制性之實體名稱。
(4) Person Name (PN): 當 EN 是用在人時，則特別使用此資料型態。
(5) Organization Name (ON):當 EN 是用在組織時，則特別使用此資料型態。 7. Thing Data Types 又可再細分為
a、 ISO Object Identifier (OID): 全域唯一辨識碼，其內容值例如： 2.16.840.1.113883.3.1。
b、 Instance Identifier (II): 用以辨識唯一的事件或物件。
c、 Unique Identifier String (UID): 一種用來標識物件的全球唯一辨識碼。 d、 Universal Unique Identifier (UUID): 讓分散式系統中的所有元素，都能
有唯一的辨識資訊。 (2) URL and TEL Data Types
a、 Universal Resource Locator (URL) : 遵從 IETF 與 W3C 之規範。 b、 Telecommunication Address (TEL): 任何可提供通訊之資料，如電話號
碼、e-mail 地址、或者其他可以定位資源的資訊。 (3) Concept Descriptor Data Types
a、 Concept Descriptor (CD) : 用以參照或引用定義於某 coding system 之 編碼。
b、 Concept Role (CR) : 提供可選擇性之編碼。
c、 Coded with Equivalents (CE): 除主編碼資料外還包含了相等值之資料。 d、 Coded Value (CV): 包含編碼資料只包含了編碼、編碼系統與可選的顯
示名稱與原始文字
e、 Coded Simple Value (CS): 編碼資料為簡化格式，主要是因其編碼未有 預設值。現階段只能知道編碼系統與其版本。
f、 Coded Ordinal (CO): 編碼資料具排序。
g、 Character String with Code (SC): 一個字符串可能有攜帶編碼。
表 2 Overview of HL7 version 3 data types
Name Symbol Description
DataValue ANY
Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type.
Boolean BL BL stands for the values of two-valued logic. A BL value can be either true or false, or, as any other value may be NULL.
BooleanNonNull BN
BN constrains the boolean type so that the value may not be NULL. This
type is created for use within the data types specification where it is not appropriate for a null value to be used
Encapsulated Data ED
Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information
Name Symbol Description
in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an ED may contain only a reference (see TEL.) Note that ST is a specialization of the ED where the mediaType is fixed to text/plain.
Character String ST
The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions.
Concept Descriptor CD
A CD represents any kind of concept usually by giving a code defined in a code system. A CD can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A CD can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the
CD need not contain a code but only the original text describing that
concept.
Coded Simple Value CS
Coded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set.
Coded Ordinal CO
Coded data, where the coding system from which the code comes is ordered. CO adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain. Coded With
Equivalents CE
Coded data that consists of a coded value and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist.
Character String with
Code SC
A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.
Instance Identifier II
An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers.
Name Symbol Description
Address resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose.
Postal Address AD Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc.
Entity Name EN
A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe".
Trivial Name TN A restriction of entity name that is effectively a simple string used for a simple name for things and places.
Person Name PN
An EN used when the named Entity is a Person. A sequence of name parts, such as given name or family name, prefix, suffix, etc. A name part is a restriction of entity name part that only allows those entity name parts qualifiers applicable to person names. Since the structure of entity name is mostly determined by the requirements of person name, the restriction is very minor.
Organization Name ON An EN used when the named Entity is an Organization. A sequence of name parts.
Integer Number INT
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity.
Real Number REAL
Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal digits is known as the precision.
Name Symbol Description
Ratio RTO
A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and
denominator are not automatically cancelled out. The RTO data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the REAL should be used instead of the RTO.
Physical Quantity PQ A dimensioned quantity expressing the result of measuring.
Monetary Amount MO
An MO is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between PQ and MO, and the reason why currency units are not physical units.
Point in Time TS A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression.
Set SET A value that contains other distinct values in no particular order. Sequence LIST A value that contains other discrete (but not necessarily distinct) values in
a defined sequence.
Bag BAG An unordered collection of values, where each value can be contained more than once in the collection.
Interval IVL A set of consecutive values of an ordered base data type.
History HIST
A set of data values that have a valid-time property and thus conform to the HXIT type. The history information is not limited to the past; expected future values can also appear.
Uncertain Value -
Probabilistic UVP
A generic data type extension used to specify a probability expressing the information producer's belief that the given value holds.
Periodic Interval of
Time PIVL
An interval of time that recurs periodically. PIVL has two properties, phase and period. phase specifies the "interval prototype" that is repeated every ..
Name Symbol Description
Periodic Interval of Time
activities of daily living or other important events that are time-related but not fully determined by time.
General Timing
Specification GTS
A <dt-TS>, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours.
Parametric Probability Distribution
PPD
A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution.
其中最重要的就是「Text and Multimedia Data Types」，本論文之後會大量使用此種
資料型態作為診療記錄中指向外部連結檔案的方式。Encapsulated Data(ED)依據 HL7 的 定義，主要是給人解讀的資料，或是更進一步給 HL7 範圍以外的機器處理用的資料。 它包含已格式化或未格式化的語言、多媒體資料或以不同標準定義出的結構化資訊(例 如..XML-signatures)，ED 可能只是個 reference 而非資料本身；ST 即為當 ED 的 media type 為 text/plain 時的特例。它主要支援檔案類型有 jpeg、gif、DICOM、mp3、video/mpeg… 等(請參閱表 3)。
表 3 Domain media type
code name status Definition
text/plain Plain Text required For any plain text. This is the default and is equivalent to a character string (ST) data type.
text/x-hl7-ft HL7 Text recommended
For compatibility, this represents the HL7 v2.x FT data type. Its use is recommended only for backward compatibility with HL7 v2.x systems.
text/html HTML Text recommended
For marked-up text according to the Hypertext Mark-up Language. HTML markup is sufficient for
typographically marking-up most written-text
code name status Definition
deployed.
application/pdf PDF recommended
The Portable Document Format is recommended for written text that is completely laid out and read-only. PDF is a platform independent, widely deployed, and open specification with freely available creation and rendering tools.
text/xml XML Text indifferent
For structured character based data. There is a risk that general SGML/XML is too powerful to allow a sharing of general SGML/XML documents between different applications.
text/rtf RTF Text indifferent
The Rich Text Format is widely used to share word-processor documents. However, RTF does have compatibility problems, as it is quite dependent on the word processor. May be useful if word processor edit-able text should be shared.
application/msword MSWORD deprecated
This format is very prone to compatibility problems. If sharing of edit-able text is required, text/plain, text/html or text/rtf should be used instead.
audio/basic Basic Audio required
This is a format for single channel audio, encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz. This format is standardized by: CCITT, Fascicle III.4 -Recommendation G.711. Pulse Code Modulation (PCM) of Voice Frequencies. Geneva, 1972.
audio/mpeg MPEG audio
layer 3 required
MPEG-1 Audio layer-3 is an audio compression algorithm and file format defined in ISO 11172-3 and ISO 13818-3. MP3 has an adjustable sampling frequency for highly compressed telephone to CD quality audio.
audio/k32adpcm K32ADPCM
Audio indifferent
ADPCM allows compressing audio data. It is defined in the Internet specification RFC 2421
[ftp://ftp.isi.edu/in-notes/rfc2421.txt]. Its implementation base is unclear.
code name status Definition
image/png PNG Image required
Portable Network Graphics (PNG)
[http://www.cdrom.com/pub/png] is a widely supported lossless image compression standard with open source code available.
image/gif GIF Image indifferent
GIF is a popular format that is universally well supported. However GIF is patent encumbered and should therefore be used with caution.
image/jpeg JPEG Image required
This format is required for high compression of high color photographs. It is a "lossy" compression, but the difference to lossless compression is almost
unnoticeable to the human vision.
application/dicom DICOM recommended
Digital Imaging and Communications in Medicine (DICOM) MIME type defined in RFC3240 [http://ietf.org/rfc/rfc3240.txt].
image/g3fax G3Fax
Image recommended This is recommended only for fax applications.
image/tiff TIFF Image indifferent
Although TIFF (Tag Image File Format) is an international standard it has many interoperability problems in practice. Too many different versions that are not handled by all software alike.
video/mpeg MPEG
Video required
MPEG is an international standard, widely deployed, highly efficient for high color video; open source code exists; highly interoperable.
video/x-avi X-AVI
Video deprecated
The AVI file format is just a wrapper for many different codecs; it is a source of many interoperability
problems.
model/vrml VRML
Model recommended
This is an openly standardized format for 3D models that can be useful for virtual reality applications such as anatomy or biochemical research (visualization of the steric structure of macromolecules)
2.1.4 Referenced Information Model(RIM)
RIM[16]是 HL7 v3 開發流程中最基本的資料模型，RIM 的物件模型作為 HL7 v3 方法論的一部分，是臨床資料領域（domain）的大型圖示，並可用來標識一個訊息或一 組相關的訊息所攜帶之事件的生命週期；它是所有領域（domain）以及領域（domain） 所自訂之訊息皆共享的資料模型，並明確表現出 HL7 訊息所攜帶的資訊之間連接關係 之存在。 RIM 大略可分為六個核心物件，分述如下：1. Act：代表每一個正在發生的行為，如 Procedures, observations, medications, supply, registration 等。
2. Entity：用來扮演 Role 的實體，如 persons, organizations, material, places, devices 等。
3. Role：用來代表參與者，如 patient, provider, practitioner, specimen, employee 等。 4. Act_Relationship：用來連結 Acts，如 composition, preconditions, revisions, support
等。
5. Participation：連結描述 Roles 所參與的行為(Acts)，如 author, performer, subject, location 等。
6. Role_Link：描述 Roles 之間的關係。
RIM 圖如下：
圖 3 最新版 RIM 圖
六個核心物件間的關係如下：
2.1.5 HL7 Development Framework(HDF)
HDF[17]的目的是將研發 HL7 發佈規格及標準的過程、政策及相關構件進行研究， 分析，設計與文件化。
下圖 5 是 HL7 Message Development Framework(MDF)，HL7 v3 將 HDF 視為 MDF 的延伸，根據圖五我們可以得知 HL7 在 Message Design 上，皆以 RIM 為基礎，各醫學 領域(medical domain，如 Clinical Document Architecture…等)所需的 Message 皆繼承自 RIM，也就是由 RIM 可衍伸出適合各種不同領域的醫學訊息，而每個 Domain Message Information Model(DMIM)又可以視為是許多 RMIM(Refined Message Information Model) 的集合，RMIM 也就是把 RIM 給定某些屬性後，就代表了某特定用途之類別，就像是 在 UML 模型中，所設計出的皆為 Class，一旦給了 Class 某些值，就變成 Object 的意思。 Hierarchical Message Description(HMD) 將 RMIM 中所定義的 elements(如 classes、屬性 及關聯)的順序以表格方式呈現，並定義出不需參考實作技術的訊息。其目的是為了提 供串列資料能以特定上下文組成進行交換並增加額外的限制到其對應的 RMIM 上。他們 會基於 state-transition 或觸發類型而定義。Message Types（MT）則是一個可用於資料交 換的消息的特定規格。任何一個 RMIM 或 HDM 可以各種方式進一步限制來創建一組密 切相關的 Message Types，然後再以 XML 的線性字串進行交換，並使用 XML Schema 驗證。
本論文將會使用 HL7 所定義用於臨床文件領域上的標準 Clinical Document Architecture(CDA)來實作我們的 SOAP 診療記錄檔，關於 CDA 的內容請參閱 2.1.6。
Participation Role Entity Role_Link Act Act_Relationship plays scopes
has target has source Participates in
has
has source has target
圖 4 RIM 六個核心物件間的關係 資料來源： Introduction to: HL7 Reference Information Model (RIM)
2.1.6 Clinical Document Architecture(CDA)
CDA 被設計專門用在臨床文件上語法(syntax)與框架(framework)上的標準，它能包 含目前所有的臨床內容，並可以此標準產生各類如出院病歷摘要(Discharge Summary)、 轉診單(Referral)、病程記錄(Progress Note)、疾病史(H&P)及公共衛生報告(Public health report)等文件。CDA 是根據 RIM 並使用 HL7 v3 的 Data Type 及 Methodology 產生。CDA 以 XML 為基礎，CDA 中的 XML 的標籤是參考 RIM 而定義的，CDA 的規格裡詳細介 紹了文件與模型間的關係，並包含了一個由 RIM 所產生的 RMIM，RMIM 藉由限制 (constrains)RIM 來定義出可用於臨床文件上的更精確的參數。
因為 CDA 採用 XML 為基礎，將 CDA 文件透過 XSL 樣式表可轉換成 HTML 格式， 可在任何瀏覽器上顯示 CDA 文件。
CDA 文件的 RMIM 圖形一覽如圖 6，一份 CDA 文件包含 Header、Body、Entry 以 及 external reference 等四大部分，本論文僅使用到 Header、Body 及 Entry 等部分，分別 就這三部分略述如下：
1. CDA Header：這部份包含文件可用來作為發現、管理、搜尋文件所需的 metadata 資訊，並提供有關認證(authentication)、診療(encounter)、病患及提供者(provider) 的資訊。
2. CDA Body：為臨床報告的主體，也就是可作為出院病歷摘要等文件內容的區 塊，在概念上可切分為巢狀的 sections，並且每個 section 中包含有可用來呈現 結構化的(structured) entries 及外部連結(external reference)的 narrative block。 3. CDA Entry：規範 Section 內容應包含哪些欄位及編碼的細項資訊。
圖 5 HL7 Message Development and Framework 資料來源：HL7 Development Framework (Jan-2003)
2.2 相關研究
Seok-Hwan Jang 及 Whoi-Yul Kim 在 2004 年六月提出一份論文，名稱是「Defining a new annotation object for DICOM image: a practical approach.」[18]，內容是有關在手持 裝置(如 PAD 或 Tablet)上利用數位筆進行註解的研究。此研究是在原本的 DICOM 醫療 影像上覆蓋一層 Channel，在這層 Channel 上會記錄數位筆所畫過的軌跡，並記錄成 Grayscale Softcopy Presentation State (GSPS)格式，此格式為向量圖形，是 DICOM 2000 標準可接受的註解格式，利用此種格式能簡單的將數位筆畫過的軌跡記錄下來，記錄在 和 DICOM 圖形重疊的 channel 上，利用數位筆在重疊 channel 進行註解，不但能使不擅 長使用手持裝置打字的醫師能更便利的在臨床檢查時即時進行註解，也不會影響到原本 的 DICOM 圖，並且做出的醫療影像註解亦符合 DICOM 格式。
M. Möller 及 S. Mukherjee 在 2009 年 提出的 論 文 ，名稱 是「 Context-driven ontological annotations in DICOM images: towards semantic PACS」[19]，內容是討論目前 醫師可以利用 DICOM Header 中的屬性查到相關醫療影像，但這些影像內的屬性卻大部 分不包含任何與解剖或疾病相關的訊息。因此利用一些標準化的語意在醫療影像上進行 註解，以便能根據這些註解立即取得儲存於 PACS 中的醫療影像。此研究的另一貢獻是 簡化並加快醫師進行註解的工作。 圖 6 CDA R2 之 RMIM 資料來源： http://archive.hl7.org/v3ballotarchive/v3ballot2008may/html/infrastructure/cda/graphics/L-POCD_RM000040. gif
三、註解系統分析、設計與實做
3.1 看診時配合多媒體註解系統之過程分析
3.1.1 現實世界中的看診流程
在設計我們系統的架構之前，我們先來了解一下在現實世界中，醫療人員是如何 使用多媒體註解系統來即時產生診療記錄檔的流程(圖 7)，以下依據 SOAP 過程進行解 說。 1. Subjective 階段：首先是當病人進入診間後，醫師會開始詢問病人有哪裡覺得 不舒服，之後病人便開始描述自己的病況，此時醫師會開啟註解系統的錄音或 錄影功能，在問診階段結束後，醫師會根據病人的主觀描述安排進一步的檢 查，因此他會在註解系統裡尋找適合的 SOAP 樣板(例如選擇健康檢查的樣 板)，並將此次問診時所記錄下來的檔案和樣板作連結，產生一份未完成的診 療記錄檔，並儲存到 Content Server 上。 2. Objective 階段：病人根據醫生的安排去進行各類檢查，一開始醫療檢查人員會 開啟多媒體註解系統從 Server 下載此名病人的診療記錄檔，根據這份診療記錄 檔內的檢查項目進行檢查，之後將檢查結果存入診療記錄檔內，並上傳 Server。 3. Assessment 階段：醫師開啟多媒體註解系統，自 Server 下載此名病患的診療記 錄檔，檢視其檢查結果，開啟多媒體註解系統的錄影或錄音功能進行記錄，根 據檢查結果進行診斷並向病患進行解說，之後將這段診斷過程的影音檔案連結 到診療記錄檔裡，並將診療記錄檔上傳 Server。 4. Plan 階段：醫師開啟多媒體註解系統並啟動錄音或錄影功能，根據其診斷內容 安排下一次的看診時間，以及是否需要病人做更進一步的檢查，之後將這過程 錄下的內容與診療記錄檔作連結，並上傳回 Server。 經過 SOAP 的過程後，診療記錄檔將包含此次看診時的內容，日後若有民眾或其 他醫療人員需要參考此次診療記錄，便可從 Server 上自行下載，如何管理下載的方式有 很多，並不在本論文的討論範圍內，故不贅述。經過整理，上述流程我們轉以流程圖表示，其結果如圖 8 所示。之後我們再更深 入的去探討每一個階段內每一個角色彼此之間的互動關係。
圖 7 看診流程
3.1.2
Subjective 流程
在 Subjective 的階段裡，主要的角色有病患、醫生、註解系統及資料庫。首先醫生 在病患開始說明病情之前，會由其他系統讀取病患資料以確認病患身份，之後確認無誤 後開啟多媒體註解系統，此時螢幕錄影及錄音功能亦開始啟動，之後病患開始說明病 情，說明結束後醫師根據病情選擇 SOAP 樣板做進一步的檢查，到這裡都和之前看診流 程差不多，之後當醫生確認 SOAP 樣板後，會從資料庫取得樣版的原型，並決定是否需 要新增或刪除檢查項目。多媒體註解系統取得樣板原型及醫生對樣板原型所做的調整等 資料後，開始進行在樣板原型裡新增或刪除檢查項目的動作(請參閱 3.5 節)，先找到 Objective 在 SOAP 樣版內的部分，並依據所勾選的檢查項目對樣板原型進行調整。之後 醫師將剛剛錄好的檔案當作註解內容，將其路徑加到此樣板中 Subjective 註解的欄位 內，再決定是否要新增 Subjective 的文字註解，輸入完文字註解後將診療記錄檔存回資 料庫後結束 Subjective 流程並開始 Objective 階段的流程。 圖 9 Subjective 流程3.1.3
Objective 流程
Objective 過程中，一開始也是先確認病人身分，之後根據病人身分由資料庫下載 該病人的診療記錄檔，此時註解系統會開始解析診療記錄檔的內容，並將解析過後的內 容顯示於顯示器上供醫療人員檢視及輸入。醫療人員根據檢驗項目對病人進行檢查，並 將檢查結果輸入到於顯示器上的診療記錄欄位內，檢查完畢後決定是否新增檢查項目， 若是，則開始勾選可新增的檢查項目，並依據新增的內容更新到診療記錄的文件上；若 否，則由醫療人員檢視是否還須進行下一個檢查，若有下一個檢查須進行，則回到之前 的流程繼續對病人進行檢查；若否，則將診療記錄存回資料庫，並開始下一階段 Assessment/Plan 的流程。 圖 10 Objective 流程3.1.4
Assessment 及 Plan 流程
將 Assessment 及 Plan 流程合在一起討論的原因是因為這兩個階段在實務上大都是 同時進行的，通常醫師診斷完後就會馬上安排病人下一次的檢查以及針對病情開藥給病 人進行治療，放在一起討論會使流程更為順暢。首先開啟系統後會自動啟動螢幕錄影及 錄音功能，當醫生由資料庫取得診療記錄檔後，多媒體註解系統會解析診療記錄檔並將 檔案上的資訊顯示於顯示器上，醫師此時開始檢視檢查結果，評估病情完後向病患解說 病情，藉由螢幕錄影及錄音功能進行全程記錄，有時若需要向病人解說醫療影像上的內 容，螢幕錄影功能就能將這過程記錄下來，方便日後需要的人作為參考。 解說完病情後醫師開始對下一次的看診進行規劃，與病患確認下次看診的時間 後，並視情況給予病人藥物，這些過程也都被螢幕錄影記錄下來，這些過程都結束後， 將產生的 Assessment 及 Plan 過程的影音檔案及其路徑記錄在診療記錄檔上，並儲存到 資料庫內，結束了這次看診的過程。 圖 11 Assessment/Plan 流程3.2 診療記錄檔設計(CDA 格式)
3.2.1 健康檢查表的 CDA 文件框架設計
一般健康檢查的項目及內容包含如表 4 所示，我們一開始必須先設計出可以表達 此健康檢查表內容的 CDA 文件。參考表 5，我們先定出整份 CDA 文件的樣板。 文件最外圍以<MultipleClinicalDocument>包住，此 Tag 為自訂欄位，目的是將多份 電子病歷在一份 XML 文件中呈現(為了將多個<ClinicalDocument>包起來)。一份標準的 CDA 文件可分成 Header 與 Body 兩塊，在外圍以<ClinicalDocument>包住，之後屬於 CDA Header 部分，其中包含的資訊已在 2.1.6 章節中介紹過，故不贅述。<typeId>中的 root 屬性值代表的是 HL7 所註冊 CDA 模型的 OID，用來表示此文件為 CDA Release2 的版 本，extension 的值則是代表 CDA R2 的 Hierarchical Description 的唯一辨識碼。病人的 資料則以<patientRole>包住。Body 外圍先以<component>包住，<component>內的屬性 typeCode 則賦予”COMP” 的值，表示此部分為文件中的一塊 component，contextConductionInd 設成 true 則表示這 塊 component 中 confidentialityCode 及 languageCode 的設定可以覆蓋掉 header 上的設定 (propagation)。之後在此 component 裡的<strucetureBody>內的屬性 classCode 設成 DOCBODY 則是代表用來切割文件的 Header 與 Body 部分，每一個檢查項目會先以 <component>先包好，再以<section>來切割 Body 成一塊一塊的檢查項目。
表 4 健康(體格)檢查表
Item
Health(Physical) Examinations Record
Medical Record Form Data(Form name, the name and code of the institutions production form) Field Name Description
Header
1 Patient information
1 Name
2 Medical Record Number 3 ID Number
Input patient`s identity number of ROC or residence number 4 Passport Number Input the passport number of the patients (nationality) 5 Sex □Male□Female
6 Birthday
1.Enter patient Republic of date of birth(or former), such as Year 79 October 18 could be transfer to A.D. by the computer.
2.Every Hospital could set the age field depending on their needed. It could be transfer to age by the computer.
1 Bed No. The patient source was emergency、hospitalization, need to fulfill this field (outpatient sources is not required)
3 Basic information of the patient administrative
Button to click to enter the module to reference patient data, due to the work needed and privileges.
4 Application contents
1 Application form number
2 Application physicians Medical personnel signature module 3 Application Date
4 Inspection Date 5 Application of the
inspected units
Application of the inspected units，could be Nursing homes、clinic、 various medical institutions
1 Medical institutions, health insurance code
Designated hospital code specified by the Bureau of National Health Insurance
2 Medical institutions, the
full title name Input the medical institutions, the full title name
5 Examination Category
□employment (new employee physical examination) □employees regularly check
□school □abroad □Other
6 Date of Employment Optional, year/month/day 7 History of past illness
8 Job experience 9 Symptoms
10 Height cm
11 Weight kg
12 Blood pressure mmHg
13 Vision □Before Correction□After Correction 1 Right 2 Left 14 Color Differentiation 15 Hearing Tests 1 Right 2 left
16 All system examinations
1 Respiratory System 2 Blood Circulation System
3 Urinary System 4 Digestive System 5 Nervous System 6 Skin 17 Chest X-ray 18 Examination Items 1 Urinary protein 1 Test value
2 Reference value the hospital attached the reference value 2 Urine
1 Test value
2 Reference value the hospital attached the reference value 3 Urinary occult blood
1 Test value
2 Reference value the hospital attached the reference value 4 White blood cell number
1 Test value
2 Reference value the hospital attached the reference value 5 Hemoglobin
1 Test value
2 Reference value the hospital attached the reference value 6 Blood sugar before meals
1 Test value
2 Reference value the hospital attached the reference value 7 Serum creatinine
1 Test value
2 Reference value the hospital attached the reference value
8
Serum glutamic acetone turn amino enzyme (ALT or SGPT)
1 Test value
2 Reference value the hospital attached the reference value 9 Triglyceride
1 Test value
2 Reference value the hospital attached the reference value 10 Cholesterol
2 Reference value the hospital attached the reference value 11 Hepatitis B Screening 1 Surface Antigen 2 Surface Antibody 3 Core Antibody 19 Result □ Yes □ No 20 Note
21 Report physician signature Medical personnel signature module 1 Name
2 Date/time 3 Certificate Identifier
表 5 CDA 文件樣板
CDA 文件框架
<MultipleClinicalDocument> <ClinicalDocument>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040" /> <patientRole classCode=“PAT”>
<id extension="123456" root="2.16.886.111.100000.100000.2" /> <patient classCode="PSN" determinerCode="INSTANCE"> <name>張三</name>
<birthTime value="9" /> </patient>
</patientRole>
…
<component typeCode="COMP" contextConductionInd="true"> <structuredBody classCode="DOCBODY" moodCode="EVN"> <component typeCode="COMP" contextConductionInd="true"> <section classCode="DOCSECT" moodCode="EVN">
... </section> </component>
<component typeCode="COMP" contextConductionInd="true“> <section> ... </section> </component> ... </structuredBody> </component> </ClinicalDocument> <MultipleClinicalDocument>
3.2.2 Objective Component 設計(CDA 格式)
參考表 6，以實驗室檢查紀錄之檢查項目為例，在檢查項目的<section>裡面定義了 <code>的作用在於說明此 section 裡面的資訊是屬於哪種類別。<code>中的屬性 code 的 值代表的是 displayName 屬性值” Reference lab test results”的 LOINC 編碼，
表 6 Objective Component(CDA 格式)
Objective Component
<component typeCode="COMP" contextConductionInd="true"> <section classCode="DOCSECT" moodCode="EVN">
<code code="19146-0" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Reference lab test results" /> <title>實驗室檢查紀錄</title> <text> <list> <item>身高：175CM</item> <item>體重：70KG</item> <item>血壓：</item> <item>視力：</item> <item>辨色力：</item> <item>聽力檢查：</item> <item>胸部 X 光報告：</item> <item>結果：</item> <item>注意事項：</item> </list> </text> </section> </component>
3.2.3 Subjective、Assessment 與 Plan Component 設計(CDA 格式)
Subjective、Assessment 及 Plan 之註解設計和 Objective 的部分類似，不同之處在於 code 的編碼不同以及多了<renderMultiMedia>作為宣告外部連結檔案的標籤，其屬性 referencedObject 的值是指向<observationMedia>標籤內之屬性 ID 的參考，
<observationMedia>用來宣告外部連結檔案的路徑及其檔案格式。因為 ID 內的值是系統 產生的，因此其命名規則為”SMM”加上一個 sequence number，例如 SMM1、SMM2… 等。Assessment 的檔案命名規則為”AMM”加上 sequence number，例如 AMM1、AMM2… 等。Plan 的檔案命名規則為”PMM”加上 sequence number，例如 PMM1、PMM2…等。
表 7 Subjective Component(CDA 格式)
Subjective Component
<component typeCode="COMP" contextConductionInd="true"> <section classCode="DOCSECT" moodCode="EVN">
<code code="61150-9" codeSystem="2.16.840.1.113883.6.1“
codeSystemName="LOINC" displayName=“Subjective" /> <title>主觀症狀</title> <text> <list> <item>記錄：</item> </list> <renderMultiMedia referencedObject=“SMM1"/> </text> <entry>
<observationMedia classCode="OBS" moodCode="EVN" ID=“SMM1"> <id root=“2.16.840.1.113883.19.613.1"/>
<value xsi:type="ED" mediaType="video/mov"> <reference value=“SMM1.mov"/> </value> </observationMedia> </entry> </section> </component> 表 8 Assessment Component(CDA 格式) Assessment Component
<component typeCode="COMP" contextConductionInd="true"> <section classCode="DOCSECT" moodCode="EVN">
<code code="35517-2" codeSystem="2.16.840.1.113883.6.1“
codeSystemName="LOINC" displayName=“Assessment" /> <title>診斷</title> <text>> <list> <item>記錄：</item> </list> <renderMultiMedia referencedObject=“AMM2"/>
</text> <entry>
<observationMedia classCode="OBS" moodCode="EVN" ID=“AMM2"> <id root=“2.16.840.1.113883.19.613.1"/>
<value xsi:type="ED" mediaType="video/mov"> <reference value=“AMM2.mov"/> </value> </observationMedia> </entry> </section> </component> 表 9 Plan Component(CDA 格式) Plan Component 註解項目範例 <component typeCode="COMP" contextConductionInd="true"> <section classCode="DOCSECT" moodCode="EVN">
<code code=“18776-5" codeSystem="2.16.840.1.113883.6.1“
codeSystemName="LOINC" displayName=“plan to treatment" /> <title>接續的診治計畫</title> <text> <list> <item>記錄：</item> </list> <renderMultiMedia referencedObject=“PMM3"/> </text> <entry>
<observationMedia classCode="OBS" moodCode="EVN" ID=“PMM3"> <id root=“2.16.840.1.113883.19.613.1"/>
<value xsi:type="ED" mediaType="video/mov"> <reference value=“PMM3.mov"/> </value> </observationMedia> </entry> </section> </component>
3.3 註解系統架構說明
本論文主要將多媒體註解系統分為五個部份(圖 12)，分別簡述如下： (1) 診療記錄顯示子系統(參考 3.4.1 節) 解析使用者欲開啟的診療記錄檔，並將診療記錄檔的內容顯示在顯示器上。 (2) 註解工具子系統(參考 3.4.2 節) 提供使用者畫面錄影、錄音及醫療影像註解工具等內容產生工具，該內容可作 為診療記錄檔之註解。 (3) 診療記錄儲存子系統(參考 3.4.3 節) 提供使用者將製作好的診療記錄檔儲存到資料庫的工具。 (4) 診療記錄編輯器(參考 3.4.4 節) 提供使用者新增/刪除/修改診療記錄的工具。 (5) Database 用以儲存外部多媒體註解及診療記錄檔的儲存媒體。 圖 12 系統架構3.4 各子系統說明
3.4.1 診療記錄顯示子系統
這個子系統主要負責處理將診療記錄檔解析後將其內容顯示於螢幕上的處理。使用 者先由 Database 取得診療記錄檔，之後多媒體註解系統會將診療記錄檔丟進診療記錄顯 示子系統內的診療記錄解析器中，將診療記錄檔內的資料拆解成”病人資料”、”醫生資 料”、”醫院資料”、”檢查資料”、”診斷資料”…等。檔案解析完後，會丟進診療記錄顯示 器內，由診療記錄顯示器依照其資料型態丟進不同的顯示模組中，例如醫療影像就會丟 進醫療影像顯示模組，診療記錄的部分由診療記錄顯示模組處理，而多媒體資料則由多 媒體解壓縮模組與多媒體播放模組處理。 圖 13 診療記錄顯示子系統3.4.2 註解工具子系統
註解工具子系統主要是提供使用者在診療記錄檔或醫療影像上產生註解的能力(圖 14)。此系統使用 ImageJ 開啟 DICOM 格式的醫療影像，在 ImageJ 的 Plugin 裡加上醫療 影像註解工具後，便可直接透過 ImageJ 在醫療影像上進行新增/刪除/修改醫療影像上多 媒體格式的註解(包含文字、圖片、聲音及影像等格式)。 畫面錄影模組及錄音模組則提供醫生在 Subjective/Assessment/Plan 等階段，錄製醫 生使用電腦在螢幕上向病人講解病情之過程。錄製完的影音檔案透過診療記錄編輯器以 外部連結的方式記錄於診療記錄檔上，最後會將診療記錄檔透過診療記錄儲存子系統儲 存到資料庫中。 圖 14 註解工具子系統
3.4.3 診療記錄儲存子系統
由診療記錄編輯器所產生的診療記錄檔在儲存時會透過診療記錄儲存子系統處 理，診療記錄儲存子系統裡的診療記錄解析器會先解析診療記錄檔中的資料，將之拆解 成如「病人資料」、「醫生資料」、「檢查資料」、「外部連結」…等，並將這些文字資料丟 入資料儲存模組中，經過整理後存入資料庫中。「外部連結」之影音資料須丟入影音壓 縮模組中，經過壓縮後儲存到資料庫內。 圖 15 診療記錄儲存子系統3.4.4 診療記錄編輯器
提供使用者新增/刪除/修改目前診療記錄檔內欲進行的檢查項目列表 (Objective)及 欄位內容、Subjective/Assessment/Plan 註解項目及註解內容等功能。此編輯器包含下列 四個功能： a、 檢查項目選擇器：提供使用者使用勾選/取消勾選的方式新增/刪除診療記錄檔 內之檢查項目。 b、 診療記錄輸入工具：提供使用者在使用者介面上新增/刪除/修改診療記錄內容 的工具。 c、 診療記錄產生器：接收使用者透過「檢查項目產生器」或「診療記錄輸入工具」 所輸入的內容，並藉此產生一份診療記錄檔。 d、 檢查項目 Pattern Library：每個檢查項目所包含的檢查內容皆被整理成為一份 pattern，用戶選擇新增某一檢查項目時，會讀取檢查項目 pattern library 中的內 容進行新增。3.5 診療記錄編輯器
3.5.1 檢查項目選擇器與診療記錄產生器
檢查項目選擇器(圖 17)提供醫生或醫療人員使用勾選的方式簡單的修改診療記錄 檔上面的檢查項目。
首先，當醫生開啟診療記錄檔後，如欲新增檢查項目，可點選「修改檢查項目」 功能，註解系統會依據 CDA header 中的 templeteId 來判斷此診療記錄檔是依據何種樣板 建立的。 根據樣板類型，到檢查樣板 Pattern Library 讀取可供新增的檢查項目，並列出目前 已存在於診療紀錄中的檢查項目後，此時醫生可在勾選欲新增的檢查項目，或將已存在 於診療記錄檔中的檢查項目刪除(取消勾選)，醫生確定修改後，註解系統會站存所勾選 的項目，並將結果丟進診療記錄產生器，以產生新的診療記錄檔。 圖 17 檢查項目選擇器
