query-series API

Hi there,

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

query = {
‘Level’ : ‘Series’,
‘Query’ : {
‘Modality’ : ‘',
‘ProtocolName’ : '
’,
‘SeriesDescription’ : ‘',
‘SeriesInstanceUID’ : '
’,
‘StudyInstanceUID’ : pageData.uuid
}

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 ?

Best regards,

Salim

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).

Best regards,

Salim

Dear Salim,

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.

However, I have dug deeper, and I have implemented an integration test named “test_study_series_find_inconsistency” that covers more possible cases:
https://bitbucket.org/sjodogne/orthanc-tests/commits/a2719263fd043adb33137ee051f4ebfbf27b869e

You’ll find comments in these tests that explain the expected behavior of Orthanc.

Small changes have also been applied to the Orthanc source code to make some edge cases pass:
https://bitbucket.org/sjodogne/orthanc/commits/6358923d3ced5a646fe0f3225d612d2747f65f14

I hope this clarifies the situation…

Kind Regards,
Sébastien-

Dear Sebastien,

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

{"Level":"Series","Query":{"Modality":"*","ProtocolName":"*","SeriesDescription":"*","SeriesInstanceUID":"*","StudyInstanceUID":"1.2.840.113619.2.354.3.3523896338.527.1582613413.604"}}

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,

Best regards,

Salim

Hello,

That’s how DICOM is supposed to work: C-FIND SCP only report the tags you were asking for.

Also, you should avoid wildcards: Have a look at the so-called “universal matching”:
http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.2.2.2.3.html

“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.”

The correct request in your case is probably:

{“Level”:“Series”,“Query”:{“Modality”:“”,“ProtocolName”:“”,“SeriesDescription”:“”,“SeriesInstanceUID”:“”,“StudyInstanceUID”:“1.2.840.113619.2.354.3.3523896338.527.1582613413.604”},“Normalize”:false}

HTH,
Sébastien-

OK ! Now I get it !
Thanks for clarification !

By the way, you can forgot about my message telling Orthanc can’t query itself.
It was due to my wrong queries syntaxt,

Now everything works fine !

Thanks Again