COI - Configurations between Kuali Research (monolith)

Overview

This is a summary of standard configuration items on the monolith (KNS/KRAD Kuali Research) side to set or consider when integrating with the new COI module.  

Roles

Persons who will be COI Administrators will need the role: KC-COIDISCLOSURE: COI Administrator

If you are using the Auto-Assign Reviewers functionality schools using Additional Reviewers in COI, will need to assign the role KC-COIDISCLOSURE: COI Reviewer to persons for them to be available for adding as an Additional Reviewer. 

If you are not using the Auto-Assign function and are instead manually assigning reviewers, such as COI Committee members they will need to be listed in the KC-COIDISCLOSURE: COI Reviewer role to be available on the Additional Review screen.

Setup for Auto-Assign Reviewers

Schools who want to use the COI General Configuration option “Automatically assign additional reviewers when disclosure is submitted” will need to populate Primary Department Code in Persons for any user who will be submitting disclosures in order for the system to find the reviewer to assign.  The system uses the reporter’s primary unit to find reviewers that responsibility in the relevant Unit hierarchy to determine the automatic assignment.

Project Push

When first setting up a COI instance, the action Project Push To COI in Miscellaneous in System Administration will send all existing proposals, awards, IPs, IRB protocols and IACUC protocols to the COI module to be available in disclosures.

COI Sponsor Hierarchy

Schools who want projects from only specified sponsors included in COI disclosures should set up a COI Disclosures Sponsor Hierarchy (in Kuali Research go to System Admin > Maintenance > Sponsor Hierarchy) and reference that hierarchy in the COI configuration file.

Schools who want reporters to disclose on all sponsors should not set up a Sponsor hierarchy for COI Disclosures and not reference a hierarchy in the COI Configuration; more info can be found in the Configuration - Project Requirements article. If there is no COI Disclosures Sponsor hierarchy then all sponsors are included in COI.

Display of COI Disclosure Status

Parameters

To enable display of COI Annual Disclosure Status from the 'new' COI module in the Proposal, Award, and IP modules, set the relevant parameter to Y:

• KC-PD: ENABLE_DISCLOSURE_STATUS_FROM_COI_MODULE. Also, set KC-GEN: PROP_PERSON_COI_STATUS_FLAG as N because it pulls from the monolith COI module.
• KC-AWARD: ENABLE_DISCLOSURE_STATUS_FROM_COI_MODULE
• KC-IP: ENABLE_DISCLOSURE_STATUS_FROM_COI_MODULE

To enable display of Project COI Status for all module, set the follow parameter to Y:  

• KC-SYS:  COI_PROJECT_STATUS_FEATURE

Permissions 

If a user can view or edit a proposal, IP, award, or protocol document, then they can can see their own disclosure disposition.  To display dispositions to other users with view access, the permission 'View COI Disclosure Disposition' is needed.

Legacy COI Module

If you are still using the old/legacy COI module in the monolith there are a number of COI configuration items available still in the monolith that are not used by the new COI module. They are listed here for clarification.

The following COI-related configuration parameters only affect behavior related to the monolith COI module. In most cases, they can be ignored, but KC-GEN: PROP_PERSON_COI_STATUS_FLAG should be set as N when using new COI.

• KC-COIDISCLOSURE: COI_CERTIFICATION_ACKNOWLEDGEMENT
• KC-COIDISCLOSURE: COI_CERTIFICATION_STATEMENT
• KC-COIDISCLOSURE: COI_DISCLOSURE_FE_CONFLICT_HEADER_LABEL
• KC-COIDISCLOSURE: coiAttachmentDefaultSort
• KC-PD: COIHierarchyLevel1
• KC-PD: COIHierarchyName
• KC-GEN: PROP_PERSON_COI_CERTIFY_QID
• KC-GEN: PROP_PERSON_COI_STATUS_FLAG

KC-COIDISCLOSURE Roles NOT used by the new COI module are:  Coi Disclosure Reviewer, COI Reporter, Maintain COI Questionnaire, COI Approver, COI Maintainer.

The new COI module does NOT look at the COI Maintenance Documents in monolith.