I have been working on some changes to the QuantitativeReporting plugin for loading DICOM Structured Reports. Currently, the extension supports the loading of measurements. Now, we can load and display bounding boxes, lines, and points. It would be great to get feedback on how I can improve the UI. For instance, I could include automatic jumping to a slice when a markup is clicked, or when an entry in the table is selected.
Here is a gif for loading and displaying a bounding box:
Hi Deepa - it’s great you are working on this. My thought would be to have a custom module that’s specific to the concept of a report. It looks like now the SR is being parsed and the data is extracted into markups and tables, but other than having them in the same subject hierachy study, the idea that they all came from the same report is somehow lost. It’s possible in the markups module to jump the slices to markup control points, but it would be nice to centralize this for the specific task of reviewing a report or comparing multiple reports.
It would be intestesting to look as some of the use cases where there is a clinical intent behind the SRs, like in the older QIICR datasets where there were lesion annotations from multiple raters and you’d want ways to load multiple SRs and easily compare the data across raters (e.g. turn all markups for one rater on/off or make the markups from one report yellow and all the ones from a second report blue).
Steve, I had similar thoughts when we reviewed this with Deepa, but how can this be remedied? Is there a concept in the subject hierarchy that would map to an SR series and could have those measurements as children? Or do we need to introduce a new node?
I think you can easily create a folder in the subject hiearchy that corresponds to a report (even named by SeriesDescription or other attributes) and put all the extracted markups inside that folder inside the dicom study.
For the actual implementation, we should probably use SeriesDescription content for the name of that folder.
@pieper you are saying we should not create a dedicated MRML node that would correspond to the SR series containing those measurements, and folder is sufficient?
@DeepaKrishnaswamy yes, that looks like what I had in mind. I agree the name should come from the SeriesDescription.
@fedorov I think it depends on how sophisticated you intend to be. The folder seems like enough just to keep things organized. I think you should check if it handles things like hierarchical visibility control (can you click the eye on the folder and turn on/off all the markups in the folder? Maybe that needs to be explicitly programmed.). Also can you drag the folder to a view and have the markups show up only in that view? I.e. so you can compare two SRs side by side. These features would make them act more like segmentations.
Also do you want to create this kind of SR in Slicer or just consume existing ones? If you want to create them then a custom module with custom nodes (probably scripted) would make sense.
This approach works well if the SR has a referenced series. However, in the case of a SCOORD3D point where a FrameOfReferenceUID is used, I would need to come up with a nice way to name the folder.
I would use SeriesDescription (or SeriesNumber:SeriesDescription) as the name for the folder - I believe this is what is done for other items in the hierarchy that match DICOM series.
