DICOM Elements

DICOM Elements

Let’s start with a useful example. Suppose you are a dermatologist and that you use your Smartphone digital camera to record and track patients’ skin condition. You practice a simple procedure that is basically this:

1. Take a photo 

2. Send it to yourself by email 

3. Open the email on your laptop and save the picture in a folder having the patient name. 

As programmers, we don’t have to talk much about the flows of this practice but for a small, one doctor clinic, this might just work. 

In this lesson, we’ll take the JPEG image and DICOMIZE it. When we DICOMIZE an Image we wrap the image in a DICOM envelope and add important data that is required by the DICOM standard in order to enable all DICOM enabled applications to read and display the image correctly. It’s true that non DICOM application can display the JPEG image just as it is now without DICOMIZING but that’s another story. 


We will use RZDCX DICOM Toolkit to convert the image to a DICOM object. Then we’ll ‘dump’ the content of the DICOM object into a text file in order to see how DICOM objects are structured. 

To convert to DICOM using RZDCX we’ll use the following three lines of C# code: 

        private void Convert()

        {

            DCXOBJ o = new DCXOBJ();

            string jpegImage = "my_image.jpg";

            o.SetJpegFrames(jpegImage);

        }

Now let’s see what we have in the file after that by adding a small dump to text file so our function now looks like this:

        private void Convert()

        {

            DCXOBJ o = new DCXOBJ();

            string jpegImage = "my_image.jpg";

            o.SetJpegFrames(jpegImage);

            o.Dump("my_image.txt");

        }

If we now look at the content of the file my_image.txt we'll see this:

# Dicom-Data-Set
# Used TransferSyntax: UnknownTransferSyntax
(0008,0016) UI =SecondaryCaptureImageStorage # 26, 1 SOPClassUID
(0028,0002) US 3 # 2, 1 SamplesPerPixel
(0028,0004) CS [YBR_FULL_422] # 12, 1 PhotometricInterpretation
(0028,0006) US 0 # 2, 1 PlanarConfiguration
(0028,0010) US 96 # 2, 1 Rows
(0028,0011) US 372 # 2, 1 Columns
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored
(0028,0102) US 7 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(0028,2110) CS [01] # 2, 1 LossyImageCompression
(0028,2114) CS [ISO_10918_1] # 12, 1 LossyImageCompressionMethod
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
  (fffe,e000) pi (no value available) # 0, 1 Item
  (fffe,e000) pi ff\d8\ff\db\00\43\00\08\06\06\07\06\05\08\07\07\07\09\09\08\0a\0c... # 9624, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
