Now that we've covered what a finished database will look like, let's see how you actually set one up. The majority of your database creation is going to be done in the Online Designer. Here you have a list of all the instruments, or forms, in your project. REDCap uses the terms "instrument" and "form" interchangeably. If you need a brand-new form, you can hit the create button to create an instrument from scratch. You can use the import button to pull in an instrument from the REDCap shared library. The REDCap shared library is a collection of instruments put together and monitored by one of the groups in the REDCap consortium. Any instrument that has a red star next to it is a validated instrument that has gone through a significant screening process to ensure that it is both free for use and that it has been translated accurately from paper to electronic format. If you're using a validated instrument that is relatively common and open to public use, you might want to check the REDCap library before you create it yourself so you don't have to reinvent the wheel. You can also potentially upload an instrument from another project.
Once you've created your instrument, you go into it to make changes. To create a new field, you'll click on the "Add field" button. To edit an existing field, you'll click on the pencil icon. There are many different types of fields that you can use in a REDCap project. A text box and a notes box are both used for entering free text. The text box is simply a line where a notes box is paragraph shaped. They both have a very high character limit. Calculated fields are doing calculations. You have your three types of multiple choice questions; yes/no and true/false; an e-signature field; a field where users can upload files; a slider field; a field for descriptive text, where you can simply write out instructions or where you can add an image, or video, or an audio, or a file attachment; and the section headers, which are the yellow bars that break up the text.
The field label is where you type out the question as you want it to be seen on the data entry form or survey. So this is the long question, like, "Please tell us your age" or "How many packs of cigarettes do you smoke in a week," or "When were you diagnosed with diabetes?" The variable name is a short, alphanumeric name that you'll use to identify your field on the back end when you're doing analysis. It is also how REDCap identifies your variable as something unique. This should be something relatively short and meaningful enough that when you're doing your analysis it makes sense.
You also have the option to validate your text fields. If you want people to simply enter words in your text field, you won't need to validate it. But for most other kinds of text fields you will. For example, if you're using dates you'll need to note the date format or the datetime format. You can validate email fields; fields to be integers only; letters only; a number, to multiple decimal places; a phone number; a postal code or zip code; a social security number; or a time. There are two reasons you validate a field. One is that a validated field won't accept a different type of data, so it helps prevent data entry errors. The other is when you do your backend analysis, if a numbers field (for example) hasn't been validated, it will export as text. Meaning that if you sorted on that, it would sort as 1-10-11 instead of 1-2-3-4-5. The validation would then have to be manually changed on the backend. Validating it correctly up front saves a lot of time and effort. So, as this is an age field I'm going to validate it as a number.
The minimum and maximum are providing an expected range for the field. I expect my participants to have an age between 0 and 70. These are soft validations, meaning people can enter other values, but they'll get a quick popup letting them know they might need to check their answer.
You can make a field required. On a data entry form there will just be a prompt that this field has been left blank. On a survey form participants will not be able to move on until they provide an answer in the field. You can mark the field as containing potentially identifying information, like name, birthday, address. You can give it a custom alignment, which just says where the box or multiple choice answers appear in relation the field label, and you can give it a field note, a small textual reminder that displays underneath the field exactly like "The small reminder text displayed underneath a field."
For multiple choice fields you'll select which of the three multiple choice fields you want. Then you'll give it a field label and variable name exactly like you did in the text question, but there's a new box as well, where you assign your choices. These will appear one per line, and they're where you put all your potential answer choices. If, partway through your study, you decide you want to add an answer choice in you can do so at any time. What you should not do is renumber your answer choices. So if I wanted to add the field "drama," I should not do it like this. If I try to do that, anything that was science fiction is now going to read as drama. Anything that was comedy is now going to read as science fiction, and anything that was romance is now going to read as comedy. You should never recode your variables. Instead, just pick the next number on the list. The order of these coded choices doesn't matter; it just matters that they're unique and you don't change it.
Another very common thing is wanting an N/A or Other answer choice option. It's considered best practices in data circles to give them a pick number, usually two or three digits like 88, 99. This sets it apart from the rest of your answer choices. If you have multiple choice questions that all have the same answer choice, you don't have to type it out every single time. Instead, you can go to "Copy existing choices" and find the example of the one that matches how you want it to look and click use. This way you keep your coding consistent across all your multiple choice fields, which helps prevent errors when you're doing your analysis. It can also save you some time.
Dropdown fields have one small difference compared to radio buttons or checkbox fields. In the dropdown fields, you have the option to enable autocomplete for the dropdown, so that as people are typing it tries to autocomplete the answer for them.
Next, we're going to talk about slider fields. Creating a slider field is done in the same basic way as all the other fields, with the small difference of instead of displaying answer choices, like in a multiple choice question, you just provide labels for the different points in the slider. You do not have to put in labels, and you do not have to fill in all the label fields if you don't want to. Slider fields are scored on a 0 to 100 scale, and you can also choose whether or not the person entering the information can see that number value. Custom alignment can also be a little bit more interesting with slider fields because you can make them horizontal, like it was, or vertical.
Next we have descriptive fields. Descriptive fields have the same field label and variable name setup that all the other fields do. If you're using the descriptive field to provide instructions, you'd put them into the field label. You can also use the descriptive field for file attachments. Here, I have a picture uploaded, and I have it displayed inline so that it's automatically seen when the person loads a page. If I wanted to, I could change that to a link where instead people can easily download the picture. This is great if, for example, you want your participants to be downloading a consent form. You can also embed audio files that people could then listen to or download. Or you can link to an external video, such as a YouTube video. Doing this is very easy--just find the video, wherever it's hosted, and paste the URL in. Again, you can choose if you want it inline like the picture was, so you can simply see it and play it as you're filling out the form, or you can put it inside of a popup. If you do this, people click the button and they get a popup window to let them play it.
The next kind of field is a yes/no field. We actually recommend that you don't use the yes/no or the true/false, which has the same setup. The reason we suggest this is because the choices are hardcoded with the 1, Yes/0, No or 1, True/0, False that's very common in data management. However, it's fairly frequent that partway through the project two answer choices are no longer considered sufficient. In that case, you have to go and change this to a multiple choice field, and then what happens is people often end up coding it like this. Now everything that was true now says false. All my false answers are lost, and I have to start from scratch with my new true and my N/A fields. It can save a lot of time and make life a lot easier if you just create your yes/no fields as multiple choice questions to begin with, so you never have to worry about accidently overwriting the coding.
File upload fields are where a participant or data enterer can upload their own document. All these have is a field label and a variable name.
Similarly, the e-signature field is simply a field label and a variable name.
The final kind of field that we're going to go over in this video is a section header. Section headers are those yellow bars that just help break your form into more easily manageable chunks and let people know what's coming up in the next group of questions. These don't even have a variable name you have to worry about, simply a field label. The other thing I want to show you here is how I've used a little bit of HTML to change the color of the text and to center it. You can use HTML in a lot of different kinds of REDCap fields, such as field labels, the answer choices, or in survey invitations. All I've done here is google the HTML coding for blue and then told it to center it. This way the text comes out as blue and centered.
Those are the most basic features of the online designer. In the video, we'll go over some of the more advanced features.