For projects with surveys, you must complete the "Set up my survey" step in order to activate the Survey URL. If this step is not complete, the following message will appear to on the "Survey Distribution Tools page: "Enable my surveys(s) NOTICE". You cannot utilized the "Survey Distribution Tools" page until you have first enable one or more surveys..."

The survey-related options, like Survey Settings and Notifications, can be accessed on the Project Setup > Online Designer page.

For ALL projects, you must define a unique identifier as the first field on your first data entry form. The data values entered into this field must be unique. The system will not allow for duplicate entries. If you do not have a specific unique identifier, you can enable the option "Auto-numbering for records".

Examples of Unique Identifiers: Study-assigned ID

Examples of Non-Unique Identifiers: Names, Dates of Birth, Consent Dates

The unique identifier must be a 'text' field. In addition, please note that unique identifier values will be visible at the end of the URL -- and likely cached in web browsers -- as individual records are viewed or entered. (Example URL: https://www.example.com/redcap/redcap_vx.x.x/data_entry.php?pid=xxx&page=xxx&id=ID_VARIABLE_VALUE.)

It is strongly recommended that you do not use Protected Health Information (PHI) Identifiers such as MRN or DOB+initials as the unique identifier. This is an additional precaution to preserve research participant confidentiality from displaying in the URL and becoming cached.

Depending on which project settings are enabled, you will have the following steps/modules to complete on the Project Set-up page:

Project status reflect where in your project lifecycle your REDCap project is.

Development: All projects when first created start in Development. In Development, you can design, build, and test your REDCap projects. All design decisions can be made in real time and are implemented immediately to your project. All survey and data entry features/functions can and should be tested.

Production: When you have completed thorough testing, you should move your project from Development to Production status by clicking the button at the bottom of the Project Setup page. All survey and data entry features/functions will be exactly the same as they are in Development with the exception of certain Project Setup features.

To make any form design changes you will need to enter Draft Mode to be able to edit your instruments. Changes to data collection instruments in Draft Mode are not made to your project in real time. After making updates, you must submit the changes for review. Depending on your institution’s policies, some changes are processed automatically, whilst others will need approval by a REDCap Administrator. These settings, as well as review and approval times will vary as they are institution specific. They are intended to protect from unintentional impacts to existing data and data structures in a live production project.

From Production, you can move the projects to the following statuses on the Project Setup > Other Functionality page:

Development: Only an administrator can move your production project back to development from production.

Analysis/Cleanup: Move the project to Analysis/Cleanup status if data collection is complete. This will disable most project functionality, although all collected data will remain intact. Once in Analysis/Cleanup status, the project can be moved back to production status at any time.

When a project is in Analysis/Cleanup, it is assumed that formal data collection has ended, except for cleaning and analyzing the data already collected. Many features are disabled, such as surveys, Alerts & Notifications, Automated Survey Invitations, and other features typically used during data collection. Also, no new records can be created while in this status.

Modify data locking mode

While the project is in Analysis/Cleanup status, you may set the data in the project to be either;

1) Editable (existing records only), or

2) Read-only/Locked. If set to Read-only/Locked mode, then no data in the project will be able to be modified in any way.

When in Analysis/Cleanup you can move the project back to Production or to Completed status.

Completed: If you are finished with a project, sure that no one needs to access it anymore, but you want to ensure that the project and its data remain intact, it can be marked as Completed. A Completed project can only be accessed by a REDCap administrator and only they can change its status back to Analysis/Cleanup .

Marking a project as Completed takes it offline and hides it from everyone's project list. It can only be seen again by clicking the small Show Completed Projects link at the very bottom of the My Projects page. Clicking this link will make your completed projects appear in the same project folders that they were originally allocated to.

Changes to project status

Project statuses were changed from version 9.8.0 standard release and 10.0.5 LTS, and some changes automatically made to projects which were in the older Inactive and Archive statuses.

Projects which had been in the older Inactive project status, are updated to a project status of "Analysis/Cleanup". This is to help reinforce that cleaning and analysing the data is the next logical step after data collection in Production status.

Projects in the older Archived status were originally located in an Archive folder at the bottom of the My Projects page.

This Archive folder is renamed to “My Hidden Projects" folder. Projects with Archive status which were previously in this folder are updated to have a status of Analysis/Cleanup. A user can move these projects out of the “My Hidden Projects" folder in the usual way by going to the Organize button at the top of the My Projects page and reallocating them to a chosen folder.

1.Put the project into Draft mode.

2.Add the new form to the project.

3.Reposition the new form to be first in the project

4.Make sure the first field in the new form is the same record ID form as it was before the forms were moved

5.If the new form or the form it is replacing are surveys, make sure the correct forms are enabled as surveys and correct any changes to survey settings. Remember that the first form in the project is what the public survey link will link to-if the former first form was using the public survey link, you cannot move it without changing what the public survey link moves to

6.Put the changes into production.

REDCap administrators, also known as superusers, oversee the REDCap system and its settings. They often have the ability to do things that REDCap end users (regular users) can't do directly. Each REDCap system is overseen by a different group of administrators because each system is independently maintained and supported. The following is a list of some common administrator capabilities and responsibilities. Please contact your system's REDCap administrators if you would like to explore which of the following capabilities are available for your system.

• Project-specific tasks
  • At some institutions, only superusers can create projects.
  • At some institutions, only superusers can move a project to production.
  • Add custom text to the top of the Home page of a project.
  • Add custom text to the top of all Data Entry pages of a project.
  • Add custom logo and institution name to the top of every page of a project.
  • Add grant to be cited.
  • Display a different language for text within a project. The languages available vary by institution.
  • Turn Double Data Entry on and off.
  • Customize the date shift range for date shifting de-identification.
  • Approve API token requests.
  • Delete all API tokens.
  • Create an SQL field, generally used to create a dynamic dropdown list with data drawn either from the same project or another.

• Additional project-specific tasks for projects in production status
  • At some institutions, only superusers can approve some or all production changes, a.k.a. moving drafted changes to production.
  • Delete events.
  • Uncheck instruments from events.
  • Enable/Disable Main Project Settings: Use Longitudinal and Use Surveys
  • Erase all data.
  • Move the project back to development status.
  • Delete the project.

