Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Key Image Object #3644

Open
sedghi opened this issue Sep 11, 2023 · 2 comments
Open

[Feature Request] Key Image Object #3644

sedghi opened this issue Sep 11, 2023 · 2 comments

Comments

@sedghi
Copy link
Member

sedghi commented Sep 11, 2023

What feature or change would you like to see made?

A key image is a clinically significant image has been flagged or marked by the interpreting physician. Because devices such as multi-slice CT and MR can generate studies that contain hundreds (if not thousands) of images, a mechanism for flagging and retrieving key images is critical. In a workflow that supports key images, other physicians such as surgeons or referring physicians can easily access the key images instead of having to browse the entire study. [1]

Hierarchy

Based on our research there seems to be two concepts

  1. Key Object Set

In which a set of objects can be referenced, e.g., referencing s:4 Image 5 and s:3 (the whole thing). A more complex scenario can also reference instances s:3 image 5 & s:7 instance 6 (notice "instance" instead of "image"). In this complex scenario, it means applying instance 6 (gsps, seg, rt, etc.) on the s:3 image 5. However, we will target the basic use case for now.

  1. Key Image Object Series

Which can store and reference couple of Key Object sets. Usually the newest one is of interest but should be possible in the UI for the user to select older ones as well.

image

Rendering KO

We believe it should be a similar viewport like the SR viewport, so have it as a temporary viewport that the user should be able to navigate across different images using the arrow buttons. As for loading, we can have some strategies. For instance, a simple use case can be: if the key object contains two series, make the grid 1x2 and load those series, then jump to those images.

Basically we need the following:

Marking Key Image Objects in Viewer:

  • Implement an intuitive user interface (UI) feature within the Viewer that allows users to designate a specific image or frame as a Key Image Object (KO).

  • This feature should include a clearly identifiable icon or button, tooltips for guidance, and a confirmation prompt to ensure deliberate marking.
    Use cases:

  • Ability to choose multiple studies and select images from separate series to create a Key Object (KO).

  • Ability to create a KO based on all available annotations.

Display of KOs in UI:

In the study browser panel, there should be a way to indicate the presence of key objects. Additionally, it should be possible to order or filter out certain sets based on configuration names, following specific ordering rules. (see #3644 (comment))

CleanShot 2024-05-28 at 17 36 39@2x

Why should we prioritize this feature?

It is a fairly common functionality in standard dicom viewers

e.g.,

https://weasis.org/en/tutorials/build-ko-pr/

https://documentation.clearcanvas.ca/Documentation/UsersGuide/Personal/13_1/index.html?key_images.htm

https://www.youtube.com/watch?v=CidK9c8YURQ

@sedghi
Copy link
Member Author

sedghi commented Sep 12, 2023

CleanShot 2023-09-11 at 21 54 19

@rbartonmedweb
Copy link

When marking a Key Object, the DICOM standard has some defined titles, "Of Interest" being the most common one for Radiologists. "Rejected for Quality Reasons" is also useful, there is a whole list. It would be best to provide a simple configuration item to limit this list to those that are appropriate. There is also an optional comment that might be enabled or not. It would also be nice to bypass any dialog and just toggle the key. Perhaps something like "keyTitles:['Of Interest'], keyComment:false,"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants