为了说明该标准中的许多核心概念，我决定使用一个免费可用的功能强大的工具“ OsiriX”，该工具具有许多开箱即用的DICOM功能。但是，请记住，该软件只能在Mac OS X操作系统上运行。因此，如果您正在运行其他操作系统，我深表歉意。但是，只需阅读此处的材料以及查看显示的屏幕截图，即可帮助您理解这些概念并将其应用于您选择使用的任何其他DICOM软件。另外，请记住，这不是编程教程，尽管很像我以前的HL7文章中采用的方法，
DICOM标准的本质是基于服务提供商（也称为“服务类别提供商”或“ SCP”），服务使用者（也称为“服务类别用户”或“ SCU”）和信息的概念提供者和消费者所作用的对象。例如，前面部分中描述的打印机是服务提供商的示例，被称为具有“ C-PRINT SCP”功能。请求打印活动的应用程序充当服务使用者，并具有“ C-PRINT SCU”功能。服务类及其作用于其上的信息对象模板的组合称为“服务对象对”类，也称为“ SOP”。SOP为与DICOM相关的合规性（或“合规性”）奠定了基础，并允许供应商披露其软件和硬件支持的与DICOM相关的功能。每个SOP类都有一个由DICOM委员会颁发的唯一标识号。SOP类的列表已经很长了，并且随着支持更多的方式而继续增长。
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中如何组织患者的图像。图像始终存储在由患者，他们的研究以及研究中的图像（或“系列”）组成的层次结构中。
通常，当将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软件中如何实现某些查询/检索功能。
DICOM打印服务使图像采集设备和查看工作站可以共享与DICOM兼容的打印机，类似于在信息网络中通常使用普通打印机的方式。DICOM打印可以使用标准校准（在DICOM图像本身中进行编码），以确保各种显示设备以及在其上可以看到图像的硬拷贝打印输出之间的一致性。设备的打印功能指定为“ C-PRINT SCU”或“ C-PRINT SCP”。有多种类型的DICOM打印机可用，它们的功能通过它们声称支持的SOP类来描述。基本支持始终包括灰度打印，彩色打印，具有查找表增强功能的灰度打印以及具有查找表增强功能的彩色打印。可选功能包括注释，图像覆盖和打印作业执行状态报告。OsiriX支持标准中指定的所有基本打印功能。
“最小的善举比最大的意图有价值。” 〜Kahlil Gibran
MPPS服务用于在执行扫描的设备与RIS和/或PACS之间传达与正在执行的成像步骤有关的消息。基本上有两种类型的消息被使用。在过程步骤开始时会发送一个称为“ N-CREATE”的消息，而在过程步骤完成后会发送一个“ N-SET”消息。作为步骤完成的一部分获取的任何图像也将作为此消息的一部分进行传输。
Introduction to the DICOM Standard using OsiriX
- What is DICOM
- Image Transmission within Hospital Systems
- Understanding DICOM Services
- DICOM Services Offered by OsiriX
- Other DICOM Services
- DICOM File Format
- DICOM Structured Reporting
- Conformance in DICOM
- DICOM Interoperability with Other Standards
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.
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.
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”).
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.
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.
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.
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.
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.