ＤＩＣＯＭ 簡介

ＤＩＣＯＭ 簡介

( Digital Imaging and COmmunications in Medicine )

商之器

A. DICOM 是什麼？

 

在現代化社會進步的過程中，醫療服務的水準是一項非常重要的指標，在物質生活的提昇後，維護人們健康的難度也隨之增加，相對而言，社會大眾也會更進一步要求更迅速、更簡單、無痛苦的醫療技術。然而，醫療服務可說是一個科學研究應用的終極目標，故醫療水準的提昇並非只是一個狹隘的單方向發展。隨著醫學技術的日新月異，各種不同領域的科技漸漸進入醫院的大門，同時也在這多樣化新觀念的激盪下，發展出一個接一個的革命性演進。在這其中最具代表性，也是目前發展速度最驚人的，當屬結合了時下熱門的網路、通訊、電腦和醫療的‘DICOM’。

雖然DICOM的威力是如此的驚人，但以目前國內醫療院所而言，所謂DICOM云云，往往尚停留在鏡花水月的階段，若想深入了解DICOM，又缺乏正確充足的訊息資源，就算找到得來不易的資源，也往往被龐雜艱澀的技術資料給嚇退。為了解決這些困難，並為提昇國內醫療水準盡一份心力，基於我們多年對DICOM規格的鑽研，及技術上的領先地位，以下我們將利用短短的時間將DICOM的重要觀念及菁華介紹給各位。

要了解DICOM是什麼，首先讓我們先看一下它的英文縮寫 DICOM = Digital Imaging and COmmunications in Medicine。由字面上來解釋，第一，DICOM的發展背景完全是針對醫學應用領域來開發的；第二，適用對象是數位化的醫學影像，所謂數位化的醫學影像，是可以擷取並顯示在電腦中的影像；第三，也就是整個DICOM規格的核心，是在於『通訊』這個觀念上，將這些東西綜合起來，我們可以簡單的將DICOM定義為「醫學影像儀器和軟體間共通的通訊規格」。

這樣子說也許還不能清楚的表達DICOM的能力所在，讓我們簡單的舉一個例子，DICOM其實就是儀器和電腦用的共同語言。像我們出國時，不管遇到什麼國家的人，最先都會以英文來嘗試和他溝通，在醫院整體的環境中也是如此，各種不同廠牌的儀器和軟體就如一個小國家般擁有自己的語言，但一旦需要和其他儀器溝通時就會遇到語言障礙，而DICOM的發展正是希望能跨越此一鴻溝。換言之，只要儀器或軟體符合此規格，彼此之間就能以相同的語言溝通，建構一個無國界、無障礙的電腦化醫學影像環境。

 

B. DICOM 的應用範圍在哪裏？

 

在對DICOM規格有一個初步的了解之後，再讓我們將視野拉大，以整個醫院體系的角度來看看DICOM的定位。正如方才所提到的，DICOM的應用對象是針對各種數位化的醫學影像，所謂醫學數位影像，用白話一點來說，就是電腦可以看到的影像，如：電腦斷層影像(CT)、核磁共振影像(MR)。這些影像的特性，就是沒有底片，整個攝影、計算和成像的過程皆在電腦中完成，如果要觀察影像時，也可以直接由電腦螢幕上看到。相對來說，傳統的醫學影像則是以底片為基礎，如X光影像就是最好的例子，在攝影完成後，尚須經過沖片的過程才將肉眼可見的影像呈現在底片上供醫師觀察。

如此說來，一般的傳統醫學影像是否就不能借助DICOM的威力呢？答案當然不是。在今日電腦技術的進步之下，只要在這些傳統醫學影像儀器的後端加裝一些轉換的裝置，如：掃描器或影像擷取器等，就可以很輕易地將傳統影像送入電腦環境中，也就是一般所謂『數位化』的動作，如此當然可以將這些傳統影像也一併納入DICOM的範疇中。

綜合以上所述，只要有醫學影像的地方，就適用DICOM。以功能性上來說，若我們分析一張醫學影像的生命週期，其中包含了擷取、成像、壓縮、儲存和調閱等各方面的流程，而這所有的流程都可以在DICOM的大環境下流暢而沒有阻滯的運作。

再讓我們以更實際的角度，來看看DICOM可以應用於醫院架構上的哪些科室部門。不可諱言的，大多數人只要一想到醫學影像，就會和放射科畫上等號，那麼說來，DICOM是否就只是一個放射科內部的電腦系統，和醫院其他部分毫無關聯呢？

這個問題要分成幾個層次來回答，首先要再次強調的，只要有醫學影像的地方，就適用DICOM。所以，如果我們將眼光放窄，只專注於醫學影像的擷取上，而醫院大部分的影像儀器都在放射科的範疇下，當然我們會把DICOM的使用侷限在單一的放射科應用層面；但是，仔細想想，醫學影像是輔助醫療診斷的重要參考工具，在不同的科室中，如圖中所列出的腸胃科、婦產科、內科和心臟科...等等，同樣也要仰賴各種醫學影像儀器，所以DICOM同樣也可以在此發揮其強大的威力；再以一個更宏觀的視野來說，如果我們把影像的調閱也納入DICOM環境，同時結合醫院原有的文字病歷系統(HIS)，那麼醫學報告的呈現將不再是一成不變的白底黑字，而可以隨醫師的需求擷取病患各種影像資料以作為觀察診斷的依據。如此，我們就可以將 DICOM推向院內包含診間、病房、急診室或手術房...等各個角落；或者，我們也可以將 DICOM 推廣到醫院對外的應用方面，與目前發展蓬勃的網際網路做一結合，不管是在教育訓練或學術研究上，都能提供莫大的幫助。如此的發展潛力將具有無限的可能，端視管理者和設計者的想像力，而研發出各種不同的應用模式。

 

C. 為什麼要用 DICOM？

 

由以上的介紹，我們可以簡單的歸納，在DICOM最初設計的考量上，確實是以醫院的放射科為出發點考量。然而，隨著DICOM的順利推展，同時醫療與資訊的結合也日漸緊密，DICOM目前的演化方向不只著眼在任何單一科室上，而是提升整個醫院影像管理的資訊化為最高宗旨。

因此，以醫院管理的角度來說，參照歐美各國推行醫學影像資訊化的過程，若能夠由上而下，在整體醫療院所建構一DICOM化的大環境，再依據各部門的需求建構不同特色子系統以適應各科醫師喜好。如此作法在未來醫院擴充或添置新儀器時，將有一簡單的統一規格可循，真正能做到隨插即用的理想，不僅可以節省許多人力物力成本，也能有效提昇醫院形象及層級，為最有效率的解決之道。

另一種管道，則是以需求為導向，視各科室的需求個別建立獨立資訊系統。在此種架構下，DICOM更是獨一無二的選擇，否則在未來發展或各獨立系統相互連接時，將面臨嚴重的不相容危機。

而且，以病患的角度而言，DICOM架構的醫院環境可以大幅縮短病患候診時間。以往可能需造訪醫院數次才能完成就診、攝影和報告這幾個過程，現在只要看診一次就可全部完成，對現代化工商業社會一切講求速度、效率的價值觀而言，這將是多大的誘因。

在醫師方面，DICOM系統可以將看診時間縮短，使醫師有更多時間進修或研究，同時也可輕易擷取DICOM資料庫上各種數位化的影像資料，以作為統計或研究的參考。

因此，我們可以簡單的作出結論，二十一世紀將是DICOM的世紀。在醫療的範疇中，沒有DICOM就會失去競爭的優勢。DICOM與非DICOM的關係，就像槍與劍的對比，結果不言可喻。

 

D.  設計 DICOM 的是誰？

 

提了這麼多關於DICOM種種，究竟這個遊戲規則是由哪些人制定出來的呢？讓我們小小的回顧一下歷史。在1982年時，有鑑於各種醫療影像儀器間的訊息無法傳遞，American College of Radiology (ACR) 和National Electrical Manufacturers Association (NEMA)這兩個組織決定共同成立一個委員會稱為ACR-NEMA，並致力於制定影像儀器間共通的通訊規格。後來陸續在1985及1988年發表了兩套規格（ACR-NEMA 1.0, ACR-NEMA 2.0），但因為技術上的不成熟，這兩套規格並沒有被廣泛的應用。然而，這許多年的努力已經吸引了許多儀器製造商加入ACR-NEMA的行列，終於在1993年發表了一套革命性的協定，並正式定名為DICOM 3.0。這套規格在發表後立即被許多儀器及軟體廠商採用，同時隨著醫療及資訊科技兩方面的進展，DICOM也納入了各方面的頂尖人才，成立了十數個工作群，從不同的專業角度一再添加擴張DICOM的範疇與深度，慢慢演變為今日如此成功的局面。

