By Tony Pham
Going through the standard biomedical engineering curriculum at college, I was taught about the inner workings of various imaging modalities, including ultrasound, X-ray, MRI, etc. Upon entering the HTM workforce, it became apparent that I was never taught how all the images got transferred outside of those modalities. This was my introduction to Digital Imaging and Communications in Medicine (DICOM) and is a public use protocol for the digital storage and transmission of medical images. Fortunately, I have some colleagues who are knowledgeable on the topic of DICOM and they were willing to teach me. Following is more about my experience learning DICOM.
The first concept I found useful was learning the roles that each device played during image transfer. Specifically, these roles are SCU (Service Class User) and SCP (Service Class Provider). Despite their names, the SCU serves as the image sender and SCP acts as the image receiver. It may be easier to just think of the roles as a sender and a receiver. In each instance of image transfer through DICOM, one software will be the SCU and the other will be the SCP. Normally, imaging modalities like X-ray machines will only ever be used as an SCU. These devices typically have no use for receiving medical images. Likewise, printers would act as SCPs. Almost everything else could be either role, depending on the specific DICOM transfer being performed.
After understanding how the SCU and SCP roles work in DICOM, I began setting up a complete DICOM network. I used two open-source applications called GinkgoCADx and Conquest DICOM Server. GinkgoCADx served as a workstation DICOM viewer while Conquest was the DICOM server. After starting up the Conquest DICOM server, I went to the configurations tab to set both the Application Entity (AE) title and port for the server. Similarly, I also set the AE title and port for GinkgoCADx under the DICOM nodes page in its settings. Take good notes of the IP addresses, AE titles, and ports for both the server and the workstation viewer as these are vital for establishing the connection.
Because I was setting up the server and the workstation on the same computer, they shared the same IP address, that of my computer. This did not mess up the DICOM network configuration thanks to the different ports set for each application. My colleague explained this concept using the analogy of an apartment complex where the DICOM image is a piece of mail, and the IP address is the address of the whole apartment complex. In this analogy, the ports would be the apartment numbers. While both the DICOM server and the workstation viewer resided in the same main address, which was my computer, they were in two separate locations, which were the ports. This allows us to send images back and forth between Conquest and GinkgoCADx. In a practical setup, the server and workstations would be separate machines with different IP addresses, but the same concept still applies.
Next, I had to finish establishing a connection between the applications by inputting each one’s information into the other. In Conquest, I entered GinkgoCADx’s information under the known DICOM providers tab, making sure to add an extra new line under the list of DICOM providers. In GinkgoCADx, I then entered the Conquest server information into the DICOM nodes page, the same place I set the AE title and port configuration before. Once both Conquest and GinkgoCADx had the other’s information, it was time to test the DICOM network.
Before testing, I downloaded a couple of DICOM images from the Internet and loaded them into GinkgoCADx. In Conquest, I opened the server status tab and checked the debug log box on the right side to see any errors on the server. Upon first trying to upload the DICOM images from GinkgoCADx to the Conquest server, I saw an error in the server logs. Trying a different image gave me the same error. I restarted the server and re-initialized the database. That seemed to work, and the images uploaded correctly. As with almost all technological devices, a complete reboot seems to be the easiest fix to an issue. I verified that the new images were in the database by checking the logs and browsing the database in Conquest.
After verifying that the images were uploaded to the server correctly, I ran the DICOM Query/Retrieve (Q/R) operation from GinkgoCADx. I wanted to see what could be found from the server’s database. Using the broadest search conditions available, I looked for all images/studies. GinkgoCADx found the two images I had previously uploaded along with two default images. The successful download and viewing of those two default images from the server indicated that the DICOM network functioned properly. This was further supported by the server logs which showed successful processes for the DICOM Q/R.
On the topic of operations, there are a few terms that are commonly used in DICOM. C-STORE, also known as “DICOM Push”, is normally used by imaging modalities (SCUs) to send their captured images to the DICOM server and/or workstations (SCPs). The C-FIND and C-MOVE operations are used in DICOM Q/R to first find specific images and then pull the selected images to the SCP. Finally, C-ECHO is equivalent to a more advanced ping, specifically used to test DICOM connection and functionality. There are other operations in DICOM, but these four are the most used by large PACS manufacturers.
At this point, my colleague and I had a brief discussion on what kind of information is stored in the DICOM header. In each DICOM transfer, information about the medical image/study is sent in the form of a header that comes before the actual image(s). Within the DICOM header, there are many fields that can contain standard information as well as custom ones. Each piece of info has an associated tag as well as a name and value, and this information is what is filtered through when using the C-FIND operation. Common standardized information includes patient information, the type of medical image, where the images were taken, etc. Fun fact, information in the DICOM header can be removed, or anonymized, as needed for sharing of the images such as in court cases or for educational purposes.
To review the steps for setting up DICOM for new devices: The key information when connecting any device to the DICOM network is the IP address of the device, the AE title and specific port number that is assigned to it. This info then needs to be added to all machines (including servers, workstations, etc.) that will be directly sending or receiving images from the new DICOM device. This must be done on each SCU and SCP for them to communicate with each other. Once all the info has been entered on both sides, a test can be performed with the C-ECHO command or through sending/retrieving a test image. If the new device is networked appropriately, a “successful test” signals that the connection is good.
