Introduction to DICOM

• Introduction
• The DICOM Interface
• History
• Information Objects
• Roles
• Service Classes
• Conformance
• Parts of the Standard
• Other DICOM Terms
Traditional imaging workflow

Image Clinical
Acquisition Interpretation

Film
Management
and
Library
Result Distribution
Image Output to
on Film Referring Physician
 Introduction
Introduction- Evolving from a hospital need

In the 1980’s, it became clear

that the tremendous growth
in image acquisition systems,
display workstations, archiving
systems and Hospital Infor-
mation Systems made it
vital to have a good
connectivity and
interoperability between all
kinds of (medical) equipment.

There was a strong need to:

• Share diagnostic information
in different departments
• Combine all medical
information on a patient for
better diagnostic results
• Complete the patient folder
with results from all medical
studies performed
 Introduction
Why do we need a (DICOM) standard ?
Without a standard, custom
interfaces are needed for each
Without a standard: imaging device.
CT
Currently, in a typical multi-
vendor imaging department,
there is little compatibility of
equipment, so custom
interfaces are developed or
purchased in order to
interconnect the equipment.

Custom When Dicom is built into a

Interface medical imaging device, it can
be directly connected to other
equipment via a standard
Print network.
 Introduction
The hospital benefits of the Dicom standard
The benefits are:
• enables the hospital to select
the best equipment per
diagnostic application
• improves the level of
interactive communication
among medical professionals
• provides a wider access to
images and associated
information
• creates new opportunities for
handling diagnostic images in
more cost effective ways.

• Increase diagnostic quality

• Cost effective
 Introduction
DICOM – The Standard in communicating medicine

DICOM is the industry standard

for transferal of medical
images, patient demographics
and related information.

DICOM enables digital

communication between
diagnostic equipment, printers,
picture archives etc. from
various manufacturers
(vendors)

DICOM is the first

• Multi-modality standard multi-modality standard
( US, CT, MRI etc. )
• Multi-vendor standard
 Introduction
Introduction - What DICOM stands for

In order to simplify and improve

equipment connectivity,
medical professionals joined
forces with manufacturers in an
international effort to develop
DICOM.

DICOM stands for:

D = Digital
I = Imaging and
CO = Communications in
M = Medicine
 Introduction
History

DICOM is the result of an

alliance of potential users of
the standard ( Members of the
American College of Radiology
ACR NEMA - ACR ) with the companies
(Users) (Manufacturers) that manufacture medical
equipment ( Members of the
National Electrical
Manufacturers Association -
NEMA ) that began in 1984.

DICOM DICOM has also been

standard embraced by other worldwide
standards organizations and
other healthcare disciplines
outside of radiology.
History

DICOM, the expanding standard Through development over the

course of more than the past
decade, DICOM continues to
grow and evolve to meet the
2000 needs of the imaging
community.
1999 DIC
OM •ACR/NEMA 1.0 (Ó1985)
1998 •ACR/NEMA 2.0 (Ó1988)
DIC
OM •DICOM 3.0 (1993) current
1997 3.0
evolving standard
DIC
1996 OM
3.0 Work continues on many useful
1995 supplements to DICOM which
extends its usefulness to other
medical disciplines, such as
Endoscopy, Radiation Therapy
Planning, Pathology and
More than 40 supplements during the past years Diagnostic Reporting
 Introduction
Image transfer via networks

Image Acquisition CT DICOM uses computer industry

standards to provide a network
connection with other devices.
This allows easy connection of
DICOM imaging equipment to
existing hospital networks.
Archive
Intra-hospital connections,
communication with remote
Standard hospital network clinics and tele-radiology
applications are supported.

Distribution
Printer
 Introduction
The DICOM interface
A manufacturer uses the
standard to design and build a
product. The Dicom standard
describes all of the detailed
functional specifications which
Image Acquisition a device with a communication-
DICOM interface (allowing one
computer to ‘talk’ to another
Interface
e.g. Ultrasound Inside medical
computer) must employ to meet
equipment the standard.
The standard provides a
common reference for all
developers of medical
equipment.
DICOM image
The interface uses a set of
computer software which
executes the DICOM protocol.
The software also formats the
data for transmission.
DICOM concepts

