1. New Administrator Workshop
Portland, Oregon
September 28, 2015
2015 REDCapCon Workshop Leaders:
Andy Arenson, Indiana University
Sean Banks, Seton Healthcare Family
Linda Carlin, University of Colorado Denver
Bas de Veer, University of Washington
Andrew Martin, Stanford University
Terri Shkuda, University of Pittsburgh
Rob Taylor, Vanderbilt University

2. REDCap Consortium Resources
Linda Carlin

3. REDCap Consortium Resources
Project REDCap Website
Consortium Wiki
Weekly All-Hands Webinar
Weekly Tech Assistance Webinar
Google Group Listserv

4. Project REDCap Website
projectredcap.org
Public info site
List of consortium partners
Partner site contacts & stats (if you know the super secret login)

5. REDCap Wiki Requires login Links to all RC resources
REDCap updates & release notes
All committee information

6. REDCap Weekly All-Hands Webinar
Weekly 1-hour webinar to update consortium members about:
New members
New or upcoming functionality
Demonstrations
Great way to stay “in the know” about the consortium
Fridays, 1-2 CT
Registration link on wiki main page

7. REDCap Tech Assistance Webinar aka Rob’s Corner
Weekly 1-hour technical support call/webinar with the man himself!
Worth calling in just to listen and learn
Thursdays, 11:30-12:30 CT
GoToMeeting information is on Wiki main page
Rob’s Corner

8. REDCap Google Groups Listserv
Requires login
Great resource for getting help
All levels of questions welcome (really)
Search history first
Usually get same-day response(s)

9. Installation and Upgrades
Andrew Martin

