A Step by Step Guide

Imagine your hospital just acquired a brand-new multislice CT scanner, and the radiologists are excited about the potential for faster scans and higher-resolution images. But before the scanner can start contributing to patient care, it must be properly integrated into your hospital’s PACS. As a PACS administrator, your task is to ensure the modality is configured according to DICOM standards, including setting up the AE Title, IP address, and port number, and verifying communication through DICOM validation steps.

This guide will take you through the installation process, focusing on DICOM-specific tasks, while also emphasizing collaboration with various teams like the modality vendor, PACS team, RIS team, networking team, and biomed team. Although this example is for a CT modality, the following guide can apply to any radiology modality including MR, US, XR, PET, NM, etc.

1. Gathering Contacts and Initial Planning

The first step is gathering all relevant contacts and planning the installation. The PACS Team typically leads this, but it requires collaboration with several stakeholders:

• Modality vendor (field engineer) who is responsible for the modality setup
• Networking team for network configuration
• RIS or EMR team for Modality Worklist (MWL) configuration
• Biomed team if they are involved in physical setup
• IT Security for security review or antivirus installation

Communication between these teams is critical to avoid delays. If your institution’s Modality Worklist (MWL) is managed by another team, such as the RIS or EMR team, place a request to ensure the new modality can retrieve worklists.

Start the request for the IT security team to review the modality documentation. The security team typically reviews the modality to ensure it adheres to all hospital security policies, including data protection and network safety standards. If the modality runs on a Windows platform, antivirus software may need to be installed, and the device added to the hospital’s domain. Also, see if the antivirus (AV) software conflicts or disrupts the modality during scanning. Ask the vendor if the security team needs to place exceptions on the AV software. Facilitate any necessary meetings between the vendor and your IT security team if needed. Start this process early to avoid delays. 

The biomed team is typically responsible for safety, maintenance and calibration of the modality. They perform testing to verify that the scanner is safe for patient and staff use, following protocols that minimize electrical hazards. The biomed team ensures that the CT modality complies with health regulations, radiation safety standards, and manufacturer recommendations They will place service desk labels on the modality to help identify it for future troubleshooting or service needs.

2. DICOM Conformance Review

Before configuration, it’s essential to review the DICOM conformance statements for both the modality and PACS. These documents define which SOP classes the modality supports for image storage and query/retrieve functions.

For example, the modality must support the CT Image Storage SOP Class to send images to the PACS. Compare these supported SOP classes with those listed in the PACS’s DICOM conformance statement to ensure compatibility. If you find any discrepancies, work with the modality vendor to adjust the configuration and ensure the SOP classes align correctly.

This early review ensures the new modality can send images and retrieve them from the PACS in compliance with DICOM standards.

3. AE Title, IP Address, and Port Configuration

In DICOM, three essential pieces of information are required to establish communication between a modality and the PACS:

• AE Title (Application Entity Title): This is the unique identifier for the modality within the DICOM network. It ensures that the modality can be recognized and communicate with other devices, such as the PACS. AE Titles are case-sensitive, and the naming convention should follow your hospital’s standard (e.g., CTPROD5).
• IP Address: This is the network address assigned to the modality, allowing it to communicate over the hospital network. A static IP is crucial to ensure consistent connectivity between the modality and PACS.
• Port Number: This defines the specific communication port used for sending and receiving DICOM data (e.g., images and queries) between devices. Each modality and server will use specific port numbers to ensure data is sent to the right destination.

Static IP vs. DHCP

A static IP is a fixed IP address that does not change over time, ensuring that the modality can always communicate with the PACS using the same network identifier. This is essential for DICOM connections, as any change in the IP address would break the communication between the modality and PACS.

In contrast, DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses to devices on a network. DHCP is the default setting for most network interface cards (NIC). While DHCP is useful for devices that don’t need permanent IP addresses, using DHCP for a modality can cause issues. If the IP address of the modality changes due to DHCP, the PACS won’t be able to recognize or communicate with the modality, leading to failed DICOM associations and disruptions in image transmission. For this reason, it’s important to use a static IP for any PACS-connected modality to ensure consistent and reliable communication.

4. Building in PACS and RIS Systems

After configuring the AE Title, IP address, and port, the next step is to integrate the modality with the hospital’s RIS system for worklist retrieval. In most healthcare systems, there are two environments available. A Production environment with live patient data and a Test environment with fake data which is helpful for testing. Be sure to configure your new modality to the Test environment first. 

MWL Configuration
The Modality Worklist is a DICOM service class that allows the modality to automatically retrieve scheduled patient studies from a Modality Worklist Service Class Provider (MWL SCP). The MWL SCP is typically the RIS or EMR system that manages patient schedules and sends them to the modality for accurate exam data entry, reducing manual input and ensuring patient safety.

When a referring physician places a CT exam order in the EMR, it uses HL7 (Health Level 7) messaging to send the order to the RIS (or whatever system serves as the MWL provider). The HL7 order typically includes details like patient information, the requested exam, and scheduling data. The RIS then converts this HL7 order into a DICOM MWL entry that the modality can pull using the Modality Worklist Service Class. This seamless conversion and transmission from HL7 to DICOM is key to ensuring the CT scanner has accurate and up-to-date information for each scheduled patient.

The RIS or EMR team will handle the Modality Worklist (MWL) setup if they manage the worklist provider. If the RIS or EMR team is unable to assist, the PACS team can use a MWL emulator to simulate test orders and validate the modality’s ability to pull patient schedules. This is especially useful if the RIS or EMR team is unavailable during testing.

