數字影像傳輸標準協議的初衷，是爲了在不同廠商生產的數字影像設備之間實現影像及其附屬信息的調用。這個標準的最初版本是所謂ACR（美國放射學會）-NEMA（全國電器設備製造商協會）標準，這個標準定義了點對點的連接協議。但是計算機網絡技術的日新月異和PACS（影像傳輸及歸檔系統）的發展，很快就讓這個協議顯得捉襟見肘。其結果是以後的工作目標變成了對ACR-NEMA標準的升級，以使此標準能夠支持複雜網絡系統的信息處理需要。DICOM（醫用數字影像和傳輸）標準應運而生。目前這個標準在數字影像系統的採購和評介過程中，已經得到廣泛的應用。
DICOM標準有很強的適應性。在設計初期，就充分考慮到了DICOM標準對放射以外的影像支持（比如：病理、內窺鏡和牙科影像）。醫療影像設備的製造商往往都是大型跨國企業，他們的對DICOM標準的關注，對此標準的推廣起到推波助瀾的作用。歐洲標準化組織（the Comitâ Europâen de Normalisation）在制定MEDICOM標準時完全基於並且兼容了DICOM標準。在日本，放射設備及醫療信息系統行業協會發展中心已經採用了DICOM標準中可擦寫媒介影像交換標準部分，並且考慮將DIOCM標準納入其未來的醫療影像處理標準。目前，DICOM標準已經在全球範圍內得到不同領域組織的廣泛認同。
在醫療影像通訊領域DICOM標準已經成爲主導標準。然而，儘管DICOM標準在廠商那裏唾手可得、應用廣泛，並且在迅速擴展進入包括非放射影像在內的新領域，仍然有很多放射專家仍然對DICOM認識不足。這種情況出現的部分原因是DICOM的“學習曲線過於陡峭”，現有的DICOM介紹材料不是寫給工程人員的對於放射專家來說太過技術性，就是寫給高層管理人員對於放射專家來說太膚淺了。
爲什麼我們要對這樣一個看上去很簡單的東西大費周章呢？答案是，事情並不想它看上去那麼簡單。通常放射專家都對膠片影像瞭如指掌，膠片影像在任何有光源的地方都可以觀看。當我們把傳統膠片影像轉化爲數字影像的時候需要面對一系列的問題，傳輸、顯示、存儲等等，這時候DICOM的出現就很必要了。在膠片時代，曝光、處理流程和讀片工作中的細微變化對工作影響不大。而在數字影像時代，幾個字節的差異就足以中斷影像在系統之間的傳送。
DICOM標準的組成
DICOM標準由一組文檔組成，現今的版本就包括了13個發行部分。每一個DICOM文檔通過標題和標準編碼來識別，看上去的樣子就像這樣“PS 3.X-YYYY”，其中‘X”就是常說的標號，“YYYY”是發行的年份。舉例來說，DICOM 標準第二部分的標題是“順應性”文件標號是PS3.2-1996. 在正式場合，年份經常被省略。
DICOM通訊
DICOM標準的核心就是設置了一套統一的易於理解的數字影像通訊規則。在本文中，“通訊”是指系統中信息的交換。這個動作聽上去很簡單實際上，通訊就是我們日常生活中的一部分。然而，我們之所以能夠良好的溝通是因爲我們遵循了一套良好的規則。這套規則是我們在孩提時代就掌握了的。
- 通訊協議
電子通訊通常被劃分爲不同的層次，每一個層面上完成相應的功能。這種將通訊標準劃分成不同層面的模型實際上是一個國際通訊標準的一部分，此標準就是ISO-SOI（國際標準組織開發系統互聯）參考模型。這個模型可以類比爲一個生產加工廠的結構。在這個模型的最高層面是用戶應用程序的界面（比如在一個計算機終端上用戶可以通過應用程序跨越網絡訪問數據）。這個層面相當於工廠的決策者他們決定工廠生產什麼樣的產品，運輸什麼樣的貨物。在模型的最低層面是物理層，這個層面爲電子通訊提供物理介質( 比如：線纜)。這個層面相當於運輸部門的貨車。模型中的“高層”和“低層”並不是表示不同層面的重要程度，實際上高低的區別只是因爲不同層面象一個堆棧，物理層在最下面，應用層在最上面。
在最高層和最低層之間，還有其他層面負責解決類似下列問題：用什麼樣的字符集來顯示信息；用什麼樣的規則在物理層上建立連接；如何處理通訊過程中出現的錯誤等等。這些中間層面類似於我們假象工廠中不同的職能部門，每個都承擔着特定的功能（比如：零件選擇、製造裝配、質量控制、規劃運輸路線等等）。在電子通訊模型和假象工廠中發生着同樣的情況，每個層面（部門）從上一個層面（部門）獲得信息，按照預定功能工作，將結果輸出到下一個層面（下游部門）。
任何兩個層面之間的交換都是無往不復的，因爲所有通訊（正如同貨物在不同公司之間的交流）都是雙向的。在通訊術語中，信息在不同層面之間的流動被稱之爲層面提供的服務。然而，通訊意味着信息的交換，因此，還需要對方設備上有相對應的層面並且有物理媒介的連接。
我們的假想工廠加工並且運輸自己的產品到另外一個公司，在那裏經過組裝產生新的產品。後面這個公司並不把產品原封不動地送回到去我們的假想公司（除非他們收到劣質產品要退貨），不過他們要把貨款發送回來。兩個公司的物流部門需要爲雙方貨運制定計劃和規則（比如，不要在在長假期間發運保鮮貨物）。同理，兩個電器設備之間的的通訊也需要事先設定的規則或者協議，這樣設備間相對應通訊層面才能連接。在電子通訊中，兩個設備之間真正的數據流動只存在於物理層。然而，由於建立了機遇層面的通訊模型，每一個層面可以看作和對方設備的對應層面基於已有協議的直接通訊。在提供本層面的服務時，一個層面在所接收到的數據上加入一些信息然後發送給下游層面，下游層面接收到數據後也作相同的工作。在接收端，數據在向上穿行過各個層面的時候，每個層面提取從數據中出自己所需要的信息實現層面功能。在我們的假想公司中，質控部門會在產品的包裝上貼合格標籤再將其送到物流部門發貨，而在收貨的公司，產品接收後會開包驗貨，公司的質控部門會檢查產品的合格標籤並且確認產品沒有任何運輸損壞。只有產品通過檢查後，纔會被髮送到別的部門接受進一步處理，最後財務部門會得到簽收通知安排付款。在上述過程中的協議保證了發貨人在產品上粘貼了正確的質控標籤，而收貨人可以根據發票檢查產品數量和質量。如果過程中有人違反協議（比如發貨人沒有檢查產品，或者忘記了貼標籤），產品將被拒絕接收（收貨人拒絕收貨或者扣留貨物直到問題解決）。
- DICOM通訊協議
電子通訊的層面模型優勢之一是當一個層面被新層面替代時其他層面不受到影響。舉例來說：如果我們能找到一種物理媒介其速度是現有物理媒介的10倍，而且能夠提供現有物理層提供的所有服務，我們就能立刻用新的物理層替換掉現有系統。在我們的假想公司中找到一個新的物流公司，新公司運貨速度提高一倍，使用原有的集裝箱，提供和現有公司一樣的貨物保險，那麼我們可以不對其他部門作任何調整直接轉換到新的物流公司。
不同層面的集合通常被稱爲棧或者協議棧。 DICOM標準使用了層面通訊結構，實際上它並沒有新建一個標準通訊棧而是直接使用了一個已有標準。可能有人會問，如果DICOM僅僅是使用了一個已有的通訊標準，它還有什麼意義？爲什麼不直接用那些現有的通訊協議標準呢？
DICOM標準的意義和其功能的重要性，可以用個假想製造廠之間的交易來解釋。
假想你是產品開發部的經理，現在需要一些零件來組裝一個原形產品。於是你要求你的採購經理貝蒂從埃克美零件公司採購一些零件。貝蒂知道最快捷的辦法就是打電話給埃克美公司訂貨，但同時她也知道你需要的零件非常搶手很可能已經銷售一空。她拿起電話撥號，聽到了熟悉的聲音：“你好，這裏是埃克美公司，請問你要找哪位？”貝蒂回答道：“請轉銷售部鮑勃羅伯茨。”
貝蒂剛纔所做的工作非常類似於一臺設備使用DICOM協議與另外一臺設備通訊。當她拿起電話，她首先要求線路暢通。她聽到的撥號音告訴她線路正常（如果沒有撥號音則說明線路有問題）。同理，DICOM標準通過服務請求與網絡上的另一臺設備通訊。網絡協議會首先探測網絡是否可用。如果可用，DICOM協議就將發起一系列的活動，由此產生一個對另一臺設備的連接。
拿起電話撥入需要接通的號碼然後傾聽迴應，你就遵循了一系列通訊協議。首先，你遵從一定的規則撥號。如果你在辦公室裏撥號，可能還要先撥一個外線號碼，如果對方不在本地，你還要撥對方的區號。然後你聽到對方的振鈴聲，你知道對方沒有佔線，否則你的“協議”會引導你掛上電話等會兒再撥。
電話那一端的人所說的頭兩個字就很有意義。它告訴你兩件重要的事情，首先對方所說的語言是你能夠聽懂的，其次你沒有撥錯號碼。如果你聽到的回答是“Moshi moshi, Fujiyama Denki desu”，你可能會馬上掛斷電話或者尋問對方是不是你要找的人。在這種情況下，會發生某種談判，你會詢問對方的電話號碼，對方也會改說一種你能夠聽懂的語言。你假設對方能夠聽懂你說的話，而對方此時的反應決定了你下一個問題是什麼。
DICOM協議也是用過發起某種談判來建立連接的。這些談判的主要內容是判斷髮起通訊的設備希望完成什麼工作，以及接受設備能夠完成什麼工作。實際上，在DICOM協議中並不是設備本身完成這些談判，而是其上運行的軟件完成這一功能。DIOCM協議作爲設備所支持的一個應用實體而存在，因爲發起建立通訊是應用層（通訊棧中最上面的一個層面）的功能。
- 傳輸語法：VR方法還是字節順序
正如同你在電話中的談判確定了通訊雙方的基礎能力（比如，使用的語言，對方的身份等），DIOCM中的連接建立也需要談判來確定能力。應用實例的連接發起方將希望完成的工作編成一個列表發給對方。而接收方迴應一個能夠完成工作的列表。後續的交流是在兩個列表的交集範圍內進行的。舉個例子，對於大於8位的數字像素值不同系統的處理就不同。有些計算機系統先發送最小有效字節，而有些系統則恰恰相反。如果兩個系統用相反的表示方法傳送數據，將導致錯誤數值出現。解決辦法是設備能夠發現這個問題，並且自動轉換數值。DICOM協議對兩種表示方法都支持，因而在信息交換前的談判中有一個內容就是檢測設備使用哪種方法。
另外一個影像設備之間的差異是對數值的表示方法。正如後面將要詳述的，DICOM標準將所要發送的信息分解爲一系列的數據元素。對於數據元素中所包含的數值，不同的應用程序會有不用的表示方法。DICOM對所支持的數據類型有着非常明確的定義，被稱之爲數值表現方法（VR）。其中包括了不等長混合字符串（像一個句子那樣包含了開頭、結尾和一連串順序字符的文字串）、二進制數據、時間和日期數據以及人員姓名數據等等。在早期的ACR-NEMA標準中，這些VR被定義在所謂數據字典的一組標準中。如果你需要編寫能夠接收ACR-NEMA標準數據的應用程序，爲了解釋接收到的數據，你需要在數據字典查詢ACR-NEMA元素標籤才能瞭解數據元素中包含什麼樣的數據以及如何表示這些數據。DICOM標準需要擴充新的VR標準，未來的進一步擴展將增加數據字典的大小和複雜性。這也就是爲什麼在DICOM標準中同時支持ACR-NEMA方法和在數據元素中定義VR的新方法。 DICOM新定義的方法VR被定義在數據元素中，這樣就不免了可能的混淆。對於軟件設計人員來說，新方法減少了查閱數據字典的負擔。在數據字典中定義VR的ACR-NEMA方法被稱做內部VR；而DICOM所使用的在數據元素中定義VR的方法被稱爲外部VR。DICOM同時支持這兩種方法，在通訊能力談判時知道這一點很重要。
不論是VR方法還是字節順序都是談判信息的一部分，這些信息對成功建立信息交換至關重要。這些信息被稱做傳輸語法，被定義在DICOM標準中。在建立連接的最早期階段，使用何種傳輸語法進行信息交換是主要的談判內容。
貝蒂呼叫埃克美公司銷售部鮑勃的電話叫通了，雙方寒暄幾句後，鮑勃問貝蒂需要什麼幫助。貝蒂說：“我需要15個零件”。鮑勃查了一下庫存量回答說：“沒錯，我們正好有庫存。”他接着說：“你知道，貝蒂，我們剛剛發佈了馬克二型零件，它的價格和馬克一型一樣速度提高了10% 。” 貝蒂問道：“新零件的界面怎麼樣？”“馬克二型向前兼容馬克一型，一旦清空馬克一型的庫存，我們將停止銷售老產品。”貝蒂說：“聽上去不錯，這樣我定15個馬克二型的零件。”
這次交易簡捷高效，主要是因爲雙方都對流程非常熟悉。假如貝蒂不認識銷售部的鮑勃，她也會和銷售部的其他人員要求相同的東西。
在上述場景中發生的事情，也發生在我們每天的日常生活中。這些交易如此頻繁以至於除非出了什麼茬子，否則很少有人會注意到它們的存在。在這個例子中不論是術語的定義還是工作的模式都是你、貝蒂和鮑勃所熟知的。現實生活中的溝通交流就是這個樣子：我們基於人所共知的術語詞彙和交流模式，一旦出現我們不熟悉的詞彙或者交流模式，我們或者停下來明確它們的準確定義或者冒着出問題的風險繼續交流下去。在這個例子中你（產品開發經理）要求購買一打零件，但是貝蒂（工程採購經理）定購了15個。因爲貝蒂根據和你共事的歷史經驗數據判斷，你總是忘記需要爲安全性測試多定購幾個零件。由於貝蒂對你所設計的原形設備有一定了解，所以在定購馬克二型零件的時候會確認界面一致性。同時她知道提高零件的運行速度對你的設計有利，沒有理由不定購新型零件。在這個場景中還存在更高層次的考量。有的工程是可能對使用新型號持保留意見，因爲新型號通常不象久經使用的老型號那樣穩定。然而，在這個場景中，你和貝蒂都對埃克美公司的質控體系有信心，知道新老產品在可靠性方面的差距可以忽略不計。
DICOM定義了什麼
DICOM標準的最重要的意義就是儘可能明確地定義影像傳輸過程中涉及到的術語詞彙和模型。並且保證接收此協議的用戶能夠方便使用這些定義。在比較高層面的通訊中（比如用戶之間的通訊) ,對術語詞彙的認同非常重要。不論實在放射科內部還是在放射科與其他學科交流中，明確地術語定義是保證溝通準確的前提。舉例來說，對於“中間”和“側面”的不準確理解，對於一個基於放射科報告作出診斷的外科醫生來說會直接導致災難性的後果。美國病理學協會已經在“系統化醫療術語”（SNOMED）標準上作了一些工作。這個也被稱爲受控詞彙表的術語標準是基於解剖學和病理應用的。現在美國病理學會是DICOM標準委員會成員，並且正在致力於開發一個新的SNOMD章節用於影像描述。這個章節也被稱作SNOMED-DICOM 詞彙表。
DICOM同時也採用了其他一些適用標準的常規定義，比如說HL7 標準中的人員姓名格式。在這個格式定義中描述了姓名的表現格式以及稱呼中前綴（比如：Mr. Fr.) 以及後綴（比如：Jr ) 的使用。格式定義中將姓名劃分成幾個部分，比如姓氏，名字，前綴等等，同時每個部分還可能是單個或者多個單元以應對一些不常見的姓名結構。
DIOCM標準的定義範圍已經超越了術語詞彙、測量值和環境變量等範圍。它還定義了實體之間的關係模型。舉例來說，一個患者和一個他所做過的檢查之間的關係。這個例子中兩者之間的關係可以用一個簡單的字來描述“做過“。一個患者做過一個檢查。同理類推，一個檢查包含一系列影像。通過對臨牀活動的研究，流程也可以被定義爲標準模型，在這個模型中定義了一組實體（比如：患者、檢查、影像、報告）以及實體之間的關係。這個流程稱爲實體關係模型（E-R）。值得注意的是實體關係模型通常是一個圖表，並不描述具體數據的流動方向。
在E-R模型中每一個實體都有其描述或者屬性。例如，患者這個實體可以用下列屬性來描述：姓名、年齡、性別、病案號、身高體重等等。所有這些屬性可以用來標誌或者描述一個特定的患者。DICOM標準不但定義了E-R模型，而且定義到了模型中每個實體的具體屬性。實際上，DICOM中使用的屬性就是ACR-NEMA標準中的數據元素。
定義E-R模型和模型中實體屬性的過程式信息分析和建模工作的重要內容。這個分析和建模過程就是面向對象的分析。這項技術與現代計算機科學緊密相關，目前不使用面向對象分析方法的信息科學幾乎是不可能的。建立E-R模型的部分目的就是得到一個面向對象的結果：實體就是對象，用屬性來描述對象。
- 信息對象
DICOM 的設計邏輯中部分地採用了面向對象方法。類似影像、報告
患者這樣的實體在DICOM中被稱爲信息對象，因爲它們的功能就在於承載信息。對於信息對象構成的定義在DICOM中被稱爲信息對象定義。信息對象定義的實質就是一個屬性列表，這些屬性分成必要屬性，可選屬性和條件屬性（這種屬性在某些條件下是必需的）。在描述信息對象細微的差別都有重大的意義。信息對象定義類似於一張包含很多空白字段的表格。象患者姓名、病案號這樣的信息片斷都可以當作一個屬性。即使一個空白表格，也代表了一定的信息結構意義。當表格中的空白被填滿，屬性被賦予數值，對象就有了具體的實際意義它可能代表一個患者，一幅影像或者其他什麼對象。這個填表的過程，也就是爲屬性分配數值的過程就是所謂的創建信息對象實例。
在ACR-NEMA標準的第一和第二版本中並沒有使用面向對象的分析和設計思路。相反地，所有的屬性（這裏叫做數據元素）按照用途分組。舉例來說，描述患者身份的元素分爲一組，而描述檢查影像獲取方法的元素分爲另外一組。因爲這些版本沒有依照E-R模型開發，所以這些分組也不符合面向對象定義的原則。舉例來說，在ACR-NEMA第二版中關於CT檢查影像的描述元素中也包含了患者姓名。按照E-R模型，患者姓名應當是患者對象的一個屬性，而不屬於影像對象。換句話說，即使CT影像需要使用患者姓名來做標誌，患者姓名也不是CT影像的必要描述內容。這些複雜對象可以看作是由E-R模型中多個實體組成的集合。
產生這些問題的原因在於DICOM標準開發者（當時還是ACR 和NEMA）仍然希望保持新標準對老版本的兼容性。另外一個原因是，當時的計算機技術人員認爲對象應當有具體的數值，而不是離經叛道地讓對象包含一些屬性。首先，從存儲設備中調用複雜對象會更有效率，因爲如果對象被拆分爲更細小的元素，那麼在調用的時候需要在存儲中搜索更多更小的元素，耗費更多的時間。因此，DICOM標準繼承了所謂的複雜數據及結構，稱之爲複合對象。遵從面向對象設計原則，DICOM標準E-R模型定義的新對象並不包含除子對象屬性外的任何新屬性。這些DICOM定義的新對象叫做規範化對象。影像對象（比如CT，超聲和MRI的影像）都是複合對象，用於影像及其報告管理的對象是規範化對象。
現在回到我們的假想公司，記得嗎你是公司的產品開發經理，爲建立準確有效的質量控制流程你需要對組裝到產品中的每一個零件追蹤。這樣的話，不論是你自己的實驗室還是你的客戶，一旦發現產品有問題，你就可以追蹤到產品中哪個部分的設計或者加工有缺陷。支持這個流程，首先需要你對產品中的零部件型號編號。但是僅僅這樣還不足以讓你能夠定位出加工製造的缺陷源頭。換句話說，型號編號可以在一個產品線中標誌唯一零件，但是不能在多個產品批次中找到唯一零件。舉例來說，貝蒂訂購的零件型號編號是2011030-001。但是你所有生產的產品中都有這幾個編號的零件。所以要定位到特定的某個零件你還需要一個唯一編碼（UID）。如果你發現埃克美公司給每個出品零件都分配了序列號，你就可以使用這個編號來描述特定產品中的特定零件。只有一個產品可能安裝了型號爲2011030-001序列號爲97-2003的零件，凡是有埃克美公司零件的售後服務就簡單多了。
正如同某些工業品標誌有唯一識別號碼一樣，包括影像、報告及其他一些由一臺影像設備傳輸到另外一臺設備的信息都需要唯一識別號碼。DICOM定義了UID來起到這個作用。UID的格式遵從國際標準，當正確使用時，這個識別碼不但在一個機構內是唯一的而且應當在全球範圍內是唯一的。UID號碼大多是由計算機軟件生成的，其結果是號碼看上去晦澀難懂。在DICOM標準中任何時候一個對象指向另外一個對象時都要使用UID。舉例來說，我們前面提到的不同的傳輸語法就有不同的UID，這樣當設備通訊時可以利用UID來指向某個特定的語法規則。作爲國際標註組織的一部分，DICOM委員會負責申請並獲得了一個特定的數字字段用來定義DICOM的UID。這個數字字段被稱爲組織根字段。DIOCM組織獲得的字段是1.2.840.10008。在這個根字段上可以附加數字作爲標誌碼。比如說，UID 1.2.840.10008.1.2.1 就表示了DICOM協議衆某個特定的語法。組織根字段根據UID由廠商發放還是由用戶發放而略有不同。在這些數字中間出現的符號看上去似乎把數字分成了幾個有特定意義的字段，但實際上它們並沒有什麼意義。UID僅僅給特定對象一個唯一標識，並不附帶關於被標識對象的任何信息。
- 服務類
DICOM標準中的信息對象是用來在不同的硬件設備之間傳送影像及相關信息的。不過，僅有這些信息不足以保證操作流程的正常進行。當貝蒂給埃克美公司打電話之後，不僅是告訴對方自己需要什麼，而且還引發了一系列的活動。貝蒂說她需要訂購15個零件。下這個訂單會引發下列動作：埃克美公司的倉庫會完成分揀工作，並將貨物發送給運輸部門，運輸部打包後裝車發貨。在此過程中，需要填寫相應得紙質或者電子表格來跟蹤流程，記錄庫存變化。從功能上來說，訂單的信息交流引發了埃克美公司不同部門提供的不同服務。同樣，當這批零件到達你的公司時，也會引發公司中不同部門的不同服務。因此，在信息交換之外（例如說：“我將預定15個零件”“我們已經用型號二代替了型號一”），還需要一些與信息相關的服務來最終滿足公司的要求。
醫療影像信息的通訊也有類似的情況。在與設備通訊的同時，你還需要設備能夠提供一些服務（比如，顯示器能夠顯示影像，打印機能夠打印，歸檔設備能夠存儲）。我們前面提到的談判過程，就是設備聲明其能夠提供服務類型的方法。
DICOM爲其所定義的信息對象制定了標準化的服務類型。這些服務是基於一組數據元素服務而建立的。因爲DICOM的信息對象包括複合對象和規範化對象兩種，相應的服務也分爲複合服務和規範化服務。所有服務都是通過一組數據元素服務來實現的。在我們的例子中，填寫訂單這個服務實際上就是由一組簡單的動作組成的。首先是接線員接聽電話，然後轉接到銷售部門，銷售人員根據電話提示書寫訂單後將複印件發送到付款部門。這樣一組小的活動，組成了填寫訂單這個服務。同理，DIOCM也將其複雜的服務分解成一些小的服務元素，稱之爲DICOM消息服務元素，簡稱DIMSE。對於複合信息對象定義了五種DIMSE（叫做DIMSE-C），對於規範化信息對象定義了六種DIMSE（叫做DIMSE-N）。所有這些DIMSE可以分爲兩類：操作（比如“存儲”可以把信息寫入存儲設備）；通知（比如“事件報告”用來通知設備有事情發生）。這些簡單的DIMSE構成了影像歸檔和通訊系統中所需的服務。這些服務包括“歸檔”（用來將信息對象寫入歸檔設備）和“查詢-調閱”（用來在存儲設備上提供信息查詢和調用功能）。某些服務要求DIMSE成對出現才能正常工作（比如“發送存儲”和“接受存儲”，另一些服務則需要多個DIMSE才能實現（比如：查詢-調閱）。在“查詢-調閱“服務中使用了“find”“get” 和 “ move” 三個DIMSE。
由於DICOM的面向對象特性，服務通常被稱爲服務類。這樣稱呼的部分原因是對於某個制定的服務，可以被多個（或者多類）信息對象所使用。瞭解一臺設備到底是服務的提供這還是服務的使用者非常重要。舉例來說：工作站中的文件系統可以提供影像存儲服務，而超聲機利用工作站的存儲服務來存儲和最終顯示影像。DICOM標準用服務角色來描述這個差別。設備可以是服務的提供方，或者是服務的使用方，也可以兩者都是。毫無疑問，如果一個系統中的各個設備能夠正常通訊，明確各自的角色就是前提。這一點需要在我們前面提到的談判過程中明確，換句話說，在功能列表中不但要明確能夠支持什麼樣的服務類，而且要明確對應服務類的角色。
信息對象和服務類是DICOM標準中兩個最基礎的部件。在首先理解了這些部件之後纔有可能理解DIOCM的功能和用途。信息對象定義了醫療影像的核心內容，而服務類定義了這些內容能做什麼事情。
- 服務對象對（SOP）
服務類和信息對象結合成爲DICOM標準中的基本單元，這個單元叫做服務對象對（service-object pair) 簡稱 SOP。既然DICOM是個面向對象的標準，SOP實際上被稱爲SOP類。SOP類是DICOM的最基礎單元，DICOM中任何功能的實現都是基於對SOP類的使用。
服務和信息對象的結合簡單直接。舉例來說，DICOM定義了一系列的存儲SOP類（比如，CT影像存儲 SOP類，MR 影像存儲SOP類）。CT影像存儲SOP類是由CT信息對象定義和存儲服務類組成和，其他存儲SOP類也是用類似的方法組成的。因爲SOP類是一種描述DICOM功能的方法，所以它也有自己的UID。而且一旦信息對象的屬性被賦值，服務類的變量被確定，SOP被實例化時它就有了自己的UID。
在DICOM通訊過程中，通過DICOM消息傳遞，SOP實例可以被交換。DICOM消息可以傳輸SOP類的版本，消息中包含特定服務的提供方或者使用方命令，同時還包括創建相應信息對象的數據集。
順應性
對於任何標準來說順應性的確定都是頭等大事。在許多涉及好公衆安全和健康的領域內，對標準的順應性是法律強制的。而其他一些標準，DIOCM也在此列，僅僅是自願的。DICOM標準委員會並沒有任何強制性權威。不過即便如此，DICOM標準中專門有一個章節是關於順應性問題的。任何人在宣稱其設備和軟件順應DICOM標準的時候，都必須提供順應性說明文件，在這個文件詳細敘述了其設備或者軟件如何符合標準。關於DICOM標準的一個常見問題是：既然這是個標準爲什麼還需要順應性說明文件？簡單地公佈符合標準不就可以了嗎？象前面曾經講過的那樣，DICOM標準支持許多不同的影像格式，傳輸語法，服務角色等等。爲支持多樣的醫療影像應用程序，DICOM標準必須保持其柔性，但同時帶來的問題就是對於某一個特殊的運用必須瞭解其具體處理的細節。而順應性說明文件就是來做這個工作的。
範例
讓我們用一個使用實例來總結前面的理論。假設現在我們要把一個CT檢查影像從CT設備上發送到一個工作站，來看看在DICOM中如果如何實現這個操作。你或者操作設備的放射科技師需要設置CT設備上的軟件來準備選擇特定的檢查來發送。設備會要求你明確具體要哪臺工作站接收圖像。這個操作實在醫療影像應用層完成的，基本不涉及到DICOM。但是，設備控制檯需要以DICOM格式保存其影像，也就是說控制檯對設備產生的影像生成了一個DIOCM CT信息對象。生成信息對象的過程就是一連串的賦值過程，有一些值需要在控制檯輸入（比如：患者姓名，醫囑編號），還有一些值是設備產生的（比如：檢查日期，時間，醫院名稱，設備名稱等等）。當檢查發送之前，還需要知道工作站的具體名稱的網絡地址。
工作站的CT設備之間的物理連接問題通過通訊協議（通常是TCP/IP協議）來處理。當選擇發送功能時， CT控制檯的軟件開始組裝一系列SOP實例，具體說就是CT存儲SOP實例。在這個例子中，每發送一幅圖像就要創建一個實例。一旦的得到工作站的位置信息，DICOM軟件就開始建立網絡連接，開始通訊過程。網絡通訊協議首先建立通訊通道，以保證後續操作的進行。在建立連接的過程中，CT設備首先聲明自己的通訊語法，告訴工作站：這是一臺以服務類用戶身份支持CT存儲服務類的設備，要求對方的應用程序以服務類提供者身份支持CE存儲服務類。CT設備同時還聲明自己默認支持的VR類型。工作站發送的迴應包括：聲明自己即可以以服務提供者身份也可以以服務使用者身份支持CT影像服務類。同時工作站還聲明自的通訊語法與CT設備的默認語法一致。這樣，一個關於建立連接和服務能力確認的通知就發回了對應的設備端。
本文來自: HC3i數字醫療論壇