Information Objects:
Information Objects
standardize the content of
a wide range of image
DICOM types (e.g. CT, MRI, NM,
concept US, Xray)

Service Classes:
Service classes define what to
do with those Objects (e.g.
store, move, print) across
Information Role Service the network.
Objects Definition Classes Role Definition:
In the Role Definition is
defined which equipment
Three concepts specified is the transmitter of
information and which
equipment is the receiver
of information.
Information Objects

The Information Objects consist

Information of two parts:
Objects •Object Attributes
•Image Object

Object Attributes Image Object Object Attributes:

•patient information e.g. CT pixel matrix This is the so called header
•acquisition parameters
information of an image
•modality etc
containing Patient information,
modality information etc.
Example: CT Object
Patient module : Name, birthday, sex etc Image Object:
• Study module : Study date, time, ID etc The Image Object contains the
• Series module : Modality, series etc Attributes
• Image plan module : Slice orientation, slice thickness pixel data of the medical image,
• Etc. like the pixel data of a CT-
image.
Image
Information Objects

• Information Objects are not only

images and graphics but also
studies, reports, lists, etc.

• An information Object has:

– Modules
– Attributes
Data elements

In all the modules there are standard data elements

that can be :
M : Mandatory.
C : Conditional.
U : User options.
M* : Mandatory with special conditions.
U* : User option with special conditions.

All the defined data elements start with an even

number (like in ACR-NEMA).

Private data elements have an odd number and may

contain data that is not defined in the standard data
elements.

example :Relative Couch position : 0019 110B

Service Classes

A Service Class defines the

service or operation that can
Storage Service Class take place ( e.g. printing, storing
etc.) now that the objects have
Query and Retrieve Service Class been defined.

Print Service Class

Modality Work list Management Service Class

Modality Performed Procedure Step Service Class

Media Storage Service Class

Storage Commitment Service Class

Structured Reporting Service Class

 Roles –storage class user, provider
To setup communication, two
I am a User of the I am Providing the roles have to be specified:
Archive Services Archive Services
Service Class User
•The device that sends information
or an image on the network is a
Service Class User Service Class Provider Service Class User ( SCU ).
(SCU) (SCP) The SCU uses the network service.
( e.g. A CT scanner uses a network-
workstation to display the CT
Image images)
Archive
acquisition
Service Class Provider
•The device that receives
information or an image from the
network is a Service Class Provider
Network ( SCP ).
The SCP provides the service to the
network ( e.g. a network-archive
provides the archiving service )
 Roles –Print class user provider

I am a User of the I am Providing the

Print Services Print Services
A CT scanner uses the Print
Services of a printer which is
Service Class User Service Class Provider connected to the network.
(SCU) (SCP)
Printer
A Printer provides the Print
Image Services to the network
acquisition
A SCU always needs a SCP
and visa versa.

Network
 Successful communication
If two devices want to have a
The DICOM functionality is defined as follows:
successful communication, we
Functionality = must consider the following:

Information Role Service • What functionality is

Objects
+ Definition
+ Classes supported?
• Communication Rules.
E.g. : XRAY image + SCU + Storage
To make a successful communication between Systems
we must consider the following communication Rules:

• They must support identical Information Objects

• They must support identical Service Classes
• A SCU needs a SCP ( a User needs a Provider )

Communication examples are:

CT Storage SCU and CT Storage SCP : OK
XRAY Print SCU and US Print SCP : No good
 Association request
If two devices want to have a
1. I need to STORE US successful communication,
2. Yes, I can STORE US
images, do you support they first must negotiate
images in my archive
this? supported functions and rules.

Storage Service Storage Service This is accomplished by an

Class User Class Provider association request or
“handshake.”

Image
Archive
acquisition

