[醫療信息化][DICOM教程]DICOM標準簡介

[醫療信息化][DICOM教程]DICOM標準簡介

使用OsiriX的DICOM標準簡介

內容

  1. 介紹
  2. 什麼是DICOM
  3. 醫院系統內的圖像傳輸
  4. 瞭解DICOM服務
  5. OsiriX提供的DICOM服務
  6. 其他DICOM服務
  7. DICOM文件格式
  8. DICOM結構化報告
  9. 符合DICOM
  10. DICOM與其他標準的互操作性
  11. 結論

介紹

這是我有關DICOM標準的系列文章的一部分,並快速概述了DICOM標準。

DICOM是一種醫療保健標準,負責管理醫學成像的幾乎所有方面,例如圖像傳輸,圖像解釋,打印管理,程序管理和離線存儲,並且幾乎用於與醫療保健相關的所有成像“模態”,例如磁共振,核醫學,計算機斷層掃描和超聲檢查。全世界幾乎所有的臨牀成像工作流程都基於DICOM標準。如果您在醫療信息學行業工作或想要工作,那麼學習此標準至關重要。我希望寫本系列文章的目的是通過查看簡短但有針對性的代碼示例,幫助進入“ DICOM世界”的人們更快地學習標準的各個方面和部分。在本文中,我們將從較高的層次看待該標準的所有主要部分,本系列的文章中,我們將使用有助於將DICOM的理論與實際實現聯繫起來的代碼示例,對這些方面的每個方面進行更詳細的研究。

帶代碼的電腦屏幕

爲了說明該標準中的許多核心概念,我決定使用一個免費可用的功能強大的工具“ OsiriX”,該工具具有許多開箱即用的DICOM功能。但是,請記住,該軟件只能在Mac OS X操作系統上運行。因此,如果您正在運行其他操作系統,我深表歉意。但是,只需閱讀此處的材料以及查看顯示的屏幕截圖,即可幫助您理解這些概念並將其應用於您選擇使用的任何其他DICOM軟件。另外,請記住,這不是編程教程,儘管很像我以前的HL7文章中採用的方法,

什麼是DICOM

DICOM代表“醫學數字成像和通信”,由美國國家電氣製造商協會(NEMA)和美國放射學院(ACR)聯合開發,以允許成像設備之間以及與其他設備之間的互操作性。該標準負責管理圖像格式以及傳輸在許多與醫療保健相關的成像“方式”(例如磁共振,核醫學,計算機斷層掃描和超聲)期間生成的醫學圖像信息所需的各種網絡協議。自1983年以來,DICOM標準就以一種或多種形式存在,並且每年都在不斷髮展。

醫院系統內的圖像傳輸

我認爲,解釋該標準的最佳方法是首先描述在診所,醫院或大型衛生網絡中經常發生的與影像相關的工作流程。稍後,我將以這種情況爲基礎來解釋標準的“細節”。

假設某位患者因胸痛入院。主治醫師可以命令進行MRI掃描,並且當此請求記錄在醫院信息系統(HIS)上時,通常會將電子請求發送到位於成像中心的放射學信息系統(RIS)。該請求通常包括有關該請求的來源,訂購者,患者的詳細信息,所請求的成像方式的類型等信息。一旦完成預訂,就將患者發送到成像中心進行掃描。掃描完成後,將從原始數據中創建一組符合DICOM要求的圖像,並將其稱爲“研究”。一項研究本身可能由多個採集組成,具體取決於掃描配置,這些採集中的每一個都稱爲“系列”。

掃描程序完成後,所有圖像都將被存檔以傳輸到PACS系統(圖片存檔和通信系統)。在將掃描的圖像傳輸到PACS系統之前,可以檢查其質量,如果不滿意,檢查技術人員可以再次下令進行掃描。然後可以將存檔的圖像從PACS系統中檢索到工作站,以供放射科醫生查看。放射科醫生可以直接在屏幕上查看圖像,也可以在膠片上打印這些圖像。稍後,她可以在報告中添加有關其觀察結果的其他註釋。一旦她完成了此過程,更改將與PACS系統上的原始研究合併。電子消息也被髮送回RIS,指示模態請求已經完成。

“我們應該被教導不要等到靈感來開始做某件事。行動總能激發靈感。靈感很少產生作用。” 弗蘭克·蒂博特

在繼續閱讀我的文章之前,您可能需要暫停一下,觀看Marc Kohli的精彩視頻,該視頻解釋放射學的典型工作流程,包括DICOM標準(以及其他標準,例如HL7)如何適合其中。我覺得這段視頻確實說明了DICOM如何與任何醫院網絡中更大的醫療保健工作流程集成。

瞭解DICOM服務

如果不使用DICOM(和HL7),則很難輕鬆實現前面部分所述的工作流中涉及的多種類型的硬件和軟件之間的圖像和圖像相關信息的無縫流動。現在讓我們深入研究細節,看看DICOM標準如何使這種類型的信息流發生。

Osirix DICOM軟件

DICOM標準的本質是基於服務提供商(也稱爲“服務類別提供商”或“ SCP”),服務使用者(也稱爲“服務類別用戶”或“ SCU”)和信息的概念提供者和消費者所作用的對象。例如,前面部分中描述的打印機是服務提供商的示例,被稱爲具有“ C-PRINT SCP”功能。請求打印活動的應用程序充當服務使用者,並具有“ C-PRINT SCU”功能。服務類及其作用於其上的信息對象模板的組合稱爲“服務對象對”類,也稱爲“ SOP”。SOP爲與DICOM相關的合規性(或“合規性”)奠定了基礎,並允許供應商披露其軟件和硬件支持的與DICOM相關的功能。每個SOP類都有一個由DICOM委員會頒發的唯一標識號。SOP類的列表已經很長了,並且隨着支持更多的方式而繼續增長。

DICOM標準的目標是在任何醫療保健信息網絡中實現“即插即用”架構。因此,該標準規定,所有具有DICOM功能的設備都會在兼容DICOM的設備之間發生的初始“握手”期間以電子方式公開其功能。這種握手通常稱爲“協會建立”。根據支持的功能,此關聯可以成功還是失敗。如果關聯成功,則將在握手期間協商的格式下,在服務的使用者和提供者之間交換SOP類的實例。先前描述的打印示例中的SOP實例可以攜帶諸如患者信息之類的信息,要打印圖像的像素數據,以及需要與圖像一起打印的所有註釋。讓我們進一步瞭解使用OsiriX的DICOM兼容設備提供的各種服務。

OsiriX提供的DICOM服務

OsiriX軟件具有“ C-STORE SCP”功能,因此能夠將傳入的DICOM圖像存儲到本地數據庫中。這使軟件可以作爲基本的PACS服務器運行。爲了能夠使用此功能,您將在“首選項”屏幕中配置設置,以使OsiriX能夠作爲DICOM偵聽器運行。該軟件具有許多功能,包括能夠使用DICOM標準的“ WADO”規範通過HTTP協議接收圖像(WADO表示“對DICOM對象的Web訪問”)。它還通過基於SOAP的消息傳遞提供Web服務集成。OsiriX提供的另一項與存儲相關的功能是“ C-STORE SCU”。此功能使我們能夠將OCOM的DICOM信息發送到其他DICOM存儲服務提供商,例如PACS系統。“本地數據庫”屏幕(如下所示)顯示了在OsiriX中如何組織患者的圖像。圖像始終存儲在由患者,他們的研究以及研究中的圖像(或“系列”)組成的層次結構中。

Osirix查詢檢索

通常,當將DICOM圖像從查看工作站推送到PACS系統以在硬盤上或在備份介質(例如CD)上進行長期存檔時,至關重要的是,存儲設備必須提供一些確認,說明信息已成功接收並存儲在發送方刪除圖像之前。使用存儲承諾服務在DICOM中可以使用此功能,該服務通常通過結合使用其他服務(例如“ C-MOVE SCU”,“ C-MOVE SCP”,“ N-ACTION”和“ N-EVENT”)來實現。此功能由OsiriX提供。

