You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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))
Why should we prioritize this feature?
It is a fairly common functionality in standard dicom viewers
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,"
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
In which a set of objects can be referenced, e.g., referencing
s:4 Image 5
ands:3
(the whole thing). A more complex scenario can also reference instancess: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 thes:3 image 5
. However, we will target the basic use case for now.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.
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))
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
The text was updated successfully, but these errors were encountered: