Transcript DICOM - Research Imaging Institute

DICOM
“The Language of Medical Equipment”
Mick Fox
Digital Imaging and
COmmunication in Medicine
• Committee formed to develop a standard
for imaging equipment to communicate
with other devices.
• Both an image format & a network
protocol. (As you might be able to guess
from the “Imaging” and “Communications”
parts of the name)
Brought To You By:
• ACR:
American College of Radiology
• NEMA:
National Electrical Manufacturers Association
• AAPM:
American Association of Physicists in Medicine
• RSNA:
Radiological Society of North America
Origins
• ACR & NEMA formed a committee in ’83
• Inspired by AAPM’s format for writing images
to tapes
• Released “ACR/NEMA” precursor in 1985
and “ACR/NEMA V2.0” in 1988
• Version 3 in 1993 improved network support
and changed the name to DICOM
• DICOM is still version 3 and has been
updated regularly since
Supported Imaging Modalities
•
•
•
•
•
•
•
•
•
Magnetic Resonance Imaging
Nuclear Medicine
Computed Tomography
Positron Emission Tomography
Ultrasound
Digital X-Ray & X-Ray Angiography
Electron Microscope
Digital Microscopy
And a good bit more…
Devices with DICOM Support
Searching Google for DICOM support I found:
• Printers
• Projectors
• Monitors
• Film digitizers
• Storage servers / RAID
• CD-R drives
• …and Photoshop
DICOM File Format
• Header and image data stored in the same
file so the important info can’t be lost
• Stores hundreds of pieces of data about
the patient, machine, and data acquisition
• Implemented by the manufacturers
• Supports one slice per file (although there
are some work-arounds for that)
Everything has a Tag
• Each data field has a unique tag or key
• Tags are two 4 digit hexadecimal numbers
• Length of the field is stored after the tag
– Allows header fields to be of variable length
• AAPM’s image on tape format used
variable length header tags identified by
tags
One Big Header
• Even the image data has a tag (7fe0
0010) and is part of the header.
• It’s usually the last element in the header.
– Causes trouble for .des files and some image
readers when there is data after the image
Entirely Variable
• Each header field is of variable length
• Fields are generally optional
• You never know what fields will be
there
• Headers have to be read sequentially
• Makes coding DICOM support full of
surprises
Tag Groups
• Tags are organized into groups by type
• The tag groups have their own tags which
end in 0000, like “0002 0000” which gives
general information on the “0002” group
like the length of all elements combined
• All of the tags in the same group have the
first 4 digits in common
Important Tags
• Session Name & Study Number
– (0008 0090) ID Referring Physician
– (0020 0011) REL Series Number
• Image “Shape”
– (0028 0010)
– (0028 0011)
– (0028 0030)
– (0018 0050)
– (0020 1041)
IMG Rows
IMG Columns
IMG Pixel Spacing
ACQ Slice Thickness
REL Slice Location
Important Tags (cont.)
• How & where the image data is stored
– (0028 0100)
– (0028 0101)
– (0028 0102)
– (7ef0 0010)
IMG Bits Allocated
IMG Bits Stored
IMG High Bit
PXL Pixel Data
MRI specific tags
•
•
•
•
•
MR Acquisition Type (0018, 0023)
Repetition time (0018, 0080)
Echo time (0018, 0081)
Echo numbers (0018, 0086)
Magnetic field strength (0018, 0087)
PET specific tags
•
•
•
•
Radiopharmaceutical (0018, 0031)
Counts Accumulated (0018, 0070)
Syringe Counts (0018, 1045)
Radiopharmaceutical Route, Volume, Start
time, Stop time, Total dose, Half life (0018,
1070) through (0018, 1075)
Display Tags
• Window Center & Width (comparable to
brightness & contrast)
• Particularly important for X-Ray & PET
with consistently calibrated intensities
• Also important for DICOM supporting
monitors and film printers, etc
Patient Information
•
•
•
•
•
•
•
Birth time (0010, 0032)
Weight (0010, 1030)
Mother’s Birth Name (0010, 1060)
Military Rank (0010, 1080)
Smoking status (0010, 21A0)
Religious Preference (0010, 21F0)
Breed Description (0010, 2292)
The Whole Standard Overview
•
•
•
•
•
•
•
•
3.1 Introduction & Overview
3.2 Conformance
3.3 Information Object Definitions
3.4 Service Class Specifications
3.5 Data Structure and Encoding
3.6 Data Dictionary
3.7 Message Exchange
3.8 Network Communication Support for
Message Exchange
…continued
• 3.10 Media Storage and File Format for
Data Interchange
• 3.11 Media storage Application Profiles
• 3.12 Storage Functions and Media
Formats for Data Interchange
• 3.14 Grayscale Standard Display Function
• 3.15 Security and System Management
Profiles
• 3.16 Content Mapping Resource
• 3.17 Explanatory Information
• 3.18 Web Access to DICOM Persistant
Objects (WADO)
“DICOM is a complex standard
because of the size of its
content”
http://www.dicomanalyser.co.uk/html/introduction.htm
Message Exchange (Part 3.7)
• C-ECHO
– “ping”, a command sent only to get a
response
• C-STORE
– Instruction to archive data sent from console
• C-GET, C-MOVE, C-FIND, N-GET,
SET, N-ACTION, N-CREATE,
N-DELETE
N-
– Commands that search or retrieve data that
we don’t support at the RIC
How do we support so few?
• The DICOM Server we run is relatively
simple - It only accepts data and puts it in
one permanent location. Other servers
support moving, deleting, etc. Our data
stays put. It is not retrieved via the
DICOM server, but using get_mri, get_pet,
get_icbm, etc…
Network Communication Support
(Part 3.8)
• This is the new & exciting part that was
added to version 3 of the standard in 1993
• Based on TCP/IP Network Protocol
Association & Request
• “Association” - the connection used to
send commands across the network
• 1st data sent is the “request”
– sent from client to server
– Contains calling title and called title
Response
• 2nd, the server prepares a “response”
– Sent from server to client
– based on the request, the types of data the
server is prepared to accept, the calling title
and the called title and a few other settings.
• The response can be an acknowledge or a
reject. If the request is not understood or
can not be properly answered, it’s rejected.
Result
• Sent from client to server
• “Abort”
– Something broke. Stop now.
• “Release Request”
– I have finished communicating. Stop now.
• “PData PDU”
– I’m ready to send data. Keep the association
up and running.
Result (continued)
• If the association is kept, get more data
from the result first.
• SOP Class - the type of data being sent
(CT, PET, MRI, etc)
• SOP Class Instance UID - a unique
identifier for this data
• Message ID - defines this round of
messages (request, response, result)
Problems
• Large complex format -> difficult to
implement support
• Each implementation has a different level
of completeness -> difficult to predict
which tags and services will be available
• Most scanners add custom proprietary
tags to the header -> difficult to interpret
• One slice per file is lame
Mango
•
•
•
•
•
Spike & I worked on the DICOM support
It’s read-only, but can save as other formats
Open -> “Open DICOM Folder…”
File -> Image Info -> Format Specific
Command Line Tools
– convert2avw, convert2des, convert2nii &
imageinfo should all work with DICOM
RIC Specific
• Our MRI scanners use DICOM images
• MRI Transfer Logs
– http://ric.uthscsa.edu/scanner.html
• get_mri
– interactive command line tool
• We almost always add a .des file to make
reading DICOM files easier & reliable
• Recently, DICOM files are being converted
to NIfTI instead
Random DICOM Tools
http://sourceforge.net/projects/irad/
• jDicomX
– Open source package
– Originally based on code from Tiani
– Java based, multi-platform
– can be run in a web page
• iRad
– Mac OS X only (made to be native & pretty)
– Same code base as jDicomX (so also free)
jDicomX - StorageSCU
jDicomX - StorageSCU
jDicomX - BrowseDicomSR
jDicomX - BrowseDicomSR
jDicomX - EditDicomObj
Useful Links
•
•
•
•
medical.nema.org – Official Site
rsna.org/Technology/DICOM
Wikipedia.org/DICOM
Extensive history of DICOM
– http://www.dicom-analyser.co.uk/html/introduction.htm
• Some Guy’s Introduction to DICOM
– http://www.sph.sc.edu/comd/rorden/dicom.html