以地區性而言，雖然DICOM是在美國發展的，但它已被歐洲、日本等地正式接受並列入國家規範。而在台灣地區的發展現況上，中央標準局也已承認DICOM為醫療影像資訊交換的唯一標準，使國內醫療服務水平也能跟上國際水準。

但以使用者的角度來說，仍有許多應用上的困難需要克服。其一乃是語言文字上問題，雖然同樣是符合DICOM規格的系統，若在介面和資料庫方面不能完全的中文化，輕則會造成使用上嚴重的困擾，重則會造成資料無法使用；其二則是因DICOM目前尚有不斷的持續發展，由於科技發展日新月異，今天的突破到了明天可能就是落伍，故一套有效的DICOM系統仍需不斷的修改發展才跟的上時代的腳步。

 

E. DICOM 的工作原理為何？

DICOM資料結構：

要了解一個人，就要試著以他的角度來看事情；同樣的，要了解DICOM的工作原理，就要先來看看DICOM眼中的世界。就像我們前面所提到的，DICOM的一切觀念都環繞著醫學影像這個核心，所以我們要思考的，就是一個醫學影像如何產生。假設一個病患到醫院來就診，為了判斷她的病灶，醫師需要指定各種不同的檢查（比如說有CT和MR兩項），每一個檢查項目都需要一個相對應的儀器來完成，但影像儀器所產生的往往不是單張而是一系列的影像（假設CT產生一組8張，MR產生兩組各8、10張影像），那麼這些影像要如何和這位病患產生關聯呢？

在DICOM規格中，使用了一個非常簡單的模式來描述上面的狀況。純粹以資料結構的角度來看，我們訂出Patient、Study、Series、Image四個層級來儲存上述的例子。Patient中包含了這位病患的所有基本資料（姓名、身分證字號...等）和醫師指定的兩組Study，這兩組Study則分別囊括了CT和MR檢查相關的資料（檢查日期、檢查項目...等），依此類推，CT、MR 的 Study 下分別又有Series儲存同一序列的影像Image，當醫師需要調閱影像時，只要輸入病患相關資料，就能依據這一連串的資料結構找到病患所做過的檢查，及其中包含的所有醫學影像。

1.    DICOM影像物件 (IOD)：

介紹完了DICOM資料的鏈結方式之後，再讓我們來看一下整個架構的核心，也就是醫學影像的儲存方式。在這個課題上，DICOM引入了近年來資訊科技的熱門趨勢－『物件導向』的觀念。傳統的資訊系統在處理影像資料時，完全只專注於資料本身的排列方式。而DICOM則不同，它將每個影像包裹成一個物件 IOD (Information Object Definition)，每個IOD可分為兩大部分：像素資料(pixel data)、影像屬性(attribute)。所謂像素資料就和傳統方法一般，單純描述每一個圖像點的值，組合成一個影像；而影像屬性的部分，則包括了上面提到的資料結構中摘要的資訊，如：病患姓名、病歷號碼、檢查項目和日期...等，一方面方便資料庫在搜尋資料的過程，另一方面可以將這些資訊轉換為影像的一部份，在日後調閱影像時提供重要參考。

2.    DICOM SOP (Service-Object Pair)：

在DICOM開發之初，便將其應用範圍訂在網路的溝通上，對這樣一個致力於通訊規格化的協定而言，只單純定義資料的儲存方式就像是只有一具軀殼般，當然不能滿足軟體設計的需求，所以必須要再加上功能性的定義。所謂功能性的定義，講得簡單一些，就是軟體和軟體間在DICOM這個大環境下可以被允許作哪些動作。舉例來說，與影像相關的動作，包括Verification、Storage和Query/Retrieve等，就必須和影像型態相結合（MR、CT、US、SC...等） ，組成一個SOP class (Service- Object Pair)，這樣一個兼具了軀殼和靈魂的組合才構成了DICOM最基本的運作單元。再舉個簡單的例子，如果某個軟體支援CT image Storage SOP class，那就表示它可以儲存電腦斷層的影像；反之亦然，若是一部Ultrasound的儀器要符合DICOM規格，就要能支援US image Storage SOP class。

3.    SCU/SCP (Service Class User/Provider)：

