[BitBucket user: Erik Ziegler]
[BitBucket date: 2016-02-03.11:28:13]

Hello,

We've been using the orthanc-dicomweb plugin and noticing that the QIDO-RS retrieval at the Study Level becomes much slower as more studies (or studies with large instances, e.g. mammo tomographs) are added to Orthanc.

When I run Orthanc in verbose mode, I see that the plugin is making REST GET calls on /studies/{id}}/instances, which according to the documentation is used to "Retrieve all the instances of this patient in a single REST call". This seems reasonable, since the plugin needs information about the studies. 

What seems odd, though, is that the plugin is also making requests to /instances/{id}/file, which I suppose means that Orthanc is reading one file from each study in order to gather the metadata and return it for the QIDO-RS call. This appears to be done in the ExtractFields function in QidoRs.cpp (https://hg.orthanc-server.com/orthanc-dicomweb/file/cf5002bc63a885bf99c413718d612f199a8cd748/Plugin/QidoRs.cpp).

Assuming my understanding is correct, could this metadata be retrieved from the Orthanc database instead? E.g. From the documentation, would it be faster to parse the simplified-tags? (https://orthanc.chu.ulg.ac.be/book/users/rest.html#accessing-the-dicom-fields-of-an-instance-as-a-json-file).

If your answer is yes, that this is a reasonable plan, I will attempt it. I just wanted to make sure you thought this was a decent option.


I've tested this on Orthanc 1.0.0 and Dicomweb plugin 0.2.

[BitBucket user: Martin van Kuik]
[BitBucket date: 2016-03-08.10:21:14]

Thanks a lot for your help. However, I may have found something. The issue still persists, but it seems that in

    https://hg.orthanc-server.com/orthanc-dicomweb/file/cf5002bc63a885bf99c413718d612f199a8cd748/Plugin/QidoRs.cpp

the DICOM tag used in the QIDO call is wrong.

result.push_back(gdcm::Tag(0x0008, 0x0056)); // Modality

Shouldn't that be result.push_back(gdcm::Tag(0x0008, 0x0060)); // Modality ?

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2016-04-28.07:42:12]

@mtjvankuik You are right about the "Modality" tag. This was an error in the original DICOMweb standard that has been fixed [when moving from DICOM 2015a to DICOM 2015b](http://dicom.nema.org/medical/dicom/2015b/output/pdf/part18_changes.pdf). The fix [has just been submitted](https://hg.orthanc-server.com/orthanc-dicomweb/changeset/7cb164a4b5f0348f97d7b6c92609c1b481a23379) to the mainline of the plugin. But this does not solve Erik's issue.

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2016-04-28.08:05:38]

@swederik Internally, here is how the DICOMweb plugin works:

 1. It calls the `/tools/find` REST call to retrieve the list of matching studies, series or instances. This step is as fast as a C-FIND query against Orthanc's DICOM SCP.
 1. In a second time, for each matching study/series/instance, the plugin chooses 1 DICOM instance among all the child instances of this study/series/instance. Hence the call to `/studies/{id}/instances` you observe.
 1. In a third time, for each selected child instance, it downloads the DICOM file and parses its content using GDCM to format the queried tags. Hence the call to `/instances/{id}/file`.

As a conclusion, the number of times a DICOM file is parsed linearly depends on the number of matching resources (and not on the number of instances contained in these resources). I could indeed use the `/instances/{id}/tags` API instead of `/instances/{id}/file` to reduce the computing time, but this would only increase the speed by a constant factor (i.e. do not expect an improvement in the global complexity of the plugin). I will give a try.

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2016-04-28.13:15:11]

@swederik I have just committed a patch so that the DICOMweb plugin uses the JSON file precomputed by Orthanc, instead of a decoding with GDCM.
https://hg.orthanc-server.com/orthanc-dicomweb/changeset/4fa66776ba092805b26d133623b96ed36c693bb3

I would love to hear your feedback about this modification improves the performance of the plugin on your side. In the meantime, I put the issue on hold.

[BitBucket user: Erik Ziegler]
[BitBucket date: 2016-04-29.06:37:48]

Awesome thanks. I will take a look ASAP!

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2020-06-16.07:43:04]

Closing, as the DICOMweb plugin has greatly evolved since 2016. Performance should be strongly improved now. Don't hesitate to re-open this issue if need be.