Institutional Validation
Individual institutions should adapt this document to meet their institutional requirements.
Approach
Core and ancillary features are validated centrally by the REDCap Regulatory & Software Validation
Committee (Core features) and the Canadian REDCap Validation Group (ancillary, commonly used features
that are not considered core). The aim of institutional validation is to demonstrate that the REDCap system
is correctly installed and that critical functions and features operate in the context of the institution’s
infrastructure and operating environment.
Individual institutions must run one or more validation scripts locally in order to confirm that, in general, the
REDCap application is installed correctly and runs in the context of the institution’s own technical
infrastructure and operating environment. This may be based on a simple script provided by the Canadian
REDCap Validation Group but should also include elements that are designed to test local configurations
and additional elements such as LDAP configuration, two-factor authentication, hooks, plugins, external
modules, etc. Ideally, this institutional validation should be performed in a test environment provided for that
purpose. It should be performed after initial system installation and before subsequent upgrades. However,
in a situation where an individual study team has minimal or no technical support for their installation this
validation could be performed in a project provided specifically for that purpose or could be included in study
level testing. Under these circumstances the script must be edited to exclude features that are not
accessible to the study team and to document other approaches to testing these features.
Institutional Requirements Definition
Risk Level
The items below are assigned a risk rating based on their level of dependence on local infrastructure and
server configurations. Most critical items are tested by REDCap’s built-in configuration test module.
However, for high risk items, institutions should consider how the feature is reliant upon these local
configurations and tailor the validation effort accordingly. Low risk items are included in the validation script
in order to provide additional confidence in the overall validation effort. Note however that these features are
unlikely to be tested at the study level each time a system upgrade is applied, so there is value to be had
from adding them at the institutional level.
1 High Risk Feature is critical to system security or performance and highly dependent on
local infrastructure. Should be tested with each major upgrade.
2 Medium Risk Feature is critical to system security and/or privacy but does not need to be tested
with every minor upgrade.
1 of 5
3 Low Risk or subject Other commonly used features, study specific features.
to study level testing.
Institution Specific Items
Feature Risk Level Notes
1 Installation 1 After a fresh install, or following an upgrade, correct installation
should be confirmed by running REDCap’s Configuration Test
module. This should be done in the validation environment prior to
upgrading the live system. It should also be run in the live system
immediately after installation or upgrade in order to confirm that the
installation remains valid.
2 Data encryption - 2 SSL configurations must be valid and free from critical issues. The
browser configuration check tests that SSL is enabled. Local configurations
should be tested periodically, but not necessarily with every
upgrade since REDCap upgrades do not modify web server
configurations.
Can be validated using the SSL Server Test page at
[Link]
3 Data encryption - 2 Several REDCap features rely on the ability to encrypt and decrypt
application data, files, etc. This feature is dependent on correct installation of
server. the underlying software stack. Availability of the required software is
tested by the configuration check. Additionally, logging in to
REDCap using a table-based username and changing the user’s
password will check that REDCap can encrypt and decrypt data
while also testing system logins. Institutions that use external logins
such as LDAP or Shibboleth may wish to consider additional tests.
Data encryption is unlikely to be affected by minor upgrades. It
should, however, be tested every major release and whenever
significant changes are made to the underlying software stack or
operating system.
4 System login 1 The default script should test system logins and 2FA (Twilio, Duo,
etc.) configurations.
Two-factor Institutions that use external logins such as LDAP or Shibboleth
authentication 2 may wish to consider additional tests.
2FA need not be tested with each minor upgrade.
5 File permissions, 2 Default REDCap configurations store files on the application server.
file uploads and Operating system file permissions are checked by the configuration
storage. check. The validation script should check that files can be uploaded
and downloaded to/from CRFs, the file repository, etc. Institutions
that use external file storage should consider if these checks are
adequate for their system.
6 Plugins, hooks 2/3 The API, plugins, hooks and external modules are features that
2 of 5
and external allow individual installations of REDCap to provide additional
modules. non-standard features and product extensions. The configuration
API Integrations. check tests basic configurations for these features. Additionally, the
default institutional validation script should check that external
modules, where supported, can be enabled and upgraded and that
upgraded modules do not obviously interfere with subsequent
operations.
Individual institutions should consider their approach to testing
these features, most likely during study level testing.
7 Email 2 Several REDCap features are dependent on the system’s ability to
send email. Email configuration is both institution and operating
system dependent but is unlikely to be affected by minor upgrades.
The configuration check tests that email functions are available but
the default validation script should also test that email can be sent
and that it is received by its intended recipient.
8 Database 2 The configuration check tests basic database connectivity and
configuration performs additional tests that are intended to warn of non-optimal
configurations. Warnings displayed by the configuration check may
not be critical but should be considered for remediation by the
institution.
Database configuration is unlikely to be affected by minor upgrades.
9 Database 2 When performing upgrades that modify database structures
consistency institutions should give consideration to how they check that
database integrity has been maintained. In general, this may be
inferred from the configuration check and the continued operation of
the system. However, some upgrades or other systems operations
may involve significant change. At the very least administrators
should give consideration to record counts in the main REDCap
data tables (or statistics provided by the Control Centre). Large
variations in before and after counts may indicate an issue.
Minor LTS releases, by definition, do not normally affect database
structure and therefore database consistency does not need to be
checked before each minor upgrade.
Standard REDCap Features
The following standard but critical features of REDCap will also be tested by the institutional validation
script.
Feature Risk Level Notes
10 System Login 1 Users can login, using locally configured 2FA, if applicable,
and change their password.
11 Home page and “My 3 Pages are displayed, existing projects are listed correctly.
Projects”.
3 of 5
12 Project creation 3
13 Online designer / 3
instrument build
14 Support for multiple 3
variable types and
validations
15 Data entry 3 Addition and deletion of records, basic branching logic.
Form level display logic
16 Surveys. 3 Some simple tests should suffice because complex
configurations such as ASIs should be tested at the project
level.
17 Longitudinal projects 3
18 Repeating instruments 2
19 User roles, rights and 1 Should be included in any minor upgrade testing.
data access groups.
R1 Data quality rules, 3 Data quality
9 queries and query
resolution.
20 Data export and import 2 Since exports are based on user roles errors could impact
privacy.
21 Logging 2 Privacy
22 External module 3
version upgrades
Out of Scope
Additionally some features are only implemented at the project level and are considered out of scope for
institutional level validation. These features should be considered for study-level testing and may require
retesting following each upgrade.
Feature Notes
23 Project Bookmarks Generally cosmetic, but may be used to link to participant specific data or
records in other REDCap projects.
24 API Integrations May be considered high risk in the context of an individual project.
4 of 5
25 SMS messaging SMS messaging (Twilio, Mosio) can be configured and tested at the study
level. Again, these may be critical for an individual study.
26 Google Captcha Although configured centrally this is enabled for individual surveys and
therefore tested at the study [Link] is also considered low risk.
27 Automated Survey These features, where used, should be tested at the study level.
Invitations, Alerts &
Notifications.
Minor Upgrades
REDCap’s development life cycle produces two codelines, Standard and LTS. The Standard codeline is
actively developed and subject to frequent changes as functionality is added. This results in frequent new
releases, often weekly. This is referred to as the Standard REDCap version. The Standard version always
contains the newest functionality. In contrast, the LTS (Long Term Support) codeline is a major release
forked from the Standard codeline every six months. During the six month cycle it is supported with patches
only (i.e. new features are not added). Only bug fixes and security updates are included. As a result, minor
releases are considered to be low risk. However, each institution should consider a strategy for testing minor
releases before they are implemented on production systems. The suggested approach is to develop a
“minor upgrade script” that confirms that the upgrade was error free and that fundamental system features
still function. This script may be based on a subset of the institutional validation script.
5 of 5
