REDCap Frequently Asked Questions

Please consider submitting your idea for any new feature via the feature suggestion survey link, found in the Help & Information section of any project menu. Suggestions made there are ranked for feasibility and utility by the REDCap consortium software development team (www.projectredcap.org). That development team considers the input of users across all consortium partner sites worldwide. We of course cannot guarantee that all suggestions will result in changes or new features, but survey submissions do all feed into the consortium's exploration and development prioritization list. It's the best way to ensure your voice is heard!

Hyperlinks can be embedded in field labels, field notes, and a few other places by using HTML tags. For example, a field label might be:

Please click here to learn more about REDCap.

Here is this example field label as seen in the Online Designer, showing the HTML tags.

Replace the "http...org" part with your desired URL. Replace the word "here" with the text you want displayed in the field label. (In can be identical to the URL, but doesn't have to be.) And remember, this is just an example field label. The field type, variable name, etc. can be anything.

The part about href and 'target = blank' is the HTML tag that tells the browser to open this link in a new tab/window. That's usually recommended because otherwise, the user/survey respondent will be taken out of REDCap and the hyperlink's page will open in their same window (making it difficult for them to return to REDCap to resume data entry).

Here's what the Online Designer's subsequent field itself looks like:

REDCap is HIPAA compliant and can be used for a variety of operational projects across the medical center. But please keep in mind that it is not an EHR system. It is a multifunctional database and can help support your work. It is not designed specifically for patient care needs, however, and is not supported in the same way as Epic.

The UAMS AR-CRIS REDCap system (https://crisredcap.uams.edu/redcap/) is housed in an environment which is maintained in compliance with HIPAA. Please see the NOTE below for background about using individual features in compliance with 21 CFR Part 11.

If you are subject to 21 CFR Part 11, you may want to double-check with your sponsor or other oversight to confirm if 21 CFR Part 11 compliance is applicable to the potential REDCap component of your work. In many cases, FDA-type projects need 21 CFR Part 11 compliance only when the electronic data capture system is considered the SOURCE document. This is frequently not the case because the data originally exists elsewhere - e.g. on paper or in an electronic medical record. So you may find that a HIPAA-compliant environment is sufficient.

NOTE: Depending on the project design, data entry workflow, and users involved, a few individual REDCap features can be configured and used in compliance with 21 CFR Part 11, if that's how the users create and manage their project. Specific features which can be configured and used in compliance with 21 CFR Part 11 include the eConsent Framework for surveys, Record-level Locking Enhancement, and 'File Upload' field enhancement.

The Framework is found on the Online Designer (under any individual instrument's Survey Settings button there) while the other two features are accessible via the Project Setup tab's 'Additional customizations' button in the section 'Enable optional modules and customizations'. It's up to the individual user to explore those features and implement them in whatever way they determine is compliant for their own individual needs.

A public link is only possible when the first instrument is a survey. Only that survey can have a public link.

All later instruments are considered a continuation of the earlier one(s). Later surveys capture different data, but are completed by the same people. So the later instruments can only ever be distributed via Participant List.

If different respondents will complete the other surveys, then a separate project should probably be used for each group of respondents.

Surveys can be enabled at any time in development mode. (This feature gets locked down when moving to production. So please contact your instance administrator if your project needs to be moved back to development mode.)

Here are instructions for enabling surveys in your development project:

1) First, look on the Project Setup tab. In the Main Project Settings step at the top, find the button to enable surveys in the project. This feature must be enabled in order to use surveys. So click that 'Enable' button.

2) 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, ensure that your instrument is designated as a survey by clicking the 'Enable' button next to it.

3) Once you complete step two, you will be prompted to define some additional features of your survey instrument. Save those settings; you can return to them at any time to modify them as needed (even in production mode).

The Survey Distribution Tools link will appear in the Data Collection section of the menu ONLY after at least one instrument is enabled as a survey.

If you are more of a virtual learner and would like to watch a past seminar on CDIS click the video link here.

There are many study designs in which CDIS could prove beneficial. The link below is a general guide to help decide which technique works best for you.

CDM is a special feature that imports Epic clinical data into a totally new REDCap project, at the time the project is first created. The project creation includes setting up a 'fetch' request, which includes things like the list of Medical Record Numbers in your target dataset, data types and values, and the date range. CDM is most useful for retrospective research studies, where you want to pull an Epic dataset once and then rarely (or never) update it by pulling those values again later.

CDM differs from CDP in that the REDCap project is created AFTER the CDM feature is enabled on your user account. So you should submit your CDM request BEFORE creating your REDCap project.

