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.