[Feature Request] Automate tracking prompts for a less disruptive annotation workflow

[sen-trenser]

What feature or change would you like to see made?

Currently OHIF asks a lot of prompts for tracking in different scenarios. This would be confusing for a user to understand what is tracking, untracking etc. The current tracking workflow is documented here. This is alleviated in v3.9 with the appConfig.disableConfirmationPrompts config.

This feature request is for further simplifying the UX for the underlying tracking workflow and reducing the involvement by users for workflow decisions (assuming the user wants the tracking workflow to update automatically with what he does with annotation or SR reports).
This proposal is to remove the below scenarios from a user perspective based on the same configuration.

• "Untracked" annotations (Except non-acquisition oriented viewports in MPR views).
• Displaying locked measurements in SR preview viewport.

The existing tracking workflow could be kept under the appConfig.disableConfirmationPrompts config.

The below is the attached diagram for the proposed workflow..

Please share your suggestions or any preferred alternative suggestions to implement this requirements.

Why should we prioritize this feature?

This will provide an easier and better experience for the users.
This will also allows users to track measurement changes and allows to save their changes when necessary.

This proposal is to discuss and align the future plan from OHIF and ours to provide a better experience for users. We (Flywheel) would also plan to contribute the proposed changes to Cornerstone3D (for measurement changes tracking) and OHIF for the workflow changes once the proposal is approved.

Could you please prioritize this?

[sedghi]

I think it makes sense to have three options for tracking, the "standard" (current), the "simplified" and "none" for disable, so we get rid of the appConfig.disableConfirmationPrompts and just have appConfig.measurementTrackingMode

Is this workflow something you have iterated on based on your user interviews?

[kgoettler]

@sedghi to confirm my understanding:

• standard: current tracking workflow
• simplified: disable all prompts, except those mentioned by @sen-trenser above
• none: no tracking whatsoever (all measurements will be untracked)

Do I have that correct?

Is this workflow something you have iterated on based on your user interviews?

Yes. We've heard from users that they expect tracked measurements to be the default behavior, as they have little need for untracked measurements. The solution we've described here is the most straightforward way we've found to accomplish this without having to remove the measurement tracking functionality entirely (though if there was a way to do this while preserving the ability to save/export measurements as SR, we'd be interested in exploring that).

[sedghi]

@james-hanks

[james-hanks]

Agreed to review PR for config level change to allow simplified measurement tracking. Will review user data for future measurement tracking iteration

[sen-trenser]

@james-hanks @sedghi We require Cornerstone modifications to track modified annotations with a dirty flag. Can we upgrade Cornerstone3D with the OHIF PR for these changes to enable this workflow?

We would like to understand if there are no known compatibility issues in the latest version of CS3D that would prevent us from using it with OHIF 3.10. We would greatly appreciate any insights or advice you can provide on this matter.

What is the frequency of Cornerstone package upgrades in OHIF?

Thank you!

[sedghi]

Can you explain why cornerstone modifications are needed? What does the current flow do inside cornerstone3D, or it does not do it in cs3d

[sen-trenser]

@sedghi We are planning to have the isDirty flag as a state of cs3d annotation tools itself similar to Lock/Visibility/Selection states of annotations. This can later be consumed by OHIF's measurement services to set or reset annotation dirty state based on annotation modification events, color change, label change or SR save workflow etc.

As _calculateCachedStats() of annotations trigger the ANNOTATION_MODIFIED event on first annotation render after loading an SR file, it would set the dirty flag on SR report loading/scrolling/jumpToMeasurement itself. So we would like to avoid using the ANNOTATION_MODIFIED event to set dirty flag. In order to identify the actual changes that affects the created SR report content, we would also like to add two events for ANNOTATION_POINTS_MODIFIED and ANNOTATION_TEXT_BOX_MODIFIED as well.

[sedghi]

I am still struggling to understand why we need a dirty api for having SR. and even if we do why inside cs3d. Maybe we discuss it in this week's office hours?

[sen-trenser]

Based on the discussion in Office hours, the below path was suggested.

Use measurement service tracking instead of modifying Cornerstone.
Check the annotation modified event with change types for better control.
The PR 4686 is WIP, that changes the tracking flow and handles multiple studies measurement display. Any changes to workflow if needed, should be done based on that PR.

On further analysis, the change type is not properly set in cs3d for annotation modified events.

The below list is the current change types used.

The below list would be an ideal** change type to implement.

** The StatsUpdated ChangeType triggered from renderAnnotation() would cause duplicate annotation modified events. This may also fire from scrolling after SR loading or scrolling after interpolation. If possible, this may need calculation at the time points are modified/SR is loaded, and then the modified event could be triggered.

We would also like to introduce LabelChange as a new change type.

@sedghi We are also waiting for our PO to have some suggestion for untracked annotation's behavior with annotations in multiple studies.
Currently we are working on the cornerstone changes needed for correcting the ChangeTypes in annotation modified event. Is it okay to update the proposed changeTypes list partially in cs3d (to unblock this workflow) as given in above image?

[sedghi]

Let's do like only one tool say Length with proposed change and have a PR and we can look and discuss

[nithin-trenser]

@sedghi We have created a PR with proposed change in Length tool. Could you please have a look into it?
cornerstonejs/cornerstone3D#1821
cc: @sen-trenser