Project Best Practices

Attention to detail at the start of a project can save many hours work further down the line. This page provides some hints and tips that could save effort later.

Preparation

Form Development

Develop REDCap forms from ‘near final’ drafts of the paper forms.

Form and Field Names

Name your forms and fields in a way that makes it obvious what they are. There’s no need to be too cryptic and you’ll find it easier to work with the data later.

Try to develop your forms so that the same data is collected consistently throughout. In longitudinal studies design the forms to keep them as similar as possible from one study event to the next. Re-use forms in subsequent events rather than creating new variables for repeated assessments.

Statistical Limitations:

Be aware of the limitations of your statistical software. Data that is exported from REDCap will be easier to work with if it conforms to the expectations of your stats package. Naming rules vary depending on software and version.

To stay out of trouble try the following:

Field Type

REDCap field types are based on the html objects that display them. Restricting a text field to specific field “types” is done through the use of “validation”. Validations are “hard”.

Field Label (Question Text)

Make sure your question text is meaningful and grammatically correct. Again there’s no need to be cryptic and it’ll make data entry easier for everyone.

Try to use case and punctuation consistently.

Don’t make the question text too long if you can help it. This text will be used as column headings in data exports and as value labels (SPSS) or labels (SAS) and there are limits on what is supported by these packages. If you need to include large volumes of text then consider using a descriptive text field above the REDCap variable and keep the variable label shorter. Descriptive text fields do not export into your stats package.

You can use html for formatting question text. However, only a limited number of html tags are supported. You can include html in the field label but please note that the question text, including html, will be reproduced in data exports as column headings or labels (unless it's descriptive text).

Range Checking

For standard data entry forms range checking is ‘soft’.

 If a user attempts to enter data that falls outside the specified range REDCap will warn them.

 For surveys range checking is ‘hard’.

Design range checks based on realistic expectations. Use them to check for unreasonable and impossible values. If a check fires too often it will slow data entry and frustrate users. Do not use normal ranges for range checks unless you genuinely expect your study population to be normal!

Branching Logic

Fields can be hidden Using branching logic if, based on context, they are not relevant. Good use of branching logic allows most fields to be set as required. Fields containing no data are ambiguous so skipped required fields are better than empty fields that are not required.

Required

For standard forms the “Required” setting is soft.

 REDCap will warn when a required field has not been completed

 For surveys the “Required” setting is hard.

Use branching logic to hide questions based on context.

Record IDs and Identifiers

Study assigned record IDs tend to be more meaningful and easier to work with than automatically assigned IDs. Under some circumstances it may be useful to use automatic IDs and to assign a second, unique, study specific identifier.

It’s helpful to define a format for study IDs so that data entry staff cannot enter free text. We have added a validation to our copy of REDCap that can be used to force IDs to the following format AAA-nnn.

We do not recommend using names or initials as part of the main record ID. REBs prefer for identifiers not to be collected unless absolutely necessary. Even if you have REB approval to collect identifiers in your project including them as part of the record ID makes it difficult to deidentify the project during export and analysis.

Field Note

Use field notes to provide guidance to the people doing data entry. For instance if a text field is set to collect numeric values with two decimal places then indicate this like so: (n.nn)

Testing

Test your forms as you build them. Don’t leave it all to the end.

Get a third party to enter data for a number of subjects before putting the database into production. Someone who was not involved in building the database will find errors that may otherwise be missed.

Perform “boundary checks” for fields that include range checks (check that numbers either side of the range can be entered).

Please note: If your project is a Health Canada regulated clinical trial you must test and approve the project database before moving the project to production and collecting participant data. See our "maintaining compliance" document for more information.

Move the Project into Production

After testing your project move it into production. REDCap's production mode gives you some additional protection by not allowing changes to the forms. Once in production you can edit the forms by moving the project into draft mode. While the project is in draft mode data entry users see a consistent version of the forms whilst changes are being made. Once the changes have been completed moving the project back into production will make those changes available for data entry. As the project is moved back into production REDCap also checks for certain critical issues and can will refer your project to administrators if it finds any.

For more information see this page.

User Administration

REDCap users are created by system super users but can be added to and removed from projects by users who have access to the project’s User Rights module. Typically this means that Principal Investigators and senior study staff control who does what on their projects.

Privacy

Ensure that you are familiar with and conform to applicable privacy policy and legislation. In general:

For further information see our privacy page.

Data Quality

Identify Critical Data Items

Identify critical data items and make sure that they are collected appropriately. Some examples may be:

Assess Risks

What are the risks to data quality?

Plan for Quality

Measure Data Quality

End of Study

Once the study is complete and published you should consider your options regarding archival and secondary use. Please see the following page for additional information: