Introduction to Read Tasks

Disclaimer

Please note, Tasks is behind a feature flag and is being released to a limited number of customers for testing. If you are interested in hearing more about Tasks please contact your Flywheel Representative or submit a ticket request here.

Introduction

What is a Read Task?

Flywheel is dedicated to empowering our users to extract as much valuable information from their multimodal imaging data as possible in an easy and reproducible manner. One way we do this is through a new concept in our system called ‘Read Tasks’ (16.14 Release). These are human tasks with a specific set of data capture points and validation schemas aimed at gathering both objective image features as well as subjective form data about the image. The utility of this new feature set ranges from simplistic quality control reviews of images as they enter the system to detailed double-blinded reader studies.

A ‘Read Task’ is a set of actions that a reader, often a Radiologist, is assigned to perform. These actions can have a conditional logic and validation schema applied to ensure that they were performed correctly and that all necessary data has been captured. The components of a ‘Read Task’ are:

• Flywheel Project
• ‘Read’ Task Type
• Read Protocol
• Flywheel Container
• Task Assignee
• Date Due

Instruction Steps

Flywheel Project

The first data point needed for defining a Read Task is the Flywheel project in which you would like to perform this task. Once a project is selected, the subsequent inputs are filtered to only allow for valid inputs to be selected.

‘Read’ Task Type

Flywheel is actively working on expanding our human task options within the system to include actions such as Form Tasks, General Tasks (or Queries), Upload Tasks, and more. However, at this point, the only available option will be Read Tasks.

Read Protocol

The Read Protocol is a set of multiple customization options aimed at ensuring optimal Reader user experience (UX) as well as data quality. Multiple protocols can be defined in a single project and utilized in parallel workflows without the need to copy data to new projects. This allows your data to remain in place while it progresses through the data lifecycle inside Flywheel. The components of a Read Protocol are outlined below.

• Custom colors, either by individual label or a general palette to be used, for your annotations
• Logic for the number of annotations allowed with a given label and how they are able to interact with other defined labels

Hanging Protocol* Symmetric vs Asymmetric, modality, viewport type (2D vs 2D MPR), & series description for which image needs to go where

• Custom displays for specific workflows (EX: ETDRS Grid for OCT imaging)

Hotkeys and Mouse Actions* Define viewer tools and other presets, such as custom WW/WL definitions, to be invoked by either a keystroke or mouse action for optimal reader UX

Hide/Display Certain Items in the Toolbar* Hide the auxiliary tools that you won’t be using in your custom workflow

General Configuration Settings* Do you want to allow readers to “draft save” their work and return to it later?

• Capture the time it takes for readers to complete their workflows
• Disallow overlapping annotations to ensure that pixels are not being counted twice in downstream analysis
• Hide/display annotation outputs in the viewer itself | | Viewer Form Definition | Form Field Types* Short & long from free hand text
• Multiple choice, single answer
• Multiple choice, multiple answers
• Dropdown
• Button

General Logic* Conditional display logic for certain fields based on previous form field responses

• Mark a form field as “Required” to have an answer prior to submitting the read task for review

Required Annotation by Field Response* If a reader answers “X” require them to annotate the image using a specific annotation label, annotation tool, and switch their active tool to that automatically

Reader Instructions* Provide your readers with text, gif, video instructions directly in the viewer when prompted to perform a required annotation

• We also support the option to define an external link that can open a new tab with more robust documentation as well | | Protocol Definition | Key Components* Viewer Form & Configurations to be used
• Where the configuration should be saved in Flywheel
• The name & description for the protocol

Advanced Settings* Acquisition & file filters for the contents returned in a task |

Flywheel Container

Read Tasks are currently able to be assigned at either the session, acquisition or file to support multiple different workflows that may need to leverage single data points as well as the related imaging data as well. In addition to this scoping option, we also support filtering certain files and acquisitions out of a task by label if that level of granularity is beneficial.

In our first implementation of Read Tasks in the system, we are going to be leveraging a tagging filter to determine which containers should be assigned to which reader, for what workflow, and when. This will leverage the case randomization algorithms developed for historic iterations of reader studies in the system.

Assignee

This is the user in the system that is assigned to perform the specific read task on an image/file or collection of them. This is flexible and can be easily updated if the reader fails to perform the tasks or if someone else needs to own the workflow moving forward.

Due Date

Optional date.  This is the date the Task Administrator sets on each individual Read Task that tells the assignee (reader) when to complete each respective task by.  If overdue, it gets flagged for attention.  

Permissions

New permissions will be available in Roles which provides the user the ability to create, modify, delete and view reader tasks.  Depending on the Custom Roles you create, it will provide you with different results of what can be done.

