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) 來執行遠端的影像讀取。