在進入到SCU/SCP的介紹之前，我們要先介紹一下Client/Server的架構。隨著近年網際網路的快速發展，相信大家對於這兩個名詞應該是耳熟能詳，但是卻不見得真的了解其中的涵義。舉個生活中常見的例子，傳統的非Client/Server架構，取用資料和提供資料雙方完全以‘一對一型式’溝通，就像是推銷員或直銷的方式，所有的動作都必須是面對面才能完成。而在Client/Server的系統中，電腦可以依據它所執行的功能區分為兩大類。提供資訊的一方稱為Server，作用則如便利商店一般，所有的資料（商品）都是開放式的，擷取資料的一方則像是上門的顧客(Client)。如此一來，Server不僅可以允許多個顧客同時瀏覽所需要的資料，大大增加資料搜尋的效率，另一方面，也能因應不同的需求使用不同等級的硬體，降低網路建構的成本。因為這諸多好處，目前網路常見的各種服務，如：WWW、ICQ、FTP...等，一律都是使用Client/Server的架構。

同樣的，在DICOM規格中，也採用了 Client / Server 這種概念。所謂的SCP (Service Class Provider)是負責提供對於影像資料的各種服務，扮演的是Server的角色；而SCU (Service Class User)則是使用這些服務的一方，也就相當於Client的地位。

舉一個實際的例子。假設A方是一部醫學影像儀器，在完成一次檢查後，必須將影像X送到影像伺服器B方，則其簡單的作業流程如下：

i.                  A儀器將影像X包裹成DICOM IOD，再加上所需的Storage Service部分封裝為網路訊息(message)，經過網路向B伺服器發出請求－「請將影像X存於你的系統上」。

ii.                 B伺服器收到訊息後，解開封包，先判讀命令的部分，再將影像X讀出，並且把它存入硬碟中。

iii.               B伺服器完成儲存動作後，必須發出一個回應的訊息，告訴A方動作已經順利完成，A方收到訊息後，才算完成整個通訊流程。

在這個範例中，B電腦是負責執行整個儲存動作的一方，也就被稱為SCP；反之，A儀器的動作是發出要求並等待回應，當然就是扮演SCU的角色。

然而，SCU/SCP的角色關係，並不只是如上述的那樣簡單而已，在較為複雜的系統下，同一個軟體往往需要兼顧兩者的地位。延續上述的例子，假設A方要把原本存在B系統中的影像X複製一份到C系統中，作業流程如下：

i.                  A儀器向B系統發出要求──「請將影像X存到C系統」。

ii.                 B伺服器收到訊息後，解開封包，先判讀命令的部分。發現必須要連接到另一個系統，所以將影像X包裝產生一個新的Storage SCU，發出要求給C系統－「請將影像X存於你的系統上」。

iii.               C伺服器收到訊息後，判讀命令的部分，再將影像X它存入硬碟中。

iv.               C伺服器完成儲存動作後，發出一個回應的訊息，B方收到訊息後，先結束B-C間的通訊。

v.                B系統發出一個回應的訊息，告訴A方動作已經順利完成，A方收到訊息後，才算完成整個通訊流程。

在這裡我們可以清楚地看到，為了簡化資料傳遞的流程，原本A,B,C三方通訊的動作被分成了A-B和B-C兩組，兩兩間仍然具有SCU/SCP的相對關係，而負責中介的B系統，就必須同時具有擔任SCU和SCP的能力。

 

通訊起始設定：

如果我們以一個更審慎而精密的眼光來看上面所提到的兩個例子，應該可以發現很多的問題。譬如說：B系統要怎麼解開A系統傳送來的封包、如果B系統根本就不支援影像X的型態該怎麼辦...？答案其實很簡單，方才因為解說上的方便，我們省略了DICOM規格中一個重要的部分，也就是通訊起始設定的部分。

所謂的通訊起始設定，其實是一個很簡單的概念，在我們平時的生活經驗中，常常不自覺的就會用到它，譬如兩個不認識的人在通電話時，一定會先以「喂」、「喂，請問您找哪位」、「我要找XXX」這類的對話來作開場白。兩個不同的電腦系統在正式開始溝通前，同樣要有類似的訊息交換，才能確定彼此的語言相通。如上面所說， DICOM整體的範疇可說是非常的大，所以目前尚沒有一個系統可以支援所有的DICOM規格，換言之，每個儀器或軟體廠商都只是針對他們最需要的部分來提供支援。在這樣的狀況下，兩個不同的系統間要如何從這龐大的DICOM規格中挑出一條兩者都能接受的溝通管道，就必須經過起始訊息的交換來完成。同樣利用上述的例子來說明，假設A系統想要嘗試以DICOM語言和B系統通訊，則它必須要發出一個起始的訊息，其中包含幾個部分：

