DICOM INTERNATIONAL
CONFERENCE & SEMINAR
Oct 9-11, 2010
Rio de Janeiro, Brazil
Exchanging Imaging
Data
Cor Loef
Exchanging Imaging Data
• Objective: This presentation will
answer the following question:
– What are the types of DICOM objects and
how do we move them around, i.e. over a
network as well as on media?
Exchanging Imaging Data
• Agenda
– Main Classes of Objects: Images,
Presentation States, Structured Reports,
Encapsulated Objects
– Pushing Objects, Pulling Objects, Finding
Objects and Retrieving Objects
– DICOM as a Protocol vs a File Format vs a
product Internal Data Representation
– Use of Media (CDs, Memory Sticks, Email,
WADO)
Information Object Definition (IOD):
IE’s
Modules
Attributes
Information Object Definition (IOD):
• DICOM Composite objects:



For persistent, “permanent” objects using
DIMSE-C commands (C-Store, C-Move, CFind…)
Multiple IE’s: relate to DICOM Information
Model (Patient-Study-Series-Image…)
Cannot be changed or modified, if so, create a
new object with new SOP Instance UID
Multiframe objects:
Vector
•
•
•
•
Ultrasound Multiframe
Nuclear medicine
XA and RF
New objects: MR, CT,
PET, XA-XRF (new),
X-Ray 3D, US 3D
• VL and ophthalmology
• Any future new
objects: NM (new)
Structured Reports:
• Same structure as Images:
– “main body” contains report and/or other
information (measurements, etc.) instead of
pixels
– Same structure for header
– Same study information
– Modality is “SR”
– Has a tree structure
SR example (IHE simple report):
Document Title
(CONTAINER)
HAS OBS CONTEXT
Observation Context
(See Figure 5.3-5)
1
1-n
CONTAINS
Section Heading
(CONTAINER)
HAS OBS CONTEXT
0-1
CONTAINS
0-n
1-n
Image Reference
(IMAGE)
Report Text
(TEXT)
INFERRED FROM
0-n
Image Reference
(IMAGE)
0-n
Measurement
(NUM)
0-n
Measurement
(NUM)
Observation Context
(See Figure 5.3-5)
SR example (Key Image/Object Note-KON):
Document Title
(CONTAINER)
HAS OBS CONTEXT
1
CONTAINS
1
Key Image Description
(TEXT)
1-n
Image Reference
(IMAGE)
Observation Context
(See figure 5.3-5)
Encapsulated Objects (SC and PDF):
• Some objects are difficult to encode as
“native” objects:
• Secondary Capture (SC):
– Digitized film, captured video, documents
• Encapsulated PDF:
– typically for bone scans and eye care
(topographic maps)
Softcopy Presentation State:
- Present images (almost) identical on
softcopy media in standard manner
- Separation of Stored Image Instances from
Display characteristics and changes
- Includes shutters, image annotation,
spatial transformation, display annotation
Softcopy Presentation State:
Solution:
- Create Composite object containing the
presentation state parameters ONLY (no
images)
- Link this Composite object to one or more
images (Series, Images); stored within same
Study; Modality “PR”
- Communicate with regular Storage service
(C_Store); Retrieve with Query/Retrieve
service
How do we move these objects
around?
Push, Pulling Objects (Storage SOP
Classes), Finding Objects (Information
model/FIND) and Retrieving Objects
(Move/Get)
Storage Service class:
Information
System
Modality Push/
PACS Push
Printer
DICOM C-Store
Modality
Archive
PACS
Viewing
Storage Service class:
 Allow
composite objects, e.g. images, reports,
RT plans, waveforms, to be transferred from
one to the other AE
 One AE functions as the SCU, the other one
SCP
 The SOP classes use the C-Store DIMSE-C
service
 The information is stored in some medium,
accessible for some time
(Issue! Might need Storage commitment!)
Query/Retrieve Service class:
Information
System
SCU/
SCP
Modality
Pull/PACS Pull
Printer
DICOM C-Find
DICOM C-Move
Archive
Modality
PACS
Viewing
Query/Retrieve Service class:
 Simple