CDP is a special feature that imports Epic clinical data into an existing REDCap project. To learn more, go to any project's Project Setup tab. Scroll to the 'Enable optional modules and customizations' section. Find the CDP line item, and click the question mark icon next to it to open the CDP help popup.

CDP is NOT required if you want to import Epic data into an existing REDCap project. That can always be done manually or via the Data Import Tool. CDP is an optional feature, most useful for REDCap projects requiring frequent updating of Epic data in many REDCap fields/records (e.g. prospective, ongoing research studies).

NOTE: CDP was formerly called DDP on FHIR (referencing the underlying FHIR technologies involved).

The University of Arkansas for Medical Sciences EPIC system is used for electronic health/medical records. CDIS refers to the two standard REDCap features which currently allow individual REDCap projects to interact with Epic. The two features are 1) the Clinical Data Pull (CDP) and 2) the Clinical Data Mart (CDM).

More information about these features can be found below, as well as in any project or REDCap User Guide. The User Guide contains a detailed comparison of the CDIS features, which may be useful if you aren't yet sure which feature best meets your needs.

CDIS involves advanced features which must be enabled by a REDCap administrator. Additionally, CDIS features can only be used for research or operational support. If using for research you must have an active and approved IRB protocol in place.

You can definitely move to production and still retain all existing data. Moving to production is not required, but it is STRONGLY RECOMMENDED. Production mode has additional protections against data loss.

When moving to production (via the last step on the Project Setup tab), you get a popup asking whether or not you want to delete all data. It looks like this:

Select whichever choice matches what you want to happen to your existing data.

We do strongly suggest exporting all data and the data dictionary before moving to production in this situation. That ensures you have the complete dataset backed up and ready to import into the project just in case you accidentally select the wrong option.

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 (it's on the left-most column of permissions). Select that, then save your account.

Next, use the project menu's Data Collection section to go to the Add/Edit Records page or Record Status Dashboard and select the record you want to delete. (HINT: If using the Dashboard, make sure you click the record ID in the very first column to make your selection. If you click any of the colored buttons instead, you'll be taken to that particular instrument instead of the Record Home Page.)

After selecting the record, you should see the Record Home Page screen, including the dropdown field to 'Choose action for record' in the upper left. It should look something like this:

In the 'Choose action for record' dropdown, select the delete option. That will completely erase all data across all instruments for the given record.

In development mode, the Other Functionality tab has a button to Erase all data. This is useful when you are iteratively testing your project and want to practice your data entry several times, starting with an empty project each time.

In production mode, records must be deleted individually. Because of this limitation, you may want to consider copying your project and using the copied version instead. That copied version would be in development mode and have no records/data. (It would also be totally separate to the original project, ensuring you still had the original data and could quickly reference it in the future.)

Statistical software might have trouble opening your export file for any number of reasons. Here are some steps to help you troubleshoot what is amiss.

1) The export instructions must be followed exactly. The separate files must be downloaded exactly where and how described. So first, re-download the file(s). Make sure ALL applicable files are saved locally (i.e. on your computer). Saving to the  browser's Downloads folder is sometimes problematic. So try saving to your Desktop or a USB drive instead. (NOTE: If you are using statistical software remotely, the files must usually be saved on the same computer/device as your software program. Meaning if you save files to a laptop at your home while using the statistical software remotely on your office computer, the files won't be accessible. They must be saved to your office computer for its statistical software program to open them.)

2) Close all open files and applications. You might see errors if you have the data file open in another format while trying to open in the statistical software. And some applications drain your computer's memory, bogging down the processing needed to open the file. So close everything that you don't need, and then follow the REDCap export page's instructions to open the file(s).

If you still have trouble, try these additional troubleshooting techniques.

1) Download a smaller export. Create a new report having only a subset of the data you want. Then download that smaller chunk and see if the data opens in the package. If so, incrementally export more and more fields to identify the point where it fails.

2) Remove unvalidated text and notes fields. If there are "!" or other special characters in text fields, it can throw off the columns when viewing it in a stats package. Double-check the dataset to see if that is interfering with the reading of the file.

We typically suggest removing all unvalidated text/notes fields from exports used in statistical packages because those data types are usually not useful for analysis and can clog the statistical package processing (including throwing off the column dividers). It is also possible that the variable names themselves are incompatible with your statistical package. For example, SPSS may not be able to process variable names which include negative values.

If the file still fails to open properly, here are some final suggestions.

1) The UAMS biostatistics department might be able to provide feedback based on their experiences with similar statistical packages. Check out their webpage: https://biostatistics.uams.edu/

2) Try a general web search. Most statistical packages have user forums. Those can be a valuable resource for troubleshooting.

3) If you've received a specific error message, send it to cris@uams.edu with the project title, statistical package name, and a detailed description of the issue. Our team has no access to or familiarity with any statistical packages. But we can certainly take a look at your error message and try to find someone in our department familiar with both REDCap and your statistical package.

NOTE: If your project uses the Data Missingness feature (found on the Project Setup tab, under Enable optional modules and customizations-Additional customizations): exported Missing Data Codes in CSV data might cause an error or otherwise not load correctly in statistical analysis packages. You might need to manually modify the syntax file before loading it into the stats package in order to allow your Missing Data Codes to be accepted for certain data types, such as date-validated text fields. (Alternatively, try exporting your data without the Missing Data Codes as that should allow the CSV to open properly with the default syntax file.)

When calculated fields are added or when their equations are edited AFTER data collection has begun, REDCap does NOT retroactively run and save those calculations. You must do that manually.

Until that's done, new calculations will be blank in reports/exports, and edited calculations may not have the correct values in reports/exports. (Warnings about this appear when making these sorts of equation changes in the Online Designer.)

Be mindful that calculations run when you open the record. So you might open records and see the calculations (i.e. the values in red font) as if they are truly there. But unless you save the record to write the value to the server, it isn't truly there and won't appear in the exports, reports, or stats page. Opening the form is misleading - it'll look like the data is there, but it really isn't saved yet. If you see a red vertical bar along the right-hand edge of the calculated field's text box, that indicates the calculated data is displayed but NOT yet saved.

You can either manually/individually open and save each record on the instrument having the new calculations to get the values saved OR use the Data Quality module's Rule H to find and fix them en masse. (Other, more technical approaches to fix the issue (e.g. importing into a calculated field) are described on the Help & FAQ tab of redcap.vumc.org.)

Running Rule H is generally the best approach, as that is usually faster and easier than manually saving each record. The Data Quality tool is in the project menu's Applications section, assuming you have high enough project permissions to use it.

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.

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.

To set up a PDF Snapshot trigger, follow these steps:

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.

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.

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.

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.

Version control is essential if your consent forms and/or their language could change over time as the study progresses. It allows you to track which study participants (e.g., REDCap records) signed which 'versions' of your consent form at any given time. REDCap automatically logs all version changes to maintain a complete audit trail for compliance purposes.

REDCap offers several options for managing version control, with the new e-Consent Framework and PDF Snapshot features providing the most efficient and compliant methods.

Using the e-Consent Framework and PDF Snapshot: The simplest and most compliant approach is to:

1. Enable e-Consent Framework: Navigate to the Online Designer, enable the e-Consent Framework for your consent instrument, and configure the necessary settings.
2. Upload Consent Forms: Use a descriptive field to upload the consent form PDF within the instrument.
3. Automatic Version Control: The e-Consent Framework supports version control by allowing you to manage and present new versions of consent forms while maintaining historical versions for audit purposes.
4. PDF Snapshots: The system will automatically generate and store a static, unalterable PDF copy of the completed consent form in the File Repository or specified fields, ensuring secure and organized storage.

Version Control Details:

• DAG and MLM Support: The e-Consent Framework supports version control for projects using Data Access Groups (DAGs) and the Multi-Language Module (MLM).
• Immediate Activation: New versions go live immediately upon creation. There is no draft mode for consent versions.
• No Reverting: Once a new version is live, you cannot revert to an old version, but you can view all versions in the version log.
• Version Log: The version log provides a record of all active and inactive versions, including associated DAGs and MLM languages.

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.

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:

1. 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.
2. 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.

The 'Signature' field type in REDCap is often considered equivalent to a 'wet signature' by many IRBs and regulatory bodies. Standard text box fields may also be used for signatures depending on the regulations governing your study. For example, in some protocols, typing in a name (using a regular text box) is considered legally binding in the state of Tennessee. Please contact your IRB to learn about their specific requirements for your protocol.

REDCap offers a "Signature" field type that allows the participant to sign their name electronically.

When in the Online Designer, if you add a new field, you'll be prompted to choose a field type. The 'Signature' field type is just over half-way down the list. This "Scribble Signature" field captures a handwritten signature using a mouse, stylus, or touchscreen. In many regulatory contexts, including under 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. However, always verify with your IRB or regulatory body to ensure compliance with specific laws and regulations governing your study.

Your Human Research Protections Program/IRB is the ultimate authority over what must be included on your e-consent. Please coordinate closely with your IRB to learn about what they require for your specific protocol.

We recommend exploring all the options in both REDCap and with your study oversight to determine which REDCap features are most applicable to your work. Your oversight/governing bodies have the final say in what they consider 'valid' - e.g. yes/no fields, typed vs. signed names. You can use REDCap's features to build your e-consent form however you (and they) wish.

