Your SlideShare is downloading. ×
DICOM_2008.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

DICOM_2008.ppt

643
views

Published on

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
643
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.
  • Radiologists, Physicists & Manufacturers, OH MY!
  • 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?
  • Some of the imaging modalities are no longer supported (“retired”)
    As in spectroscopy, which was supported until 2008
  • Monitors were the fancy ones, like those that light up X-Rays
  • 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?
  • 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
  • Command - a request to operate on information from across the network
  • 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)
  • Point out that “stop now” means breaking the association
  • 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
    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?
  • 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
  • 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
  • The client that sends data to the server
    I use it for testing & debugging
    Chris Cook uses it for real work
  • The client that sends data to the server
    I use it for testing & debugging
    Chris Cook uses it for real work
  • http://groups.google.com/groups?group=comp.protocols.dicom&hl=en
  • Transcript

    • 1. 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)
    • 3. 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
    • 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
    • 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…
    • 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
    • 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)
    • 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 “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
    • 12. Important Tags • Session Name & Study Number – (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
    • 13. 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
    • 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” http://www.dicom- analyser.co.uk/html/introduction.htm
    • 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
    • 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
    • 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” – 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.
    • 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)
    • 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
    • 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
    • 30. 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
    • 31. Random DICOM Tools • 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) http://sourceforge.net/projects/irad/
    • 32. jDicomX - StorageSCU
    • 33. jDicomX - StorageSCU
    • 34. jDicomX - BrowseDicomSR
    • 35. jDicomX - BrowseDicomSR
    • 36. jDicomX - EditDicomObj
    • 37. 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