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.

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.

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.