This manual takes users through the use of the Workflow Designer menu item under the System Administration menu group on the homepage of iRIS. Within this menu item you can create workflow paths for each submission form.
The workflow designer is a portion of iRIS where System Administrators define the route of each submission to a review board using the iRIS Software. Workflows should be configured to mirror the current process a submission routes throughout your institution.
A workflow must be setup for each type of submission form that is used. If a workflow is not defined for a submission type, and that type of submission is made, then it is impossible to submit the form to a review board.
After clicking on the Workflow Designer link in System Administration, the System Template Designer, a list of all Templates page, opens, as seen in the image above. This page lists all the current workflows that are defined. To delete a workflow from the system, click the icon in the Remove column next to the appropriate workflow.
Note: It is not recommended that you delete a workflow from the designer unless you are also deleting the submission form from the Form Designer and will no longer use the form in iRIS at all. If you have studies/projects associated to the form and to the workflow, you will break the link and data may be lost.
Edit Workflow Graph – Click this icon to edit the current workflow. If the workflow has already been published, the only editing that can be done is defining the rules of a relation. To edit the entire workflow, select the Create New Version button.
View History – This folder can expand to view any workflow template with a version greater than 1. The folder expands and displays a read-only version of each previous version of the workflow template.
Template Name – Identifies the name of the submission.
Template Type – Identifies what submission type this workflow is defined for.
Template Version – Indicates the amount of times the workflow has been published.
Template Published – Indicates if the template is published or not. If it displays “Yes” the template is published and is being actively used by the submissions made of this type. If it displays “No” the template is not published. If this is the first version and it is not published, the submission type does not have a workflow to follow.
Modified By – Displays the last user to modify the workflow.
Date Modified – Displays the date the workflow was last modified on.
Add New Template- Select this button to add a new template. A page listing the forms that do not have a workflow defined will open.
The items in this list are the forms that do not have a workflow associated to them. Once a form is selected and a workflow is created, the form will no longer appear in this list. iRIS doesn't allow more than one workflow for each submission type, there can also only be one version of the workflow published for each submission type.
A new page will open with a workflow graph that only has the green start and the red end steps. The workflow will start at the green start button and end at the red end button.
Notice on the top of the blue area the text that reads Level 1. Each item that will be defined in the workflow must be placed on a level. The system runs starting at Level 1 and steps up one level until it reaches the end or when the criteria is not met by a submission. At this point the workflow will stop the submission.
When creating a new workflow, the first step is to create the needed Actions, Queues and Decisions. The second step is to add Relations between these until the end of the current workflow process for the specific form. To add an Action, Queue or Decision, first select the level where the item needs to be placed. Do this by clicking on the text “Level 1”. Adding items and levels will be discussed throughout this document.
After the workflow has been created and defined it must be published. Select the Publish/Freeze the Template button. After it is published only the Define Rule for relations will be available, allowing you to view the current configuration of a relation and/or make modifications to that decision relation. Publishing a workflow allows the current version to be used by the form when it is submitted into the workflow. The screenshot below displays an example of a workflow (Image shows the workflow for an Adverse Event form).
Even though the workflow designer can add relations within a level, it is not recommended. This can create confusion for the iRIS users. Therefore, it is highly recommended that another level be created for the second action.
In the below screenshot, the workflow is routed to go back to a previous level.
In this case, when the submission is being routed back, the submission history will not list this as a new process so the submission may look completed, but it is actually stuck in the workflow.
New Template
Add Action – This will indicate what iRIS will do with the submission when it reaches this action node in the workflow. More than one action can be defined at a level, but dependent on the decision of the previous level, it may only perform a few of the actions defined.
Add Queue – This node type is where the submission will rest in a queue until an iRIS user reviews the submission and moves it along in the workflow.
Add Decision – This node type is a decision in the workflow, the iRIS system will determine where the submission will move next based on the rule(s) defined. Usually in this case, there are two or more items in the next level for the system to choose from.
Note: It is highly recommended that decisions be used for items that are a required value. You should NOT attempt to use decision nodes for values that may be unavailable. For example, values from sections of forms that may not be visible due to branching logic, as well as values that may not exist at the time of the submission (i.e. Review Board)
Edit Item/Remove Item – To edit or remove an action, queue, or a decision node(s) select the item then click the edit buttons.
Add Relation/Remove Relation – A relation is the path between the Start, Levels and End of the workflow. There are two different kinds of relations; one is a generic relation that shows the flow of the workflow (black arrow). The other relation is between a decision and the item (red arrow).
Note: When relations are made from decision nodes, they will first be red until the decision relation has been defined for the decision. The arrow will then change to green. See the example below.
Add Level/Remove Level - During the configuration of a workflow you can add and remove levels from the current unpublished workflow. The creation of additional levels will be necessary when adding additional actions, decisions, or submission queues to the workflow.
Define Rule – After the relations have been configured, undefined decision relations will appear in red. Once the decision relation is defined the relation arrow will change in appearance from red to green.
Add Action
To add an action, you must select a level for that action to be added to and then select the Add Action icon located above the blue workflow area. This will bring you to the following pop-up, selection window.
Level Number – Indicates the level that you’ve selected for this action.
Action Type – A predefined list of types of actions can be selected here. The types include:
Action Passthrough
There are two different types of Action Passthrough nodes as described below:
Action Pass-through (Node is Displayed) – Used as a placeholder step, no action is taken on the submission when it passes through this step.
Action Pass-through (Node is not displayed) - Used as a placeholder step, no action is taken on the submission when it passes through this step. This is used to help organize more complex workflow diagrams.
Key Personnel Education Validation & Study Association
When the workflow gets to this action node, iRIS will verify the current user training status of personnel on a study (provided their role on the study is set to be included in the training check). A new Yes/No selection field will be displayed after selecting this action type, along with a list of the training groups setup in System Administration – List Configuration and Maintenance – Define Training Groups. When a submission is passed through this step, the selected groups will be associated to the study and to the personnel listed on the study. iRIS will check the rules defined for the training groups selected against the users listed as personnel on the study to ensure their training is in good standing.
Note: Regardless of the CITI Interface or any other automated training import process (i.e. the user training upload). Rules must be defined for each training group(s) to be used in the workflow in order for the Key Personnel Education Validation & Study Association workflow action node to function properly.
Stop the Submission from proceeding to the Review Board
Selecting “No” for this field, allows this form to continue through the workflow when users are attempting to submit, regardless of the status of the training for KSP associated to the specific study the form is being submitted from.
Within the Workflow – Submission Tracking, a warning will still be displayed for the KSP that the education validation has failed, if the users failing the validation have not been set with the *Override Flag. Otherwise, if the personnel on the study have no training listed, the training listed is expired, or their User Training status is set to Inactive then the system will flag when it runs through this action.
Override Flag - This setting can be configured for each user individually, via the user training area and causes the system to overlook expired training.
Selecting “Yes” to the “Stop the Submission from proceeding to the Review Board” within the workflow action configuration will hold the submission from proceeding, at which point all users will need to have current up to date training for the study to complete the submission. Within the Workflow – Submission Tracking, a warning will display.
Check the boxes next to the training groups that this validation point will check. The group(s) checked here will be the only group(s) that the system will validate the personnel’s training records against. Be sure to Save the action setup.
Note: System Administrators should also verify that each training group used in the Key Personnel Education Validation & Study Association workflow action node has been manually associated with each review board that will receive submissions via the workflow designer tool.
Key Personnel Education Validation & Study Association Using Rules
When the workflow gets to this action node, it will verify the user training of each personnel on a study (provided their role on the study is set to be included in the training check). A new Yes/No selection field will be displayed after selecting this action type. When this step is used in the workflow, iRIS will check rules setup in System Administration – List Configuration and Maintenance – Define Training Group Rules against the study personnel’s training records to verify training is up to date for the study being submitted. This differs from the step above because instead of assigning a specific defined training group to the study when the submission passes through the step, the system checks rules against the study to determine what group should belong to the study. Rules set up in System Administration can look at values in the application to determine what kind of group the study should belong to. An example would be if the study is involved in biomedical research. A value in the application would indicate this and the rule would check to see if the value was set a certain way. If so, the system will assign a group to the study that is particular to biomedical research and the training required for that type of study.
This workflow step functions in the same way for stopping the submission in the workflow or allowing it to proceed with a warning to the study if training is not current.
Key Personnel IACUC Species Vaccination Validation
When the workflow gets to this action node, it will verify the user training of each key study personnel. A new Yes/No selection field will be displayed after selecting this action type.
Note: This item is available for use only with the IACUC module.
This step will check the species added to the study and the study personnel to verify they have correct vaccinations (list of vaccinations is configurable in IACUC Assistant – Review Board Administration – List Maintenance Setup – Vaccination Configuration List).
This workflow step functions in the same way as the two prior steps for stopping the submission in the workflow or allowing it to proceed with a warning to the study if training is not current.
Send E-mail with attached Submission Forms
An e-mail with the submission form and its components attached will be sent out in this action to selected recipients each time a submission reaches this node in the workflow. After selecting this action type, a template will be displayed with the content of the e-mail notification, subject, and allowing the user to select the recipient(s) from a list of system users you would like to receive the e-mail with the submissions. The e-mail subject and at least one recipient are required. Additional recipients can also be designated – this area is reserved for those recipients that do not have a user account in iRIS.
Send E-mail with Merge Codes
An e-mail will be sent out that will include any inserted merge codes. The screen will populate similar to the screen shot below, but this time it will have an Insert Merge Code button right above the text editor.
Note: This is an email only – no attachments.
After selecting the merge code button, a new window will appear that lists all available merge codes.
Select a merge code and click OK. The merge code will appear in the text editor.
Send E-mail by Study Role with Merge Codes
An e-mail will be sent out at this node to certain study roles and it will include any merge codes inserted. The screen will populate, but this time it will have a field that allows you to choose the role.
Note: This is an email only – no attachments.
Send E-mail with Selected Components
When this action type is selected, the subject, recipients, and contents of the email can be configured. This e-mail action will be triggered once the submission is completed and saved; then the documents selected in the Submission Complete tab of a submission will be bundled and sent to the selected recipients.
Note: Proper use of this workflow action node will require configuration at the Review Board level. There are specific Review Board properties that must be enabled for the bundle feature to work from both the Review Board and the workflow areas.
Review Board – RB Fee Validation
This action node is used to validate that the Principal Investigator’s fees are not outstanding. The system will check financial information for the Principal Investigator of the project. If the Principal Investigator has an outstanding fee, then the submission will be automatically retracted.
Review Board Committee – Auto Assignment
This action node will pre-select a Review Board Committee for the submission. After selecting this action node, two more fields will be displayed for the System Administrator to select the desired Review Board and Committee.
Note: The committee list will not display until the Review Board is selected. The committee list will be blank if the Review Board selected does not have any committees. In this case, the submission will be assigned to the Review Board itself. You must also have your Review Board setup in Committee mode which separates submissions into separate committees as opposed to going to one Review Board submission queue.
Review Board Auto Assignment
When this option is selected, a list of Review Boards available in iRIS will populate in a drop-down list. The System Administrator can select the board and the submission will automatically be assigned to the selected board.
Review Board Committee – Return Response
This action node is used in the workflow for the submission correction/response submission form and is utilized when a submission needs to be returned to the submitting personnel for correction action(s). When the response is submitted and this action is in the workflow, it will direct the submission back to the committee that returned the submission for correction action(s). This action is used only with Submission Response/Correction forms.
Review Board Committee – Return Committee
The first time a submission is made on a study it will be assigned to a committee by using Committee of Record on the Review Board. If any other submission is made for the same study, it would go to the same committee if this action node is placed in the workflow. This action is not recommended for use in the Initial Review workflow because the Initial Review is typically the first submission each new study will make.
Review Board – Auto Complete Submission
This action node is used to close out a submission from the review board committee level. Typically, a submission will go to a board queue and will be processed through that board. When the board has completed processing the submission it will be completed. This action bypasses the need for a submission to go through a board in order to reach the completed state. An example of when this step would be necessary is for a submission that has been processed in a Review Board queue and can either be complete based on a decision or needs to go on to another review board or action in the workflow. If the decision causes the submission to be completed, this step can be incorporated into the workflow.
Review Board -Review Board Committee of Record for Study
This action node is used for submissions other than the Initial Review when the review board is broken into multiple committees. This action node would check the study for the committee of record and will send the submission to that committee. This action node should typically be placed in Level 1. Level 2 would be a decision and Level 3 would be the review board queues.
Review Board-Auto Assign IRB Number
This action type automatically assigns an IRB Number to the study when this action node is reached in the workflow.
Note: IRB Numbering must already be configured in the IRB Review Board for this action node to function.
Review Board-Auto Assign IACUC Number
This action node type automatically assigns an IACUC Number to the study when this action node is reached in the workflow.
Note: IACUC Numbering must already be configured in the IACUC Review Board for this action node to function.
Review Board-Auto Assign IBC Number
This action type automatically assigns an IBC Number to the study when this action node is reached in the workflow.
Note: IBC Numbering must already be configured in the IBC Review Board for this action node to function.
Review Board-Auto Assign SRB Number
This action type automatically assigns an SRB Number to the study when this action node is reached in the workflow.
Note: SRB Numbering must already be configured in the SRB Review Board for this action node to function.
Review Board-Auto Assign Proposal Number
This action type automatically assigns a Proposal Number to the project when this action node is reached in the workflow.
Note: Proposal Numbering must already be configured in the e-Proposal Review Board for this action node to function.
Workflow Routing wait for parallel submission
This action will hold a submission based on the definition of additional parallel submissions in the workflow. An example of this behavior is when a submission was sent to multiple Review Boards and needs to be reviewed by each one simultaneously. The submissions that reach this action node will wait for the processing to be completed at all the other review boards that were defined at the previous levels in the workflow before proceeding to the next node defined in the workflow.
Lock Submission
This action provides the ability to route a submission that is not locked, which would allow the form to be edited and modified. The user can specify where in the workflow process the submission becomes locked and read-only. This behavior is controlled with special actions like “Lock Submission”.
Workflow Completed
This action allows you to define a completed status for a submission that the workflow process would not know when the submission is completed. A workflow action of Workflow Complete now provides the closure of submissions and allows the submission to move from “in process” to “complete”.
Change Study Status
This action can automatically update the study status selected here from workflow actions. This action node can be utilized in several workflow levels to allow you to change the study status to different study statuses through the progression of a submission in the workflow.
Change Project Status
This action has the ability to automatically update the project status selected here from workflow actions. This action node can be utilized in several workflow levels to allow you to change the project status to different project statuses through the progression of a submission in the workflow.
Note: This functionality is available for use iRIS e-Proposal & iRIS R&D module(s) only with the.
Personnel Assigned to Select User Data Value
This action node provides the ability to route review submissions to a specified iRIS user.
Wait for all Signatures to be approved
This action holds the submission until all signatures are approved. These additional signatures are typically defined at the review board level.
Wait for all Signatures to be completed
This action holds the submission until all signatures are completed (whether they are denied or approved). These additional signatures are typically defined at the review board level.
Cancel all Outstanding signatures
This action cancels all outstanding signatures. These additional signatures are typically defined at the review board level.
Denial Action for Workflow Assigned Signoffs
This action must be used in conjunction with the Feasibility feature of iRIS.
Check for Conflict of Interest
This action step is used with the iRIS Conflict of Interest module. This step initiates a check on the associated study personnel for any COIs.
Algorithm for Load Balancing
This action will balance the work between review boards. For instance, if one review board is carrying more work than another, the review board with less work will take on the next submission.
Note: The Load Balancing Algorithm that is to be employed by this action node must be configured prior to use by a System Administrator in the List Configuration and Maintenance area of System Administration in iRIS.
Reporting and Delegation Rule Logic
This action needs to be the first action in a Conflict of Interest workflow. It begins the process for checking the Conflict of Interest Form submitted for any conflicts to the COI board.
Pre-Define E-mail template Type Selection
This action is used with the Conflict of Interest module.
Reporting Commitment Reviewer Level 1
This action will send the submission to the designated reviewer based on whether a conflict of commitment was indicated in the COI submission form.
Reporting Commitment Reviewer Level 2
This action will send the submission to the designated reviewer based on whether a conflict of commitment was indicated in the COI submission form.
Send Covered Person Commitment Reviewer Outcome
This action works with the Commitment Reviewer Level 1 and Commitment Reviewer Level 2 actions. A decision prior to this step will check if the reviewers denied the COI submission form. If so, the submission will reach this step and send an outcome to the covered person.
Send Study Personnel COI Questionnaire
This action will send a COI Questionnaire to study personnel (for those Study Roles configured with the COI Required flag to Yes). This is a COI workflow action that would be used in submission forms such as the Initial Review or Continuing Review.
Set covered person “Yes” if COI required in role
This action will affect project and study submission form workflows and will check who on that study or project holds a role that is a “COI check Required = Yes”. If any users on the study hold a role with “COI Check Required = Yes”, this workflow node will make those users into “Covered Person = Yes” and set their Annual COI Due date to be 15 days from that day. If a user already is set to be a “Covered Person = Yes”, then this workflow will not change anything for those users.
Note: This new node will execute two checks: 1. Are these persons on this proposal listed with a COI Required Role? If “Yes”, it will proceed with Check 2. 2. Are these persons named a 'Covered Person'? If “No”, this node will switch a person's 'Covered Person' status from “No” to “Yes”. This will then generate an Annual expiration set for the following day. If “Yes”, then the person will not have to do anything because they should already have an existing Annual expiration date or an existing task to complete their annual.
Copy Reviewer between boards for the submission
This action should be used in the case the institution has multiple review boards that share reviewers. If a board member starts a review in one review board and the submission must be passed on to the next review board prior to having the review completed, this step can be used to copy the incomplete review over to the next board. The board member can then pick up the review where it was left off.
Note: When using this step the board member must have a role on both review boards and the reviewer checklist must be the same for both review boards.
Review Board selection by meeting Submission Due
This action node is for multiple review boards that assign submissions based on upcoming meeting dates. When using this action, the system will check the selected review boards and their meeting dates.
Whichever review board (from the review boards which have been selected, as seen in the screen shot above) has the next upcoming meeting and the Submission Due By date has not yet passed will receive the submission. If there is no Submission Due by date defined for the review boards next upcoming meeting, the system will only look at the Meeting Date. For example, if today’s date were 6/10/19 the submission would go to committee one which has a meeting date of 6/14/19 but no Submission Due by date.
Choose the item from Action Type and select the review boards defined in the system from the drop-down list.
The screenshot below shows how this item must be setup in order for it to work properly. The first level will be Review Board selection by meeting Submission Due By, the second level will be a decision and the third level will have the boards the submission could be assigned to.
The rules going from Level 2 to the boards in Level 3 should be setup as shown in the screenshot below. What to Validate will be the selected board from Action and the Data Value will be the review board the submission would go to.
Review Board – Study IRB of record
This action is used for submissions other than the Initial Review when you have multiple review boards that review the submission. This action is typically placed in Level 1 and checks the study for the IRB of record. Level 2 would be a decision and Level 3 would be the review board queues.
The rules going from Level 2 to the boards in Level 3 should be setup as shown in the screenshot below. What to Validate will be “Selected board from Action” and the Data Value will be the review board the submission would go to.
Select the Save button after selecting the action type you want.
Add Queue
A queue is a place where the submission will rest until it is manually processed by an iRIS User. This is useful when more than one review board needs to review the submission and it is typical to add more than one review board queue in a level and have the submission go to the correct review board depending on specified criteria.
To add a queue, select the level the queue is to be added to and click the Add Queue icon, the following pop-up window will display.
Review Board Submission Queue – The submission form will rest in the selected review board’s submission queue until the board completes the submission. A drop-down menu will be display for you to select the review board to send it to.
Review Board Committee Queue – This action should only be used if the Review Board Property rb.use_submission_by_committee is set to “Yes”. Please see the Review Board Administration manual for details.
This queue is also typically used only for the Initial Review Submission workflow. When it is selected, a drop-down menu of committees (listed under their Review Board) will be displayed.
Note: The processing type of each review board is a configurable review board property; the processing type of each review board must match the selected review board type used in the workflow. For example, if committee processing is selected in the workflow the associated review board/committee must have processing submissions by committee already enabled. For additional information please see the manuals regarding the iRIS Review Board Modules purchased.
Designated Personnel
This allows you to specify a user to review and signoff on the submission. When the workflow reaches this step, the user will receive a task on the homepage that will allow review of the submission and its components and will allow the user to apply an electronic signature. After the electronic signature is applied, the submission will continue through the workflow.
Note: This queue type should only be used for iRIS users that already have an account; it is NOT to be used for any outside collaborators that do not have access to the iRIS interface.
Study Personnel by Role
This step will send a submission to all personnel who hold a certain role in iRIS. When this queue is selected, a drop-down list will appear that allows the user to select the desired role. When the workflow reaches this step, any user on the study with this particular role will receive a task on the homepage that will allow review of the submission and its components and will allow the user to apply an electronic signature. After the electronic signature is applied, the submission will continue through the workflow.
System Role
If you have defined a System Level Role with ‘Use for Routing in Workflow’ set to Yes, you will be able to add that role as a signoff step in a workflow. This step will allow you to select a System Level Role from the dropdown list. You can use this to assign a user to the role instead of naming a specific user in the workflow. You can also associate multiple users to the role and iRIS will assign each user with that role.
For example, the Investigator has been given the System Level Role ‘Routing Role’ in their user account. When the form was submitted, it sends signoff tasks to the Routing Role users. The user received a task on their homepage, if multiple users have been assigned with this role, they will all receive this task but only one user is required to sign off. As soon as one user opens the task and completes the signoff, the other two tasks will cancel, and the form will continue through the workflow.
Add Decisions
When adding a decision to the workflow, the system will determine where the submission will move next based on the rule(s) defined. Usually when adding decisions, there are two or more items (action/queue/decision) in the next level for the system to choose from. For user convenience, a name, such as Review Board Type, Animal or Human, etc., must be created for the decision being made.
To add a decision, select the level the decision will be added to and click the Add Decision button.
The decision in the workflow will allow you to define rules to the relations added for this decision.
Edit Item & Remove Item
To edit or remove an action, queue or a decision, select the item then click one of these buttons. If editing, a page similar to the item’s add screen will be displayed.
When an item is removed, all the relations connected to that particular item are also removed.
Add Relation & Remove Relation
A relation is the path between the Start, Levels and End of the workflow. There are two different kinds of relations; one is a generic relation that shows the flow of the workflow. The other relation is between a decision and the item. This requires a rule to be defined for the relation in order for the decision to process the submission.
When you add a relation, a text box opens with the information shown below.
Specify the level the relation will start from and which level item it is. This is applicable when there is more than one item on a level. The order of the items on a level are in order from top to bottom, so if you have three items in a level, the topmost item is number 1, the middle item is number 2 and the bottom item is number 3.
Specify the level that the relation will end at. Typically, this is set only from one level to the next. In the screen shot above, the relation is from Level 2 to Level 3.
After adding the specifications, click the Save button.
When the relation is added, it normally shows a black arrow connecting the items in the workflow.
When a relation is created between a decision and another item, it shows a red arrow between the two. This arrow is red to indicate that there have been no rules defined for this relation. After a rule is defined, the arrow will become green.
To remove a relation, click on the relation then click the Remove Relation button.
Note: Though the delete button on your keyboard will remove the relation on the screen, it will not permanently delete the relation. Also, when clicking and dragging the relation to a different start or end item, it will only be temporary. The relation will appear in the same spot it was before any changes after the page refreshes.
Add Level & Remove Level
Another level must be created when adding another step to the workflow. Do this by clicking the Add Level button.
Choose where the level should be inserted into the workflow. This allows flexibility in adding levels in between levels when necessary. In this case, you would want to add a level before the End level, which would be level 2. Click the Save button.
To remove a level, click the Remove Level button.
Select the level number to be removed then click the Save button.
Define Rule
After the relations have been set up, rules may be added to the relations appearing in red, which are relations coming from a Decision item.
Do this by selecting a relation, then clicking the Define Rule button.
The Relation Rule page opens with an empty validation.
Relation Rules will check certain criteria set up and if the rule returns true it will proceed to the item that is related to the rule. Typically, these rules are set up to check what Review Board the submission should go to, but a number of things can be checked including study attributes.
Delete – The checkbox is used to delete a rule.
Order – If there is more than one validation in the rule, they can be ordered in a sequence of which order they will be run by the system. Order number 1 will run first, then 2 and so on.
What to Validate – This drop-down list contains the material that may be selected for the system to check.
Review Board – Select this when the relation rule is based on the review board the submission specified it should go to.
The Value drop down will populate with all the review boards that are associated with the system.
Review Committee – This action should only be used if the Review Board Property rb.use_submission_by_committee is set to “Yes”. It is also typically used only for the Initial Review Submission workflow.
This property will split all the submissions into the defined committees for the Review Board. This means that instead of all the submissions in the IRB Submission queue displaying together they will rather display in different committees’ submission queues.
When you select this and set the committee, then the relation will only work if the committee associated with the submission is the one specified in this rule.
Application Form Variable – This will allow you first select the application you would like to the Form Variables to pull from and then allow you to list all the data values for the submission application in the Data Value column.
After choosing a data value, the Value will change depending on the data type of the data value selected. In the screen shot below, a Yes/No selection data value was selected.
You may set the value depending on what the criteria in the rule must be.
Current Form Variable – This pulls all the column names of the data values of the current form (that you are setting the workflow up for).
Current Form - Review Board Selection variable – This pulls the Review Board selection variable of the current form (if there is one).
Selected Committee from Action – This will use the committee chosen from a previous action in the workflow. This rule should only be used if the Review Board Property rb.use_submission_by_committee is set to “yes”.
This property will split all the submissions into the defined committees for the Review Board. This means that instead of all the submissions in the IRB Submission queue will not display together, but in the different committees’ submission queues.
You would use this in a rule to check what committee was used in one of these actions: Review Board Committee – Auto Assignment, Return Response and Return Committee. An example would be to set a rule based on a Review Board Committee – Auto Assignment action earlier in the workflow.
In the screenshot above, Level 1 has an action, Auto Assign submission to committees. This action is setup to split up the submission into one of the two committees for the Review Board. After the submission has been assigned to one of these committees it will reach a decision on Level 2. To send the submission to the first item on Level 3 (Institutional Review Board Submission Queue), a rule will be defined in which the submission will only go there if the committee auto assigned is the Full Review Board (1) committee.
This rule is set up to find out from the Auto Assignment action if the submission was assigned to the Full Review Board (1). If so, then the submission will continue on this path.
Selected Board from Action – This is similar to Selected Committee from Action except it will use a Review Board as criteria instead of the committee of the Review Board.
Study Attributes – This will base on study attributes such as multi-site site view, multi-site, single study or exempt.
Submission Attributes – This will base on submission attributes like the outcome action.
Signoff Status – This will list all the signoff statuses available allowing the user to select a particular status they want a signoff to be to send it in a particular direction in the workflow.
Selected Department from Study – This will list all the parent departments in the system allowing the user to select a particular department.
Data Value – This column will populate depending on that item is chosen from the What to Validate drop down list.
Comparator – Set this to be the comparator for the What to Validate. Typically, EQUAL is chosen, then select or enter the Value that the comparator will use to match itself to.
Join by, if any – This drop down contains three values: AND, --none--, and OR. Choose one of these only if there is more than one validation to the rule.
Note: A rule does not necessarily have to be defined, but it is recommended to do so. If a rule is not defined, then the submission will be sent to that item, just like a regular black relation arrow. A relation rule that is not defined is referred to as a Generic Rule.
Helpful Tips
Review Response Workflow
When creating a workflow for a Review Response form, it is no longer necessary to use the Return Response node. The study will return to the board as expected without including the Return Response node in the workflow.
Auto-Assign Analyst
This feature auto-assigns an Analyst to a submission via the workflow. Previously, board members would need to navigate to the “Pre-Review Screening” tab within a submission and assign an Analyst. A new “Action Type” has been created within System Administration > Workflow Designer > Define Action called “Review Board - Auto Assign Responsible Analyst”.
When the “Action Type” is selected, drop-down lists called “Select the Review Board”, “Select the Review Board Committee”, and “Select the Assigned Analyst” are prompted. When an Analyst is added through the workflow, and a board member navigates to the “Pre-review Screening” tab in a submission, the Analyst name will already be displayed in the “Assign Analyst” field.
© iMedRIS Data Corporation