DICOM 影像格式標籤 ( Tags ) 分析
要對醫學影像做進一步的處理，就必須了解DICOM 影像的格式與資訊，在DICOM 的影像
格式包含了兩大部分，其ㄧ為像素資料(pixel data)，其二為影像屬性(attribute)，
影像屬性部份位於檔案格式的檔頭，故也稱DICOM Header ，檔頭內對於資料的紀錄，
採用了唯一的標籤(Tag) 以識別，標籤(Tag )內包含了群組代號(Group number)與
元素代號(Element number) ，如下圖1所示: Patient Name 的Tag 為 (0010,0010)
其0010 為此群組代號(Group number)，而後面的0010 則為元素代號(Element number)，
這些相關Tag 的說明可以參考DICOM 的文件，由於DICOM文件都已經定義好這相關的Tag
訊息與描述，讓不管是儀器設備或PACS 系統的廠商，在開發應用程式時，有了標準
可以依循。
圖1
了解了DICOM Tag 的用意後，我們來看CT的檔頭資料共包含了哪些模組(Modules)，
如圖2所示為CT 影像的檔頭資料。
從圖所示，CT 影像的檔頭資料，包含了許多的模組(Modules)，這些模組就如
一個一個的物件資料，相同模組訊息的資料會有相同的群組代號(Group number)，
故非常容易辨別這元素代號(Element number)值所表示的意義。
DICOM 定義中Modality 群組的代號為 [0008]，Patient 群組的代號為[0010] ，
Study 群組的代號為 [0020]，Image 群組的代號為[0028]，Pixel群組的代碼為[007F]，
其餘相關Tag 的詳細說明請參考DICOM 的第三章。
DICOM 資料結構
DICOM 的發展背景完全是針對醫學應用領域來開發的，其主要的功能是提供數位化的醫學影像，並將醫療影像傳遞於網路上，以方便儲存與調閱、管理。我們可以簡單的將DICOM定義為「醫學影像儀器和軟體間共通的通訊規格」。
傳統的資訊系統在處理影像資料時，完全只專注於資料本身的排列方式，與演算法的應用。而DICOM則不同，它將每個影像包裹成一個物件 IOD (Information Object Definition)，而每個IOD可分為兩大部分：像素資料(pixel data)、影像屬性(attribute)如圖1所示。所謂像素資料就和傳統方法一般，單純描述每一個圖像點的值，組合成一個影像；而影像屬性的部分：則摘要了基本資訊。如：病患姓名、病歷號碼、檢查項目和日期、更包含了影像訊息...等，一方面方便資料庫在搜尋資料的過程，另一方面可將這些資訊轉換為影像的一部份，在日後調閱影像時提供重要參考。
DICOM 影像格式中有其標準的組織定義，其相關的資料訊息皆有標準的關連性樹狀聯接著，如圖2所示:結構樹狀內，方塊圖Patient、Study、Series已至最下層的Image 層，記錄著影像內重要的訊息，依照儀器的不同，其影像訊息所記錄的資料內容將有所不同，其中最大的差別性在於Image 層。
圖2.Patient、Study、Series、image 樹狀圖
DICOM 影像格式裡的影像屬性(attribute)，包含了許多IOD Module 模組，如下表1中所示，其橫軸包含了儀器的種類，而其縱軸則為IOD 模組，其中: M=Mandatory 表示為必要資料內容 , C=Coditonal 表示為條件式的資料內容, U=User Option 表示為非必要的資料內容。
DICOM Tag 資料型態說明
DICOM 定義的標準裡，就是透過 DICOM Tag 的方式將影像資料由 A 系統或儀器設備
傳遞到 B 系統或儀器設備時，B系統與儀器能馬上解讀 B系統或儀器所傳送出的影像
資料，這全都是依賴已經定義好的 DICOM Tag 資料位置與資料型態，資料位置
定義模式如 ( 0000,0001 ) 其第一個資料 0000 定義為 Group Item ，而後面的 0001
定義為Element 資料元素，再包含定義好的資料型態格式，則可以輕易的解讀
資料內容，其相關的資料的型態如下所示:
| UL-Unsigned Long | UI-Unique Identifier |
| CS-Code String | US-Unsigned Short |
| AE-Application Entity | AT-Attribute Tag |
| LO-Long String | SH-Short String |
| IS-Integer String | OB-Other Byte |
| SQ-Sequence of Items | DA-Date |
| TM-Time | DT-Date Time |
| ST-Short Text | PN-Person Name |
| DS-Decimal String | FL-Floating Point Single |
| AS-Age String | LT-Long Text |
| FD-Floating Point Double | SL-Signed Long |
| SS-Signed Short | OW-Other Word |
由於DICOM 所定義的資料型態不容易記憶，所以還是必須透過工具來
解讀。
以下整體的資料依照順序排列::
| Value Representation | Description |
|---|---|
| AE | Application Entity |
| AS | Age String |
| AT | Attribute Tag |
| CS | Code String |
| DA | Date |
| DS | Decimal String |
| DT | Date/Time |
| FL | Floating Point Single (4 bytes) |
| FD | Floating Point Double (8 bytes) |
| IS | Integer String |
| LO | Long String |
| LT | Long Text |
| OB | Other Byte |
| OF | Other Float |
| OW | Other Word |
| PN | Person Name |
| SH | Short String |
| SL | Signed Long |
| SQ | Sequence of Items |
| SS | Signed Short |
| ST | Short Text |
| TM | Time |
| UI | Unique Identifier |
| UL | Unsigned Long |
| UN | Unknown |
| US | Unsigned Short |
| UT |
Unlimited Text
|
醫療雲端概念
**Patient /Doctor carry with all the DICOM Images and report store ,
electronic medical record in cloud.
**Hospital / Clinic easily manage Patient images and electronic medical record
for exchange and shared (outside).
**Clinic easily images store in cloud.
**Hospital / Clinic easily for Tele-Radiology service and emergent event.
**Doctor easily manage your patient data and teaching file in cloud.
**Provide across platforms desktop,laptop, or Android phone, iOS.
**Easy for synchronized , backup , recovery , virus scan ,security.
**Provide upload and download ,Search ,re-view.
**Provide more medical application software in the cloud.
DICOM 工具
此網站提供了 DICOM 工具使用，不管你是醫療資訊界的新手還是舊手
都可以下載免費使用。
如果看了這些工具的名稱但還是看不太懂工具的用意也可以連到網站內的說明
我相信手裡有這些工具肯定可以讓你功力大增的，不過回到醫療資訊的本質
工具只能幫你找到訊息，問題的重點還是要了解 DICOM 的內涵。
DICOM 網路傳輸協定
DICOM規範開發之初，除了定義DICOM 影像標準外，第二重點就是將其應用範圍訂在網路的溝通上。如下圖 1所示: 我們可以輕易的了解DICOM 通訊協定的應用必須架構在TCP/IP通訊協定的上層。
圖1.DICOM 網路與OSI 七層
DICOM 網路服務依據 ISO 7498-1 定義了
a. Application Entrity 如下圖2所表示的灰色部分 b. Service or Layer Service c. Application Entity Title .
圖2.Application Entiry
DICOM 定義了兩種型態的 Service-Object Pair (SOP) Classes 包含Normalized 及 Composite 兩種，使用一個SOP Classes 服務必須遵守一方為Service Class User (SCU) 服務定義，而另一方為 Service Class Provider (SCP) 服務定義，才可正常運作。
DICOM Service-Oject Pair (SOP) Classe 中提供了許多資訊交換的服務，包含
ØVerification Service Class ( Normative)
使用 C-ECHO DIMSE-C 訊息命令服務確認DICOM AEs 雙方已經完成動作，一端DICOM AE支援 Verificatoin SOP Class SCU 角色對遠端的DICOM AE 必須支援 Verification SOP Class SCP角色提出事件需求，遠端DICOM AE也會回送C-ECHO DIMSE-C 訊息命令已表確認。
ØStorage Service Class (Normative)
使用 C-STORE DIMSE-C 訊息命令已完成兩DICOM AEs 雙方完成儲存動作，一端 DICOM AE支援 SCU 角色對遠端 DICOM AE 支援 SCP角色進行影像儲存之動作。
關於C-STORE 訊息狀態如下表1所示 :
表1 . C-Store Service Status
|
Service Status
|
Further Meaning
|
Status Codes
|
Related Fields
|
|
Failure
|
Refused: Out of Resources
|
A7xx
|
(0000,0902)
|
|
|
Error: Data Set does not match SOP Class
|
A9xx
|
(0000,0901)
(0000,0902)
|
|
|
Error: Cannot understand
|
Cxxx
|
(0000,0901)
(0000,0902)
|
|
Warning
|
Coercion of Data Elements
|
B000
|
(0000,0901)
(0000,0902)
|
|
|
Data Set does not match SOP Class
|
B007
|
(0000,0901)
(0000,0902)
|
|
|
Elements Discarded
|
B006
|
(0000,0901)
(0000,0902)
|
|
Success
|
|
0000
|
None
|
SOP Classes 在DICOM Tag IODs內定義了標準的 Class UID 以來辨認SCU所傳送至SCP 的影像格式，其相關的 SOP Class UID 表示如下表2所示:
表2.SOP Class UID
|
SOP Class Name
|
SOP Class UID
|
IOD Specification
(defined in PS 3.3) |
|
Computed Radiography Image Storage
|
1.2.840.10008.5.1.4.1.1.1
|
|
|
Digital X-Ray Image Storage - For Presentation
|
1.2.840.10008.5.1.4.1.1.1.1
|
DX IOD (see B.5.1.1)
|
|
Digital X-Ray Image Storage - For Processing
|
1.2.840.10008.5.1.4.1.1.1.1.1
|
DX IOD (see B.5.1.1)
|
|
Digital Mammography Image Storage - For Presentation
|
1.2.840.10008.5.1.4.1.1.1.2
|
Digital Mammography IOD (see B.5.1.2)
|
|
Digital Mammography Image Storage - For Processing
|
1.2.840.10008.5.1.4.1.1.1.2.1
|
Digital Mammography IOD (see B.5.1.2)
|
|
Digital Intra-oral X-Ray Image Storage - For Presentation
|
1.2.840.10008.5.1.4.1.1.1.3
|
Digital Intra-oral X-Ray IOD (see B.5.1.3)
|
|
Digital Intra-oral X-Ray Image Storage - For Processing
|
1.2.840.10008.5.1.4.1.1.1.3.1
|
Digital Intra-oral X-Ray IOD (see B.5.1.3)
|
|
CT Image Storage
|
1.2.840.10008.5.1.4.1.1.2
|
|
|
Enhanced CT Image Storage
|
1.2.840.10008.5.1.4.1.1.2.1
|
Enhanced CT Image (see B.5.1.7)
|
|
Ultrasound Multi-frame Image Storage
|
1.2.840.10008.5.1.4.1.1.3.1
|
|
|
MR Image Storage
|
1.2.840.10008.5.1.4.1.1.4
|
|
|
Enhanced MR Image Storage
|
1.2.840.10008.5.1.4.1.1.4.1
|
Enhanced MR Image (see B.5.1.6)
|
|
MR Spectroscopy Storage
|
1.2.840.10008.5.1.4.1.1.4.2
|
MR Spectroscopy
|
|
Ultrasound Image Storage
|
1.2.840.10008.5.1.4.1.1.6.1
|
|
|
Secondary Capture Image Storage
|
1.2.840.10008.5.1.4.1.1.7
|
|
|
Multi-frame Single Bit Secondary Capture Image Storage
|
1.2.840.10008.5.1.4.1.1.7.1
|
Multi-frame Single Bit Secondary Capture Image
|
|
Multi-frame Grayscale Byte Secondary Capture Image Storage
|
1.2.840.10008.5.1.4.1.1.7.2
|
Multi-frame Grayscale Byte Secondary Capture Image
|
|
Multi-frame Grayscale Word Secondary Capture Image Storage
|
1.2.840.10008.5.1.4.1.1.7.3
|
Multi-frame Grayscale Word Secondary Capture Image
|
|
Multi-frame True Color Secondary Capture Image Storage
|
1.2.840.10008.5.1.4.1.1.7.4
|
Multi-frame True Color Secondary Capture Image
|
|
12-lead ECG Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.1.1
|
12-lead ECG Waveform
|
|
General ECG Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.1.2
|
General ECG Waveform
|
|
Ambulatory ECG Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.1.3
|
Ambulatory ECG Waveform
|
|
Hemodynamic Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.2.1
|
Hemodynamic Waveform
|
|
Cardiac Electrophysiology Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.3.1
|
Cardiac Electrophysiology Waveform
|
|
Basic Voice Audio Waveform Storage
|
1.2.840.10008.5.1.4.1.1.9.4.1
|
Basic Voice Audio Waveform
|
|
Grayscale Softcopy Presentation State Storage
|
1.2.840.10008.5.1.4.1.1.11.1
|
Grayscale Softcopy Presentation StateStorage
|
|
Color Softcopy Presentation State Storage
|
1.2.840.10008.5.1.4.1.1.11.2
|
Color Softcopy Presentation State
|
|
Pseudo-Color Softcopy Presentation State Storage
|
1.2.840.10008.5.1.4.1.1.11.3
|
Pseudo-ColorSoftcopy Presentation State
|
|
Blending Softcopy Presentation State Storage
|
1.2.840.10008.5.1.4.1.1.11.4
|
Blending Softcopy Presentation State
|
|
X-Ray Angiographic Image Storage
|
1.2.840.10008.5.1.4.1.1.12.1
|
|
|
Enhanced XA Image Storage
|
1.2.840.10008.5.1.4.1.1.12.1.1
|
|
|
X-Ray Radiofluoroscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.12.2
|
|
|
Enhanced XRF Image Storage
|
1.2.840.10008.5.1.4.1.1.12.2.1
|
|
|
Nuclear Medicine Image Storage
|
1.2.840.10008.5.1.4.1.1.20
|
|
|
Raw Data Storage
|
1.2.840.10008.5.1.4.1.1.66
|
Raw Data
|
|
Spatial Registration Storage
|
1.2.840.10008.5.1.4.1.1.66.1
|
Spatial Registration
|
|
Spatial Fiducials Storage
|
1.2.840.10008.5.1.4.1.1.66.2
|
Spatial Fiducials
|
|
Deformable Spatial Registration Storage
|
1.2.840.10008.5.1.4.1.1.66.3
|
Deformable Spatial Registration
|
|
Segmentation Storage
|
1.2.840.10008.5.1.4.1.1.66.4
|
Segmentation
|
|
Real World Value Mapping Storage
|
1.2.840.10008.5.1.4.1.1.67
|
Real World Value Mapping
|
|
VL Endoscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.1
|
VL Endoscopic Image
|
|
Video Endoscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.1.1
|
Video Endoscopic Image
|
|
VL Microscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.2
|
VL Microscopic Image
|
|
Video Microscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.2.1
|
Video Microscopic Image
|
|
VL Slide-Coordinates Microscopic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.3
|
VL Slide-Coordinates Microscopic Image
|
|
VL Photographic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.4
|
VL Photographic Image
|
|
Video Photographic Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.4.1
|
Video Photographic Image
|
|
Ophthalmic Photography 8 Bit Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.5.1
|
Ophthalmic Photography 8 Bit Image
|
|
Ophthalmic Photography 16 Bit Image Storage
|
1.2.840.10008.5.1.4.1.1.77.1.5.2
|
Ophthalmic Photography 16 Bit Image
|
|
Stereometric Relationship Storage
|
1.2.840.10008.5.1.4.1.1.77.1.5.3
|
Stereometric Relationship
|
|
Basic Text SR
|
1.2.840.10008.5.1.4.1.1.88.11
|
Basic Text SR
|
|
Enhanced SR
|
1.2.840.10008.5.1.4.1.1.88.22
|
Enhanced SR
|
|
Comprehensive SR
|
1.2.840.10008.5.1.4.1.1.88.33
|
Comprehensive SR
|
|
Procedure Log
|
1.2.840.10008.5.1.4.1.1.88.40
|
Procedure Log
|
|
Mammography CAD SR
|
1.2.840.10008.5.1.4.1.1.88.50
|
Mammography CAD SR IOD
|
|
Key Object Selection
|
1.2.840.10008.5.1.4.1.1.88.59
|
Key Object Selection Document
|
|
Chest CAD SR
|
1.2.840.10008.5.1.4.1.1.88.65
|
Chest CAD SR IOD
|
|
X-Ray Radiation Dose SR
|
1.2.840.10008.5.1.4.1.1.88.67
|
X-Ray Radiation Dose SR
|
|
Encapsulated PDF Storage
|
1.2.840.10008.5.1.4.1.1.104.1
|
Encapsulated PDF IOD
|
|
Positron Emission Tomography Image Storage
|
1.2.840.10008.5.1.4.1.1.128
|
|
|
RT Image Storage
|
1.2.840.10008.5.1.4.1.1.481.1
|
|
|
RT Dose Storage
|
1.2.840.10008.5.1.4.1.1.481.2
|
|
|
RT Structure Set Storage
|
1.2.840.10008.5.1.4.1.1.481.3
|
|
|
RT Beams Treatment Record Storage
|
1.2.840.10008.5.1.4.1.1.481.4
|
|
|
RT Plan Storage
|
1.2.840.10008.5.1.4.1.1.481.5
|
|
|
RT Brachy Treatment Record Storage
|
1.2.840.10008.5.1.4.1.1.481.6
|
|
|
RT Treatment Summary Record Storage
|
1.2.840.10008.5.1.4.1.1.481.7
|
|
|
RT Ion Plan Storage
|
1.2.840.10008.5.1.4.1.1.481.8
|
IOD defined in PS 3.3
|
|
RT Ion Beams Treatment Record Storage
|
1.2.840.10008.5.1.4.1.1.481.9
|
IOD defined in PS 3.3
|
ØQuery/Retrieve Service Class (Normative)
使用 DIMSE-C C-FIND,C-MOVE 及 C-GET訊息命令已完成兩DICOM AEs 雙方完成影像調閱及回傳的動作，一端 DICOM AE 支援 SCU 角色對遠端 DICOM AE 支援 SCP角色進行動作。
DICOM Message Exchange訊息交換，定義了關於 a. DICOM Message Service Element (DIMSE) b. DIMSE-N Service c.DIMSE-C Service d. DIMSE Service Group (DSG)。
其整體的 DICOM Message Exchange 於整體的通訊協定上的運作模式如下圖3所示:
圖3 .DICOM Message Exchange
整體的DICOM Message 分為兩大類 a. Command Set (圖4)，b. Data Set (圖5)，於Command Set 內的元件特別定義包含 Tag 、Length、Value 已確定DICOM 訊息命令。
圖4 .DICOM Message
而其 Data Set 內的Data 元件包含了 Tag、VR、Value Length、Value Field
已確定病患基本資料、檢查資料、儀器資料、影像資料等。
圖5 .Data Set
DICOM WADO 支援
DICOM 提供Web Access to DICOM Persistent Ojects 標準以下簡稱WADO ，可在HTML (HyperText Markup Language)Page 或XML(eXtensible Markup Language) 文件下執行DICOM 影像，並透過HTTP(HyperText Transfer Protocol)/HTTPs(HyperText Transfer Protocol,secured)的協定來使用DICOM UIDs ( Unique Identifiers) 。
圖1 .DICOM WADO(Web Client & Web Enabled DICOM Server)
有了WADO 的支援模式，所有報告系統可以輕易的透過URL命令將影像資料進行整合，如下為影像取得的命令，說明如下:
影像取得範本:
nhttp://wado_server/WebPush/WebPush.dll?PushWADO?requestType=WADO&contentType=image/jpeg&rows=256&objectUID=1.2.410.200010.200601180252196784.20060118.1.1
說明:
說明:
u需求模式 : WADO
u影像資料型別 : image/jpeg , application/dicom, etc
u長/寬 : 256 (Size of image)
u影像物件UID : instance uid
整合影像+報告範本:
只要透過URL 的方式，報告系統也可以輕易的整合於報告內，影像的顯示有助於醫師挑選預列印之影像內容。
圖2 .報告系統與影像的整合畫面
DICOM Structure Reporting(SR) 簡介
一、什麼是 DICOM SR？
首先讓我們來看看SR這兩個字到底有什麼樣的意義，簡單來說，它是Structured Reporting的縮寫，也就是結構化的醫學報告。
一般傳統的醫學報告，包括常見的病歷或醫學研究報告，不論手寫或電腦打字，多半是以條列式的文字來陳述，換句話說，也就是白紙黑字的一行一行寫出內容，而無法靈活的呈現醫生腦中的各種想法。
所謂結構化這個觀念，當然是為了改良傳統條列式的報告而發展出來的，它將一份完整的報告分解成一個個小項目，每個項目只包含一組Name/Value Name代表該項目的主題，Value是它的值，例如：病歷號碼=12345、呼吸=每分鐘15次、體溫=38度、主訴=”頭痛,流鼻水”就是四組Name/Value項目。最後再利用一些連結關係將這些項目組合在一起，就成為一份完整的報告內容。
二、SR document的優點：
經過上面的介紹，相信大家還是不能感覺到SR document的好處，以下我們就利用一些簡單的例子來說明SR到底具有何種威力。
1.靈活的報告呈現方式：
單就文字的部分而言，以上述的例子來說，在呈現的時候，可以仿照windows常用的檔案樹方式，將各個項目層層相疊，一開始點選時只會看到主訴和診斷的部分（圖一），而理學檢查的項目構成另一個目錄，如需進一步的資料，點選後可見到體溫、血壓、脈搏等數據。
這樣的呈現方式，不僅可以表達醫生在整個邏輯思考判斷的過程，也使得後來的閱讀者在觀看文件時更加簡潔有效率，而不會迷失在一大堆分不出重要程度的文字中。對醫學教育來說，使用SR的醫學報告也非常適於學生的學習過程，可以加強其醫學推理思考的能力。
2. 與多媒體資料的結合：
多媒體科技可說是二十一世紀最熱門的課題，在醫學的領域中也不例外，SR另一個強
大的威力，就是能夠結合各種醫學多媒體資料（影像、聲音…等），並將其完美的融
合於報告中。
舉例而言，傳統的醫學影像報告是將影像和文字報告分離（圖二、三），這樣的呈現
方式對閱讀報告的人來說，可說是相當的不便，為了找到文字報告中提到的病變部位
，必須要在影像上花費許多時間搜尋。
即使是將影像和文字部分並列於同一螢幕上，對於報告的幫助仍然有限，除非
閱讀報告的人有受過相當的專業訓練，否則還是不容易瞭解報告內容（圖四）。
但是在使用SR之後，整個報告的面貌有了截然不同的改變，因為我們可以將整份
報告分為各個註解部分，在利用註解與影像間的鏈結關係，將註解直接加在影像特
徵的位置上（圖五），這樣一份報告，文字的部分不但簡潔明瞭，也可以傳遞更多
的訊息，對醫學報告品質的提昇非常有幫助。
3.方便的資料檢索與搜尋：
結構化的報告構造，也非常適合用於資料的搜尋，舉例而言，如果有研究者希望
從某醫院近十年的病歷資料中分析吸煙與肺癌間的關係，以傳統的病歷儲存方式來
說，可用的方法只能在龐大的文字中檢索『吸煙』、『肺癌』等相關的字串，這將
是一件非常耗時耗力，而且正確度不高的工作。
而在SR Document中，因為它對資料已做過事先的整理，只要搜尋所有”病史=肺癌”
的病患，再分析他們的吸煙習慣就可以輕鬆正確的得到答案。
4.統一的文件模板：
在以整個醫院的角度來說，利用SR結構化的特性，可以建立一些各科室或Modality
專用的報告格式，醫生在打報告時只要叫出相關的模板，很快就能產生一份圖文並
茂的報告。
三、SR document和DICOM的關係：
在整個DICOM的架構上，SR document IOD的地位和原有的Image IOD完全相等，換句話說，它同樣是掛在Patient、Study、Series、SR Document 這樣的四層構造下。
因此，加入SR的功能完全不會影響到server端的運作，在Query/Retrieve時，與以往的過程完全相同，唯一的差別，是除了Image以外，又另外多了一個SR的部分傳回client端，然後再經由client端解譯並顯示SR document。
四、結語：
在以往的DICOM規格中，應用的範圍都是以醫學影像為出發點，然而，隨著DICOM這幾年成功的發展，目前的走向也逐漸踏出更開闊的角度。以結構化報告為例，不僅其應用範圍可以包含現有RIS和HIS的範疇，而且也是整個醫學領域的重要發展，使用結構化報告可以具有的優勢為：
l靈活的報告呈現方式
l與多媒體資料的結合
l方便的資料檢索與搜尋
l統一的文件模板
在醫學和資訊兩方面發展的推波助瀾下，結構化報告勢必要取代傳統條列式報告而成為醫院使用的報告規格，唯有及早搭上這班通向未來的高速列車，才能使醫院整體的水準不斷提昇，獲得最有利的競爭地位。
DICOM章節簡明介面說明
(1)DICOM Part l對整個標準做了一個簡略的介紹，並解釋整個標準的設計理念、定義使用了哪些物件，以及對其他幾個Part做簡短的說明。
(2)DICOM Part2定義了DICOM中conformance，及conformance究竟作何解釋，以往的儀器雖宣稱標準相容卻發生無法連接情況，因此conformance主要功用就是讓使用者能夠正確的選擇所要購買的機器服務，並確保能夠互相連接。
(3)DICOM Part3中，依照放射醫療環境下的數位影像傳輸定義了一組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的屬性。
(4)DICOM part 4中是服務類別（service class）的規格，服務類別可以想像是IOD 的操作。且在Part 4中SCU（service class user）和SCP（service class provider）所扮演的角色也有明確的定義。
(5)DICOM part 5中定義了一些在ACR/NEMA l.0 & 2.0中所沒有的資料結構以及編碼的方式，為了妥善管理資料內容中可能一再出現的資料元件（data elements，called item）及複雜的資料夾訊息物件（folder information objects），使用可靠的編碼方式以及簡單的資料結構有助於系統的穩定與維護。
(6)所有的資料元件被定義成一連串的元件，稱為串列（sequence），並以一個符號"SQ"來代表。而每個串列的編碼必須遵照DICOM 3.0的格式將其元件編成tag，串列的起始 tag緊跟著是4bytes的元件，若元件的內容不是FFFFFFFF的話表示這個公認的元件；在一串列最後，必定有一個稱為sequence delimiter的元件，元件tag值為(FFFE,EOOD)，value length為0。
(7)DICOM Part 6是整個資料元件（Data Elements）中其數字（numerical names）與文字（text names）間對應的完整列表、資料結構（例如text、floating-point或integer）及元件中是否有包含其他的元件。
(8)DICOM Part 7定義應用程式與DICOM通訊層連接所需要的訊息；典型DICOM訊息包含了命令字串（command stream）及資料字串（data stream），命令字串中所支援的服務項目即Part 4中所定義，而資料字串（或稱為訊息物件，information object）須以Part 5中的編碼方式編碼。在某些特殊的情況之下，命令字串可能會很小或者是根本不存在於訊息當中。也可說，Part 5定義的是資料字串的組成，而Part 7則是命令字串的組成。
(9)DICOM Part 8定義網路上DICOM訊息（DICOM message）的交換，目前所支援的協定為TCP/IP以及ISO-OSI。但這部份在制定過程中，上層服務（upper Layer service）的設計原則必須是具有高度的擴充性，亦即將他種協定納入DICOM必須是十分簡易。
(10)一旦脫離了DICOM的上層服務，剩下來的通訊協定（例如TCP/IP或ISO-OSI）與其原來的標準依舊相同，也就是DICOM的通訊服務是在不修改既有通訊協定之下進行。在ACR/NEMA Version l.0中定義了一高速的平行資料傳輸界面，而若有應用程式連接較為老舊的成像機器時，就必須透過這個界面，因此，為了相容性緣故，在DICOM 3.0 中依然保留了這項設計。
(11)DICOM Part 9中描述了5O-pin點對點連接界面的更新版，因此，製造商可選擇Part 8中的何一種網路協定來實作，或選擇Part 9中的點對點協定，並且能讓同一個應用程式在這兩種情形下都能正常的運作。簡而言之，在Part 9的定義中能夠連接ACR/NEMA l.0 &2.0，但這種連接需一網路界面單元（network interface unit）連接於點對點協定端，而另一端連接於網路協定端。
(12)DICOM Part 10: DICOM物件存入媒體時的檔案目錄及檔案本身的格式。
(13)DICOM Part 11: 定義應用軟體可具備的DICOM File Service存取功能
(14)DICOM Part 12: 說明各種儲存媒體儲存DICOM資料時的格式。
(15)DICOM Part 13: 點對點列印DICOM影像時控制印表機及資料傳輸的格式。
(16)DICOM Part 14: DICOM影像在螢幕顯示以及列印成傳統膠片時顯示的規格。
(17)DICOM Part 15: DICOM資料在網路傳輸時加密的方式，以及利用電子簽章簽認DICOM影像及報告的方式。
(18)DICOM Part 16: 引用DCMR(DICOM Content Mapping Resource)支援，已定義其相關範本與報告使用。
(19)DICOM Part 17: 規範DICOM有關之詞彙說明，以確定資料的統一使用。
(20)DICOM Part 18: 規範如果何透過Web –based 的服務來執行相關的DICOM服務，包含如影像及報告部分。透過HTTP/HTTPs 的標準並使用DICOM UIDs ( Unique Identifiers) 來執行遠端的影像讀取。
DICOM SCP/SCU Testing
透過兩個工具進行 DICOM SCP/SCU 的測試環境，我們選擇DICOM Validation Tools 來扮演 DICOM SCP 的角色，其畫面如下所示，其 AE / IP / Port 皆可以自行設定。
DICOM Validation Tool SCP 的執行請 Click 滑鼠右鍵來進行啟動( Execute )。
DICOM SCU 的AE / IP / Port 設定必須指定為 SCP 的參數方可成功。
DICOM SCU 可傳送一個C-ECHO 來進行測試，其DICOM SCP 如正常收到
C-ECHO 的需求，必須建立通道 ( Association ) 已利後續進行的 C_Move ,
C_Find , C_Get 等 DICOM 的 Command 作業。
下圖為 SCP 的 Log 訊息:
下圖為 SCU 的 Log 訊息:
原文網址
http://imediface.blogspot.tw/2012/01/dicom_15.html
維基解釋
http://zh.wikipedia.org/wiki/DICOM
某學校的教學投影片
wwwold.ctust.edu.tw/mdc/file/DICOM%20Fundamentals.ppt
dicom viewer
1．EZ dicom viewer
http://www.sph.sc.edu/comd/rorden/ezdicom.html
請按我下載EZ dicom viewer
2．Santesoft dicom viewer
http://www.santesoft.com/dicom_viewer_free.html
請按我下載Santesoft Dicom viewer
亞東醫院
DICOM VIEWER軟體連結(adiAntViewer免安裝唷)
文章標籤
全站熱搜
程式語言 (17)
