Support fetching of all data from both primary and secondary DICOM store in the URL

[fedorov]

With this URL, I do not see any derived series (ANN, SEG):

https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0?gcp=https://healthcare.googleapis.com/v1/projects/idc-dicom-review/locations/us-central1/datasets/gbm-parametric-map-test-heatmap-2025-08-06-dataset/dicomStores/gbm-parametric-map-test-heatmap-2025-08-06-dicom-store

If I drop the secondary store, I do!

https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0

[igoroctaviano]

With this URL, I do not see any derived series (ANN, SEG):

https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0?gcp=https://healthcare.googleapis.com/v1/projects/idc-dicom-review/locations/us-central1/datasets/gbm-parametric-map-test-heatmap-2025-08-06-dataset/dicomStores/gbm-parametric-map-test-heatmap-2025-08-06-dicom-store

If I drop the secondary store, I do!

https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0

@fedorov can you enable localhost:3000? i'm getting cors trying this url. Or maybe you have another study + gcp query param example i could use?

[fedorov]

It is using the same GitHub actions workflow config that you set up - nothing changed!

Did you try the store in #321 (comment)? @CPBridge says he gave you the permissions.

[igoroctaviano]

It is using the same GitHub actions workflow config that you set up - nothing changed!

Did you try the store in #321 (comment)? @CPBridge says he gave you the permissions.

Sounds good. I'm getting CORS trying to use localhost, but I'll investigate why. Thx.

[igoroctaviano]

@fedorov https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0 already has ann / derived data. Maybe you can share another example that does not have derived data, so we can test the GCP param?

[fedorov]

Igor, the fact that the primary store has derived data should definitely not prevent loading of derived data from the store specified in the gcp param. Are you saying this is a feature?!

[igoroctaviano]

Igor, the fact that the primary store has derived data should definitely not prevent loading of derived data from the store specified in the gcp param. Are you saying this is a feature?!

@fedorov, it doesn't I think but if it's the same derived data, then you can't spot the differences.

[fedorov]

It should not be the same, right @CPBridge ? Just the PMs I would think.

[CPBridge]

Correct. The main IDC store has some segmentations and ANNs for this study. The additional store has only parametric maps (none of which are present in the main IDC store)

[igoroctaviano]

@fedorov this works for me: https://viewers-sandbox-gha-testing.web.app/studies/2.25.68803095896966276583382138924964839274/series/1.3.6.1.4.1.5962.99.1.1139028448.995765201.1637521600992.2.0?gcp=https://healthcare.googleapis.com/v1/projects/idc-dicom-review/locations/us-central1/datasets/gbm-parametric-map-test--heatmap-2025-08-06-dataset/dicomStores/gbm-parametric-map-test--heatmap-2025-08-06-dicom-store/dicomWeb

I can see the parametric maps now. One thing I noticed, though — the viewer doesn’t seem to retrieve derived data from both the default store and the one specified via query param. It pulls images from the default store, but retrieves derived data only from the store provided in the query param. Is this the expected behavior?

[fedorov]

It pulls images from the default store, but retrieves derived data only from the store provided in the query param. Is this the expected behavior?

I didn't think so, and I flagged precisely this as a regression in the initial comment! I am pretty sure it should pull derived series from the primary store. I am quite confident it did it in the past, and I know for sure this is what we in OHIF, and we should be consistent.

[igoroctaviano]

It pulls images from the default store, but retrieves derived data only from the store provided in the query param. Is this the expected behavior?

I didn't think so, and I flagged precisely this as a regression in the initial comment! I am pretty sure it should pull derived series from the primary store. I am quite confident it did it in the past, and I know for sure this is what we in OHIF, and we should be consistent.

Your primary store for this deployment is proxy-dev, so that’s where the images are being fetched from. The queryParam is used to fetch complementary data (like annotations) from a secondary store.

In OHIF, this is the expected behavior:

The primary handles image fetching

The queryParam handles annotations or other derived data
I know this applies here because the primary is also used for the worklist, so it’s definitely active.

The point I’m making is that, in OHIF, you can have:
→ Primary images
→ Derived data from the primary (e.g., annotations already there)
→ Additional derived data via queryParam (from a secondary store)

So, if the primary store already has annotations, you’d expect to get both:
→ those annotations (ANN) from the primary
→ plus whatever additional derived data is in the secondary

But that’s not what’s happening in SLIM. When using queryParam, it's only fetching derived data from the secondary, and ignoring what's in the primary.

[fedorov]

But that’s not what’s happening in SLIM.

Got it, I just didn't know if this is the expected behavior, and assumed it is a regression.

If this is the expected behavior, let's reclassify this issue as "enhancement", I will change the title, and we lower its priority - not a priority to implement this now!

[CPBridge]

When using queryParam, it's only fetching derived data from the secondary, and ignoring what's in the primary.

This was my observation too, and not what I expected