1 2
Network
Verification Service classes
The verification Class is used to
test DICOM connections
over the network. It uses the
DICOM echo command to
another DICOM compatible
workstation to verify the
Verification (SCU) Verification (SCP) connection.
Most systems have the
verification class user and
provider function to be able
to test connections.
Provider means that when you
Echo
receive a DICOM echo
SCU SCP command that you will
respond to this (you provide
this service to the users on
the network).
User means that you can send a
DICOM echo command to
another system. (you use the
service from a provider on
the network).
 Storage Service Class

•The storage class describes

I can send US-images I can store US-images the storage of digital images in
to a Storage device in my archive via a network.

•In the Storage Service

Storage Service Storage Service Classes, two Roles can be
Class User Class Provider defined: User and Provider

•If you are Storage Class User,

Image
Archive
it means that you can send data
acquisition to a Storage Class Provider.

•If you are Storage Class

Provider, it means that you can
receive data from a Storage
Network
Class User, provided that both
systems do support the same
Image-object. E.g. an US-image
object.
Query and Retrieve Service Class
•The Query and Retrieve Service
1. Please send me a 2. Here you have the Class supports basic operations to
list of studies of list access and move images based on
patient X search criteria, such as retrieving an
image of a particular study of a
patient X
4. Here you
•If you are Query and Retrieve User
3. Please send me have image you can ask for a list from a Query
images no. 4 no. 4 and Retrieve provider on the
network and pull any desired image
Archive from this provider to your local
Viewing system.
station server
Query •An additional condition is that both
systems support the same DICOM
Image Object ( e.g. US-Object )

•If you are Query-and-retrieve-

Provider you accept a request for a
list from a Query-and-retrieve-User
over the network and send the
desired data images to this user.
Modality Worklist Management Service Class

The worklist management service

class is intended to transfer patient
information between the hospital
server (HIS=Hospital Information
System, RIS=Radiology Information
New patient System) and the imaging
equipment.
All clinical appointments in a
hospital are normally made on a
central HIS/RIS server. With
Patient Worklist management class it is
schedule list possible to send the patient
information from the central desk to
TOSHIBA HIS/RIS- all imaging equipment. The
advantage is that the operator at the
User Server Ultrasound system doesn't need to
Provider type in all the patient information
(with the risks of typing mistakes).
Even a bigger advantage is that
traceability of patient images in the
archive can be better guaranteed.
 DICOM Data Exchange Walkthrough

SCP
SCU
Image

DICOM
Application DICOM DICOM Protocol

Transfer TCP
Communication TCP TCP Protocol
Protocol
IP
Network IP IP Protocol
(Internet Protocol)

Ethernet
Link Ethernet card Ethernet card Protocol
(DICOM I/F PWB)
Network
Data transfer

• When the system starts the communication, it

will send a package to the other system
(provider) with
– The other party's IP address
– The other party's Port Number.
– The other party's AE title (Application Entity)
– The systems IP address for return handshake
• In the other system this packet will be passed
upwards and because of the port number, the
TCP layer knows to which application this
package must be passed. The DICOM provider
will now check the AE Title and respond to the
source IP number with the source port
number.
• The packages that are sent are called
datagrams.
OSI model

• Application
• Presentation
• Application • Session
• Transport
• Presentation • Network
• Datalink
• Session • Physical
• Transport • Application

• Network
• Datalink
• Physical
Image transfer via networks

• OSI model
DICOM Application Entity

DICOM "Added
Value"
OSI Assocationa DICOM
OSI Upper Layer Control (ACSE)
Service Boundary Upper Layer
OSI Presentation protocol for
OSI Session TCP/IP
OSI Transport TCP
OSI Network
IP
OSI LLC Standard
Networking

Ethernet, ATM, FDDI, ISDN, etc.

DICOM Terminology

Application Entity
The label or name of a
• Application Entity DICOM application

• Image Object Definition Image Object Definition

