Healthcare’s anatomy:
The DICOM protocol

Introduction


The first episode of this series on medical protocols highlighted the HL7 protocol, a key method for transmitting health data that allows quick exchange and aggregation of patient information. However, protocols specific to the medical field are not limited to the exchange of medical records. Some, like DICOM, enable the transmission of medical imaging.

Healthcare’s Anatomy: Scanning the DICOM Protocol


DICOM (Digital Imaging and Communications in Medicine) is an international standard protocol based on TCP/IP, typically exposed on port 104. It is also a file standard created in 1985 in the United States by the American College of Radiology. DICOM facilitates the sharing of patient data, examinations, and reports.

It is used both internally within healthcare facilities and between different medical entities, such as between a radiology clinic and a hospital. From dental offices to private clinics to university hospitals, all imaging exchanges rely on DICOM. This widespread use sometimes results in some PACS/DICOM servers being exposed online. A PACS server (Picture Archiving and Communication System) is a medical imaging storage server that supports several imaging standards, including DICOM. To highlight the issue of exposing services on the web, it’s important to understand that any workstation capable of DICOM exchange can interact with an exposed PACS server if it is not properly secured.

Imaging Modalities and PACS Servers: DICOM Exchanges in a Medical Information System


After introducing the concept of a PACS server, it is important to explain DICOM exchanges between the imaging storage service and the devices that produce these images.

Like HL7, DICOM is characterized by a large number of standardized messages. Before detailing them, it is essential to define the terms “device” and “Service Class.”

In the DICOM context, a device refers to any equipment or terminal that exchanges data using this protocol. Therefore, a PACS server is a device, as a workstation is, scanner, or imaging printer. A Service Class corresponds to a specific action performed on medical imaging data.

Service Classes

Each Service Class contains a predefined number of messages. There are 13 specific classes:

  • Storage Service Class: Related to the storage actions of DICOM objects, such as images, structured reports, presentation documents, etc. Associated message type: C-STORE.
  • Query/Retrieve Service Class: Related to the search and retrieval actions of DICOM objects stored on a server. Associated message types: C-FIND, C-MOVE, C-GET.
  • Worklist Management Service Class: Related to managing worklists for imaging modalities (scanners, MRIs, and other acquisition tools), facilitating the planned acquisition of images. Associated message type: C-FIND.
  • Modality Performed Procedure Step (MPPS) Service Class: Related to monitoring the status and results of procedures performed by imaging modalities. Associated message types: N-CREATE, N-SET.
  • Print Management Service Class: Related to managing the printing of images on DICOM-compatible printers. Associated message types: N-CREATE, N-DELETE, N-ACTION, N-EVENT-REPORT.
  • Storage Commitment Service Class: Related to confirming the permanent storage of DICOM objects on a PACS server. Associated message types: N-ACTION, N-EVENT-REPORT.
  • Media Storage Service Class: Related to managing the storage and retrieval of DICOM objects on removable media (CD, DVD, etc.).
  • Presentation State Service Class: Related to storing and retrieving image presentation information (such as annotations and window arrangements). Associated message type: C-STORE.
  • Verification Service Class: Related to verifying connectivity between DICOM devices. Message type: C-ECHO.
  • Structured Reporting (SR) Service Class: Related to creating, storing, and retrieving DICOM structured reports. Message type: C-STORE.
  • Relevant Patient Information Query Service Class: Related to searching for relevant patient information for a given procedure. Message type: C-FIND.
  • Unified Procedure Step (UPS) Service Class: Related to managing and coordinating steps of medical procedures across different systems. Message types: N-CREATE, N-SET, N-GET, N-ACTION, N-EVENT-REPORT.
  • Workflow Management Service Class: Related to managing medical procedure workflows. Message types: MWL, MPPS, UPS.

 

DICOM Message Types Used in Service Classes