i.                  A系統本身支援的SOP型態有哪些。

ii.                 針對每個支援的SOP，A系統必須要列舉它是如何編碼（壓縮）這些資料(Transfer Syntax)。

iii.               對SCU/SCP的相對關係而言，A系統可以扮演什麼樣的角色。

iv.               其他必要的訊息。

B系統收到起始訊息後，就已經掌握了A系統到底能支援DICOM的哪些部分。將這些資料和B系統本身支援的部分做一對照之後，很輕易就能整理出兩系統共通的SOP和Transfer Syntax。再將這些所有對應的部分包裝成一個訊息回應給A系統，以後兩者間只能根據相通的部分來進行訊息交換，這樣就算是完成了一個起始的動作。

1.    DICOM網路架構：

結束軟體與軟體間抽象的介紹後，讓我們更進一步來看看實際上的DICOM網路是如何搭建起來的。以傳統網路學說ISO/OSI中的七層架構來講，DICOM協定是位在最高三層(ACSE, Presentation, Session Kernel)，底層的部分則是符合TCP/IP架構。換言之，在辨識兩台連接於網路端點的電腦時，DICOM同樣是利用IP address(xxx.xxx.xxx.xxx)的方式，而Server在架設時也可以掛在任一台電腦的port上(一般為104)。再換句話說，DICOM的網路架構和現存的網際網路其實絕對相容，在架設時可以保留原有的結構，也完全不會干擾到其他網路服務，如：WWW、FTP或Mail等。唯一的不同，是在所有支援DICOM的軟體系統上，都必須有一組獨立的Application Entity Title和ID以供辨識。

依此類推，網路最底層的硬體架構也可以和DICOM架構完全隔離，也就是說，網路骨幹的部分不管用哪種線路（如：電話線、ISDN、同軸電纜或光纖），同樣都可以架構DICOM網路。唯一的問題，是在傳輸速度的方面，因為一般醫學影像的資料量都相當龐大，使用較慢的網路骨幹通常會影響影像擷取速度，這些必須要視使用者的需求來作考量。

2.    Conformance Document：

如上所述，起始訊息可以讓軟體和軟體之間建立彼此的共識，以DICOM這共同的語言來交談，那麼，使用者與廠商之間是否也有這樣的機制來讓人了解到他們的系統是否真正相符？答案當然是肯定的。在DICOM規格中，同樣訂立了一套稱為Conformance Document的文件來對照各DICOM系統間的相容性。Conformance Document的內容其實和前一段所介紹的起始訊息有著異曲同工之妙，在一個支援DICOM的儀器或軟體系統完成後，設計者同時必須附上一份Conformance Document，其中必須列舉出該系統所支援的SOP和Transfer Syntax、簡單工作流程和設計者自訂（非DICOM）的部分。這些規格化的SOP及Transfer Syntax皆具有一個由ACR-NEMA組織所賦予全世界通用、獨一無二的UID，以避免衝突或誤解的情形。

對一個醫院的大環境來說，如要建構一個DICOM網路架構，最重要的當然就是要選擇一個能支援最多資料型態和服務種類的醫學影像系統，如此才能順利整合各家不同廠牌的儀器，也不會在未來的發展上反而造成瓶頸，反而徒然浪費人力物力資源。

要挑選一個支援能力最強大，彈性最好的系統就要從Conformance Document著手，不論設置儀器或軟體系統前必須詳閱文件中列舉之規格，確定系統與現有資源完全相容，還要再經實際上線測試才能了解整體適用性如何。

3.    影像資料壓縮：

影像壓縮這個課題，在資訊網路科技的發展上一直都具有相當的地位。而對醫學影像而言，因為其資料量的龐大，是否壓縮或如何壓縮就更是決定整個醫學影像資訊系統成敗的主要關鍵。