10. REDCap is a Web Application
(e.g.
Web Server
connectivity
Database Server
File system
Configuration
Web Server
Apache or IIS
PHP
Database
MySQL
File System
Local or WebDAV

11. Simple – Single Machine Installation
Run everything on your computer!
Web server with PHP
Database server
Downside is only you or others on your local network can connect
No public surveys, sketchy support
This should only be used for testing & development
Join one of the developer talks to learn more about how to set this up
Virtual Machines
MAMP / WAMP / XAMPP

12. A Professional Installation
Separate servers for web and database
More secure, scales better, performs better
Robust backups
A slave DB server allows for 24-7 runtime with backups
No backup is complete without both eDocs AND database components
Don’t forget DET / API / HOOK scripts
Additional installations are useful
Testing can be used to practice the upgrade process
Recovery can be used to validate backups and help quickly recover from common user mistakes
Robust firewall and security precautions
Proper MySql and Apache/IIS configurations for production environment

13. An Example Secure Installation

14. Practical Take-Homes
REDCap requires IT personnel to properly maintain and secure in a healthcare / research environment
While one could run it under their desk, this should only be for testing/development and not for REAL use
In order to use the robust patient-reported features (public surveys) you MUST expose your web server to the internet
Firewall / Proxy / Load Balancer / etc…
A robust backup strategy is a life saver – test it, use it, one day it will be needed

15. Common Struggling Points
Mail Configuration
Often you will have to work with central IT to configure a SMTP relay
LDAP Integration
Identify an institutional LDAP guru who can make sure you have a user with proper credentials to use the directory
Database Configuration
Make sure MySql user-level security is tight and my.cnf is configured with appropriate settings
Is there a training page / lookup page for my.cnf
Proxy Server
Use of external library and adaptive testing requires that oyur server can access the internet – this may require a proxy server in some settings
File Permissions
Verify the redcap temp and edocs folders are writable by your webserver user

16. Memory and Configuration
Web Server (CPU+++ / Memory++ / Disk+ )
PHP: /etc/php.ini
memory_limit
Max memory a script can consume. Can affect large imports and exports. (We’re running at 384M)
max_input_vars
Maximum number of post key-value attributes (10,000 is recommended)
REDCap takes care of some of this for you (bootstrap.php):
if (str_replace("M", "", ini_get('memory_limit')) < 512) ini_set('memory_limit', '512M');
ini_set('max_execution_time', 1200);
Production Settings
display_errors = Off
log_errors = On
error_log = /var/log/php/php_errors.log (optional)
Maximum Uploads:
post_max_size
upload_max_filesize
Your default timezone
date.timezone = America/Los_Angeles
Mail Settings ([mail function] section (work with local IT)

17. Memory and Configuration
Web Server Cont (Apache in my case)
APACHE: /etc/httpd/… or /etc/apache2/…
Php5 handler / DirectoryIndex index.php
Prefork vs Worker MPM (most default to prefork…)
We’re running PreFork with 32GB ram (high-end – many running with 4GB ram)
CPU Demands of PHP / Caching – Accelerators
Authentication / Shibboleth requires special folder permissions
Database Server (CPU++ / Memory+++ / Disk++) – 16GB /
MySql: /etc/php.ini
default-storage-engine=innodb
collation_server=utf8_unicode_ci
sort_buffer_size (we’re running at 64M)
max_allowed_packet (once had to increase due to VERY large ‘in’ clause)
innodb_file_per_table (something to discus with your IT)

18. Obtaining REDCap Consortium Website (requires credentials)
TRAC Wiki
Which Version to Run?
LTS = Long Term Support
Good for conservative / high audited environments
Do a full review for each major release (every 6-9 months)
Apply bug patches (6.5.x point-releases) without full review
Standard = Lastest and Greatest
Quicker access to new features
Can require more frequent patching if new bugs emerge

19. Standard and LTS Which version is right for us?
Can I switch flavors later?
Yes, so long as you are going ‘up’ in version number you can move on or off the LTS path

20. Upgrade Frequency The more the better REDCap updates are NOT automatic
Google Maps: 10 updates in 2015
REDCap Mobile App: 15 updates in 2015
Uber App: 24 updates in 2015
REDCap Standard: >25 updates in 2015
REDCap updates are NOT automatic
Recommend updating at least every 3 months
Unscheduled updates for security / key bug fix

21. Upgrade Workflow File-component Database-component
Each release creates a new folder
Leave them alone – they do not introduce a security risk
Can be done anytime as REDCap won’t start using the new folder until the database is upgraded
Database-component
Two types of upgrades:
Online: Can be applied without downtime
Offline: Requires scheduled downtime

22. One Approach to Upgrades
Read through change log from current version to new version – understand what’s going on and look for clues / warnings about upgrade
Upgrade your TEST or RECOVERY instance
Unzip upgrade and verify file locations
View Control Center to generate update SQL
Tells you if this update requires downtime
Speak SQL?
Review the code – helps you understand REDCap better
Execute SQL
Be aware of timeout caveats and stopping on errors
Repeat process on production
If downtime is required, give advanced
A full backup is the ONLY way to revert from a failed upgrade
Good communication is a must between IT and REDCap Admins
If errors occur, obtain as much detail as possible

23. Server Tuning Apache / IIS Configuration (/etc/httpd/httpd.conf)
CPU / Memory Resources
Maximum number of simultaneous users/survey takers (impact testing)
Access permissions
Shibboleth / LDAP / API / Survey URLs
Learn to read the access and error logs for your web server
PHP Configuration (/etc/php.ini)
date.timezone
memory_limit >> max_post_size >= upload_max_filesize
(example from our server: 384MB / 65MB / 32MB)
max_input_vars = 10000
error_log (where will your php errors write?)
Find this and get to know it – it is an invaluable resource if you are ever debugging an issue
MySql Configuration (/etc/my.cnf)
Consider innodb_file_per_table (must be done before setup or with restore)
sort_buffer_size / max_allowed_packet
Sufficient free disk space (some db operations can use a LOT of temp disk)
MySql user configuration should restrict access as needed (do not use wildcards)

24. REDCap Configuration Rob Taylor

25. Initial Configuration (General Configuration page)
Who will be the REDCap administrators supporting your users?
Set the names/ s of general contact person and person approving production changes (can be same person or a shared account)
Can be done during REDCap installation or on General Configuration page.

26. Authentication Settings (Security & Authentication page)
Initial REDCap installation has no authentication (public/none) – everyone is “site_admin” user
Built-in authentication: Table-based
How to create Table-based user accounts in Control Center

27. Authentication Settings
External authentication methods (uses other systems outside REDCap)
LDAP
LDAP & Table-based together
Shibboleth, Open ID, RSA SecurID, and others
How to choose which authentication method?
Does your institution already utilize a centralized login system?

28. Authentication Settings
External authentication methods (cont’d)
How user accounts are created
User Whitelist
Need two-factor authentication for extra security?
Receive SMS message with verification code
Receive phone call
Use Google Authenticator app
(default)
Duo Security (all-in-one SMS, phone, app)

29. (Optional) Authentication Settings
Customizing the login page with custom text and logo
Set login session expiration time & auto-lockout for multiple failed logins
Table-based authentication only
Password recovery questions
Enforce password re-use and force users to change password periodically

30. Other Configuration Options
Security settings
Rate limiting and IP blocking (General Config page)
Password expiration (Browse Users page)
User suspension - manual by super user (Browse Users page) or auto-suspension due to inactivity (User Settings page)
Troubleshooting general issues
First, always check the Configuration Check page
Ask the Google Group (sign up at tinyurl.com/redcapsupport2)
Attend the Rob’s Corner call on Thursdays (11:30 AM CT)

31. Gatekeeping Andy Arenson
Which functionality will be reserved for super users?

32. Decisions to be made Who can create a project?
Who can move a project to production?
Which project changes require approval?
Who can add/modify events and arms?

33. Who can create a project?
Anyone
Super users only

34. Who can move a project to production?
Anyone
Super users only

35. Which project changes require approval?
All
All, except new fields
All, except new fields, or if no records exist
None, unless critical issues found
None, unless critical issues found and records exist
Critical issue: (e.g., fields deleted, multiple choice options deleted, field type changed)

36. Who can add/modify events and arms?
Anyone
Super users only – Typically chosen, as data can easily be lost when modifying events.

37. REDCap User Tools Terri Shkuda

38. REDCap Super User Tools
Table-based user creation
LDAP user creation and the Whitelist
Finding a user or project
Sending an
Statistics and activity

39. Table-based User Creation
Table-based authentication allows for the creation of the user account as opposed to searching your local LDAP.
Benefits to table-based are:
Allows for an automated expiration of an account
Allows for auto-suspension due to inactivity
Create Users in bulk

40. LDAP User Creation and the Whitelist
REDCap provides for the selection of LDAP (Light-weight Directory Access Protocol) as its authentication method where it uses the employee’s institutional credentials for accessing REDCap.
Along with LDAP authentication, REDCap provides a Whitelist functionality that can be used to restrict access from the broader LDAP directory for the institution. The whitelist states who in the LDAP for your institutions will have access to REDCap.

41. Finding a User Search by criteria Search by username/name/email
Information for each user can be found such as their s, sponsor, access restrictions, expiration date and access statistics.
For table-based, additionally you can reset passwords, suspend and delete users from the system.

42. Finding a Project
Projects can be found by searching:
By user
Alphabetically by project
Filter projects by title
View projects by user when you have the User information page.

43. Sending an
Selection of the users who will receive an can be selected individually or by activity level.
New Feature: ability to opt out of s when creating the user.

44. Statistics and Activity
Activity Graphics for:
Concurrent users
Daily users logins
Projects created
Projects moved to Production
Active users
First-time visitors
Logged events
Page hits

45. Regulatory Terri Shkuda

46. REDCap System Validation & 21 CFR Part 11
The REDCap Consortium has a committee, Regulatory & Software Validation, which provides documentation to support system validation and 21 CFR Part 11 compliance.
It provides the Functional Specification with its corresponding test scripts to support validation activities.
The committee also provides a support document that addresses 21 CFR Part 11, paragraph-by-paragraph.

47. System Validation
A systematic review of administrative, physical and technical controls which results in documented evidence that the system was developed, implemented and operated in a controlled manner throughout the life cycle of the system and is suitable for its intended purpose.
Software Development Life Cycle:
User Requirements
Functional Specification
Test Scripts

48. 21 CFR Part 11 Title 21 of the Code of Federal Regulations: Electronic Records; Electronic Signature (21 CFR Part 11).
In order to submit information to the FDA, researchers need to show compliance with 21 CFR Part 11. In particular, it “….applies to electronic records that are created, modified, maintained, archived, retrieved or transmitted...”1
Validating the REDCap system serves as only part of this compliance picture. The project’s study team will need to provide documentation of their processes as well to show compliance.
The REDCap application can be only considered 21 CFR Part 11 capable.
1http://

49. Gaining Institutional Support Sean Banks

50. Institutional Support
Technical team (IT/IS)
REDCap Security information!
Scan REDCap? (App / server scan)
Biostatistics / Analytics Department
Research Organizations
Clinical Organizations
IRB

51. Operations and Capabilities
Bas de Veer

52. Operations – Operational Models
Hands-off approach (Vanderbilt)
Low cost
Minimal user support
Less control
Hands-on approach (Duke)
High cost
Fee per project
Higher burden of responsibility
Hybrid (University of Washington)
Medium cost
Consultancy model (hourly fees)
Emphasis on training users

53. Operations – User Support
Issue tracker
List servs
Personal versus generic
Phone
Limited hours
Interview/troubleshoot style
1 at a time
In-person
Time intensive
Teaching experience
Becoming the “face” of your service

54. Operations – Training Classes Documentation Outreach/Demonstrations
Quality depends on the speaker
Lecture versus step by step
Recordings
Documentation
Local FAQ
Tip of the month / Canned responses
Speeds up support
Outreach/Demonstrations
Seeing is believing
Requires in-depth knowledge of REDCap
Great for “busy” professionals (M.D.’s, Professors)

55. Operations – Marketing
Word of mouth
Generated by good and fast service
IRB sponsorship
Lowers the threshold
Market as a “shortcut”
Highlight useful features
Dependent on audience, e.g.,
M.D.’s: New ontology lookups
Researcher coordinators: Survey automation
Statisticians: Export into statistical formats
IRB: Code book and logging features

56. Operations – Governance
Day-to-day
Low level decisions
Done by REDCap administrator
Decision power
Upgrade cycles (Hospital IT versus Local IT)
Operational model
Target type of users (internal versus external)
Stakeholders
Users versus leadership versus IRB versus IT
Documentation
Professionalism = Trust

57. Operations – Personnel Requirements
How big is your shop?
Operational model
Hands-off versus hands-on versus hybrid
Size of your institution(s)
Potential users (incl. external)
IT requirements
Upgrade cycle
Support requirements

58. Operations – FTEs Hardware Management Administration Training
Installation
Upgrades
Hardware maintenance
Administration
Day-to-day click-throughs
Advanced features (Dynamic SQL, Double Data Entry)
Troubleshooting
Training
Demos, classes, hands-on training
Marketing
Generating content

59. Operations – User Growth
Support model
Drives growth rate
Drives administrator requirements
Marketing & Training
Target low hanging fruit (Research Coordinators)
Train “Champions”
Lower thresholds
Monitor your user growth
Control Center
Adjust based on data
Operational model
Marketing

60. Operations – Project Development
Consultancy
Under-promise, but exceed expectations
Communicate clear standards and estimates
Study management trap
Design, not manage
Train study team to do data entry
Lower thresholds
Communicate often
Iterate, iterate and iterate some more
Include study team in the design / test process
Agile methodology

61. Capabilities – Out of the box
Classic
Simple
Linear
Data entry by users
Longitudinal
Complex
Multiple time points (or events)
Recycling of forms
Surveys
Data entry without login
More restrictive but simpler
Various distribution methods

62. Capabilities – Classical
Good for beginners
Flat file
Unique record IDs
One variable = one value
Exceptions:
Checkboxes
File upload
Signature
Multiple different forms allowed
Simple branching logic
Surveys allowed

63. Capabilities – Longitudinal
List of forms and list of arms/events
Arms
Events
Forms
Recycling forms
Unique event names
Found in the “Define my Events”
Increased branching logic complexity
[bmi]>30 vs [baseline_arm_1][bmi]>30
Days offset
Calendar function and event order

64. Capabilities – Longitudinal
Single arm
Single protocol
Baseline plus multiple follow ups
Multiple arms
Locations
Placebo vs intervention
Drug A vs drug B
Different workflows (e.g. parents and kids)
Record ID pitfall

65. Capabilities – Surveys
Setup phase
Main project settings
Optional modules and customization
Designate the field ( validation)
Setup Twilio
Online designer
Survey settings
Survey queue
Survey login
Survey notifications
Automatic invitations
Classical vs longitudinal

66. Capabilities – Surveys
Distribution phase
Public link vs invitations
Manage survey participants
Public survey link
Participant list
Survey invitation log
QR codes
Twilio (phone and text surveys)
Survey access code
Survey queue links
Automatic invitations
Trigger forms
Survey queue

67. Capabilities – Surveys
Export phase
Survey time stamps
Anonymous surveys vs de-identified export
Nuggets of wisdom
Any survey can be filled out as form
De-activating a survey counts for all events
Auto-numbering gets turned on automatically
Auto-continue and survey queue might conflict
Looping a survey back on itself, if allowed

68. Capabilities – Applications
Design and setup
Data entry
Quality control
Data export
Logging and auditing
API

69. Capabilities – Applications
Design and setup
User rights
Individual rights
Roles
“Keys to the castle”
Expiration dates
Data access groups (DAGs)
Double data entry
Multi-site studies
Randomization
Involve a statistician
Locking
Complex workflows

70. Capabilities – Applications
Data entry
Data import tool
Legacy data
Partial imports allowed
Generate lots of records quickly
REDCap Mobile App
API
Calendar
Longitudinal
Not exportable
Based on “Days offset”

71. Capabilities – Applications
Quality control
Data comparison
Displays just the differences
Data quality
Check your whole data set
Create custom rules
Field comments
Turned on by default
Data resolution workflow
Complex projects
Define a clear S.O.P. (Standard Operation Procedure)
Assign the correct user rights

72. Capabilities – Applications
Data exports
Data exports, reports and stats
Dynamic reports
Limited analytic ability
Basic graphs for structured fields
Different formats (CSV x 2, SPSS, SAS, R, Stata)
De-identification options
API

73. Capabilities – Applications
Logging and auditing
Logging
Contains everything for that project
Exportable
Filters
History widget
File repository
Previous exports
Project revision history
Only in production mode
Data dictionaries of previous versions

74. REDCap Mobile App Rob Taylor

75. What is the mobile app? Can be used on an iOS device or Android device
Can be used on a tablet or phone
Mobile web view (requires internet)
vs. Mobile app (can use with or without internet)

76. Purpose of the mobile app
Primary benefit: Offline data collection
REDCap requires internet, but the app can collect data in places where internet or a cellular signal is not available.
After collecting data, sync data on the app back to the REDCap server.

77. Beyond Vanilla: Developer Features
DET (Data Entry Triggers)
API (Application Program Interface)
Plugins (new REDCap pages)
Hooks (modified REDCap pages)
Andrew Martin

78. Data Entry Triggers Event-driven programming
Each time an action happens, you can chose how to respond (by adding a ‘listener’)

79. Configuring the DET Configured under Additional Customizations
Example output (input for your listener)
[redcap_url] =>
[project_url] =>
[project_id] => 209
[username] => andy123
[record] => 1
[instrument] => my_first_instrument
[my_first_instrument_complete] => 2

80. Application Programming Interface
The API defines rules and methods for interacting with an application
The REDCap API
Pseudo-RESTful interface
Import and Export project data and survey links
Why use the API instead of SQL?
All transactions are logged
Uses REDCap permissions
Available from anywhere in the world
Depending on your config
Adheres to system/software constraints
For example, survey URLs aren’t created until they are actually needed

81. Enabling the API System-wide option under Module Config
User/Role-level permissions in User Rights
API Rights WIN
Trump Data Export Rights
Data Entry Rights do not matter

82. The API Token and Security
The API Endpoint
An API Token is a type of credential
User + Project ID + Password
Each API token must be requested and approved
They can be revoked (for example after a project-change)

83. Using the API Any Language Will Do Example Parameters (Import records)
Java, PHP, .NET, Ruby, Javascript, etc…
Example Parameters (Import records)
Required
Token – User assigned token (KEEP SAFE)
content – record
Format--csv, json, xml [default]
Type—flat,eav
overwriteBehavior normal [default], overwrite
Data the formatted data to be imported (array)
Optional
returnContent– ids, count[default], nothing
returnFormat--csv, json, xml [default]
Test your methods first!
API Playground
Local test on your actual REDCap server
POSTMan
External test from your client computer

84. API Applications Bulk/Automated Import/Export of Data Helper Software
Statistical Software
SAS Exports in script
R Exports
Helper Software
PHP
RestCallRequest.php
PhpCap R
REDCapR
Python
PyCap

85. Mixing DETs and the API
Based on a user-input in a previous form you can augment the data for that record
Do an LDAP lookup based on an ID and add other data to the record
Automatically send out an based on a response
Assign a record to a cohort based on a custom randomization routine
Automatically score a complex standardized assessment with an external program and push the results right back into REDCap

86. DET+API: AutoScore Workflow
Example Project
Multiple instruments to be scored
Main Autoscore Web Service
Listens for any Data Entry Trigger messages
1) DET
1. DET notifies the Autoscore Web Service
Library of autoscore configuration files
3. Query data from the source project
3) API
Pulls Current Record
4. Runs specified algorithm
5. Writes results to calling project
Writes the scoring results
5) API
2) API
Scoring Parameters
2. Check for configured scoring jobs
ABC
RBSR
SCQL
Writes a Summary
6. Writes log to configuration project
6) API
Autoscore Config Project
One record for each instrument
Calliing Project
Algorithm to use
Trigger Instruments
Advanced configuration options