• User-specific tasks
  • Suspend and unsuspend users from all of REDCap. (Note, however, that expiring a users' access to a specific project does not require a REDCap administrator.)
  • For sites that use REDCap's table-based, local authentication, reset the password for a user.
  • Update the email address associated with an account for a user, in case that user is neither able to log in nor has access to the email address associated with their account.

• Cross-project tasks
  • Create project templates.

In Project Setup, under "Design your data collection instruments", click "Download PDF of all data collection instruments".

The first variable listed in your project is the unique identifier which links all your data.

For any type of project, you must define the unique identifier field. This is the first field of the first instrument and if not using a template, the default is Record ID [record_id]. For projects where a survey is the first data collection instrument, the value must be numeric and auto-increments starting with the highest value in the project. If no records exist, it will begin with '1'.

Users can define a unique identifier value that is not numeric (ex: Site-001) and does not auto-increment for projects with surveys: Instead of enabling the FIRST instrument as a survey, have a data collection instrument with data entry fields, then collect data via subsequent surveys.

The secondary unique field may be defined as any field on the data collection instruments. The value for the field you specify will be displayed next to the your unique identifier when choosing an existing record/response. It will also appear at the top of the data entry page when viewing a record/response. Unlike the value of the primary unique identifier field, it will not be visible in the URL.

The data values entered into the secondary unique field must also be unique. The system will not allow for duplicate entries and checks values entered in real time. If a duplicate value is entered, an error message will appear and the value must be changed to save/submit data entered on the data entry instrument.

The redcap_survey_identifier is the identifier defined for surveys when utilizing the Participant Email Contact List and sending survey invitations from the system. The "Participant Identifier" is an optional field you can use to identify individual survey responses so that the participant doesn't have to enter any identifying information into the actual survey. This field is exported in the data set; the email address of the participant is not.

NOTE: redcap_survey_identifier values cannot be used with "piping". If you want to send surveys to participants and pipe in values (ex: first and last name); create a data entry instrument prior to the survey. Add your required fields and an email address to be used for the invitations (on the Project Setup page > Designate An Email). Then you can enter or import your participants' information and send the invitations using piping.

Project users can delete projects that are in Development status by navigating to the 'Other Functionality' tab and then clicking on the 'Delete the project' button. Project users can request that projects in Production status be deleted by navigating to the 'Other Functionality' tab and clicking on 'Request delete project'. Clicking "Request delete project" sends a request to the REDCap Administrator.

NOTE: After a REDCap Administrators deletes a project, it is only permanently removed from the database backend 30 days after deletion. Until that time, REDCap Administrators can undelete the project. The files associated with the project do not get deleted permanently at the same time, but will then be put into *another* 30-day wait until they are actually deleted from the server. So it takes a total of 60 days for the files themselves to get deleted from the time that a user "deletes" a project.

Yes, you can customize both the "End the survey?" pop-up window as well as an alternate survey completion text that is only displayed when a stop action triggers the end of the survey.

The "End of survey?" pop-up window that appears after a stop action is triggered may be edited using Multi-Language Management (MLM). MLM gives you the ability to edit the title, text, and instructions but not the buttons associated with the pop-up. Customizing the language of the "End of survey?" pop-up is on the project level, meaning you are unable to customize different pop-up language per stop action if you have multiple stop actions in the project. To edit the pop-up language, create at least one language under MLM. Under "User Interface" search for "End the survey" to filter items on the page to the title, text, and instruction fields and enter the customized text under "Enter translation" for each customized text. If you leave the translation blank, the default text will appear.  

Alternate survey completion text is customized through the survey settings page of the instrument under "Options related to Survey Stop Actions". The survey completion text will appear only when a stop action is triggered, the survey was ended through the end of survey pop-up, and before the survey is closed. If the alternate survey completion text is left blank, the standard completion text (if applicable) will be used. Since alternate survey completion text is customized per instrument, you may have different customized text per instrument instead of per project like the pop-up customization using MLM above.

To track the amount of time a participant spends taking a survey, you can use the smart variables [survey-duration:instrument:units] or [survey-duration-completed:instrument:units] to pipe the values into field (using @DEFAULT or @SETVALUE), or you can pipe the value into a descriptive field, alert text, or anywhere else you pipe values. [survey-duration] will tell you the difference between the survey start time and the completion time (if completed) or the current time (if not completed). [survey-duration-completed] specifically returns total time it took to complete the survey. If the survey is not complete, it will return a blank value.

You can also use the smart variables [survey-time-started:instrument]/[survey-date-started:instrument] and [survey-time-completed:instrument]/[survey-date-completed:instrument] to capture the survey start and completion times.

Project designers may choose to give participants the ability to return to a previous section on multi-page surveys. In survey settings under "Pagination", the optional 'Hide the "Previous Page" button (i.e, Back button) on the survey page' checkbox will control the ability for participants to update previously entered data. The default unchecked behavior will allow participants to select the "Previous Page" button at the bottom of the survey screen. If you select the 'Hide the "Previous Page" button...' checkbox it will remove the previous page button from pages and not allow the participant to return to the previous page of answers. Once selected even if a participant tries to select the web-browser's back button, they will see a generic "You have partially completed this survey" message and inform them to start over. 

The best way to do this is to go to Survey Settings --> Survey Access --> Time Limit for Survey Completion (optional). Here you can set a period of time the survey is available. The amount of time that each respondent has to complete the survey based on when they were initially sent the survey invitation. Note: This feature excludes public survey links and is not applicable for survey links sent via Alerts & Notifications.

If you need more customization, within the survey itself, you can use branching logic to hide questions based on your date's conditions. You can set up the questions to only be visible within a range that works with your relative dates using a datediff calculation. You would then have a descriptive field stating that the survey is unavailable display if the datediff calculated value falls outside of your accepted range.

The secondary unique field is usually used to ensure that a text entry field, such as MRN or Study ID, is unique across the projects record, which is why it is setup to accept text fields only.

If you want to ensure only one person selects each multiple choice response, such as for a booking system, you can use the action tag @MAXCHOICE and allow one response per answer choice. After someone selects an answer choice, it will be disabled for future data entry and surveys.

Surveys can be enabled at any time in development mode by a project user with "Project Design & Setup" User Rights.

On the Project Setup tab, in the Main Project Settings step at the top, click "Enable" button for "Use surveys in this project?". This feature must be enabled in order to use surveys.

After enabling surveys, go to the Online Designer. A link to that page is on the Project Setup tab, in a lower step on the page. On the Designer, designate which instruments should be surveys by clicking the 'Enable' button next to them. You can enable surveys on as many instruments as you wish.

Each time you designate an instrument as a survey, you will be prompted to define some additional features of the survey. Be sure to scroll down and save those settings. You can return to them at any time to review and modify them as needed, even in production mode. They are found in the 'Survey Settings' buttons that will appear next to each survey instrument in the Online Designer.

To enable surveys for a project in "production" status, you must contact your REDCap Administrator.

It depends on if you have the need for future scheduling or conditional logic. Use this grid to determine the best option for you:

This link [Survey Wizard: The Basics] will take a user to a survey algorithm that was created by the Training Collaboration Committee using REDCap version 7.6.3. It addresses when to enable survey functionality, what to consider when choosing a survey model, and reviews survey setting options.

(URL: https://redcap.vumc.org/surveys/?s=43TD4MRF8A)

Responses can only be collected anonymously using the Survey Distribution Tools > Public Survey Link.

The survey questionnaire must not contain any questions asking the participants for identifying data (ex: What is your email? name? address?).

Multiple Surveys: Be mindful that projects with multiple surveys present potential challenges to anonymous data collection. If you are analyzing data in aggregate, you can having multiple REDCap projects, each using the Public Survey Link. If you need to track individual responses over time, using the Public Survey Link for each survey (pre, post, follow-ups) requires that you collect data points within the survey questionnaire to later export and merge. The data points should not be identifying information, but specific enough question(s) that a participant will enter answers consistently (ex: last 5 digits of their first phone number; color of first car).

Projects containing data entry forms and surveys cannot be considered anonymous. Manually entered data needs to be identified by the team to be properly associated and linked with survey responses.

If the responses need to be anonymous, please see the section Surveys: Anonymous.

If responses do not need to be anonymous, you must at some point collect individual email addresses to send participants multiple surveys and have the data linked. You can do this in a few ways:

1. Project's first instrument is a Survey & Use of Public URL & Designate an email field: If you want to utilize the Public URL to distribute an initial survey and invite participants, the survey MUST contain a text field with validation = email to collect the participant's email address.

On the Project Setup page > Enable optional modules and customizations > Enable: Designate an email field to use for invitations to survey participants. Designate the email address you are collecting on the first survey.

When participants complete the first survey, their email addresses will pre-populate the Participant Lists and will allow you to send additional surveys for the same record.

Surveys will be automatically linked by record ID. Participant Identifier on Participant List will not be editable.

Additional Notes: You will still be able to use the Participant List to send emails to the first survey, if needed. Participant will be prompted to enter their email address on the survey itself. You can also create new records using the Data Entry feature to populate the first survey and manually enter email addresses.

LIMITATION: Only participants that answer the first survey with an email address will be able to respond to the follow-up surveys.

2. Project's first instrument is a Survey & Use of Participant List:

If have individual email addresses, you can create a project with multiple surveys. You would add individual emails to the Participant List with or without a Participant Identifier. Then you can send the survey invites through "Compose Survey Invitations".

LIMITATION: Only participants that answer the first survey will be able to respond to the follow-up surveys. If you wish to collect additional surveys for the non-responders, you will need to create additional REDCap projects with the follow-up surveys. Because of this limitation, you may want to try method #3:

3. Project's first instrument is Data Entry & Use of "Designate an email field":

If you know your email addresses and want participants who haven't completed the first survey to be able to complete the second survey (within the same project), then you can do the following:

1. The first form is a data entry form (ex: "Email Form"). On the "Email Form", at minimum, you can have the participant ID number field and an email field: a text field with validation = email

2. On the Project Setup page > Enable optional modules and customizations > Enable: Designate an email field to use for invitations to survey participants

3. Select the email field you created on the "Email Form"

4. You can either import (Data Import Tool) or enter the email addresses directly into the data entry "Email Form". Entering the emails here will automatically populate the Participant Lists for all surveys in the project

You can send your invites to any surveys regardless of participant's responses and survey completions.

Advantages: You can import a list of pre-defined record IDs and email addresses. Record IDs do not have to be assigned incrementing values by REDCap.

You can setup survey reminders in the same modules that REDCap allows you to send out a survey invitations: Automatic Invitations, Participant List, Compose Survey Invitations.

Yes. If the survey queue has surveys in it, the respondent will see the link for the queue and be able to access it and any surveys that are not locked. This is true even if the survey respondent received the survey trough the "Survey-specific invitation field" option and is not the main respondent for that record, because the survey queue exists on the same level as the record itself, not the individual forms. If there will be multiple respondents for a record and you are concerned about them accessing inappropriate surveys via the survey queue, then you should not use the survey queue for that project.

Both Survey Auto-continue and Survey Queue can be used to direct the flow of surveys in a project.

Generally, Survey Auto-Continue redirects participants to the next available survey, while Survey Queue enables participants to see a "table of contents" of all available surveys, after submitting a survey response.

That said, Survey Queue can also be set up to automatically redirect to the next available survey in the queue, bypassing the "table of contents" view, if the "Keep the Survey Queue hidden from participants?" option is selected.

As a rule of thumb, given the overlap in functionality, it is suggested that you activate only one of these features and leave the other turned off.

Survey Auto-Continue:

• Is easier for many users.
• Optional conditional logic is used to control if the *next* survey is redirected to after the current survey is submitted.
• Simpler, less granular controls - One config per survey applies to the survey across all events.

Survey Queue:

• Provides a landing page for a pt. showing surveys they've already taken and available to be taken.
• Optional conditional logic is used to control whether the current survey is visible in the queue or hidden/skipped over.
• More granular controls - One config per "survey x event" - need to activate and configure the survey across each of its events

Limitations of Auto-Continue:

• No landing page / "table of contents" view

Limitations of Survey Queue:

• If a lot of events, slow to load.
• Can be a challenge in multi-arm projects.
• Survey styling doesn't apply to the table-of-contents view.
• The Survey Queue link at the upper-right corner of surveys and the "Summary" on the end-of-survey page cannot be selectively disabled; either they are both disabled (using "Keep the Survey Queue hidden" option) or both remain visible.

The Auto-continue survey setting overrides the Survey Queue logic. If you want to utilize the Survey Queue, disable the Auto-continue feature first.

Note: Survey Queue only works on instruments that are 'enabled' in the queue. You could potentially have a mix of Auto-continue and Survey Queue. However, it is true that if a survey is enabled in the Survey Queue, it is probably not good to have that same survey (or the survey before it) set up with auto-continue.

To provide improved security to your surveys, you can require the participant to enter specified login credentials in order to begin a survey and if the "Save & Return Later" feature is enabled to return to a previously entered survey response.

To enable the Survey Login feature, there is a button at the top of the instrument list on the Online Designer that will open up the Survey Login settings popup. Users who wish to enable Survey Login may choose one, two, or three fields in their project to be used as the login credential fields for surveys in their project.

The Survey Login can be enabled for ALL surveys in a project or just selected surveys. For selected surveys, navigate to the Survey Settings page to enable.

If Survey Login has been enabled and a record does not exist yet for the respondent (e.g., if they are beginning a Public Survey), then the survey page will display directly without the login page. However, once the record exists, the respondent will always be prompted to log in to the survey.

Note: If a survey has the "Save & Return Later" feature enabled, Return Codes will not be used to return to the survey, but it will use the Survey Login's login credentials instead.

Note: Survey Login cannot be used with a public survey, which requires a Return Code if "Save & Return Later" is enabled.

REDCap specifically checks to ensure it doesn't send a double email to someone. However duplicate notifications can be sent if another user on that project has a slightly different version of your email address on their REDCap account e.g. jane.J.doe@vanderbilt.edu vs jane.doe@vanderbilt.edu. There is another possibility. After a survey participant finishes a survey he or she may refresh the acknowledgement page. This could result in another batch of emails being sent.

Every survey that is submitted is date/time stamped. This completion date and time are available in the data export and data entry forms. However it's not possible to display the current date on the survey while it's being taken by participants.

You can add a question onto your survey to indicate "Today's Date". The calendar pick list will have a button for "Today" or "Now" that the participant can easily click.

Action tags are a relatively new addition to REDCap and can be applied to any variable (see Action Tags info for additional details). These options are available:

@NOW
Automatically provides the user's current time as the value of a Text when the page is loaded. Once the value is captured, it will not be changed when visiting the page at a later time. If the field has validation, the value will conform to the date/time format of the field. The field will be disabled and will not allow users to edit the value. NOTE: The time will be the user's local time, which is derived from their device/computer.

@TODAY
Automatically provides the user's current date as the value of a Text when the page is loaded. Once the value is captured, it will not be changed when visiting the page at a later time. If the field has validation, the value will conform to the date/time format of the field. The field will be disabled and will not allow users to edit the value. NOTE: The date will be the user's current date, which is derived from their device/computer.

@READONLY
Makes the field read-only (i.e., disabled) on the survey page, the data entry form, and in the REDCap mobile app so that its value cannot be changed

When the REDCap system is "offline", participants will no longer be able to view your survey. They will navigate to a page that displays "REDCap is currently offline. Please return at another time. We apologize for any inconvenience.

If you require assistance or have any questions about REDCap, please contact your REDCap Administrator.

Navigate to Project Setup --> Design your data collection instruments & enable your surveys --> Online Designer --> Survey Settings (next to the survey name in the Online Designer). In the "Survey Customizations" section, set "Question Display Format" to "One section per page". Then on your questionnaires, you can create page breaks by adding in fields (field type = "Begin New Section (with optional text)") where you would like those breaks to occur.

No, sections (as separate survey pages) where ALL questions are hidden due to branching logic will be skipped while in survey view. However, this is not true for the last page of any survey, in which the last page will always be displayed, even if all questions are hidden on the page.

Fields on a survey that are hidden by branching logic due to a new value being entered on that same page will have any already-entered values removed, but fields on other pages will not.

While not ideal, this is currently the expected result due to technical limitations.

This situation arises if:

• A survey is configured to show one section per page
• A value is entered for a field on one page
• On another page, a value is entered that causes branching logic to hide the field on the first page.

Project users may designate a field in their project to be the survey participant email field for capturing the email address to be used. The field must be validated as an email to be used for this purpose.

The field can be designated in the "Enable optional modules and customizations" section of the Project Setup page.

Once designated, if an email address is entered into that field for any given record, users will then be able to use that email address for any survey in the project to send survey invitations.

Currently, only English is supported.

You can set the survey expiration date for any survey in the survey settings. REDCap will deactivate the survey at the specified time point.

Note: The survey will be deactivated for all instances of that survey in all arms and events. It's currently not possible to put expiration dates on specific surveys in specific events.

Yes, you can. If you set a time limit (for example, 2 weeks) on a survey and want to change it, you can go back and extend the length of time. If the survey had already closed and you extend the time limit, the old surveys will be re-opened if they are within the new time limit.

Yes. You must enable the "Save and Return Later" option in the Modify Survey Settings section of the Project Setup tab. This option allows participants to save their progress and return where they left off any time in the future. They will be given a Return Code, which they will be required to enter in order to continue the survey.

Note: If a project has the "Survey Login" feature enabled, Return Codes will not be used to return to the survey, but it will use the Survey Login's credentials instead.

If participants forget their Return Code and contact you, you have access to participants codes on their Survey Results page. You will only be able to distribute lost codes if the survey responses capture identifiers. If the survey is "anonymous" you will not be able to recover the Return Code for the participant.

Yes. This feature can be enabled on the Online Designer > Survey Settings page under the "Save & Return Later" section. Once enabled, a respondent will be able to return to their response and make any edits to it even if they have fully completed the survey.

Once enabled as part of the "Save & Return Later" feature, respondents will need to provide a Return Code in order to make edits to a completed survey. If the Survey Login feature is enabled for the survey, then instead of using a Return Code, they will use their login credentials to return to the survey.

If enabled, participants who have completed the survey will still appear in the Participant List in the Compose Survey Invitations popup to allow their invitations to be resent to edit their completed response. Additionally, their survey link and survey return code will also remain in the Participant List for this same purpose.

Note: If Survey Notifications have been enabled for a survey that has the "Edit Completed Responses" option enabled, then whenever the respondent returns to the survey again and completes the survey again, it will again trigger the Survey Notifications to send an email to those users selected.

You can setup a confirmation email in the survey settings of each email in the survey termination section. Select "Yes" on the dropdown and fill in the "From", "Subject" and "Body" sections. You can also add an optional attachment.

Note: REDCap must have an email field defined for the project in order to send out the survey confirmation automatically.

The REDCap/Twilio interaction looks like this:

A longitudinal project is similar to a traditional data collection project in that multiple data entry forms are defined. However unlike the traditional model, forms in a longitudinal project can be completed repeatedly for a single record. The longitudinal model allows any data entry page to be repeated any given number of times across pre-defined time-points, which are specified by the user before data is collected. So rather than repeating a data entry form multiple times in the Data Dictionary, it can exist only once in the Data Dictionary but be repeated N number of times using the longitudinal model.

The longitudinal project lets you define "events" for your project that allow the utilization of data collection forms multiple times for any given database record. An "event" may be a temporal event in the course of your project such as a participant visit or a task to be performed. After events have been defined, you will need to designate the data entry forms that you wish to utilize for any or all events, thus allowing you to use a form for multiple events for the same database record. You may group your events into "arms" in which you may have one or more arms/groups for your project. Each arm can have as many events as you wish. You may use the table provided to create new events and/or arms, or modify existing ones. One arm and one event will be initially defined as the default for all databases.

The Define My Events page allows you to establish the events and scheduling intervals for your project. An "event" may be a temporal visit in the course of your project such as a participant visit or a task to be performed. After events have been defined, you may use them and their Days Offset value to generate schedules. For data collection purposes, you will additionally need to designate the data entry forms that you wish to utilize for any or all events, thus allowing you to use a form for multiple events for the same database record. You may group your events into "arms" in which you may have one or more arms/groups for your project. Each arm can have as many events as you wish. To add new events provide an Event Name and Date Offset for that event and click the Add New Event button.

If you will be performing data collection on this project then once you have defined events in the Define My Events page, you may navigate to the Designate Instruments For My Events page where you may select the data collection instruments that you with to utilize for each event that you defined.

In the traditional data collection model and for surveys, each project record is stored independently as a separate row of data, which can be seen when exported. But for longitudinal projects, each row of data actually represents that particular time-point (event) per database record.

For example, if four events are defined for the project, one record will have four separate rows of data when exported. The data export will include a column "redcap_event_name" indicating the unique event name for each row.

Longitudinal projects are most commonly created for clinical and research data. A longitudinal project is created by selecting the "Longitudinal / repeating forms" collection format for data entry forms when creating or requesting a new project.

First, export the data that you want to transfer out of REDCap. Save as a new CSV file and update the information in redcap_event_name to match the new event name. If you need to find this in REDCap, go to the "Define My Events" page and look for "Unique event name" in the last column. Make sure the variable names match the variables the data will go in, if you are also moving the data to a different form. Save the CSV and go to the "Data Import Tool" under Applications on the sidebar. Choose to upload you CSV and review the data to make sure it is all included and going into the correct variables, event, and arm before finalizing the import.

Go to the first form in the arm from which the subject will be removed and delete the record. This will remove the subject from that arm, but not other arms.

When you copy a project, REDCap will show you a checkbox list of data, settings, and modules you can bring over, including records, users and their user rights/roles, alerts & notifications, and so forth. REDCap will only give you the option to select a box for a setting or module that is used in the existing project. Importantly, project logging is never copied into the new project, so anything in the logs will not migrate to the new project. This includes when records are created and updated, survey timestamps, and information about project management and design tasks.

Provided that both your origin REDCap installation and your destination REDCap installation are on a REDCap version of 6.12.0 or higher, you can perform a CDISC ODM export of the project's metadata on the Other Functionality tab of the Project Setup page.
You have two options for export:

- A export of just the full project setup (including all the variables, forms and settings)
- A export with the full project setup plus all the data captured so far.

Note: Both export options do not include log files or user rights.

To load a CDISC ODM export in your destination REDCap installation, Create or Request a new project and select the "Upload a REDCAp project XML file" option.
This option will allow you to upload your previously downloaded XML file.

Note: Do not upload a data dictionary file during project creation, the system only accepts the CDISC ODM format.

The e-Consent Framework in REDCap helps you obtain participant consent electronically using a REDCap survey. This module is located in the Online Designer under the "e-Consent and PDF Snapshots" button in the Data Collection Instruments header box. The e-Consent Framework offers standardized tools to create and store electronic consent forms, including a certification screen and automatic generation of a PDF copy of the signed form. The official consent document is this generated PDF, which includes a footer containing critical information for regulatory compliance. Always consult your local IRB or regulatory body to ensure that your e-Consent process meets all necessary legal and ethical standards.

Enabling the e-Consent Framework:

1. Navigate to the Online Designer.
2. Enable e-Consent Framework:
• Click "e-Consent and PDF Snapshots" in the Data Collection Instruments header box.
• Enable the e-Consent Framework for a survey.

Configuring Settings:

1. Primary Settings:
• Allow user edits and specify name fields.
2. Additional Settings:
• Add date of birth field, custom headers/footers, and signature settings.
• Specify save locations and customize file names.
• Save your settings.

Adding Consent Versions:

1. Add a New Consent Version:
• Click "Add consent form," specify the version number, and provide the consent form.
• Save the new version.

Note: Always consult your local IRB or regulatory body to ensure compliance. The generated PDF is the official consent document, containing necessary regulatory information.

1. e-Consent PDF Integrity: The official e-Consent is the generated PDF, which can never be changed or modified after it is created.
2. Editing Data in REDCap: The real question is whether the data in REDCap can be altered. This depends on your instance's settings:

- Admin-Controlled Editing: Some instances allow only admins to control the ability to edit e-Consent forms at the project level. If your instance does not have this option enabled, contact your local REDCap administration team to discuss their policies.

- Project-Specific Settings: If your instance allows editing, enabling the "Allow e-Consent responses to be edited by users" option will let users with editing rights modify the form. If this option is not enabled, the consent form cannot be altered after submission.

3. Best Practices: Never alter a signed e-consent. If you are using the module for non-traditional purposes (e.g., not for consenting), best practices depend on your specific use case. Editing the form or survey data will generate a new PDF snapshot, preserving the original and modified versions without altering the PDF.

REDCap offers a "Signature" field type that allows the participant to sign their name electronically. This "Scribble Signature" field captures a handwritten signature using a mouse, stylus, or touchscreen. In many regulatory contexts, including the U.S. Electronic Signatures in Global and National Commerce (ESIGN) Act and the EU's eIDAS regulation, a scribble signature is considered equivalent to a wet signature, meeting the requirements for electronic signatures.

Example regulations include:

- U.S. ESIGN Act: Provides legal recognition of electronic signatures for transactions and documents, ensuring they are as valid as handwritten signatures.

- EU eIDAS Regulation: Establishes a framework for electronic identification and trust services, recognizing electronic signatures and providing guidelines for their legal acceptance.

However, always verify with your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study.

The requirement for a signature field can vary based on your project's regulations. While some studies may require a scribble signature, others may allow participants to type their name. Consult your IRB or regulatory body to determine the specific requirements for your study.

Participants can edit their responses if the "Allow respondents to return and modify completed responses" setting is enabled in the survey settings. However, it's important to note that the official e-Consent is the generated PDF, which cannot be changed or modified once created.

If participants modify their responses, a new PDF snapshot will be generated, resulting in two versions in the file repository: the original and the modified version. This ensures that all versions of the consent form are preserved and no data is lost. For compliance and best practices, always ensure that your e-Consent process meets all necessary legal and ethical standards as advised by your local IRB or regulatory body.

To manage user access to e-consents in REDCap:

1. Navigate to the "User Rights" section of your project.
2. Assign user roles with specific permissions for viewing, editing, and managing e-consents.
3. Utilize Data Access Groups (DAGs) to restrict access to e-consent forms based on user groups, ensuring that only authorized personnel can access sensitive data.

Version control in the e-Consent framework tracks changes to consent forms over time, allowing you to manage different versions as the study progresses. This ensures compliance with regulatory requirements by maintaining a complete audit trail.

To use version control in your e-Consent form:

1. Enable the e-Consent Framework: Navigate to the Online Designer, enable the e-Consent Framework for your consent instrument, and configure the necessary settings to use it to collect consent.
2. Create a field for your consent: Create a descriptive field in the consent form that you will use for your consent PDF or text.
3. Click "Add consent form" on the e-Consent Framework page under your survey: Add your consent number, specify the field that contains your consent document, and make any rules for DAGs or specific languages. The either provide the consent form as rich text or upload a PDF of your consent form document in the "Consent Form (Rich Text)" or "Consent Form (Inline PDF)" tabs. This will automatically appear in the field that you specified as containing your consent document.
4. To update your consent form: Click on the "Add consent form" button under the survey in the e-Consent Framework settings. Give it a new consent version and provide the new consent document in the "Consent Form (Rich Text)" or "Consent Form (Inline PDF)" tabs.
5. Viewing all versions: Use the "View all versions" link under the survey in the e-Consent Framework Settings to view all past consents and to set the current consent form as inactive.

When using the version control, be aware that all versions go live immediately after activation and cannot be reverted.

Always contact your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study.

If your study requires multiple consents (e.g., different consent for different study phases or participant groups), you can manage each consent form independently using the e-Consent Framework. Here are two approaches to handle multiple consents effectively:

Multiple Instruments:

Independent Management: Create separate instruments for each consent form and enable the e-Consent Framework for each instrument independently. This allows each consent form to have its own version control and PDF snapshot settings, ensuring that all consents are properly tracked and stored.

Branching Logic:

• Dynamic Display: Use branching logic within a single instrument to display the appropriate consent form based on participant responses or study phase criteria. This ensures that participants see the correct consent form tailored to their specific situation.
• Framework Integration: Enable the e-Consent Framework for the instrument and configure the branching logic to ensure the correct consent form is presented and managed.

Always contact your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study.

The e-Consent Framework supports capturing multiple signatures across different forms. Each form can independently use the e-Consent Framework and generate its own PDF snapshot. For scenarios requiring multiple signatures on the same form, follow these steps to ensure that each signature field is properly configured and captured in the PDF snapshot:

1. Create Separate Consent Forms (if needed):
   • If your study requires signatures from different stakeholders (e.g., participant and guardian), create separate consent forms for each stakeholder. Each form should independently use the e-Consent Framework.
2. Enable e-Consent Framework for Each Form:
   • In the Online Designer, enable the e-Consent Framework for each form that requires a signature. Configure the settings for each form, including the signature fields and any other required fields.
3. Configure Signature Fields:
   • Ensure that each signature field is properly configured in the form. Use the 'Signature' field type for capturing scribble signatures.
4. Set Up PDF Snapshots:
   • Navigate to the e-Consent Framework and PDF Snapshots button from the Online Designer.
   • Select the PDF Snapshots tab and add a new trigger.
   • Define the conditions for the trigger, specifying the forms that will be included in the snapshot. Ensure that all relevant signature fields are included for multiple signatures on the same form.
   • Choose the storage location for the snapshot (File Repository or specified field).
   • Customize the file name template for the snapshot, if desired.
   • Save the trigger settings.
5. Generate PDF Snapshots:
   • The system will automatically generate PDF snapshots based on the configured triggers. Each snapshot will include the captured signatures and any other relevant information.
6. Verify Setup:
   • Run a test to verify that the PDF snapshots are generated correctly and include all required signatures. Ensure that the snapshots are stored in the specified location and are accessible for audit and compliance purposes.

Always contact your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study.

The e-Consent Framework supports Data Access Groups (DAGs), allowing you to manage consent forms for different groups of users. Each version of the consent form can be associated with specific DAGs, ensuring that only authorized users within the designated groups can access and manage the consents. Here's how to set it up:

1. Enable Data Access Groups:
   • Ensure that DAGs are enabled in your REDCap project. This can be done through the project settings or by contacting your REDCap administrator.
2. Create Consent Forms:
   • In the Online Designer, create your consent form, ensuring it includes all necessary fields, such as participant name, date of birth, and signature fields.
3. Enable e-Consent Framework for the Consent Form:
   • In the Online Designer, enable the e-Consent Framework for the consent form.
   • Configure the settings for the e-Consent Framework, including the primary settings and signature fields.
4. Add Consent Versions for Each DAG:
   • Within the e-Consent Framework settings, add a new consent version for each DAG.
   • When adding a new consent version, specify the DAG associated with that version. This ensures that the version log will track the DAG for each consent form version.
5. Configure PDF Snapshots:
   • Navigate to the e-Consent Framework and PDF Snapshots button from the Online Designer.
   • Select the PDF Snapshots tab and add a new trigger.
   • Define the conditions for the trigger, specifying the forms and DAGs that will be included in the snapshot.
   • Choose the storage location for the snapshot (File Repository or specified field).
   • Customize the file name template for the snapshot, if desired.
   • Save the trigger settings.
6. Assign Users to DAGs:
   • In the User Rights section of your REDCap project, assign users to the appropriate DAGs. This will restrict access to consent forms based on the user's DAG membership.
   • Ensure that only authorized users within the designated DAGs can access and manage the consent forms.
7. Verify Setup:
   • Run tests to verify that consent forms are correctly restricted to users within the appropriate DAGs.
   • Ensure that the PDF snapshots are generated correctly for each DAG version and are stored in the specified location.
8. Track Version and DAG in Version Log:
   • The version log within the e-Consent Framework will automatically track the DAG associated with each version of the consent form. This helps maintain a clear record of which DAG was responsible for each version.

The PDF Snapshot feature in REDCap allows you to automatically generate and store PDF copies of completed surveys and consent forms. This feature ensures secure and organized storage of survey responses and consent documents, meeting regulatory requirements and improving data integrity.

1. Navigate to the Online Designer:
   • Go to the Online Designer page in your REDCap project.
2. Access e-Consent Framework and PDF Snapshots:
   • Click on the e-Consent Framework and PDF Snapshots button.
   • Select the PDF Snapshots tab.
3. Add New Trigger:
   • Click the "Add new trigger" button.
   • Define the conditions for the trigger (e.g., survey completion, specific field value).
4. Specify Forms and Storage Location:
   • Specify which forms and/or surveys will be included in the snapshot.
   • Choose where the snapshot will be stored (File Repository, specified field, or external storage).
5. Customize File Name:
   • Customize the file name template for the snapshot, using static text or piping, appended with the date-time of the snapshot generation.
6. Save the Trigger:
   • Save the newly configured PDF snapshot trigger.
   • Test the setup to ensure everything is configured correctly.

Yes, you can modify or copy an existing PDF Snapshot trigger. To do this:

1. Navigate to the PDF Snapshots Tab:
   • Go to the Online Designer and select the PDF Snapshots tab.
2. Modify a Trigger:
   • Locate the trigger you want to modify.
   • Click the edit button next to the trigger to make changes.
3. Copy a Trigger:
   • Locate the trigger you want to copy.
   • Click the copy button next to the trigger to duplicate it.
   • Make any necessary changes to the copied trigger and save it.

Yes, the PDF Snapshot feature supports enhanced conditional logic integration. You can define conditions for the snapshot trigger based on specific events or field values. This allows for more granular control over when and how PDF snapshots are generated.

PDF snapshots can be stored in multiple locations, depending on your project needs:

1. File Repository:
   • The default storage location for PDF snapshots is the project's File Repository.
2. Specified Field:
   • You can choose to store the snapshot in a specified field within the project.
3. External Storage:
   • If external storage is enabled (e.g., SFTP, WebDAV, Azure, S3), PDF snapshots can also be stored on an external file server for additional security and compliance.

To customize the file names of PDF snapshots:

1. Navigate to the PDF Snapshots Tab:
   • Go to the Online Designer and select the PDF Snapshots tab.
2. Edit or Add a Trigger:
   • When configuring or adding a new trigger, you can define the file name template.
3. Customize File Name Template:
   • Use static text, smart variables, and piping to customize the file name.
   • The file name will automatically include the date-time of the snapshot generation.

Ensuring compliance and security with PDF Snapshots involves multiple aspects typically managed at the admin level based on site-specific policies and procedures. Here's what you need to know:

1. Data Encryption: The REDCap administrators generally configure data encryption settings according to your institution's policies. Users should contact their local REDCap admin team to understand their instance's encryption settings and procedures.
2. Access Controls:
   • Access to PDF snapshots is controlled through project design and user rights.
     • Project Design Control: This affects how consents are created, associated with surveys, and used.
     • User Rights: These settings determine who can access the file repository where PDF snapshots are stored. Special user rights such as Data Access Groups (DAGs) can also restrict access to specific users.
   • Users should ensure that appropriate permissions are set within their project to maintain security and compliance.

3. Audit Trails: REDCap automatically logs all actions related to PDF snapshot generation. Regularly reviewing these audit logs can help monitor for unauthorized access or modifications. - For detailed information on your instance's logging policies, contact your local REDCap admin team.

Best Practices:

• Always consult with your local REDCap administration team to understand your instance's settings, policies, and procedures to ensure compliance and security for your PDF snapshots and overall project data.
• Always contact your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study

REDCap can customize the header and footer of the PDF consent form. This can be done in the e-Consent Framework settings:

1. Navigate to the Online Designer:
   • Go to the Online Designer page in your REDCap project.
2. Access the e-Consent Framework:
   • Click on the e-Consent Framework button.
   • Select the survey for which you want to customize the header and footer.
3. Customize Header and Footer:
   • In the e-Consent settings, you can add static text, smart variables, and piping to the header and footer sections.
   • Customize the content as needed to include relevant information such as participant IDs, study names, and dates.

User access to PDF snapshots can be managed through:

• The "User Rights" section where permissions for accessing the File Repository and specific fields can be set.
• Ensuring that only authorized users have permission to view, download, or manage PDF snapshots stored in the File Repository or specified fields.

REDCap automatically logs all actions related to e-consents and PDF snapshots, creating a comprehensive audit trail. This includes:

• The creation, modification, and viewing of e-consent forms.
• The generation and storage of PDF snapshots.
• User interactions with e-consents and PDF snapshots, ensuring all activities are recorded for compliance and review.

To review audit trails:

1. Navigate to the "Logging" section in your REDCap project.
2. Filter logs to view specific actions related to e-consents and PDF snapshots.
3. Use the audit logs to verify compliance with regulatory requirements and ensure all actions are properly documented.

The terms "variable name" and "field name" are used interchangeably in REDCap. Variable names can only contain lowercase letters, numbers, and underscores. It is important to note that while numbers are allowed within a variable name, it is not possible to start a variable name with a number. Although the technical limit for a variable name is extremely long, best practice is to keep them short while still being meaningful. You may receive a pop up warning when a variable name exceed 26 characters; as this length could potentially lead to complications when exporting data to certain statistical software packages. 

Additionally, there are a few more restrictions enforced on variable names. While it is possible to include some of these terms in a variable name, it is not possible to name a variable any of the following: 

No. There are no restrictions on the length or number of fields per instrument. The best practice is to keep instruments fairly short for easier data entry, and to ensure that you're saving data to the server more frequently.

For long surveys, you can use section headers and enable the feature "Display Questions" = One Section Per Page. This will allow participants to save each section when they click "next page".

REDCap defines Data Collection Instruments as "data entry forms" and "surveys".

With "surveys" you can collect data directly from participants. Participants will access your questions via a secure webpage. No authentication is required; however, you can enable the Survey Login feature if needed.

With "data entry forms", data is entered by authorized REDCap project users. REDCap log-in access and project rights are required to view and edit the data entry forms.

You can hardcode emoticons into the label--you can find a list of the codes here: https://emojiguide.org/

If you use this option, make sure to test using the data dictionary and test it in different browses to make sure they all recognize the codes you're using.

The other option is to create a descriptive field with images in the proper places and put it above the radio buttons of LH alignment.

Project Setup tab -> Enable optional modules and customizations section -> click on "Additional customizations" button -> check/uncheck "Require a 'reason' when making changes to existing records?"

Require a 'reason' when making changes to existing records?
Require users to enter a reason (200 character max) in a text box when making any data changes to an already existing record on a data collection instrument. The prompt is triggered when clicking the Save button on the page. Any 'reasons' entered can then be viewed anytime afterward on the Logging page.

The general data entry templates are static and cannot be changed. Survey Themes in the Survey Settings page allows you to customize the font and background colors for many sections of a survey.
REDCap does allow the use of some HTML and CSS in the Field Label and Field Notes. Please note that HTML tags print as text on the pdf exports/forms and do not print the formats created with the HTML tags.
Check out this example survey for formatting ideas: https://redcap.vumc.org/surveys/?s=JA3AXMHYC7

It is possible to embed a free text field (for example, a text box next to an "Other" option) next to an answer choice in a radio question, but not in a dropdown question. To do this with a dropdown, you first need to create a secondary field that is a descriptive field and then embed both the dropdown and the text box in the same descriptive field.

While branching logic is only available on a field-by-field basis, REDCap does have what could be considered a form-level branching logic called Form Display Logic. Form display logic is located on the online designer page of your REDCap project. Form display logic may be used to disable an entire instrument(s) for data collection until certain conditional logic is met. The form will still appear on the record status dashboard (unless you hide the form using a custom record status dashboard), but the form will be inaccessible and greyed out. During data collection, the "Save & Go To Next Form" button will save the current form and skip any forms that should be disabled by form display logic. 

In the case of surveys, you may skip entire surveys by using either the Survey Queue (located on the online designer page) or Conditional logic for Survey Auto-Continue (located in the individual instruments survey settings).

Branching logic is only available on a field-by-field basis. While it cannot be applied at once to a section within an instrument, you could skip an entire section of a form using branching logic. To skip an entire section, you would need to create branching logic on ALL fields within two section header fields on the instrument. Section headers themselves, do not allow for branching logic. If branching logic hides all fields within two section headers the first section header will also be hidden. This would hide or skip that entire section on the instrument. 

If the section can be separated into a different instrument without other fields not related to the branching logic, REDCap does have what could be considered a form-level branching logic called Form Display Logic. Form display logic may be used to disable the entire instrument for data collection until certain conditional logic is met. The form will still appear on the record status dashboard, but the form will be inaccessible and greyed out (unless you hide the form using a custom record status dashboard).

In the case of surveys, you may skip entire surveys by using either the Survey Queue (found in the online designer) or Conditional logic for Survey Auto-Continue (found in the individual instruments survey settings).

1. If the project is still in development, then download the current data dictionary and save as Version 0. This step is not necessary for a project already in production since REDCap stores all previous versions of the data dictionary (since moving to production) in "Project Revision History".

Note: If study records already exist in the database, then it is good practice to export the raw data before proceeding. It is important to have a backup of your project as it currently exists should you need to go back to the original version.

2. Make a copy of the Version 0 database and save as Version 1 in CSV format.

3. Make edits/additions/deletions to Version 1 and save.

4. Upload the entire revised Version 1 data dictionary to your project.

Warning: Uploading the new data dictionary will overwrite, not update, the original data dictionary (Version 0), so it is necessary to upload the revised file in its entirety. If you have multiple developers on a project, it is also important to communicate and coordinate revisions. You do not want to be working on an outdated "local" version of your data dictionary if others have been updating the project in REDCap. Always download a new current version prior to making changes.

Setting up a biomedical ontology in the data dictionary is done by first defining a variable with the text field type without any other validations attached.
You will also have to define which ontology you want for this variable. You do this by inserting the text "BIOPORTAL:" plus the correct shorthand code into the "choices, Calculations, OR Slider Labels" column in the data dictionary (typically column F).

E.g. A lookup for the ICD-10 ontology would need to be coded as "BIOPORTAL:ICD10".

Be careful to make sure that the entire code is in all caps and does not contain the quotation marks.

The ontology lookup short hand codes can be found in two ways:

1) In the online designer, look for the biomedical ontology dropdown (only visible in text variables). Each ontology will have the shorthand code displayed before the dash.

e.g. Entry: "ICD10 - International Classification of Diseases, version 10". The "ICD10" part is the shorthand code.

2) Go to the bioportal website and look for your ontology of choice. In the description of any ontology, there will be a field for "acronym". That acronym is what REDCap uses as a shorthand code.

