Digital Imaging and Communications in Medicine (DICOM)

5.5 DICOM Objects 47
mation and commands. All DICOM data (such as medical images, commands,
and reports) is always wrapped in DICOM object format. In this format, it
travels between various DICOM devices on a DICOM network and gets stored
in DICOM files. In fact, even DICOM files can be viewed as memory dumps of
DICOM objects to a file media.
When we studied the DICOM Data Dictionary, we learned that DICOM
breaks all real-world data into atomic pieces, called data elements, encoded
with 27 available VR types. A DICOM object is nothing but a collection of data
elements – there is no separate “DICOM header” vs. “DICOM image”, as many
like to think. For example, consider a digital medical image. It will have several
attributes such as image width, height, colors (palette), date the image was acquired,
and so on. All of these attributes can be found in the standard DICOM
Data Dictionary and will be translated into DICOM data elements, each with
its own tag and value. The sequence of these translated elements, which describes
the image in its entirety, becomes the image’s DICOM object.
DICOM objects, however, can grow much more complex than simple element
sequences. When we looked at VRs, I mentioned one particular VR type
used for sequencing, SQ. The SQ VR is designed to hold a sequence of data element
sets, each set being, in essence, a separate DICOM object. These DICOM
objects in turn may also contain SQ VRs, meaning that DICOM objects can
contain sets of other DICOM objects. This recursion or nesting of DICOM objects
creates a more complex tree-like structure, making DICOM objects look
like data trees, with DICOM objects being the branches and data elements the
leaves (Fig. 8).
How does DICOM write all this complex branching data? It uses very basic
data encoding rules that we are about to review.
Fig. 8 DICOM object nesting