1 / 23

Avoiding Common Pitfalls in REDCap

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.

kamran
Télécharger la présentation

Avoiding Common Pitfalls in REDCap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Avoiding Common Pitfalls in REDCap By J. KevanEssmyer Special Thanks to Jack Baty

  2. REDCap Goals • Easy to use • Metadata Driven • Adaptable Features • Data entry validation • Self service tool

  3. Public HTTPS Access Biostatistics Secure Domain Tiresias Server File Server https://redcapsurvey.wustl.edu... REDCap Survey MySQL Server Uploaded Files Authenticated Access Data Sync WEB Server WUCON Data Entry /Admin MySQL Slave Server Data Entry /Admin Installation Files Sidedoor Server Host Server

  4. Project Creation Flow Chart Move to Production Status on Production Server and start Data Collection Move to Production Status and start Data Collection Create Project –Project Name, Longitudinal or Cross-Sectional/ Survey Excel Spreadsheet Or Online Form Designer Test Forms Define Study Events (Longitudinal) add Schedule (optional) Data Entry Forms Add Users and Set User Rights

  5. 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)

  6. 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

  7. 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

  8. 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

  9. Target Form Forms Actually Deleted

  10. Target Form Delete Record button located at bottom of REDCap forms Forms Actually Deleted Feature should be turned off when not needed

  11. 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

  12. 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.

  13. Old variable name Blood_draw 1/20/2011 New variable names Blood_draw_1 Blood_draw_2 Blood_draw_3

  14. 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=Kevan2=Jack • Choices will show in the order declared rather than numeric order. • Danger -- Overwriting Choices • 1=Yu 3=Bobby 2=Jack • Safer Option • 1=Yu 3=Kevan2=Jack 4=Bobby • Better Option -- Overwriting Choices • 10=Yu 20=Jack 25=Bobby 30=Kevan

  15. 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.

  16. Branching logic warning about hiding existing data Can be a dangerous situation and is best avoided.

  17. 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;

  18. 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.

  19. 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)

  20. “?!!?” Branching Logic Data Validation User Rights API Data Dictionary Scheduling

  21. REDCap Lifelines • Built-in tutorial videos • Built-in Frequently Asked Question (FAQ) guide • Demonstration Databases (Some Online, more to come) • WUSM BiostatREDCap Email Help Queue • [redcap@rt.biostat.wustl.edu] • Monitored by 4 to 5 Administrators

  22. REDCap Email Support redcap@rt.biostat.wustl.edu

  23. 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?

More Related