Viewers icon indicating copy to clipboard operation
Viewers copied to clipboard

[Bug] QIDO /series call issued with additional WADO /frames like value in the accept header.

Open awsjpleger opened this issue 3 months ago • 1 comments

Describe the Bug

Hi all,

I have been using OHIF for a while now, but this is my first time opening an issue. I'd like to take this opportunity to thank all the contributors to this wonderful project.

While integrating OHIF with the AWS HealthImaging DICOMWeb API, I encountered an interesting issue related to how Accept headers are crafted and reused with wadoDicomWebClient.

I'm not very familiar with the codebase, and what follows is based on my partial understanding of the application. I might be wrong:

The application creates a wadoDicomWebClient object that is used for metadata retrieval operations and reused by some extensions to fetch images. The application logic determines which path to take to obtain the metadata, and when the configuration setting "enableStudyLazyLoad: true" is set, the metadata loader will use the WADO DICOMWeb client to call a QIDO /series query, so that it can discover SeriesUID and get granular series level metadata. When doing so the WADO client is being used and the QIDO request is configured with an Accept header that has multiple values: The accept header contains the expected QIDO /series accept header value, and a WADO /frames type accept value:

application/dicom+json, multipart/related; type="application/octet-stream"; transfer-syntax="*"

I assume that for most DICOMWeb origin servers this doesn't matter since one of the values is a correct "application/dicom+json" option. As mentioned above, I'm integrating OHIF with AWS HealthImaging and the service has rather strict Accept header verification rules, causing this request to fail.

To work around this issue, I made a small modification to the file extensions/default/src/DicomWebDataSource/wado/retrieveMetadataLoaderAsync.js by adding the line delete client.headers.Accept; before the searchForSeries function call is added to the loader, like so:

export default class RetrieveMetadataLoaderAsync extends RetrieveMetadataLoader {
  /**
   * @returns {Array} Array of preLoaders. To be consumed as queue
   */
  *getPreLoaders() {
    const preLoaders = [];
    const { studyInstanceUID, filters: { seriesInstanceUID } = {}, client } = this;

    // asking to include Series Date, Series Time, Series Description
    // and Series Number in the series metadata returned to better sort series
    // in preLoad function
    let options = {
      studyInstanceUID,
      queryParams: {
        includefield: includeField,
      },
    };

    delete client.headers.Accept;
    if (seriesInstanceUID) {
      options.queryParams.SeriesInstanceUID = seriesInstanceUID;
      preLoaders.push(client.searchForSeries.bind(client, options));
    }
    // Fallback preloader
    preLoaders.push(client.searchForSeries.bind(client, options));

    yield* preLoaders;
  }

With this change, the dicomweb-client searchForSeries function is called with the default Accept header generated by the dicomweb-client itself, which result in "application/dicom+json" only, fixing my issue.

As said I'm not very familiar with the code base, and I found that DICOMWeb headers management is topic actually discussed in other issues recently. Maybe there is a better way to work around this one ? If not, besides fixing the specific compatibility with AWS HealthImaging, this change makes the /series call more aligned with the DICOMWeb standard.

Could we consider bringing this code change into the project main ?

Regards,

JP

Steps to Reproduce

  1. Configure OHIF to and AWS HealthImaging DICOMWeb endpoint ( using OIDC ).
  2. Set the enableStudyLazyLoad to true in the configuration.
  3. Select any study from the OHIF StudyList
  4. Series discovery fail can be observed in the browser dev tool network monitoring while /series is called.

The current behavior

The call to /series is sent to the AWS HealthImaging DICOMWeb endpoint with an multi-value Accept Header like this :

application/dicom+json, multipart/related; type="application/octet-stream"; transfer-syntax="*"

Causing the AWS HealthImaging API to return :

Error 40 Bad request

Response Body : { "message": "1 validation error detected: acceptHeader failed to satisfy constraint: Member must satisfy regular expression pattern: application/dicom\+json" }

The expected behavior

The Accept header crafted for the QIDO /series call contains the only one value : "application/dicom+json"

System Information

Any AWS HealthImaging datastore DICOMWeb API.

awsjpleger avatar Sep 29 '25 18:09 awsjpleger

anyone working on this?

pyoneerC avatar Oct 27 '25 19:10 pyoneerC