“The Language of Medical Equipment” 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) 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.

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!

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 300-1985) 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?

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

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

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?

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

Important Tags Session Name & Study Number Image “Shape” (0008 0090) ID Referring Physician (0020 0011) REL Series Number Image “Shape” (0028 0010) IMG Rows (0028 0011) IMG Columns (0028 0030) IMG Pixel Spacing (0018 0050) ACQ Slice Thickness (0020 1041) REL Slice Location

Important Tags (cont.) How & where the image data is stored (0028 0100) IMG Bits Allocated (0028 0101) IMG Bits Stored (0028 0102) IMG High Bit (7ef0 0010) 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.dicom-analyser.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, 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

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

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” “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

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.

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?

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

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

Random DICOM Tools jDicomX iRad Open source package 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 The client that sends data to the server I use it for testing & debugging Chris Cook uses it for real work

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

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 http://groups.google.com/groups?group=comp.protocols.dicom&hl=en