讓我們先來看看壓縮究竟能帶給我們哪些好處。第一個明顯可見的優點，就是節省儲存空間，這當然也就是壓縮原本的目的。做一些簡單的計算，假設一張醫學影像的大小是1024 x 1024點，顏色是256灰階，則這樣的影像若不經過壓縮，必須佔用1 M-bytes(1000 K-bytes)的空間，若我們以壓縮比例20:1來計算，壓縮過的影像就只需要50 K-bytes，大小明顯降低；第二，再考慮網路傳輸的速度，假設以56 K-bits的數據機連線來擷取此影像，非壓縮的檔案約需2~3分鐘，壓縮檔則只需6~7秒，可以大幅提昇傳輸效率；最後，再將醫學影像系統整體的壽命列入考量，因為硬體的大小有限，使用壓縮檔案更可以拉長系統使用時間，間接節約成本。

說了這麼多，我們可以知道，在一個醫學影像系統中，使用影像壓縮的技術幾乎是不可或缺的，再來的考量，就是要如何來作壓縮。在DICOM的規格中，目前是以JPEG的格式為壓縮的方法，選擇JPEG的理由，一方面是因其壓縮效率較高，令一方面則是因為其可以支援失真與非失真兩種壓縮型態。

所謂非失真的壓縮，顧名思義，就是表示影像資料在壓縮前後完全不會有差異，所有影像中傳遞的訊息或特徵都沒有損失。這種壓縮方式對要求精確的醫學影像來說，是最適合的解決之道，一方面可以享受壓縮的諸多優點，一方面又無損醫學判斷的準確性。

相對而言，失真的壓縮就可能造成影像品質的損失，而且損失的程度與壓縮比例成正比，簡單的說，檔案壓的越小，畫面品質越差。

然而，與非失真壓縮相比，失真壓縮可以得到更大的壓縮比例，將儲存空間做更有效的利用，所以在一般醫學影像系統中，多是以失真與非失真影像共存的方式來處理。新進的資料以非失真壓縮儲存，等到一定的時間以後，再將非失真壓縮影像進一步壓成失真影像，以節省空間。而在這轉換過程中，同時也將原本非失真影像轉存於長期媒體中（如：MO、CDR、磁帶等）作為永久的存檔資料。

 

F. DICOM 是終極解決方案嗎？

經過以上這些介紹，相信大家都對DICOM的威力有了一定的了解，那麼，既然DICOM有這麼神通廣大，我的醫院裏是不是只要把所有的系統都換成DICOM，一切的問題就都迎刃而解了呢？

很遺憾的，這個問題的答案是否定的。正如我們一再強調的觀念，DICOM它為什麼能受到這麼多組織、廠商和醫院各方面的青睞，主要就在於DICOM規格的包容性強、彈性大，能夠將各種不同的觀念融合運用於醫療影像這個專一的領域中，並隨著各種技術的演進不斷的發展，但這些優點也往往提高了實際上DICOM系統運作的困難度。換句話說，如果我們直接引進一套外國的DICOM系統，從系統裝機、與各儀器連接、到日後種種維修支援、或未來版本更新等，都將造成系統運作的困難，進而影響醫院營運；如果發展DICOM系統的廠商，只是單純以case-by-case的方式設計，不能對DICOM規格的演進作適時的研發與支援，則此DICOM系統將很快的被淘汰而無用。

總而言之，唯有一個完全本土化而且具有豐富DICOM研發經驗與技術的廠商，才能以最專業、最實用的角度來規劃設計醫學影像資訊系統，而且才能確保DICOM永遠都是醫學影像的終極解決方案。

 

G. 結語

DICOM規格是一種電腦醫學影像的通訊規格，它發展的主要目的，是為了要讓醫院中各色各樣的醫學影像儀器和軟體間能夠有一個共通的語言，以塑造一個無國界、無障礙的電腦化醫學影像環境。

近年來，各種不同領域的科技逐漸進入醫院的大門，大幅提昇醫療服務的品質，而其中在資訊與醫療的結合上，DICOM可說是一個非常成功的典範。在二十一世紀中，醫院邁向DICOM化已經是不可抵擋的趨勢，各種支援DICOM規格的儀器和軟體也如雨後春筍般出籠，但由於DICOM規格包容了多方面的技術，也隨著各種技術成熟而不斷演進。

故以醫院的角度而言，若要搭上這班科技列車，就必須選擇具有紮實研發經驗與技術的廠商，才能享受日後技術支援和版本更新的優勢，提高醫院技術水平及形象