OsiriX提供的另一個DICOM功能是DICOM圖像的查詢/檢索。這使用戶可以搜索遠程PACS系統,然後檢索他們感興趣的圖像以在本地查看。查詢功能指定爲“ C-FIND SCU”和“ C-FIND SCP”,檢索功能通過“ C-GET SCU”和“ C-GET SCP”以及使用“ C-MOVE SCU”指定”和“ C-MOVE SCP”操作。C-GET操作非常類似於大多數軟件開發人員應該熟悉的HTTP協議中使用的HTTP GET請求,並且經常在從醫院等醫院環境進行通信以從運行中的服務器提取放射圖像時使用在醫院網絡中。C-MOVE操作主要在醫院網絡內使用,既可以檢索圖像,也可以將圖像發送到完全不同的目的地。請查看上面的屏幕截圖,顯示在OsiriX軟件中如何實現某些查詢/檢索功能。

Osirix打印

DICOM打印服務使圖像採集設備和查看工作站可以共享與DICOM兼容的打印機,類似於在信息網絡中通常使用普通打印機的方式。DICOM打印可以使用標準校準(在DICOM圖像本身中進行編碼),以確保各種顯示設備以及在其上可以看到圖像的硬拷貝打印輸出之間的一致性。設備的打印功能指定爲“ C-PRINT SCU”或“ C-PRINT SCP”。有多種類型的DICOM打印機可用,它們的功能通過它們聲稱支持的SOP類來描述。基本支持始終包括灰度打印,彩色打印,具有查找表增強功能的灰度打印以及具有查找表增強功能的彩色打印。可選功能包括註釋,圖像覆蓋和打印作業執行狀態報告。OsiriX支持標準中指定的所有基本打印功能。

“最小的善舉比最大的意圖有價值。” 〜Kahlil Gibran

DICOM離線存儲服務使用戶可以在可移動存儲介質(例如軟盤,CD-ROM和光盤)上交換DICOM文件。基於成像環境,例如冠狀動脈造影,一般診斷超聲或胃腸道內窺鏡檢查,優選不同的存儲機制。OsiriX提供了將DICOM圖像刻錄到CD-ROM的內置功能(請參見下面的屏幕截圖)。但是,它還允許將DICOM圖像導出爲JPEG,TIFF和QuickTime電影格式,從而可以更輕鬆地進行傳輸。

其他DICOM服務

儘管OsiriX具有許多DICOM功能,但它不提供DICOM中指定的其他更高級的服務,例如“模態工作清單”服務或“模態執行過程步驟”服務(也稱爲“ MPPS”)。通常僅在需要實現與RIS或PACS系統交互時發生的複雜工作流方案時才需要這些服務。

Osirix離線存儲

當您希望最大程度地減少手動鍵入的信息量時,模態工作列表服務非常有用。例如,它允許進行MRI的技術人員將所請求的過程中包含的信息自動傳輸到作爲掃描一部分收集的圖像上。這種方法不僅提高了信息傳輸的效率,而且還提高了患者安全性,因爲減少了錯誤信息的可能性。

MPPS服務用於在執行掃描的設備與RIS和/或PACS之間傳達與正在執行的成像步驟有關的消息。基本上有兩種類型的消息被使用。在過程步驟開始時會發送一個稱爲“ N-CREATE”的消息,而在過程步驟完成後會發送一個“ N-SET”消息。作爲步驟完成的一部分獲取的任何圖像也將作爲此消息的一部分進行傳輸。

DICOM文件格式

除了圖像像素數據之外,DICOM文件還包含其他信息,例如患者身份信息,研究和圖像採集的系列信息等。所有這些信息都以數據集的形式存儲在DICOM文件中。這些數據集本質上是數據對象的集合,而它們又由名稱/值表示形式的幾個屬性組成。有關圖像的信息(包括患者信息,模態信息,圖像的像素數據)存儲在這些屬性中,這些屬性通過DICOM詞典進行維護/管理。一個DICOM文件可以存儲許多圖像(也稱爲“幀”),以便以電影形式或“電影循環”的形式進行查看,因爲它們在DICOM世界中經常被提及。屬性內的圖像像素數據可以根據存儲和傳輸要求以壓縮或未壓縮格式存儲。圖像查看器應用程序可以讀取圖像數據並將其顯示在高分辨率打印機上,從而可以對結果進行準確的診斷。下面的屏幕截圖顯示了OsiriX中如何顯示DICOM圖像的“元信息”。

