View source: R/docsRecordsTypedMethods.R
recordsTypedMethods | R Documentation |
These methods enable the user to export records from a
database or from a report. These methods have more control for casting
fields to R objects than exportRecords
.
exportRecordsTyped(
rcon,
fields = NULL,
drop_fields = NULL,
forms = NULL,
records = NULL,
events = NULL,
...
)
exportReportsTyped(rcon, report_id, ...)
## S3 method for class 'redcapApiConnection'
exportRecordsTyped(
rcon,
fields = NULL,
drop_fields = NULL,
forms = NULL,
records = NULL,
events = NULL,
survey = TRUE,
dag = FALSE,
date_begin = NULL,
date_end = NULL,
na = list(),
validation = list(),
cast = list(),
assignment = list(label = stripHTMLandUnicode, units = unitsFieldAnnotation),
filter_empty_rows = TRUE,
warn_zero_coded = TRUE,
...,
csv_delimiter = ",",
batch_size = NULL
)
## S3 method for class 'redcapOfflineConnection'
exportRecordsTyped(
rcon,
fields = NULL,
drop_fields = NULL,
forms = NULL,
records = NULL,
events = NULL,
na = list(),
validation = list(),
cast = list(),
assignment = list(label = stripHTMLandUnicode, units = unitsFieldAnnotation),
warn_zero_coded = TRUE,
...
)
## S3 method for class 'redcapApiConnection'
exportReportsTyped(
rcon,
report_id,
drop_fields = NULL,
na = list(),
validation = list(),
cast = list(),
assignment = list(label = stripHTMLandUnicode, units = unitsFieldAnnotation),
warn_zero_coded = TRUE,
...,
csv_delimiter = ","
)
rcon |
A |
report_id |
|
fields |
|
drop_fields |
|
forms |
|
records |
|
events |
A |
survey |
|
dag |
|
date_begin |
|
date_end |
|
na |
A named |
validation |
A named |
cast |
A named |
assignment |
A named |
filter_empty_rows |
|
csv_delimiter |
|
batch_size |
|
warn_zero_coded |
|
... |
Arguments to pass to other methods |
The 'offline' method operates on the raw (unlabeled) data file downloaded from REDCap along with the data dictionary. This is made available for instances where the API cannot be accessed for some reason (such as waiting for API approval from the REDCap administrator).
When validating data for offlineRedcapConnection
objects,
links to invalid data forms will not work if the user does not provide
the url
, version
, project_info
, and events
arguments (if the
project is longitudinal). For the project_info
, the values project_id
and is_longitudinal
are required. The user may be able to provide
as little as project_info = data.frame(project_id = [id], is_longitudinal = [0/1])
.
The user should be aware that the REDCap User Interface download for
events does not include the event ID. To include the event ID, the user
must construct a data frame to pass to offlineConnection
.
In all calls, the project's ID fields will be included–there is no option provided to prevent this. Additionally, if the project has a secondary unique field specified, it will also be included. Inclusion of these fields is necessary to support some post-processing functions.
By default, the system fields redcap_event_name
,
redcap_repeat_instrument
, and redcap_repeat_instance
are
exported (when they are appropriate to the project). These are automatically
included by the API. However, if the user omits any of these in fields
or designates one in drop_fields
, the final result will honor those
conditions. Excluding any of these identifiers may cause problems with
some post-processing functions that operate on repeating instrument data.
The combination of the project ID field, secondary unique field, and the system fields are what uniquely identify an experimental unit. In nearly all cases, it is desirable to have them all included.
System fields are cast to labelled values by default. They may be cast
to their coded values using the override cast = list(system = castRaw)
.
The fields affected by the system
override are redcap_event_name
,
redcap_repeat_instrument
, and redcap_data_access_group
.
Text fields that are validation enabled using the BioPortal Ontology service may be cast to labeled values so long as the labels have been cached on the REDCap server. Caching is performed when the field is viewed in a form on the web interface. However, labels are not cached when data are imported via the API. In cases where labels are not cached, the coded value is treated as both the code and the label.
A 'batched' export is one where the export is performed over a series of
API calls rather than one large call. For large projects on small servers,
this may prevent a single user from tying up the server and forcing others
to wait on a larger job. The batched export is performed by first
calling the API to export the subject identifier field (the first field
in the meta data). The unique ID's are then assigned a batch number with
no more than batch_size
ID's in any single batch. The batches are
exported from the API and stacked together.
In longitudinal projects, batch_size
may not necessarily be the
number of records exported in each batch. If batch_size
is ten and
there are four records per patient, each batch will consist of 40 records.
Thus, if the user is concerned about tying up the server with a large,
longitudinal project, it would be prudent to use a smaller batch size.
The final product of calling this is a data.frame
with columns
that have been type cast to most commonly used analysis class (e.g. factor).
This version allows the user to override any step of this process by
specifying a different function for each of the stages of the type casting.
The algorithm is as follows:
Detect NAs in returned data (na
argument).
Run validate
functions for the field_types.
On the fields that are not NA and pass validate do the specified cast.
It is expected that the na
and validate
overrides should
rarely be used. Their exposure via the function parameters is to future
proof against possible bugs in the defaults, and allows for things that
higher versions of REDCap add as possible field types. I.e., the overrides
are for use to continue using the library when errors or changes to REDCap
occur.
The cast override is one where users can specify things that were controlled
by an ever increasing set of flags before. E.g., dates=as.Date
was
an addition to allow dates in the previous version to be overridden if the
user wanted to use the Date class. In this version, it would appear called
as cast=list(_date=as.Date))
. See fieldValidationAndCasting()
for a full listing of package provided cast functions.
exportRecordsTyped
returns a data frame with the formatted data.
exportReportsTyped
returns a data frame with the formatted data.
exportRecordsTyped()
: Export records with type casting.
exportReportsTyped()
: Export reports with type casting.
exportRecordsTyped(redcapOfflineConnection)
: Export records without API access.
A zero-coded check field is a field of the REDCap type checkbox
that has
a coding definition of 0, [label]
. When exported, the field names for
these fields is [field_name]___0
. As in other checkbox fields, the
raw data output returns binary values where 0 represent an unchecked
box and 1 represents a checked box. For zero-coded checkboxes, then, a
value of 1 indicates that 0 was selected.
This coding rarely presents a problem when casting from raw values
(as is done in exportRecordsTyped
). However, casting from coded or
labeled values can be problematic. In this case, it becomes
indeterminate from context if the intent of 0
is 'false' or the coded
value '0' ('true') ...
The situations in which casting may fail to produce the desired results are
Code | Label | Result |
0 | anything other than "0" | Likely to fail when casting from coded values |
0 | 0 | Likely to fail when casting from coded or labeled values |
Because of the potential for miscast data, casting functions will issue a warning anytime a zero-coded check field is encountered. A separate warning is issued when a field is cast from coded or labeled values.
When casting from coded or labeled values, it is strongly recommended that
the function castCheckForImport()
be used. This function permits the
user to state explicitly which values should be recognized as checked,
avoiding the ambiguity resulting from the coding.
exportRecords()
,
exportReports()
,
exportBulkRecords()
fieldValidationAndCasting()
,
reviewInvalidRecords()
recastRecords()
,
guessCast()
,
guessDate()
,
castForImport()
,
mChoiceCast()
,
splitForms()
,
widerRepeated()
vignette("redcapAPI-offline-connection")
vignette("redcapAPI-casting-data")
vignette("redcapAPI-missing-data-detection")
vignette("redcapAPI-data-validation)
vignette("redcapAPI-faq)
## Not run:
unlockREDCap(connections = c(rcon = "project_alias"),
url = "your_redcap_url",
keyring = "API_KEYs",
envir = globalenv())
# Export records with default settings
exportRecordsTyped(rcon)
# Export records with no factors
exportRecordsTyped(rcon,
cast = default_cast_character)
# Export records for specific records
exportRecordsTyped(rcon,
records = 1:3)
# Export records for specific instruments
exportRecordsTyped(rcon,
forms = c("registration", "visit_1", "medications"))
# Export records using filterLogic, an API parameter not provided
# in the exportRecordsTyped function signature
exportRecordsTyped(
rcon,
records = 1:3,
api_param = list(filterLogic = "[age_at_enrollment] > 25")
)
# Export a report
exportReports(rcon,
report_id = 12345)
# Export records using files downloaded from the user interface
rcon_off <-
offlineConnection(
meta_data =
system.file(file.path("extdata/offlineConnectionFiles",
"TestRedcapAPI_DataDictionary.csv"),
package = "redcapAPI"),
records =
system.file(file.path("extdata/offlineConnectionFiles",
"TestRedcapAPI_Records.csv"),
package = "redcapAPI"))
exportRecordsTyped(rcon_off)
## End(Not run)
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.