Expected behavior for studies that contain a single SR should be refined

[fedorov]

This study contains a single SR series, but the SR series does not show up in the list on the left.

https://idc-sandbox-000.firebaseapp.com/projects/idc-dev-etl/locations/us-central1/datasets/idc/dicomStores/v2/study/1.3.6.1.4.1.5962.1.1.0.0.0.1563690660.7173.1309

[igoroctaviano]

@fedorov Currently, the sorting series function had only two supported SR sop classes ((Enhanced SR Storage and Grayscale Softcopy Presentation State Storage) in its array:

Viewers/platform/core/src/DICOMSR/utils/findMostRecentStructuredReport.js

Line 41 in 2f443fa

const supportedSopClassUIDs = [

• I tried adding the one in this series (Acquisition Context SR Storage) but now I'm getting errors in dcmjs: Error: This package can currently only interpret DICOM SR TID 1500.
• I have created a PR to notify the user on SR related errors: IDC-2348: Add acquisition storage sr sopclass to sr html ext #2352

[fedorov]

Currently, the sorting series function had only two supported SR sop classes ((Enhanced SR Storage and Grayscale Softcopy Presentation State Storage) in its array

I think that should be revised. TID 1500 instances can be saved as Comprehensive SR storage, so that is not a good assumption to have.

This package can currently only interpret DICOM SR TID 1500.

I would also think that display of the SR content as text should be supported for any SR, independent of the template. Do you agree? I think the current constraints are too limiting.

[igoroctaviano]

Currently, the sorting series function had only two supported SR sop classes ((Enhanced SR Storage and Grayscale Softcopy Presentation State Storage) in its array

I think that should be revised. TID 1500 instances can be saved as Comprehensive SR storage, so that is not a good assumption to have.

This package can currently only interpret DICOM SR TID 1500.

I would also think that display of the SR content as text should be supported for any SR, independent of the template. Do you agree? I think the current constraints are too limiting.

@fedorov Just to clarify, this dataset contains ContentTemplateSequence.TemplateIdentifier === "8101" and the dcmjs cornerstone adapter can currently only interpret DICOM SR TID 1500. We should update dcmjs cornerstone adapter to interpret 8101?

[fedorov]

I think the dcmjs adapter should be updated to read the SR content tree, independent of the template encoded, to produce SR format similar to what DCMTK dsr2html does, as illustrated here: https://peerj.com/articles/2057/#fig-7, or by the Pixelmed tools, as illustrated below (image credit: https://github.com/dcmjs-org/data/releases/download/DICOMSR_AIM_Test/DICOMSR_Test.zip). Identification of tree patterns specific to a given template is a higher order operation, which should not be needed for basic rendering of the SR content in a human-readable form.

[pieper]

Agreed, yes, a nicely formatted SR would be a good addition.

[igoroctaviano]

PR Updated. #2352
@Punzo can you take a look/test?

[igoroctaviano]

https://peerj.com/articles/2057/#fig-7

@fedorov I have updated the PR to allow the rendering of this SOP in the formatted HTML/SR extension. It should render this SR as an HTML page in the viewport like we currently see in OHIF for other SRs. But now I'm wondering if you want to improve that extension to render differently as well? I mean, with collapsible nodes like in your example?

[fedorov]

Yes, it would be nice, but not urgent. I think implementation of a more user-friendly rendering should be done both for the DICOM Tag view (to support collapsible sequences) and SR view in a similar way. Let's add a separate issue for improved rendering?

[igoroctaviano]

Yes, it would be nice, but not urgent. I think implementation of a more user-friendly rendering should be done both for the DICOM Tag view (to support collapsible sequences) and SR view in a similar way. Let's add a separate issue for improved rendering?

That makes sense, issue created: #2372.

[fedorov]

When I open the URL in the initial post of the issue, I get the following at the bottom of the SR view - this must be wrong, no?

[igoroctaviano]

When I open the URL in the initial post of the issue, I get the following at the bottom of the SR view - this must be wrong, no?

Maybe there's something wrong in dcmjs or in HTML extension, this task didn't make any changes to the parsing logic, it only included more sop classes. I'll investigate and let you know.

[igoroctaviano]

@fedorov fixed here: #2419

These tags are dicom meta info which was not naturalized before they were sent to the parsing function in dicom-html extension. Now I have added a new section to better display this info.