QIDO/WADO endpoints handling in OHIF v3

kzgrzendek · September 10, 2021, 6:57am

Hello everyone!

Congrats to the team for the new website and this shiny forum!

To give a bit of context, I am working for the Greater Paris University Hospitals (APHP), and we’re using OHIF v2 for a few months now with some of our research projects.
We are pluging OHIF to our own PACS solution (opensource, soon to be published) based on Python (pydicom, pynetdicom, on top of Django Rest Framework for handling DICOMweb).

I am in the process of installing OHIF v3 in our dev environment, so we can test it and get back to you with some feedback.

I have a strange issue that I did not encountered with OHIF v2 ; it seems that the qidoRoot param is not taken into account :

Here is my Datasource :

dataSources: [
    {
        friendlyName: "SPHERE DICOMWeb Server",
        namespace: "org.ohif.default.dataSourcesModule.dicomweb",
        sourceName: "dicomweb",
        configuration: {
            name: "SPHERE",
            wadoUriRoot: "https://sphere.docker.local:443/wadors",
            qidoRoot: "https://sphere.docker.local:443/qidors",
            wadoRoot: "https://sphere.docker.local:443/wadors",
            qidoSupportsIncludeField: true,
            imageRendering: "wadors",
            thumbnailRendering: "wadors",
            enableStudyLazyLoad: true,
            supportsFuzzyMatching: false,
            supportsWildcard: false,
        },
    },
];

It seems that the query to the PACS for displaying the study list is using the wadors endpoint :

Looking into the code, it seems that these config params are not well known :

/**
 *
 * @param {string} name - Data source name
 * @param {string} wadoUriRoot - Legacy? (potentially unused/replaced)
 * @param {string} qidoRoot - Base URL to use for QIDO requests
 * @param {string} wadoRoot - Base URL to use for WADO requests
 * @param {boolean} qidoSupportsIncludeField - Whether QIDO supports the "Include" option to request additional fields in response
 * @param {string} imageRengering - wadors | ? (unsure of where/how this is used)
 * @param {string} thumbnailRendering - wadors | ? (unsure of where/how this is used)
 * @param {bool} supportsReject - Whether the server supports reject calls (i.e. DCM4CHEE)
 * @param {bool} lazyLoadStudy - "enableStudyLazyLoad"; Request series meta async instead of blocking
 */

I cant find the root of the issue by quickly looking at it, does that ring any bells to anyone?

Thank you

alireza · September 12, 2021, 4:34pm

