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

• Plan your data collection form before you start creating the forms in REDCap.

• Document your data collection needs in a study protocol or similar document.

• Group your data fields/questions based on how they are being collected. For example:

  • Data source (chart review, patient assessment, lab report, etc.)

  • Time point (baseline clinic visit, follow-up visit, etc).

  • Method of collection (the question flow should mirror the actual data collection process).

• You may find it helpful to draft a paper form in Word before you start in REDCap

Form Development

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

• You don’t want to keep having to go back and modify your REDCap forms because the paper forms keep changing.

• However, developing the REDCap forms will help you focus on the data collection process and you may want to make changes to the paper forms based on decisions made developing the electronic 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.

• Develop naming conventions for your variables. For instance:

• Use a prefix to indicate which form the variable is on.

  • bas_ for baseline data

  • scr_ for screening data

• For dates and date-times indicate the data type in the variable name

  • visitd for date of visit (date)

  • visitdt for time and date of visit (datetime)

  • visittm for time of visit

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:

• Keep form and variable names shorter than 20 - 25 characters.

  • If the title of the form is long then give it a short but meaningful name and add the title as descriptive text or a section header on the form itself.

  • During export REDCap creates status variables based on the form name. If the form has a long name these variables won’t import into your stats package!

• Do not start or end end variable names with a number.

  • During export REDCap names code lists based on the variable name. In SAS code lists names (SAS formats) cannot be longer than 32 characters and cannot end in a number.

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”.

• You cannot put text data into a numeric field.

• You cannot enter decimal places in an integer field.

• If a field validation specifies a number of decimal places then these have to be entered, even if zero.

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.

• The user may ignore the warning and continue.

• REDCap’s data quality module allows users to identify and review data that falls outside the specified range.

• Range checking is a good way to reduce data entry errors. Ranges should be chosen carefully so that data entry is not interrupted too often but obviously invalid data is trapped.

 For surveys range checking is ‘hard’.

• REDCap will prevent a survey user from entering data that is outside the specified range.

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

• The user may ignore the warning and continue to save the form

• The data quality module allows users to identify and review missing data.

 For surveys the “Required” setting is hard.

• REDCap will not let a survey user save the page if required fields are incomplete.

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.

• Use data access groups if you are collecting data at more than one study site

• Don’t give a team member more access rights than they need

• If you have a large number of users it may be helpful to create User Roles to simplify management of user rights.

• Delete users from your project when they leave the project team 

Privacy

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

• Make sure you have the required administrative and ethics approval

• Do not store identifiable healthcare information in your research project unless:

  • Identifiers are required for “data matching purposes” and

  • Identifiers are documented in your ethics application

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:

• Primary and secondary outcome variables

• Compliance data. This is data that demonstrates compliance with the study protocol. For instance, dates of clinic visits, date and time of assessments and/or administration of medications, medication doses, medication accountability data

• Any other data item that has received special treatment in the study protocol.

Assess Risks

What are the risks to data quality?

• What is the source for each data item?

  • Is data being entered directly by participants?

    • Will the participants understand the questions?

    • Is data entry easy?

  • Is data being received from third parties such as laboratories?

    • Are you receiving data for the correct participants

    • Do you have data for the correct time points?

    • Is data missing?

• Do you have source documents?

  • Are source documents available and appropriately managed?

  • Does data entered into the database reflect the source documents?

• What data is being transcribed and how is quality assured

  • Data quality checks

  • Double data entry

  • Data quality measurement / audit

Plan for Quality

• Develop a formal data management / data quality plan

• Implement and document procedures to mitigate identified risk.

• What error rate is acceptable to the study (based on power and other statistical factors)?

• Document quality audit plans.

  • Define what data items will be checked

  • How frequently will data be checked?

  • What volume of data will be checked?

• What actions will be taken if data quality is too low?

Measure Data Quality

• Perform frequent data quality audits.

• Document audit results.

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:

• End of Study and Archival