國 立 交 通 大 學
資訊學院 資訊學程
碩 士 論 文
應用於數位醫療影像且符合 DICOM 規格的
多媒體註解工具
A Multimedia Annotator with DICOM Compatibility
on Digital Medicine Image
研 究 生：許豪岱
應用於數位醫療影像且符合 DICOM 規格的多媒體註解工具
A Multimedia Annotator with DICOM Compatibility
on Digital Medicine Image
研 究 生：許豪岱
Student：Hao-Tai Hsu
指導教授：陳登吉
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 2011
Hsinchu, Taiwan, Republic of China
應用於數位醫療影像且符合 DICOM 規格的多媒體註解工具
學生：許豪岱
指導教授：陳登吉 博士
國 立 交 通 大 學 資 訊 學 院 資 訊 學 程 碩 士 班
摘要
隨著資訊科技的快速發展，各種產業都積極結合資訊科技，以提高效率，而醫療與 資訊科技的結合也是一種必然的趨勢；目前可以看到這樣的趨勢明顯呈現在醫學影像無 片化，病例無紙化-也就是電子病歷上面。醫學影像做到無片化的方法，是把檢查的影 像，以數位型態輸出，而在醫療領域，普遍被採用的是 DICOM 加上 PACS 資料庫，作 為數位醫療影像的取得、儲存、交換的共通標準。 醫療影像圖上的註解內容，來自於醫療專業人員的專業知識及經驗，但是如何在數 位醫療影像檔上，完整的記錄下醫療專業人員的診斷及見解，以及把這些寶貴的內容， 與醫療影像圖做適當的連結，使其可以透過 DICOM+PACS 進行資訊的的交換，有賴註 解工具提供足夠的功能來實現。 也由於醫療影像數位化後，註解的形態已經不受限於文字、符號、圖片；如果可以 有包含聲音(Audio)、影片(Video)的多媒體註解工具，則可以記錄下更豐富，更完整的註 解內容。 本論文提供一個多媒體註解工具的實做方法，可以讓醫療專業人員針對 DICOM 數 位醫療影像檔作註解，註解內容包含文字、影像、動畫、聲音、影片等多媒體註解；同 時，加入註解的影像檔，仍然維持其 DICOM 格式的相容性，可回存至 PACS 資料庫中。 未來甚至可以整合包含註解的 DICOM 影像檔至醫療系統，成為病歷的一部份。A Multimedia Annotator with DICOM Compatibility on Digital Medicine Image
Student：Ha0-Tai Hsu
Advisor：Dr. Deng-Jyi Chen
Degree Program of Computer Science
National Chiao Tung University
ABSTRACT
With the rapid development of information technology, All industry also active combine in information technology to improve efficiency. While the combination of medical and information technology is an inevitable trend. We can see such a trend clearly showing on no film in medical imaging technology, like cases paperless, electronic medical records(EMR). In the medical field, DICOM Standard and PACS database are widely used as acquisition, storage, exchange of digital medical image.
Annotation on medical image come from the experience of medical professionals, but how to completely annotate the diagnosis and insights of medical professionals on digital medical images, and how to link with the annotations to digital medical images appropriate, and exchanging through DICOM+PACS, depends on adequate functionality which annotator provide.
This paper provides a multimedia annotation tool. Medical professionals can make multimedia annotation on DICOM medical image, include text, symbols, images, audio, video form. At the same time, the DICOM file with multimedia annotation still keep compatibility of DICOM standard, and can be restored to the PACS database. In the future, it can integrate the DICOM image file with multimedia annotation to one part of the Health Information System.
誌謝
對於此篇論文的完成，首先要感謝指導教授陳登吉老師，除了在研究方向及內容的 指正，更針對發現問題及解決問題的方法上，時時給予正確的建議。同時特別感謝口試 委員曾建超老師、蕭嘉宏老師，在百忙之中抽空蒞臨指導我的論文，給予寶貴的建議， 使得論文內容更加完備。 此外，要感謝研究室博士班李鎮宇學長的協助，不吝犧牲寶貴的當兵休假時間，針 對研究的細節一一討論修正。在研究過程中，一起同甘共苦的實驗室夥伴們：興郎，維 明、靖哲，因為有你們的互相勉勵、分享與討論，讓論文更完整。 感謝公司長官及同事，有你們的支持與後援，我才得以在兼顧工作與課業的情形 下，無後顧之憂的完成學位。 最後必須感謝我的太太-美云，在求學期間的全心支持與鼓勵，是我努力的原動力。目錄
摘要 ... i ABSTRACT ... ii 誌謝 ... iii 目錄 ... iv 表目錄... vii 圖目錄... viii 一、 緒論 ... 1 1.1 研究背景... 1 1.2 研究動機... 2 1.3 研究目標... 4 1.4 章節概要... 5 二、 相關研究 ... 6 2.1 DICOM 的簡介... 6 2.2 典型的 DICOM Network 介紹... 7 2.3 DICOM Standard 2009 ... 7 2.4 DICOM 資料結構 ... 9 2.5 DICOM 影像物件 ...11 2.6 DICOM 檔案內容 ...11 2.7 Data Element 的內部結構... 122.8 DICOM Value Representations 範例 ... 13
2.9 DICOM 的實際資料內容 ... 14 2.10 Annotation 的儲存方式... 15 2.10.1 以 DICOM 標準格式存放... 15 2.10.2 以自訂欄位存放 ... 19 2.11 PACS 簡介 ... 19 2.11.1 影像擷取... 20 2.11.2 影像處理及展示 ... 20 2.11.3 影像儲存及管理 ... 21 2.11.4 PACS 處理醫療影像的方式 ... 21 2.12 國內 PACS 現況 ... 21 2.12.1 全國醫療影像交換中心... 21 2.12.2 國內醫療院所 ... 22 三、 註解系統分析、設計與實做... 23 3.1 註解系統架構說明 ... 23 3.2 各子系統說明... 24
3.2.1 DICOM 影像圖處理子系統... 24 3.2.2 註解編輯子系統 ... 25 3.2.3 註解儲存子系統 ... 25 3.2.4 註解瀏覽子系統 ... 26 3.3 DICOM Header 與外部註解的連結 ... 27 3.4 註解流程說明... 28 3.4.1 註解產生流程 ... 28 3.4.2 註解播放流程 ... 29 3.4.3 註解修改流程 ... 30 3.5 實做說明... 31 3.5.1 實做使用工具 ... 31 3.5.2 實做結構說明 ... 31 3.5.3 自定 DataElement 說明 ... 32 四、 討論 ... 33 4.1 相容性問題探討 ... 33 4.1.1 DicomWorks 介紹 ... 33 4.1.2 新增 Data Element 驗證 ... 34 4.1.3 Data Element 存放位置討論 ... 34 4.2 註解存放播放方式探討... 36 4.2.1 以標準格式存放 ... 36 4.2.2 以自定欄位存放 ... 37 4.2.3 註解方式的多樣化... 37 4.2.4 使用自訂註解的誘因... 37 五、 實做展示 ... 38 5.1 展示說明... 38 5.2 DICOM 檔案上產生多媒體註解... 38 5.2.1 開啟 DICOM 檔案 ... 38 5.2.2 新增註解-以 Text 為例 ... 39 5.2.3 新增註解-以 Audio 為例... 41 5.2.4 新增註解-以 Video 為例 ... 42 5.3 開啟、播放含有自訂註解的 DICOM 檔案 ... 44 5.3.1 開啟含有自訂註解的 DICOM 檔案 ... 44 5.3.2 播放多媒體註解-以 Text 為例... 45 5.3.3 播放多媒體註解-以 Video 為例 ... 45 5.4 修改、刪除 DICOM 檔案上的註解內容 ... 47 5.4.1 修改自訂註解 ... 47 5.4.2 刪除自訂註解 ... 48
6.1 總結 ... 50 6.2 未來發展方向 ... 50 REFERENCES ... 51
表目錄
表 1 DICOM Value Representations... 13
表 2 Annotation 組成結構 ... 15
表 3 Annotation 的一個範例 ... 16
圖目錄
表 1 數位醫療影像的註解方法 ... 4
圖 2 註解工具應用示意圖... 5
圖 3 數位醫療儀器影像的資訊交換... 6
圖 4 DICOM Network ... 7
圖 5 DICOM Specification interactive ... 9
圖 6 Example of DICOM Series Generation... 10
圖 7 Example of Mapping CT Series... 10
圖 8 DICOM 影像物件 ...11 圖 9 DICOM 檔案內容 ...11 圖 10 DICOM Header 結構 ... 12 圖 11 Data Element... 12 圖 12 Data Element 的內部結構 ... 13 圖 13 Data Element 實際範例 ... 14 圖 14 自訂欄位範例... 19 圖 15 PACS 系統架構圖(資料來源:電腦與通訊雜誌第 53 期第 41 頁) ... 20 圖 16 系統架構圖 ... 23 圖 17 DICOM 影像圖處理子系統 ... 24 圖 18 註解編輯子系統... 25 圖 19 註解儲存子系統... 25 圖 20 註解瀏覽子系統... 26
圖 21 自訂 Tag 的 Data Element ... 27
圖 22 透過自訂 Tag 連結 DICOM 影像檔與註解 ... 27
圖 23 註解產生流程... 28
圖 24 註解播放流程... 29
圖 25 註解修改流程... 30
圖 26 Annotator 實作架構... 31
圖 27 自訂 Tag 的 Data Element ... 32
圖 28 外部連結格式... 32
圖 29 原始 DICOM File 及 Tag... 33
圖 30 新增自訂 Tag 後的 DICOM File ... 34
圖 31 Pixel Data 的 Data Element 結構說明 ... 35
圖 32 Annotator Data Element 存放於檔尾... 35
圖 33 檔尾有 Annotator Data Element，DicomWorks 無顯示... 36
圖 34 執行 MultiMedia Annotator ... 38
圖 36 標記註解位置及指定 Text 註解... 39 圖 37 執行 Annotator ... 40 圖 38 顯示錄製完成的註解-Text ... 40 圖 39 標記註解位置及指定 Aduio 註解... 41 圖 40 錄製 Audio Annotator ... 41 圖 41 顯示錄製完成的註解-Audio ... 42 圖 42 標記註解位置及指定 Video 註解 ... 42 圖 43 錄製 Video Annotator ... 43 圖 44 顯示錄製完成的註解-Video... 43 圖 45 開啟包含自訂註解的 DICOM 檔案... 44 圖 46 播放 Text 註解... 45 圖 47 開啟包含自訂註解的 DICOM 檔案... 45 圖 48 播放 Video 註解 ... 46 圖 49 指定要修改的註解... 47 圖 50 修改後的註解... 48 圖 51 指定要刪除的註解... 48 圖 52 刪除後剩餘的註解列表 ... 49
一、緒論
1.1 研究背景
隨著資訊科技的快速發展，各產業也都積極結合資訊科技，以提高效率，而在醫療 領域中，除了以數位化的醫療設備，取代了傳統的醫療設備，並不斷提升醫療資訊系統 與資訊科技作深刻的結合應用，更成為一種趨勢。其中，最直接的例子就是「醫學影像 無片化」與「病歷無紙化」。 也因應醫療系統資訊化的趨勢，政府延續民國八十九年推動的「二代全國醫療資訊 網(HIN2.0)計畫」，並在九十八年四月三十日衛生署所提健康照護升值白金方案經行政院 院會通過，於 2 年內建立影像交換中心。民國九十九年成立「全國醫療影像交換中心」， 先以 CT、MRI、PET(正子斷層攝影)等高貴檢查影像進行交換，經評估後再擴及其他影 像資料。目前已有 128 大小醫療院所加入(包含醫學中心，區域醫院，地區醫院)。 為了使醫療資訊系統間能夠互相交換資訊，「全國醫療影像交換中心」使用國際間已經相當廣泛的醫療數位影像傳輸協定(DICOM-Digital Imaging and Communications in Medicine)加上 PACS(Picture Archiving and Communication System)做為各國內各大小醫 療院所的醫療資訊系統之間，傳遞資料的標準格式。 PACS 是在 1980 年開始即有的構想，目的在於創造一個無軟片(Filmless)的醫療影 像診斷環境。H.K. Huang 之研究論著認為影像擷取設備、影像存取設備、影像顯示、 電腦處理器及資料管理系統元件，經由電腦網路加以整合即為 PACS。 我們的研究背景，來自於醫療實務上：當醫生遇到病情比較複雜的病患時，可能需 要藉助精密的儀器，例如照 X-ray、核磁共振(MRI)、電腦斷層攝影(CT)、正子斷層攝 影(PET)等等這些不同的醫療器材，去做進一步的檢查。檢查結果出來後，傳統就是用 實體片子(X 光片)直接放在燈箱上看，無片化之後，醫療人員透過網路，以 DICOM Protocol 取得 PACS 資料庫中，病患檢查的醫療影像檔案(X-ray, MRI, CT/PET)，在銀幕 上徒手講解，或是在複製的醫療影像圖上向病人進行解說。在解說的過程中，如果有發 現異常的地方，可以在影像檔上面標記出病變的部分，作為註解。也有可能醫師看診時 間比較匆促，只進行解說，看診結束整理資料的時候，再把需要註解的內容，事後補充 到病歷或是相關文件檔案中，讓註解成為此次看診資料的一部份。於是，在醫療影像的 上做註解的工具，使用上是否方便、功能是否齊全，就成為醫療專業人員在使用上的重 要考量之一。
數位內容 (Digital Content) 的註解有五個性質，包括 Identification、Cooperation、 Linking、Semantics、Materialization，簡略說明如下:
對於每一個數位內容或是註解，我們必須有唯一的識別 (Identification)，讓我們 可以正確地對映 (Mapping)註解和數位內。
(2) 合作 (Cooperation)：
註解系統必須設置使用權限與使用者角色的機制提供網路上的使用者合作與分 享註解。使用權限分為不可讀寫 (Denied)、唯讀 (Read only)、可讀寫 (Read and write) 而註解分享的方式分為私有 (Private)、分享 (Shared)、公開(Public)。 (3) 連結 (Linking)：
註解必須和數位內容連結才具有意義，註解與數位內容連結的形式有註解連結 (Annotate link) 與相關連結 (Relate-to link)。每個註解都必須依附在另一個數位 內容或註解上，這種連結就是註解連結，而註解內可能參考其他的數位內容或 註解，這種連結就是相關連結。
(4) 語意 (Semantics)：
註解在實際的應用時有各種用途，常見的三種用途為學習 (Comprehension and study)、解釋(Interpretation and elucidation)、交流(Cooperation and revision)。 (5) 實現 (Materialization)：
註解的 形 式 (Sign of annotation) 包括文字形式 (Textual sign) 、圖 形形 式 (Graphic sign)、聲音形式 (Audio sign)、以及影片形式 (Video sign)。
醫療影像圖上的註解內容，來自於醫療專業人員的專業知識及經驗，但是如何方便 的記錄下醫療專業人員的診斷及見解，以及把這些寶貴的內容，與醫療影像圖做適當的 聯結，則是註解工具要具備的功能。目前的註解工具所提供的方法，除了使用不同顏色 作為文字、符號的摽記，也有連結影像圖並提供快速搜尋。
1.2 研究動機
一般醫療影像圖上的註解產生及使用方式，舉例來說: l 醫療人員對病患、家屬的講解往往直接於螢幕上以徒手講解，或是於複製的醫 療影像上繪製註解符號 l 現行醫療影像的註解，往往是由醫療人員使用錄音筆，錄下講解時的內容。事 後聽取錄音筆的內容搭配筆記，整合後再註記到醫療影像或病歷中。 l 在相同的系統中產生的註解，使用上自然不會有問題，但是，由於病患可能會 有轉診的行為，如果病歷中有完整的註解，並可以同時移轉，接手的醫療人員 可以清楚的了解整個情況，對病人的照料比較完善。 在上述的使用情境下，可能遇到的問題有兩大類： (1) 非多媒體註解(不包含聲音(Audio)，影片(Video))：的醫療影像上繪製註解符號。 è病患或家屬難以理解與記憶「符號」所代表的意義 現行醫療影像的註解，往往是由醫療人員或病患及家屬使用錄音筆，錄下講解 時的內容。事後聽取錄音筆的內容搭配筆記，整合後再註記到醫療影像中。 è講解與註解行為是非同步的 è萬一產生糾紛，對病人及醫療人員皆無保障可言 (2) 數位醫療資訊與其他院所不相容： 在註解系統開發的時候，尚未採用 DICOM 格式+PACS 的儲存方式，在專屬資 訊系統內流通沒有問題，但是要與其他院所共享資訊時，可能要透過一些額外 的轉檔程序，才能跟別人做資訊交換，但是轉檔之後的內容可能已經有所遺漏， 或是無法做進一步的編輯。 也由於未能與 DICOM 格式相容，無法透過與全國醫療影像交換中心，與其他 院所進行資料交換。 產生註解的方法，在資訊領域行之有年，也有不少相關研究，由於本論文探討的是 數位醫療影像檔上的註解方式，所以非醫療領域的註解，則不在本論文討論之內。查詢 相關期刊論文中，與醫療領域相關的註解處理方法，比較具有代表性的，我們挑選出以 下三篇，針對其內容分析如下：
(1) Defining a new annotation object for DICOM image: a practical approach 特色：提供文字及符號的註解並與 DICOM, PACS 相容
缺乏：影像、Audio, Video 等多媒體註解方式 (2) Semantic Annotation and Retrieval for Medical Images
特色：提供文字、符號及影像的註解並與 DICOM, PACS 相容 缺乏：Audio, Video 等多媒體註解方式
(3) A Web-Based Solution for Viewing Large-Sized Microscopic Images
特色：使用 Virtual Slide 並轉成 SVS 格式，提供文字、符號及 Audio, Video 等 多媒體註解方式
缺乏：SVS 不是 PACS 的標準格式，與 DICOM, PACS 不相容。需要資訊人員 把醫療專業人員提供的註解內容, 以程式碼的型態寫進 virtual slide 系統中，需 要資訊人員與醫療人員反覆來回確認註解內容，耗時又無法保證註解的正確性。
針對代表性的三篇，使用表格整理圖下：
S.H. Jang’s M. Möller’s C.Y. Lien’s
文字、圖形註解 ˇ ˇ ˇ 影像註解 ˇ ˇ 聲音註解 ˇ 動態影片註解 ˇ 註解支援 DICOM ˇ ˇ 表 1 數位醫療影像的註解方法
1.3 研究目標
由表 1 可知，目前在數位醫療影像檔上的註解工具，與 DICOM 相容的不支援多媒 體影音註解，支援多媒體影音註解的無法與 DICOM 相容。本論文希望實做一個 User Friendly 的 DICOM Compatible 註解工具(Annotator)，做到既與 DICOM 相容，又能夠 提供多媒體影音註解的能力，協助醫療專業人員在醫療影像圖上標記多媒體註解。主要 特色： l DICOM Compatible l 提供文字、圖片，動畫(Animation)、聲音、影片等不同能力的註解方式 l 完整保存醫療專業人員的見解 1.3.1 註解工具(Annotator)應用於醫療實務中的 DICOM 影像檔案透過 DICOM protocol 從 PASC 資料庫中，取得的數位醫療影像，可以藉由我們 的註解工具，附加多媒體註解於其上，同時保留 DICOM 的完整相容性。附加的 註解，可以透過既有的 Partial DRM 技術進行保護，也可以與成為病歷結合，整 合成為進現有的醫療資訊系統的一部分。
圖 2 註解工具應用示意圖
1.4 章節概要
本論文的章節內容摘要如下： 第一章「緒論」，說明本論文的研究背景與動機，以及研究的目標。 第二章「相關研究」，探討與研究相關的規格及文獻。 第三章「系統分析、設計與實做」，說明 DICOM 多媒體註解系統的設計及實做。 第四章「討論」，對 DICOM 多媒體註解系統面臨的問題進行討論及說明。 第五章「實例展示」，透過範例的展示，說明如何使用本論文實做的多媒體註解工 具對 DICOM 影像檔製作、修改、播放多媒體註解。 第六章「結論」，本研究的總結，並建議未來可以繼續發展的方向。二、相關研究
2.1 DICOM 的簡介
DICOM(Digital Imaging and Communications in Medicine-醫療數位影像傳輸協定)。 在 1982 年時，有鑑於各種不同的醫學影像診斷設備的格式和介面都不同，因此要整合 所有的設備，就必需要有一套共通的標準，於是 ACR（American College of Radiology, 美國放射學會）和 NEMA（National Electrical Manufacturers Association,國家電子製造商 協會）這兩個組織決定共同成立一個委員會(ACR-NEMA)，致力於制定影像儀器間共通 的通訊規格。後來陸續在 1985 及 1988 年發表了兩套規格（ACR-NEMA 1.0, ACR-NEMA 2.0），並在 1993 年發表了一套革命性的協定，並正式定名為 DICOM 3.0，用於數位化 醫學影像傳送、顯示與存儲。這套規格在發表後立即被許多儀器及軟體廠商採用。同時 已被美國、歐洲、日本等地正式接受並列入國家規範。在台灣地區，「國家醫療影像交 換中心」也已以 DICOM 作為醫療影像資訊交換的標準。 舊式的醫療設備，以 X 光影像為例，在攝影完成後，尚須經過沖片的過程才將肉眼 可見的影像呈現在底片上，醫師則需透過看片箱進行觀察；但現今透過數位化的醫療設 備及 DICOM 標準的輔助，不同廠商的醫療影像儀器，可將 DICOM 格式的檔案，儲存 在 PACS 資料庫中，並互相接收與交換影像及病人資料，達到無片化的環境，如下圖所 示: 圖 3 數位醫療儀器影像的資訊交換
2.2 典型的 DICOM Network 介紹
一個 DICOM 的產生過程可分成下面步驟:
l Step1. A CT (Computed Tomography) scan is performed. l Step2.The scanner constructs a set of images (study).
l Step3.The scanner sends the study to a PACS ( Picture Archiving and Communication System - 影像擷取暨傳輸系統).
l Step4. A workstation queries the PACS and retrieves the study. l Step5. Reconstructions or reformats.
圖 4 DICOM Network
2.3 DICOM Standard 2009
以下為 DICOM Standard 各 Part 的概要說明: l Part 1 Introduction and Overview
對整個標準做了一個簡略的介紹，並解釋整個標準的設計理念、定義使用了哪 些物件，以及對其他幾個 Part 做簡短的說明。
l Part 2 Conformance
定義了 DICOM 中 conformance，及 conformance 究竟作何解釋，以往的儀器雖 宣稱標準相容卻發生無法連接情況，因此 conformance 主要功用就是定義了 DICOM 要求製造商精確地描述其産品的 DICOM 相容性，即構造一個該産品 的 DICOM 相容性聲明，讓使用者能夠正確的選擇所要購買的機器服務，並確 保能夠互相連接。它包括選擇什麽樣的資訊物件、服務類、資料編碼方法等， 每一個用戶都可以從製造商處得到這樣一份聲明。
l Part 3 Information Object Definitions
分別定義 每 種 DICOM 物件(CT,MR, Ultrasound) 等所包含的 Information Object Classes 內容，每一個 Information Object Classes 包含了這個 Object 的功 能及其定義。而為了要表現出放射醫療環境下會產生的一些狀況，設計了 Information Object Classes Instance 處理 Information Object Classes 的屬性
（attribute）變化。因此，Information Object Classes Instance 會隨著 DlCOM 3.0 系統在操作中所產生的一些事件（event）而動態的反映出結果，必要時改變 Information Object Classes 的屬性。Service-Object-Pair Class（SOP）是由 IOD （ Information Object Definitions ） 以 及 DIMSE （ DICOM Message Service Element）所構成，SOP Class 的定義包含了限制或擴充 DIMSE 之 service 或更 改 IOD 的屬性。
l Part 4 Service Class Specifications
服務類別（service class）的規格，服務類別可以想像是 IOD 的操作，如儲存、 查詢、擷取、列印等。
l Part 5 Data Structures and Encoding
定義 DICOM 物件的資料結構及語義，描述了怎樣對資訊物件類和服務類進 行構造和編碼
l Part 6 Data Dictionary
說明 DICOM 所定義的每個 Tag 及 UID。定義整個資料元件（Data Elements） 中其數字（numerical names）與文字（text names）間對應的完整列表、資料結 構（例如 text、floating-point 或 integer）及元件中是否有包含其他的元件。 l Part 7 Message Exchange
定義應用程式與 DICOM 通訊層連接所需要的訊息；典型 DICOM 訊息包含了
命令字串（command stream）及資料字串（data stream）。命令字串中所支援的
服務項目即 Part 4 中所定義，而資料字串（或稱為訊息物件，information object） 須以 Part 5 中的編碼方式編碼。
l Part 8 Network Communication Support for Message Exchange
定義網路上 DICOM 訊息（DICOM message）的交換，目前所支援的協定為 TCP/IP 以及 ISO-OSI。但這部份在制定過程中，上層服務（upper Layer service） 的設計原則必須是具有高度的擴充性，亦即將他種協定納入 DICOM 必須是十 分簡易。
l Part 9 Retired.
l Part10: Media Storage and File Format for Media Interchange 定義 DICOM 物件存檔資料時檔案目錄及檔案本身的格式。 l Part11: Media Storage Application Profiles
定義應用軟體可具備的 DICOM File Service 存取功能 l Part12: Formats and Physical Media
說明各種儲存媒體儲存 DICOM 資料時的格式 l Part13 Retired
l Part 14: Grayscale Standard Display Function
說明 DICOM 影像在螢幕顯示以及列印時的規格及要求。 l Part15:Security Profiles
影像及報告的方式
l Part 16: Content Mapping Resource
規範 DICOM 引用之 DCMR(DICOM Content Mapping Resource)相關標準詞彙 及詞彙格式。
l Part17: Explanatory Information
規範 DICOM 有關之詞彙說明，以確定資料的統一使用 l Part 18: Web Access to DICOM Persistent Objects (WADO)
規範如果何透過 Web –based 的服務來執行相關的 DICOM 服務，包含如影像 及 報 告 部 分 。 透 過 HTTP/HTTPs 的 標 準 並 使 用 DICOM UIDs ( Unique Identifiers) 來執行遠端的影像讀取。
我們也可以透過下圖，了解 DISOM Standard 各 part 之間的關係：
圖 5 DICOM Specification interactive
2.4 DICOM 資料結構
假設病患到醫院就診時，如果病情比較複雜，醫師需要藉助各種精密的儀器，例如 照 X-ray、核磁共振(MRI)、電腦斷層攝影(CT)、正子斷層攝影(PET)等等這些不同的醫 療器材，去做進一步的檢查。每一個檢查項目都需要一個相對應的儀器來完成，但影像 儀器所產生的往往不是單張而是一系列的影像。從 DICOM 的資料結構來看，分成了 Patient、Study、Series、View 四個層級來儲存上述的例子，Patient 中包含了病患的所有 基本資料，Patient 底下有 Study，用來表示檢查儀器類別，舉例來說，可能是 MR 或是CT，在 Study 下，又分為數個 Series，每個 Series 可能有一到多張的影像。當醫師需要 調閱影像時，只要輸入病患相關資料，就能依據這一連串的資料結構找到病患所做過的 檢查，及其中包含的所有醫學影像。
圖 6 Example of DICOM Series Generation
2.5 DICOM 影像物件
以下列出了一個 DICOM 檔案的內容，各個 Group 分別描述了 Patient/ Study/ Series/ Equipment/Image 等資訊。
圖 8 DICOM 影像物件
2.6 DICOM 檔案內容
每個 DICOM 檔案，由 IOD (Information Object Definition)物件所組成，每個 IOD
可以分為 Header 與 Pixel Data 兩個部份。
Header 最前面有 128 bytes preamble, 然後會以固定的 4bytes String “DICM” 做為前 置字串(Prefix)；接下來會由一連串的 Data Element 組成：
圖 10 DICOM Header 結構
從上圖來看，每一個檔案 Header 裡的的最小單位的我們稱為 Data Element，不同性 質的 Data Element 可以形成群組( group) 或模組( module )；DICOM 影像是以「病人 PATIENT」為主檢索的目錄結構。有些群組 (group) 放在一起代表的是病患模組 (patient module)；有些形成檢查模組(study module)， 病人接受檢查(study) ，可能不只一種檢查， 如有 CT、MR、US；有些形成系列模組( series module) ，每個檢查可能產生不只一張 影像，而是一系列(series)影像；有些形成影像模組(image module)。每個 Data Element 又由下面欄位組成：
圖 11 Data Element
2.7 Data Element 的內部結構
由(Group ID, Element ID) 組成，以 16 進位數字表示，不同的 Service 需要不 同類別之 Tag。
l VR (Value Representation)
定義 data element 的資料型別與格式，舉例來說，”PN” = Person Name，用來 記錄病患姓名；”DT” = Data Time，用以代表日期的資料型別，VR 事實上是一 個 option 的欄位，它端視在傳輸過程中之協定( transfer syntax)來決定是否要在 data element 中加上這個欄位，如果是 explicit 格式，data element 必須將 VR 明 確表示，若是 implicit 則可隱藏不需明示。
l Value Length
Value Length 則是表示在 Value Field 中之實際資料長度。 l Value Field
存放該 Data Element 的實際文字、數值、或圖形資料（需為偶數個位元組）。
圖 12 Data Element 的內部結構
2.8 DICOM Value Representations 範例
表 1 列出了部份的 VR 資料。
表 1 DICOM Value Representations
2char
code
Max
Length
Description
AE 16 Application Name
CS 16 Code String
DA 8 Date yyyymmdd (check for yyyy.mm.dd also and convert)
DS 16 Decimal String may start with + or - and may be padded with l or t space
DT 26 Date Time YYYYMMDDHHMMSS.FFFFFF&ZZZZ (&ZZZ is optional & = + or -)
LO 64 Character string. can be padded. cannot contain \ or any control chars except ESC
LT 10240 Long Text. Leading spaces are significant. trailing spaces arent
PN - Person's Name 64byte max per component. 5 components. delimiter = ^
SS 2 signed short integer (word)
ST 1024 Short Text of chars
TM 16 Time hhmmss.frac (or older format: hh:mm:ss.frac)
UI 64 Unique Identifier (delimiter = .) 0-9 only, trailing space to make even #
UL 4 Unsigned long integer
UN - unknown
UT - Unlimited Text. trailing spaces ignored
2.9 DICOM 的實際資料內容
底下為一個應用程式對 DICOM 做 Parsing 後得到的結果。
2.10 Annotation 的儲存方式
在 DICOM 內部，儲存 Annotation 的方式，可以採用 DICOM 標準內制定的儲存方 式，以及用自訂欄位連結到外部存放的方式
2.10.1 以 DICOM 標準格式存放
在下表中，顯示了 Annotation 的基本結構: 表 2 Annotation 組成結構 GraphicAnnotationSequence (0070,0001) GraphicAnnotationSequence { (0008,1140) ReferencedImageSequence (0070,0002) GraphicLayer (0070,0008) TextObjectSequence (0070,0009) GraphicObjectSequence } ReferencedImageSequence (0008,1140) ReferencedImageSequence { (0008,1150) ReferencedSOPClassUID (0008,1155) ReferencedSOPInstanceUID (0008,1160) ReferencedFrameNumber } TextObjectSequence (0070,0008) TextObjectSequence { (0070,0003) BoundingBoxAnnotationUnits (0070,0006) UnformattedTextValue (0070,0010) BoundingBoxTopLeftHandCorner (0070,0011) BoundingBoxBottomRightHandCorner (0070,0012) BoundingBoxTextHorizontalJustification } GraphicObjectSequence (0070,0009) GraphicObjectSequence { (0070,0005) GraphicAnnotationUnits (0070,0020) GraphicDimensions (0070,0021) NumberOfGraphicPoints(0070,0022) GraphicData (0070,0023) GraphicType (0070,0024) GraphicFilled } 從上表中可以看出，首先由 (0070,0001)開始進入一個巢狀的 annotation 結構, 內部 可能包含了很多組的 ReferencedImageSequence、GraphicLayer、TextObjectSequence、 GraphicObjectSequence 等等，以 TextObjectSequence 來說，(0070,0006)記錄了一個文字 類 型 的 annotation ， (0070,0010) 和 (0070,0011) 記 錄 了 此 annotation 的 座 標 ， 以 GraphicObjectSequence 來說，(0070,0023)記錄了 POLYLINE、CIRCLE 等圖形；因此， 利用這些組合，即可組成一個 DICOM 裡的 annotation 描述。下表為一個更細部的 Annotation 範例： 表 3 Annotation 的一個範例 GraphicAnnotationSequence
(0070,0001) SQ (Sequence with explicit Length #=2) # 1096, 1 GraphicAnnotationSequence
(fffe,e000) na (Item with explicit Length #=4) # 820, 1 Item
(0008,1140) SQ (Sequence with explicit Length #=1) # 122, 1 ReferencedImageSequence (fffe,e000) na (Item with explicit Length #=3) # 114, 1 Item
(0008,1150) UI =SecondaryCaptureImageStorage # 26, 1 ReferencedSOPClassUID (0008,1155) UI [1.2.826.0.1.36809.29274.2156968137] # 62, 1 ReferencedSOPInstanceUID (0008,1160) IS [1] # 2, 1 ReferencedFrameNumber (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (0070,0002) CS [TESTLAYER_1 0] # 14, 1 GraphicLayer (0070,0008) SQ (Sequence with explicit Length #=1) # 102, 1 TextObjectSequence (fffe,e000) na (Item with explicit Length #=5) # 94, 1 Item
(0070,0003) CS [PIXEL] # 6, 1 BoundingBoxAnnotationUnits
(0070,0006) ST [This is my text annotation ] # 28, 1 UnformattedTextValue (0070,0010) FL 123.492\238.041 # 8, 2 BoundingBoxTopLeftHandCorner (0070,0011) FL 136.451\71.1288 # 8, 2 BoundingBoxBottomRightHandCorner (0070,0012) CS [LEFT] # 4, 1 BoundingBoxTextHorizontalJustification (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (0070,0009) SQ (Sequence with explicit Length #=5) # 538, 1 GraphicObjectSequence (fffe,e000) na (Item with explicit Length #=6) # 84, 1 Item
(0070,0022) FL 227.627\118.285... # 16, 4 GraphicData (0070,0023) CS [POLYLINE] # 8, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e000) na (Item with explicit Length #=6) # 108, 1 Item
(0070,0005) CS [PIXEL] # 6, 1 GraphicAnnotationUnits (0070,0020) US 2 # 2, 1 GraphicDimensions (0070,0021) US 5 # 2, 1 NumberOfGraphicPoints (0070,0022) FL 64.4814\179.031... # 40, 10 GraphicData (0070,0023) CS [POLYLINE] # 8, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e000) na (Item with explicit Length #=6) # 82, 1 Item
(0070,0005) CS [PIXEL] # 6, 1 GraphicAnnotationUnits (0070,0020) US 2 # 2, 1 GraphicDimensions (0070,0021) US 2 # 2, 1 NumberOfGraphicPoints (0070,0022) FL 223.288\395.98... # 16, 4 GraphicData (0070,0023) CS [CIRCLE] # 6, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e000) na (Item with explicit Length #=6) # 100, 1 Item
(0070,0005) CS [PIXEL] # 6, 1 GraphicAnnotationUnits (0070,0020) US 2 # 2, 1 GraphicDimensions (0070,0021) US 4 # 2, 1 NumberOfGraphicPoints (0070,0022) FL 415.939\238.041... # 32, 8 GraphicData (0070,0023) CS [ELLIPSE] # 8, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e000) na (Item with explicit Length #=6) # 124, 1 Item
(0070,0005) CS [PIXEL] # 6, 1 GraphicAnnotationUnits (0070,0020) US 2 # 2, 1 GraphicDimensions (0070,0021) US 7 # 2, 1 NumberOfGraphicPoints (0070,0022) FL 358.664\308.332... # 56, 14 GraphicData (0070,0023) CS [POLYLINE] # 8, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(fffe,e000) na (Item with explicit Length #=3) # 260, 1 Item
(0008,1140) SQ (Sequence with explicit Length #=1) # 122, 1 ReferencedImageSequence (fffe,e000) na (Item with explicit Length #=3) # 114, 1 Item
(0008,1150) UI =SecondaryCaptureImageStorage # 26, 1 ReferencedSOPClassUID (0008,1155) UI [1.2.826.0.1.36800.29274.2156968137] # 62, 1 ReferencedSOPInstanceUID (0008,1160) IS [1] # 2, 1 ReferencedFrameNumber (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (0070,0002) CS [TESTLAYER_2 1] # 14, 1 GraphicLayer (0070,0009) SQ (Sequence with explicit Length #=1) # 92, 1 GraphicObjectSequence (fffe,e000) na (Item with explicit Length #=6) # 84, 1 Item
(0070,0005) CS [PIXEL] # 6, 1 GraphicAnnotationUnits (0070,0020) US 2 # 2, 1 GraphicDimensions (0070,0021) US 2 # 2, 1 NumberOfGraphicPoints (0070,0022) FL 104.4\64.4814... # 16, 4 GraphicData (0070,0023) CS [POLYLINE] # 8, 1 GraphicType (0070,0024) CS [N] # 2, 1 GraphicFilled (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem (0070,0041) CS [N] # 2, 1 ImageHorizontalFlip (0070,0042) US 90 # 2, 1 ImageRotation
(0070,005a) SQ (Sequence with explicit Length #=1) # 212, 1 DisplayedAreaSelectionSequence
(fffe,e000) na (Item with explicit Length #=6) # 204, 1 Item
(0008,1140) SQ (Sequence with explicit Length #=1) # 112, 1 ReferencedImageSequence (fffe,e000) na (Item with explicit Length #=2) # 104, 1 Item
(0008,1150) UI =SecondaryCaptureImageStorage # 26, 1 ReferencedSOPClassUID (0008,1155) UI [1.2.826.0.1.3680.29274.2156968137] # 62, 1 ReferencedSOPInstanceUID (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem
(0070,0052) SL 1\1 # 8, 2 DisplayedAreaTopLeftHandCorner (0070,0053) SL 512\512 # 8, 2 DisplayedAreaBottomRightHandCorner
(0070,0100) CS [MAGNIFY] # 8, 1 PresentationSizeMode (0070,0102) IS [10000\10000] # 12, 2 PresentationPixelAspectRatio (0070,0103) FL 1.15234 # 4, 1 PresentationPixelMagnificationRatio (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(0070,0060) SQ (Sequence with explicit Length #=2) # 156, 1 GraphicLayerSequence
(fffe,e000) na (Item with explicit Length #=4) # 70, 1 Item
(0070,0002) CS [TESTLAYER_1 0] # 14, 1 GraphicLayer (0070,0062) IS [1] # 2, 1 GraphicLayerOrder
(0070,0066) US 65535 # 2, 1 GraphicLayerRecommendedDisplayGrayscaleValue (0070,0068) LO [sample test layer 1] # 20, 1 GraphicLayerDescription (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem
(fffe,e000) na (Item with explicit Length #=4) # 70, 1 Item
(0070,0002) CS [TESTLAYER_2 1] # 14, 1 GraphicLayer (0070,0062) IS [2] # 2, 1 GraphicLayerOrder
(0070,0066) US 65535 # 2, 1 GraphicLayerRecommendedDisplayGrayscaleValue (0070,0068) LO [sample test layer 2] # 20, 1 GraphicLayerDescription
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 1 ItemDelimitationItem (fffe,e0dd) na (SequenceDelimitationItem for re-enc.) # 0, 1 SequenceDelimitationItem
2.10.2 以自訂欄位存放
由於 Annotation 的形式各式各樣，甚至可能包含了影音及其他多媒體的素材，使 得 Annotation 的儲存變得相當複雜，因此，也可以使用自訂欄位的方式儲存，方 法為新增一組新的 Tag，並依照 DICOM 的標準 Data Element 格式，定義出自己 所需的結構，同時也可以將 Data Element Value Field 內容，指到外部檔案，就可 以連結 DICOM 影像檔與外掛的 Annotation 檔案。
圖 14 自訂欄位範例
2.11 PACS 簡介
PACS 定義為「PACS 包括了影像的產生、處理、電訊 X 光造影術(Teleradiography)、
通訊工程、資料庫工程、軟體工程、及影像顯示站等工作的整合」。PACS 系統包含三
Tag
VR
Value
Length
Value
A55A,0001
1
0x0162
…
個主要子系統，分別為影像擷取(Image Acquisition)，影像儲存(Image Archiving)以及影 像展示 (Image DispIay)。這三個子系統透過標準介面，
以電腦網路連結。由圖 2-2 可看出 PACS 系統所牽涉到的技術包括: (1)影像擷取 (2) 影像處理及展示 (3)影像儲存及管理 (4)通訊網路(Communication Network) (5)儀器硬體 介面及標準(Equipment Interface and Standard)。
圖 15 PACS 系統架構圖(資料來源:電腦與通訊雜誌第 53 期第 41 頁)
2.11.1 影像擷取
醫學影像以其儲存的媒介之不同，又可區分為類比(Analog)影像及數位(Digital) 影像。類比影像包括傳統 X 光片、超音波等，這類影像必須經過雷射/光學掃描機 (Laser/Optical scarnner)或視訊擷取(Video Capturing)的方式加以數位化後才能儲存於 PACS 系統中。數位影像則包括電腦斷層攝影(Computer Tomography；CT)、核磁造影 (Magnetic Resonance Imaging；MRI)、電腦放射攝影(Computed Radiography；CR)、單光 子放射電腦斷層攝影(Single Photon Emission Computed Tomography)、正子放射電腦斷層 攝影(Position Emission Tomography；PET)等，這類影像只要透過適當介面，即能整合於 PACS 系統中。
2.11.2 影像處理及展示
影像處理包含平面(Two-DimensionaI)及立體 (Three-Dimensional)的影像處理。在 一般的醫學應用上，簡單的平面影像處理功能，如放大/縮小、旋轉、灰階調整等即已足 夠，而在較專業的醫學領域，如模擬開刀、放射治療劑量計算等，則需要複雜的立體描 繪處理(Surface/Volume Rendering) 。影像展示/查詢是 PACS 系統面對使用者的第一 線，也是 PACS 能否為使用者接受的首要因素之一。對醫師而言，簡單的使用介面(User
像解析度、方便的查詢介面等，比 PACS 系統所帶來的其他好處更為直接且重要。
2.11.3 影像儲存及管理
醫學影像資訊以其量大著稱，而且一般必須保存十年，而 PACS 資料除了影像 外，還包含文字、語音等。也就是說 PACS 資料庫除了必須支援多媒體資料外，還必須 提供足夠的儲存空間以容納累積十年的影像資料，以及順暢地(Smoothly)將影像移轉於 不同層級的儲存體。目前大部份的 PACS 系統均至少具備三級的影像儲存媒介，包括使 用者工作站的磁碟、磁碟陣列以及速度較慢但容量較大的 WORM 裝置(如光學 Jukebox) 或是 Tape Library。另一個牽涉到影像管理的問題為病人資料的一致性，這問題在於 PACS 中仍須儲存一定程度的病人基本資料，而與醫院資訊系統(Hospital Information System；HIS)中的資料重複，將造成資料不一致的可能性。因此在 PACS 建置過程中， 須特別注意建立 PACS 與 HIS 之間的良好介面及整合，使 PACS 成為醫院流程自動化 的一部份，如此不僅可以保證資料的一致性，更可減少重複輸入資料的麻煩。2.11.4 PACS 處理醫療影像的方式
PACS 之處理方式比傳統醫學影像處理的方式簡單許多。病患在照完 X 光片、 斷層掃描、核磁造影、、、等，經由醫學儀器顯現出影像後，利用目前現有的技術，將 所有的影像數位化， 轉換成 DICOM3.0 的格式， 亦可以轉換成點陣圖(Bit Map Graphic；BMP)、略失真壓縮的圖形檔格式(Joint Photographic Experts Group； JPEG)等 格式，以便於在網路上直接瀏覽。
2.12 國內 PACS 現況
PACS 的觀念從 1982 年開始萌芽，但發展的速度卻相當的緩慢，主要原因是受到當 時各種相關技術尚未成熟、成本過高及維護不易的限制，再加上引用數位化影像來代替 傳統放射膠片影像，不容易被醫師所接受，因此成果並不很明顯。但近幾年來，相關技 術的成熟，相關標準的制訂及各種零組件價格的降低，情況已經有了改變。此外因為個 人電腦的普及及網路蓬勃發展，使得新一代的醫生也漸漸能接受影像以數位顯示的方式 呈現2.12.1 全國醫療影像交換中心
由於 DICOM 目前已漸為製造廠商所接受，也解決了許多 PACS 建構之困擾。而民 國九十九年成立「全國醫療影像交換中心」，也架構於 DICOM+PACS 之上，對於醫療 影像處理單位主要可分為三個部份 l 影像交換中心：負責影像索引之管理、交換作業制度之修訂、交換平台提供及 維運。l 醫療機構：依健保局之規定提供、分享影像資源，為索引、報告、影像之提供 者，及提供病人跨院調閱報告、下載影像之診療服務。有 CT(電腦斷層攝影； Computed Tomography)、MRI(核磁共振攝影；Magnetic Resonance Imaging)、 PET(正子放射斷層攝影；Positron Emission Tomography)之醫院者，需傳送索引 至健保局，可查詢他院索引、調閱影像報告、下載影像及報告。無 CT、MRI、 PET 之醫院者，可查詢他院索引、調閱報告。目前共有 128 家醫療機構加入。 l 中央健康保險局：協助提供影像交換配套措施，加強影像交換作業。
2.12.2 國內醫療院所
在國內方面，目前各大醫院皆有發展 PACS 系統的計畫，例如台北醫學院將超音 波、胃鏡檢查室內的診斷工作站與掛號工作站及診斷報告工作站用網路連結起來成為一 個小型的 PACS 系統。在高雄小港醫院為全院性的 PACS 系統，包含的儀器有 CR、CT、 XA 及 Fluoro Scopy 等。所有影像在擷取到之後即儲存至影像伺服器，醫師可以透過院 內任何一部影像工作站來調閱這些影像，可達到無底片環境(filmless)的目標。還有三軍 總醫院在 87 年 7 月完成院內 PACS 系統第一期的建設，銜接的區域包括了放射診斷部、 急診室、加護病房與資訊中心，系統包括了影像擷取系統、影像傳輸系統、影像儲存系 統、影像顯示系統及影像列印五大系統。而連結上 PACS 的醫療影像儀器共計有兩部 CT、兩部 MR、一部心導管攝影、一部 X 光影像數位系統、一部 X 光片掃瞄工作站與 一部雷射洗片機，並將產生的影像傳輸至影像伺服器儲存。影像儲存系統包括影像儲存 主機及資料庫主機，儲存主機連接一部 50GB 磁碟陣列及 600GB 之 MO Jukebox 來儲存 大量之醫療影像，而資料庫主機採用 Oracle 7.3.2 資料庫管理系統，儲存方式則按 DICOM 3.0 所規範的層階式儲存，依據 Patient、Study、Series、Image 等四個階層來建立資料庫。 在網路傳輸方面則以 ATM 為骨幹之光纖網路，可以控制網路傳輸的品質並將影像快速 送至目的地。三、註解系統分析、設計與實做
3.1 註解系統架構說明
在我們實作的系統中，主要將系統分為五個部份， (1) DICOM 影像圖處理子系統 用以讀取、開啟、顯示、儲存 DICOM 檔案。 (2) 註解編輯子系統 提供新增、修改、刪除多媒體註解的功能。 (3) 註解儲存子系統 用以產生與 DICOM 影像檔的連結 Tag，並提供壓縮、儲存註解內容的功能。 (4) 註解瀏覽子系統 透過 DICOM 影像圖處理子系統，讀取 DICOM 影像檔案，並讀取、解壓縮註解 檔，顯示註解所在座標，播放多媒體註解。(5) Content Server 及外部 PACS Database
Content Server 用以儲存外部多媒體註解，PACS Database 則是我們使用的 DICOM 醫療影像檔的來源。
3.2 各子系統說明
3.2.1 DICOM 影像圖處理子系統
這個子系統主要負責處理 DICOM 影像。由於我們 DICOM 影像來自於 PACS 資料 庫，影像圖傳輸模組負責從 PACS 資料庫取得 DICOM 影像檔；取得的影像檔則透過 DICOM Header parsing 模組，解析檔案包含的 DICOM Data Element，並透過 DICOM 影 像圖顯示模組，顯示 DICOM 醫療影像的內容；Data Element 處理模組，則把自訂 Tag 及內涵的外部連結，以符合 DICOM 規格的方式，加進原始 DICOM 檔案中。 圖 17 DICOM 影像圖處理子系統 PACS DataBase DICOM 影像檔 影像圖傳輸模組 DICOM Header Parsing 模組 DICOM Data Element 處理模組 External Link /註解座標 DICOM影像圖處理子系統
3.2.2 註解編輯子系統
註解編輯子系統，提供註解新增、註解修改、註解刪除等操作模組，透過註解編及 介面，可以處理文字、影像、動畫、聲音、影片等多媒體註解。 圖 18 註解編輯子系統3.2.3 註解儲存子系統
產生的註解，透過資料壓縮模組進行壓縮，以減少註解檔的容量；Tag 建立模組， 負責建立自訂的 Tag，並把外部註解連結加在 Data Element 中；資料儲存模組，負責把 Tag，加上多媒體註解內容，儲存到 Content Server。3.2.4 註解瀏覽子系統
瀏覽註解時，透過註解資料傳輸模組，取得 Content Server 中的註解檔案；資料解 壓縮模組負責對有註解檔進行解壓縮；聲音及影像，則是需要啟動影音資料 PreFetch 模 組，確保註解播放的流暢度；圖層重疊模組，則把註解與透過「DICOM 影像圖處理子 系統」取得的 DICOM 影像圖做重疊，以顯示註解在影像圖上的位置；註解瀏覽介面， 則透過多媒體播放模組播放多媒體註解。 圖 20 註解瀏覽子系統3.3 DICOM Header 與外部註解的連結
在這一小節中，我們將說明在進行 DICOM 資料處理時，如何與外部註解作連結， 達到正確的顯示座標及對應的註解內容。
在 DICOM Header 中，我們使用自訂的 Tag 產生 Data Element，並在 Data Element 的 Value Filed，以文字記錄外部註解的連結位置，並藉由 Annotation Group 的方式加上座 標 Data Element。由於是自訂 Tag，其他 DICOM 工具不會去解析這個 Tag 而忽略它。但 是我們的註解工具，在開啟 DICOM 檔案時，會依據 Tag 所指的外部連結，去 Content Server 讀取註解檔，並在選取註解時，播放註解內容。
圖 21 自訂 Tag 的 Data Element
3.4 註解流程說明
在這個章節中，我們將針對 DICOM 影像檔產生註解時的各項操作流程進行說明， 包含註解產生，註解播放，註解修改。3.4.1 註解產生流程
使用這開啟 DICOM 影像圖後，如果有需要產生註解，首先需要指定註解對應到 DICOM 影像圖上的座標，然後選擇產生註解的型態，並依據不同的註解型態，使用不 同的註解產生介面(舉例來說：Audio 註解須開啟麥克風，Video 註解須開啟 Camera)。 做完註解後，產生使用自訂的 Tag 的 Data Element，並將自訂 Tag 依照 DICOM 格式， 加入原始 DICOM 影像圖。同時，結合自訂 Tag 的內容，與註解內容，並進行壓縮後，儲存至 Content Server 如下圖：
3.4.2 註解播放流程
讀取 DICOM 影像檔時，解析 Header，檢查 Header 中是否有包含我們的自訂 Tag 的 Data Element，如果沒有，則單純顯示原始 DICOM 影像檔。如果包含我們的自訂 Tag 的 Data Element，則依據 Tag 內容，到 Content Server 讀取對應的註解檔。
讀取出來的註解檔，解壓縮後之後，依據註解座標，重疊顯示在原始圖上。如果使 用這選取座標上註解，則依據註解內容進行播放(舉例來說:Audio 使用 Speaker 播放， Video 使用 PC 預設 Media Player 播放)。
3.4.3 註解修改流程
當使用者需要對已存在的註解進行修改，要先開啟 DICOM 影像檔，解析 Header， 檢查 Header 中是否有包含我們的自訂 Tag 的 Data Element，如果包含我們的自訂 Tag 的 Data Element，則顯示對應的註解座標。當使用者點選某一座標上的註解，並進行修改 後，系統產生新的對應 Data Element，並把 Data Element 更新到 DICOM 影像檔。同時 也結合自訂 Tag 的內容與註解內容，並進行壓縮後，儲存至 Content Server 如下圖：
3.5 實做說明
3.5.1 實做使用工具
本論文的實做，選擇以 ImageJ 作為開發工具，並使用其提供的 Plug-in 介面，作為 嵌入我們實做模組的方式。ImageJ 是由 National Institutes of Health (NIH)所開發的免費 影像軟體，其特色如下：
l 跨平台，使用 Java open source code l 支援種格式：
n Open and save GIF, JPEG, BMP, PNG, PGM, FITS and ASCII. n Open TIFFs, GIFs, JPEGs, DICOMs and raw data using a URL l Plug-in 附加步驟簡單
l 目前被廣泛的使用在生物醫學領域之中
選擇 ImageJ 這個工具的理由，主要是因為他已經具備開啟及儲存 DICOM 影像檔的 能力，我們可以不需要從頭撰寫 DICOM 影像檔處理工具，而專注在註解工具的開發； 同時因為 Plug-in 開發及使用方式極為容易，如果其他人要使用我們開發的模組，直接 將我們開發好的 Java Class，放到 ImageJ 的 Plug-in Folder，不需額外的安裝程序，即可 使用。
3.5.2 實做結構說明
依據本論文的 Annotator 設計內容，搭配現有 ImageJ 的功能，進行實做。如下圖 所示：左半邊為 ImageJ 既有的估能，右半邊為本論文開發的功能。
3.5.3 自定 DataElement 說明
本論文所自訂的 Data Element , 考量 0x0000 - 0x7FXX DICOM Spec 已經大量使 用，所以決定把自定的 Tag 定為 0xA55A，VR＝LT (Long Text)，VL 則根據後面 Value Field 的長度決定，整個 Data Element 內容如下：
A55A,0001
LT
XX
XXXXXX…
圖 27 自訂 Tag 的 Data Element
Value Field 欄位最前面，使用 8 個 bytes，用來記錄註解的種類，次序，所在座標。 後面才是實際的註解內容檔案：
四、討論
4.1 相容性問題探討
由於對 DICOM 增加註解之後，為了使 DICOM 影像檔，仍然可以被一般 DICOM 播放軟體進行播放，我們對註解工具做了以下的設計:
將新增的註解，以自訂 Tag 的方式(可參照 3.3 節說明)，產生 Data Element 並加入 DICOM Header，由於一般 DICOM Viewer 看到到自訂的 Tag, 不會去 parsing 內容，而 會跳過自訂的 Tag，繼續 Parsing 其他 Data Element，也就可以保持檔案對 DICOM 規格 的相容性。
4.1.1 DicomWorks 介紹
我們使用免費的 DICOM 瀏覽工具 – DicomWorks 作為驗證加入自定 Tag 相容性的 工具。DicomWorks 是一個免費的 DICOM 瀏覽器，擁有超過 50000 個註冊用戶，並超 過 20 萬次下載，具有 18 種語言版本；在免費 DICOM Viewer 中，屬於被廣為使用的一 個軟體。下圖為使用 DicomWorks 開啟的原始 DICOM file.及 Tag list
4.1.2 新增 Data Element 驗證
經由我們的註解工具，產生註解並對原始 DICOM 檔案加入自訂的外部註解連結 Tag (A55A,0001)，再使用 DicomWorks，仍然可以正常開啟，並可以看到有 A55A 的 Tag 被 parse 出來：
圖 30 新增自訂 Tag 後的 DICOM File
4.1.3 Data Element 存放位置討論
由於 Dicom 規格中，關於 pixel data 內容，仍然可以視為一組 Data Element， 以下圖為例：藍色部分為 Tag(7FE0,0000) = Pixel Data Group Length，VR = UL， Value Length = 4，Value Field = 0x8000c；用來說明後面的 pixel data 總共長 度為 524300bytes；接下來則是 Tag(7FE0,0010) = Pixel Data，用來儲存實際的 Pixel Data 內容。
圖 31 Pixel Data 的 Data Element 結構說明
所以我們新增的 Data Element 其實不一定要放在 pixel Data 之前，也可以直接 Append 在 Dicom 檔案的最後面，只要是正確的 Data Element 格式，仍然可以保有 DICOM 相容性。
圖 32 Annotator Data Element 存放於檔尾
但是大部分的 DicomViewer，對於 Data Element 的 parsing，都僅止於於 Pixel Data，所以把 Annotator Header 加於檔尾，如果 Viewer 沒有把 Pixel Data 也視為一 組 Data Element，一直 parsing 到檔案結束，就有可能 parsing 不到自訂的 Tag：
圖 33 檔尾有 Annotator Data Element，DicomWorks 無顯示
為了避免產生誤會，我們仍然是把 Annotator 用的自訂 Data Element，存放於 Pixel Data 之前。
4.2 註解存放播放方式探討
DICOM 醫療影像檔中，註解可以用標準格式存放或是用自訂欄位存放，雖然同樣 可以儲存於 PACS 系統，不影響其流通性；但是註解播放方式則因播放軟體而有所不同， 以下進行相關討論。4.2.1 以標準格式存放
標準格式註解(參照 2.10.1 節)的欄位是固定在 Specification 中，醫療影像播放軟 體，只要有依照 DICOM 標準進行實做，就可以順利播放標準格式的註解，但也由於在 Specification 制定時就定義完成，所以能表達的內容有限。同時，也因為任何軟體皆可 以播放其註解內容，醫療人員製作數位註解時，可能因為牽涉到智慧財產權的爭議而有 所保留。4.2.2 以自定欄位存放
如果使用本論文提出的自定欄位存放(參照 2.10.2 節)，醫療影像檔仍然可以透過 DICOM 格式，於 PACS 系統中使用。但是其他播放軟體(Example: DicomWorks)無法識 別我們的自訂 Tag，也不會了解我們自訂註解的代表的涵義，以及註解的內容。除非使 用我們製作的 MultiMedia Annotator，才能順利看到註解內容。但是對於使用 DICOM 規 範的 Internal Annotation Tag 方式儲存的註解，仍然可以播放。
4.2.3 註解方式的多樣化
由於 DICOM 標準中 Standard Annotation Tag 能夠表達的內容有限，而使用本論文註 解工具，則可提供多媒體的方式，讓使用者視需要選擇不同媒體型態進行註解。
4.2.4 使用自訂註解的誘因
由於註解往往包含醫療專業人員本身的經驗，可以透過 DRM，對於醫療人員保障註 解製作者的製作財產權，進而提高醫療人員使用註解工具的意願。
五、實做展示
5.1 展示說明
在展示章節中，會說明我們實做的多媒體註解工具，對於 DICOM 數位醫療影像檔 提供的多媒體註解方法，以及如何播放含有多媒體註解的 DICOM 數位醫療影像檔。 展示內容主要分為以下幾個部份： l 在 DICOM 檔案上產生多媒體註解 (文字、圖片、動畫、聲音、影片) l 開啟、播放含有自訂註解的 DICOM 檔案 l 編輯、修改 DICOM 檔案上的註解內容5.2 DICOM 檔案上產生多媒體註解
在這一節裡，我們主要介紹如何開啟現有的 DICOM 檔案，並指定位置，產生各種 多媒體註解。5.2.1 開啟 DICOM 檔案
1. 直接於 Plug-in 執行編譯好的 Multi-Media Annotator
2. 開啟現有的 DICOM 檔案，如果檔案內不含自訂註解，預設為註解錄製模式。
圖 35 開啟現有 DICOM 檔案
5.2.2 新增註解-以 Text 為例
1. 在 DICOM 圖像上標記註解位置，並指定註解種類為 Text
2. 輸入註解內容，按”OK”確認儲存註解，並同時新增自訂註解欄位到原始 DICOM 檔案中。
圖 37 執行 Annotator 3. 完成後顯示錄製的註解
5.2.3 新增註解-以 Audio 為例
1. 在 DICOM 圖像上標記註解位置，並指定註解種類為 Audio
圖 39 標記註解位置及指定 Aduio 註解
2. 按”OK”開始錄製 Audio 註解，同時出現”Stop”,”Pasue”,”Cancel”操作視窗。
3. 按”Stop”確認完成錄製並儲存註解，並同時新增自訂註解欄位到原始 DICOM 檔 案中。 圖 41 顯示錄製完成的註解-Audio
5.2.4 新增註解-以 Video 為例
1. 在 DICOM 圖像上標記註解位置，並指定註解種類為 Video 圖 42 標記註解位置及指定 Video 註解2. 按”OK”開始錄製 Video 註解，同時出現影像預覽視窗
圖 43 錄製 Video Annotator
3. 關閉影像視窗結束 Video 註解錄製，並同時新增自訂註解欄位到原始 DICOM 檔 案中。
5.3 開啟、播放含有自訂註解的 DICOM 檔案
在這一節裡，我們利用 Annotator 開啟包含有自訂註解的 DICOM 檔案，並指定其 中的多媒體註解；依據指定的註解，顯示所標示的位置並播放其內容。5.3.1 開啟含有自訂註解的 DICOM 檔案
開啟的 DICOM 檔案如果已經含有自訂註解，則將所有的自訂註解顯示在註解列表 視窗，預設行為為註解播放模式。 圖 45 開啟包含自訂註解的 DICOM 檔案5.3.2 播放多媒體註解-以 Text 為例
1. 選擇要播放的多媒體註解，按”OK”確認播放。
2. 於 DICOM 檔案上以紅色箭頭顯示註解所標示的位置，並將文字註解內容顯示 於 DICOM 影像檔上及 Text Annotation 視窗。
圖 46 播放 Text 註解
5.3.3 播放多媒體註解-以 Video 為例
1. 選擇要播放的多媒體註解，按”OK”確認播放。
2. 於 DICOM 檔案上以紅色箭頭顯示註解所標示的位置，並將 Video 註解內容顯示 於播放視窗。
5.4 修改、刪除 DICOM 檔案上的註解內容
在這一節裡，我們利用 Annotator 開啟已經包含有自訂註解的 DICOM 檔案，並針 對已存在的多媒體註解進行編輯、修改、刪除。5.4.1 修改自訂註解
開啟的 DICOM 檔案如果已經含有自訂註解，則將所有的自訂註解顯示在註解列表 視窗，選擇註解修改模式對現有註解進行修改。 1. 選擇註解修改模式並指定要修改的註解 2. 選擇要變更的註解種類，並指定新的註解位置 圖 49 指定要修改的註解3. 修改註解位置及註解內容 圖 50 修改後的註解
5.4.2 刪除自訂註解
開啟的 DICOM 檔案如果已經含有自訂註解，則將所有的自訂註解顯示在註解列表 視窗，選擇註解刪除模式對現有註解進行修改。 1. 選擇註解修改模式並指定要修改的註解2. 刪除後註解列表
六、結論
6.1 總結
既有的數位醫療影像檔上的註解技術，無法同時兼顧多媒體註解與 DICOM 格式的 相容性。 本論文提出的註解方法，解決了既有醫療影像檔上註解方式的缺點，同時滿足以下 特點， l 相容於 DICOM 格式 l 提供直接在醫療影像圖上面直接附加多媒體註解的能力 表 4 本論文註解特色比較表S.H. Jang’s M. Möller’s C.Y. Lien’s Our’s
文字、圖形註解 ˇ ˇ ˇ ˇ 影像註解 ˇ ˇ ˇ 聲音註解 ˇ ˇ 影片註解 ˇ ˇ 註解支援 DICOM ˇ ˇ ˇ
6.2 未來發展方向
l 可結合 Partial DRM，提供”取得授權者”瀏覽 DICOM 影像檔上的註解，以 保護註解製作者的智慧財產權。l 本研究為單機版本，ImageJ 也有提供 Java Applet 版本，可直接內嵌於網頁， 未來可結合雲端概念，移植成 Web-base 版本。
REFERENCES
[1] Digital Imaging and Communications in Medicine (DICOM), NEMA
Publications,"WORKING GROUPS of the DICOM Standards Committee", 2002, available at: ftp://medical.nema.org/medical/dicom/Geninfo
[2] Digital Imaging and Communications in Medicine (DICOM), NEMA Publications, "DICOM Standard", 2008, available at: ftp://medical.nema.org/medical/dicom/2008 [3] Seok-Hwan Jang, Whoi-Yul Kim, Defining a new annotation object for DICOM image:
a practical approach, Computerized Medical Imaging and Graphics, vol. 28, Issue 7,2004, pp.371-375.
[4] Sven Regel, Michael Sintek., RadSem: Semantic Annotation and Retrieval for Medical Images, Manuel Möller, Proceedings of the 6th European Semantic Web Conference on The Semantic Web: Research and Applications (ESWC2009), 2009.
[5] Chung-Yueh Lien, Hsu-Chih Teng, Deng-Ji Chen, Woei-Chyn Chu and Chia-Hung Hsiao, A Web-Based Solution for Viewing Large-Sized Microscopic Images, Journal of Digital Imaging, vol. 22, no. 3, 2009, pp. 275-285.
[6] Digital Imaging and Communications in Medicine (DICOM), NEMA Publications," DICOM strategic document," Ver. 8.0, April 2008, available at:
http://medical.nema.org/dicom/geninfo/Strategy.pdf
[7] W. Dean Bidgood, Jr., MD, MS, Steven C. Horii, MD, Fred W. Prior, PhD, and Donald E. Van Syckle, "Understanding and Using DICOM, the Dana Interchange Standard for Biomedical Imaging", Journal of the American Medical Informatics Association, Vol. 4, No. 3, May 1997, pp. 199-212
[8] Peter Mildenberger, Marco Eichelberg, Eric Martin "Introduction to the DICOM standard," European Radiology, Vol. 12, No. 4, April 2002, pp. 920-927
[9] Steven C. Horiil, Fred W. Prior, W. Dean Bidgood, Jr., Charles Parisot, Geert Claeys, "DICOM: An Introduction to the Standard", 1994, available at:
http://www.csd.uoc.gr/~hy544/mini_projects/Project8/DICOM%20(Paper_Parisot).doc [10] Kelly Welch, "Digital Imaging and Communications in Medicine: DICOM", April
2004,available at:
http://svn.assembla.com/svn/PdC3_Rubel/references/WelchDICOM2.doc
[11] R.N.J. Graham, R.W. Perriss, A.F. Scarsbrook,"DICOM demystified: A review of digital file formats and their use in radiological practice",Clinical Radiology, Vol. 60, June 2005, pp.1133-1140
[12] 全國醫療影像交換中心http://image.doh.gov.tw/intro.html
[13] Jonathan Whitby, White Paper The DICOM standard",
[14] David S. Channin, Pattanasak Mongkolwat, Vladimir Kleper, Kastubh Sepukar, and Daniel L. Rubin," The caBIG™ Annotation and Image Markup Project", Journal of
