The study Workflow section is used for a couple of things:

  • To set up the review process for a study. In other words, once a form is entered by a user, what cycle of reviewing and a signature does it go through. 
  • Commonly, this includes at least a Monitoring stage and a sign off stage by an Investigator or Data Manager.
  • To teach the system which forms and variables in the study serve a few key functions (Registration, Study Exit, etc) for the purposes of tracking and reporting.


On a web browser:

Select Study Configuration from the study menu, and select the Workflow tab highlighted in the image. 

1. Order - Set review order of roles. Be sure these are sequential and not skipping values

2. Name - Name of review level set up

3. Role - Role of the reviewer to the system

4. Status - Form Status ID assigned to the review level.  This is the code for each review level in data extracts. The example below is not sequential because the initial verification level was added later in the study. To prevent the system from changing any current records, the original statuses were maintained. This is an important point to keep in mind when making workflow changes on a live study.

5. Field - Checking this field will allow the role the ability to do Partial Monitoring of forms. 

6. Sign - Checking this field requires Electronic Signature for this role review to be completed. eSignature types are displayed in the audit trail and exports along with the user and date.


7. Soft - Can only be selected at the first review level, and should not be mixed with FLSV (field) level review. 
This allows the first level to mark something as reviewed regardless of the form's current status (open queries or missing data). This is useful for Monitors who perform monitoring before forms are completed. If data is changed after a soft review has been applied, the review level will be removed on that form only if there are open queries on the form.


Caution: Existing studies that already contain data and would like to add this function should be cautious to not alter current workflow status values.  


8. Description - Review level description text that will appear on the form when applied.




The bottom section of the Workflow is where users define basic forms for the system to use in controlling various elements. 


9. Term to use for Participant - The term used for "Participant, patient, subject" etc can now be defined in the study configuration.  Type in the name by hand and it will update all the areas and reports this term is used.


10. Registration form - The form from the form builder that will serve as the initial enrollment or registration form to create a new subject profile ID. This item will be grayed out and cannot be changed if there are subjects in the database. In those cases, clear the data or create a new copy of the study to change the registration form.


11. Enrollment Trigger (NEW) - This is the form and corresponding variable (boolean) and value which will count each subject as "enrolled" in the study. This may be the same as registration in many cases, but may also be later on, such as the case with screening subjects (registration) and later on enrolling them upon randomization, for example. This variable is displayed in the dashboard for the number of subjects and TrialKit Site Progress export.


12. Deviation form - Indicate which form will serve as a deviation form. These are counted in the dashboard report

13. Withdrawal form - Indicate which form from the form builder will serve as the withdrawal form (e.g. study exit or discontinuation). The system uses the date on this form to make any visits beyond that date inaccessible to the site and subjects in ePRO. A description field can also be identified which is displayed on the subject's records page after withdrawal. The form defined here will also discontinue possible ePRO forms to the patient.

14. Medication log - Indicate which form will serve as the medication log.

15. Adverse Event form - Indicate which form will serve as the adverse event form. This is counted in the Dashboard Report AE metric.   Adverse Event Field - This is the field (must be a choice field) you want the system to use specifically when counting the number of AEs in various reports. If this is not set, it will default to use the form defined as AE form in the workflow (as noted above)  Finally the Adverse Event Value - This is the value of the Adverse Event Field selected above that will true a "true" response - or a count in this case.  For example, Serious AE is = YES. Which is the value of YES will count as a true AE in reports.


16. Save Configuration! Do not forget to save your edits!