Avoiding Common Pitfalls in REDCap

advertisement
Avoiding Common Pitfalls in
REDCap
By
J. Kevan Essmyer
Special Thanks to
Jack Baty
REDCap Goals
 Easy to use
 Metadata Driven
 Adaptable Features
 Data entry validation
 Self service tool
Public HTTPS Access
Biostatistics Secure Domain
Tiresias
Server
File Server
Authenticated Access
Sync
MySQL Server
WUCON
Sidedoor
Server
Data Entry /Admin
WEB Server
MySQL Slave Server
Host Server
Project Creation Flow Chart
Create Project
–Project Name, Longitudinal or CrossSectional/ Survey
MoveMove
to Production
to Production
Status on
Production
Status and start
Server
Dataand
start Data
Collection
Collection
Excel Spreadsheet
Or
Online Form Designer
Data Entry
Forms
Add Users
and
Set User
Rights
Define
Study Events
(Longitudinal)
add Schedule (optional)
REDCap Best Practices for Data
Collection of Clinical Trials
 The Why?
 Design better studies
 Utilize previously proven techniques and forms
 Effeciencies
 Costs of not following good guidelines
 The When?
 Data form should be developed during the Protocol design and development,
not afterward
 The What?
 Design forms to capture the pertinent and necessary information
 Define variables, classes, elements and attributes as well as labels
 Define workflows and timelines for the data capture
(https://sweb.biostat.lan/wiki/index.php/Best_Practices)
(https://sidedoor.biostat.wustl.edu/wiki/index.php/Best_Practices)
Production Server
“Real Data”
 http://www.biostat.wustl.edu/redcap
 REDCap Project Request form (Fax or email)
 Sponsoring PI
 IRB Approval or Waiver
 Only PI or Project Admin can create projects
 Production “Status”
 Data Dictionary
 Changes saved
 Review of submitted changes to avoid unintended data corruption
 Delete all records function disallowed
Common Pitfalls
 Deleting Records
 Deleting Events
 Renaming Fields
 Corrupting Data Through Enumeration Changes
 Moving to Production Status Too Early
 Exotic Meta-Characters
 Project Account Request Paperwork
 Calculated fields
Deleting Records
 Record Deletion in REDCap is “record” based not “form”
based
 Removing a records removes all associated forms within the
current treatment arm
 Current solution(s):
 Export Data Delete  Re-Import record (not the entire
database)
 Contact Administrators
Target Form
Forms
Actually
Deleted
Target Form
Forms
Actually
Deleted
Delete Record button located at
bottom of REDCap forms
Feature should be turned off when
not needed
Deleting Events (Longitudinal)
 Events lists in REDCap are auto-numbered unlike form
fields.
 Removed fields can be restored by creating the same variable
again.
 Removed Events cannot be restored without administrator help.
 Changes to Event grids can now only be performed by the
REDCap administrators
Renaming Form Fields
 Form field names are linked directly to REDCap data values
 ?????
 Changing field names results in new variables.
 Data will still be linked to the old variable name.
 Data must be transferred to the new variable
 Manual entry
 Data Export / Import
 Restoring the original field name will restore access to the data.
 !!!First data field in the first form is the project data index!!!
 Renaming this field will cause all existing data to be in accessible.
 Date fields not recommended here.
Old variable name
Blood_draw
1/20/2011
New variable names
Blood_draw_1
Blood_draw_2
Blood_draw_3
Corrupting Data Through Enumeration
Changes

Dropdown list and Radio Button enumeration

Dropdown list or set of radio buttons can be in any order regardless of the numeric value assigned.


For example, they can have
1=Yu
3=Kevan
2=Jack

Choices will show in the order declared rather than numeric order.
Danger -- Overwriting Choices


Safer Option


1=Yu
3=Bobby
2=Jack
1=Yu
3=Kevan
2=Jack
4=Bobby
Better Option -- Overwriting Choices

10=Yu
20=Jack
25=Bobby
30=Kevan
Moving to Production Status Too Early
 Testing Forms!
 Critical both for avoiding delays and preventing data errors
 Test data is recommended to test calculated fields and branching logic
 Branching logic Errors can disable forms and inadvertently Erase
data.
 REDCap Deletes existing data in hidden fields.
 Use <>” ”
 Production Status on the Production Server
 Changes to forms must be approved by Administrators before they are
committed to the project.
 Changes to the Forms/ Event Grid must be preformed by the
Administrators.
Branching logic warning about
hiding existing data
Can be a dangerous situation and is best avoided.
Exotic Metacharacters
 Non-standard symbolic characters typically used by office
software such as MS Word.
 Usually benign but can sometimes cause problems with the
data dictionary
 Best to avoid using these Characters
 Alternatives
 HTML Codes for field label display.
 Comma -&#44;
 @
-&#64;
Project Account Request Paperwork
 Project Request Form
 Required for Each IRB Study in REDCap
 Identifies the PI and Project Administrators
 Used to verify request for project access in special cases.
 Person who setup the project leaves their position
 PI wants to gain access to their project data
 REDCap Administrator is requested to make design changes to the
project
 Reminder that data collection is regulated by the appropriate
IRB not REDCap.
Calculations
 Calculations should be considered a tool not data.
 Calculation should be reapplied during data analysis.
 Multiple calculations on a form.
 Order of execution is determined by the alphabetical ordering of it’s
associated variable/field name.
 Calculation 1 [weight_met] =[weight]*.45359237
 Calculation 2 [BMI]=[weight_met]/([height]^2)
 !!!Calculation 2 will occur before calculation 1

Calculate BMI in one step (Best Solution)
or

Rename variable to change order (only other option)
“?!!?”
User Rights
REDCap Lifelines
 Built-in tutorial videos
 Built-in Frequently Asked Question (FAQ) guide
 Demonstration Databases (Some Online, more to come)
 WUSM Biostat REDCap Email Help Queue
 [[email protected]]
 Monitored by 4 to 5 Administrators
REDCap Email Support
[email protected]
REDCap Goals
 Deleting Records -- Becareful!! Record based
 Deleting Events -- Makes all existing event data inaccessible
 Renaming Fields – Creates new variable and hides data
 Corrupting Data Through Enumeration Changes
 Moving to Production Status Too Early
 Exotic Meta-Characters
 Project Account Request Paperwork
 Calculated fields
Questions?
Download
Related flashcards
Create Flashcards