Skip to main content

Importing Legacy Data in Human Ethics

Emily Yeomans
  • Updated

Cayuse can import data extracted from other IRB systems into Human Ethics.

  1. You must provide a CSV file containing the data describing each study you wish to import.
  2. We will then load the list of studies into Human Ethics.
  3. A member of the research team or an Analyst creates a legacy submission (to replace the initial submission) for each imported study.
  4. Once the legacy submission has been created, researchers may create additional submissions for the study (modifications, renewals, etc.) and it will appear in reports.

File Format

The CSV file used to import the studies contains thirteen fixed columns as described in the table below. You cannot change the name of the 13 columns, nor can you add/remove columns to change what fields are available for upload. The first row in the file must contain the column names.

 

Column Required

Must Be Unique

Description & Considerations

 

 Example Reference
legacyStatus No No
  • Status of the study in the previous system. 
  • Cayuse recommends setting this to "Approved" for all studies, since you would not need to load non-approved studies into Cayuse IRB. As an alternative, you may use "Legacy" as the status. If you leave this blank, it will list “Legacy” as the status.
  • If you are performing multiple legacy data loads, the Legacy status can be used to distinguish newly-imported studies from studies that were loaded in previously.

Please Note: Although the import process allows you to use any text string for the study status, if you use a status other than the supported study statuses you will be unable to update the status after import, and the study will not appear in reports. Supported statuses: Approved, Legacy, Exempt, Suspended, Disapproved

 Approved  
label Yes Yes
  • Unique identifier for the study. The label format/convention is up to you, and so can match the study label from your previous system.
  • Must be unique across all CSV data and all existing studies in Cayuse IRB. 
  • It is recommended that your label convention for Legacy is different than the Cayuse HE Study Label convention to ensure unique identifiers and at-a-glance identification of Legacy studies.
Please Note: If the label matches a study that has already been imported into Cayuse IRB, the record for that study will be updated with any new information. 		IRB-FY2014-123  
title Yes No
  • Title of the study
  • Length restriction: 600 characters.
  • If there are duplicate titles, there won’t be a validation error, but it may raise questions on if it was a copy/paste error.
 Social Effects of Early Onset Hair Loss  
expirationDate No No
  • Date the study expired or will expire (e.g., full board studies, some expedited, etc.). 
  • Acceptable Date Formats: yyyy-mm-dd, mm/dd/yyyy, or mm/dd/yy
  • Warning: This is a distinct data field in Cayuse HE compared to Administrative Check-in Date. Do NOT enter Admin Check-in dates here. Leave this cell blank for such studies and discuss methods to add Admin Check-in Dates post upload with your Consultant.
  • Once a study has expired, only renewal and closure submissions can move a study out of expired status. 
  • Cayuse recommends loading only active studies with expiration dates in the future into Cayuse IRB. 
  • If you choose to import closed studies into Cayuse IRB, the expirationDate field should not be populated for these studies.
Please Note: Importing studies that have approaching or passed expiration dates will trigger email notifications to the research team reminding them of the study's expiration. 		   
createDate No No
  • Date the study was created. 
  • Acceptable Date Formats: yyyy-mm-dd, mm/dd/yyyy, or mm/dd/yy
  • If this field is left empty, it will be set to the date of import into Cayuse IRB.
 2014-10-30  
closedDate No No
  • Date the study was closed (via a closure or withdrawal submission). 
  • Acceptable Date Formats: yyyy-mm-dd, mm/dd/yyyy, or mm/dd/yy
  • Cayuse recommends loading only active studies into Cayuse IRB, however you may choose to load closed studies if desired. 

Please Note: Studies that have a closedDate should not have a value entered for the expirationDate, since this will trigger inappropriate email notifications to the research team regarding expiration of a study that is already closed.

    
approvalDate No No
  • Date the initial or most recent renewal submission was approved.
  • Acceptable Date Formats: yyyy-mm-dd, mm/dd/yyyy, or mm/dd/yy

Please Note: Approval Date is used by the system to decide the Policy (i.e., Pre-2018 Common Rule or Post-2018 Common Rule). If the Approval Date is prior to 1/19/19, the system will default to Pre-2018 for the study. If such a study has been transitioned to Post-2018 Common Rule, the only way to adjust that is after the Legacy Data upload, Legacy submission is complete, and a follow-on submission is submitted for review.

 2014-11-15  
Principal Investigator Yes No
  • Username of the Principal Investigator. 
  • You can only specify ONE Principal Investigator for a study.
  • Will directly populate in the Key Contacts tab of Study Details.
  • Will also populate the username in the Legacy Submission form Person Finder object with the “Principal Investigator” Assignment.

Please Note: Since this populates directly to the Key Contacts tab, listing a different person as the PI when filling out the Legacy Submission form will NOT overwrite the PI listed in this spreadsheet. A Modification would need to be submitted to effectively change any study team members (and their access) once the Legacy Submission form is complete.

 MShelley Admin Bulk Data Template,
People tab, Column I (Username)
Primary Contact Yes No
  • Username(s) of the Primary Contact.
  • Will directly populate in the Key Contacts tab of Study Details.
  • Will also populate the username in the Legacy Submission form Person Finder object with the “Primary Contact” Assignment.
