A modern, secure software application for building and managing online clinical research databases and survey forms. REDCap has the required safeguards for research data security and privacy (compliant with HIPAA). The application allows users to create research databases and data entry web-based forms that link the data collected with existing statistical software tools. It is a replacement for Microsoft Excel spreadsheets and Access databases for study data, improving data security, online access and the quality of data collected.

If you are unfamiliar with REDCap, follow the instructions below to create your first project: (*UC Davis accounts above required for links below)

Completion of a REDCap Introductory Training course is a required step when requesting REDCap access. Training is available through the University of California Learning Center's Learning Management System (LMS), powered by SumTotal, using your UC Davis campus computing account (i.e. CAS/Kerberos). Once logged in, search the system using keyword: REDCap or follow the link below:

Start REDCap Training Course

An initial REDCap project is requested through UC Davis Health IT Service Hub (ServiceNow). A UC Davis Health AD/Citrix account is required for at least one project collaborator in the role of a REDCap database ‘project sponsor’ to complete this task.

Request REDCap Access

Detailed instructions:

After a Biomedical Informatics staff member has reviewed your initial REDCap Access Request, you will be contacted via email about the next procedural steps needed to complete your project level agreement form. Please prepare to supply the following:

 Note: Please do not submit the project level agreement form until you have been contacted via email by an informatics team member. A Principal Investigator signature will be required on the final project level agreement form.

Collaborate within your research team to build your database using REDCap and construct a data dictionary for your project. Here are some examples:

You may review your data dictionary with a biostatistician at the UC Davis Health Clinical and Translational Science Center (CTSC). Request database feedback from CTSC Biomedical Informatics staff by email using hs-redcap.support@ucdavis.edu.

When finalizing your database design please review these points before requesting your REDCap project be moved from the development mode (staging) to the 'live' production mode accessible through the REDCap URL:

  • Enter any number of test patients to the database while in development mode and ensure all fields work as intended.
  • Upload a data dictionary to your REDCap project.
  • Ensure that all documentation requested in Step 3 have been finalized and submitted.

After this, please contact Biomedical Informatics at hs-redcap.support@ucdavis.edu staff and let them know you are ready to ‘Go Live’ to production mode with your database.

The URL to launch the secure UC Davis Health instance of REDCap application is:

https://redcap.ucdmc.ucdavis.edu/redcap/

REDCap authorized users specified in Step 3 (roles and permissions spreadsheet) must use their UC Davis campus computing account (CAS/Kerberos) to log on.

Version 11.4.4

