Why is Orthanc not standards compliant to hierarchical (default) C-Find requests?

Hey,

“C.4.1.3.1.1 Hierarchical Search Method” of the DICOM standard (less cryptic version can be found in C.4.1.2.1 Baseline Behavior of SCU) define the requirements for a standards compliant C-Find request.

Judging from the Orthanc roadmap, extended negotiation is not supported, which means that Orthanc must use the hierarchical, not relational C-Find flavor.

However, if I do

findscu -d -aec ORTHANC -aet FINDSCU -P -k “PatientID=1234” -k “PatientName=” -k “QueryRetrieveLevel=Series” localhost 4244 # Orthanc listening for DICOM traffic at localhost:4244

Orthanc will happily yield me a response, even though that I should have also supplied a single-value, non-wildcard StudyInstanceUID according to the DICOM standard. The above should only work if I have negotiated Relational Queries with the DICOM Peer. The result I actually should have gotten is specified as per C.4.1.3.1.1 and should be a empty, successful C-Find and most real-world, commercial PACS I’ve come across will actually behave this way.

Of course, it’s a cool feature that Orthanc will yield a response on the Series / Composite level even with incomplete hierarchy information. However, I reckon there is a significant user base of Orthanc (myself included) that use it to test their applications before plugging them into a real PACS. For this exercise, my “testing PACS” needs to follow the DICOM standard as closely as possible.

Finally, the question.
Do the Orthanc developers want to primarily

  1. Deliver a better, faster version of C-Store SCP functionality, that allows for queries like the one above, on the costs of standard conformity?
  2. Be standards compliant (would the above be considered a bug by the Orthanc developers?)
    Thanks in advance.
    Georg

Dear Georg,

The ultimate objective of Orthanc is to make the deployment of a generic DICOM server straightforward. This implies that Orthanc tries to be as permissive as possible, even in the presence of non-compliant requests.

We could certainly think about introducing a “strict” mode for C-Find requests, that would be disabled by default but that could be enabled in the configuration file. This could indeed be useful to software editors like yourself.

I have added a TODO item to track this idea:
https://bitbucket.org/sjodogne/orthanc/commits/2b645caab9ee6904f2a9255530566d77c92b4442

The Osimis services team could certainly implement this feature for you.

Regards,
Sébastien-