The DICOM Standard

Digital Imaging Communications

in Medicine
 DICOM was developed as a digital-image transmission standard in
order to enable users to retrieve medical images and associated
information from digital imaging equipment in a standard format
that would be the same across multiple manufacturers’ systems.
 It makes it possible to predict the interconnection of various
imaging modalities, through a Document of Conformity or "
Conformance Statement " emitted for each machine/software
following this standard.
 Thus, the standard makes it possible for the equipment to
communicate remotely through a network or a media (disk or
tapes ). By ensuring the compatibility of the equipment and by
eliminating proprietary formats.
 It defines:
• How the radiological objects (images, reports, measurements
and other related patient documentation) should be structured
• How radiological objects should be exchanged.

 The standard is both a file format and a transfer protocol, and

it is not tied to a particular manufacturer, hardware device,
operating system or software application.
 Let’s Recall Communication
Protocols: Key to Connectivity

 Layered Model, each layer performs a specific function

 Set of Services and Protocols
 Connectivity requires sharing of a complete protocol
define in

[
DICOM format
 Communication requires a shared Semantic Context
-
 ISO Reference Model (OSI)
APPLICATION

Upper Layers PRESENTATION

(DICOM) (3)
SESSION

TRANSPORT

NETWORK

Lower Layers DATA LINK

PHYSICAL
 Communication Standards
 Protocols are defined by standards
 A Standard is an agreement which may be voluntary,
Government mandated, or International Law
 Protocols may also be proprietary
-
 Who Defines Communication
Standards?
 User Consortia (e.g., HL7)
 Organizations (e.g., National Electrical Manufacturers
Association NEMA, IEEE)
 US Government Agencies (e.g., ANSI, NIST)
 Foreign Government Agencies (e.g., CEN)
 United Nations (e.g., ISO, CCITT)
 ACR-NEMA history for knowledge

X
 1982 – ACR (American College of Radiology) and NEMA
(National Electrical Manufacturers Association) form a joint
committee
 1985 - Publication of Version 1.0
 1988 - Compression and Mag Tape Standards
 1988 - Publication of Version 2.0
 1989 - Began work on Network Version with HIS/RIS
 DICOM
 A new version aiming to include network protocols was released
in 1992.
 Because of the magnitude of changes and additions, it was given a
new name: Digital Imaging and Communications in Medicine
(DICOM 3.0) 1993.
 Current version of DICOM in use from 1993 onwards remains
DICOM v3, which is still being developed, receiving regular updates
but retaining the same version number.
 Updates allowing for wide ranging compatibility between old and
new equipment, even when recent technologies had not been
foreseen originally. compatibility
 Consequence of this interoperability is that estimated trillion medical
-

images can be viewed and transferred with DICOM today.

 In 1996, a new version was released consisting of 13 published parts
that form the basis of future DICOM new versions and parts.
 Manufacturers readily adapted this version to their imaging products.
 Function of DICOM
 DICOM as standard contains number of parts, with 18 (20 total, with
two retired) as of 2017 that document and define standard way for data
to be formatted, communicated, and presented by medical imaging
systems during the creation, management, and exchange of those images
 By creating common standard this allows imaging acquired on one
manufacturer’s device to be viewed on another compatible device much
more widely, and is basis for how we are able to ‘mix-and-match’ different
pieces of equipment within our departments
 DICOM standard overall defines:
 Set of protocols (rules) for manufacturers to use
 Syntax (arrangement) and semantics (meaning) of commands and data
models (relationships)
 Guidance on standardized formatting of data
 Communication methods
  Each DICOM document is identified by title and standard
-

number in the form:

Dicom us
PS 8
3.X-YYYY where “X” is the part number and “YYYY” is the
year of publication.
 Thus PS 3.1-1996 means DICOM 3.0 document part 1
(Introduction and Overview) released in 1996.
 X
The Parts of the DICOM Standard
 Part 1 - Introduction and Overview
 Part 2 - Conformance
 Part 3 - Information Object Definitions
 Part 4 - Service Class Definitions
 Part 5 - Data Structures & Semantics
 Part 6 - Data Element Listing and Typing (Data Dictionary)
 Part 7 - Message Exchange Protocol
 Part 8 - Network Support for Message Exchange
 Part 9 - Point-to-Point Support
 X
The Parts of the DICOM Standard

 Part 10 - Media Storage and File Format

 Part 11 - Media Storage Application Profiles
 Part 12 - Media Formats and Physical Media
 Part 13 - Print Management Point-to-Point
 Part 14: Gray Scale Standard Display Function
 Part 15: Security Profiles
 Part 16: Content Mapping Resource
 Part 17: Explanatory Information
 Part 18: Web Access to DICOM Persistent Objects (WADO)
 DICOM Application Domain
Storage, Query/Retrieve,
workstation

Lite Box
Study Component
MAG N

ETOM

Print Management
Query/Retrieve
Results Management

Media Exchange modality

Query/Retrieve, Patient & Study Management

Archive

Information Management System

THE DICOM 3.0 STANDARD

 Two fundamental components of DICOM are the

① ②
information object class and the service class.
 Information objects define the contents of a set of images and
their relationship.
 The service classes describe what to do with these objects.
 The service classes and information object classes are
combined to form the fundamental units of DICOM, called
service-object pairs (SOPs).
 DICOM Information Object Classes
 The use of information object classes can identify objects encountered
in medical imaging applications more precisely and without ambiguity.
 For this reason, the objects defined in DICOM 3.0 are very precise.
 However, sometimes it is advantageous to combine normalized object
classes together to form composite information object classes for
facilitating operations.
 As an example, the computed radiography image information object class is
a composite object because it contains attributes from the study
information object class (image date, time, etc.) and patient information
object class(patient’s name, etc.).
 DICOM Information Object Classes
Normalized one data Composite Group of data

Patient Study Computed tomogram

Results Digitized film image

Storage resources MR image

Image annotation Nuclear Medicine image

Ultrasound image
 Unique Identifiers (UIDs)
Several UIDs generated within each modality and included within
produced images: > easy
-
to retrieve images or data

 DICOM uses a unique identifier (UID), 1.2.840.10008.X.Y.Z, to identify a specific

part of an object, where the numerals are called the organizational root and X,Y, Z are
additional fields to identify the parts.
 UIDs generated for DICOM services all begin with the leading digits
1.2.840.10008[…] allowing for their easy recognition among wider network traffic
 Information about generating devices, patient, individual encounter, and files making
up study
 Each image within study contains number of different UIDs to link it to remainder of
series, exam, and overall patient encounter (Hierarchy being: Patient > Study > Series
> Image)
 Globally unique from various issuing registries, which seek to avoid duplication by
assigning batches to manufacturers and individuals or sites as required >
- each
UID
manufacture
even if the
have

devices are
different

the same

 Note that the UID is used to identify a part of an object; it does not carry information.
 DICOM Service Classes
 DICOM services are used for communication of imaging
information objects within a device and for the device to perform a
service for the object, for example, to store the object, to display the
object, etc.
 DICOM builds its more common services out of a set of service
elements called “DICOM message service elements” (DIMSEs).
 For example, query-retrieve is made up of the “find,” “get,” and
“move” DIMSEs
 These DIMSEs are computer software programs written to perform
specific functions.
 There are two types of DIMSEs, one for the normalized objects and the
other for the composite objects.
 DIMSEs are paired in the sense that a device issues a command request
and the receiver responds to command accordingly.
 DICOM Service Classes
 DICOM services are referred to as “service classes” because of
the object oriented nature of its information structure model.
 If a device provides a service, it is called a service class provider -

(SCP).
 If it uses a service, it is a service class user (SCU). -

 Thus, for example, a magnetic disk in the PACS controller

server is a service class provider for the server to store images.
>
- provider :

Archive
-

On the other hand, a CT scanner is the service class user of the

user

provider
magnetic disk in the PACS server to store images.
-

 Note that a device can be either a service class provider or a

service class user or both, depending on how it is used.
Example???
Archive as a user : ask for display the
images Archive Provider at time [not the time]
storage
-

as the same
image7
a : a
,

image Y
Server can work both for archive as provider for workstation a the same time
manager as
user -
a
,
b

also provider also user

between Server, archive between Server , workstation

 DICOM Service Classes
 Image Storage: Provides storage service for data sets
 Image Query: Supports queries about data sets
 Image Retrieval: Supports retrieval of images from storage
 Image Print: Provides hard copy generation support
 Examination: Supports management of examinations (which may consist of
several series of management images)
 Storage resource: Supports management of the network data storage resource(s)
Service-Object Pair Class
 The service classes and information objects are combined to
form the functional units of DICOM. This combination is
called a “service-object pair (SOP) class.”
 When setting up a DICOM connection, there is a negotiation
process between entities (devices), where it comes clear what
capability the decive supports and what not (either it is SCU
-

user

or SCP or both).
~
from conformance statement

Provider

 These capabilities are clearly specified and identified in the

standard as so-called SOP Classes.
 Service-Object Pair Class
Data Dictionary

Information Object DIMSE Service Group

SOP
Real-World Object
 Common DICOM Terminology
device
>
-
 Modality: discrete type of imaging specialty such as CT, MR, CR, and
US
-

 Application Entity Title (AET): ‘names’ of services or applications

communicating within the network, typically used to identify individual
pieces of image acquisition equipment
 Modality Worklist: service that provides collated feed of demographic
and exam data to image acquisition equipment
 Query/Retrieve (Q/R): provides method to search (query) for
particular attributes – normally a patient name, patient ID, or date of
birth, etc., then to download (retrieve) matching examination data and
images
 Association: connection or conversation between two programs
 Service-object pair (SOP) class: equivalent to ‘topic’ of conversation and
is framed in context with actor (‘thing’ doing action) plus action
required
 Common DICOM Terminology
 Service Class User (SCU) and Service Class Provider (SCP): two
‘ends’ of single connection at any one time – SCU is end T

initiating the contact, and SCP receiver or responder

user

 Composite and Normalised Operations

 Composite operations (beginning with C-) are found as part of
wider sets of instructions (common in PACS)
-

 Normalized operations (beginning with N-) contain enough

information to be free-standing as single instruction (rare). -

>
-
modality or workstation

"

DICOM file
-
 DICOM Data Format

 DICOM Model of the Real World is used to define the

hierarchical data structure from patient, to studies, series,
and images and waveforms.
 It provides a framework for various DICOM Information
Object Definitions (IOD).
 DICOM Data Format

 DICOM file format defines how to encapsulate the DICOM data set of a SOP
instance in a DICOM file.
 Each file usually contains one SOP instance.
 The DICOM file :
 Self contained file, not very different from any other file, i.e. a text-document. (CT, MRI, …)
 Consists of the header and the content

The header contains a long stream of textual information, specific to the type of
content.
 UIDs within the Header
-
Study, Series, Individual Image, Modality, Date, ...
 The DICOM File Meta information (header) includes file identification information. The
Meta information uses Explicit VR (Value Representations) Transfer Syntax for encoding.
Medical Image Viewer
 Data Structure and Encoding
 DICOM has very specific definitions of the different data types
allowed, called “value representations” (VR).
 DICOM historically defines the VR in a data dictionary.
 In DICOM 3 and higher VRs are explicitly imbedded in each
data element.
 DICOM allows both methods, and this is one of the issues
negotiated between application entities at association time.
 The VR and the byte order are part of a set of information
required for a successful interchange. This set is called the
“transfer syntax.”
 DICOM Header With Explicit VR
 Each image generated by medical equipment has, stored within, chunk
of information about technical aspects of image, patient, and transfer
methods at its start, followed by actual image data -Date
 DICOM tag would read: 0008 0020 | 8 | study_date | DA | 1 |
-
-
#
u

“20130415” T
-

⑤ ①
April 15 2015
-
⑤

Q Two blocks of hexadecimal characters at the start of each row are Group and
Element number – these reference parts of the standard and help equipment
know what information is being presented
② Length advises the maximum size of value
③ Description aids human interpretation by providing short explanation of
row
Q Value Representation (VR) provides type of value system should expect to
find (e.g., DT = Date and Time; UI =Unique Identifier; TM = time) from
list contained within DICOM standard

8 

Value Multiplicity (VM) indicates how many values are provided
-

Actual value is given at the end of row

 Example for DICOM Value Representations
(VR)
Value Representation Description

AE Application Entity

AS Age String

AT Attribute Tag

CS Code String

DA Date

DS Decimal String

DT Date/Time

FL Floating Point Single (4 bytes)

FD Floating Point Double (8 bytes)

IS Integer String

LO Long String

LT Long Text

OB Other Byte

OF Other Float

OW Other Word

PN Person Name

SH Short String

SL Signed Long

SQ Sequence of Items
 DICOM Header

*
the same

group number
 One Data Set represents a single SOP Instance.
 A Data Set is constructed of Data Elements.
 Data Elements contain the encoded Values of the attributes of the
Data Set
DICOM object. order of transmissi on

Dat a El em. Dat a El em. Dat a El em. Dat a El em.

Data Element
Value
Tag VR Length Value Field

optional field - dependent on

negotiated Transfer Syntax

 Example: encoding for element “Modality” of “CT” value in

explicit VR
08 00 60 00 43 53 02 00 43 54 Explicit VR
↓
in
Tag VR representing Length Element value :C T
%0 VR Code

Code String CS
0008 Group.
“726” is the number
element

value for the - -

group length

Group length
element 16

“SOP Class UID -

element G

Modality -

Study number - header number

image group --
Description

The image pixel data is not in 0008

Group. Its tag is “7FE0 0010,” and
following the tag are the coding
for pixel data.

An example of Implicit VR encoded CT DICOM file.

 Public Tags versus Private Tags
Public Tags
 Public tags are ‘common’ tags that were internationally standardized by
committee and likely to be found in all files
 These range from being common in every exam (patient name, date of birth,
address, accession number, etc.), to only found in certain examinations (e.g.
pitch, scan width, slice thickness in CT)
 Public tags have even group numbers (the first block of numbers on each
-

row, such as [0008], [0010]).

Private Tags
 Differentiated from public tags by their group numbers being odd numbers
-

 Contain pieces of image information that are either unique to equipment

through which image was acquired, or are extra pieces of data provided
beyond that available in public tags to allow for more specialty use.
 Some uses of private tags may create vendor lock-in
re m
Public Tags versus Private Tags

T
·

Godd
 color , greyscale
↑

Photometric Interpretation
-

 Not all digital images are captured solely in greyscale

 Even when images are in greyscale, there is question as to which ‘way-
around’ greyscale is applied in particular image
 Example: in greyscale range of 0–255, is 0 the whitest pixel value with 255
being pure black or vice versa
 During 2013, problems with incorrect photometric interpretation values
were found, with legacy CR equipment images being displayed inverted
when transmitted through data sharing services until update patch for
original equipment was applied
 Photometric interpretation values are typically: Monochrome 2
(lowest pixel value is displayed black), Monochrome 1 (lowest pixel
-

value is displayed white) or RGB (color)

- -

 Photometric interpretation DICOM tag is included in every image to

ensure correct display
 DICOM Communication
 An example for the movement of the CT images from the
scanner to the workstation with DICOM will take numeral
steps as follows:
(1) The CT scanner encodes all images into a DICOM object.
-

(2) The scanner invokes a set of DIMSEs to move the image

object from a certain level down to the physical layer in the
ISO-OSI model.
(3) The workstation uses a set of DIMSEs to receive the image
object through the physical layer and move it up to a certain
level.
(4) The workstation decodes the DICOM image object.
-
 C
-

Within a
device the
movement
is called a
service
G
& &

Between devices it is called aE

protocol
other modality

/
Entity
 Conformance
 DICOM Part 2 specifies the structure of a conformance
statement

 DICOM does not specify a test suite or a compliance

verification mechanism

 All DICOM implementations must be supported by a

properly constructed conformance statement
DICOM Conformance Statement
 Implementation Model which describes the Application Entities in the
implementation
 Detailed specification of each Application Entity
 SOP Classes supported
 policies for initiation and acceptance of associations
 Presentation Contexts
 SOP options
 Supported communications protocols
 Specializations
 Configuration
Purpose of a Conformance Statement
 Allow a user to determine which optional
components of the DICOM Standard are supported
by a particular implementation, and what extensions
or specializations an implementation adds.
 By comparing the Conformance Statements from two
implementations, a knowledgeable user should be able
to determine whether or not interoperability is
-

possible. Compatibility
 Examples of Using DICOM
Class serves Storage
:
-
> server

user Provider
=

user if have
start >
- Check it the

the request
Service or not from the
-
u

Conformance
Statement

also by -

the user
 Query
T

user -
provider
-

-
another serves

user : Server

Provider : workstation

termination -

Provider
of the Service
~ user