So, in this module, we'll be looking at the Fundamentals of Electronic Data Capture. In particular, we'll, we'll be looking at important functions and features to consider when, when, deciding on any electronic data capture program. Any time you're collecting information digitally, these are important concepts to keep in mind. We developed a platform for electronic data capture here at Vanderbilt a number of years ago called REDCap. And just for convenience, we'll be looking through that one the, the features and functions in, in that particular package. Not because it's necessarily the best in the in, in any particular domain, but because it's an easy platform and, and it turns out it's a very easy teaching tool. So as we go along in this course, in the in this particular lecture as well as in exercises, we'll, we'll typically be using this REDCap platform. So I hope as we go through this set of fundamental things to look for and consider for any platform, that'll you'll recognize some of the concepts that we've already talked about in a previous module around research data planning. Let's talk just a little bit before we get into screenshots and looking into functionality, let's talk just a little about the REDCap platform. REDCap stands for Research Electronic Data Capture. And the history of REDCap goes something like this. In 2004, we were looking at the enterprise here at Vanderbilt, trying to figure out how we were going to deal with this problem, that we had lots of lots and research teams and very, very diverse domains. from a scientific standpoint using what, what we would now call especially very substandard methods for collecting and man, managing data. A lot of these were very small studies, but some were very large. Some were one to two individuals working together on a study, but some were, you know, quite, quite large and diverse in terms of the number of contributors. This was beginning to be a problem, because we were seeing risk at, at the institutional level. You know, we didn't want to see breaches in, in data. We were seeing risk for the research protocols and the research teams. we talked earlier in another module about the, the need to make sure that we're doing the right things in terms of auditing and logging what's happening. it's [UNKNOWN] w, we were seeing that this was just not happening in other, other methods of collecting and storing data. Things like collecting data directly into SASS or Excel or SPSS or even Microsoft Access. So, so we, we realized that, you know, people were not doing sort of things in a substandard way, because they were necessarily wanting to do things in a substandard way. They were doing them in that way because they didn't have tools to do them the right thing, right way. So our hypothesis at the time was that researchers would do the right thing, you know, in terms of security, audit trails. all, all of those things that we talked about in the, in the good data management practices. If they were provided in easy way to get and to use those tools. The problem at the time was the same as the problem now, we have many, many research projects at, at a typical academic enterprise like Vanderbilt. But few resources. It takes a lot of resources to create custom programs. when you're creating custom programs you, you typically have to go through a very long specification stage. You build things out, and then if things change, it, it becomes very costly to support and maintain custom software. So we realized we had this problem in many projects and few resources. So, so we came up with the idea that you know, if we could get the data about the data, that research teams wanted to collect for studies. Whether they be in the, the domain of nephrology or neurology or autism or even, you know, animal research. If we could get the data about the data for individual projects, then perhaps we could write software that would morph depending on the, the, the data that was stored behind the scenes about those studies. So, so that's exactly what we did. We created not only the, the, sort of, the front-in infrastructure to be able to sort of look at the data behind the scenes about particular studies. But, but also we created some very easy tools for our research teams to, to supply and to provide that data for us. So the, that concept is called metadata driven application programming. we weren't the first to invent metadata driven application programming of course. But I think one of the things that's quite novel about what we were able to do was we created a process and a workflow for our research teams that force them to own their own projects. And in so doing, made it easy for them to do the right thing while, while caring the most about the data and the projects that they were undertaking. So in 2004, we launched the first REDCap project here at Vanderbilt. It was pretty popular. We we found that that research team told their other colleagues in their lab and they used it again for the next study that they were doing. And actually it went viral around here pretty quickly. Mainly because it was this disruptive technology that was doing something that that, that individuals couldn't do before. So, we started sharing it out with, with other individuals and, and groups as we would talk about this, this solution we had created in, in a national meeting settings. And we found out that Vanderbilt was not the only group that, that, or not the only enterprise that had this problem of having few, few resources, and way many projects, and, and not a lot of time for custom programming on individual ones. So we've started sharing this. We created an, a what I think is a novel sharing model and consortium model, but we share it at no cost to academic institutions and non-profit groups. And since that time around 2006 we've grown to, to be a fairly large consortium. We'll talk more about that in later modules. But one of the successes of, of REDCap is that it is so prevalent out there at many institutions and academic enterprises, and as well as non-profits throughout the world. So, so I want to kind of stop there with the, the, the, the history and actually get into some of the, the, the, the actual pages and look and feel and functions. And again, we're, we're presenting this in the context that these are important concepts that might consider when selecting any electronic data capture. We're just using REDCap for convenience here. So when an individual logs into a REDCap system, whether that be at Vanderbilt or Mayo Clinic, or anywhere else in the world using it. they're going to see their projects. So, so being able to sort of see all my projects at a glance. ha, having the users only see the projects that they should be seeing. in other words, REDCap might be supporting, or your EDC capture system might be supporting 500 projects across the enterprise. But if you as an individual should only see three, then, then you should only see three. And so, being able to sort of sequester the information in the project information based on users e, is an important concept. we also have within REDCap, when, when you're seeing those projects, it will, it'll sort of pull dynamic status reports from those different projects and be able to show you how many records are in that database or that project. How many you know, whether, whether the status of it is live or it's in development mode or maybe in archival mode. So just sort of this dashboard at a glance view of all of your studies is, is a good EDC function. Once you drill down into a given project the first thing that you see in, in REDCap is you see sort of information about who is associated with your project. we'll get into that in just a second, but, but first we'll talk about the data, data instruments. So the first thing that you see on the left is you see the, the customized data instruments for this particular study. And they really are customized for that study based on that data dictionary or metadata up, upload and, and model that we we discussed earlier. And we'll show a little bit later in this module. Other things that that, that an individual might see when they're logging directly into their project, is a lot of other core modules. Not necessarily associated with the individual case report forms and data collection fields, but other features and functions. And again we're going to go through that as we go along in this particular video and in the next several to come. Other things that we see there. This is what I was mentioning at first. Other things that we see there are being able to look and, and see who's using my projects. Over on the left in the main panel, we see the, the users that are registered across that project. We also see that there in the, in the larger caption there. We see the last time I was logged in. And so, even, even at this very first screen, there's, there's an awareness by the research teams that here we've got auditing going on. There, there are functions in place to know when I was here last. The way I like to sort of describe this to, to new users of REDCap is these are the things that you might expect from your electronic banking system. that, that's an important system. You, you care a lot about the security of the data and who's doing what there. You should care just as much about your research data. So, important here, you know, again, as a concept within, in the EDC system. So then, then we'll drown, drill down to one of the case report forms. Here I've got a side showing what might halfen, happen if I chose demographics. That first form on the left. And again, that, that makes sense for a human study, it might make sense for this particular study. If it doesn't make sense for another study, then it's important in our model at least that, that REDCap be able to morph and show that the data that, that's most relevant for your particular project, but within a given case report form. Or, or a data collection instrument, we might call it. it's important that first and foremost, I think that we have human readable labels. You don't want to have a computer programmer entering the data for you at the bedside when you're working you know, on a clinical study, or, or even on a basic science study. You want these human readable labels that don't look like database speak, but, but really, you know, would be recognized by anyone. different field types. You see there over on the right that, that we have some, some types of fields, that you can just type in text. Some types of fields down a little bit below, you know, might have areas where if you type something other than a number or a phone number or a zip code or you, you name it. that it will come back and it will say hey, that doesn't look quite right to me. we've got places where you can enter data not in text form, and here you could get it very structured. Like the pull down list for gender that you see there, or with the Radio buttons way down below. So, so there, there should be num, a number of different ways of entering data into a case report form. But it should all be consistent and readable by the end user. data validation. So on those type in fields. If it's supposed to be date. Then, you know, again, as I said earlier, it should, it should force it to be a date. And if you enter something else, then it, then it should come back and nag you a little bit until you get it right. By the same token, sometimes we have ranges. So, if it's supposed to be a number, it might be a good idea to go ahead and set up from a data quality module going in. That, that this number really should always, always fall between the numbers zero and ten, or 100, or 1,000, whatever makes sense for your particular study. one, one of the nice ways that you can force getting good quality data in is to, is to not give the end user any choice. So, so here we've got gender and a question about pregnancy there. If, if we were to do a you, you know, quick, quick study where we didn't enforce these values the, these choices, a lot of times, what we might get back is you know, inconsistency in the data reporting. Things like male, female, m, f, zeros and ones for the same type of, same data field. So it's a good idea not to give end users any choice if, if you've got things that, that are categorical and you can code in like we've done here. on that line though, it's important that not only do we show the user something like male and female. But as we mentioned in an earlier broadcast video, it's, it's, it's a good idea to code those variables behind the scenes so that the system can keep up with the fact that zero is female and one was a male. But the end user doesn't have to see it. Other things here might be branching logic. So that question about pregnancy way down at the bottom of the form, that makes sense if the individual is a female. But it really makes no sense and, and might lead to corrupted data if we leave that field in, in the case that an individual is male. So any electronic data capture system you might think, that you're considering, you might want to look at whether it has branching logic and the ability to discern when, when and where to ask specific questions. in, in REDCap, we think that you know, once you're you know, entering data or looking at information for a given subject, it's a good idea to give you a status report of all of the instruments in case report forms for that particular individual. and again, well, let be a human or a mouse or, or a test tube, whatever, whatever your record is is collecting data on. But over on the left there, you'll see some little buttons that, that appear once you're in contacts of a patient. And that's going to give the status of the individual. You know that, that case report form or instrument. as well it serves in REDCap at least as a navigation tool so that if you click on one of those Red buttons, it would take you directly to the next case report form for that same individual. And then finally on the case report forms. One of the things that we found people asking for quite a bit early on in the electronic data capture creation process for individual projects, was the ability to not only show this on the screen, but, but make these same fields and these same data collection instruments available via PDF. A couple of ways that, that's very useful. The first way is if you are submitting your, your study to an IRB or to a human subjects ethics board, a lot of times they will require you to give detail on the types of co, collection you're doing. So being able to, on a case report form page click a button and have it spit out the PDF for you. Where, where you've got a clean, clean set, set of questions and options. That's pretty useful when you're, when you're going through that type of process. We've also found that useful for teams that are a little bit uncomfortable, that maybe their, their system could possibly be down at some point. And maybe, you know, their wireless adapter breaks right in the middle of when they're wanting to collect data. We also found that useful to be able to sort of auto generate these PDFs, and just have a copy sitting around just in case the there, there is some sort of catastrophe and, and the internet is not working at a particular time. So, you know, again an REDC platform we found that very useful, and, and our end users find it very useful to be able to have these auto generated PDF reports be, being able to be exported. So, once you get through with the thinking about getting data into a system using forms that, that humans would be able to read and interact wit,h and enjoy using it at the bedside. Then, then the next thing we typically think about in the electronic data capture world would be exporting data. This is very important. we, we'll won't be using it as often as we use the data import, sorry, as we use the case report forms and data collection instruments. But it's very, very important that we're able to get the data out after the study or even during the middle of the study, if we're doing interim analysis. One of the things that we found was the research domain is that in a place as large as Vanderbilt and, and places that are as diverse as places that are using REDCap across the world. We found that there is not one common statistics package that is used. clinical trials will typically use SASS, clinical, you know, other groups [UNKNOWN] or some other package SASS data, SPSS. We, we really don't want to make that decision or have that individual research team have to make that decision early on in, in the process. And so what we've done is, we've created a data export module that will enable the, the end user research teams to, to specify what data they want to export. And too, to export it in any of those common statistics packages. We also believe that it's important to think about confidentiality of data. And so, so with that, we've created some data d identification tools that will able to obfuscate the data as it's coming out, even shifting dates in the case where we have dates of service. So that we get somewhat of a De-Identification process if required or if, if, recommended by the research team. So, I think that covers this particular topic. And we'll pick it up in the next video.