(IOD)
• Service Class The standardized format for
data based on the modality of
the image. CT images have
• Association a different IOD than do US
images.
• DIMSE Services
DICOM Terminology

Service Class
associates one or more
Information Objects with one
• Application Entity or more Commands to be
performed upon these
• Image Object Definition objects. Service Class
Specifications state
requirements for Command
• Service Class Elements and how resulting
Commands are applied to
• Association Information Objects. Service
Class Specifications state
requirements for both Users
• DIMSE Services (SCU’s) and Providers
(SCP’s) of communications
services.
DICOM Terminology

Association
The initial ‘handshake’
• Application Entity between Application Entities
(AE’s) that represents an
• Image Object Definition agreement the SCP will
support the requested
services of an SCU.
• Service Class
• Association DIMSE Service
Generic services which act
• DIMSE Services upon instances of an
information object. The
specific messages that AE’s
use to
DICOM data format

• Since there are 2 different data Most DICOM programs accept

both forms and convert it
formats commonly used you automatically to their desired
format (depending on the CPU
must specify what format you and Operating System.
use in your DICOM The default setting is Little
conformance statement: Endian.

– Little Endian: If byte order 68A4 is

received it will be converted to
A468.

– Big Endian: If byte order 68A4 is

received it is not converted.
Conformance Statement
Anyone claiming that their
equipment or software conforms to
the DICOM standard, must be able
DICOM Standard to provide a so called Conformance
Statement that describes exactly
System A how that device or software
Connectivity conforms to the standard.

System B A question that is frequently asked

about the DICOM standard is :
If DICOM is a standard, why is a
Conformance Statement required?
Isn’t it sufficient to simply state that
equipment conforms?
As has already been explained,
DICOM can support many different
Information Objects, Service
Classes etc.
Because of the wide multi-modality
scope of the DICOM standard, a full
implementation of the DICOM
standard is seldom targeted in a
medical product development plan.
 Conformance Statement
The Conformance Statement of a
Example of a Toshiba Conformance Statement: DICOM interface (defining a part of
the DICOM standard), contains the
following items:
•Which Information Objects are
TOSHIBA No.2A260-669E supported
•Which Service Classes are
supported
DICOM •Which role ( SCU or SCP ) is
CONFORMANCE STATEMENT supported
FOR
TOSHIBA WHOLE BODY X-RAY CT SCANNER A user or manufacturer trying to
X-SERIES determine if two DICOM devices will
communicate to suit a particular
application, can compare the
conformance statements side by
side.

This process does not guarantee

that the two devices will
communicate properly, but obvious
problems, such as one device not
supporting the service needed by
the other, can be caught.
 Toshiba Conformance Statements

• Most are available from TAMS Web

Site at http://www.toshiba.com/tams
 The Standard

Section Introduction and Overview

Part 1 Introduction and Overview • Overview of the DICOM
Part 2 Conformance standard. It describes the
Part 3 Information Objects Definition history, scope, goals, and
structure of the standard.
Part 4 Service Class Specifications
Conformance
Part 5 Data Structure and Encoding
• Defines principles that
Part 6 Data dictionary implementations claiming
Part 7 Message exchange (DIMSE) conformance to it are
Part 8 Network Communications Support for message exchange required to follow.
(TCP/IP) • Defines DICOM
Part 9 Network communication support for message exchange (50 Conformance Statement,
pin) minimum general
Part 10 Media storage and file format conformance
Part 11 Media storage application profiles
requirements, etc.
Part 12 Media formats and physical media
Part 13 Print management
Part 14 Grayscale standard display functions
 The Standard

Section Information Object Definitions

Part 1 Introduction and Overview • Specifies all the Information
Part 2 Conformance Object Definitions (i.e.
images, overlays, print
Part 3 Information Objects Definition
objects, etc.)
Part 4 Service Class Specifications
Service Class Specifications
Part 5 Data Structure and Encoding
• Defines all the Services
Part 6 Data dictionary Class and more important
Part 7 Message exchange (DIMSE) SOP classes (i.e. Store,
Part 8 Network Communications Support for message exchange Query, Retrieve, Print, etc.)
(TCP/IP) Data Structure and Encoding
Part 9 Network communication support for message exchange (50 • Defines the structure and
pin) encoding rules of the Data
Part 10 Media storage and file format Set (encoding, transfer
Part 11 Media storage application profiles syntax, etc.)
Part 12 Media formats and physical media
Part 13 Print management
Part 14 Grayscale standard display functions
 The Standard

Section Data Dictionary

Part 1 Introduction and Overview • Registry of all DICOM
Part 2 Conformance
data elements and unique
identifiers (UIDs).
Part 3 Information Objects Definition
Message Exchange
Part 4 Service Class Specifications • Defines the DICOM
Part 5 Data Structure and Encoding Message Service Element
(DIMSE). It specifies the
Part 6 Data dictionary
protocol to send
Part 7 Message exchange (DIMSE) commands such as Store,
Part 8 Network Communications Support for message Find, Move, Get, Create,
exchange (TCP/IP) Action, Event, Set, and
Delete.
Part 9 Network communication support for message exchange (50
pin) Network Communication
Support for Message
Part 10 Media storage and file format Exchange
Part 11 Media storage application profiles • Defines the services and
Part 12 Media formats and physical media upper layer network
protocols (i.e. association
Part 13 Print management
negotiation, support for
Part 14 Grayscale standard display functions TCP/IP, OSI, etc.)
 The Standard
Section Network Communication
Part 1 Introduction and Overview Support for Message
Exchange
Part 2 Conformance
• Define the 50-pin
Part 3 Information Objects Definition protocol. This portion of
Part 4 Service Class Specifications the standard is no longer
Part 5 Data Structure and Encoding
significant in an actual
networking clinical
Part 6 Data dictionary environment.
Part 7 Message exchange (DIMSE) Media Storage and File
Part 8 Network Communications Support for message exchange Format
(TCP/IP) • Specifies the general
Part 9 Network communication support for message
model for media
exchange (50 pin) interchange (i.e. DICOM
File Format, Directory,
Part 10 Media storage and file format etc.)
Part 11 Media storage application profiles
Part 12 Media formats and physical media
Part 13 Print management
Part 14 Grayscale standard display functions
 The Standard
Section Media Storage Application
Part 1 Introduction and Overview Profiles
Part 2 Conformance • Specifies a selection of
choices which are
Part 3 Information Objects Definition applicable to a specific
Part 4 Service Class Specifications need or context in which
Part 5 Data Structure and Encoding
media interchange is to
be performed (i.e. X-ray
Part 6 Data dictionary Cardiovascular, etc.)
Part 7 Message exchange (DIMSE) Media Formats and Physical
Part 8 Network Communications Support for message exchange Media
(TCP/IP) • Specifies a set of physical
Part 9 Network communication support for message exchange (50
media and formats (i.e.
pin) CD-R, 3" MOD, etc and
DOS, ISO 9660, etc.)
Part 10 Media storage and file format
Print Management
Part 11 Media storage application profiles • Point-to-point
Part 12 Media formats and physical media Communication Support
Part 13 Print management • Defines a point-to-point
print protocol replacing
Part 14 Grayscale standard display functions
the network.
 The Standard

Section Grayscale Standard

Part 1 Introduction and Overview Display Function
Part 2 Conformance • Specifies the display
Part 3 Information Objects Definition standard used to
obtain visual
Part 4 Service Class Specifications
consistency in how a
Part 5 Data Structure and Encoding given digital image
Part 6 Data dictionary appears whether
Part 7 Message exchange (DIMSE) viewed on separate
Part 8 Network Communications Support for message exchange
display monitors or
(TCP/IP) light boxes.
Part 9 Network communication support for message exchange (50
pin)
Part 10 Media storage and file format
Part 11 Media storage application profiles
Part 12 Media formats and physical media
Part 13 Print management
Part 14 Grayscale standard display functions
Questions