Understanding Query/Retrieve

After many days of combing through the DICOM protocol documentation,
particularly PS3.4 Annex C, I am no closer to understanding exactly
what is involved in performing a query and retrieving images from a
PACS. I am experimenting with the DICOM Image I/O Plugin from Apterix,
and their example code and API documentation leave a lot to be desired
if one does not have a thorough understanding of the protocol.

For a test setup, I'm using the PacsOne server, into which I have
imported a set of files from Sebatien Barre's site, and then inserted
"cooked" records into the PacsOne Mysql database to define studies,
series and associated images for a patient. In the web front end that
is suppled with PacsOne, I can search successfully for the patient,
and locate the "cooked" series, studies and images, view or download
the images etc., so I know that what I want to search for and retrieve
from my Java application is there. An implicit assumption is that the
search engine within the PACS invoked from the web front end is
exactly what will be invoked after an association is established by an
SCU.

I have gotten as far as establishing an association and performing a
C_FIND operation at the PATIENT level. In an example class from
Apterix, a Patient Name tag and a Patient ID tag are inserted into the
query object. If the Patient Name is a valid one and the ID has a null
value, the response contains the matching names along with the correct
ID values. So far so good.

Am I correct in assuming that, for any additional tags whose values I
want to retrieve, I can simply insert the tag with a null value into
the request? This seems to work for e.g. Patient Sex, but not for e.g.
Sop Instance UID.

Any advice would be appreciated.

bob thomas wrote:[color=blue]
> Am I correct in assuming that, for any additional tags whose values I
> want to retrieve, I can simply insert the tag with a null value into
> the request? This seems to work for e.g. Patient Sex, but not for e.g.
> Sop Instance UID.[/color]

The Query/Retrieve protocol is hierarchical. Depending on the SOP class
negotiated between client and server, different information models (in
database terminology: views of the underlying database) are available.
The most general model is called "patient root", and it defines four
levels: Patient, Study, Series, Instance.
Each image (which is an instance) is always part of a series, which is
part of a study, which is assigned to exactly one patient.

A query is a message that contains a list of *matching keys* and *return
keys* for a specific level of this hierarchy. Matching keys are tags
with non-empty values against which the responses have to match, in your
example the patient's name. Return keys are tags that can be returned
by the archive but for which no matching is supported.

Due to the hierarchical model, you can only request a list of
patient attributes, or a list of study attributes *for a single given
patient*, or a list of series attributes *for a single given study*
or a list of instance attributes *for as single given series*.

This means, if you want to retrieve a SOP Instance UID (which is part
of the IMAGE level), you first have to identify a patient, then
send a second query that identifies the studies for this patient,
then in a third query request the series for a single study and finally
request a list of images for a given series.

All of this is documented in Part 4 of the standard, in annex C.

Regards,
Marco Eichelberg
OFFIS

Thanks for the help, Marco