Thanks for reporting this.
I lookd at the code, and I confirm this is bug introduced here (feat: Add Static WADO display (#2499) · OHIF/Viewers@2327b4a · GitHub)

The fix will get merged soon

kzgrzendek · September 13, 2021, 7:47am

Awesome, thank you!

kzgrzendek · November 22, 2021, 5:41pm

Hello again

It seems that I now have the same issue a bit further in the workflow.

Indeed, I can now access the studies list view, but every time I click on a study, OHIF is querying the WADO-RS endpoint instead of the QIDO-RS one) to query series metadata (or at least that is what it seems to happen) :

The consequence is that I cannot display any series content since OHIF cannot retrieve the series metadata it needs to query the WADO-RS endpoint for data frames.

I precise that I am working on the last version of the v3-stable branch.

Here is the last version of my DataSource configuration, if this can be of any help :

window.config = {
  routerBasename: '/',
  // whiteLabelling: {},
  extensions: [],
  modes: [],
  showStudyList: true,
  filterQueryParam: false,
  dataSources: [
    {
      friendlyName: 'SPHERE',
      namespace: 'org.ohif.default.dataSourcesModule.dicomweb',
      sourceName: 'dicomweb',
      configuration: {
        name: 'SPHERE',
        wadoUriRoot: 'https://sphere.docker.local:443/wadors',
        qidoRoot: 'https://sphere.docker.local:443/qidors',
        wadoRoot: 'https://sphere.docker.local:443/wadors',
        qidoSupportsIncludeField: true,
        supportsReject: false,
        imageRendering: 'wadors',
        thumbnailRendering: 'thumbnail',
        enableStudyLazyLoad: true,
        supportsFuzzyMatching: false,
        supportsWildcard: false,
        staticWado: false,
      },
    },
  ],
  defaultDataSourceName: 'dicomweb',
};

Do you know what could cause the issue?

Thank you

alireza · November 23, 2021, 2:58pm

What is the last commit hash you have on your OHIF? (having said that we need a better way to communicate which version you are using …)

kzgrzendek · November 23, 2021, 5:18pm

This one →

commit 1d0b310d9235aa29b7834a12e3c0a725496ddbb5 (HEAD -> v3-stable, origin/v3-stable)
Author: Daryl.Xu <ziqiang_xu@qq.com>
Date:   Mon Oct 25 16:55:13 2021 +0800

    fix: typo (#2592)

alireza · November 25, 2021, 1:54pm

It is very weird, we are using the qidoRoot for querying here.

Where exactly (which file) is querying using the wado (instead of qido)?

kzgrzendek · November 25, 2021, 5:46pm

EDIT : Here is a GIF of the issue, with public data from the TCIA :

StudyLoading

OHIF v3 shows one empty series, but when switching to OHIF v2, I can see several series with instances inside.

I took some time to dig through the code today despite my very limited React skills, but here is what I found (and I hope it also answers your question) :

The issue seems to be with the way OHIF v3 is calling the searchForSeries function inside the dicomweb-client dependency :

github.com

dcmjs-org/dicomweb-client/blob/e03be5afbd4814f473e07e21730a53c14283f5b7/src/api.js#L995

    
      
          }
          
          
/**
           * Searches for DICOM series.
           *
           * @param {Object} options
           * @param {Object} [options.studyInstanceUID] - Study Instance UID
           * @param {Object} [options.queryParams] - HTTP query parameters
           * @returns {Object[]} Series representations (http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_6.7.html#table_6.7.1-2a)
           */
          searchForSeries(options = {}) {
            let url = this.qidoURL;
            if ("studyInstanceUID" in options) {
              console.log(`search series of study ${options.studyInstanceUID}`);
              url += `/studies/${options.studyInstanceUID}`;
            }
            url += "/series";
            if ("queryParams" in options) {
              url += DICOMwebClient._parseQueryParameters(options.queryParams);
            }
            let withCredentials = false;

Indeed, this function seems to be called with the wadoDicomWebClient object, instead of the qidoDicomWebClient one (and this function clearly wants a QIDO URL).

In the DicomWebDataSource module, we can see inside the retrieve series implementation a declaration of a studyPromise, which is calling the retrieveStudyMetadata with a wadoDicomWebClient object`:

github.com

OHIF/Viewers/blob/1d0b310d9235aa29b7834a12e3c0a725496ddbb5/extensions/default/src/DicomWebDataSource/index.js#L171

    
      
              'Incomplete queryParams, missing StudyInstanceUIDs'
            );
          }
          
          
const storeInstances = instances => {
            const naturalizedInstances = instances.map(naturalizeDataset);
          
          
  DicomMetadataStore.addInstances(naturalizedInstances);
            callback(naturalizedInstances);
          };
          const studyPromises = StudyInstanceUIDs.map(StudyInstanceUID =>
            retrieveStudyMetadata(
              wadoDicomWebClient,
              StudyInstanceUID,
              enableStudyLazyLoad
            )
          );
          
          
studyPromises.forEach(studyPromise => {
            studyPromise.then(data => {
              const { seriesPromises } = data;

If we take a closer look to the retrieveStudyMetadata function inside the RetrieveMetadata module, we can see a new promise which is using the RetrieveMetadata function :

github.com

OHIF/Viewers/blob/1d0b310d9235aa29b7834a12e3c0a725496ddbb5/extensions/default/src/DicomWebDataSource/retrieveStudyMetadata.js#L47

    
      
              `${moduleName}: Required 'StudyInstanceUID' parameter not provided.`
            );
          }
          
          
// Already waiting on result? Return cached promise
          if (StudyMetaDataPromises.has(StudyInstanceUID)) {
            return StudyMetaDataPromises.get(StudyInstanceUID);
          }
          
          
// Create a promise to handle the data retrieval
          const promise = new Promise((resolve, reject) => {
            RetrieveMetadata(
              dicomWebClient,
              StudyInstanceUID,
              enableStudyLazyLoad,
              filters,
              sortCriteria,
              sortFunction
            ).then(function(data) {
              resolve(data);
            }, reject);

This function is using the RetrieveMetadataLoaderAsync :

github.com

OHIF/Viewers/blob/1d0b310d9235aa29b7834a12e3c0a725496ddbb5/extensions/default/src/DicomWebDataSource/wado/retrieveMetadata.js#L27

    
      
            enableStudyLazyLoad,
            filters = {},
            sortCriteria,
            sortFunction
          ) {
            // const RetrieveMetadataLoader =
            //   enableStudyLazyLoad !== false
            //     ? RetrieveMetadataLoaderAsync
            //     : RetrieveMetadataLoaderSync;
          
          
  const RetrieveMetadataLoader = RetrieveMetadataLoaderAsync;
          
          
  const retrieveMetadataLoader = new RetrieveMetadataLoader(
              dicomWebClient,
              studyInstanceUid,
              filters,
              sortCriteria,
              sortFunction
            );
            const { preLoadData, promises } = await retrieveMetadataLoader.execLoad();

Finally, this async loader is calling the searchForSeries function of the dicomweb-client dependency with the wadoDicomWebClient it has been called with :

github.com

OHIF/Viewers/blob/1d0b310d9235aa29b7834a12e3c0a725496ddbb5/extensions/default/src/DicomWebDataSource/wado/retrieveMetadataLoaderAsync.js#L55

    
      
              studyInstanceUID,
              filters: { seriesInstanceUID } = {},
              client,
            } = this;
          
          
  if (seriesInstanceUID) {
              const options = {
                studyInstanceUID,
                queryParams: { SeriesInstanceUID: seriesInstanceUID },
              };
              preLoaders.push(client.searchForSeries.bind(client, options));
            }
            // Fallback preloader
            preLoaders.push(client.searchForSeries.bind(client, { studyInstanceUID }));
          
          
  yield* preLoaders;
          }
          
          
async preLoad() {
            const preLoaders = this.getPreLoaders();
            const result = await this.runLoaders(preLoaders);

Now this is pure supposition of my part, but I think that this AsyncLoader is triggrered when we are displaying a Study in order to crawl through the series, for performance reasons I guess, and that could explain why this error arises at this moment in the workflow.

This is the best lead I have, but do not hesitate to correct me if I am wrong

kzgrzendek · November 26, 2021, 11:11am

Sorry for the spam, but I figured my latest investigations could help you out

I found that the dicomweb-client dependency have four interesting parameters in our case :

url : base URL of the DICOMWeb server
qidoURLPrefix : the qido base URL extension
wadoURLPrefix : the wado base URL extension
stowURLPrefix : the stow base URL extension

github.com

dcmjs-org/dicomweb-client/blob/e03be5afbd4814f473e07e21730a53c14283f5b7/src/api.js#L71-L106

    
      
          constructor(options) {
            this.baseURL = options.url;
            if (!this.baseURL) {
              console.error("no DICOMweb base url provided - calls will fail");
            }
          
          
  if ("username" in options) {
              this.username = options.username;
              if (!("password" in options)) {
                console.error(
                  "no password provided to authenticate with DICOMweb service"
                );
              }
              this.password = options.password;
            }
          
          
  if ("qidoURLPrefix" in options) {
              console.log(`use URL prefix for QIDO-RS: ${options.qidoURLPrefix}`);
              this.qidoURL = `${this.baseURL}/${options.qidoURLPrefix}`;
            } else {

This file has been truncated. show original

In the OHIFv3 code you showed me, we are using two different DICOMWeb clients ; one for WADO-RS and one for QIDO-RS, and in each case we are cheating a bit by replacing the url parameter in the options by a complete WADO-RS or QIDO-RS URL.
I wonder why we are doing that since one client can perfectly handle both endpoints, and also adding a proper support for STOW queries (I know there is support for such queries in OHIF v2 and v3, but I wonder how there are implemented and which client they use ).

Anyway, I tweaked the code a bit, by simply :

Creating one client instead of two
Adding support in the DicomWebDataSource module and in the DataSource config file for the url, wadoUrlPrefix, qidoUrlPrefix and stowUrlPrefix parameters :

function createDicomWebApi(dicomWebConfig, UserAuthenticationService) {
  const {
    qidoRoot,
    wadoRoot,
    baseUrl,
    wadoUrlPrefix,
    qidoUrlPrefix,
    stowUrlPrefix,
    enableStudyLazyLoad,
    supportsFuzzyMatching,
    supportsWildcard,
    supportsReject,
    staticWado,
  } = dicomWebConfig;

  const dicomWebClientConfig = {
    url: baseUrl,
    wadoURLPrefix: wadoUrlPrefix,
    qidoURLPrefix: qidoUrlPrefix,
    stowURLPrefix: stowUrlPrefix,
    headers: UserAuthenticationService.getAuthorizationHeader(),
    errorInterceptor: errorHandler.getHTTPErrorHandler(),
  };

  const dicomWebClient = new api.DICOMwebClient(dicomWebClientConfig);

And I just replaced all the calls to the former WADO-RS and QIDO-RS clients to my new generic dicomWebClient.

I also updated the dicomweb-client dependency to the latest available version.

And, for the first time, I am now able to visualize my DICOMs with OHIF v3!

Now, I am sure that this naive modification have more implications and would probably break some things, but at least now we know that there is still an issue with the DICOMWeb clients as there are implemented now.

It would be great if we could manage to use just one client, but I guess we are using two of them for a reason

Topic		Replies	Views
How to retrieve and view a single DICOM instance using WADO-URI? Development	0	141	October 28, 2023
Multiple dicomweb datasources in OHIF v3 Support	0	291	October 25, 2022
OHIF + ORTHANC (Question) Support	0	96	December 15, 2023
Custom data source (minimal endpoints) Support	3	140	November 15, 2023
Viewer and DicomWeb on s3 Support	5	458	February 23, 2022

QIDO/WADO endpoints handling in OHIF v3

Related Topics