Let’s go over this dump and see what’s in it. The lines starting with a hash (#) are comments and we’ll ignore them.

DICOM Elements

A DICOM object is comprised of DICOM elements or DICOM attributes. Every line in the above dump represents one element.
Every DICOM Element has a Tag, a Data Type called VR (acronym for Value Representation), Length and Value. In the dump above the lines starts with the tag number (gggg,eeee), then the VR Code, then the value (strings are printed in square brackets) and then a hash sign (#) followed by the element value length, a comma, then Value multiplicity (which we'll talk about later) and the tag name. The tag name and multiplicity are add by the dump method. The way DICOM encodes elements is shown in this drawing taken from the DICOM standard, chapter 5.

Illustration of DICOM element encoding in a DICOM data stream
Image takes from the DICOM standard, Chapter 5.

Tags

Every DICOM element has a Tag that uniquely defines the element and its properties, much like a bar code defines a product in the supermarket. The DICOM tag is comprised of two short numbers called Group and Element. DICOM Tags that are related to one another sometimes have the same group. In our example you can see many elements from group 0028. This is the Image group. These are attributes of the image and are used to describe the image properties. For example (0028,0010) is Rows element and it is the height of the image. (0028,0011) is the Columns and it is the width of the image in pixels. There are more elements of the image group in our example and we’ll describe them in detail when we talk about interpreting and displaying DICOM Images.

Value Representation

The VR is represented as two character code. The VR defines the data type of the element. In our example you can see UI for Unique identifier, US for Unsigned Short, CS for Coded String and OB for Other Byte i.e. a byte stream.
Because every element has a Tag, the tag implicitly defines the VR. For example the Rows element (Tag 0028,0010) is always US (Unsigned Short). This is why the VR is usually redundant and can be omitted. However, the common practice and IHE recommendation is to explicitly state the VR when serializing DICOM objects into files or into network buffers. We’ll talk more about that when we discuss Implicit and Explicit Transfer Syntax.

Value Length
Because DICOM is a binary protocol (in contrast to textual protocols such as html and xml) elements have length. DICOM elements length are always even. Even if the element’s value is a single character string like Patient Sex (0010,0040) that is either ‘M’ for Male or ‘F’ for Female or ‘O’ for Other, the element length should be 2 and the value will be padded by a space (ASCII 0x20). String types (like CS and UI) are padded by space and binary types like US are padded by null 0x0.

Summary

• DICOM Elements are the building blocks of the DICOM standards. They are used in DICOM files and in network communication.
• Every element has a unique Tag that specifies what’s in the element and its data type.
• DICOM Elements are typed. The DICOM data types are called VR.
• Every Element has even length, even if it's value length is odd. Strings are padded with a space and binary data with a null.

Adding Elements to an Object

We conclude this example with a short code snippet showing how to add elements to a DICOM object using RZDCX.
RZDCX takes care for you about the details so you simply create a new element, initialize it with the Tag and set the value. Here's the code:

            DCXOBJ o = new DCXOBJ();

            DCXELM e = new DCXELM();

            // Manufecturer

            e.Init((int)DICOM_TAGS_ENUM.Manufacturer);

            e.Value = "RZ - Software Services"; 

            o.insertElement(e);

In the next chapter we'll add more data elements to the DICOM object we've created to make it a valid DICOM object and then save it to a file and we'll discuss the differences between DICOM objects and DICOM files.

Why is it this way in DICOM?

Introduction to DICOM
Why is it this way in DICOM?
Many times when I explain features and aspects of DICOM I get questions like, “Why do you need DICOM if you have JPEG and XML?”; or, ”why is DICOM so complicated?”. Many variants of such questions continually come up over and over again. These types of questions can be very broad or very specific and relate to all kind of choices that the people who write the standard make and the options that they take.

Here’s an example. In DICOM there’s a command called C-FIND that is used to make queries to another system, to search for images and other entities. You would naturally think of SQL, but in DICOM there’s a different way of doing it. 

Let’s continue with the C-FIND example. The DICOM C-FIND command has three variants, each with its own data model. These variants are ‘Patient Root’, ‘Study Root’ and ‘Patient Study Only Root’. I’m always asked why do we need three variants and I really can’t give a simple answer. Luckily, the third model, ‘Patient Study Only Root’ is now obsolete so we are left with only two models.

There are many more examples like the C-FIND Query Model where DICOM just have too many options and redundancies. But as the standard became more and more common and dominant, developers just took care of all the options and degenerate the redundancies. Many PACS implementation simply treat all three models using the same code. The answer that I have come to use for that kind of questions is:

"That’s the way it is in DICOM and let’s just get on with it"

Introduction to DICOM

Introduction to DICOM

Chapter 1: Introduction

DICOM is a software integration standard that is used in Medical Imaging. All modern medical imaging systems (AKA Imaging Modalities) Equipment like X-Rays, Ultrasounds, CT (Computed Tomography), and MRI (Magnetic Resonance Imaging) support DICOM and use it extensively.

In this tutorial I present a high level review of DICOM. We will look at DICOM from the user point of view trying to avoid the fine details when possible.
Readers familiar with the DICOM standard and its technical vocabulary will surely recognize these terms though I will try to avoid them when there exists a common replacement. The reason for this is because the DICOM standard’s vocabulary is very different from the equivalent terms used in everyday’s computing and I try here to explain DICOM to people with common background in modern software and computing but none or very little background in Medical Imaging and Healthcare IT. 

The core of DICOM is a file format and a networking protocol. 

• DICOM File Format – All Medical Images are saved in DICOM format. Medical Imaging Equipment creates DICOM files. Doctors use DICOM Viewers, computer software applications that can display DICOM images, to diagnose the findings in the images. DICOM files contain more than just images. Every DICOM file holds patient information (name, ID, sex and birth date), important acquisition data (e.g., type of equipment used and its settings), and context of the imaging study that is used to link the image to the medical treatment it was part of. 
• DICOM Network Protocol – All medical imaging applications that are connected to the hospital network use the DICOM protocol to exchange information, mainly DICOM images but also patient and procedure information. The DICOM network protocol is used to search for imaging studies in the archive and restore imaging studies to the workstation in order to display it. There are also more advanced network commands that are used to control and follow the treatment, schedule procedures, report statuses and share the workload between doctors and imaging devices.

Just like every web browser can display JPEG pictures stored on far away servers, medical systems that use DICOM can send and receive DICOM images and search for them in other medical systems. 

DICOM is first of all an Interface Definition. It’s success relies on the ability to integrate medical systems manufactured by many different vendors. 

The reality today in medical imaging is that when installing new imaging equipment in the hospital and plugging it into the network, it can immediately query the medical imaging archive (PACS), retrieve images that were created by other systems and display them. Additionally, if the new system produces images, they can be reviewed on other vendor’s systems that are already members of the network. All this is done without any changes or modifications to any of the involved system software. 

Some of you would rightfully say that this is exactly what you would expect from any new laptop or printer you bring home. However, for the medical community, this was almost impossible before DICOM. Integrating medical equipment of different vendors used to be a big issue. Even today with all the advancement that IT made, very large budgets are spent over interfaces and integration in every large project, not only in medicine. 

The ability of modern imaging equipment to seamlessly collaborate and integrate together in a multi-vendor environment is the most notable achievement of DICOM that led to a great advancement in medical imaging.