Download the data dictionary for the project. Make sure the forms are all next to each other and change the instrument name for all the instruments you want to combine to the same name. Save the data dictionary as a CSV and upload it back into REDCap. The forms will now be one form with the new name.

The Field Type dictates how the field will be shown on the data entry form or survey and what data type will be collected.

Options include:

Unstructured Fields: Unstructured data such as text and notes fields collect information that does not have a pre-defined data model such as dates, numbers, and strings of text. 

Structured Fields: Structured data is a pre-defined data model with an established set of answer choices in a standardized format.

Unique Fields: The unique field types collect data that does not align with structured/unstructured data but are each distinct in the type of data collected such as documents, interactive image capturing, or calculations.  

Descriptive Fields: Descriptive fields are fields that do not collect data but rather provide information on data entry forms and/or surveys.

Dynamic Query (SQL) Fields: Only REDCap administrators can program SQL fields. If you would like more information about SQL fields at your institution, please reach out to your REDCap administrator. 

Dropdown:

1. Ability to use short cut keys
2. Less space on forms; use when you have limited space

Radio Button:

1. Good when you need your choices visible
2. Good option for minimal response options
3. Available with the matrix options when building forms

If validation is employed for text fields, min and max values may be utilized. Min, max, neither or both can be used for each individual field. The following text validation types may utilize min and/or max values:

The maximum number of characters are:

• Field name: *Recommended: <26, Max: 100
• Field label: ~65,000
• Text typed into a "text box" field: ~65,000
• Text typed into a "notes box" field: ~65,000

*Most stats packages (SAS, STATA...) will truncate variable/field names to max of 26 characters.

RV - right vertical

RH - right horizontal

LV - left vertical

LH - left horizontal

Yes, you can upload documents for individual records.

To create a new document upload field in the Data Dictionary for any given REDCap project, set the Field Type = 'file'. You may add as many 'file' fields as needed to your data collection instruments.

Documents can be uploaded and downloaded by navigating to the record's data entry page and clicking the file link. A document can be deleted at any time, and there is no limit to how many times the document can be replaced by uploading another file to that record's file upload field.

Contact your REDCap Administrator to confirm if this field type is available and what the maximum upload file size is at your institution.

Yes. When your data are exported, each option from a checkbox field becomes a separate variable coded 1 or 0 to reflect whether it is checked or unchecked. By default, each option is pre-coded 0, so even if you have not yet collected any data, you will see 0's for each checkbox option. The variable names will be the name of the field followed by the option number. So, for example, if you have a field coded as follows:

Race

1, Caucasian

2, African American

3, Asian

4, Other

In your exported dataset, you will have four variables representing the field Race that will be set as 0 by default, coded 1 if the option was checked for a record. The variable names will consist of the field name. three underscores, and the choice value:

race___1
race___2
race___3
race___4

Notes:

• when you import data into a checkbox field, you must code it based on the same model
• negative values can be used as the raw coded values for checkbox fields. Due to certain limitations, negative values will not work when importing values using the Data Import Tool, API and cause problems when exporting data into a statistical analysis package. The workaround is that negative signs are replaced by an underscore in the export/import-specific version of the variable name (e.g., for a checkbox named "race", its choices "2" and "-2" would export as the fields

race___2

race____2

A checkbox field can be thought of as a series of yes/no questions in one field. Therefore, a yes (check) is coded as 1 and a no (uncheck) is coded a 0. An unchecked response on a checkbox field is still regarded as an answer and is not considered missing.

For a question with an unknown number of answers, such as how many medications someone is taking, you may want to display the fields only as they are needed. REDCap currently is not able to dynamically create fields; however, there is a way to use branching logic to approximate this.

If you can estimate the maximum number of fields you will need, you can create that many copies of your field to hide and display as needed using branching logic.

Example 1: If you think 15 is a good maximum, you would create 15 copies of the field. Then, in order to only show the fields that are needed, you could create a "count" variable. Your branching logic would look like this:

field1: [count]>0

field2: [count]>1

field3: [count]>2

and so on.

If your variable is medications, and the respondent takes 2 medications, you enter 2 in [count] variable, then the med1 and med2 fields appear. If they take 3, you enter that, and meds1 to med3 fields appear.

Example 2a: Another method is to first create the maximum number of fields that you estimate will be needed, as above, and then hide and display each field as the previous field receives data. Using this method will cause each field to show up as needed. Your branching logic would look like:

field2: [field1] <> "" or [field2] <> ""

field3: [field2] <> "" or [field3] <> ""

field4: [field3] <> "" or [field4] <> ""

and so on.

The fields in this example are text fields. If field1 "does not equal blank" (aka if data is entered for field1), then field2 will display. This example will also retain any given field that happens to have data already.

Example 2b: If you want to only show a field if there is not a previous field that is empty, the branching logic will need to check every previous field:

field2: [field1] <> ""

field3: [field1] <> "" and [field2] <> ""

field4: [field1] <> "" and [field2] <> "" and [field3] <> ""

and so on.

Text Validation Types: Use for text field data validation

Dates can be formatted as mm-dd-yyyy, dd-mm-yyyy, and yyyy-mm-dd by using the text field > validation. These formats cannot be modified.

New validation types are not automatically available will need to be enabled by your REDCap Administrator. Once enabled, they'll appear in the text validation drop-down list in the Online Designer. All formats are available via the Data Dictionary.

If you have another field validated as a date and with the @TODAY (and possibly the @HIDDEN or @READONLY), then you could use a Data Quality rule with the "Execute in real time on data entry forms" checkbox checked. The DQ rule real time execution won't work on a survey, so on a survey you would need to settle for a descriptive text field that displays an error message if the date is greater than your date field with @TODAY in it.

Yes. You can turn it off on the project level by going to "Enable optional modules and customizations" on the Project Setup page. Go to "Additional Customizations" and uncheck "Display the Today/Now button for all date and time fields on forms/surveys?"

To turn it off on the field level, you can use the actin tag @HIDEBUTTON on that field.

REDCap doesn't have a specific function for e, so you will need to use the numerical equivalent to e and calculate on that. For example:

(2.718281828) ^ ([field_1]). Both sides of the exponent need to be encased in parentheses.

There are 18 pieces of information that are considered identifiers (also called protected health information, or PHI) for the purposes of HIPAA compliance. When you indicate a variable as an Identifier, you have the option to "de-identify" your data on data exports. In the Data Export Tool, the identifier variables appear in red and there are de-identification options you can select prior to exporting the data.

The 18 HIPAA identifiers are:

In a data dictionary, creating a matrix of fields is as easy as creating any regular radio button field or checkbox field. Create your first field in the matrix as either a radio or checkbox field type (since matrix fields can only be either of these) by adding it as a new row in the data dictionary. You must provide its variable name and form name (as usual), then set its field type as either "radio" or "checkbox". Then set its field label in column E, its multiple choice options in column F, and then lastly in column P you must provide a Matrix Group Name.

The matrix group name is how REDCap knows to display these fields together as a matrix. Without a matrix group name, REDCap will display the fields separately as normal radio buttons or checkboxes.

The matrix group name can consist only of lowercase letters, numbers, and underscores, and the group name must not duplicate any other matrix group name in the project.

After you have created your first field for the matrix and have given it a matrix group name, you may now create the other fields in the matrix in the rows directly below that field.

To save time, it is probably easiest to simply copy that row and paste it as the next immediate row in the Data Dictionary. Then you only need to modify the variable name and label for the new row. Once you have created all your fields for the matrix, you can upload your data dictionary on the "Data Dictionary Upload" page in your REDCap project, and those fields will be displayed as a matrix on your data collection instrument.

NOTE: All fields in a matrix must follow the following rules:

1. must be either a "radio" or "checkbox" field type,
2. must have the *exact* same choices options in column F,
3. must have the same matrix group name in column P.

If these requirements are not met, the "Upload Data Dictionary" page will not allow you to upload your data dictionary until these errors are fixed.

Any existing group of radio button fields or checkbox fields in a REDCap project might possibly be converted into a matrix of fields. In order for fields to be grouped together into a matrix, the following things are required:

1. fields must all be a Radio Button field or all be a Checkbox field,
2. they must have the *exact* same multiple choice options (same option label AND same raw coded value), and
3. they must all be adjacent to each other on the same data collection instrument (or if not, they can be moved first so that they are adjacent).

A matrix can be created only if those three conditions are met. The conversion of regular checkbox/radio fields into a matrix of fields cannot be done in the Online Designer but only using the Data Dictionary. To accomplish this:

1. Download the existing data dictionary for the project from the "Upload Data Dictionary" page.
2. Add to column P (i.e. Matrix Group Name) the matrix group name for *every* field that will be in the matrix.
3. Save and upload the data dictionary on the "Data Dictionary Upload" page
4. Confirm those fields display as a matrix on your data collection instrument instead of separate fields.

NOTE on Matrix Group name: The matrix group name is a tag that is used to group all the fields together in a single matrix group. The matrix group name can consist only of lowercase letters, numbers, and underscores, and the group name must not duplicate any other matrix group name in the project. The group name is not ever displayed on the form/survey during data entry, but is used only for design and organizational purposes. The matrix group name can be any value (even an arbitrary value), but it may be helpful to name it something related to the fields in the group (e.g. "icecream" if all the matrix fields are about ice cream).

REDCap can display a matrix group of fields in either Single Answer format (i.e. radio buttons) or Multiple Answer format (i.e. checkboxes). A matrix allows you to display a group of similar multiple choice fields in a very compact area on a page. This makes data entry forms and surveys much shorter looking. Using matrix fields is especially desirable on surveys because survey respondents are much less likely to leave a survey partially completed if the survey appears shorter, as opposed to looking very long, which can feel daunting to a respondent. So having compact sections of questions can actually improve a survey's response rate.

A matrix can have as many rows or columns as needed. Although the more choices you have, the narrower each choice column will be. Any field in a matrix can optionally have its own branching logic and can be set individually as a required field. A matrix can also optionally have a section header.

The data dictionary is the only way to add/edit field notes on matrix fields.

The 'Piping' feature in REDCap allows you to inject previously collected data into text on a data collection form or survey, thus providing greater precision and control over question wording. See more about piping: https://redcap.link/piping

When you are piping the answer *FROM* a multiple Choice radio or drop-down field, it will by default display the option label (not the coded data value) into the location where the field is piped.

You can however specify that the value is piped instead of the label.

For example if your field of Favorite Ice Cream Flavor is a radio or drop-down field coded 'Chocolate', 'Vanilla', and 'Strawberry' (coded as 0, 1, 2, respectively), and you use [flavor] in your piping, the default resulting display will be Chocolate, Vanilla or Strawberry.

If you wish to pipe the value (not the label) of a multiple choice field, append ':value' to the variable name inside brackets - e.g., [flavor:value]. In the above example this would return 0,1, or 2).

