Missing studies when using google integration

Bug Report

Study browser interfacing google healthcare DICOM is not showing all of the studies that are available in a datastore.

Describe the Bug

I do not know how widespread this problem is, but …

If I use this specific instantiation of OHIF interfacing google DICOM datastore qin-headneck, only 2 studies are shown for PatientID QIN-HEADNECK-01-0003: https://idc-sandbox-000.firebaseapp.com/projects/chc-tcia/locations/us-central1/datasets/qin-headneck/dicomStores/qin-headneck.

I know that patient has 4 studies.

Interestingly, if I manually specify StudyInstanceUID for a missing study, it does load:

https://idc-sandbox-000.firebaseapp.com/projects/chc-tcia/locations/us-central1/datasets/qin-headneck/dicomStores/qin-headneck/study/1.3.6.1.4.1.14519.5.2.1.2744.7002.150059977302243314164020079415

What steps can we follow to reproduce the bug?

You will need access to the IDC project idc-sandbox-000, or you would need to set up another google integration. The dataset is in the public TCIA offering of Google Healthcare. Navigate to datastore qin-headneck, the subject in question is at the top of the list.

This was tested with OHIF 3.3.8.

cc: @dzelemba

[pieper]

Hi @dzelemba - the sandbox app is just a statically hosted ohif instance - only the data is access-controlled (makes perfect sense that your account has access to the TCIA collections 😄 )

As for the underlying issue, I believe it is the sort-order and the limit on the qido query. If I enter QIN-HEADNECK-01-0003 and search for it by MRN I get four studies, but if I sort the list by MRN I only see 2. This is because the OHIF studylist doesn’t do a QIDO query when the sort order changes. Also since the QIDO call result is not sorted by MRN only a random subset of the collection is in the studylist and available for sorting. I don’t think think this is a google issue, just OHIF and the way the standard works.

[dannyrb]

Most implementations I’ve come across simply maintain a list of studies and their metadata separately from the PACS so it can be queried free from the limitations of DICOMWeb, or they impose the limitations you’ve described. There are options for strength/full text search that are performant for millions of rows.

If we know the dataset is small enough, we could request it entirely and perform sorting on the client. We could also provide the ability to map search fields to a function that generates the request, and an optional function to map the request’s data to the expected table result format (opening the door to non-dicomweb querying).