[et_pb_section admin_label=”section” transparent_background=”off” background_color=”#ffffff” allow_player_pause=”off” inner_shadow=”off” parallax=”off” parallax_method=”off” padding_mobile=”off” make_fullwidth=”off” use_custom_width=”off” width_unit=”on” make_equal=”off” use_custom_gutter=”off”][et_pb_row admin_label=”row”][et_pb_column type=”4_4″][et_pb_text admin_label=”Text” background_layout=”light” text_orientation=”left” use_border_color=”off” border_color=”#ffffff” border_style=”solid”]
Welcome to the new column committed to Digital Imaging and Communications in Medicine (DICOM). DICOM is the openly shared protocol to enable communication among OEM diagnostic imaging players. The DICOM spec is humongous in an attempt to clarify all the grim details of multi-OEM DI communication. This column intends to unravel the aspects of what makes DICOM work. One of the biggest barriers is the terminology. However, like most application and network terminology, once defined it becomes obvious as to what it’s all about.
My plan is to describe the various aspects, functions and terminology of DICOM. Also, I plan to cover common DICOM processes like the all-important association process between DICOM network nodes. Finally, methods will be discussed to help with system troubleshooting by becoming a DICOM node and packet analysis.
DICOM Background and Intent
DICOM is huge. It is comprised of 18 sections out of the original 20 (see sidebar). Please note that sections 9 and 13 are missing. They have been retired as they referred to point-to-point wiring before network communication came along. All of the sections are freely available at http://dicom.nema.org/. Click on “The DICOM Standard” under the menu box labeled “Products.” Once there, you’ll see a list of the 18 sections, each available for free download in various formats. Most are good remedies for insomnia!
Each section is a separate document with its own rev level. Some are quite long like PS 3.3 Information Object Definitions with more than 1,600 pages. Specifically, the DICOM Standard specifies a non-proprietary data interchange protocol, digital image format and file structure for images and image-related information. For example, the PACS (Picture Archival & Communication System) accepts any image in DICOM format.
DICOM addresses five general application areas: network image management, network image interpretation management, network print management, imaging procedure management and off-line storage media management. Much of this must be arranged between two DICOM nodes prior to communication. The association process does a bunch of handshaking to ensure all the details such as image type, image resolution, gray scale used, and image compression type (if any) are fully understood for best results.
Again, the main objective is to facilitate communication and interoperability. DICOM addresses all of the technical aspects necessary to allow complying OEMs to be understood by such entities as hospital information systems.
Some upcoming topics include:
DICOM and clinical data
• Basic DICOM terminology
• DICOM data dictionary
• DICOM objects
• DICOM information hierarchy
DICOM configuration concepts
• Processes such as the UID, IOD that help identify individual DICOM aspects
• The conformance statement – how OEMs divulge what portions of DICOM they adhere to
• DICOM Service Object Pairs (SOPs)
• DICOM value representations
• DICOM association process
DICOM media and security
• DICOM file formats
• Sharing DICOM data in PACS
• DICOM security
• Abstract syntax
• Transfer syntax
• Protocol data units (PDUs)
• Application context
• Presentation context
• User Information
Welcome to our journey through the DICOM standard. Once we gain an understanding of how DICOM approaches the communication of diagnostic imaging, we can start to poke into DICOM packets via a packet sniffer, how to set up a computer as a DICOM node, and how to better understand the communication process with tips on how to troubleshoot issues. ICE