1 MBREDCap Best Practices 12-Aug-14

REDCap Best Prac/ces

ITHS Biomedical Informa2cs Core [email protected]

1

Last updated August 12, 2014

REDCap version: 5.10.1 Bas de Veer MS Research Consultant

Goals & Agenda Goals •  Understanding Advanced Features •  Best Prac2ces

Agenda • Randomiza2on • REDCap-‐Amalga Bridge • Dynamic SQL links • User Right Management • Study Design • Form Design • Surveys

2

Randomiza2on

3

Randomiza/on What’s randomiza2on? Divide your study par2cipants in 2 or more groups without bias. REDCap offers: •  Stra2fied Randomiza2on •  Randomiza2on by Group/Site •  Granular User Rights

4

Randomiza/on How does it work? •  Ac2vate the Randomiza2on feature •  Select your op2ons & Randomiza2on Field –  Create the Randomiza2on field on the first form

•  Set up Alloca2on Tables –  Contact a Bio-‐sta2s2cian –  Development VS Produc2on

•  Define User Rights •  Start Data Collec2on & Randomize •  Monitor the Randomiza2on Process

5

Randomiza/on User Rights 3 SeZngs •  Setup •  Randomiza2on •  Dashboard Notes: •  Rights are independent of each other •  Useful for “blind” studies •  Randomiza2on right trump form level rights

6

REDCap – Amalga Bridge

7

REDCap-‐Amalga Bridge What’s Amalga? •  Clinical Data Warehouse for UW Medicine –  Outpa2ent (EPIC) –  Inpa2ent (ORCA) –  Labs –  ADT – Many other clinical systems

•  NOT Instantaneous •  Reports Require AMC Account •  Strict Direct Access Policies •  DCDR (De-‐iden2fied Clinical Data Repository)

8

REDCap-‐Amalga Bridge •  Import Clinical Data directly into a REDCap project –  One-‐2me –  Update on a Regular Basis –  Based on your Iden2fiers

•  Import REDCap data into Amalga –  As Source Data for your Amalga Query –  To Generate a Custom Report –  Do Advanced Calcula2ons/Manipula2ons

Notes: •  Have an IRB in place •  Requires Development Time from the BMI Consult Team

9

REDCap-‐Amalga Bridge Repor2ng Example

10

REDCap-‐Amalga Bridge Example

REDCap

Study Database

Secure Hospital Compu/ng Environment

Custom C#

Library

Study Data Secure Report

REDCap-‐Amalga Bridge

11

REDCap-‐Amalga Bridge Example

REDCap Secure Hospital Compu/ng Environment

Iden/fier Database

UW* Clinical Data

Repository

Custom C#

Library

Query

Query Results

Study Database

Pa/ent Name, MRN

Study Data

* University of Washington

Dynamic SQL Link

12

Dynamic SQL Link Rela2onal Database •  Mul2ple tables •  Cross links (Primary keys) •  Example: Access Database

En2ty-‐Aeribute-‐Value Database •  1 Big Flat File •  1 Record per Row •  Example: Single Excel Spreadsheet •  Example: A REDCap Project

13

Dynamic SQL Link •  Special Dropdown Field •  Populate by a Custom Code (SQL) –  Other REDCap projects –  Special Tables

•  Consists of: –  Raw Value –  Label

•  Single Value •  Combined Values

•  Only available to a REDCap Administrator •  Filters Can be Applied

14

Dynamic SQL Link Limita2ons •  Only Editable by a REDCap Administrator •  Data Dic2onary will NOT upload when you: –  Change the Posi2on of the Field –  Edit the Label –  Edit the Variable Name –  Edit the SQL Code

•  Cost 200 Dollars per Link •  Only to Projects You have Access to

15

Dynamic SQL Link Adverse Events Example: •  Longitudinal Studies •  Unknown Number of Adverse Events Example Solu2on: •  2 Projects (Main Database & Adverse Events) •  1 Record per Adverse Event •  D-‐SQL used to link to Main Database –  Raw Value: Main Database Study ID –  Label: MRN, Last Name, Date of Birth

16

