What's the purpose of the IDMS Query & Retrieve Server?

The IDMS Query & Retrieve Server essentially turns your CDMS or IDMS sysytem into a PACs-like system, whereby clients on the network (such as 3rd party planning systems) can query and retrieve DICOM studies directly from CDMS or IDMS systems without someone having to go to a planning station, load the patient, and export their DICOM series individually or manually.

More details can be explained by this article taken directly from the Internet:

The primary purpose of a DICOM Query and Retrieve (Q/R) server is to act as a central repository that allows medical devices and software to locate and fetch patient imaging data across a hospital or clinical network. It acts as a bridge between a central medical image database—like a PACS (Picture Archiving and Communication System)—and client systems like workstations, medical modalities (CT, MRI), or research tools. [1, 2, 3]

Core Functions & Protocol Messages

A DICOM Q/R server uses specific standardized commands under the DICOM network protocol to manage requests: [1]

1. The Query Function (C-FIND): When a doctor searches for a patient's historical imaging on a workstation, the client sends a C-FIND request. The server searches its database using parameters like Patient ID, Study Date, or Modality and sends back a list of matching results. [1, 4, 5]
2. The Retrieve Function (C-MOVE or C-GET): Once the correct exam is located, the client requests the actual heavy image files using a C-MOVE or C-GET command. Interestingly, a C-MOVE command allows the server to either send the images directly back to the requester or route them to a completely different destination, such as another department's viewing station. [1, 5, 6]

The Hierarchical Information Model

To make searching fast and structured, the server catalogs incoming medical files into a strict four-level hierarchy: [1, 2]

[Patient] ➔ [Study] ➔ [Series] ➔ [Image / Instance]

Users can query at any of these levels. For example, they can search broad details at the Patient or Study level, or narrow their request down to a specific Series (e.g., a specific sequence of an MRI) or individual Image slice. [1, 7]

Client vs. Server Roles

In DICOM terminology, this operation uses a client-server relationship: [4]

1. SCP (Service Class Provider): This is the Q/R Server itself. It acts as the host, constantly listening for incoming requests, searching its database, and delivering data. [4]
2. SCU (Service Class User): This is the Client (e.g., a radiology workstation, a mobile viewing app, or an imaging modality). It initiates the connection to query or ask for data. [1, 4] The "DICOM RT Viewer" application that is available for download on tcconsulting.online website is one such client.

[1] https://siim.org

[2] https://docs.sonicdicom.com

[3] https://mipav.cit.nih.gov

[4] https://www.neologica.it

[5] https://www.irya.unam.mx

[6] https://www.saravanansubramanian.com

[7] https://www.mathworks.com