Quick lists of terminology entries

[cpinter]

It would be much more convenient for the user if instead of having to go through the lengthy lists in the big terminology they had the option to create quick lists of the used entries (we also called these presets).

Proposition:

• Storage: Have a private scene for the terminology logic that contains segmentation nodes with empty segments, one each for one saved entry. This private scene can also be saved with the Slicer scene.
• Selection: A segment table would show the quick list where the user can see the names and colors of the entries, and could also add/remove/edit, just as with an actual segmentation. This table could be shown in the terminology navigator. Switching between the quick lists could be done by a combobox that lists the segmentation nodes (=quick lists) in the private scene. Exact place TBD

[cpinter]

@fedorov @lasso @che85 How about something like this below? A radio button on top would switch between quick list view and full context view (which is the current content). The button next to the quick list selector would add a new empty quick list (maybe also one for removal would be needed), and we can populate it from the context view. In my drawing there is a button under the type modifier combobox, but there could be a button elsewhere to add the current selection as a new item in the selected quick list (in context view the quick list selector combobox would not be deactivated). Suggestions are welcome.

[fedorov]

@cpinter looks good! Few comments:

• in your expanded view of Quick list widget, should it show category/type, or just the shorthand label? I would prefer to be able to see category/type either directly, or in a tooltip
• will anatomic region be part of the quick list entry, or will it be specified separately?

[cpinter]

Thanks @fedorov

• By default it shows the short name, and all the info in a tooltip, just as in the segment table in Segment Editor. Anything can be changed though.
• Anatomic region information included (the doodle was originally just for me and I was lazy to draw all three sections)

I talked to Andras in person, and he also agreed with the gneral idea, but he'd like the quick list to be also shown when adding items to it, so that the user can see what is in there already. I think it makes sense, so I'll implement it that way if you agree as well.

We also went into details a bit more, and made initial decisions about what to disable when and what interactions would do what exactly when editing. As we'll certainly see issues and will have new ideas after me finishing the first implementation, I'd start with what seems best right now (you also agreed to the basic design, so it seems like a good enough starting point), and make changes as we start using it. What do you think?

[fedorov]

Anatomic region information included

We should think how to make it more flexible. I think separate quick lists for category/type and anatomic region make sense. Think about a situation when someone outlines tumor in the lung. Category/type will always be "Morphologically altered structure/Nodule", but anatomic location will change depending on where in the lungs the tumor is located. So the anatomic region quick list could contain things like "left upper lobe" etc as shortcuts for the combination of code+modifier.

I think this issue makes sense to incorporate into the design from the start. Otherwise I agree it makes sense to start implementing and modify as needed later.

[cpinter]

Category/type will always be "Morphologically altered structure/Nodule", but anatomic location will change depending on where in the lungs the tumor is located

If the category/type is fixed, then why not have the different locations for the tumor in the same list? If the user doesn't use those anatomic regions for other category/type, then I think there is no gain to put them in separate lists.

[fedorov]

In this situation that I described, they would always have to use anatomic location. If you want to have them on the same list, then potentially you would need to have (number of category/type items)x(number of anatomic locations items) items in the quick list. For the applications such as where you want to annotate same category/type, but for different body parts, I think keeping separate quick lists is better. Ideally, this would be a configurable options for the specific quick list (whether to keep anatomy together or separate).

[cpinter]

Yes if (number of category/type items) for which you want to use the whole subset of anatomical regions is higher than one, then the list will grow long. In the example you said this number is 1 ("Category/type will always be 'Morphologically altered structure/Nodule'"), so this wouldn't be an issue. Can you imagine a scenario where it is higher than 1?

[fedorov]

Can you imagine a scenario where it is higher than 1?

Oh, that's very easy: e.g., you can have brain tumor that has different components that need to be annotated separately, in prostate applications, we very often annotate tumor and normal to compare.

But as a contra-argument - as an alternative to quick lists, we could also define short and concise application-specific segmentation contexts.

Conceptually, in your view, what are the advantages of quick list over a short subset of items from a bugger list? Also, how do you plan to serialize its content?

[lassoan]

In my segmentation tasks, I usually know exactly what structures the image may contain and would like to fully specify all aspects and just select using a single click.

For cases when you don't exactly know what you'll have in the image (for example you may have multiple tumors or cysts) you can add tumor 2, tumor 3, etc. items to the quick list.

Some mechanism would be needed to only show in the quick list those items are already used in the segmentation and probably even allow to hide those (e.g., if I already used tumor and tumor2 segment then I would prefer to hide those and only see tumor3 in the quick list).

Also, it may be useful to associate custom (reduced and/or expanded) dictionaries with a quick list, so that if I need to make some adjustments then I would not see so many irrelevant entries.

[fedorov]

I usually know exactly what structures the image may contain and would like to fully specify all aspects and just select using a single click

Right - so that is something that would be problematic for the tasks we deal with. For prostate segmentation tasks, as I said, there is (at least!) normal/tumor for the category/type, but location for each can be one of the 20+ prostate areas defined by PI-RADS. So in this case, quick lists will actually make the task of selection more complicated (single long list instead of 2 shorter ones).

But if you see value in this, and you don't mind investing resources into implementing and refining it, then perhaps it makes sense to implement it. It will not replace the shorter segmentation contexts, so users will be able to choose what is more applicable in a specific usage scenario.

[fedorov]

For completeness, and to illustrate my earlier comment about short application-specific contexts, see these segmentation and anatomic region contexts for the PET HNC segmentation use case:

• https://github.com/QIICR/PETTumorSegmentation/blob/master/SegmentEditorPETTumorSegmentationEffect/SegmentationCategoryTypeModifier-HeadAndNeckCancer.json
• https://github.com/QIICR/PETTumorSegmentation/blob/master/SegmentEditorPETTumorSegmentationEffect/AnatomicRegionAndModifier-DICOM-HeadAndNeckCancer.json

[cpinter]

Thanks, Andrey! Short contexts indeed seem to be more useful in the use cases you mentioned.

don't mind investing resources into implementing and refining it

If this is not a generally useful feature, I can easily imagine more productive ways to spend the 3-4 weeks that would take me implementing this. In Andras' case, what I'd do is probably create a template segmentation containing empty segments (with their proper terminologies) that may be useful in that segmentation task. Then when I start a new segmentation, I'd load that segmentation, maybe clone it in SH so that I can create a new one easily for the next segmentation, and start filling those empty segments in Segment Editor. I don't see this being more work for the user than using the quick lists feature proposed here. We agreed with Andras that implementing the quick lists will yield a super complex widget at the end in any case, which for "regular" users might be too hard to use.

[pieper]

+1 to the idea of using existing segmentations as templates. No reason to make a different tool to select subsets of terms.

[fedorov]

@cpinter I am glad I could help by providing another perspective. If we discover over time that we missed something, we should definitely revisit this issue, but perhaps indeed for now your time would be better spent on other tasks, which I am sure you have many!

[cpinter]

Thanks for the comments and opinions! It sounds like we misunderstood something back when we added this issue, and there is no real need for it right now. I didn't get too far in the implementation so I'm happy we figured this out early!

I suggest closing this issue and re-opening it or adding a new one if the this arises again in the future.