Dynamic SQL Link Iden2fica2on Database Example: •  Need for a Separa2on of PHI from Study Data •  Don’t Want to Go the “Excel” Route

Example Solu2on: •  2 Projects (Main Database & Iden2fier Database) •  1 to 1 Record Matching •  D-‐SQL used to link to Iden2fier Database –  Raw Value: Iden2fier Database Study ID –  Label: Iden2fier Database Study ID

17

Dynamic SQL Link Applica2on VS Reviewer Example •  Applica2on Survey & a Reviewer Survey •  Prevent Transcrip2on Errors •  Mul2ple Reviewers for Each Applica2on

Solu2on: •  2 Projects (Applica2on Project & Reviewer Project) •  Mul2ple Review Surveys per Applica2on •  D-‐SQL used to link to Applica2on Project –  Raw Value: Record ID Applica2on Project –  Label: Last Name, Applica2on Title (limit to 1st 35 Characters)

18

User Rights

19

User Rights Basic Applica2on Access •  Limit to Only Necessary Applica2ons Rights •  Keep the User’s Role in Mind •  Op2ons Depend on Ac2ve Features •  Take Special Care with: –  Project Design –  User Rights –  Data Export Tool –  Data Import Tool

20

User Rights Locking •  Useful for Bigger Projects •  Safe-‐Guard Data Integrity •  Mul2ple Data Entry Users •  Use in Combina2on with the “Unverified” Tag •  E-‐Signature Does NOT Work

•  Lock Records –  By Form –  En2re Record

21

User Rights Form Restric2ons •  Limit Form Access to Specific Users or Roles –  View & Edit –  Read Only –  No Access –  Edit Survey Responses (Semi-‐Independent)

•  Useful for Complex Studies

22

User Rights Data Access Groups (DAGs) •  Users in a DAG Can Only See Records Created

by Members of that Same DAG •  Excep2on: Users Without a DAG •  Useful for: –  Double Data Entry –  Separa2ng Different Sites

•  Records Without a DAG Assigned: –  Done by User Without a DAG –  Top Right Corner of Any Form of a Record

•  Users Can Only Export Records in Their DAG

23

User Rights Roles •  Can Be Created by Users With “User Rights” Rights •  Quickly Assign Pre-‐Defined User Rights •  One Time Setup Per Role •  Roles Are Editable •  Removing a User From a Role –  Copies the Role’s SeZngs to the User Un2l:

•  A Manual Edit •  The User Is Assigned to a Different Role

24

User Rights Best Prac2ces For User Roles: •  User Control •  Design Control •  Data Entry •  Reviewer •  Research Coordinator •  Project Manager/PI •  Sta2s2cian

25

Study Design

26

Study Design Consider SpliZng Up Forms in These Situa2ons: •  In Development Mode •  Longitudinal Studies •  Scoring Tools (FACT-‐L, Glascow, etc)

Notes: •  Overview •  Contained Modules •  More Frequent Saves •  Flexibility in Workflow Design •  Easily Undone Via Data Dic2onary

27

Study Design Variable Names: •  Short & Consistent •  Lower Case •  Decipherable •  Codes For Repea2ng Variables (Shorthand) –  Sequen2al –  Context Based

•  Consult Your Sta2s2cian Examples: Medica2on Number 1 In a Follow Up è rxfu1 Eligibility Ques2on Number 4 èeligq4

28

Study Design Record ID’s in REDCap: •  Always The 1st Variable In The 1st Form •  Used By REDCap to Link Variables to a Record •  Turn on Auto-‐Numbering •  Create a Second Unique Variable For Your Study ID

Duplicate Record ID’s cause: •  Analysis Errors •  Export Errors •  Back-‐Up Errors •  Screw-‐up Advanced Features

29

Form Design

30

Form Design Try to Design Your Variables as Granular As Possible: •  Easy to Go Less Granular •  Harder to Go More Granular •  Consider The Smallest Measurement Unit •  Makes Unexpected Analysis Paths Easier

Examples: •  Age (Category vs Years vs Months vs Days) •  BMI (Split it out in Height and Weight) •  Blood Pressure ( Normal vs Diastolic/Systolic)

