Previous Lesson Complete and Continue  

  Configure the PACS to accept images from the CT

Configure the Modality AET and Port

Choose an AET

It’s crucial to assign a DICOM Application Entity Title (AET) that follows the hospital’s naming conventions. The AET is a unique identifier used by devices in the DICOM network to communicate with each other, and consistency is key for easy identification and troubleshooting. Keep in mind that AETs are case-sensitive and typically have a character limit of 16 characters. Any mismatch in the AET can cause communication issues between the modality and PACS, so ensuring it aligns with established conventions is essential for smooth operation.

Choose the Port

The DICOM port number is another important configuration, and it must be set correctly to enable communication. The standard DICOM port is 104, though some systems might use a different port as specified in their DICOM conformance statement. The preferred port number for a modality or PACS is usually listed in the DICOM conformance document, and setting the correct port ensures proper communication between devices.





Configure the PACS to Accept Storage

Add the CT to PACS

Now that you have chosen an AET and Port for your new modality, you can add it as a known entity in the PACS storage settings.

The CT must be added as a node in the PACS because it enables the PACS to recognize and accept incoming DICOM images from the CT modality. That way the system knows where the images are coming from and can verify the source before accepting the data. Without this configuration, the PACS won’t recognize the CT modality’s attempts to send images, leading to failed DICOM associations and preventing the images from being stored. Add the CT as a SCU of the C-Store operation.

C-Store?

C-STORE (Composite Store) is a DICOM service used to transmit medical images or related data from one system (typically a modality like CT, MRI, or ultrasound) to another system (such as a PACS). It allows a Service Class User (SCU)—the system sending the data—to transfer DICOM objects (like images) to a Service Class Provider (SCP)—the system receiving and storing the data.

For example, in the context of a CT modality sending images to a PACS, the CT acts as the SCU and uses the C-STORE operation to push the images to the PACS, which is the SCP. The PACS then stores the images for later retrieval and review.

SCU?

In DICOM, the terms Service Class Provider (SCP) and Service Class User (SCU) define roles in communication:

  • The SCU initiates the communication and sends data.
  • The SCP receives the data and provides the service requested.

In terms of storage, the new CT modality acts as the SCU, meaning it sends images to the PACS. The PACS acts as the SCP, receiving and storing the images sent from the modality.

Referring back to the DICOM conformance statement we drafted for you, it lists CT Image Storage SOP Class as supported by both the CT modality and PACS. This means the CT modality, acting as the SCU, will initiate the image transfer, and the PACS, acting as the SCP, will store the images. This relationship is key to ensuring that images generated by the modality are transmitted and archived successfully in the PACS without disruption.

In the exercise below, try to add the CT modality as an authorized node for storage like you did in the earlier lesson. But this time, use verbose mode to view live logs in the process.

DICOM Lab
Local SCP Settings (Listener)
Authorized SCU Node (Remote AE)
Authorized Nodes
USPROD (192.168.1.10 : 104) CONNECTED
Complete and Continue