Configure the modality and test connectivity.
Work with the CT vendor or biomed to update the AET, IP, and Port on the modality and test connection.

Testing the network connection between the modality and PACS is critical. The C-ECHO test is a DICOM verification tool used to ensure two devices can communicate. When you initiate a C-ECHO, the modality establishes a DICOM association with the PACS. This association is essentially a handshake between the devices, confirming that they recognize each other and can exchange DICOM data. If the C-ECHO is successful, you’ve confirmed that the network setup is correct, and communication between the modality and PACS is functional.

Once configured, test the connection using a C-ECHO (Verification) test, which confirms that the modality and PACS can communicate A C-ECHO is a DICOM verification tool used to confirm whether two devices (such as a modality and PACS) can communicate. When a C-ECHO is initiated, the modality establishes a DICOM association with the PACS. This association is essentially a handshake between the devices to verify they can recognize each other and are able to exchange DICOM data. A successful C-ECHO indicates that the network configuration, including the AE Title, IP address, and port, is correct, and the modality can begin sending images.

For example. Let’s say you would like to connect CTPROD5 to the PACS Test environment. You (or the CT vendor) would need to input the following PACS storage destination into the CT modality.

AET: PACSERVERTEST
IP: 192.168.1.10
Port: 104

You can perform a network ping to ensure your modality can contact 192.168.1.50. The network ping is successful. 

Then perform a C-ECHO to test the connection. Take a look at the system log from the PACS test server. Can you tell which C-ECHO was successful?

The C-ECHO to the right was unsuccessful. The issue is with the Called AE Title AKA the destination AE Title. The Calling AE Title (CTPROD5) is the modality attempting to communicate with the PACS. The Called AE Title (PACSSERVER) is where the issue arises. The PACS expects a specific AE Title (PACSSERVERTEST), but it doesn’t recognize the one provided by the modality (PACSSERVER).

The network ping was successful in both cases. This is because a network ping tests basic network connectivity between two devices. It checks whether one device can “see” another device on the same network by sending an ICMP (Internet Control Message Protocol). It only verifies that the devices can communicate at the network level. A ping does not verify application-specific protocols like DICOM. A DICOM C-ECHO verifies both network connectivity and DICOM communication. A successful C-ECHO shows that the two devices can communicate using DICOM, have the correct AE Titles, IP addresses, and ports configured

Here is an example of a system log when the modality queries the RIS for a worklist. Can you tell which is the DICOM connectivity test and which is the worklist query?

Sending Images to PACS Using C-STORE

The DICOM C-STORE (Storage Service Class) is the protocol used by imaging modalities (e.g., CT scanners, MRI machines) to send images to the PACS for storage. After the modality captures an image, it initiates a C-STORE request to the PACS server. This request includes the image data along with the necessary DICOM metadata, such as patient information, modality details, and study information.

When the C-STORE request is received, the PACS server verifies the metadata and stores the image in its database. The PACS then sends a C-STORE response back to the modality, confirming whether the image was successfully received and stored. If the process is successful, the images are archived, making them accessible to radiologists and clinicians for review and diagnosis.

In most hospitals, the PACS must be configured to accept images from a limited list of modalities. The AE titles must be added to an allow-list within PACS. In this case, we’ll add CTPROD5 as an accepted node. Some other institutions’ PACS is promiscuous allowing any modality to send. However, this may allow 3rd party vendors or technologists to send garbage data from unknown modalities to PACS.

The C-STORE operation ensures that medical images are securely transmitted from the modality to the PACS, preserving data integrity and enabling seamless access to images within the hospital’s workflow.

5. Validation Testing with Vendor

Once configuration and initial testing are complete, conduct validation testing with the modality vendor to ensure the system works as expected. Next, repoint the modality to the Production environment. 

• Updating the AE Title, IP address, and port on the modality to match the production setup.
• DICOM Echo (C-ECHO) and test image transmission to confirm image storage and retrieval are working.
• Verifying that the Modality Worklist is functioning by retrieving test orders.
• Configure the modality to send to PACS and configure PACS to accept C-Store requests.

At this stage, all parties—including the PACS team, RIS/EMR team, and the modality vendor—should participate in testing. The PACS team will verify image storage and retrieval, while the RIS/EMR team ensures that the modality is pulling accurate patient worklists.

6. Go-Live and Post-Installation

Once the validation testing is complete, the modality can be moved from the test environment to production. Update the AE Title, IP address, and port to the production configuration, and perform a final round of tests with live patients:

• First Patient Scans: The PACS team should be on standby during the first patient scans to ensure that images are correctly sent to the PACS and stored without errors.
• Follow-Up: After the first few patient scans, follow up with radiologists and technologists to ensure that the images meet the hospital’s quality standards and that no workflow issues arise.

7. Documenting PACS Inventory and Final Steps

After the modality is fully integrated, document the hospital’s PACS inventory to ensure all information is recorded for future reference. This includes:

• AE Title
• IP Address
• MAC Address
• Switch and Port Information
• Biomed number (if applicable)

Ensure the modality is also integrated with additional systems like dose monitoring, 3D post processing software or a backup archive as required by radiology policies and procedures. 

Conclusion

Installing a new PACS modality involves close attention to DICOM configuration, including AE Title assignment, IP address setup, and port number configuration. From ensuring network connectivity with C-ECHO to validating the Modality Worklist integration, every step is crucial for a successful installation. By following the detailed steps outlined in this guide, you’ll ensure that the new modality is fully integrated into your hospital’s PACS system, with seamless communication and image transmission. With careful planning and collaboration between the PACS team, modality vendor, and other stakeholders, your new modality will be ready for clinical use with minimal disruptions.