Osirix結構化報告

DICOM結構化報告

DICOM標準內的結構化報告(SR)支持在醫療設備之間交換診斷報告。這些報告以與任何其他DICOM對象相同的格式存儲。爲SR定義的特殊SOP類提供了一種簡便的方法來基於研究中的圖像存儲基本診斷信息,例如可以無縫存儲過程日誌,觀察值,測量值,波形,並允許我們鏈接這些報告到任何對應的圖像。根據報告中包含的編碼信息的複雜性,有兩種類型:基本文本SR;和增強型SR。

符合DICOM

儘管不是強制性的,但聲稱其產品符合DICOM標準的供應商通常會提供一份一致性聲明,說明其設備或軟件如何支持該標準。一致性聲明中的信息包括如何處理關聯(例如,是否能夠啓動關聯以及並行並行的數量等),受支持的SOP類以及其他信息(例如表示上下文)和通訊資料。客戶可以使用這些文檔中包含的信息來確定供應商的產品是否可以與他們網絡中其他兼容DICOM的設備或軟件成功通信。如果您對如何編寫/構造這些文件感到好奇,請在此處查看OsiriX的一致性聲明示例。

DICOM與其他標準的互操作性

與僅使用DICOM標準相比,在醫療保健信息網絡中實施有效的工作流程需要更多的組件。例如,使用HL7處理醫療系統的許多複雜交易。但是,如果要無縫集成DICOM和HL7,則仍然需要解決一些差距。爲此,制定了IHE(整合醫療保健企業)計劃,以幫助改善DICOM,HL7和許多其他現有醫療保健標準機構之間的合作。以後,我將在單獨的教程中介紹IHE。有關HL7標準的教程,請參閱我的HL7文章系列

結論

我希望您發現此入門教程對深入瞭解DICOM標準很有用。Internet上還有許多其他資源,還有許多不錯的書,它們對我在本教程的更高層次上介紹的領域進行了更深入的研究。我的建議是,如果可能的話,還請您進行培訓,以幫助您提高對使用此標準的熟悉度和信心。如果您對此處提供的信息有任何疑問或批評,請隨時給我發送電子郵件。請注意,由於工作和其他承諾,我可能不會立即與您聯繫。

 

Introduction to the DICOM Standard using OsiriX

CONTENTS

  1. Introduction
  2. What is DICOM
  3. Image Transmission within Hospital Systems
  4. Understanding DICOM Services
  5. DICOM Services Offered by OsiriX
  6. Other DICOM Services
  7. DICOM File Format
  8. DICOM Structured Reporting
  9. Conformance in DICOM
  10. DICOM Interoperability with Other Standards
  11. Conclusion

Introduction

This is part of my series of articles on the DICOM standard, and provides a quick overivew of the DICOM standard.

DICOM is a healthcare standard responsible for governing nearly all aspects of medical imaging such as image transmission, image interpretation, print management, procedure management and off-line storage, and is used in nearly all healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. Nearly all clinical imaging workflows around the world are based on the DICOM standard. Learning this standard is vital if you work or want to work in the healthcare informatics industry. My hope in writing this series is to help a person entering the "DICOM world" to be able to learn the various aspects and parts of the standard faster by looking at short but focused code examples. In this article, we will look at at all major parts of the standard from a very high level, and in the subsequent articles of this series, we will look at each of those aspects in more detail using code examples that help tie the theory of DICOM to practical implementation.

Computer Screen with Code