Query, NOT a full SQL:
 Query: Perform basic image information
queries using small set of common key
attributes (“FIND”)
 Retrieve: Either from remote AE (“GET”), or
Xfer from one AE to the other (“MOVE”)
 Note: “GET” rarely supported
 Extended with retrieval of selected frames of a
multi-frame
Query/Retrieve Service class:
Note: Most vendors also support a proprietary,
direct protocol
DICOM
I/F
SQL
database
(Informix,
Sybase,
Oracle)
Query/Retrieve Service class:
 Key Attributes:
 U:
Unique
 R: Required
 O: Optional
Image IOD
Pat name
Pat ID
----------
Keys
Keys for FIND:
Patient’s Name
(0010,0010)
R
Patient ID
(0010,0020)
U
Study Date
(0008,0020)
R
Study Time
(0008,0030)
R
Accession Number
(0008,0050)
R
Study ID
(0020,0010)
R
Study Instance UID
(0020,000D)
U
Modality
(0008,0060)
R
Series Number
(0020,0011)
R
Series Instance UID
(0020,000E)
U
Instance Number
(0020,0013)
R
SOP Instance UID
(0008,0018)
U
Query/Retrieve Service class:
Q/R SOP Classes use:
 C-Find:
 SCP performs a match of all the keys
specified in the identifier of the request
against the information it has, depending on
level specified (Patient, Study, Series,
Image)
 SCP provides Response for each match
with values of all key fields and requested,
known attributes
 Can also Cancel if needed
Query/Retrieve Service class:
Q/R SOP Classes use:
 C-Move:
 Upon providing unique key values by the
SCU, the SCP initiates C-Store for the SOP
instances indicated. SCP becomes SCU for
Store; requires separate Association
 C-Move responses with status pending can
be issued till all the C-Stores are completed
or after each Store (see conf statement)
 Can also issue Cancel at any time
Protocols, Files, Storage
• Protocols:
– DICOM is a communication standard defining the
protocol (PDU, TCP/IP, addressing: port #, AE title)
• Files:
– DICOM ALSO defines a standard for exchanging files
on media: encapsulated with “group 2” also known as
Part-10 files
– Media includes CD, DVD, flash media
– The part-10 file format is extended for exchange
using emails (WADO)
DICOM Media:
•Meta-file header:
•Transfer syntax
(encoding)
•SOP Class
•Who generated it
•Compliant with
standard OS’s
•DICOMDIR is also
required for
exchange media
Medical Information
Application
Application Entity
Service Class Specifications
Information Objects Definitions
Data Set Structure and Encoding - Data Dictionary
Message Exchange
DICOM Upper Layer Service
Boundary
DICOM
Upper
Layer
File Format
DICOM Basic File Service
Boundary
Security
Layer
(Optional)
Security
Layer
(Optional)
TCP/IP
Transport
Layer
Network Exchange
On-Line Communication
Physical Media
and Media
File Formats
Media Storage Interchange
Off-Line Communication
DICOM Media Specifications:
part 10
DICOM Application Entity
Basic Dir.
Service / Object Pairs
part 12
part 11
DICOM File Format
Media Formats: e.g. File data structures
Physical Media: e.g. CD-R; 90 mm MOD, etc.
Protocols, Files, Storage:
• Storage:
– DICOM does NOT define how to archive
images (there is NO archive standard)
– Some vendors preserve the images in a
DICOM format, some pre-process the images
using a compression method, either standard
or proprietary
– Migration of both PACS databases and
archives are common when changing
releases, vendors, etc.
Conclusion:
• DICOM objects include not only images
but also SR’s, Presentation states, and
encapsulated objects
• DICOM images are moved around using
the DICOM protocol, and exchanged using
the DICOM part-10 file definition
• There is NO DICOM archiving standard,
some archives store natively, some do not
DICOM INTERNATIONAL
CONFERENCE & SEMINAR
Oct 9-11, 2010
Rio de Janeiro, Brazil
Thank you!
Cor Loef:
cor.loef@philips.com
www.philips.com