You should also use ':value' if piping inside the @DEFAULT Action Tag if you would like to pipe the value of a multiple choice field as the default value of a field.

If you wish to pipe the value (not the label) of a checkbox field you may also append ':value' to the variable to return the raw value instead of the label.

For example, if the Favorite Ice Cream Flavor field is a checkbox field and a respondent checked Chocolate (0) and Strawberry (2) as preferred flavours, then use [flavor:checked:value] and [flavor:unchecked:value] to return '0, 2' and '1', respectively.

To pipe a specific option code’s value use [flavor(2):value] will return the raw value of 1 when Strawberry is checked or 0 if Strawberry is not checked.

Code options:

Icecream Flavor checked: [flavor:checked]
Icecream Flavor checked value : [flavor:checked:value]
Icecream Flavor unchecked : [flavor:unchecked]
Icecream Flavor unchecked value : [flavor:unchecked:value]
Icecream Flavor Coded value 2: [flavor(2)]
Icecream Flavor Coded value 2 value: [flavor(2):value]

Returns:

Icecream Flavor checked: Chocolate, Strawberry
Icecream Flavor checked value: 0, 2
Icecream Flavor unchecked: Vanilla
Icecream Flavor unchecked value: 1
Icecream Flavor Coded value 2: Checked
Icecream Flavor Coded value 2 value: 1

In every REDCap project, you can find a link to more information about piping by clicking on the purple “Piping” button in the “Design your data collection instruments” box on the Project Setup page.You can also go to https://redcap.vumc.org/redcap_v15.9.3/DataEntry/piping_explanation.php for more detailed documentation on piping.

The Participant List Identifier cannot be used as a location to pipe information to or from. If you are using the participant list with the identifier enabled then your survey is the first form in the project and you have not collected any data about that subject to pipe from/to. If your survey form is not the first form and you are using the participant list the identifier will default to the study id of the record. You can use a data entry form as your first form with "Designate an email field to use for invitations to survey participants" enabled to build a robust participant list that could have information piped into the survey invitation and the body of the survey(s) itself.

You just repeat the process of adding an instrument to the library. Choose Share your instrument and follow the instructions. You will see a note that says you are replacing the existing instrument. There's also an option to delete the existing instrument if you want to completely remove it.

Calculated fields are a powerful tool in REDCap that can be used during both data entry and analysis.  For data entry, for instance, a calculated field could be used to determine a current age, and then that calculated field could be used by branching logic to only show certain questions to those who are 17 and under. Examples for data analysis include assigning different values to a choice based on some other field (perhaps the weight of a choice is dependent on age or sex), or producing the summation of a set of questions.

REDCap calculations can include various mathematical operations from basic (addition, subtraction, etc.) to complex (standard deviation, rounding, mean, etc.), as well as conditional (if/then/else), and follow the standard order of mathematical operation. Calculated fields always result in a number. For calculations that produce a date or text, one can us the CALCDATE and CALCTEXT action tags on a text field.

You can view the functions available in REDCap at this link: https://iihmrdelhi.org/redcap/redcap_v16.0.5//DataEntry/special_functions_explanation.php

+ Add

- Subtract

* Multiply

/ Divide

NOTE: All values that are not a number (including Null or blank values) are converted to "", so when testing whether or not a field is empty, you must compare to "", such as:

if ([my_field] <> "", [my_field], 0)

Computers store information as a series of ones and zeros, called binary, and although it's easy to write a number like 0.1, it's impossible for a binary system to represent 0.1 exactly. Because of this, a calculation like 165 * 0.7 might lead to a result like 115.499999 instead of the expected 115.5. When this happens, REDCap is attempting to represent the concept of the 9s repeating indefinitely, which is logically the same as the expected 115.5, but since there's also a limit on how many digits can be displayed, the infinitely repeating 9s are cut off.

This can lead to a problem when attempting to round a number. In the above case, if we round the number to the nearest integer, e.g. 'round(165 * 0.7),' the expected result is 116, but because of the nature of binary numbers and the inability to handle infinitely repeating decimals, the actual result is 115.

One way to avoid this rounding problem is to add a very small amount to the number being rounded, e.g. 'round(value + 0.000001)'. Typically one would add a number at least a couple of decimal points smaller than the significant digits of what is being rounded. So, for instance, in the above example one might add 0.0001, such that instead of 115.499999 being rounded down to 115, 115.500099 would be rounded up to 116.

In order for the calculated field to function, it will need to be formatted in a particular way. This is somewhat similar to constructing equations in Excel or with certain scientific calculators.

The variable names/field names used in the project's Data Dictionary can be used as variables in the equation, but you must place [ ] brackets around each variable. Please be sure that you follow the mathematical order of operations when constructing the equation or else your calculated results might end up being incorrect.

For a calculated field, if the dependent variables are simply added together, then if any of the variables are empty, the resulting calculation will be empty:

[answer1] + [answer2] + ... + [answerN] 

If, however, you use the 'Sum' function, than the resulting calculation will not be empty:

sum([answer1],[answer2], ... [answerN])

You can also use an 'if' statement to provide any desired value in place of an empty dependent variable. In the following case '-1' is supplied:

if([answer1] = "", -1, [answer1])

"" refers to any value that is not a number. For calculations, anything that is not a number is replaced with "" before the calculation is interpreted.

The calculation can have the final "else" evaluation be null by using "" or '' to indicate a null value. That would allow the calculated field to be hidden without creating popup warnings about values in hidden fields during data entry.

Yes, for longitudinal projects (i.e. with multiple events defined), a calculated field's equation may utilize fields from other events (i.e. visits, time-points). The equation format is somewhat different from the normal format because the unique event name must be specified in the equation for the target event. The unique event name must be prepended (in square brackets) to the beginning of the variable name (in square brackets), i.e. [unique_event_name][variable_name]. Unique event names can be found listed on the project's Define My Event's page on the right-hand side of the events table, in which the unique name is automatically generated from the event name that you have defined.

For example, if the first event in the project is named "Enrollment", in which the unique event name for it is "enrollment_arm_1", then we can set up the equation as follows to perform a calculation utilizing the "weight" field from the Enrollment event: [enrollment_arm_1][weight]/[visit_weight]. Thus, presuming that this calculated field exists on a form that is utilized on multiple events, it will always perform the calculation using the value of weight from the Enrollment event while using the value of visit_weight for the current event the user is on.

Yes. You may use conditional logic (i.e. an IF/THEN/ELSE statement) by using the function:

if (CONDITION, value if condition is TRUE, value if condition is FALSE)

This construction is similar to IF statements in Microsoft Excel. Provide the condition first (e.g. [weight]=4), then give the resulting value if it is true, and lastly give the resulting value if the condition is false. For example:

if([weight] > 100, 44, 11)

In this example, if the value of the field 'weight' is greater than 100, then it will give a value of 44, but if 'weight' is less than or equal to 100, it will give 11 as the result.

IF statements may be used inside other IF statements (“nested”). For example, if you wanted to look for values above ten if the chosen category was 4, but look for values below 20 if any other category was chosen, you could use:

if([chosen_category] = "4", if([given_value] > 10, 1, 0), if([given_value] < 20, 1, 0))

Other advanced functions (described above) may also be used inside IF statements.

If the calculations result in a value (including "0"), the field will display regardless of branching logic.

You can hide calc fields with branching logic if you include conditional logic and enter the "false" statement to result in null: " " or "". For example: if([weight] > 100, 44, "") Then the field will remain hidden (depending on branching logic) unless the calculation results in a value.

Another relatively new option is to use an Action Tag:

@HIDDEN
Hides the field on the survey page, the data entry form, and in the REDCap mobile app. Field will stay hidden even if branching logic attempts to make it visible.

@HIDDEN-FORM
Hides the field only on the data entry form (i.e., not on the survey page). Field will stay hidden even if branching logic attempts to make it visible.

@HIDDEN-SURVEY
Hides the field only on the survey page (i.e., not on the data entry form). Field will stay hidden even if branching logic attempts to make it visible.

@HIDDEN-APP
Hides the field only on the form ONLY on the REDCap Mobile App. Field will stay hidden even if branching logic attempts to make it visible.

Yes. Calculations can reference other calculations. Be sure to thoroughly test to ensure correct expected values. In particular, beware of creating infinite loops, in which a calculated field depends on other calculated fields that ultimately depend on itself.

You can calculate the difference between two dates or times by using the function:

datediff([date1], [date2], "units", returnSignedValue)

date1 and date2 are variables in your project

units

• Both dates MUST be in the format specified in order to work.
• For comparing two Time HH:MM fields, the date format is irrelevant.

returnSignedValue

• The parameter returnSignedValue denotes the result to be signed or unsigned (absolute value), in which the default value is "false", which returns the absolute value of the difference. For example, if [date1] is larger than [date2], then the result will be negative if returnSignedValue is set to true. If returnSignedValue is not set or is set to false, then the result will ALWAYS be a positive number. If returnSignedValue is set to false or not set, then the order of the dates in the equation does not matter because the resulting value will always be positive (although the + sign is not displayed but implied).

Examples:

Can I base my datediff calculation on today or now?

Yes. You may substitute a date or datetime field in your datediff expression with "today" or "now".

For example, you can calculate elapsed months since screening date using:

datediff([screen_date],"today","M")

or the elapsed time since the start of a test in minutes using:

datediff([start_time],"now","m")

Note1: If using a date field along with "now", REDCap will assume midnight (00:00) for the time component for the date field.

Note2: It is strongly recommended that you do not use "today" or "now" in calc fields. This is because every time you access and save the form, the calculation will run and update the field value. So if you calculate the age as of today, then a year later you access the form to review or make updates, the elapsed time as of "today" will also be updated (+1 yr). Most users calculate time from another field (e.g. screening date, enrollment date).

Daylight Saving Time transition will not affect your calculations involving dates.

Yes, this is allowable in newer versions of REDCap. Fields that are either numeric (e.g. integer, slider) or non-numeric (e.g., drop-down, free-form text) will work successfully inside an IF statement for calculated fields.

If you add a calculated field where data already exist in a form, data must be re-saved for the calculation to be performed.

Use the Data Quality rule H to find and fix all incorrect values for calculated fields in a project.

Branching Logic may be employed when fields in the database need to be hidden during certain circumstances. For instance, it may be best to hide fields related to pregnancy if the subject in the database is male. If you wish to make a field visible ONLY when the values of other fields meet certain conditions (and keep it invisible otherwise), you may provide these conditions in the Branching Logic section in the Online Designer (shown by the double green arrow icon), or the Branching Logic column in the Data Dictionary.

For basic branching, you can simply drag and drop field names as needed in the Branching Logic dialog box in the Online Designer. If your branching logic is more complex, or if you are working in the Data Dictionary, you will create equations using the syntax described below.

In the equation you must use the project variable names surrounded by [ ] brackets. You may use mathematical operators (=,< ,>,<=,>=,<>), Boolean logic (and/or), and unary Boolean not (!). You may nest within many parenthetical levels for more complex logic. If the project is longitudinal, in certain contexts you may need to additionally provide the unique event name, which must also be in brackets and prepended to the variable name, in order to target that field on a particular event - e.g., [event_2_arm_1][variable_name].

You must ALWAYS put single or double quotes around the values in the equation UNLESS you are using > or < with numerical values.

The field for which you are constructing the Branching Logic will ONLY be displayed when its equation has been evaluated as TRUE. Please note that for items that are coded numerically, such as dropdowns and radio buttons, you will need to provide the coded numerical value in the equation (rather than the displayed text label). See the examples below.

Yes, for longitudinal projects (i.e. with multiple events defined), branching logic may utilize fields from other events (i.e. visits, time-points). The branching logic format is somewhat different from the normal format because the unique event name must be specified in the logic for the target event. The unique event name must be prepended (in square brackets) to the beginning of the variable name (in square brackets), i.e. [unique_event_name][variable_name]. Unique event names can be found listed on the project's Define My Event's page on the right-hand side of the events table, in which the unique name is automatically generated from the event name that you have defined.

For example, if the first event in the project is named "Enrollment", in which the unique event name for it is "enrollment_arm_1", then we can set up the branching logic utilizing the "weight" field from the Enrollment event: [enrollment_arm_1][weight]/[visit_weight] > 1. Thus, presuming that this field exists on a form that is utilized on multiple events, it will always perform the branching logic using the value of weight from the Enrollment event while using the value of visit_weight for the current event the user is on.

Yes, special formatting is needed for the branching logic syntax in 'checkbox' field types. For checkboxes, simply add the coded numerical value inside () parentheses after the variable name:

[variablename(code)]

To check the value of the checkboxes:

'1' = checked

'0' = unchecked

See the examples below, in which the 'race' field has two options coded as '2' (Asian) and '4' (Caucasian):

Yes, see the list of functions that can be used in logic for Report filtering, Survey Queue, Data Quality Module, and Automated Survey Invitations.

If a calculated field is hidden by branching logic but will evaluate to a number, it causes the web form to notify the data enterer about a hidden field with data in it. To avoid receiving the notification, use an "if...else" statement--if(X, ValueIfTrue, ValueIfFalse)-where the value if false is "".

The statement should be written so if the calculated field is hidden, it will evaluate to false and provide the empty response, meaning there will be no data in the field. This will prevent the notification.

Yes, see the list of functions that can be used in logic for Report filtering, Survey Queue, Data Quality Module, and Automated Survey Invitations.