CHANGES IN THIS VERSION:

  • Improvement: New parameter "repeat_instance" was added to the API method "Export PDF file of Data Collection Instruments" to allow users to export a PDF of an instrument for a specific repeating instance of a repeating instrument/event. (Ticket #117182)
  • Change/improvement: When a survey participant partially completes a survey that has the Save & Return Later feature enabled, and an email is then sent to the participant to remind them to finish their survey later, instead of sending that email from the system-level "Email Address of REDCap Administrator" (as in previous versions), the "From" email address of the "Survey partially completed" email will be set to the sender's address from the most recent survey invitation received by the participant. This will create more consistency and will reduce confusion for participants when attempting to reply back to the email, as has been a problem in the past.

Version 11.4.0

CHANGES IN THIS VERSION:

  • New action tag: @IF- Allows various action tags to be set based on conditional logic provided inside an @IF() function - e.g., @IF(CONDITION, ACTION TAGS if condition is TRUE, ACTION TAGS if condition is FALSE). Simply provide a condition using normal logic syntax (similar to branching logic), and it will implement one set of action tags or another based on whether that condition is true or false. For example, you can have @IF([yes_no] = '1', @HIDDEN, @HIDE-CHOICE='3' @READ-ONLY), in which it will implement @HIDDEN if the 'yes_no' field's value is '1', otherwise, it will implement the two action tags @HIDE-CHOICE='3' and @READ-ONLY. If you wish not to output any action tags for a certain condition, set it with a pair of apostrophes/quotes as a placeholder - e.g., @IF([my_radio]='1', @READONLY, ''). You may have multiple instances of @IF for a single field. You may also have multiple nested instances of @IF() inside each other. Both field variables and Smart Variables may be used inside the @IF condition. The @IF action tag is also evaluated for a given field when downloading the PDF of an instrument/survey, in case there are any PDF-specific action tags used inside of @IF(). Note: The conditional logic will be evaluated only when the survey page or data entry form initially loads; thus the action tag conditions will not be evaluated in real time as data is entered on the page.
  • New feature: Protected Email Mode
    • Users can enable the Protected Email Mode on any project on the Project Setup via the Additional Customization dialog. This setting prevents identifying data (PHI/PII) from being sent in outgoing emails for alerts, survey invitations, and survey confirmation emails.
    • If enabled, either A) all alerts, survey invitations, and survey confirmation emails or B) those whose email body is attempting to pipe data from Identifier fields will be affected, in which it will not send the full email text to the recipient but will instead send a surrogate email containing a link that leads them to a secure REDCap page to view their original email. If someone is accessing an email in the Protected Email Mode for the first time (or for the first time in the past 30 days), it will send a security code to their inbox that will allow the recipient to view any protected emails for up to 30 days on that same device. The Protected Email Mode is similar to Microsoft Outlook's "sensitivity label" feature.
    • When enabled in a project, users may specify custom text/HTML to display at top of the sent email and web page where the original email is viewed. This will allow users to also display logos/images pertaining to their project or institution.
    • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
  • New feature: Email Logging page
    • This is a new project page that contains a search interface to allow users with User Rights privileges to search and view ALL outgoing emails for that project (also includes searching and viewing of SMS messages if using Twilio services).
    • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
    • “Re-send email” feature - When viewing an individual email after performing a search on the page, a “Re-send email” button will be displayed in the dialog to allow users to re-send the email. Note: If the original email contained email attachments, the attachments will not be included in the email that is re-sent.
    • Only users with User Rights privileges in the project may access the page, and additionally they must opt-in and agree to a disclaimer before being able to view the page. The following text will be presented to the user before accessing the page: “Before viewing and accessing this page, you must first agree that you understand the following important information and conditions. This page is only accessible by users having User Rights privileges in this project. The Email Logging feature allows users to search and view *all* outgoing emails related to this project, and this includes being able to view all aspects of any given email (i.e., the recipient(s), sender, subject, message body, attachment names). If you are using anonymous surveys in this project, keep in mind that viewing this page and the emails displayed therein might inadvertently cause anonymous survey responses to be identifiable/de-anonymized. Additionally, if the project is using Data Access Groups, you will be able to view the emails related to all DAGs in this project (and thus possibly any data piped into the body of those emails). If you understand and agree to these conditions, click the button below. Please note the act agreeing to this disclaimer will be documented on the project Logging page.”
  • Improvement: New "Banned IP Addresses'' pagein the Control Center allows administrators with "Manage User Accounts'' privileges to add or remove IP addresses to/from the blocklist of banned IP addresses for the REDCap installation. The IP addresses listed on that page are IPv4 or IPv6 addresses that have been blocked manually using that page or have been banned automatically via the Rate Limiter feature (enabled on the General Configuration page in the Control Center).
  • Improvement: When using the ''Reason for Change'' feature in a project, a new button is displayed underneath each "reason for change" textbox on the Data Import Tool summary page. Users can simply click the button to copy the text to all other "reason for change" textboxes on the page, thus saving lots of time of having to add text to each individually. This feature is the integration of Luke Steven’s “Copy Change Reason” external module, which will be automatically disabled at the system-level when upgrading to (or past) REDCap 11.4.0 to prevent any conflicts.
  • Improve: New data export option - Export blank values for gray instrument status
    • All instrument complete status fields having a gray icon can be exported either as a blank value or as "0"/”Incomplete”. In previous versions, they could only be exported as “0”. By default, they are now exported with a value of “0”, but this option can be changed via a drop-down option in the “Advanced data formatting options” section of the data export dialog.
    • When exporting the Project XML file with both metadata & data, the option to export gray instrument status as a blank value will be preselected by default, whereas in other data export contexts (e.g. My Reports & Exports page), the option to export them as “0” will be preselected by default.
    • The API method “Export Records” has a new optional parameter “exportBlankForGrayFormStatus” that can accept a boolean (true/false) with default value = false, and it functions the same as its equivalent data export option in the user interface.
    • Note: Exporting gray instrument statuses as blank values is recommended if the data will be re-imported into REDCap. For example, when users export a Project XML file for a project and then create a new project with it, all the gray instrument status icons will be preserved in the new project, whereas in previous versions they were all converted into red status icons.
  • Improvement: New option “Allow normal users to edit their primary email address on their Profile page” on the User Settings page in the Control Center. This setting will be enabled by default, but an admin can disable it if they wish to prevent any users from modifying their primary email address for their user account.
  • Improvement:The developer methods REDCap::getSurveyLink() and REDCap::getSurveyQueueLink() now have an optional parameter "project_id" that (when provided) allows one to call the method outside of that target project's context. If project_id is not explicitly provided, then the methods must still be called within their target project's context.
  • Minor security fix:A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way as user-defined text on the Project Setup page.
  • Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. (Ticket #115308)
  • Improvement/change: New LOINC codes were added for CDIS-related functionality.
  • Change: All CDIS-related features and functionality now utilize a centralized set of assets in the code, rather than each feature having only their own private set of assets. This change reduces the entire size of the REDCap code by half, thus saving lots of space on the REDCap web server.
  • Various updates and fixes for the External Module Framework, such as the following: PID parameter safety improvements, Documentation updates, Prevented unnecessary errors from the Portable UTF-8 library's auto-redirection, Increased the setting lock timeout, and Fixed a getSafePath() case with absolute paths.

 

Changelog LTS version 10.2

Improvements to Data Resolution Workflow Feature

  • When a user is opening a new data query and assigning the query to a user, there are new options to send a notification to the assigned user via email and/or REDCap Messenger to inform them about their query assignment.
  • Attachment files uploaded to an opened data query may now be deleted after the fact, if needed. Note: As a precaution, only REDCap administrators may delete such attachments.

For existing data queries, users may now be assigned to an opened query after the fact, and if the data query already has a user assigned to it, it may be reassigned to another user.

REDCap-Branded URL Shortener (https://redcap.link)

  • The “Get short survey link” and “Create custom survey link” buttons on a project’s Public Survey Link page now utilize the REDCap-branded URL Shortener (https://redcap.link) instead of BIT.LY and IS.GD, which are third-party websites utilized by previous versions. 

Project Life Cycle Changes

  • “Inactive” project status renames to “Analysis/Cleanup.”
  • Projects that are in "Analysis/Cleanup" status can now optionally have their project data set as "Locked/Read-only" or "Editable" (see the top of the Project Setup or Project Home page). This will give users more control to prevent data collection from happening while in this project status.
  • Mark a project as "Completed": If users are finished with a project and wish to make it completely inaccessible, they may mark the project as Completed. Doing so will take it offline and remove it from everyone's project list, after which it can only be seen again by clicking the Show Completed Projects link at the bottom of the My Projects page. Once marked as Completed, no one in the project (except for REDCap administrators) can access the project, and only administrators may undo the Completion and return it to an accessible state for all project users. Marking a project as Completed is typically only done when users are sure that no one needs to access the project anymore, and they want to ensure that the project and its data remain intact for a certain amount of time.

Surveys to Capture Custom Information During Project Status Transition 

  • On the User Settings page in the Control Center, four optional fields have been added to allow you to utilize public surveys to capture custom information from users when projects transition to a new status (i.e., move to Analysis/Cleanup status, mark as Completed). This allows administrators to create custom surveys to capture all the info they desire from users during these project transitions. The survey will be presented inside an iframe on the page. The user must complete the survey before completing the process on the page. You may use any or none of these fields.

 DAG Switcher  

  • Users assigned to Data Access Groups (DAGs) can optionally be assigned to multiple *potential* DAGs, in which they may be given the privilege of switching in and out of specific DAGs on their own whenever they wish.
  • When assigned to multiple DAGs, the user will see a blue banner at the top of every project page, which will present them with the option to switch to another DAG. NOTE: Users may not move themselves into another DAG unless someone with rights to this page has explicitly granted them privileges to be in multiple DAGs.
  • To assign a user to multiple DAGs, navigate to the Data Access Groups page in a project where you will see the DAG Switcher near the bottom of the page. Then follow the directions provided there. The DAG Switcher feature is optional and can be used in any project that has Data Access Groups.
  • NOTE: The DAG Switcher feature does not override a user's current DAG assignment, as set on the Data Access Groups page or the User Rights page.
  • This feature is the result of integrating the “DAG Switcher” external module built by Luke Stevens. We thank him for his contribution and for agreeing to let us integrate this useful module into REDCap. NOTE: Because the “DAG Switcher” external module is not compatible with this integrated functionality in v9.9.0, when upgrading REDCap to 9.9.0 or higher, if the “DAG Switcher” external module is already installed and enabled on your REDCap system, it will be automatically disabled at the system level during the upgrade process to prevent a conflict.

 Changes for Long-Standing Quirks with Calculated Fields and Branching Logic 

  • Change: In previous versions, calculated fields could only utilize either numeric fields or date/datetime fields in the calculation. Now non-numeric fields may be used, most notably inside IF statements. For example, if ([field1] = “A”, 0, 99).
  • Change: In previous versions, using > or < in branching logic would not always work as expected. For example, [a] > [b] would have to be formatted as [a]*1 > [b]*1 to work correctly 100% of the time, which is not intuitive. This is no longer required, in which [a] > [b] will work as one would expect in branching logic. Note: This does not apply to calc fields, which have never had this problem.
  • Change/improvement: The datediff() function used in branching logic and calc fields no longer requires the date format parameter (“ymd”, “mdy”, “dmy”). This was required for datediff() in calc fields and branching logic but was not required elsewhere, such as in report filters, DQ rule logic, ASI/Alert conditions, etc. The $returnSignedValue parameter (if provided) can now be provided as the fourth parameter - e.g., datediff([dob], “today”, “y”, true). NOTE: Both of the date/datetime fields used in the datediff function must still be in the same date format (“mdy”, “dmy”, or “ymd”), so that is still a requirement.

Record-Level Locking Feature 

  • This feature allows users to lock an entire record (as opposed to locking individual instruments) so that none of the record’s data can ever be modified unless someone with record-level locking/unlocking privileges goes and unlocks the record again.
  • The old “lock all forms for all events” feature has been changed into this new record-level locking feature, which is distinguishable from the existing instrument-level locking feature. Now the instrument-level locking can only be used while on a data entry form (using the Locking checkbox at the bottom of the form). Whereas the record-level locking feature is available as an option on the Record Home Page and the project’s left-hand menu after a record has been selected.
  • While records have always been able to be locked (i.e., made read-only) for individual data collection instruments in a project, you may now easily lock an ENTIRE record so that no data in the record can ever be modified while it is locked.
  • WHAT HAS CHANGED? It is important to note that the old user privilege "Lock all forms" has now been converted into the new record-level locking feature, which works entirely independently from instrument-level locking (i.e., the checkbox at the bottom of data entry forms). Instead of that particular user privilege allowing you to lock all forms individually (which was the previous behavior), it will now serve in a slightly different capacity as the record-level locking user privilege to lock an entire record fully.
  • HOW TO USE IT: You may lock an entire record via the "choose action for record" drop-down on the Record Home Page or by clicking the "Lock Entire Record" link on the project's left-hand menu when viewing a record. Note: Since the record locking and instrument locking are completely separate features, they both may be used together in a project, if you wish. However, please note that since record locking is a higher-level locking than instrument locking, an entire record may be locked or unlocked while one or more instruments are currently locked, but an instrument cannot be locked or unlocked while the entire record is locked.

 Field Embedding 

  • Field Embedding is the ultimate way to customize surveys and data collection instruments to make them look exactly how you want. Field Embedding is a Shazam-like feature that allows you to reposition field elements on a survey page or data entry form so that they get embedded in a new location on that same page. Embedding fields gives users greater control over the look and feel of your instrument. Users may place fields in a grid/table for a more compact user-friendly page, or position fields close together in a group if they are related.
  • To use Field Embedding, users need to place the REDCap variable name of a field inside braces/curly brackets - e.g., {date_of_birth} - and place it in the Field Label, Field Note, Section Header, or Choice Label of any other field on that same instrument. Field embedding will not work across instruments but only on the current instrument/survey being viewed. If on a multi-page survey, then the embedded field must be on the same survey page as its host field.
  • No action tags or custom HTML is required to use Field Embedding. Users can use the rich text editor in the Online Designer to design their layout and then place the field variables inside that layout. The layout does not have to be a table/grid (although tables are common for this), and fields can be embedded inside *any* field type (not just Descriptive fields).
  • We wish to thank Andy Martin (Stanford) because his popular Shazam external module served as the conceptual inspiration of the Field Embedding feature.
  • Note: When installing or upgrading to v10.0.0, a new project “Field Embedding Example Project” will be automatically added as a project template to easily allow users and admins to see some examples of Field Embedding in action.

 Online Designer’s “Add/Edit Branching Logic” 

  •  A new feature was added dialog to help users modify branching logic for many fields at once if they had the same branching logic.

 Modify Multiple Fields Together on the Online Designer 

  • Users may select multiple fields on the Online Designer by holding the Ctrl, Shift, or Cmd key on their keyboard while clicking on the field in the table, which will reveal the options to Move, Copy, or Delete all the selected fields. To make users aware of this feature, a floating note now appears near the right side of the Online Designer page with instructions on how to use this.

Changelog LTS Version 8.10.11

Bug Fixes and Other Changes:

  • Critical security fix: An SQL Injection vulnerability was found on several pages that could be potentially exploited by manipulating the URL query string of an HTTP request by a malicious user, including non-REDCap users through publicly available URL end-points that do not enforce authentication. It appears very unlikely that this vulnerability could be used to extract information from a REDCap database. But if enough knowledge is known about REDCap internally, it might be possible for an outsider to upload files into random projects in REDCap; however, there is no evidence that those same files could be executed or downloaded, and thus the files would essentially be orphaned (would not be accessible through the user interface in any way) and would simply take up unnecessary space on the file server. This bug appears to exist in every version of REDCap since version 4.0.0.
  • Major bug fix: If a user attempted to put a production project into Draft Mode on the Online Designer page, it would fail and merely reload the page. (Ticket #49866)
  • Major bug fix: If a user has "De-identified" or "Remove all tagged Identifier fields" data export user privileges in a project, and then the user downloads a PDF of a data entry form with saved data, in which the form is a repeating instrument or repeating event, it would mistakenly not remove the appropriate data from the PDF as required according to their user privileges. (Ticket #52190)
  • Major bug fix: If a user has data export privileges of "De-identified" or "Remove all tagged Identifier fields", and then the user exports a report in which every field in the report gets removed due to their export privileges, then it would mistakenly export data for *all* the fields in the entire project. (Ticket #48976)
  • Major bug fix: On survey pages, data entry forms, and other pages where conditional logic and calcs are evaluated, those pages may take an exorbitant amount of time to load (and in some cases may never successfully load at all). This appears to only affect certain Windows server environments.
  • Major bug fix: The "Export Records" API method mistakenly fails and will never complete due to a fatal PHP error. Bug emerged in REDCap 8.5.23. (Ticket #54340)
  • Major bug fix: The DateDiff+Today/Now cron job would sometimes crash due to a fatal PHP error caused when processing the [survey-link] Smart Variable in the message of an Automated Survey Invitation. This would occur only under very specific conditions, and it would result in many projects/records not having their ASI datediff logic being processed, thus the ASI's survey invitations would not get successfully scheduled in these cases and might cause invitations from other unrelated projects not to get scheduled either. (Ticket #61346, #61213)
  • Major bug fix: When a project is using a public survey that has "Save & Return Later" enabled with "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button on the public survey and leaves the survey open on the "Your survey responses were saved!" page while another participant partially or fully completes the survey, and then if the original participant clicks the "Continue Survey Now" button on the "Your survey responses were saved!" page, then the original participant will mistakenly create a brand new record/response whenever they submit survey page again after returning. (Ticket #61764)
  • Major bug fix: When a project is using a public survey that has "Save & Return Later" enabled with "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button on the public survey and leaves the survey open on the "Your survey responses were saved!" page while another participant partially or fully completes the survey, and then if the original participant clicks the "Continue Survey Now" button on the "Your survey responses were saved!" page, then the original participant will mistakenly have the other participant's response loaded for them on the survey page.
  • Major bug fix: When the Clinical Data Pull (CDP) is enabled on a project, if extra data is imported from the EHR for several patients at one time via the cron job (after a user has already pulled some patient data from the EHR for those patients), in certain cases it might mistakenly not clear out data from another patient whose data is being fetched and thus inadvertently add one patient’s data to another patient.
  • Major bug fix: When the Clinical Data Pull (CDP) is enabled on a project, if extra data is imported from the EHR for several patients at one time via the cron job (after a user has already pulled some patient data from the EHR for those patients), in certain cases it might mistakenly not clear out data from another patient whose data is being fetched and thus inadvertently add one patient’s data to another patient.
  • Major bug fix: When upgrading from a REDCap version lower than 8.4.0 to version 8.4.0 or higher, if any projects used Twilio telephony services for surveys and had an Automated Survey Invitation set to use the "Participant's Preference" for the delivery method, then new invitations scheduled by the ASI might not include a survey link (when needed) upon being scheduled. (Ticket #42868)
  • Major bug fix: When using Smart Variables in the conditional logic of an Automated Survey Invitation, in which the logic also contains a datediff function using "today" or "now" as a parameter in the function, it would often cause the ASI cron job to not correctly parse the logic and thus not schedule the invitations at the correct time, or it might mistakenly cause the cron job to crash unexpectedly without finishing scheduling all other ASIs for other surveys.
  • Medium security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on many pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.
  • Medium security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on many pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.
  • Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on certain pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.
  • Minor security fix: An SQL Injection vulnerability was found on surveys pages and data entry pages in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.
  • Minor security fix: If a malicious user is able to find the URL endpoint at which REDCap Messenger's message history can be downloaded as a CSV file for a given conservation, they could potentially exploit it by manipulating the query string of the HTTP request, which might allow them to download other users' conversations to which they do not have access.
  • Minor security fix: If the hook functions file (as defined on the General Configuration page in the Control Center) begins with "http" or "ftp", then REDCap will not attempt to call/include that path.

Boilerplate Text for IRB and Grant Submissions

You may copy and paste the following boilerplate text into the data management section of your IRB application or grant submission.

The Biomedical Informatics program of the UC Davis Clinical and Translational Science Center is a central location for data management. Vanderbilt University, with collaboration from a consortium of institutional partners, has developed a software toolset and workflow methodology for electronic collection and management of research and clinical trial data.

REDCap (Research Electronic Data Capture) data collection projects rely on a thorough study-specific data dictionary defined in an iterative self-documenting process by all members of the research team with planning assistance from the Biomedical Informatics program. The iterative development and testing process results in a well-planned data collection strategy for individual studies. The REDCap system provides secure, web-based applications that are flexible enough to be used for a variety of types of research, providing an intuitive interface for users to enter data and have real time validation rules (with automated data type and range checks) at the time of entry. These systems offer easy data manipulation with audit trails for reporting, monitoring and querying patient records, and an automated export mechanism to common statistical packages (SPSS, SAS, Stata, R/S-Plus).

REDCap servers are housed in a cloud data center at Amazon Web Services (AWS) and all web-based information transmission is encrypted. REDCap was developed specifically around HIPAA-Security guidelines. REDCap was initially developed and deployed at Vanderbilt University but now has collaborative support from a wide consortium of domestic and international partners. More information can be found at https://www.project-redcap.org/.

Need support? Have questions or comments about REDCap?

Request Consult (hs-redcap.support@ucdavis.edu)