To illustrate many of the core concepts within this standard, I decided to use a freely available and yet powerful tool called “OsiriX” which has many DICOM capabilities right out of the box. However, please keep in mind that this software runs on the Mac OS X operating system only. So, my apologies if you are running a different operating system. However, simply reading the material here as well as viewing the screenshots shown should help you take in the concepts and apply it to any other DICOM software that you choose to utilize. Also, please keep in mind that this is not a programming tutorial, although much like the approach that I took with my earlier HL7 articles, I plan to use this tutorial as a foundation for some of my DICOM programming tutorials in which I will illustrate how to write custom software applications using the DICOM standard.

What is DICOM

DICOM stands for “Digital Imaging and Communications in Medicine” and was developed jointly by the National Electrical Manufacturers Association (NEMA) as well as the American College of Radiology (ACR) to permit interoperability between imaging equipment as well as with other devices. This standard is responsible for governing both the image format as well as the various network protocols required for transmission of medical image information generated during the many healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. The DICOM standard has existed in one form or the other since 1983 and continues to evolve every year.

Image Transmission within Hospital Systems

I feel that the best way to explain the standard is by first describing an imaging-related workflow that occurs very frequently in clinics, hospitals, or large health networks. Later, I will use this scenario as the basis for explaining the “nuts and bolts” of the standard.

Let us say a patient was admitted to a hospital with some chest pains. The attending physician may order an MRI scan, and when this request is recorded on the Hospital Information System (HIS), an electronic request is often transmitted to the Radiology Information System (RIS) located in the imaging centre. This request typically comprises of information about where the request came from, who ordered it, the details of the patient, the type of imaging modality requested, etc. Once the booking is done, the patient then is sent for the scan to the imaging centre. After a scan has been completed, a set of DICOM-compliant images are created from the raw data and is referred to as a “Study”. A study may itself consist of several acquisitions depending on the scan configurations, and each of these acquisitions is referred to as a “Series”. Each series will consist of several images, and each of these images are individually referred to as a “DICOM Information Object”.

After the scanning procedure has been completed, all the images are transmitted for archival to a PACS system (Picture Archival and Communication System). The scanned images may be reviewed for quality before being transmitted to a PACS system, and the reviewing technologist may order a scan again if they are not satisfactory. The archived images can then be retrieved from the PACS system to a workstation for viewing by a radiologist. The radiologist may either view the images directly on the screen or print these images on film. Later, she may add additional comments about her observations on a report. Once she completes this process, the changes are merged with the original study on the PACS system. An electronic message is also transmitted back to the RIS indicating that the modality request has been completed. Information may also be transmitted back to the originating HIS along with some of the key images to assist in intervention by a cardiologist if necessary.

“We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” Frank Tibolt

Before you continue reading my article any further, you may want to take a pause and watch this excellent video by Marc Kohli explaining the typical workflow in radiology including how the DICOM standard (along with other standards such as HL7) fits within it. I feel that this video really explains the big picture of how DICOM integrates into the larger healthcare workflow within any hospital network.

Understanding DICOM Services

The seamless flow of images and image-related information between the many types of hardware and software involved in the workflow described in the earlier section could not be easily achieved without the use of DICOM (and HL7). Let us now dive a little bit into the details to see how the DICOM standard enables this type of information flow to occur.

Osirix DICOM Software

At its very core, DICOM standard is based on the concept of service providers (also referred to as “Service Class Providers” or “SCP”), service consumers (also referred to as “Service Class Users” or “SCU”) and information objects that are acted upon by the providers and consumers. For example, the printer described in the earlier section is an example of a service provider and is referred to as having a “C-PRINT SCP” capability. The application requesting the print activity is acting as a service consumer and has “C-PRINT SCU” capability. The combination of a service class along with the information object template that it acts upon is referred to as “Service-Object Pair” class, also referred to as “SOP”. SOPs form the foundation for DICOM-related compliance (or “conformance”) and allow vendors to disclose what DICOM-related capabilities their software and hardware support. Each SOP class has an unique identification number issued by the DICOM committee. The list of SOP classes is very long already and continues to grow as more modalities are supported.

