1. “The Language of Medical Equipment”
DICOM
“The Language of Medical Equipment”
Mick Fox

2. 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)
Apparently in the early 1980s it was very hard for people other than the manufacturers to “decode” the images from CT and MRI scanners. Each manufacturer probably used their own file format.

3. Brought To You By: ACR: NEMA: AAPM: RSNA:
American College of Radiology
NEMA:
National Electrical Manufacturers Association
AAPM:
American Association of Physicists in Medicine
RSNA:
Radiological Society of North America
Radiologists, Physicists & Manufacturers, OH MY!

4. 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
The history of this sounds a bit bitter. They all state rather bluntly that the 1985 and 1988 versions “had errors”, “was clear improvements were needed” and “the text was vague and had internal inconsistencies.”
First version (ACR-NEMA ) was distributed in 1985 with “some errors”.
The revision published in 1988 had few new features and just focused on corrections.
The third version was renamed DICOM with hopes of greater acceptance. Especially internationally (removed America from the acronym)
The improved network support changed it from a point to point network to being built on top of TCP/IP (the standard internet-y protocol)
Add history from DicomSlides?

5. 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…
Some of the imaging modalities are no longer supported (“retired”)
As in spectroscopy, which was supported until 2008

6. Devices with DICOM Support
Searching Google for DICOM support I found:
Printers
Projectors
Monitors
Film digitizers
Storage servers / RAID
CD-R drives
…and Photoshop
Monitors were the fancy ones, like those that light up X-Rays

7. 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)
The one slice per file seems like a film hold-over
Talk about Siemen’s “mosaic” work around
- they store many slices in one image
- they store all the extra info shoved into one proprietary tag
- move this to “problems” section?

8. 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

9. 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

10. 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

11. Tag Groups Tags are organized into groups by type
The tag groups have their own tags which end in 0000, like “ ” 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
See group 6 for these:
Groups I could find:
0002 – meta
0008 – identifying information (institution name)
0010 – patient info (age, weight, name, breed)
0012 – clinical trial info
0018 – acquisition data, imager spacing, detector element spacing, protocol name
0020 – orientation & position, position in series
0022 – light & eye movement & pupils
0028 – image shape (rows, columns, bits, etc)
0032 – requested procedure
0038 – special needs & state (wheelchair, oxygen, comatose, vision impared, etc)
003A – waveforms
0040 – other person (console operator, health care worker)
0042 – referenced documents
0050 – calibration
0054 – energy windows and detectors & phases & counts & dose (pet?)
0060 – histogram
0062 – segmentation & algorithm used
0064 – grid deformation
0070 – presentation info (monitors)
0072 –
0074 – beam order & exposure (xray?)
0088 – storage medium
0400 – encryption & network info
1000 – compression
2000 – medium type
2010 – printer info, film size
2100 – number of films printed

12. Important Tags Session Name & Study Number Image “Shape”
( ) ID Referring Physician
( ) REL Series Number
Image “Shape”
( ) IMG Rows
( ) IMG Columns
( ) IMG Pixel Spacing
( ) ACQ Slice Thickness
( ) REL Slice Location

13. Important Tags (cont.) How & where the image data is stored
( ) IMG Bits Allocated
( ) IMG Bits Stored
( ) IMG High Bit
(7ef ) PXL Pixel Data

14. 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)

15. 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)

16. 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

17. 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)

18. 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

19. …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)

20. “DICOM is a complex standard because of the size of its content”

21. 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, N-SET, N-ACTION, N-CREATE, N-DELETE
Commands that search or retrieve data that we don’t support at the RIC
Command - a request to operate on information from across the network

22. 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…

23. 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

24. 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
0) Association - a connection or socket, used to send commands over
Describe how the server sits and waits for a client to call
Telephone metaphor?
1) Receive initial request over association
Define calling titles (allowed consoles) and called title (this server)

25. 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.

26. Result Sent from client to server “Abort” “Release Request”
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.
Point out that “stop now” means breaking the association

27. 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)
SOP Class can also be “verification” for the C-ECHOs
SOP Class UID allows me to check if the data has been sent already.
Multiple results can be sent?
Multiple <something> can be sent - the message id makes it clear
Which requests / response / results match up.

28. 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
Problems
as such, generally a read-only format (there’s no “Save As DICOM”)
one file per slice, no volume support (hacked in by “mosaic format”)
Includes Proprietary Tags & Data too:
* show some Siemens specific tags?

29. 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
Add a screenshot of something?
The “Format Specific” section of “Get Info”?
Mango doesn’t have a “save as dicom” option
List Mango as the DICOM tool of choice to replace these slides:
* create_des is given a list of files or a directory, reads each one, creates a .des file (our standard)
* dump_dcm_file (& my new version) shows header
* dump_mosaic, Siemens Trio 3T machine has extra header info, show text

31. RIC Specific Our MRI scanners use DICOM images MRI Transfer Logs
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
How We Do
Network: simple servers with only “store”
“read-only”: we use .des and/or convert to NIfTI
At the RIC, only our MRI are DICOM files.
We've gotten PET from other places

32. Random DICOM Tools jDicomX iRad Open source package
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)

33. jDicomX - StorageSCU The client that sends data to the server
I use it for testing & debugging
Chris Cook uses it for real work

34. jDicomX - StorageSCU The client that sends data to the server
I use it for testing & debugging
Chris Cook uses it for real work

35. jDicomX - BrowseDicomSR

36. jDicomX - BrowseDicomSR

37. jDicomX - EditDicomObj

38. Useful Links medical.nema.org – Official Site
rsna.org/Technology/DICOM
Wikipedia.org/DICOM
Extensive history of DICOM
Some Guy’s Introduction to DICOM