Please Note: Since this populates directly to the Key Contacts tab, listing different people as the PC when filling out the Legacy Submission form will NOT overwrite the PCs listed in this spreadsheet. A Modification would need to be submitted to effectively change any study team members (and their access) once the Legacy Submission form is complete.		 JRRTolkien

Admin Bulk Data Template, People tab, Column I (Username)
Investigators No  
  • Username(s) of the Investigator(s) involved with the study.
  • Will populate the username in the Legacy Submission form Person Finder object with the “Investigator” Assignment.
 "WSmith, PStewart, JDean" Admin Bulk Data Template, People tab, Column I (Username)
Co-Principal Investigators No No
  • Username(s) of the Co-Principal Investigator(s) involved with the study.
  • Will populate the username in the Legacy Submission form Person Finder object with the “Co-Principal Investigator” Assignment.
 RThompson Admin Bulk Data Template, People tab, Column I (Username)
Organizations No No
  • Alphanumeric Primary Code(s) for the Org Unit(s) associated with the study.
 D100087

Admin Bulk Data Template, Org Units tab, Column C (Primary Code)
Sponsors No No
  • Alphanumeric Primary Code(s) for the Sponsor(s) of the study.
  • Entries in this column will be uploaded to every Sponsor Finder Object in your Legacy Submission Form for that study. This means if there is more than one Sponsor Finder in the Form, it will upload the list of sponsors for this study to each finder object, even if you are using those objects as a place to list external organizations other than the sponsor(s) of the study (e.g., external sites/collaborators, COI for study staff, etc.).
 S0006

Admin Bulk Data Template, Org Units tab, Column C (Primary Code)

Data Formatting

  • Single Username/Organization/Sponsor: Enter the username/primary code.
  • Multiple Usernames/Organizations/Sponsors: Use commas to separate usernames/primary codes. Do NOT include a space before the comma of after it. 
    • Note: Do NOT wrap the entire field value in double quotes. If your codes are purely numeric, you might want to designate the cell format for the Organizations and Sponsor columns as Text to allow for numeric codes separated by a comma (e.g., 1002,3240).
      • Examples:
        • Usernames: WSmith, PStewart, JDean
        • Sponsors: S0006,S0007
    • Warning: The Primary Codes of your Organizations or Sponsors should be alphanumeric codes with NO spaces or commas contained within the code. 
      • Commas contained within Primary Codes (e.g., Organization = “Physical, Inorganic, and Analytical Chemistry” or Sponsor =  “Google, Inc.”) cannot be accurately processed in the uploader and are inevitably treated as a delimiter when upload. This will incorrectly split the cell to treat them as separate codes. Commas should only be used to separate multiple distinct organizations/sponsors.
      • These codes can be solely numbers (e.g., 0007) or letters (e.g., TTBD), but using full names (e.g., Department of Biology or National Institutes of Health) for Organization/Sponsor unit codes is strongly discouraged. Also, these unusual conventions for a “code” may cause future unanticipated issues with data linkage. 
      • If possible, it is recommended that Organization Primary Codes match with the corresponding HR identification codes, or id codes in your ERP system for Sponsor Primary Codes.
  • Special Characters: Most special characters can be included in the cells for Title, dates, and usernames (see exception above for Organizations/Sponsors) without doing anything special/additional for them to be uploaded properly in the CSV. However, some will require you to “escape” the character in order for it to be included in the imported cell text without being identified as a delimiter (i.e., character in CSV file that indicates the cell contents should be separated into different cells).
    • Nothing Additional Required: ! @ # $ % ^ & * ( ) _ - + = : ; " ' / ? . , > < |
      • You do NOT need to escape double quotes ".
    • Escape Character Required: If you want to use a backslash (\) in a field value, you must escape the character by including a backslash before the desired character. For example: enter \\ to include a backslash.

TIP: Avoid using backslashes entirely if you can, as they can easily cause issues in validation.

Specifying Research Team Members

  • The research team for a study is comprised of the Principal Investigator, Primary Contact, and optional Co-Principal Investigator(s) and additional Investigator(s).

    • The research team columns will NOT match to the “Title” field (the name of the object end-users see) of the Person Finder objects in your Legacy Submission form. Once uploaded and the Legacy Submission is created, each username will be listed in the corresponding Person Finder objects based on the Assignment of the Person Finder Object. For example, usernames listed in the Co-Principal Investigator column will be matched and added to the Person Finder Object in the Legacy Submission form that has the “Co-Principal Investigator” Assignment (regardless of what you named the object in it’s “title” field).
      • Since the Co-Principal Investigator and Investigator Assignments can be selected for more than one Person Finder Object, if the Legacy Submission Form contains more than one Person Finder Object with the Co-Principal Investigator Assignment, it will upload the usernames in the Co-Principal Investigator column to every Person Finder Object with the corresponding Assignment. The same will happen if you have more than one Person Finder Object with the Investigator Assignment.
    • If the Person Finder objects in the Legacy Submission form do not allow multiple (toggle in object Properties) people to be listed in the object, then only the first username in the field will be listed in the corresponding Person Finder object.
    • The CSV file should include all members of the research team who will need access to the study and its submissions. Otherwise, a modification submission will need to be created to add additional research team members at a later time.
    • The research team should not include any users who are also IRB Analysts or Admins. Cayuse HE prohibits users with a conflict of interest from being involved with the review process. If an IRB Analyst or Admin is added as a member of the research team, they will be unable to review the submission due to this conflict.

Related articles