The DICOM is in the Details! but how does it work?

Most of us use DICOM every day, we smell it, we live it and we talk about it. However, often the deep dark secured is that we don’t really know how it works. What is a SOP? What is a Transfer syntax? And why do the engineers keep talking about Endians?

To begin with lets quickly review how a DICOM Store occurs, the sending system initiates a transaction. The sending system is the USER of DICOM Store (Service Class User or SCU) and the receiver is the Provider of DICOM Store or the Service Class provider (SCP). The user says I have this study that I want to store. The provider (receiver) says great, here I am. Then the user says I want to send a Breast Tomosynthesis Image.

*nerd alert- The type of image to be sent is defined by the SOP Class, the SOP stands for Service-Object Pair which is the Information Object Definition (image type) and DICOM Service Elements (DICOM Wrapper).   The SOP for Breas Tomo is 1.2.840.10008.5.1.4.1.1.13.1.3, which is in a supplement.

https://www.dicomlibrary.com/dicom/sop/

At this time the provider will reply back with yes, no problem or no, I don’t know that that is. If the answer is yes and the receiver (SCP) supports that SOP (see how you are starting to get the lingo!) it will also send back the list of languages it speaks. We are all pretty familiar by now with the 3 types of compression, uncompressed commonly called DICOM, lossless compressed which is compressed but still ok for reading and lossy compressed in which image data is lost but is much smaller. Each of these along with several others are called in DICOM Speak a transfer syntax.

Once the sender and receiver have agreed on what will be stored, the receiver sends back a list of languages it speaks, or transfer syntaxes. The sender or SCU will then select one of these to send the image. Thus, it is the sender the decides whether or not the image is sent compressed or not. Implicit VR Endian is the default DICOM transfer syntax and therefore supported by ALL vendors.  Because of this, many vendors take the easy road and simply accept the default. This is … OK… within a LAN but when the data is stored or transferred over a WAN compression becomes very important.

https://www.dicomlibrary.com/dicom/transfer-syntax/

Now that SCU and SCP have agreed on what is to be sent and how it will be sent the data transmission goes. The transmission can be at the instance level which refers to individual images or at the study level in which many images are sent on the same association. Once the association is complete the sender may initiate a Storage Commit, which I highly recommend when sending to VNA across a WAN.

Briefly in a storage commit message the sender reaches back out to the provider and sends a list of all individual images that were sent. The Provider then responds back either positively that ALL images were received or negatively in which something wasn’t. In the case of negative the entire study is considered a failure and will be resent, which takes up a lot of your bandwidth.

Please like, share and comment. I would love to know what topics are of interest to the imaging people out there!

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

Published by

Kyle Henson

I am a doctoral student, entrepreneur and longtime imaging professional. I truly love what I do and strive to make healthcare better for every patient that goes to a facility I work with. I apply the "my wife" principle to IT, if it was my wife having xxxx procedure what information would I want the physicians to have? If I provide that, I have done my job.

Leave a Reply

Your email address will not be published. Required fields are marked *