As you can see here, the REDCap Shared Library is a global repository of data collection instruments, that have been curated and preloaded into REDCap. Into a common repository that can be accessed via other inst-, all institutions that are running the REDCap platform. We're pretty careful about what gets in there. It's well curated, it's, validated instruments only, and we get permission from the instrument owners. So there's a lot of things that are not in that library. But, if you're doing a study, and you have something in mind, it's always a good idea to check there first. Because it'll save you a lot of time and everything's already coded into that REDCap format. So you just click here, that's going to launch a page, it actually goes back to our public REDCap consortium site. this is where people learn about the software, learn how to become a partner. they, they can look at all of the different groups that are using it, but this Library tab, this Library tab allows sort of special functionality and if, and only if, you're coming from a REDCap Install, there's a set of functions and features that are going to happen for us. So, we'll type in anxiety. We notice that the PROMIS short form for anxiety is there If I wanted to look at it, as if it might look in REDCap, I can click there. I could view it as a PDF if I like. That would that would require me to, agree to some terms of use, which we'll also have to in the next example. But if I really just wanted to bring it over into my REDCap project right now I click that button. Take a look at the lengthy Terms of Use and the set of information about the, the, the, the fact that this is in this shared library. But if I agree with that Terms of Use, I just click the button down here. I click I agree and then it's going to take that metadata, that data dictionary, and it's going to bring it back to my local version of REDCap, the one I left to get there. It's going to recognize that now you're in the process of importing an instrument. And it asks you what to call it. So we'll just call it PROMIS Anxiety Data and we'll click the Add button. If I return to the previous page, now that you're going to see now, now that you'll see that we have that instrument in and it's just as if we had coded it up. I will move it, just by clicking and dragging over there to the left just as we've moved fields before. And now I've got three data collection instruments, in for my project. So at this point we're pretty good on our data collection instruments. And let's go back to the Project Setup and see what's left. We've checked off that we completed our main project settings. We think we've done a pretty good job now on the data collection instruments. We can always go back there again and we can edit and modify in any time that we want. Especially before we push it into production mode. But before that we say that we're finished here, let's click this little Check For Identifiers tab. We've seen a little of the identifiers earlier on when we were creating the case report forms, but sometimes we forget we forget to take tick them off, and again it makes a big difference when we get into the export functionality. So, we have a little function that that really sort of scours the variable names and field labels from the different field, fields on the case report forms. And it will propagate those up with a reminder that, you may not you maybe right or you maybe wrong, but here is a few that, that might look like identifiers to the REDCap program and you have the final choice but, in this case it looks like the person identifier should have been checked. The, the dates of service need to be checked. Date of birth should be checked. so we'll leave ethnicity alone. But, but it looks like it's caught a few that we did not catch as we went along. So that's good. And it goes just behind the scenes and it it, it, it's just as if I've got to each of those forms, each of those fields and clicked off on that identifier toggle button. So, at this point we've checked for identifiers, we're going to say I'm done here with the data collection instruments. And now we need to think about the timing. We said that this was a longitudinal data collection project. We'll be using the same form multiple times. So the first thing we'll do is, we'll define our events for our study. Before we do so, we need to go back and remind ourselves a little bit about the study conditions. Remember, we said we would have a baseline visit where we would screen the individual and get some non drug related thermal measurements. We would wait approximately three days and do another set of measurements after they've received the drug combination or drug cocktail. And then we would do that on out through visit four. The REDCap Define My Events module is a pretty simple model of adding in events expected for the volunteers participating in the study. We can put as many events as we want. We would specify a number of days offset from the very beginning. In this case the baseline visit. And, if we wanted we could even provide some flexibility around offset range, that was that was allowable for this particular study. We won't do that here. If it were a complex study, we could also add arms and, and add as many arms or cohorts as we wanted for the particular study. But in this case, it's a pretty simple study so we'll just add here in the beginning, a baseline visit. That's going to be, again, days offset zero. Three days later, we will have Visit 1. We'll leave alone the offset range and just assume that we, we have the flexibility, the schedule as we need to, rather than having the computer check on us. Second visit will be at six days after baseline. Third visit will be nine days after baseline. And Visit 4 will be twelve days after the baseline visit. We have a final visit there, as 15 days after the baseline visit. So now that we have the visit schedule set up for individual patients, as they come through the study, we're just about ready to go. I should note again, that this day's offset, we're going to be flexible on this particular study. We'll be able to deal with things like weekends, and holidays and, and reschedule accordingly. But, now that we have these in, we're really in pretty good shape and ready to go with, with the next step, which is designating the instruments that will be used on each of the individual events. So here we have the case report forms and the instruments already defined. And we've got the visits that have been identified in the last step across on the horizontal. So at this point, we just begin editing. We say that hey the baseline visit, we're actually going to have all three of those data instruments used. We won't give the drug combination on that first day but we still want the measurement on that first day. That way, we have that sort of no drug as, assessment of their pain threshold. After that first visit, or the baseline visit, we really don't need the demographics or the PROMIS Anxiety Data again, so we'll just click that we want just the Thermal Data on those particular visit days. So now I have got a grid of all of my days versus all of my instruments And, and everything's set up so we'll come back here and say it's all complete. So at this point, we'll look at some other optional modules and customizations that you, we could make for our REDCap database. we have the opportunity to enable auto numbering for records. We've already gone through the, record identify, identification piece for this particular study. We're just going to have a unique number assigned to each patient that comes through. We won't have the database auto number for us. We've been setting up temporal events for a longitudinal study. if we click off here it will allow us to use the scheduling module. this will allow us to sort of have participant calendar that, that's common across the whole study. We can either choose that for a longitudinal study, or we can, we can leave it off and not have REDCap handle the, the calibrating and scheduling. But in this case, we'll say sure, we, we'll enable that option. There's a randomization module in REDCap. in this particular study, we don't need any type of participant randomization. That's going to be done early on in the whole study. we, we've said we would make that assumption earlier. But if we have a complex study that needed randomization we could read about it here and we could implement it on a study by study basis. If this study was using surveys, then we could choose, choose an additional option here to designated e-mail field for, for re for, for re-invites for the same survey participants. And then we got a number of opt, optional customizations that can be done. Setting a custom record label is kind of a nice idea, unless we do that as we look for information about our individual participants, we're going to be searching for them by their record ID. By applying this custom record label, where we're able to use some of the fields that we've identified for this particular REDCap project, we can, we can sort of concatenate those together and, and have it used as a label. Just a good sanity check or you know, nice, nice feature or function for your research coordinator, or your data entry folks. In this case, I remember that we did use data fields for last name and first names in that demographics form. So we'll just use this exact example here. Typing it in exactly in that syntax, and what we'll find is that When we get into the data collection forms we'll see that, any time we're looking at a case report form for an individual, it will automatically bring that record label together, and we'll be able to see that. Again, even though it's a cocottonation, concatenation of data across multiple fields. We could define a secondary unique field which we'll skip here. We could order the records by another field if we'd like. The enable comment logs or data resolution would allow us to have comment logs within the particular study. We could even go full boat on it and get quite complex and ask for formal data query functionality. In this particular case, we will just leave it alone for now. There's a history widget that will show up as a little h next to each of the data fields in each of our case report forms. And clicking on that will allow us to see who did what, when, to that data element at any time. We've already seen the, display the today now button for all dates. that's that's automatically, checked by default. But if we don't want to see that we could always uncheck that as a, as an option for our particular study. And then, finally, there's a an option for complex study, maybe for regulated, regulated studies where we might require e-signatures or might require a reason when making any change to the database and so we could toggle that one on, if we wanted that functionality. At this point, we'll just save, and we'll say that we've, we've enabled all of the optional modules and customations that we, customizations that we want. Again, we could always go back at any time. [BLANK_AUDIO] So, moving along, if we desire, we could set up project specific bookmarks for each of our studies. Basically all that means is we can set up links that live over on the left hand side of the menu. Those would be available to link out to other sites and they would be accessible by the users for this particular project. So it might be to other information or to lists of static SOPs or, or really anything that you desire. They are optional and we're just going to ignore that function for this particular project. We do need to look at the user rights and permissions, before we start thinking about launching our study. So if it's a single site study, we'll probably just going to use the user rights tab here. If its a multi sites study, we might set up a use the data access groups functionality. This would allow us to put individual users into individual access groups. So you might have multiple institutions with individuals belonging to the access groups for those institutions. They would be able to see their own data. But they wouldn't be as, see, be able to see across to other institutions data. Again this would be only if you were hosting a multi-center study within a single version, or single install of REDCap. That is not the case here, so we're just going to move into the user rights page as if we were setting up a single study. Here we can add new users, we can add those users to have custom rights, to be able to do certain things but not other things on the study. We can also add users and assign them to roles. roles are always a great idea, and allow you to sort of standardize things. So here we're going to create a new role, called data entry role. We're going to come here to this next page and we're going to see among, along the left hand side that we can dial up or down access to individuals assigned to this role to many of the functions and modules that we've already seen along the left hand side of the screen. We can dial this up or down, based on either an individual or in this case, a role. [BLANK_AUDIO]. That includes, giving users the ability to have access to all of the different modules, as you see here. could be being able to create records, or rename, or even delete records. Or even some of the more complex things like e-signatures and locking of records and again some of the functions and features that are often used in more regulated studies and trials. So over on the right, we see that for this particular role or if we were coming in at the user level for a user. We can dial up or down the access to any of the case report forms that we've already created. Either no access read or read, read and write access. So for this role, we're good. We'll save those changes and we'll now see that we have a data entry role defined. We could then add users and assign them to that role. Or, again as we mentioned earlier we could create individual users with custom rights. I think it's always a good idea to add roles whenever possible. So, we won't go into more detail here, we'll assume that you can go ahead and play around with that. we're going to assume that we've already set up the user rights for all of our team members. And even in this preparatory mode, we want those users in, so that they can help us through with this next piece, which is the testing.