For the current roles provided by Flywheel, the following individual permissions have been added to each:

• admin - ALL new task permissions are added by default for the site admin
• read-write - View Reader Tasks, Manage My Annotations, Manage My Viewer Form Data
• read-only - View Reader Tasks

Here is a screenshot of the new, individual Read Task permissions:

For Reader Studies, we recommend the following general Reader Workflow Custom Roles to be created and used.

• Task Admin Role:  A site admin can create a custom role to provide access for others to be Task Administrators.  If created, this is a person who has task administrative access and full view/control of the tasks within the projects to which they have access.  I can create, view, manage, and delete anything related to Tasks as long as they have the following sections in Roles all selected:
  • • Reader Tasks *View Reader Tasks
• Manage Reader Tasks

• Manage Viewer Protocol Definitions

  • Read Task Annotations
  • Manage My Annotations
  • View Others' Annotations
  • Edit Others' Annotations
  • Read Task Form Data
  • Manage My Viewer Form Data
  • View Others' Viewer Form Data
  • Edit Others' Viewer Form Data

• Reader Role: A site admin can create a custom role named Reader Role to provide access for others to be a reader (radiologist).  This will allow a user to be in the "Assignee" list and this is a user who is assigned tasks to complete in the viewer.  The following individual permissions should be selected and checked in order to be able to successfully launch and complete the reads:

  • • View Reader Task
• Manage My Viewer Form Data
• Manage My Annotations

Note: Task-level permissions work differently than other Flywheel permissions.  They apply simply to task-generated data and you have to make explicit decisions to launch or view multiple reader's data at the same time. This is different from the current viewer experience (pre-16.14).

Task List

The Task List is where a user can go frequently catch up on all tasks at the project or site level.  The Task List is available as a tab under the project or on the left navigation to see all Tasks across projects.  

Tasks from the project level:

Tasks from left navigation, site level:

A user will see the following columns and information on the Task List in columns:

Badge Count (displays on the left navigation)

A count of what is outstanding for the logged-in user to take care of will be on the Task List in the left navigation.  This does not display in the Project level version of the Task List.

Project

The project name that each task is associated with will display here.  

Task ID and Icon to Launch Viewer

The Task ID for a read task value will look like this: R-XX-XXX

Traditionally, reader study workflows leverage a batch case assignment model to provide radiologists with a set of tasks that they can realistically complete in a given timeframe.  By doing this, task administrators can ensure continued progress on data capture while also not overwhelming the Readers with hundreds of tasks at one time.  

As such, Flywheel opted to address the batch assignment workflow first with Read Tasks.  In order to assist the task managers in their visual review of task progress in the task list, we opted to provide a naming convention for our tasks that capture multiple elements.

The prefix is the task type (R stands for Read Task), the batch ID represents the batch assignment action which typically is a portion of the overall work to be done by a single radiologist by a given due date, and then the individual task count within that batch.

Example:

If reader 1 needs to complete 200 read tasks over the next month, the task admin may opt to divide that work up over four batches of 50 tasks and assign each batch to be done over a week span:

• Batch 1 = R-1-01, R-1-02, R-1-03... R-1-50 (Due EOW1)
• Batch 2 = R-2-01, R-2-01, R-2-03... R-2-50 (Due EOW2)
• Batch 3 = R-3-01, R-3-02, R-3-03... R-3-50 (Due EOW3)
• Batch 4 = R-4-01, R-4-02, R-4-03... R-4-50 (Due EOW4)

Task Type

The Task Type column for a Read Task will look like this: Read / Protocol Name

Read will display first indicating that this type of task is a Read Task. Flywheel Tasks will be expanded in the future to include other types like Form Tasks, Queries, etc.  At that time, this column will become more important.

The Protocol Name indicates the associated Protocol that was selected during creation will be listed second.

Container

The Task Admin can select one of three different levels of the FW hierarchy to associate a task with, including Sessions, Acquisitions, or Files.  The name of it will display in this column.  The viewer will open with this context.  This allows the Task Admin to scope up or down the information they provide to the reader.

Status

The status today can be To Do, In Progress, or Complete on each line item which will provide the Task Admin, or anyone else reviewing them, a clear status on where each Reader is with their task.

• To Do - the assignee has this on their list to do but they have not started it yet
• In Progress - the assignee has saved this as a draft
• Complete - the task has been completed by the assignee

Task Assignee

The Reader's avatar and name will appear here.

Due Date

The due date is set by the task admin for readers to be assigned batches of reads at one time, allowing them not to be overwhelmed.  The due date selected by the task admin will appear here in the format of Month Date, Year (example: Oct 21, 2022).  If overdue, a user will see it change to red text, with an overdue indication.  When a user hovers, they can see how many days past due it is.  