You are encountering a limitation that stems from having a lot of fields especially multiple choice fields in your project. If a good number of your fields involve multiple choices then the number of choices that the Drag-N-Drop Logic Builder has to load into the pop-up is large. So having a lot of fields with several choices each can slow down the system. The performance is further affected because REDCap uses javascript (powered by the user's browser) to do the drag-n-drop and also to process the conversion of the advanced syntax to the drag-n-drop method (if you decide to switch methods within the pop-up).

The slower your computer and the slower your browser (Internet Explorer is the worst, especially versions 6 and 7), than the slower the drag-n-drop method will be. Chrome is much faster at handling Javascript than other browsers and is recommended. The only other option is to use the data dictionary for building your branching logic.

Action Tags are special terms that begin with the '@' sign that can be placed inside a field's Field Annotation. Each action tag has a corresponding action that is performed for the field when displayed on data entry forms and survey pages. Such actions may include hiding or disabling a given field (either on a survey, data entry form, or both).

There is a comprehensive list of all available action tags that you may use within the Online Designer "Edit Field" pop up box. You can use as many as you want for a single field, but if you do use more than one tag for a field, make sure to put a space or line break between them. Because the action tags are used as part of the Field Annotation, they are not displayed anywhere on the page. For example, if you put @HIDDEN-SURVEY in a field's Field Annotation text box, then the field will always stay hidden when viewed on a survey page, but the field will be visible when viewing the same instrument as a data entry form, which might be helpful if you want to hide specific fields from your survey participants so that they do not see them. There are many different use cases for each action tag.

Auto-fill Action Tags: Pre-fill a variable with a value

• @DEFAULT
• @LATITUDE
• @LONGITUDE
• @NOW
• @NOW-SERVER
• @NOW-UTC
• @SETVALUE
• @TODAY
• @TODAY-UTC
• @TODAY-UTC
• @USERNAME

Calculation Tags: Calculate the value for a field

• @CALCDATE
• @CALCTEXT
• @DOWNLOAD-COUNT
• @IF

Cosmetic Tags: Change the look and feel of a variable without impacting the data

• @INLINE
• @INLINE-PREVIEW
• @PASSWORDMASK
• @PLACEHOLDER
• @RANDOMORDER
• @RICHTEXT

Entry Limits Tags: Limit what can be entered in a variable

• @CHARLIMIT
• @FORCE-MINMAX
• @MAXCHECKED
• @MAXCHOICE
• @MAXCHOICE-SURVEY-COMPLETE
• @NOMISSING
• @NONEOFTHEABOVE
• @READONLY
• @READONLY-FORM
• @READONLY-SURVEY
• @WORDLIMIT

Obscuring Tags: Action tags that hide a variable or make it uneditable

• @HIDDEN
• @HIDDEN-FORM
• @HIDDEN-PDF
• @HIDDEN-SURVEY
• @HIDECHOICE
• @HIDEBUTTON
• @SHOWCHOICE

Mobile App Tags: Action tags that are only useful when using the mobile app

• @APPUSERNAME-APP
• @BARCODE-APP
• @HIDDEN-APP
• @READONLY-APP
• @SYNC-APP

Multi-Language Management: Action tags that are used with the MLM tool

• @LANGUAGE-CURRENT-FORM
• @LANGUAGE-CURRENT-SURVEY
• @LANGUAGE-FORCE
• @LANGUAGE-FORCE-FORM
• @LANGUAGE-FORCE-SURVEY
• @LANGUAGE-SET
• @LANGUAGE-SET-FORM
• @LANGUAGE-SET-SURVEY

No, the @DEFAULT tag will not populate if the field is hidden when the form loads.

Please note: If the action tag '@DEFAULT= ' is used on a branching logic hidden field, the action tag does fire on page load but it throws an
error message

No, the @DEFAULT action tag is incompatible with branching logic. REDCap will by populate any default value to @DEFAULT'ed fields at the point of render. If that field with that value should not appear due to upstream branching you will receive an error message.

No, you can't. You can manually enter data to import into those fields and import that data into them, but the file import process will not trigger the action tags to populate those fields with data.

Navigate to Project Setup > Online Designer > Click on a data collection instrument > Click Add or Edit a field. Within the pop-up box, there is the Action Tags / Field Annotation option and a link to learn more about Action Tags.

Repeating forms is the ability to use the same form multiple times in a project or an event, without having to define how many times you want to use it. You can use it a different number of times for each record in the project and add new instances of the form as you need them for each record.

For example, if you are collecting a list of medications, you could create a form that asks for one of the medications, and then add a new instance for each additional medication:

In longitudinal projects, you have the option of repeating individual forms inside an event or repeating the event as a whole. If you choose to repeat just a form in an event, you will have multiple instances of just the form(s) you want to repeat. If you choose to repeat the entire event, all the forms in the event will be offered again, and you will have the same number of instances of each of the forms in the event, in that record. You cannot repeat an instrument inside a repeated event.

To enable repeating forms in a non-longitudinal project, navigate to the Project Setup page and go down to the "Enable optional modules and customizations" box. Click "Enable" next to "Repeatable instruments." Inside the popup box, select which instruments in the project you want to repeat.

In a longitudinal project that has multiple events defined, you will still select "Enable" next to "Repeatable instruments and events." For each event, you will need to choose if you want the entire event to repeat, if you just want specific forms in the event to repeat, or if you don't want anything to repeat. If you select "Repeat entire event (repeat all instruments together)" all the instruments in that event will be checked. If you select "Repeat instruments (repeat independently of each other)," then you'll need to select which instruments you want to repeat in that event.

No. You can only compare the first instance of repeating forms with double data entry. From the Data Comparison Tool:

The Data Comparison Tool does not *fully* support the Repeating Instruments and Events feature, which appears to be enabled in this project. Data can be compared (and even merged if using Double Data Entry), but it will only allow comparison and merging of Instance #1 of a repeating instrument or repeating event. Thus all other repeating data will be ignored on this page. Also, all non-repeating data can still be compared and merged.

Repeating forms are not compatible with the scheduling module.

Repeating forms are not compatible with the REDCap Mobile App.

Yes, you can. First, you need to enable the form as repeating in the project in general on the Project Setup page. Then make sure the form is enabled as a survey and go into the Survey Settings. Under "Survey Termination Options" select "(Optional) Allow respondents to repeat the survey: Ask them to take the survey again upon completion, if they wish."

This will allow your participants to repeat the survey. You will be able to choose if you want them to see the option to repeat the survey before or after they click submit, and you will be able to customize what the text on the repeat button says.

There are limitations to using repeating forms in surveys. You cannot schedule surveys that are in repeated instruments or repeated events to go out on a regular basis. You need to compose the survey invitation for each instance manually using either the compose invitations in the participant list or the option to send a survey invitation in the survey instance itself. Additional, survey queues in repeating events only work on the first instance of the event.

You can check by looking at the instance number next to the record ID when you click "view" after running the rule. However, you cannot filter by individual instances.

When you export data that has repeating instances, there will be two new columns in the export: redcap_repeat_instrument (the instrument's name) and redcap_repeat_instance (the instance number). All data that is not in a repeating form will be on one line, and then each instance of a repeating field will receive its own line, similar to how the data exports in a longitudinal study:

The formatting will be the same if the project is longitudinal; it will just include the event information as well.

The completion status of a repeating instrument will have three small circles instead of just one. If the completion status of all the instruments is the same, the circles will be colored red (incomplete), yellow (unverified), or green (complete), just like with regular forms. If the completion status isn't the same for all instances, then the circles will be blue.

On the record homepage, you'll be able to see all the instances of a repeating form listed out with the completion status of each instance:

You can add information from repeating forms in reports. You will just add the field(s) you need the same way as you would any field in the project. When you view the report, the information from the instances will be on their own line, similar to how information displays for different events in a longitudinal project:

Yes, piping, branching logic, and calculations can be used with repeating forms.

If you only use the variable name, REDCap will assume that you are referring to the variable on your current instance.

To refer to the variable on a specific instance, you can append the instance number after the variable name. For example: [variable1][5] will reference the data in variable1 on instance five.

To refer to the variable on a relative instance, there are several smart variables. They all append after the variable name.

• [current-instance] refers to the current instance
• [previous-instance] refers to the instance immediately previous
• [next-instance] refers to the instance immediately after
• [first-instance] refers back to the very first instance
• [last-instance] refers back to the very last instance

For example, to reference the data in variable2 on the previous instance, you would use [variable2][previous-instance].

You can see more information about these smart variables by clicking on the green "Smart Variables" button on the Project Setup page or when building a data entry form in the Online Designer.

Click on "Modify" next to "Repeatable instruments" in the "Optional modules and customizations" box on the Project Setup page. There will be a text box next to each instrument's name; you can the custom names there. The most effective way to use this is to pipe in a key piece of information (such as the medication name) here. The custom name will then show up next to the completion status for the individual instances on the record home page.

If this is a longitudinal project and you are repeating the entire event, you cannot use custom naming for the repeating event.

Only REDCap administrators can enable repeating instruments for a project that is in production.

Be aware that adding repeating instruments can affect branching logic, calculations, piping, and survey set up.

You can import data into repeating forms by using the redcap_repeat_instrument and redcap_repeat_instance fields to direct it to the appropriate form and instance. However, several people have found when they import into repeating forms the import is incomplete. It is highly recommended you manually check that the data imported correctly and completely after importing data into repeating forms.

The import columns for repeating forms are: record_id,redcap_event_name,redcap_repeat_instrument,redcap_repeat_instance,redcap_data_access_group,[data]

Yes, you can. As long as you have the "Delete Record" user right, you will see a button at the bottom of the data entry form that says "Delete data for THIS FORM only." Clicking that button will delete the data in that instance only.

The instances in repeating forms are autonumbered. Therefore, if you have instances 1, 2, 3, and 4 and delete instance 2, the next time you add a new instance of that form it will be numbered as 5. It will not go back and fill in the gap in the numbering, and you cannot renumber instances. However, you delete instance 4 and then add a new instance, the new instance will also be 4. REDCap simply looks at the highest existing instance number and adds one.

You cannot combine filters from fields that are on repeating instruments with fields that are not. The information from repeating forms is stored on different rows than information on non-repeating forms, and so you can't filter on both at the same time.

For example, if you have a project where "State" is captured in a non-repeating instrument and "Medicine" is captured in a repeating instrument, you could filter on "State" or on "Medicine" individually. However, you could not filter on both "State" and "Medicine" at the same time, because it is not possible to have both in the same row of data.

You can refer to other variables in REDCap by referencing their variable names. (e.g. [dob]) This is commonly used in features like branching logic, calculations and piping. Smart variables are an extension of that functionality. Instead of referencing a single static variable, smart variables allow you to reference other variables in a dynamic way. (e.g. instead of referring to medication variable in a specific event like "[baseline_arm_1][rx1]", you can refer to it like [previous-event-name][rx1]. The meaning of that reference changes depending on the event you are in.) This allows you to build more elegant branching logic or calculations.

For a full overview of all types of smart variables, go to the project setup page of any project and click on the "Smart variables" button.

In smart variables, using the "name" version of the variable will pull the official REDCap name for the Data Access Group, record, event, or instance. This is what you will need to use if you are trying to pull information in a calculation or piping, just like you will need to use the variable name. "Label" refers to the designation you've given DAG/event/etc, such as "Hospital 1" or "First Visit." This is more useful when you are pulling information about the item itself, rather than trying to pull a specific data point from the item.

Smart variables can be used with the @DEFAULT action tag.

When using the Smart Variable [survey-queue-link] in a context where the current record does not yet exist (e.g., on the first page of a public survey), this Smart Variable will return a blank value since the record does not yet exist.

Smart variables can be used in piping the same way static variables can. You can use them to pipe information into field labels, survey invitations, or use them in conjunction with @DEFAULT. You will just need to include smart variable command in brackets either before the variable you are piping (such as when piping longitudinal items) or after (when piping from repeating forms). If you attempt to pipe information from the "previous" instance/event on the first form or the "next" instance/event on the last form, the result will either be blank or ______.

No. [previous-instance] and [next-instance] cannot be used to reference across events. [previous-instance] and [next-instance] only reference an instance of a repeating instrument in the same (non-repeating) event or an event instance if the event is repeating.

In every REDCap project, you can find a link to more information about smart variables by clicking on the green “Smart Variables” button in the “Design your data collection instruments” box on the Project Setup page.

You can also go to https://redcap.vumc.org/redcap_v15.9.3/Design/smart_variable_explain.php to see the most up-to-date list of smart variables and information on using them. It's possible there may be variables on this list that aren't in use at your institution yet--if you have any questions, contact your REDCap administrator.

To capture the form creation time, create a text field with the action tag @NOW. This will capture the time the form is created. You can add the action tag @READONLY and/or @HIDDEN to prevent users from changing or seeing this field.

Form completion cannot be captured neatly, because it is much more difficult to determine what the completion criterion is. For different projects, it could be the first time the status field is saved as complete, the most recent update of the record, or something else.

Every Create - Update - Delete operation is captured in the database and is available to end users via Logging, and can be exported to CSV for analysis

To enter or view individual records, you can navigate to the "Data Collection" section on the left menu bar. Depending on your project type, you will see "Add or View Survey Responses", a listing of your form names, or a "Data Entry" icon. These options will navigate you to the drop down record lists so you can select or add a new record/response.

You can also use the "Data Exports, Reports and Stats" module under "Applications" to view your data. Create New Reports to search and view your project data in aggregate.

• When you click "View Report", it queries the database in real time and displays the resulting data in table format. Variables are listed in columns and individual records are displayed in rows.
• Clicking the "Stats & Charts" option within Data Exports, Reports and Stats module, displays graphical representations for all numerical and categorical variables and provides links for cleaning notable data (missing, highest, lowest values).

Existing records must be deleted by opening each one individually and deleting them. To do so, you must first have permission to delete records.

Go to the User Rights page. (This link is in the Applications section of the project menu.) Open your account, and scroll to the bottom of the screen. There, you'll find the permission to delete records. Select that option and save your account.

Then, open any record or survey response. You will find the delete options underneath the 'save' buttons at the bottom of the page. You can use the 'delete record' button to completely erase all data across all instruments for the given record.

NOTE for surveys: If the project uses surveys, you'll additionally need the 'Edit survey responses' permission. This separate permission is in the Data Entry Rights section of your account, in the upper right of the screen. On the survey response page, you'll first need to click the 'Edit survey response' button at the top of the record before the 'delete record' button will be enabled.

Yes. You can edit survey responses if you have permission to do so.

To edit a survey response:

1. Open the completed survey record.

2. Click the Edit Response button at the top of the page.

3. The survey will become editable. You can then make your changes and save.

Requirements:

• Your user account must have the Edit Survey Responses option selected in User Rights.

• You must have View & Edit access for that instrument.

• If you have only Read Only rights, you will not be able to edit.

Notes:

• The Delete right (added in REDCap 15.7) allows users to remove data from a form. Editing changes data; deleting removes it entirely.

• Some institutions disable the ability to edit survey responses. If the checkbox for Edit Survey Responses does not appear in User Rights, contact your REDCap Administrator.

• Editing survey responses does not change the survey's completion status automatically.

• Editing permissions may allow access to identifiable or sensitive data depending on the project setup.

The Double Data Entry (DDE) module that needs to be enabled by a REDCap administrator prior to any data is collected in the project. This module allows two project users or roles to be set as Data Entry Person 1 and Data Entry Person 2 (using User Rights page), and allows them to create records with the same name and enter data for the same record without seeing one another's data.

• Only one person or role at a time can be set as Data Entry Person 1 or 2.
• All other users are considered Reviewers.
• Reviewers have the ability to merge a record created by Data Entry Person 1 and 2 after viewing differences and adjudicating those differences using the Data Comparison Tool, thus creating a third record in the set.

It is sometimes recommended to use the Data Access Groups over the actual DDE module to implement a form of double data entry. The advantages of using DAGs include allowing an unlimited number of users to be in a group and enter data, to utilize the Data Import Tool, and to access all Applications pages. Discrepancies between double-entered records can be resolved by a "reviewer" (i.e. someone not in a group) using the Data Comparison Tool. However, two records can ONLY be merged together when using the DDE module. So if it is necessary for a third party "reviewer" to merge the two records into a third record, then in that case the DDE module would be advantageous over using DAGs.

When exporting records (or viewing a report) from a double data entry (DDE) project, the exported record set will, by default, include three records for every merged record (the first user's entry, the second user's entry, and the merged record).

To limit the exported (viewed) records to only the final merged version of each record, follow these steps:

1. Create a filter.

2. Switch to Advanced Logic:

3. Add this code: not_contain([record_id], "--")

Note, change [record_id] to whatever field you are using as the record identifier.

Data quality rules can be imported and exported using the "Upload or download Data Quality Rules" button on the top right of the Data Quality Rules header box.

It is not.

Technically, no. Data is not anonymous when collected using the Participant List; but it can be "coded" and "unidentifiable" to the project admins.

REDCap's user interface has two separate modules for (1) sending emails and tracking responders/non-responders [Participant List] and (2) viewing data/responses. Through the REDCap interface, there is no link between the modules and no connection between the email address entered and the responses collected unless you enter unique values into the "Participant Identifier (optional)" field. The Participant Identifier field links the email address to the survey responses.

To ensure confidentiality of the data, REDCap tracks responses by attributing it to an email address. If the Participant List > Participant Identifier field is not used, the project administrators are not privy to this information. Access to the association between the individual who took the survey and the survey responses is restricted in the database and can only be accessed by authorized privileged users(system engineers, database admins).

**Important to know: There is a link "behind the scenes" and REDCap / REDCap support personnel (system engineers, database admins) are really acting as an "Honest Broker": information is provided to investigators in such a manner that it would not be reasonably possible for the investigator or others to identify the corresponding patients-subjects directly or indirectly. REDCap holds the key to the code.

** If you truly need Anonymous Data, use the Public Survey Link.

For the Participant List, the identifying emails can be forever stripped from the data with no way for anyone to go back and find out the identity of the individual from whom the data the was obtained. No re-identification is possible if you do the following:

1. Export a copy of the REDCap dataset (so you have a copy of the data + date/time stamps if needed for future reference)
2. EXPORT LIST for the Participant List to excel
3. REMOVE ALL PARTICIPANTS from the Participant List. This will delete all links between the email addresses and data collected, INCLUDING survey date/time stamps. Date/time entered is still available in the Logging module.

This ensures that identities cannot be reversed engineered in REDCap.

**If data collection must be anonymous in "real time", then the Participant List should NOT be used. Use the Public Survey Link to collect anonymous survey data.

It is recommended that you keep access to the Survey Distribution Tools tool restricted since a small number of respondents would be easily identifiable from the Participant List and the Add / Edit Records pages.

Additional guidelines to help you collect unidentifiable coded survey data:

Multiple Surveys: Be mindful that projects with multiple surveys present potential challenges to anonymous data collection.

Only participants that answer the first survey will be able to respond to the follow-up surveys. If you wish to collect additional surveys for the non-responders, you will need to create additional REDCap projects with the follow-up surveys or you may have to open the survey using the link provided and save the survey without data (issue will be required fields).

LACK OF DATA MAY INADVERTENTLY IDENTIFY PARTICIPANTS: If you are using the Participant List to send 3 surveys, a scenario may arise in which a high number of subjects respond to the first 2 surveys and only 1 or 2 subjects respond to the last survey.

As you know, each exported record will contain a subject's response to all of the survey questions. In this scenario, you will need to be aware that the lack of data for the third survey can inadvertently identify a subject's identity and his/her responses to all prior surveys.

For this reason,

1. Do not EXPORT any of the project data until the survey in question is completed and closed.

2. Before exporting survey data:

• Review the number of responses (for each survey in the project) and make a judgment as to whether or not enough responses have been received to ensure that subject identities can remain unidentified. This is particularly critical when using the Participant List, as this list will identify the individuals who have responded. A low count of responses could be problematic. Take care to ONLY export and view data from surveys that have a suitable number of responses. For example, if only one response has been received (and the Participant List identifies that jsmith@yahoo.com< mailto:jsmith@yahoo.com> has responded), you will know that this single response belongs to that subject.
• Only export the data associated with a closed survey (both single and multi-survey projects). Once data has been exported, no further responses should be received or allowed.

Also note: Projects containing data entry forms and surveys cannot be considered anonymous. Manually entered data needs to be identified by the team to be properly associated and linked with survey responses.

REDCap provides a reCAPTCHA tool that can deter spam bot access to public surveys in REDCap version 8.11.0 and above

This feature allows users to utilize the Google reCAPTCHA functionality to help protect public surveys from abuse from "bots", which are automated software programs that might enter trash data into surveys. This feature must first be enabled by an administrator for the entire server. If your administrator has enabled it for use on your REDCap, you can choose to enable the Google reCAPTCHA functionality on the Public Survey page in your project. Once this is done, the public survey will display the reCAPTCHA checkbox and "I'm not a robot" text on a survey page prior to allowing the participant to view the public survey. This feature is not employed on any private survey links because those are unique to a record and thus would never be made publicly available like a public survey link would.

A survey participant will never have to pass the reCAPTCHA test more than once per day on a given device/computer.

There is a time limit of 24 hours per page. If a participant selects the "!Save&Return" option, their link is active until the project admin closes/de-activates the survey.

You should not use REDCap's Participant Email Contact list with group email addresses or distribution lists. The emailed invitations send only 1 uniquesurvey link per email address; therefore, only the first person in the distribution group who clicks on the email link will be able to complete the survey.

For group distribution lists, you can:

1. Email the general "public" survey link provided at the top of the "Invite Participants" page directly from your email account, or
2. Add each individual email address from the distribution list to the Participant Contact list. You can copy/paste the emails from a list (word or excel) into REDCap.

The advantages of using REDCap's Participant Contact list and the individual emails is that REDCap will track responders and non-responders.

You'll be able to email only non-responders if you want to send a reminder. With the general distribution email, you won't be able to track responses and participants will have the potential to complete the survey more than once.

On the Survey Invitation Log page, there is a checkbox for displaying the reminders. Check that box and then click the button to apply the filters. Then you can use the red x to delete the reminders.

There is no way to withdraw a sent survey link or deactivate a survey on the record level.

You could create field in the project, "Block" as a yes/no question, and apply branching logic to all questions in the survey to only display is [block]<> "1". If you need to prevent a participant from seeing the questions, you could then select "Yes" on the block question in their record. As long as this was done before they clicked on the link, they would not see the survey questions to answer.

If the survey is for an already-existing record and the record is deleted before the participant clicks on the survey link, the participant will receive the message "Thank you for your interest, but you are not a participant for this survey."

Yes, but it will only affect future invites. If you need to update the email field for already scheduled invites, you must delete the invites and reschedule.

Once a survey invitation is in the Survey Invitation Log, the only way to get rid of them through the UI is to click on the red X next to each one.

The easiest way to simply stop future surveys from going out is to add a new field call "Do not send further survey" in a "Control Center" form, and add that to the ASI condition and click "Ensure logic is still true before sending invitation?" in the Survey Invitation pop up box

This effectively depends on "Ensure logic is still true before sending invitation?" to get the ASI condition to be re-check (and evaluate to false) just before the survey invitation goes out. Whether changes in ASI and the checkbox will affect invitation already in the queue I don't know. Hence, please check before you use it in anger.

For for projects with multiple surveys, there will be one participant list per survey. You'll be able to select the survey specific to survey name and event (longitudinal projects).

Participant List may be used to:

1. Send emails to many participants at once
2. Send individual survey invites directly from a data entry form

The Public Survey Link and Participant List have been separated onto different pages within Survey Distribution Tools because they each represent a different method for inviting survey participants.

Note: To be able to add participants directly to the Participant Contact List, the first data collection instrument (DCI) must be enabled a survey. All participants of all surveys must be added to the first survey of the project. If the first DCI is not a survey, you can add an email address to the first DCI and use the feature "Designate an Email" which will auto-populate the Participant Contact List.

The most common methods to send out a survey are the Public Link and the Participant List. These methods are on the "Survey Distribution Tools" page, which is accessed through the project menu's Data Collection section.

Public Link: This is a single survey link for your project which all participants will click on. This link can be copy and pasted into the body of an email message in your own email client. It can also be posted to web pages. This is the most common method for large, anonymous surveys where you do not need to follow-up with survey respondents.

Participant List: This option allows you to send emails through REDCap and thereby track who responds to your survey. It is also possible to identify an individual's survey answers by providing an Identifier for each participant. This is the most common method when you need to know who has responded so far and who hasn't.

Designate an Email Field: You can capture email addresses for sending invitations to your survey participants by designating a field in your project. If a field is designated for that purpose, then any records in your project that have an email address captured for that particular field will have that email address show up as the participant's email address in the Participant List (unless an email address has already been entered for that participant in the Participant List directly).

Using the designated email address field can be especially valuable when your first data collection instrument is not enabled as a survey while one or more other instruments have been enabled as surveys. Since email addresses can only be entered into the Participant List directly for the first data collection instrument, the designated email field provides another opportunity to capture the email address of survey participants.

NOTE: If the participant's email address has already been captured directly in the Participant List, then that email address will supersede the value of the email field here when survey invitations are sent to the participant.

Compose Survey Invite: This option is available on the Participant List and on survey data entry pages for individual records. This allows you to create and send the actual survey invitations.

Yes, you can do this in the Survey Invitation Log. Navigate to the log to see all the pending survey invitations. You can select a batch individually by checking the boxes in the far right column, or you can select all by clicking the checkbox directly above that column. If you select all, you can individually deselect invitations as well. Once you have selected your batch, use the "Delete all selected" button.

No. You may have to delete scheduled invites and reschedule. And don't forget the reminders! They are not displayed by default.

Email addresses cannot be removed from the participant list after the survey is completed. However, they can be edited to a placeholder email address if you need to remove the potential identifier.

REDCap will only create public survey links for a single instrument.

In a single arm project, the public survey link will be created for the first instrument.

In a multiple-arm project, the public survey link will be created for the first instrument in the first arm, and for that same instrument in every other arm.

If you want to have the public survey link for different arms point to different instruments, one workaround is to make the first instrument be nothing but a descriptive field with instructions and then use auto-continue to reach the actual survey that you want to be first for each arm.

REDCap has the capability to make voice calls and send SMS text messages to survey respondents by using third-party web services. The two third-party companies that can be enabled to work with REDCap are Twilio (www.twilio.com) and Mosio (www.mosio.com). When these features are enabled on a REDCap project, you could invite a participant to take a survey by sending them a SMS message (Mosio and Twilio) or by calling them on their phone (Twilio only). There are many different options available for how you can invite participants and how they can take your surveys, either as a voice call survey or as an SMS conversation. 

The use of Twilio and Mosio are at the discretion of your institution and may require legal agreements between your institution and the third party vendor.  If you do not see the option to enable "Twilio SMS and Voice Call services for surveys and alerts" or the option to enable "Mosio SMS services for surveys and alerts" on the "Project Setup" page under the "Enable optional modules and customizations" section, contact your local REDCap Administrator for more information. 

For those not using either Twilio or Mosio, there are many providers that may let you convert an email into an SMS. You have to register your email address with them for billing, then you construct your messages using a particular pattern, e.g.

To: [recipient's mobile number]@provider.com
Body: The message text

This mechanism would work fine from within REDCap - even for automated invitations - although the built-in text containing the survey link may not be particularly nice in an SMS. Contact your REDCap Administrator who may be willing to adjust the language file.

Yes, this is possible. To disable the survey functionality for an instrument enabled as a survey, go to the Online Designer --> Survey Settings for that instrument --> Scroll to the bottom for "Delete Survey Settings."

This will NOT delete any responses collected through the survey, and it will NOT delete the data collection instrument. The instrument will revert back to how it was before it was enabled as a survey, in which data can only be collected by authenticated users on the data entry form.

All participants will be removed from your Participant Lists associated with this survey, and all survey links and return codes will cease to function for this survey. Any email invitations that have been scheduled to be sent for this survey will be deleted. Additionally, all survey responses will have their 'survey completion' timestamp removed, as seen in a data export file or on the data entry form. If you choose to delete the survey, you may enable the data collection instrument as a survey again, but you will still lose all the survey-related information mentioned thus far.

The version simply called "MyCap" (purple logo) is a new version of MyCap was released in September of 2023 as a full app re-write in the cross-platform Flutter framework. This new version offers many new functionalities including:

• Longitudinal project support
• Parity in active tasks for Android and iOS
• Support of rich text in REDCap field labels
• Ability to embed hyperlinks within field labels
• Participant dashboard of overdue, future, and completed tasks
• Support of image and video capture, as well as upload from device's gallery from iOS and Android
• Ability for participants to switch devices and retain their place in project after rejoining
• Supports multiple users on a single device
• View full list of new features here.

 Please note that the new MyCap App has a minimum version requirement of REDCap v13.10.0.

The version called "MyCap Classic" (black logo) is the original MyCap app that was replaced by the new MyCap app. It continues to be available for participants that were already using it and institutions still on older versions of REDCap.

MyCap is an application installed on a participant's mobile device so the participants can complete data collection instruments, surveys, and other tasks remotely and over a period of time. 

Alternatively, the REDCap Mobile App is primarily used when an internet connection is unavailable or unstable. The REDCap Mobile App requires a REDCap login and is typically downloaded to the study team's mobile device and taken to the participants - it is not downloaded to a participant's device. 

MyCap is a standard feature of REDCap v13.0+. Data is collected from participants through the app via customizable surveys and the automated administration of active tasks (activities performed by participants using mobile device sensors). All data collected in the MyCap App is automatically sent back to the REDCap server as soon as internet connection is available (i.e., it can also be used for offline participant data collection). Frequent data collection is strongly encouraged for MyCap usage.

MyCap also facilitates participant engagement and retention by providing quick access to project staff and secure two-way communication (e.g., messaging and announcements) within the App. 

For more information about MyCap, check out the MyCap website, publication, resources, videos, and a list of MyCap use cases. 

A tool for researchers - a customizable participant-facing mobile application freely available to capture patient reported outcomes based on a REDCap project.

A tool for participants - a centralized study 'home' (app) for information and actions that facilitates continuous participant engagement and participant retention. It is available on iOS devices (iOS v11.0+) and Android (v5.0+) at no-cost.

The MyCap AppMyCap App uses Firebase Analytics, Crashlytics, and Cloud Messaging. Firebase generates its own identifiers that live on the participant's device. There is no way for Vanderbilt to link a MyCap participant code to a Firebase user identifier. Participant meta-data stored in Firebase cannot be linked to participants in your project. 

Messages sent to and from a participant are transmitted via the MyCap API, not Cloud Messaging. Cloud Messaging simply handles push notifications and the push notification message is always "You have a secure message waiting." 

• Participant data is stored locally on the device in an AES-256+SHA2 encrypted database. Data remains on the device if an internet connection is not available. Applies to both iOS and Android devices. 
• When an internet connection is available, data is transmitted directly to REDCap using a SSL (TLS v1.2) connection. A hash-based message authentication code (HMAC) is used to verify the integrity of the data and to authenticate the sender. 
• Participant entered data (i.e. task responses) are not stored or sent anywhere else. Data exists on the participant's device or on your server. 
• Data is wiped from the device after the MyCap app verifies that data has been successfully transmitted. Note that there is an optional MyCap feature that lets a participant see some of the data s/he has entered for an individual task/instrument/survey. By default, data is wiped. 
• Participants create a 6-digit PIN that is used to open the App. A participant can disable the PIN feature.

Also see security and architecture overviews below.

Security PDFDownload 

Architecture PDFDownload 

Yes. For fully remote trials, use Dynamic Links for onboarding participants as everything can be done from a single mobile device. You can review the table on Participant Onboarding Procedures in the question "How do I decide whether to onboard participants via Dynamic Links or QR Codes?"

Yes. MyCap provides text and/or HMTL that can be used to automatically trigger the dissemination of the Dynamic Link and/or QR Code for participants. After copying the text/HTML, it can be inserted as (a) Survey Completion Text that is displayed after a survey is completed or (2) REDCap Alerts and Notifications that are automatically triggered once logic is met (e.g., a record is created or saved).  

• In REDCap, the text is provided under MyCap Participant Management > Participant List > Invite Participants.  This is the method you use if you see MyCap as one of the options in the first box on the Project Setup page.
• In the MyCap External Module, first set the trigger for when the QR code or Dynamic Link should be generated under MyCap External Module > Configure App > Setup. Once that is set, locate the HTML to use in Survey Completion Text and /or Alerts and Notifications under MyCap External Module > Participants > Participant Access Information. Check out our Getting Started Quick Guide for instructions on setting up the automated emails. 

Participant must scan the QR Code using the MyCap App, not their device's camera. After scanning the QR Code, the MyCap App immediately takes the participant through several setup screens, including the project's About Screen(s).  

The QR code contains three data elements: the participant ID, REDCap project ID, and an institution ID. Researcher teams can view each participant's unique QR code in their MyCap online interface on each Participant's Profile. 

Dynamic Links can be sent to participants via email, such as REDCap's Alerts & Notifications or text, if using a third-party service like Twilio (see ** under table above), or a Dynamic Link can be set to appear in the "Survey Completion Text" after a REDCap survey is completed. 

MyCap leverages Google's Firebase Dynamic Links that allow participants to click on a URL to join a MyCap project, even if they do not yet have MyCap installed. This allows participants to join projects without requiring the use of QR Codes and helps decrease accessibility barriers to MyCap.  

* Enter HTML provided into Survey Settings > Survey Completion Text 

** REDCap has the capability to send SMS text messages for Alerts & Notifications by using a third-party web service named Twilio (www.twillio.com) or Mosio (www.mosio.com). To use this feature, you must have a paid Twilio/Mosio account as there is a cost for each phone call made and for each SMS message sent. Not all institutions all the user of Twilio and/or Mosio--reach out to your REDCap administrator with any questions on these services

The Dynamic Links and QR Codes contain three data elements: the participant ID, REDCap project ID, and an institution ID. Researcher teams can view each participant's unique QR Code in their MyCap online interface on each Participant's Profile. 

Each participant using MyCap must have a record ID in the REDCap project before they can join the project in their MyCap App. After the participant's record is created, participant's access can be granted via a unique QR Code or Dynamic Link (i.e., hyperlink). Participant records can be created by having the participant complete an intake survey (recommended). Alternatively, research teams can add (or import) participants directly in REDCap or directly into MyCap.  

MyCap supports active tasks in seven distinct categories. This includes activities related to motor skills, fitness, cognition, speech, hearing, hand dexterity, and vision. Please note that unlike the MyCap App released in September of 2023 (purple logo), MyCap Classic does not offer parity in Active Tasks. Click here to view which tasks are available in iOS versus Android.

Yes, participants can send messages via their MyCap App (both MyCap and MyCap Classic) to the REDCap users on a project. REDCap users are NOT currently notified when a participant sends a message. 

• In REDCap 13.0+, REDCap admins and users with "MyCap Participant Management" rights can view messages from any participant/record. When a message is received, a badge displays beside "MyCap Participant Management" to indicate if there are unread messages.
• From MyCap Participant Management --> Messages, REDCap users can view Messags received from participants. REDCap users can indicate whether the message has been reviewed by clicking the "Action Needed" toggle.

Yes, MyCap provides in-app messaging between REDCap users and participants. When messages are sent to a participant in the MyCap app released in September of 2023 (purple logo), they receive a push notification on their device that says, "New Message: Secure message is waiting for you" (assuming the participant allows MyCap to deliver push notifications). When messages are sent to a participant in MyCap Classic, they receive a push notification on their device that says, "You have a secure message waiting" assuming the participant allows MyCap to deliver push notifications).The participant may read the message after opening the MyCap App. If the participant does not allow push notifications, he or she will still be able to read the message but will not see the notice indicating a new message is available. 

Additionally, project-wide Announcements can be used to send a message to all participants in a project. All announcements are visible to participants even if they join the project after the announcement is sent. The announcement date is included.

No. MyCap cannot yet send reminder notifications for incomplete tasks. MyCap currently sends notifications for tasks at 8 AM on the day the task is schedule to occur. However, the MyCap App released in September of 2023 (purple logo) displays "Overdue" tasks in a distinct tab.

There are two types of notifications for mobile apps, local notifications and push notifications. A local notification is scheduled by the device and will be seen when a participant is online or offline. A push notification is sent from a server to the device and can only be received when a participant is online. Push notifications sent when a participant is offline will be saved until the participant is online. 

MyCap uses local notifications for scheduling tasks. Participants will receive a local notification at 8AM with the message "You have an activity to complete today." Currently the 8AM notification time cannot be changed, but adding flexibility is very high on our list of priorities. 

MyCap uses push notification when a researcher sends an ad hoc message to a single participant or an announcement to all participants. These can be sent anytime but they cannot be scheduled to send at a scheduled time in the future. 

MyCap is a built in part of REDCap since REDCap version 13.0+. However, individual institutions can choose whether or not to enable MyCap on their systems. If you do not see MyCap on your system, you will need to reach out to your institution's REDCap administrator to learn more about the local policies and procedures regarding MyCap.

MyCap is compatible with iOS versions ≥ 11.0 and Android versions ≥ 5.0.

Yes. MyCap can be enabled on all new or existing REDCap projects as long as you are operating on REDCap v13.0+. Additional configuration will be needed to enable Instruments for MyCap.

If you do not see the option to enable MyCap, reach out to your local REDCap administrator.

MyCap can be enabled on all new or existing REDCap projects as long as operating on REDCap v13.0+. Additional configuration will be needed to enable Instruments for MyCap.

If you do not see the option to use MyCap, reach out to your local REDCap administrator.

1. Set up your REDCap project.
2. Under Settings --> Project Setup press "Enable" next to, "Use the MyCap Participant-Facing Mobile App?". You may need to wait for administrator approval to enable MyCap. Once MyCap has been enabled on your project, you will see a "MyCap Participant Management" section in the left-hand menu in REDCap.
3. For guidance on how to configure your project for MyCap, you can access a detailed Help document from the Project Setup page by clicking on "Learn More about MyCap" or review brief instructions in the Design and Configure the MyCap App section under [View MyCap Initial Instructions].

If you do not see an option for MyCap, reach out to your local REDCap administrator.

Yes, MyCap Classic offers application-wide language rendering options for English, Spanish, Brazilian, Portuguese, and French. The MyCap App released in September 2023 (purple logo) does not have any language translations, but they will be available soon.

This is not available in MyCap Classic but is available on the new MyCap App. Field labels will appear as formatted using the RichText editor. 

Piping is not currently supported in MyCap.

MyCap is not compatible with REDCap's smart variables, piping,  special functions, and most action tags. MyCap does honor the @HIDDEN action tag and does have a number of unique action tags specific to MyCap. For example, the @MC-FIELD-FILE-IMAGECAPTURE action tag applied to a REDCap File Upload field would allow a participant to capture a photo using their device's camera. View the list of MyCap action tags in the REDCap action tag help text (if using REDCap 13.0 on a project) or from the MyCap Participant Management> Help > Annotations.

Yes, branching logic within a single instrument is supported. Single-statement ([foo] = 1) branching logic has always been supported. Complex branching logic ([foo] = 1 AND ([bar] > 2 OR [baz] = 'Hello')) is available since MyCap Android v1.5.1 and iOS v2.5.0. However, mathematical functions "([foo] > ROUND(2.5)" are not supported. Branching logic between instruments is not yet supported. 

The MyCap External Module, the original operational format of MyCap, was retired on June 30, 2023. This was done in light of the release of MyCap as a standard feature in REDCap in December of 2022. Utilizing MyCap as a feature of REDCap rather than as an External Module provides several advantages including:

• Streamlined features and a more intuitive setup process in a single interface
• Intuitive indicators in REDCap when participants send messages to project teams 
• Simplified processes for generating participants' QR codes/dynamic links 
• Embedded MyCap resources that help REDCap users configure their projects independently
• Functionality that honors Data Access Groups in MyCap messaging and participant lists
• Enhanced user rights that allow for limiting a user's ability to a) configure tasks and the app design and/or b) communicate with participants via MyCap messages and announcements

The External Module is still operational but no longer receives feature updates or bug fixes. Watch this video to learn how to migrate your project from the External Module to MyCap in REDCap. 

MyCap Classic (black logo) will be retired in August of 2024. Up until that point, the MyCap team will only provide app support in the form of major bug fixes (e.g., participants are unable to join a project or data is not syncing). After the app retires, however, they will not provide any support for the app. The app will remain on the Google Play and Apple App Stores and study teams can choose to continue using it, but must know that it will begin to depreciate overtime. Use of MyCap Classic after its retirement is therefore strongly discouraged. All projects are encouraged to migrate to the new MyCap App (purple logo) by August 2024.

All projects that will capture data after August 2024 should direct participants to use the new MyCap App instead of MyCap Classic. However, the app that your project points to depends on your institution's REDCap version and when the project was created:

• Projects enabling MyCap prior to September 2023 directs participants to the MyCap Classic App by default. Use this guide to transition your project and existing participants to the new MyCap App.
• If your institutional REDCap instance is 13.10 or greater:
  • • All studies created after September 2023 will automatically direct participants to join the new MyCap App (purple logo).
    • If your project was created prior to September 2023, you can transition your project and participants to the new app using this guide.

To delete a project first select your profile then swipe left on the project you want to delete from the list. Projects can only be deleted before a project has been selected, while you are on the screen right after entering your PIN.

Yes, those with user rights to the File Repository may use the "Create folder" button to create additional folders. The table headers are clickable and will adjust the sorted order (e.g., clicking "Name" will sort folder/file names alphabetically). To navigate to a folder, select the name of the folder. To navigate back, select "All Files". 

Basic Privileges

Expiration Date: Automatically terminates project access for the user on the date selected. If left blank, no expiration will be enforced on the user account.

Highest-Level Privileges

Project Design and Setup:
Grants the user access to the Project Setup page, allowing them to create, modify, and delete instruments as well as adjust project-level settings, features, and modules.
This right should be allocated only to trained study members and limited to very few users per study.
At least one team member per study should hold this right.

User Rights:
Grants the user access to change the rights and privileges of all users on a particular project, including themselves. Also allows users to add new users to the project.

WARNING: Granting User Rights privileges gives the user the ability to control other users' project access. This user should be very trusted and knowledgeable about both the project and REDCap. Giving User Rights to team members should be a carefully considered decision. Poor assignment of rights can harm both security and data integrity.
For instance, giving record-deletion or project-design rights to an unqualified person could result in data loss or broken workflows.

Potential to access PHI: YES - User can change their own User Rights and grant access to any module where PHI can be viewed or downloaded.

Data Access Groups (DAGs):
Grants user access to create and add users to DAGs. DAGs allow multi-site studies to maintain data separation (e.g., Group A cannot view, export, or edit Group B's data). Users may belong to multiple DAGs simultaneously.

WARNING: Assigning yourself to a DAG will immediately restrict your own access to other DAGs. Users who manage DAGs should not assign themselves to one, as they must see all data to maintain proper oversight.

Other Privileges

Manage MyCap Participants:
Grants access to the MyCap Participant Management page, including the ability to invite or add participants, send and view messages, and manage other MyCap-related features.
NOTE: This user right appears only if MyCap is enabled. MyCap may not be available at all institutions.
Potential to access PHI: YES - Messages with participants may contain PHI.

Survey Distribution Tools:
Grants access to manage public survey URLs, participant contact lists, and the survey invitation log.
NOTE: Appears only if surveys are enabled.
Potential to access PHI: YES - Email addresses and phone numbers may appear in contact lists and invitation logs.

Alerts & Notifications:
Grants access to add and edit alerts and to view the Notification Log of past and scheduled alerts.
Potential to access PHI: YES - Alert Logs may include PHI such as names, email addresses, or phone numbers.

Calendar:
Allows viewing and editing of project calendars and participant schedules.
Potential to access PHI: YES - PHI may appear in calendar notes and can be printed or downloaded.

Add/Edit/Organize Reports:
Allows building custom reports within the project.
NOTE: If a user lacks form-level access to an instrument referenced in the report, that instrument's fields will not appear.
Potential to access PHI: YES - Depending on Data Viewing Rights.

Stats & Charts:
Allows users to view real-time statistics on project data.
NOTE: Forms that the user cannot access will not appear.
Potential to access PHI: YES - Depending on Data Viewing Rights.

Data Import Tool:
Allows downloading and modifying import templates to upload data directly into the project, bypassing data-entry forms.
WARNING: This right enables bulk overwriting of existing data.
Potential to access PHI: YES - Imported files may contain PHI.

Data Comparison Tool:
Allows viewing two selected records side-by-side for comparison.
Potential to access PHI: YES - PHI may be visible and printable.
NOTE: All discrepancies for all fields in the project are displayed and can be downloaded. This tool is not linked to Data Viewing Rights or Data Export Rights.

Logging:
Grants access to the audit trail of all project activity (page views, edits, deletions, etc.).
Potential to access PHI: YES - All changes, including PHI, are listed in the Log and can be downloaded.

File Repository:
Allows uploading, viewing, and retrieving project files such as protocols, instructions, or announcements. It also stores exported data and syntax files.
WARNING: Users with restricted Data Export Rights cannot open saved identified exports but can still view sensitive uploaded content (e.g., photos or scanned documents).
Potential to access PHI: YES - Depending on Data Export Rights.

Randomization Privileges

Randomization Setup:
Allows defining the randomization model and uploading/downloading allocation tables.
NOTE: Appears only if Randomization is enabled.

Randomization Dashboard:
Allows viewing the status of randomization allocations (used/not used).
NOTE: Appears only if Randomization is enabled.
WARNING: Access to this page will reveal which records were assigned to each group and may cause unblinding.

Randomization - Randomize:
Allows performing randomization for records.
NOTE: Appears only if Randomization is enabled.
WARNING: This right permits viewing or editing of stratification fields even if the user lacks form-level access to them.
Potential to access PHI: YES - If PHI (e.g., location) is used in stratification, the user may see it regardless of form-level rights.

Data Quality Privileges

Create and Edit Rules:
Allows creation or editing of custom data-quality rules.

Execute Rules:
Allows running data-quality rules-either the default rules or saved custom ones.
NOTE: If the user lacks access to instruments referenced in a rule, results will not be displayed.
Potential to access PHI: YES - Depending on Data Viewing Rights.

API Privileges

API Export:
Allows extraction of data using the API interface.
NOTE: Data Export Rights still apply.

API Import/Update:
Allows creating or modifying data using the API.
NOTE: Data Viewing Rights still apply to all modified data.

REDCap Mobile App Privileges

Collect Data Offline in the Mobile App:
Allows users to initialize a project and collect data on a device while offline.
NOTE: Appears only if the Mobile App is enabled. The app enforces password protection.

Download Data for All Records to the App:
Allows users to download existing data from REDCap to a device.
NOTE: Data Viewing Rights still apply. Appears only if the Mobile App is enabled.
Potential to access PHI: YES - Users may view PHI on a mobile device depending on Data Viewing Rights.

Settings Pertaining to Project Records

Create Records:
Allows adding new records and entering data.

Rename Records:
Allows changing the Record ID field.
WARNING: Should be granted only to trained staff. Renaming records can disrupt data integrity.

Delete Records:
Allows permanently deleting an entire record (all forms, events, and repeating instances).
WARNING: Records deleted at this level cannot be restored. Should be granted only to trained staff.
Potential to access PHI: YES - Deleted content may include PHI. All deletions are permanently logged.

Form-Level Delete Rights (New in v15.7.0):
Allows deletion of data on specific instruments only-without deleting entire records or events.

• Appears under Data Viewing Rights in the User Rights dialog.

• Can be granted per instrument.

• Requires "View & Edit" privileges for that instrument.

• If the instrument is enabled as a survey, "Edit Survey Responses" must also be granted.

• Users with "Delete Records" automatically have this right for all instruments.

Purpose: Provides finer-grained control over deletion privileges.
NOTE: This option may not appear at all institutions depending on configuration or REDCap version.
Potential to access PHI: YES - Form deletions may include PHI. All deletions are logged.

Settings Pertaining to Record Locking and E-Signatures

Record Locking Customization:
Allows access to "Customize & Manage Locking/E-Signatures."
NOTE: Applicable only to users who already have Lock/Unlock rights. This is often used in regulatory projects to define the "meaning" of a lock or e-signature.

Lock/Unlock Records (Instrument Level):
Allows locking and unlocking of individual instruments.

• Disabled: User cannot lock/unlock.

• Locking/Unlocking: User may lock/unlock.

• Locking/Unlocking with E-Signature Authority: User may lock/unlock and apply e-signatures.

Lock/Unlock Entire Records (Record Level):
Allows locking or unlocking an entire record from editing.
Users without this right cannot edit any form within a locked record.

Privileges for Viewing and Exporting Data

Data Viewing Rights:
Controls per-instrument access to view, edit, or delete data.
Options include four core levels plus the optional Delete checkbox:

• No Access: Instrument and data hidden.

• Read Only: User may view but cannot edit or delete.

• View & Edit: User may view and edit data. Required for Delete rights.

• Edit Survey Responses: User may edit completed survey responses.

• Delete (Form-Level): User may delete data for this instrument only (if granted).

WARNING: Data Viewing Rights affect only in-application access. They have NO effect on exported or downloaded data.
Potential to access PHI: YES - If a form containing PHI is visible at Read Only, View & Edit, or Delete levels, PHI can be viewed.

Data Export Rights:
Control data exports on an instrument-by-instrument basis.
Levels include:

• No Access: Cannot export any data or identifiers.

• De-identified: Exports with date shifting and removal of non-validated text fields.

• Remove All Tagged Identifier Fields: Removes only fields tagged as identifiers (does not date shift).

• Full Data Set: Exports all data, including identifiers and free-text fields.

WARNING: "De-identified" and "Remove All Tagged Identifier Fields" depend on correct identifier tagging.
Mark all PHI fields as identifiers and restrict export access whenever possible.

NOTE: Once data is downloaded, the user is responsible for securing it per institutional policies (e.g., HIPAA).
Potential to access PHI: YES - PHI can be exported and downloaded. Export Rights are not linked to Data Viewing Rights.

Yes. REDCap uses the metadata you have defined in your data dictionary to create syntax files for SPSS, SAS, R, and Stata. The Data Export tool includes instructions for linking the exported syntax and data files. Note that SPSS has several variable naming conventions:

• The name MUST begin with a letter. The remaining characters may be any later, digit, a period or the symbols #, @, _, or $
• Variable names cannot end with a period
• The length of the name cannot exceed 64 bytes (64 characters)
• Spaces and special characters other than the symbols above cannot be used
• No duplicate names are acceptable; each character must be unique
• Reserved keywords cannot be used as variable names (ALL, AND, BY, EQ, GE, GT, LE, LT, NE, NOT, OR, TO, and WITH)

Go to the "Data Exports, Reports, and Stats" application and hit the "Create New Report" button.Then take the following actions

• Provide a proper name for the report
• Set the User Access
• Select which fields you want to include in your report
• Set up filters to select the appropriate records
• Set up the proper order for your report
• Hit "Save Report"

You will have successfully create a new report and saved it to the project.

To do this, you'll want to create a username field on any data forms you need to know about for the report. Use the action tags @USERNAME and @READONLY to capture the username of the first person saving data on the form, and then include your username field on the report.

If you need more detailed information about every user who may have entered data on the form, you will have to refer to the log and won't be able to pull it into a REDCap report.

Yes. You can choose who sees the report on their sidebar by selecting "All users" or "Custom user access". You can customize access based on individual users and data access groups. All users with "Add / Edit Reports" user rights will see all reports listed if they go to the "Data Exports, Reports, and Stats" page.

A project dashboard is essentially a single webpage you can design in your project. They are pages with dynamic content that can be added to a project. Each dashboard has a title and body, and user access can be set uniquely to each dashboard in a project. They can utilize special Smart Variables called Smart Functions, Smart Tables, and Smart Charts that can perform aggregate mathematical functions, display tables of descriptive statistics, and render various types of charts, respectively.

Users must have "Project Design" privileges in a project to create and edit dashboards themselves.

Access to each dashboard in a project is set individually. You can select to make it available to all users or customize user access, similar to reports. Some institutions may allow for public dashboards, where anyone with the link can visit the dashboard even if they are not logged into the REDCap project. The link is not discoverable-you cannot search for it and find it on Google. But anyone with the link can access the a public Dashboard. Contact your REDCap administrator for more information about your institution's policies.

Yes, you can. A dashboard is essentially a single webpage in your project. You can use it a space to outline procedures for team members, for taking and recording notes, or (for public dashboards) as a welcome page for participants with information about your study as a few examples.

The dashboard is best for displaying simple analyses. It is inside of REDCap, so it pulls information directly from the data without any exports/imports required, and it is standing page team members can view at any time.

More complex statistical analysis should be done outside of REDCap with a tool specifically designed for statistical analysis. You may also need to use an outside statistical tool if you need to share the analysis with people outside of REDCap.

You can find more information by clicking on the "Project Dashboards" link in your REDCap project under Applications on the sidebar, as long as you have "Project Design" rights in the project.

Vanderbilt has provided a write up on what Project Dashboards are at the top of the page, and on the top right there is an informational video showing you how to use Project Dashboards.

The Project Dashboard Wizard is a tool to help you build aggregate fields to display analyses on a Project Dashboard. You can find it on the "Edit Dashboard" page. It will have you choose a smart variable to create, tell it what field(s) to use, and set the filters to build the smart variable for you to copy and paste onto your Project Dashboard.

You need the "Project Design & Setup" right to see the ability to create and edit dashboards on the sidebar.

You will only see individual dashboards if the creator chose to give you access to them.

If you are logged in as a REDCap user, you will see all the items on the dashboard. If it is a public dashboard, aggregate variables will have to have a certain number of data points before they will display to prevent the identification of data. Contact your REDCap administrator to find out what your institution's policy is.

The minimum number of records that must have data in a variable will change by institution; contact your REDCap administrator to find your institution's policy.

REDCap can auto-number records during the data import process. To do this, set "Name the imported records automatically" to "Yes". You will also need to provide a placeholder value as the record ID in the import file. Each individual record will need a unique placeholder value for the import to be successful.

Form status can be imported into variables named form_name_complete. The data import template, available on the Data Import Tool page, will contain the appropriate form status variable name for your project forms. Form status is imported as dropdown field type coded as

0 Incomplete

1 Unverified

2 Complete

Data cannot be directly imported into calculated fields. If you are importing data to a field you have set up to calculate a value, follow these steps:

1. Temporarily change the field type to text
2. Import data
3. Change the field type back to a calculated field

Very large data files may time out in a data import. You can break them into multiple files to help prevent this.

REDCap also has a "background data import" feature for large files. This will import the data using an asynchronous background process that is better for large data files that may take longer to import. The background process will email you after the data has been fully imported. If there are any errors during the import process, you will be able to view all the errors with the option to re-download the data that failed to import, allowing you to fix the data and import it again.

To use the background data import, look for the "Choose an import option" in the green box on the Data Import page. Select the option "Import as a background process" from the dropdown menu.

As long as the REDCap server and the connection to the file storage server (if not the same as the REDCap server) uses SSL/TLS or another type of secure tunneling behind-the-firewall type method, then the transfers will be secure.

No. The log files will stay intact when a user is removed from the project or suspended. Even if the user is completed removed from the entire REDCap installation (which requires a REDCap Administrator), the log file will still reflect the actions performed by that user.

No, you can not lock an event. You can lock a record's form and you can lock all forms across all events (the entire record).

+ Add

- Subtract

* Multiply

/ Divide

The Data Quality module allows you to find discrepancies in your project data. You can create your own custom rules that REDCap will execute to determine if a specific data value is discrepant or not. Your custom rules can include mathematical operations and also advanced functions (listed below) to provide you with a great amount of power for validating your project data. You can also activate the real time execution of your custom rules to continually ensure the data integrity of your project.

Note: Although setting up a Data Quality custom rule may at times be very similar to constructing an equation for a calculated field, calc fields will ALWAYS have to result in a number, whereas the Data Quality custom rule must ALWAYS result with a TRUE or FALSE condition and NEVER a value.

Yes. You may use IF statements (i.e. IF/THEN/ELSE statements) by using the function if (CONDITION, value if condition is TRUE, value if condition is FALSE)

This construction is similar to IF statements in Microsoft Excel. Provide the condition first (e.g. [weight]=4), then give the resulting value if it is true, and lastly give the resulting value if the condition is false. For example:

if([weight] > 100, 44, 11) < [other_field]

In this example, if the value of the field 'weight' is greater than 100, then it will give a value of 44, but if 'weight' is less than or equal to 100, it will give 11 as the result.

IF statements may be used inside other IF statements ("nested"). For example, if you wanted to look for values above ten if the chosen color was blue, but look for values below 20 if any other color was chosen, you could use:

if([chosen_color] = "blue", if([given_value] > 10, 1, 0), if([given_value] < 20, 1, 0))

NOTE: The example above would not work in a calculation, because calculations can only use numbers, not a text string like "blue".

Other advanced functions (described above) may also be used inside IF statements.

No, they do not. Thus, an MDY-formatted date field can be used inside a datediff function with a YMD-formatted date field, and so on. (NOTE: Branching logic and calc fields do specifically require that the two values be in the same date format.)

To make changes after you have moved your project to Production, first download the current Data Dictionary so that you can revert to the current version, if necessary, if something goes wrong with making changes. Then, select "Enter Draft Mode" on the Online Designer or Data Dictionary page. After making your changes, you can review them by clicking on "view a detailed summary of all drafted changes" hyperlink at the top of the page.

REDCap will flag any changes that may negatively impact your data with the following critical warnings in red:

*Possible label mismatch

*Possible data loss

*Data WILL be lost

After making and reviewing changes, you can click "Submit Changes for Review." The REDCap Administrator will review your changes to make sure there is nothing that could negatively impact data you've already collected. If anything is questionable or flagged as critical, you may receive an email from the Administrator with this information to confirm that you really want to make the change.

Certain changes to the structure of the database, such as deleting events in a longitudinal project can only be done by the REDCap Administrator.

Altering a database that is in Production can cause data loss and challenges to your data analysis.

If a Production database must be modified, follow these rules to protect your data:

• Do not change existing variable names, or data stored for those variables will be lost. To restore data that has been lost in this way, revert to previous variable name(s).
• Do not change existing form names via a data dictionary upload, or form completeness data will be lost. Form names may be changed within the Online Designer without data loss.
• Do not modify the codes and response options for existing dropdown, radio, or checkbox variables; or existing data will be lost or confused.

It is acceptable to add choices to a dropdown, radio, or checkbox field; however adding an option or even an entire field may present other analytical challenges. For example, if a response option is added, it is added to all instruments for all records. For records and/or study participants who have already completed the instrument, that option was not present at the time and not available for selection. Their results may not accurately reflect their situation given the updated version of the instrument/survey. One must either consider their results in light of the instrument contents at the time of data capture or one must be careful to avoid making conclusions which would be affected by the change to the instrument.

Versioning your instruments and tracking changes over time is recommended. Use the Project Revision History to confirm changes and revisions.

Yes. Adding new choices has no data impact to data entered. New choices will be added and display on all records.

NOTE: Adding new response choices to a question does make it a slightly different question and, for that reason alone, could impact the integrity and analysis of your data. It is a new "version" of the question.

Modifying / recoding field choices does not change the data saved to the database, it only updates the labels. This will change the meaning of the data already entered and you will have to re-enter responses for those records to ensure accuracy. REDCap will flag this as:

*Possible label mismatch

The best thing to do when making field choice changes for radiobuttons, checkboxes or dropdowns is to leave the current response choices as is and start with the next available code. The coded choices do not have to be in order, so you can insert/list choices as you want them displayed.

For example, if your current codes are:

1, red | 2, yellow | 3, blue

and you want to add "green", "orange" and re-order alphabetically, DO NOT update to:

1, blue | 2, green | 3, orange | 4, red | 5, yellow

If you re-code like this, after the changes are committed any options selected for "1, red" will change to "1, blue"; "2, yellow" to "2, green"; "3, blue" to "3, orange".

That will completely change the meaning of the data entered. Instead you will want to update to:

3, blue | 4, green | 5, orange | 1, red | 2, yellow

REDCap offers optional AI features that may be enabled by your institution's administrators. These features vary by installation, so contact your local REDCap administrator to understand what specific AI capabilities are available at your organization.

The most efficient and effective way to use a language other than English in your REDCap project, either as the entirety of the project or as one of multiple options, is the Multi-Language Management feature. The link to Multi-Language Management is located under applications on the left hand menu of your project. This feature does not translate text for you, but it does provide the ability to utilize multiple languages within the same project and allows the user or participant to customize the language they view your project or survey in. You can provide translations for both the field labels in your project and the static text that is part of the interface. You may program any number of languages as long as you provide the translations to your REDCap project. The language can be customized in surveys, data entry forms, alerts, and survey invitations using this method. If a translation is not provided REDCap will fall back on the default or base language of what the data dictionary has available.

If you want your project to be in a single, non-English language, there is also the option of simply creating your label text in your preferred language. The static instructional text in REDCap in a different language may be supported in REDCap at your local institution using an .ini file that is loaded onto the REDCap instance. If you wish to utilize the Language Modules, contact your local REDCap Administrator about which languages are available. They can switch a REDCap project over so that it will display the new language text instead of the default language of the REDCap instance. The translations in the .ini may not be complete

Multi-Language Management (MLM) is a module that, when enabled, allows users to input multiple language translations and present the REDCap project interface (data entry pages, surveys, ASIs, Alerts and Notifications, PDFs, etc.) in different languages. The language is determined by the REDCap users and/or participants interacting with the page either at will by selecting a different available language or forced based on a language variable built into the project.

If you need to use the MLM for your project and you have project design rights but do not see Multi-Language Management in the left-hand menu, contact your REDCap administrator to request they enable it for your project.

The Multi-Language Management feature does not provide translation services or create language translations. Your institution or project will need to get all documents translated, then use the MLM module to input the translations for REDCap to reference. Multiple languages can be added into the same project with the MLM feature, all languages must have translations provided.

Multi-Language Management (MLM) supports many different languages!
A list of available languages can be viewed on the Multi-Language Management (MLM) Translations Repository here
Within the repository you will be able to download the ini language files for REDCap user interface translations that can be used with MLM.

What is MLM?! view that here

REDCap System Languages

• If you have questions about system languages, contact your REDCap administrator.

Uploading Language Translations to a REDCap Project

• Project-specific translations and user interface translations can be directly added to a project.
• Utilize the "from a file (JSON, CSV, or INI)" method. This can be done while adding a new language or after the language has been added to the project.

To Upload a Translation File to an Existing Language:

• Go to the "Languages" tab located under the MLM instructions in the horizontal tab menu.
• Click the "Update Language" icon (next to the "Pencil" icon) for the language you wish to update.
• Select the "by importing a file (JSON, CSV, or INI)" option.
• Choose and upload the desired translation file.
• Clearly indicate whether the file contains user interface or project-specific translations.
• Modify "Import options" according to your project's needs.
• Click "Update" to finalize the translation upload.

Note: Ensure that your translation file is correctly formatted and includes the appropriate language codes for successful integration with your REDCap project.

Hints for Proper File Formatting: Using the Export Language Feature

• To ensure correct formatting, export a language file using the "Export Language" option.
• Select items to include in the export and choose your preferred format (JSON and CSV available).
• In the exported file, add your translations in the "translation" object (JSON) or the corresponding row (CSV).
• Avoid modifying the "hash" object or row, as this is essential for identifying translation items.

There are three methods to add a language on a REDCap project.

1. Using Available System Languages:

   • If you have questions about system languages, contact your REDCap administrator. 

2. Importing from a File (JSON, CSV, or INI):

   • Import individual translation files in JSON, CSV, or INI formats.
   • These translations apply only to the specific project to which they're added.
   • They can include translations for both user interface items and project-specific items.

3. Creating a Language from Scratch:

   • Use this option if no translation files exist for your desired language.
   • Provide a unique Language ID and Language Display Name to create a new language entry.
   • This method adds the language to your project but does not include any translations.

Note: After adding a language using any of these methods, translations can be manually added or updated through the REDCap UI, or new translations can be imported from a file.

The default field type metadata translations such as yes/no and true/false answer choices is in a particular section of the MLM feature. To translate the default field type metadata:

• Navigate to the "Multi-Language Management" link located under "Applications" in the left-hand menu of your project. If you do not see Multi-Language Management in the list of applications, this could be due to permission issues. A user must have "Project Design and Setup" user rights to modify MLM settings. If you are still unable to see Multi-Language Management on the left-hand menu, the MLM feature may not be enabled at your institution. Contact your REDCap administrator with questions.
• Select the "User Interface" tab from the horizontal tab menu located under the MLM instructions.
• Select "Field Types" from the secondary tab list located further down the page.
• Select a language to translate from the list of already created languages for the project. The language selected will appear in a blue button on the page.
• Scroll down to translate the field type(s) desired.

No. When you make changes in the Multi-Language Management tool, the yellow "Save Changes" button will appear, and a yellow bar will appear on the left side of the screen. Your changes are not saved until you click the "Save Changes" button and the yellow bar goes away.

If you try to navigate away from the page with unsaved changes, a popup will alert you.

The base language is the language that matches the project language-the language used for user interface element and during project design.

The fallback language is used when a translation is not available in the language that should be displayed. For example, if your project has Spanish and French translations and Spanish is set as "Fallback," items will be displayed in Spanish if no French translation is provided. If both languages are missing translations, the base language will display.

You can set the base and fallback languages in the Multi-Language Management tool on the "Languages" tab, next to the language name and ID.

When a survey respondent accesses a survey that is using the MLM feature, they can select which language they want to be displayed in the survey. This choice is stored locally in the respondent's web browser as a cookie. If the respondent returns to a survey from the same REDCap installation, the cookie is used to set the language to the respondent's last chosen language (if it is available). 

If the respondent has cleared their browser cookies, or uses a different browser than the one storing the cookie, their language preference will not automatically be selected.

If the "__lang" parameter is included in the survey URL it will overwrite the preference stored in the respondent's cookie and will set the display language to the one specified in the URL parameter (assuming the parameter is set to a valid and active language id).

MLM does not currently work on the Mobile App. 

The Multi-Language Management tool does not work with MyCap.

First, you need to add your languages on the Languages tab in the MLM. Make sure all the languages you want to use are set to "Active" with the toggle switch.

On the Forms/Surveys tab, you will select your language at the top of the tab and then select which forms and surveys should be available in that language from the list. You need to do this for each of the languages in your project.

On the Alerts tab, you will select your language at the top of the tab and then choose if any alerts should be excluded from the list. You will also select which language source to use for each alert.

On the Misc and User Interface tabs you do not need to enable your languages. You just need to enter the translations for each language individually.

You can download the PDF on the Multi-Language Management page. Next to each language, there is a grey icon on the far right with a piece of paper and the word PDF. Click on that to download the instrument(s) in the appropriate language.

There are two action tags that track the language used for data entry:

@LANGUAGE-CURRENT-FORM tracks the language in data entry mode

@LANGUAGE-CURRENT-SURVEY tracks the language in survey mode

In surveys, you will need to use @LANGUAGE-CURRENT-SURVEY on each page of a paginated survey form. You can add @HIDDEN or the variations @HIDDEN-FORM or @HIDDEN-SURVEY to hide this tracking information during the data entry process.

If you collect data with these action tags, you can use it in reports to track languages used for data collection.

The first step in accessing the API for any project is to check if you have the appropriate user rights in the project in order to use the API.

Secondly, you will need to request an API token. This API token will be linked to your user ID and to that specific project & and your respective user rights for that project. Please note: you will need to request a different API token for each project.

You will need that API token in each API call, because REDCap uses that token to authenticate each API call.

While you wait for your API token to be approved, we recommend that you check out the API documentation page in your REDCap installation. The link to the API documentation page can be found in the API application in each project.

Once you have your API token, you can utilize another tool called the API playground to learn how to use the REDCap API.

The playground will allow you to "test drive" each API method and tweak the various options for each API method. You can run the method in your browser to see what type of response you'll get.

The API playground will also supply you with the code (including your API token & server URL) for that specific API method in the following languages:

• PHP
• Perl
• Python
• Ruby
• Java
• R
• cURL

You can copy and paste your chosen language code into your preferred scripting tool and run it there.
We recommend the R program for demo purposes: it's free, light weight and will run on both Windows and Mac environments.

Another nice tool to "test" the API from your local computer is POSTMAN - a Chrome add-in which allows you to test and save API queries from your local computer.

To set up a Data Entry Trigger, go to the Project Setup Pages. In the "Enable optional modules and customizations" box, click the "Additional Customizations" button and scroll down towards the bottom. It is label "Data Entry Trigger."

The REDCap Mobile App is an app that is installed on a tablet or mobile device so that data can be collected offline on that device. Data collected offline is later synced (i.e. uploaded) back to an online REDCap project.

Once a user is given 'REDCap Mobile App' privileges in a project, they can navigate to the Mobile App page on the left-hand menu and set up the project inside the app on their device. Once the project is set up on the device, the user can collect data (which is stored locally on the device). Users can later sync (i.e. upload) that data back to their project when they have a reliable internet connection.

The app is therefore most useful when data collection will be performed where there is unreliable or no internet service (e.g., no WiFi or cellular service).

Additional Documentation:

• Download iOS app: https://itunes.apple.com/us/app/redcap-mobile-app/id972760478
• Download Android app: https://play.google.com/store/apps/details?id=edu.vanderbilt.redcap
• About the REDCap Mobile App (PDF): https://projectredcap.org/wp-content/resources/about.pdf
• Security in the REDCap Mobile App (PDF): https://projectredcap.org/wp-content/resources/security.pdf

Yes, there are several great places to learn.

1. The about section in the app itself. https://projectredcap.org/wp-content/resources/about.pdf
2. The FAQ in the app itself.
3. The documentation which is stored somewhere in this AnswerHub. (Search for Mobile App documentation.) These are from partners in the consortium to help each other.
4. Trial and error. I find software is best learned, at least at the initial stages, by trying it out. Download a project onto the app and see what it does!

There are several factors to consider when designing a project which will use the REDCap Mobile App, including but not limited to:

• Who will install and initialize the REDCap App on the mobile devices
• Who will initialize the user account(s) and create and manage user tokens for the accounts
• Will each device be tied to a single user or will multiple users access a given device.
• What data (if any) can be downloaded to the device.
• Who is responsible for ensuring that the project metadata is kept up to date on the device
• Who is responsible for ensuring that project data is uploaded (downloaded) at appropriate intervals
• What PIN management techniques will be specified and used.

https://projectredcap.org/wp-content/resources/security.pdf

When the user has collected some data in the app and wishes to send the data back to the server, they will go to the "Send data to server" page in the app.

First, the metadata/data dictionary is checked for any project changes (e.g., deleted field names, modified labels, multiple choice options, etc.)

• If there are major changes, the user will be prompted that the upload will not proceed.
• If there are no changes or minor changes, the process will proceed.

Next, records are sent, one at a time.

• For new records:

If new record id's are needed, they are assigned values for auto-numbered projects.

• For existing records:

Modifications to existing records are adjudicated, one record at a time. They can be reassigned to a new record id or merged with an existing record.

There are three categories: overlooked values (values on the device are the same), device-only modifications (in yellow), and device-and-server-modified values (in pink/red). The user is allowed to inspect them at the record- and field-level, and then send to the server after review.

For instance, if the project uses record auto-numbering, and a record already exists on the server with the same record name, then it will let the user know that it will rename the record accordingly during the sync process in order to prevent any overwriting of the record already on the server.

If there are any possible issues that might arise when sending the data to the server, the app will prompt the user to make a decision before sending the data. There are many different scenarios that can occur in which a user might be prompted to make a decision, and the app is fully capable of providing the user with just the right amount of guidance so that they feel confident sending their data to the server with no issues.

Apple (iOS), Android, and (probably) coming soon, the Kindle Fire.

It is available via the Apple App Store, the Google Play store, and possibly a custom REDCap store.

You can find the release notes at: https://projectredcap.org/wp-content/resources/change-log.txt

1. Login as your usual app user, except add a 00 to the end of your PIN. This will make the 6-digit PIN 8 digits long.
2. Go to the page that has the error. Reproduce the error.
3. Tap "Send Diagnostic Info" at the bottom of the screen. This will send an email to the redcap app folks.
4. Send a plain-text, narrative description of your error to redcapapp@vumc.org. You can use the Report a Bug feature on the main menu to do this via the app, or you can use normal email if you want as well.

1. Get online.

2. Contact http://opensignal.com/

3. Download their app.

4. Next time you struggle, check out the maps in their app.

The Mobile App does not support the Randomization Module and will not display the "randomize" button on a project instrument. The Mobile App is used for "offline" data collection, so it cannot assume access to REDCap's 'online' server where the project's randomization table is stored and accessed in real-time to make assignments.

1. Go to the main menu on the app.
2. Tap Report a Bug.
3. Fill out the Bug Report.
4. Await a response within 1-2 business days.

Randomization is a process that assigns participants/subjects by chance (rather than choice) into specific groups, typically for clinical research and clinical trials. The REDCap randomization module uses stratification you set and randomization tables you create to determine which randomization group each record should belong to. It allows for manual or automatically triggered randomization and open or concealed (blinded) randomization.

REDCap does not design your randomization setup or randomization tables for you; it will only implement the plan you input. Consider partnering with a biostatistician to develop your randomization model.

No. Once you've entered your randomization model, REDCap will generate some template randomization tables for you to work with, but these are only templates and should not be used for randomization in a production project.

There are three user rights involved with randomization, and a user may have one, two, or all three. They can be granted in any combination.

Setup allows the user to see the Setup tab on the Randomization page and the Setup column on the Summary page. This user can define the randomization model and all of its parameters, as well as upload the custom allocation table(s). This user is usually a statistician or data analyst.

Dashboard allows the user to see the (Allocation) Dashboard tab on the Randomization page and the Dashboard column on the Summary page. The Dashboard shows the overall allocation progress and assignments for subjects that have been randomized. This user is usually the PI or project manager.

Randomize allows the user to view the randomization button on a data collection form or survey that contains the randomization field, allowing the user to perform the randomization. This user is usually a researcher or study coordinator.

Yes. You can stratify on any multiple choice field in the project, and you can stratify on up to 14 variables in one randomization model. For multi-site projects, you can use data access groups or a specific multiple choice field to stratify by site.

Yes, REDCap can do blinded randomizations. To do a blinded randomization, you will specify an unvalidated text field as your randomization field. This field will display an integer when the record is randomized. The key or crosswalk for defining this integer will be kept outside of the randomization module, such as a document in the file repository or with an honest broker.

Yes. In Step 4 of the randomization setup, you can choose from three randomization options:

Manual only, for users with Randomize permissions only: A user with randomize rights will need to go into each record and manually randomize the participant/subject. This is the default setting.

Trigger logic, for users with Randomize permissions only: The person setting up the randomization will create specific trigger logic for when randomization to occur. The record will randomize when a user with randomize permissions saves the record and the trigger logic is true. Randomization will only occur once-the record will not re-randomize when saved again.

Trigger logic, for all users (including survey respondents): The person setting up the randomization will create specific trigger logic for when randomization to occur. The record will randomize when ANYONE, including a survey respondent, saves the record and the trigger logic is true. While all randomization should be tested thoroughly before data collection begins, this method should be vetted with extra rigor.

Yes. There is currently no limit to the number of randomization models you can create in a project.

It is designed so that the randomization field is enabled for randomization on *only* one event for a record (that includes all arms). A work around (depending on your project's use case) could be:

Create one "arm" that is for pre-randomization. The arm could include the eligibility, demographics forms, etc. up to the form on which the participant should be randomized. After randomization, the participant can be added into one of the actual study arms.

You can add a record to multiple arms, but you can only schedule events in one arm. This design may be a limitation if you are using the scheduling module.

The short answer: No, calculated fields can not be used to stratify randomization. REDCap requires one or more multiple choice fields (drop downs & radio buttons, yes/no & true/false questions) for stratification.

However, a work-around would be to have a relevant multiple choice field underneath a calculated field and then manually fill out that field based on the value in the calculated field. You could then use the multiple choice field to stratify your randomization.

Your REDCap administrator has the ability to unrandomized a participant, but institutional policies on doing this may vary. Reach out to your administrator for more help.

Once a randomization model is saved, it cannot be edited, so test thoroughly before beginning data collection.

Once your project is in production status, the allocation tables will become locked and unmodifiable. They can be appended by a superuser but this will only add additional rows to the allocation table. It will not change any of the rows already in the table.

Yes, you can.

1. Make sure the project is in Production

2. Click on the instrument you want to share in any record

3. Look for the "Share Instrument in the Library" button at the top of the screen

4. Read the ENTIRE yellow text to make sure you understand what sharing your instrument in the library means

5. Read and accept the Shared Content Agreement

6. Complete the required fields. Provide a detailed enough description that someone completely unfamiliar with it would understand its purpose

6a. Information added to the 'Acknowledgement' section appears at the bottom of the instrument any time it is added to a project. This may or may not be desirable

6b. Terms of use for locally shared submissions are not encouraged. You may add them, but please understand that we have no way of enforcing any required actions

7. Choose the instrument's language and fill in your contact information

8. Choose if you want to share your instrument only within your organization or if you want to share it with any institution in the Consortium

9. An initial review will be done on your instrument and confirmation may or may not be required. A library administrator will either approve the submission or provide a reason for rejection

ERROR: Could not find XML document.

This likely occurred from an error communicating with the REDCap Shared Library server at https://redcap.vumc.org/consortium/library/

The import of the instrument from the REDCap Shared Library did not complete successfully.

Some institutions are not allowed to utilize the library, or there may be a connection issue. Check with your REDCap Administrator and IT staff to verify that the connection between your REDCap server and the Vanderbilt server is working. It could be purposely or accidently blocked by a firewall or problems with proxy settings in the REDCap Control Panel.

Guide for Simple and Complex Calculations in REDCap

A guide for using the Multi-Language Management tool in REDCap

Introduction to Action Tags

REDCap Syntax Guide

An interactive tutorial for exploring REDCap Field Types

A Guide for Randomization in REDCap