31

Form Design Calcula2ons: •  Shorter Is Beeer •  PEMDAS is Your Friend •  Match Up Those “Parentheses”. •  For Advanced Func2ons è FAQ •  Calcula2ons Can Only Produce Numbers or “NaN” •  Calcula2ons Don’t Run Automa2cally •  Calcula2ons Can Produce An Outcome

Without All The Variables Filled Out (When Using Logic) •  Use Excel For Quick Troubleshoo2ng

32

Form Design Cascading Calcula2ons •  Is Allowed, But Not Advised •  Can Be Hard To Troubleshoot •  No Limit On Length Of A Calcula2on

Example: [calc1] è [var1] + [var2] [calc2] è [calc1] + [var3] [calc3] è if([calc2]<[var4],[var3],[var5])

33

Form Design -‐ Branching Logic Branching Logic •  Keep It Short •  Put Parentheses Around Everything •  Limited Java Func2ons Allowed è FAQ •  Make Use of Nested IF Statements •  Try to Keep Your Logic “Local” •  Be Aware of Radio Bueons VS Checkboxes –  [var1] = 1 –  [var1(1)] = 1

•  Diagram Your Logic •  Cascade Your Logic When Possible

34

Form Design -‐ Branching Logic Logic Diagram Example:

35

OR OR

