UniFR Template and Best Practices

UNIFR Template

When requesting the creation of a project to REDCap admins (DIT-SIT, UNIFR), you project will be pre-populated with our own template (courtesy from CTU Bern)

Instruments

In this template we provide example eCRFs (instruments) for standard clinical trials forms:

  • Eligibility
  • Randomization
  • End of Study
  • (Serious) Adverse Event (study and sponsor) [specific to IMP trials]
  • Protocol Deviation
Keep in mind that these instruments are solely templates that you can freely modify to match your study design. Only keep the ones that may be useful for your study and remove the instruments that you do not plan to use.

User roles
ROLEDESCRIPTION
Analysis Standard role for the statistician
Data Entry Standard role for the study nurse
Monitoring Standard role for central data monitoring and for on-site monitoring
Super User The project super user has the maximum rights on his study database. He can manage user rights, roles, data access groups (DAGs), he can deploy his study database.
Project Setup Design study database: create eCRFs (instruments), visit plan, reports, enter test data
Sponsor/PI Standard role for the sponsor and/or the PI

Reports
The template comes with a predefined report that you can use to submit (serious) adverse event cases to the ethics comittee:


You can adapt the report to your study by going to  and by clicking on "Edit":


Best Practices for Database Implementation

To improve the quality of your database implementation and make your statistician(s) happy, here are a few tips with courtesy from the CTU Bern.

1. Provide understandable variable names

For each new item, you need to provide a unique variable name. Best practice is to include acronyms in the name of the item corresponding to:

  • The instrument in which the item is located
  • The label of the item
  • The field type
FORMAT: instrument_field_type


For example, if you want to create an item in a "demographic" instrument assessing whether a participant is a UNIFR student, you could code it accordingly:

dem_unistud_yn

You will find below a list of acronyms that may be used to indicate the field type of an item:

Field type Acronym
Yes/No _yn
True/False _tf
Date _dt
Date-time -dtm
Integer _int
Numeric _num
Calculated fields  _calc
Descriptive text _desc 
Notes Box  _txt
File upload _up

! Be careful that the length of a variable name SHOULD NEVER EXCEED 26 characters !

2. Standardize the coding values

When creating an item and defining choices, try to be consistent across the entire database. You can, for example, use the following coding structure for special values:

Code Value
0 no/false/negative/absent/abnormal
1 yes/true/positive/present/normal
 1  male
 2  female
88 other/else
99 not available/NA/unknown

Branching Logic Reminder

Here is a small reminder of the most useful fonctions in branching logic and what they can be used for:

Function Description
[sex] = "2" Display question if sex = female (Female is coded as 2)
[sex]= "2" and [given_birth] = "1" Display question if sex = female (Female is coded as 2) and given birth = yes (Yes is coded as 1)
([height] >= 170 or [weight] < 65) and [sex] = "1" Display question if (height is greater than or equal to 170 OR weight is lower than 65) AND sex = male (Male is coded as 1)
[last_name] <> "" Display question if last name is not blank (i.e., if last name field has data)
[visit_date] = "" Display question if visit date is blank (i.e., if visit date has no data)
[race] = "88" Display question if race = other (Other coded as 88)
 [race(88)] = "1" Display question if 'other race' is checked (Checkbox field type!)