Action Items Report

Staying up to Date With Data Entry, Queries, and Review

The action items report displays the following information:

NOTE: The last two bullet items above can be found in the Action Items Report Example below.


Prerequisite: The user has access to the Action Items Report

Access Action Items in the Reports menu on the web browser or mobile app.

Web Browser:

aiwebmenu

Mobile App:

Once open, tap one of the sections to expand the list. This action will cause the records to be retrieved and a count to display:

A metric for each section will display based on the number of records in that section. Read below for more information on each section of this report.

Note about the counts displayed:

Metrics on the Web Browser will display the number for whatever is being filtered and shown in the table.

On the Mobile App, the metric will always display the number of records across all Provider sites that the current user is a member of. Once the list is opened up, the list may show other provider site data if the user is not a direct member of the site but has access to the data.


Forms With Open Queries

This section displays all forms that have at least one open query. It can be filtered based on query routing status as well. This will provide a list of all forms that have at least one query that is routed to the selected level. 

An alternative and more detailed look at the same information is in the Queries Report.

 


Data Changes Awaiting Reasons

These are records where data was changed but a reason was not provided by the user. The system keeps this as an action item because data workflow will be prevented until the change reasons are provided.

Batch Reasons

Prerequisite: User has access to Action Items Report, Provide Change Reasons In Batch

In the event a large list of flagged records exist - normally the result of data changes made in a version migration or Administrative run of computations - The reasons can be provided in batch groups. This is done via a “Resolve All” button.

When Resolve All is used, it will apply that reason to all records that are currently being filtered in the table. Filtering can be done via the search box based on any column in the table (form name, visit name, the user who made the change, etc).

If Resolving All on changed data from a version migration or re-run of edit checks, it works best to filter by the user who made the change because a single user will have been attached to those changes. 

 


Missing Forms

This report includes forms that are required within the visit schedule and the visit window   passed before the subject exited the study.

The number displayed will be based on the last time the system updated the table for the study. If the date last updated does not match today's date, it can be refreshed with the rebuild button.

If the system is currently working to update the list, it will indicate the message below.

On a given day, if the report has already been rebuilt, other users in the study will see that updated listing without needing to perform the same action.

A form is missing if:

  • The form is required in a visit schedule, the form’s visit window has passed, and the form has not yet been saved
  • The form is not hidden by a condition
  • The subject has not exited the study with a date that falls within the visit window
  • The form's corresponding visit window has been computed (is not "TBD" based on another dependent visit)

The number of missing records is also reflected in the Dashboard Report.

 


Workflow Review Levels

Forms that are ready for the corresponding review level to perform the review task.

Prerequisite: The current user's role is assigned to the workflow level and that user role has access to the Action items report or;

The user role has access to the Action items report, Review action items

In the resulting list, a reviewer can tap on the 'Go To Form' column to open the record for review or use the subject ID to open that subject's casebook.

If batch activities have been enabled by the study Administrator, there will also be checkboxes on the table to select batches of records for performing review or bypassing review. Read more here about how to batch review or bypass the records listed in the table.

AIreviewLevel

For larger studies, the table will show data but may continue updating the count displayed in the section header. If all records are needed for exporting purposes, wait until the section header indicates the loading is complete.

If a review level requires field-level source verification (FLSV), those records will also display, even if all the fields on the form have not been source verified. If the reviewing user has permission to batch review, any records requiring FLSV will not be batch reviewed unless all fields on the form are first locked.
For users with access to bypass records in review, FLSV fields will be ignored and the records will be pushed to the next workflow level (if applicable).


Factors that can prevent records from being ready for review:

  • Contains open queries
  • Data changes flagged and awaiting a reason
  • Forms omitted at a given workflow level based on the form design
  • Not yet reviewed at the previous level

Filtering for Records that have had Lock Broken

The list of records ready for review provide a "Lock Broken" filter that allows a user to see a list of only records that were once reviewed, but where the lock was broken at some defined time period.

 

One scenario where this can be useful is if a version migration caused a computed value to change a large number of records, which in turn caused them to become unlocked. By setting this filter, a date range can be entered (the period of time when the unlocking could have occurred), and then those records can easily be batch locked again.


Excluding Forms from Missing

This function is temporarily disabled. If a form is missing and shouldn't be, the Study  Builder needs to configure a hide condition based on the criteria/exception causing it to not be required.

If forms are counted as missing based on a defined visit schedule, there could be uncommon exceptions that require that those forms be excluded from the missing count. The action items report allows this to be done.

To exclude forms, check the box next to the record and tap the button below. This function is permission-dependent on the role security settings.

AIMVExcluded

To view excluded forms, check the filter at the top or export the entire list to see which ones have been excluded. 

The total count of missing forms is reflected in the action items and dashboard reports. Within a subject’s individual casebook, the record will still display within the visit schedule as missing.