I have a question about a strange behaviour of Orthanc Query APIs.
When we Query a study level, Orthanc propose the query-series API.
I then use this query-series API with an empty post payload {}
It return a new query ID which works properly, the returned ID contains series result, the query generated was generated with only the StudyInstanceUID of the parent study query as query parameter.
The problem is that the answer content of this query made with query-series APIs does not contains Series Description, Modality etc …
It only contains :
SpecificCharacterSet,
QueryRetrieveLevel,
InstanceAvailability,
StudyInstanceUID
SeriesInstanceUID
On the other hand I see that Orthanc Explorer do not use this API to pass from Study to Series level, it generate from scratch a new query at series level passing the study UID as parameter with wildcard in other filters
This query in Orthanc explorer shows correctly the modality, series description …
To me the difference is pretty strange, the query-series is a nice API when integrating Orthanc in a third party app, but it would need to produce the full results with description and modality to display valuable results to the user.
Or maybe i’m missing something on how to use the query-series API ?
By the way, I can confirm the bug found at the orthanc con,
when you declare Orthanc AET to query itself (self, localhost, 4242, generic), the queries at the study level works but not at the series level. (this make harder to simulate a full dicom environement for developpement).
Your question was actually very complex to answer.
There are indeed many cases to distinguish depending on the value representation of the queried tags (some VRs such as UI don’t support wildcard matching), on the presence/absence of the queried tags, on the level of the query, and on the “Normalize” flag that is available for “/modalities/…/query” (which initiates a C-FIND SCU against a remote modality).
I think that what you perceived as a bug is essentially a side-effect of the “normalization” process, that automatically removes tags that are not available for the given query level. This is the default behavior: In your case, for instance, when you trigger a C-FIND SCU at the STUDY level, the “SeriesDescription” is not allowed (this one is series-related), and thus is wiped out by Orthanc. The message “Tag not allowed for this C-Find level, will be ignored” that appears in the logs, indicates that such a normalization was carried on by Orthanc.
You can disable this normalization (that is enabled by default) by setting field “Normalize” to “false” in the body of the POST call to “/modalities/…/query”. This way, I think you get the behavior you expected.
Thanks for clarification it's more clear to me how to build queries but i'm not sure we are talking about the same thing.
Here an example probably more concreate.
I'm calling a same AET called "AWServer" at a series level to retrieve series data of the StudyInstanceUID 1.2.840.113619.2.354.3.3523896338.527.1582613413.604
A) This Series Query following Orthanc Explorer syntax
Gives me content anwser in witch I can find :
SpecificCharacterSet
QueryRetrieveLevel
InstanceAvailability
StudyInstanceUID
SeriesInstanceUID
Modality
SeriesDescription
b) This Series Query duplicating /queries/{id}/answers/{index}/query-series generated query
{
"Level": "Series",
"Query": {
"StudyInstanceUID": "1.2.840.113619.2.354.3.3523896338.527.1582613413.604"
}
}
Gives me :
SpecificCharacterSet
QueryRetrieveLevel
InstanceAvailability
StudyInstanceUID
SeriesInstanceUID
=> In B), the Modality and Series Descriptions are missing in the answers while they are value of interest (I guess if my AET would respond Series Number it would be missing too).
That's a bit curious that you need to add unneded wildcard in the query to get the full content in queries answer's content and that the /queries/{id}/answers/{index}/query-series APIs return partial contents in answers
Or maybe I have something still I didn't understood,
“An Attribute that contains a Universal Match specification in a C-FIND request provides a mechanism to request the selected Attribute Value be returned in corresponding C-FIND responses.”