The goal of the DICOM standard is to enable a “plug-n-play” architecture within any healthcare information network. The standard therefore stipulates that all DICOM-capable devices electronically disclose their capabilities during an initial “handshake” that occurs that occurs between DICOM-compliant devices. This handshaking is often referred to as an “Association Establishment”. Depending on the capabilities supported, this association can be successful or fail. If the association is successful, instances of the SOP classes are exchanged between the consumers and providers of a service in the format negotiated during the handshake. The SOP instance in the print example described previously may carry information such as the patient information, pixel data of the images to be printed as well as any annotations that are required to be printed along with the images. Let us look at the various services offered by DICOM-compliant devices a little further using OsiriX.

DICOM Services Offered by OsiriX

OsiriX software has a “C-STORE SCP” capability and is therefore capable of storing incoming DICOM images into a local database. This allows the software to operate as a rudimentary PACS server. In order to be able to use this feature, you will have configured the settings in the “Preferences” screen to enable OsiriX to run as a DICOM listener. This software has many capabilities including being able to receive images through the HTTP protocol using the “WADO” specification of the DICOM standard (WADO stands for “Web Access to DICOM Objects”). It also offers web service integration through SOAP-based messaging. Another storage-related capability that OsiriX offers is the “C-STORE SCU”. This capability permits us to send DICOM information from OsiriX to other DICOM storage service providers such as PACS systems. The “Local Database” screen (shown below) shows how the images for a patient are organized within OsiriX. The images are always stored in a hierarchy consisting of patients, their studies, and the images in the study (or “series”).

Osirix Query Retreive

Often, when DICOM images are pushed from a viewing workstation to a PACS system for long-term archival on hard disk, or on backup media such as CD, it is essential that the storage device provides some acknowledgement that information has been successfully received and stored before the images are deleted at the sender. This feature is possible within DICOM using the Storage Commitment Service which is typically achieved using a combination of other services such as “C-MOVE SCU”, “C-MOVE SCP”, “N-ACTION” and “N-EVENT”. This capability is provided by OsiriX.

Another DICOM capability that OsiriX offers is the query/retrieval of DICOM images. This enables users to search a remote PACS system, and later retrieve images that are of interest to them for viewing locally. The querying capabilities are specified as “C-FIND SCU” and “C-FIND SCP”, and the retrieval capabilities are specified through “C-GET SCU” and “C-GET SCP” as well as by using “C-MOVE SCU” and “C-MOVE SCP” operations. The C-GET operation works very much like a HTTP GET request used in the HTTP protocol that most software developers should be familiar with, and is often used when communicating from outside a hosptial setting such as a clinic to pull radiological images from a server running within a hospital network. The C-MOVE operation is used mostly within a hospital network to both retrieve images and also send images to a completely different destination. Please see screenshot above showing how some of query/retrieval features are implemented within the OsiriX software.

Osirix Print

DICOM printing services enable image acquisition devices as well as viewing workstations to share DICOM-compliant printers similar to how normal printers are often utilized within an information network. DICOM printing enables the use of standard calibration (encoded within the DICOM images themselves) to ensure that there is consistency between various display devices as well as hard copy printouts on which the images are seen. The print capabilities of devices are specified either as “C-PRINT SCU” or “C-PRINT SCP”. There are many types of DICOM printers available, and their capabilities are described through the SOP classes they claim to support. Basic support always includes grayscale printing, colour printing, grayscale printing with lookup table enhancement, and colour printing with lookup table enhancement. Optional features include annotation, image overlays, and print job execution status reporting. OsiriX supports all the basic printing capabilities specified in the standard.

“The smallest act of kindness is worth more than the greatest intention.” ~ Kahlil Gibran

DICOM off-line storage services enable users to exchange DICOM files on removable storage media such as diskettes, CD-ROMs, and optical disks. Different storage mechanisms are preferred based on the imaging context such as coronary angiography, general diagnostic ultrasonography, or gastrointestinal endoscopy. OsiriX provides a built-in feature to burn DICOM images onto CD-ROMs (see screenshot below). However, it also permits the ability to export the DICOM images to JPEG, TIFF and QuickTime movie formats which can transferred more easily.

