An Introduction to DICOM (Digital Imaging and Communications in Medicine)

Click image to zoom

DICOM is a Standard for Digital Imaging and Communications in Medicine. The DICOM Standard specifies a diverse set of information about patients, imaging equipment, procedures, and images. DICOM is hierarchically structured and has a Client-Server architecture. It has the following parts:

• File/data format
• Data interchange protocol
• Network protocol architecture

Basic Knowledge About the DICOM Protocol

At it's simplest, DICOM is a protocol for dealing with medical images (X-Rays, MRIs, etc). If you're diving into DICOM, there are a few things you should know right from the start that will make your life a lot easier. I'll outline some of these basic facts here, then dig deeper later on in the post:

1. DICOM files typically have a .dcm extension and data contains both patient data and the image/pixel data.The patient data comes from the EMR/EHR/HIS systems as HL7 data which gets tightly coupled with the equipment, procedures and image/pixel data created by the radiology medical imaging devices as DICOM data.
2. The DICOM protocol is a binary Upper Level Protocol (ULP) over TCP/IP. Well known ports used by DICOM are 104, 2761, 2762 and 11112. It is used to process DICOM data, transmit, search/query, integrate, distribute, print, share, store, display medical images and patient data from the radiology archival/storage systems (PACS, RIS) to the workstation for the Radiologist to write reports.
3. The DICOM Network Protocol architecture looks something like this: Network ⇒ TCP/IP ⇒ DICOM ULP for TCP/IP ⇒ UL Service boundary ⇒ DICOM Message Exchange ⇒ Medical Imaging Application.

Why Does DICOM Matter?

Medical imaging is the fastest growing and most profitable segment of healthcare. DICOM has an ever increasing need for network bandwidth, system performance and support for many diverse medical devices.

Currently there are limited tools available to diagnose the patient data, DICOM and network protocol problems. ExtraHop can help!

How Can ExtraHop Help with DICOM Monitoring?

DICOM, HL7 data and network are crucial to the healthcare industry. As of version 5.2.2 ExtraHop has added support for DICOM. ExtraHop already had support for HL7 and many of the network protocols in previous versions.

ExtraHop has the huge advantage of having the ability to extract meaningful insights from HL7 i.e. patient data, DICOM and other network messages in real-time!

Now we get to explore many aspects of DICOM workflows and monitor DICOM. We want to see how we can help the different departments in healthcare like radiology, IT, support etc. in pinpointing the underlying problems with DICOM from multiple angles.

The History of DICOM

DICOM is a standard developed by the American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA). It started in the 1980s and in 1988 the second version was released. The first large-scale deployment of ACR/NEMA technology was made in 1992 by the US Army and Air Force. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying the first US military PACS (Picture Archiving and Communications System). In 1993 the third version of the standard was released. Its name was then changed to "DICOM." New service classes were defined, network support was added and the Conformance Statement was introduced to establish the basic DICOM communication protocols for query or retrieval, storage and print classes. Officially, the latest version of the standard is still 3.0, it has been constantly updated and extended since 1993.

Where and How Is DICOM Used?

DICOM is used extensively for medical imaging in hospitals. It is used in the processes of diagnosing and treating patients, tracking patient outcomes and scheduling procedures, ICD-10 coding, billing and teleradiology to transmit radiological patient images, such as X-rays, CTs, and MRIs, these are the different modalities, from one location to another for the purposes of sharing studies with other radiologists and physicians.

An examination number is generated prior to imaging when the order is created to synchronize image transfer to PACS using PACS ID and/or RIS using an accession number which links the radiology reports to a specific image study. The accession number is usually assigned by the HIS/RIS system and can be repeating or unique depending on the system.

Managing the modality worklist is a process used to reduce manual data entry errors and increase fidelity of patient information into the PACS/RIS imaging console.

Basic Structures and Concepts in DICOM

1. DICOM Objects are known as the Information Object Definitions (IOD). All real world data like patients, studies, medical devices, images, patient schedule list, a queue to be sent to a printer are objects with defined templates. These are definitions of the information to be exchanged between a Service Class User (SCU) - Client and Service Class Provider (SCP) - Server.
2. A DICOM modality is a property/attribute of the DICOM data object, e.g. CT, MRI, X-rays etc. are the modalities
3. A DICOM Message is composed of a Command Set followed by a conditional Data Set.
4. Command and Data sets are made of Elements.
5. Elements have a Tag, length and value.
6. Tags have group tag and element tag.
7. DICOM applications provide the services required for the data exchange.
8. DICOM Service Element (DIMSE) are used by Application Entities (AE).
9. There are two types of DIMSE Services, Composite DIMSE-C and Normalized DIMSE-N. These support operations and notifications like storage, retrieval, printing etc. on the SOP instances.
10. AEs have Titles (AET). AE has an IP address assigned. AET are case sensitive and unique.
11. Service Object Pairs (SOPs) have an unique ID (UID). SOP Classes are the fundamental unit of DICOM interoperability.

Click image to zoom

Click image to zoom

How does the DICOM transaction happen?

1. AE of SCU - Client uses DIMSE to negotiate a SOP Class with the AE of SCP - Server using it's DIMSE. There are DIMSE protocols defining the procedures and encoding rules to construct messages.
2. Message transactions between the two devices using DICOM begin with an Association establishment. Both devices negotiate the information structures that will be exchanged, the services that will be invoked, byte order and data compression method.
3. DICOM ULP consists of seven Protocol Data Units (PDUs). Each PDU has a maximum length. PDUs are the message formats exchanged between peer entities within a layer, based on the request and the response DICOM messages.

What Is Next for DICOM?

DICOM is very complex protocol with a lot of documents written by NEMA defining the DICOM standard. ExtraHop has recently added support for DICOM in version 5.2.2 which opens up many different possibilities.

I am very excited about it since DICOM provides us one more piece of the complex healthcare workflows giving deep insight into healthcare data and network issues.

Currently we are in an exploratory mode to figure out even more meaningful insights we can get from DICOM data using ExtraHop. The possibilities are endless, especially since we can correlate DICOM data with HL7 data and network protocols for a complete picture of this crucial, profitable part of the healthcare technology environment.

Stay tuned for more blogs on DICOM in the future. For now, check out Six Ways ExtraHop Enables Real-Time Healthcare Systems