So we'll close out this section of, of this module on Electronic Data Capture Tool consideration. By talking about a few more modules or few more concepts, one of the things that you might consider in choosing electronic data capture platform. It is how you're able to get the data in. maybe, maybe external data in. And there are a number of ways that, that that can be done. We've already talked about the data export components. But, but, you know, one thing that, that might come to play with an electronic data capture system and certainly something we've seen with the REDCap platform. Is this need to sometimes, do batch data uploads. Maybe I'm really not wanting someone to hand enter, every lab measurement. But I do have from the lab, a file that they can send me once a month and I can easily format that in a certain way. And if, and if I can format it in a certain way, it would be great if I could just upload that file. Have REDCap or whatever electronic data capture system I'm using, if I could get that system to, to do the same data, data vali, validation checks, the same logging and all of the things that would happen as if I hand-entered it. And so that's one use case for data import tools. The other one we've seen with the red cap database platform. Is we have a lot of teams that maybe want to switch midstream. Either in a study, or maybe it's not a study but a registry and they've been collecting data in a certain way, for some time. And they say, you know this is just so much easier. We really want to flip on over to. The REDCap system, is that possible? It's kind of tricky because it depends on, you know, the quality of the data so far. A lot of the time the reason they may want to convert is because they're not happy with the integrity of the system that they're coming from. And so you have to be really careful about pushing data in. It's dirty, that hasn't been validated, etc. Into a pristine database. we found that we could get both of those use cases, the batch data uploads and also the, the use case of converting another system. Sort of, sort of converting data from another system into REDCap by creating an import module. The import module knows your particular data set, because it again knows all of the data from your code book and data dictionary that's embedded within the system. Therefore, it knows how to spit that back out at you in a template. So REDCap will spit out into a template the the format that you need if you're going to be pushing data in, so we don't care how you get it. Just get it into this format. You click the upload tool. It's then going to go through all of the validation checks, making sure that you're not putting a number into a field that's supposed to be a date or something of that nature that validates the integrity of the data. And if it does it will tell you, it will tell you what to go fix and you'll just go and fix it. And at the end when, when there are no critical issues found. It will, it will sort of confirm, hey are you really sure that you want to do this because this is this is going to actually do the procedure it's going to upload this data as if you had hand entered it. You say yes and at that point the logging takes effect and you know we still keep track of. Who did what to the data. You just have this logging, event. That it was, that was an import operation. We found that to be very very useful, for, for any number of use cases. So I would look for that any time you're thinking about an electronic gad-, data capture tools set. Mentioned earlier in the, in the creation of, the study. That sometimes we want to use a study calendar. And this is particularly, useful in human based research. As well when you have, in human based research, where you have multiple arms, where you have 42 visits coming up over the next three years. It just kind of gets hard to take care of that on a study-by-study basis and know what we're supposed to be doing next Tuesday as a study team in terms of scheduling and as far as seeing patients. And what's being done to those patients and so it's useful, I think, in any electronic data capture system that you're using for clinical and translational research to be able to sort of embed and use a schedule schedule if, if you, if you'd like. We, we found in the data side of REDCap that many, many people. look at maybe a first trip to the biostatistician after there finished collecting data, or maybe even during study data procedures if you've got active monitoring going on. We found that, that a lot of time is actually spent in cleaning the data. And we've talked earlier about this ability to have the system. Know that a certain field should be a date, or a number, and the ability to sort of check ranges, and push back on the end user if they're violating those principles. But sometimes it's just you have unavoidable things that kind of slip in, because somebody transposed a digit. So one of the things that we found very useful is to embed within REDCap this data visualization, or cleaning tool. That, that allows you to, for any data element that you've collected. Either categorical, which would show up as a bar type graph, or continuous as you, as you see here. Being able to sort of show those out in some sort of a, jitter plot, as you see here in univariance fashion. And basically the way people use this is to find outliers. So if we found an outlier that looked really really different than the rest, we'd be able to click on the button or sorry, click on the point and it could take us directly to the data element within that person's case report form. And you'd be able to sort of check it and make sure that it, that it was right. Again there are a number of reasons you want to put some sort of rudimentary data visualization into an electronic data capture system. But one of the ways that we found the most useful is in this data cleaning and just being able to sort of get a cursory view without having to export it and put it in statistics packages, etc. Custom reporting, so the ability not to have to export all of my data really if I'm looking for just a subset. In this case, you see sort of one of the modules that in, in REDCap that would allow the end users. To be able to sort of specify which fields they want. they, they choose in, in the fields there on the left, the fields have meta data behind the scenes, so, so there are the data dictionary behind the scenes tell this particular module what type of data element that is, and so if it's a number, then different choices come up on the right for how you might want to stratify or. Or, or filter your data. But being, having some sort of a system where you have some flexibility to allow the end users to customize report without again having a programmer involved. That's a really important concept to think about with electronic data capture systems. Go, going a little bit further than that in the, in the data quality and reporting mode, it's important to think about the quality of the data and especially if we're dealing with multi-center functionality. So we'll talk later on in this course about special considerations when you're dealing with datasets that might be generated by multiple teams. Maybe coordinated by one group, but, you know, maybe the Harvard team or the Mayo team were all collaborating on this together, the Vanderbilt team. UC Denver team, maybe we all are collaborating on this project today that we're all pushing the data into a common electronic data capture system even an instance of that data capture system, so that all of the data really are in one place. But it's quite important that in the, in, in that particular case that you sequester the information. You sequester the data elements in the records that the individual sites can see, so that the Vanderbilt people can not see the Mayo clinic site data, and vice versa. But, somebody over the top of the study as a coordinator, would be able to see all of it, and generate queries. Again, we'll talk a little bit about this later, in later modules. But that ability to sort of look and see all of the, the data quality checks and issues that have arisen because you've put the data in either correctly or incorrectly, being able to sort of see that and even stratify it by sight. This is something that you should think about with electronic data capture systems, and we've found at Vanderbilt and elsewhere using REDCap. That that's a functional model that that, that is very important. one of the things that you may or may not need to consider with an electronic data capture system would be the ability to abstract language for at, at least the case report form and survey. im, implementation. So where this is going to really come into play is if you're doing multi-country studies or global health studies. But, but occasionally as well, you know it may come into play if you're doing studies right there locally where you have. Different communities that, that you're, you're leveraging for your research studies that might be speaking foreign languages or different languages rather. So, so in our case we we've, we've spent a lot of time trying to make sure that we can, fulfill the needs to be able to sort of render surveys or case report forms out. In different languages, including the categorical options, etcetera. And because we've we've really disseminated the REDCap platform out widely to lots and lots of partner institutions, we actually went ahead and abstracted the language for the entire base code so that an individual in China. Isn't reading core level instructions in English, they're reading it in Chinese. So, again I think that maybe that last piece is a little bit dependent on whether you're doing lots and lots of studies in a decentralized way where you've got people speaking different languages. But, but for sure the first set of functinality the ability to render out surveys and case report forms in multiple languages, is something you might consider when planning for an REDC system. So, so Another way that we can think about getting, data in and out of a system. and and this is a very important concept, one of the things that you want to think about with electronic data capture systems. Or really any Informatics platform in my opinion, is this, concept that the data should never be held hostage. I call it open architecture. So, so in redcap we've already seen that we can import data if we can get data from a file into a file that redcap recognizes. You can import it and then it will do all of the right things in terms of checking validity the logging et cetera. We saw earlier in this segment that we can also export data into any of the common statistics packages but if you really want to do some of the really strong integration work, there, there's another way that you can access the data that, that's in REDCap and that's through, in component called the API. It's, it's a programmer interface where and methodology where if you're programming and another environment, maybe it's a web page, maybe it's just from a statistics package. There is a methodology so that you can talk to REDCap in a secure fashion and, and, and ask it for data and also push data into REDCap. You can also ask it for metadata etc. So you know, you don't have to be a hardcore programmer. But if you do have some really clever integration type work, it's important that, that we feel, that the system should not be limited to sort of the single user interface but instead. Have sort of external system functionality, and again, that's, the, the API technology that is that is something that's built into a lot of systems these days, and, and I would definitely recommend that as you're thinking about an electronic data capture system that, that you look at that particular component, beacuse it really can Open the doors for integrating lots and lots of data sources together. So kind of concluding, you, you know, in the REDCap domain, and again sort of taking lessons from that domain and, and EDC and sort of generalizing those to any EDC platform. You know, we found it tremendously valuable to just sort of provide an easy way to do the right thing. And the right thing being you know, highly compliant, highly secure, but also make it really, really easy. And, and put the power in the hands of research teams. the power with, within the Ed system system can, can be very great you know, we just talked about the API. We've talked earlier about data de-identification and all of the audit trails and maybe double data entry. Those, those are all randomization of, of patients. Those are all very, very critical elements that, that can be employed in, in this particular EDC system. If your study requires it. But we spend a lot of time trying to take that complexity out of the way for studies that really don't need it. And so keeping it, keeping in mind that you're always designing for the humans, the research coordinator, and the data entry people, and the statistician. We found that, that's a really really, really important concept when designing and developing an EDC system, and I think our end users really appreciate that philosophy as well. So, that concludes the segment and I hope it's given at least some overview of important functions and features for EDC programs. And and, and also provided the fundamental details about REDCap that we'll be using later on in different sections and modules.
