When using the Text Box method of entry, it is best to ensure that the data coming in is the type of data that you are expecting to see. One method of doing this is by employing the Validation option in the field creation screen. By utilizing this feature, REDCap will prompt an error when a field’s entry does not meet certain expectations for data type. There are eleven basic data types that you can designate via the Validation option: date (3 formats), datetime (6 formats), e-mail, integer, letters only, MRN, number (5 formats), phone (U.S.), Social Security Number (U.S.), time (2 formats), and ZIP code (U.S.).
1.) Date: The three different formats you can specify for date are Day-Month-Year, Month-Day-Year, and Year-Month-Day. Regardless of which type you choose, a small calendar icon will be visible next to the field in data entry which you can utilize to easily specify a date in the appropriate format. You can also click the “Today” icon to automatically fill in the current date.
2.) Datetime: Datetime can be recorded with or without a “seconds” count. The three without seconds follow the same formats as the three Date formats (listed above), with an additional H:M to indicate time (Hours:Minutes). The three that do include seconds also follow the same three Date formats, with an additional H:M:S to indicate time (Hours:Minutes:Seconds). Like the Date option, a calendar icon appears next to the field, and in addition, a clock icon appears. You can also click the “Now” icon to automatically fill in the current date and time. An example of usage of the calendar/clock dialog box is below:
3.) E-mail: To validate an e-mail address entry, REDCap checks for a singular “@” symbol and an appropriate e-mail domain ending (such as “.com” or “.edu”). The inclusion of other special characters that would not be a part of valid e-mail addresses (such as “$” or “#”) will also prompt a data validation error. This is very widely applicable, however, if you are expecting e-mail addresses connected to new or uncommon domains, we do not recommend using this validation option.
4.) Integer: Integers include all of the negative and positive whole numbers, plus zero. This means that any decimal or fractional values will prompt a validation error, as well as any values outside the designated minimum-maximum range.
5.) Letters only: This validation type will only accept English alphabetical characters. It will not accept spaces, numbers, special characters, or accented letters.
6.) MRN: This validation type will only accept ten numerical digits, no longer and no shorter. No other non-numerical character is allowed.
7.) Number: This validation type accepts numbers, including decimal values. The five formats are derived from the number of decimal points you choose to allot: 1, 2, 3, 4, or unspecified. If you choose to specify a number of decimal points, an error will be prompted if that exact number of decimal points is not met. For instance, if you have specified two decimal points, an entry of “3” or “3.0” would not be accepted – only “3.00” is considered a valid entry in this case.
8.) Phone: This validation type will only accept a ten-digit U.S. phone number. Not including a valid U.S. area code will prompt an error. It is fairly lenient regarding the input format (spaces, no spaces, hyphens, etc.), but it will change your entry to a standardized “(###) ###-####” format upon field completion.
9.) Social Security Number: This validation type will only accept nine numerical digits separated by hyphens in the appropriate U.S. SSN format. Example: 123-45-6789.
10.) Time: This validation type accepts only HH:MM time format. Like the Datetime type, the clock icon and/or the “Now” icon can be used to assist data entry.
11.) ZIP code: Only five- or nine-digit ZIP codes are accepted. Nine-digit ZIP codes must include a hyphen separating the first five from the final four, or an error will be prompted.
[TIPS AND TRICKS]: Many of the data validation types include an option for setting minimum and maximum expected values. We strongly encourage users to employ this wherever applicable. For instance, if a field asks for the age of a participant, you may want to set the minimums and maximums around your study eligibility guidelines, such as 16 to 55. If you do not have study eligibility rules, it is still a good practice to set relatively reasonable limits, such as 4 to 120.
If you would like for certain questions to appear only under certain conditions, you may employ the REDCap technique “branching logic” to do so. The easiest way to demonstrate branching logic is by walking through an example. Let’s say you are working in your Online Designer, and you are concerned with these two questions:
You only want that second question to appear if the participant selects “No, I have a different data collection or survey tool that I prefer.” Otherwise, the question does not make much sense in context. Because the appearance of the second question (the variable “which_tool”) is dependent on the answer to the first question (the variable “future_interest”), we call future_interest the parent (or independent) question and which_tool the child (or dependent) question.
To begin defining your branching logic, click the branching logic icon (the green arrows) on the child question. The Branching Logic dialog box will appear. You may use either the Advanced Branching Logic Syntax box or the Drag-N-Drop Logic Builder box. For most branching logic uses, the Drag-N-Drop Logic Builder will be sufficient. We do not recommend using the Advanced Syntax box if you have no experience with computer science or programming syntax. If you have a question which you think may require the Advanced Syntax box, please feel free to contact us for assistance or review of the coding.
Simply drag and drop the appropriate conditions for appearance of the child question, being sure to specify whether you want ANY or ALL of the conditions to be true in order for the child question to appear.
Remember, branching logic is only employed on the child question. Since we want our first question to remain static regardless of any other values on the page, we leave it alone.
Survey appearance before choosing any option (or with a non-target option selected):
Survey appearance after choosing the logic-dependent option:
[TIPS AND TRICKS]:
Be sure to thoroughly test any use of branching logic with practice records to ensure that your fields/questions are being displayed exactly as you want them. Recall that the “Preview Instrument” function in the Online Designer will not test branching logic; only actual practice records can do this.
Try not to include too many conditions in your branching logic. Overuse of branching logic can lead to a higher chance of errors.
…….…..Adding a matrix of fields
For some data forms and surveys, the same set of answers may be used for many questions in a row, such as scales indicating frequency or agreement. To fully grasp the “matrix of fields” concept, it may be easier to view an example of a finished implementation before delving into the specifics of the set-up:
Setting up the matrix is essentially writing many questions at once, all of which use the same set of answers. As such, there is only one section to define column choices, but there are many field labels, each with their own variable names and requirement statuses. You may add as many rows as necessary for your matrix.
There are two answer formats for matrices of fields: Single Answer (Radio Buttons) and Multiple Answers (Check-boxes). For most matrices, Single Answer will be the preferred format.
A matrix group name must be provided. Its naming mechanism is similar to the general variable naming mechanism. The group name itself is basically a coded value which ensures that no matter what display platform the matrix goes through, all of the rows will be displayed together in a single matrix.
[TIPS AND TRICKS]: When exporting data, it will be easier for your data manager to keep track of matrix fields by assigning each field’s variable name the same short prefix, such as “mtrx_” or “eval_”.
The Shared Library can be accessed from the home page of your Project Setup.
[TIPS AND TRICKS]: If you don’t find the results you want from your first search, be sure to search for synonymous and/or related keywords. For instance, if you search “education” and don’t find any relevant results, try “academic” or “school.”
For large or repetitive projects, you may need to make large-scale changes to your forms that would be difficult or tedious to perform with the Online Designer. The Data Dictionary is a CSV file version of your project, and serves as an efficient way to make large-scale changes using (usually) Excel.
To begin making changes to your project using the Data Dictionary, click on “Upload Data Dictionary” on the home page of your Project Setup. It will prompt you to download the current Data Dictionary so that you can make changes to it. Here is a sample excerpt from a Data Dictionary (with the columns expanded for readability):
Large-scale changes made easier through the Data Dictionary may include copying many fields (rows) into another form. For instance, if you wanted to copy rows 3 through 13 into form_2, you would simply highlight rows 3 through 13 in Excel (the entire rows), copy, paste into the appropriate position (ensuring you did not paste over any other rows), and change the Form Name (column B) to “form_2” for the newly pasted rows.
To re-upload the modified Data Dictionary, save the CSV file and re-upload it back in the Upload Data Dictionary window. If REDCap notices any syntax errors it cannot read, it will prompt an error message alerting you to the issue. If there are no errors, it will ask for confirmation, ensuring that you know the new Data Dictionary will replace the old Data Dictionary (not append to it).
[TIPS AND TRICKS]:
Remember, the Data Dictionary does NOT contain any of the information from any of your practice records. Changing information in the Data Dictionary can sometimes affect information in the records (deleting fields, for instance), but it will not erase the records or corrupt the data.
If you are making large-scale changes using the Data Dictionary, it may be helpful to save separate copies of your old Data Dictionary in case you discover any errors later on after uploading it (for instance, if you mistakenly deleted several fields that you did not intend to delete).
An important part of any project, big or small, is the testing phase. Whether you are using surveys or traditional data entry, REDCap allows you to create practice records to test the full function of your forms. This is especially crucial for testing branching logic, calculated fields, and survey appearance (if applicable). For more information about practice records for surveys, see the Survey-based studies section.
Once you are in the main “Add/Edit Records” page, you may choose an existing record to edit, create a new record by typing in a new Record ID, or search for a particular record by a field value (for instance, using the search field “Name” and typing “Jane Doe” into the search query). If you are employing multiple Arms in your study, the first two options sort the records into groups by Arm. To search for a record whose Arm you are not certain of, using the Data Search option is best.
If your study is not employing multiple Events (i.e., if it is not a longitudinal study), your first data entry form will appear immediately, ready for data input. If your study does employ multiple Events, you will see a screen similar to the one above. Records are edited one Event at a time; clicking on the first form of an Event and filling it out will lead you through the forms assigned to that specific Event and then return you to this screen. To learn more about longitudinal studies and Events, see the Longitudinal studies section.
At the bottom of your data entry form, you have the option to mark the form as Incomplete, Unverified, or Complete. Incomplete forms will display a red icon, which is the default status for all forms in a new record; the yellow icon indicates Unverified, and green indicates Complete.
Clicking “Save and Continue” will save your progress and keep you on the current page. Clicking “Save and go to Next Form” will save all data and take you immediately to the next form for that record. Clicking “Save Record” will save all data and return you to the “Add/Edit Records” main page. You may also lock forms for a record to prevent other users from editing existing information.
The most important thing to remember about practice records is that they are intended for practice. This means that no real data should ever be entered into REDCap while your study is still in Development mode. Real data entry will occur once you deploy your project into Production mode, where your forms are finalized and data is more securely protected.
[TIPS AND TRICKS]: In your data entry screens (not including the survey submission screen), there is a small “H” and speech bubble appearing beside each field. The “H” tracks the history of all recorded data values for that particular variable. The speech bubble is the Field Comment Log, which allows users to make comments on particular fields, and lights up when a comment exists for a field.