IF([var] = 1 True False

[var2] = 1

[var3] = 1 AND

[var4] =0

[var5(2)] = 1

[var5(3)] = 1 AND

[var6] = 0

Form Design -‐ Branching Logic Actually Syntax: If([var1]=1,(([var2]=1) OR ([var3]=1 AND [var4]=0)),(([var5(2)=1) OR ([var5(3)]=1

AND [var6]=0))) Split Out: If([var1]=1,

( ([var2]=1) OR ([var3]=1 AND [var4]=0) ), ( ([var5(2)=1) OR ([var5(3)]=1 AND [var6]=0) )

)

36

Form Design -‐ Branching Logic Variable is Empty Trick Useful for: •  Cascading Logic •  Delaying a Field Un2l Everything Is Filled Out Syntax: [var1] <> ‘’ Notes: •  Double Quotes Do Work, but might mess up Excel •  Use Two Single Quotes Without a Space In Between

37

Form Design -‐ Branching Logic Cascading Logic – Medica2on List Example List of 6 Medica2ons (rx1, rx2, rx3, rx4, rx5, rx6) Branching Logic Example: rx2 è [rx1] <>’’ rx3 è [rx2] <>’’ rx4 è [rx3] <>’’ rx5 è [rx4] <>’’ rx6 è [rx5] <>’’

38

Form Design -‐ Branching Logic Cross Event Branching Logic Depended On: •  If A Form Is Repeated •  If Your Study Is Longitudinal •  If Your Target Variable Is In Another Form Notes •  Event Name Is Located In “Define My Events” •  Try To Use It For All Your Logic In A Longitudinal Study Syntax Example: [event1][var1]=1

39

Form Design -‐ Branching Logic Hiding Fields Instead Of Dele2ng Or Edi2ng Fields •  Good Form •  No Data Loss •  Easier/Quicker To Create A New Variable •  Create An Impossible Scenario That Is Never True •  Old Choices Are Kept (In Case Of A Mul2ple Choice Edit) Syntax Example: [record_id]=‘9999999’

40

Form Design -‐ Piping Variables

41

•  Display Entered Variables •  Field Labels •  Survey Invita2ons •  Survey Thank-‐You Message

•  Piping Syntax •  Original Variable Name “first_name” •  [first_name]

•  Example •  First Name Value = “John” •  Syntax in Thank-‐You Message = “Thanks, [first_name]!” •  Becomes = “Thanks, John!”

Form Design Raw Value Choice Coding (For Mul2ple Choice Fields) •  Try To Use A Numeric Value –  Easier To Analyze –  Shorter Logic/Calcula2ons –  Less Change Of Typo’s –  Reserve Room For Addi2onal Choices

•  When Using a Non-‐Numeric Value Try To: –  Keep It Short –  Avoid Comma’s –  Do NOT Include HTML Tags –  Use It For Piping Of Non-‐Numeric Values 42

Surveys

43

Surveys

44

Four Main Ways of Distribu2ng Surveys: •  Public Links •  Personalized Invita2ons •  Automated Invita2ons •  Survey Queue’s Bonus: •  Fill Out a Survey as a User

Surveys

45

Managed Through the “Manage Survey Par2cipant” Link Public Links •  Ideal For Recruitment •  Ini2ally Anonymous •  Can Be Filled Out Mul2ple Times •  Auto-‐generated by REDCap (Short Link Available) •  Only Available For the First Survey of Each Arm Personal Invita2ons / Automated Invita2ons •  Email Required •  Inherently Iden2fied •  Traceable Comple2on Rates •  Customizable Invita2ons •  Ini2al invita2ons only available for the first survey of each arm •  Follow up surveys can be distributed through automated invites

Surveys Public Surveys – Best Prac2ces •  Be Honest About:

–  Time Required –  Number Of Ques2ons –  Number Of Possible Follow Up Surveys

•  Be Brief –  Links Are Always An Op2on –  Keep It Simple

•  When Able Collect: –  Email (For Future Follow Up Surveys) –  Mul2ple Unique Iden2fiers

•  Monitor Responses –  Use No2fica2ons

46

Surveys Personal Invita2ons – Best Prac2ces •  Validate Emails Beforehand •  Monitor Response Rates •  Send Reminders Manually •  Make 1 User Responsible •  Use Par2cipant Iden2fiers •  Be Prepared To Deal With Spam Filters – Message Craying –  Follow Up A Subset Of Non-‐Responders

•  Be careful with DAG’s –  User should NOT Be Part Of A DAG For Best Results

47

Survey Queue •  Found in the Online Designer •  Populated by Forms & Events •  No Email Required

48

Survey Queue Survey Queue’s •  Daisy-‐Chain your surveys •  Shorten Branching Logic •  Save & Return Op2on through Survey Queue Link •  Auto-‐Start Feature •  Define Paths based on Par2cipant Input

–  Male vs Female surveys –  Follow Up Ques2ons

•  Split Up Forms for Greater Flexibility –  Complex Studies –  Longitudinal Studies

49

Surveys Automated Invites – Best Prac2ces •  Draw A Workflow Map •  Check Your Trigger Logic – Make Sure You Use The Correct Cross Event Logic

•  Check Your Time Delay •  Always Do A Test Run •  Be Prepared To Deal With Spam Filters •  Set Up A General “From” Email For Your Study –  Use Your Secondary of Ter2ary Email In Your Profile

50

Fire & Forget Example

51

Intake Dona2on Form Public Survey Link Includes email field

Includes “Choice” Field

“Whole Blood” Form Private Invita/on

“White Blood Cells” Form Private Invita/on

“Plasma” Form Private Invita/on

Follow Up Form Private Invita/on



Time Delay Time Delay Time Delay

Choice A Choice B

Choice C

Survey Queue

Automated Survey Invita/ons

Learn How To Use REDCap INTRODUCTION TO REDCAP •  WHEN: (once a month) •  WHERE: South Lake Union •  See: heps://www.iths.org/redcap-‐class-‐schedule ADVANCED CLASSES •  See: heps://www.iths.org/redcap-‐class-‐schedule

ONLINE VIDEOS & HELP •  REDCap Training Resources •  FAQ •  Supplemental Documenta2on

ONGOING HELP •  EMAIL: [email protected] (REDCap community email list)

•  EMAIL: [email protected] (REDCap administrators; last resort for help)

52

Future Advanced Classes

53

• Data Dic2onary -‐ Impor2ng and Expor2ng Data

• User Rights – Randomiza2on – Best Prac2ces

• Advanced Longitudinal Studies & Surveys

Schedule and Loca2ons will be on the ITHS website & will be announced in email to users.

hips://www.iths.org/redcap-‐class-‐schedule

1 MBREDCap Best Practices 12-Aug-14

Documents

Transcript of 1 MBREDCap Best Practices 12-Aug-14