Some general resources we recommend include:

• Vanderbilt Introduction to e-Consent Framework and PDF Snapshot Video: https://redcap.vumc.org/consortium/videoplayer.php?video=econsent01.mp4&title=e-Consent%20Framework%20and%20PDF%20Snapshots

Additionally, our REDCap system has some project templates related to consent which are accessible when creating a new project on the New Project tab of redcap.vumc.org. (These templates include the use of the new e-Consent Framework and PDF Snapshot features.)

For a comparison of changes in e-consent functionality please review the following presentation: e-Consent upgrade guide.pdf.

If a module is 'discoverable', it is considered officially released to our system by our REDCap team. Only discoverable modules are displayed by default in a project's External Modules page.

More than a hundred external modules have been created by developers at sites across the REDCap consortium, including by Vanderbilt's own Data Core. Some of those other modules exist on our system for use by a few specific groups - usually the Core customers who paid to have the module implemented in a particular way for their specific use-case. These other modules are 'undiscoverable' - meaning not officially released for system-wide usage.

Our REDCap team works closely with the Core to determine which of the numerous modules (both Core-built and from other sites) would be most beneficial to our system's users. In general, we will consider designating a module as discoverable only if we feel it will have broad usability across many different types of projects and for a majority of our system users. (Other eligibility criteria also exist, including the nature of the module, its security standards and user permissions, built-in documentation, and the authors.)

Modules can be enabled or disabled in any individual project by users having high enough User Rights permissions - specifically, Project Design/Setup permissions. Enabling is done on the project's External Modules page, which is found in the Applications section of the project menu.

Please be mindful of two important notes about enabling/disabling modules:

Please visit the External Modules page in any project to find the list of available modules. The page link is in the Applications section of the project menu, if your User Rights permissions are high enough to access it. (Specifically, you must have Project Design/Setup permissions.)

NOTE: The Email Alerts module was the basis of the official Alerts & Notifications (A&N) feature in REDCap. The A&N page is accessed via the project menu's Applications section; it works very much like the external module. Please explore whether A&N may be sufficient for your needs before enabling the Email Alerts module. While it's certainly possible to use both the A&N feature and the module in a single project, we generally recommend using one or the other - not both - to avoid potential confusion when sending emails and/or when troubleshooting issues.

External modules are custom features which REDCap users or administrators have developed for use in their particular projects. Modules are like software add-ons or extensions. They are individual 'packages' of software that work within REDCap but are not truly part of the official REDCap code.

External modules extend REDCap's current functionality. They are customizations or enhancements that change REDCap's existing behavior and appearance OR which create entirely new behavior or appearance.

External modules are not official parts of the REDCap software. They are not something that the REDCap consortium's software development team has created or controls. Modules are add-on packages that, in most cases, have been created by software developers at other REDCap consortium partner sites. They were developed to do something specific for someone else's project. These add-ons may do things that could be useful to other people, and that is why they have been made available to you as external modules.

No guarantee is available that a given module will actually work for your particular project. Modules are built on other REDCap systems and versions. Because they are not part of the official REDCap code, they are NOT necessarily designed to always work on every version of REDCap or in every possible project design. They also usually lack as much detailed instructional text and built-in prompts as official REDCap features. So expect a lot of trial-and-error to learn how they work and to configure them. Modules are provided as-is by their respective authors, for you to use at your own discretion.

If you experience any issues with an external module, we recommend contacting the author of that particular module. If you don't know who that is, your REDCap administrator can provide that information and/or contact the author on your behalf. But please note that the Vanderbilt REDCap team cannot provide as much detailed guidance or support for external modules as we can for standard, official REDCap features.

Bot - an autonomous software application programmed on the internet or another network that can interact with systems or users.

1. Eligibile individuals who take a study twice, presumably without malicious intent.
2. Eligibile individuals who take a study repeatedly to receive additional compensation.
3. Ineligible individuals who take a study once or repeatedly to profit from compensation.

1. Anti-Bot Solutions
   1. ReCAPTCHA
   2. Challenge questions
   3. Honeypot questions
   4. Study eligibility logic

   Anti-Human Solutions

   1. Include combinations of questions designed to identify inconsistencies
   2. Disclose consequences of submitting fraudulent data
   3. Use open ended questions when appropriate
   4. Offer small incentives
   5. Deliberate recruitment and distribution

   Statements such as "participants will not be compensated if suspected of providing fraudulent responses" or that "investigators can contact you by telephone or email to confirm your eligibility for the study" are also helpful in detering fraudulent activity.