Other DICOM Services

Although OsiriX has many DICOM capabilities, it does not offer other more advanced services specified within the DICOM such as the “Modality Worklist” service or the “Modality Performed Procedure Step” service (also known as “MPPS”). These services are typically only required when needing to implement complex workflow scenarios that occur when interacting with a RIS or PACS system.

Osirix Offline Storage

The modality worklist service is useful when you want to minimize the amount of information that is keyed in manually. For example, it allows the technologist conducting an MRI to automatically transfer the information contained within the requested procedure onto the images collected as part of the scan. This approach not only increases the efficiency of information transfer, but also increases the level of patient safety as there is a reduced chance for incorrect patient information.

The MPPS service is used to communicate messages pertaining to the imaging steps being performed between the device performing a scan and the RIS and/or PACS. There are fundamentally two types of messages that are utilized. There is something called a “N-CREATE” message which is sent at the start of a procedure step, as well as a “N-SET” message is which is transmitted after a procedure step has been completed. Any images acquired as part of the step completion are also transferred as part of this message.

DICOM File Format

In addition to the image pixel data, the DICOM file contains other information such as patient identification information, study and series information of the image acquisition, etc. All this information is stored inside a DICOM file in the form of data sets. These data sets are essentially a collection of data objects, and these in return consist of several attributes in the form of name/value representations. Information about the image (including patient information, modality information, pixel data for the images) are stored in these attributes which are maintained/managed through a DICOM Dictionary. A single DICOM file can store many images (also known as “frames”) to enable for viewing in the form of a movie or as “cine loop” as they are often referred to in the DICOM world. Image pixel data inside the attributes may be stored in either compressed or uncompressed formats depending on the storage and transmission requirements. Image viewer applications can read and display the image data onto high resolution printers permitting accurate diagnosis of the results. The screenshot below shows how the “meta information” of a DICOM image is displayed within OsiriX.

Osirix Structured Reporting

DICOM Structured Reporting

Structured Reports (SR) within DICOM standard enables the exchange of diagnostic reporting between medical devices. These reports are stored in the same format as any other DICOM object. The special SOP classes defined for SR permit an easy way to store the essential diagnostic information based on the images in a study, such as procedure logs, observations, measurements, waveforms can be stored in a seamless manner, and allow us to link these reports to any corresponding images. Based on the complexity of the encoded information contained in the report, there are two types: a Basic Text SR; and an Enhanced SR.

Conformance in DICOM

Although not mandatory, vendors who claim that their products adhere to the DICOM standard typically provide a Conformance Statement describing how their device or software supports the standard. The information in the conformance statement include how the associations are handled (for example, whether it is capable of initiating associations, and how many in parallel, etc.), the SOP classes that are supported, as well as other information such as presentation contexts and communication profiles. Customers can use the information contained in these documents to decide whether the vendor product can successfully communicate with other DICOM-compliant devices or software within their network. If you are curious how these are written/structured, see an example of a conformance statement for OsiriX here.

DICOM Interoperability with Other Standards

There are many more components required to implement an effective workflow within an healthcare information network than is possible using the DICOM standard alone. For example, many complex transactions with a healthcare system are handled using HL7. However, if DICOM and HL7 are to seamlessly integrate, some gaps are still required to be addressed. For this purpose, IHE (Integrating the Healthcare Enterprise) initiative was developed to help improve the cooperation between DICOM, HL7 and many other existing healthcare standards agencies. I will cover IHE in a separate tutorial in the future. For a tutorial on the HL7 standard, see my HL7 article series.

Conclusion

I hope you found this introductory tutorial useful for gaining a high-level understanding of the DICOM standard. There are many additional resources on the Internet as well as many good books that delve much deeper into the areas that I covered at a high level in this tutorial. My recommendation is also that you also take hands on training if possible, to help boost your familiarity and confidence in using this standard. If you have any questions or criticisms on the information presented here, please feel free to send me an email. Please note that I may not get back to you right away due to work and other commitments.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章