In this answer it says:
in DICOM you have to provide all unique keys (Patient ID, Study Instance UID, Series Instance UID and SOP Instance UID) down to the level that you are querying
I am looking for a reference to the DICOM standard that says that?
In particular, I need 'proof' that StudyInstanceUID is required for Series Level queries.
This is specified in DICOM Part 4 (Service Class Specifications), Chapter C.4.1.2.1 Baseline Behavior of SCU:
The Identifier contained in a C-FIND request shall contain a single value in the Unique Key Attribute for each level above the Query/Retrieve level. No Required or Optional Keys shall be specified that are associated with levels above the Query/Retrieve level.
Looking at your comment on other answer by @kritzel_sw, I am trying to explain this further and add more "proof".
List of identifiers at specific levels:
- Patient Level: Patient ID
- Study Level: Study Instance UID
- Series Level: Series Instance UID
- Image Level: SOP Instance UID
Following is copied from here : Query Levels - Patient Root:
Following is copied from here (C.3.2 Study Root Query/Retrieve Information Model):
The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.
With any model, there are two types of queries supported - Hierarchical and Relational. What is quoted in other answer and this answer is about Hierarchical query which is default implementation. Relational query support is part of extended negotiation which is optional.
Following is copied from here (C.5 Association Negotiation)
SOP Classes of the Query/Retrieve Service Class, which include query services based on the C-FIND operation, may use SOP Class Extended Negotiation Sub-Item to negotiate options such as Relational-queries and Enhanced Multi-Frame Image Conversion.
and here (C.4.1.2.2 Extended Behavior of SCU)
Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be performed with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:
- Relational-queries
- Enhanced Multi-Frame Image Conversion
In Patient Root Hierarchical model, one should first query on PATIENT level to get the list of Studies (with Study Instance UID in response). Then, further query on STUDY level to get the list of Series (with Series Instance UID in response) and so on....
In Study Root model, STUDY is highest level. So querying on PATIENT level is not applicable.
Following quotes are from specifications - DICOM Part 4 (Service Class Specifications), Chapter C.4.1.2.1 Baseline Behavior of SCU:
The Identifier contained in a C-FIND request shall contain a single value in the Unique Key Attribute for each level above the Query/Retrieve level. No Required or Optional Keys shall be specified that are associated with levels above the Query/Retrieve level.
That means, while querying to next level, SCU must specify identifier of its earlier level. In Patient Root STUDY Level query, you have to specify Patient ID. In Study Root STUDY Level query, there is no above level. So, SCU can filter without specifying Patient ID.
The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching.
In responses from above query, SCU already received identifiers for this level. Those should be included in the query. While querying on SERIES level, specify the Study Instance UID received in earlier responses.
In addition, Required and Optional Keys associated with the Query/Retrieve level may be contained in the Identifier.
Additional parameters may also be included in query.
About optional parameters:
The SCU may not assume the SCP supports any Optional Keys. Hence, Optional Keys serve only to reduce network related overhead when they are supported by the SCP.
The SCU must be prepared to filter C-FIND responses when the SCP fails to support an Optional Key specified in the C-FIND request.
SCP must support filtering on identifier on that respective level - this is mandatory. SCP may additionally support filtering on other optional parameters also; but SCU should not relay on it.
Now, answering your comment:
Does that mean that I cannot even issue a STUDY level query without patient ID ? what if I only have a study ID / accession number
With Patient Root query, communication with SCP strictly implementing the specifications will fail in this case. With Study Root, STUDY is the top level. Your filters should work if supported by SCP.
In practice, most of the SCPs are liberal. Accession Number and Patient ID are widely used filters on STUDY Level.