87. Plugins Add custom pages to your REDCap project Requirements
Use PHP and have access to the REDCap classes
Have full database access
Potential to do much good and harm
Requirements
Must have access and permission to write files to the production REDCap web server
May be a challenge in some highly regulated environments
Should have some basic knowledge about web development, security, and IT support
Server logs, debugging code, etc…
Include redcap_connect.php

88. Plugin (Developer) Methods
Build on REDCap
Instead of re-inventing REDCap
Documented Methods with example code
REDCap::getSurveyLink()

89. Plugin Examples
Add a custom report to a project

90. Hooks
PHP scripts executed in the middle of certain, existing REDCap pages
You can affect the look and behavior of certain existing REDCap pages
Including Surveys
Like plugins you have access to the full suite of “developer” methods
IMHO - Hooks are the most powerful developer tool for interaction with REDCap

91. Hook Example: Body Map
Image Map
A new UI to a checkbox question

92. Hook Example: Custom Layout
Redesign a matrix of questions

93. Summary Points DETs Plugins & Hooks Synchronous
REDCap waits for your DET to finish
API Inserts and the Data Import Tool do NOT fire DETs
There is no user interface for DET output
Debugging should be done via log files
Plugins & Hooks
Auditing must be part of the plugin design
Unlike DET+API, plugins / hooks require direct developer access to the production server and database

94. API Example in POSTMAN
POSTMAN Example

95. REDCap DDP (Dynamic Data Pull) Rob Taylor

96. What is the DDP?
Module for importing data from an external data source (e.g., EMR, EHR, data warehouse, I2B2)
Allows real-time importing of data from the data source into a REDCap project
Requires a technical person at your institution to build web services as “middleware” to allow REDCap to talk to your external data source (see DDP page in the Control Center for full details)

97. What is required to use the DDP?
DDP has a mapping module where users in a project can map their REDCap fields to fields from the source system
Each record in the project using DDP must have a record identifier that links it to the record in the source system (e.g., medical record number)
Using the mapping and the record identifier, REDCap can pull data in real time into the project.

98. How do you use the DDP?
Once the data has been fetched from the source system, a person will have to adjudicate the data, in which they will affirm it is correct (or choose one value if many values have been fetched) before importing the data into the project.

99. Lessons Learned
Sean Banks

100. Lessons Learned Backups / Development environment
Take notes to recreate your steps
What happens when we “go viral”?
How will support change?
Use your REDCap Resources
Rob’s Corner
Friday Consortium Calls
Ask the listserv