After defining the term “Service Class” and highlighting the different possible messages within these classes, it is necessary to detail the types of messages in DICOM. Here is a description of the various possible operations in DICOM:

  • A-ASSOCIATE (Verification Service Class): Establishes an association between two DICOM entities. A DICOM association is a network connection that allows entities to communicate and exchange DICOM data.
  • C-STORE (Composite Storage Service Class): Allows sending DICOM objects (images, reports, etc.) to a PACS server.
  • C-FIND (Query/Retrieve Service Class): Allows searching for information in a DICOM database.
  • C-MOVE (Query/Retrieve Service Class) and C-GET (Query/Retrieve Service Class): Allow moving DICOM objects from one device to another. The difference lies in the use case: C-MOVE is used to transfer an object between a storage server and a workstation, while C-GET is used to extract raw data from a storage server or workstation.
  • C-ECHO (Verification Service Class): Validates communication between DICOM devices.
  • N-EVENT-REPORT (Notification Service Class): Allows a device to inform another device of a particular event, such as the completion of a task or the reception of a new image.
  • N-GET (Normalized Service Class): Retrieves attributes of a specific DICOM object.
  • N-SET (Normalized Service Class): Modifies attributes of a DICOM object.
  • N-CREATE (Normalized Service Class): Creates a new DICOM object on a server.
  • N-DELETE (Normalized Service Class): Deletes an existing DICOM object.
  • Modality Worklist (MWL): Allows modalities (imaging devices) to retrieve a list of scheduled tasks.
  • Modality Performed Procedure Step (MPPS): Communicates the progress status of procedures performed by the modalities.

Workflow Examples


To better understand these concepts, here are two concrete examples illustrating workflows. The first example focuses on the association between two DICOM devices, while the second describes the exchanges carried out during an examination.

 

Association entre deux appareils DICOM :

Before describing the association steps, it is necessary to define the term AE-title. An AE-title (Application Entity Title) is a unique identifier used in DICOM communications to uniquely identify an application or device (such as a scanner, workstation, or PACS server) on a network.

Lab Dicom Image1 Schéma De L’association Entre Un Scanner Et Un Serveur Pacs
Image 1: Diagram of the Association Between a Scanner and a PACS Server

 

In this scenario, the MRI scanner sends an association request to the PACS server, which responds to either accept or reject this request. Once accepted, the devices communicate via standard DICOM commands such as C-ECHO (verification), C-STORE (image storage), and C-FIND/C-MOVE/C-GET (search/retrieval). After communication, the scanner sends an association release request, confirmed by the server, thus ending the exchange. Here is a concrete example of this type of exchange:

Lab Dicom Image2 Exemple D’un échange Complet Utilisant Des C Find Avec Un Serveur Pacs
Image 2: Example of a Complete Exchange Using C-FIND with a PACS Server

 

Exchange During an Examination

In the second example, the steps performed are as follows: acquisition, storage, and retrieval of information related to an X-ray. At each exchange phase (a request/response), the PACS server, the imaging modality, and the workstation initiate an association phase before sending the commands to be executed and end with a ‘release’ message after receiving the data.

Lab Dicom Image3 Workflow De L’acquisition D’images D’un Serveur Pacs
Image 3 : Workflow De L’acquisition D’images D’un Serveur Pacs

 

It all begins with image acquisition, followed by a request for the list of scheduled tasks from the Worklist server. The images are then sent to the PACS for storage, with confirmation of receipt. The modality then informs the PACS of the completion of the acquisition. The workstation subsequently queries the PACS to obtain specific images, retrieves them, and displays them after transfer from the PACS.

Conclusion


Throughout this article, the various elements constituting the DICOM protocol have been described. To better understand the functioning and use of this protocol, two practical cases were presented: the association between two devices and the exchanges during an examination. However, the risks associated with this protocol have not yet been discussed. In the next article, the risks and possible attacks related to the DICOM protocol will be examined.

 

 

Authors: Gatewatcher Purple Team and 0xSeeker