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.