This is part of my series of articles on the DICOM standard that I am currently working on (a number of them have already been completed). If you are totally new to DICOM, please have a quick look at my earlier article titled “Introduction to the DICOM Standard” for a quick introduction to the standard. It might be useful to also look at my other tutorials that have been completed so far to get up to speed on a number of topics including DICOM Encoding, SOPs and IODs. My DICOM networking-related tutorials covering my series of articles on the DICOM standard including DICOM Verification as well as DICOM Associations will also be very useful to understanding the material that I will cover in this tutorial. This tutorial also assumes that you know the basics of Java or any equivalent object-oriented language such as C# or C++. A basic understanding of networking will also be useful to have but is not mandatory.
In this tutorial, I am going to introduce you to an extremely useful DICOM service that is used as part of clinical workflows around the world. It is called the DICOM Query/Retrieve service. This service is often used to query a DICOM device such as a PACS server or another DICOM workstation and later retrieve any results that matched the search criteria. The interesting thing to note is that the results can not only retrieved back to the querying device but also to a completely different DICOM device.
The query/retrieve service is made up of two separate phases namely the Query Phase as well as a Retrieve Phase. During the query phase, the Calling AE or SCU queries another DICOM device (the Called AE or the SCP) for content it is interested in passing in any search criteria such as patient, study or series information. The SCP then responds back with the results. At this stage, the user may or may not decide to retrieve these results to his/her workstation. If the user does choose to retrieve the results matched by the query criteria, then another distinct operation is invoked where the results are pushed back to the querying device through the use of the DICOM Storage service. Something very interesting occurs here. During this operation, the queried device or the SCP now switches roles to become a Storage SCU and pushes the results to the querying device which now plays the role of the Storage SCP. Don’t worry too much if this does not make sense to you as we will cover this in detail as we progress through this tutorial.
“The highest education is that which does not merely give us information but makes our life in harmony with all existence.” ~ Rabindranath Tagore
In one of my earlier tutorials, you learnt about the four level hierarchy used in DICOM consisting of Patient, Study, Series and Image (or Instance). You also learnt that the standard does not permit relational database type queries (and that this is only an optional feature that some applications implement on their own). The standard implements the query and retrieval of DICOM data using this four level information hierarchy as well. Let us look at this whole operation at a more detailed level covering any pre-requisite material we need to understand as we proceed.
DIMSEs in Query/Retrieve Operations
If you recall my tutorial on DICOM associations, you will recall that before any two DICOM devices can exchange service requests and results between each other, an association first needs to be established. During the association establishment/negotiation, the two devices may check to see if they speak DICOM (done through “DICOM ping” or “C-Echo” we saw earlier). whether they are authorized to communicate with each other (security check), whether they support the DICOM SOP class that is involved (C-Find, C-Store, etc), and lastly whether they agree on a transfer syntax that they can both understand. Only when all this is completed, do they proceed to transmit other commands pertaining to the actual service operation that is desired.
During the query phase, a C-Find message is passed from the querying device (here it is Device A) to the C-Find SCP (here it is Device B). The C-Find request message is accompanied by an IOD that consists of the search criteria. The structure of the C-Find message request and message response objects are shown below. The tables shown in the illustration below are screen captures from the DICOM standard part 7 document that covers message exchange fundamentals. The queried SCP returns a C-Find Response message for each entity matching the identifier specified in the request. Then, a final response message is sent indicating that the matching process is complete.
(Work in progress. I plan to come back to this and the rest of the series in 2016 due to other commitments at present. Please see my other completed articles in this series)