Task List Filters

There are three (3) high-level filters including All tasks, Assigned to me, and Created by me.

• All Tasks - This filter option is the default for an Administrator.  A user will see all tasks that they have access to see which could include tasks assigned and created by other users.  This would be best used by an administrator to see across project(s), assigned users, etc. to get an overall idea of where tasks are at for their Reader Studies.  
• This will still show for non-admin users, but those users will only have access to see their own if they are assigned any.
• There are quick filters to quickly see the tasks that are Assigned to me and Created by me (both applicable to the logged-in user). An example is shown in the image below:

Like other grids within Flywheel, a user can use the header to filter and/or sort each column. The tasks will display by default based on the creation date and chronological order.  Not all columns have the type ahead filtering as it wouldn't be very useful in some of the available columns.

The type ahead filtering is available for Task ID, and assignee columns.  A user can also drop down on assignee to see the options.  The dropdown filtering is available on the projects and status columns.  The columns can be sorted by Task ID, Assignee, Created, Due Date, and/or Status.  A user can sort by one column at a time but can be filtered by as many criteria as they see fit.

Creating a Task

A task Admin or user deemed a Task Creator can find the Task List and start creating tasks!

To create a New Task, a user will select the New Tasks button on the upper right-hand corner of the Tasks List, and enter the respective information, including Project, Task Type, Read Protocol, Container, Container Filters, Assignee, and Due Date.

Container Filters are completely optional.  They can be used to filter in or filter out (or both!) specific containers that have been tagged.  An example of this would be if there are tags in your study that are labeled QC_Passed and QC_Failed.  A Task Admin or Task Creator can include those that are tagged only as QC_Passed.  They could also, or, include a filter that does not include anything tagged as QC_Failed.

As a reminder, Task Type will default to Read Task until Flywheel has further expanded the definition of what Tasks are to other types outside of Read Tasks. This dropdown is not currently configurable.

To create more than one batch, a user can select the Create More Tasks option in the lower left corner before selecting Create or Clone.

Cloning Existing Tasks (to create new tasks with the same information)

The Clone Task button will allow a user to reuse an existing task and its respective information to create a new task or new batch of tasks. By clicking on the Clone button after opening a task from the Task List, it will open a pre-populated task creation screen.  This new task has all the same input parameters as the original (cloned) task.  The Task Admin will select the assignee (required) and due date (optional) in order to select Create. A Task Admin / Task Creator is able to create a clone of the previous task, even if all the information is the same.

We highly recommend cloning an existing task versus reassigning a task if you want the reader to start from scratch with the viewer workflow that you have assigned.  If you want the reader to pick up where another reader left off, it would be more appropriate to reassign the original task that may have been in progress.

Duplicate Workflow

The system will do an automatic check for duplicates upon hitting Create or Clone.

If the tasks defined upon creation are the same combination of assignee, container, and protocol, and it already exists as a task, it will display a list of tasks that are duplicates.  At this time, the user can do one of the following:

1. Cancel Task Creation - This option will close the modal and not create any tasks.  This allows the Task Admin or Task Creator to make any adjustments needed to mitigate the duplication.
2. Ignore Duplicates - This option will ignore the duplicates and will create all of them as individually unique tasks which can be reviewed in the Task List.
3. Cancel - This option will go back to the edit screen where the Task Admin or Task Creator can continue to make changes prior to creating the tasks.

Deleting a Task

To delete an existing Task, a user can open the respective task and select the Delete button on the bottom right-hand button menu.

If a user wants to delete more than one task at a time, the optimal way is from the Task List.  They would select any of the Tasks they want to delete, and a Delete Selected Tasks button will display in the upper right-hand corner.  The user can select that button and watch all the selected tasks disappear from the Task List.

Editing an Existing Task

A Task Admin can edit the Assignee, Date Due, and Status of any existing tasks.  At this time, if a Task Admin needs to edit any of the other information (read protocol, container, filters), the solution is to delete the tasks and re-create them.

Editing a task includes the ability to reassign a task to a new user.  For example, if Reader A couldn't complete the read or you want someone else to take over the In Progress task for any other reason, you can simply reassign the task to another user who would then be Reader B.  Please note that if you want the user to start that particular read task from scratch, we would recommend cloning the existing task and closing the original task that Reader A had started.

Success Indications

Throughout this workflow, a user will be able to see the green success notifications in the upper right-hand corner of the screen.  Users are able to clear those notifications if they need but they do automatically go away on their own after a few seconds.  

__