Access data stored in 'REDCap' databases using the Application Programming Interface (API). 'REDCap' (Research Electronic Data CAPture; < https://projectredcap.org>) is a web application for building and managing online surveys and databases developed at Vanderbilt University. The API allows users to access data and project meta data (such as the data dictionary) from the web programmatically. The 'redcapAPI' package facilitates the process of accessing data with options to prepare an analysis-ready data set consistent with the definitions in a database's data dictionary.
Please read the documentation on your institutions REDCap installation.
Issues may be reported at https://github.com/nutterb/redcapAPI/issues
Please consider contributing tips and clarifications to the package wiki at https://github.com/nutterb/redcapAPI/wiki
This package was developed under REDCap Version 5.8.2. My institution is usually a little behind on updating REDCap and so some features of the API may not always be available.
The redcapDbConnection methods are underdeveloped as I don't personally have access to the REDCap database (and so am unable to test features). If you have that kind of access, feel free to develop the redcapDbConnection methods.
prod_allocateelements of the object returned by
allocationTablehave been named
importRecordsnow handles data with repeating forms correctly.
[form]_completefields in Reports
[form]_completefields may be explicitly requested.
[form]_completefields may be turned off.
redcapProjectInfois being deprecated, as it will inevitably create confusion with the API method
exportProjectInformation. The replacement function is
redcap_bundleby default. For now, exportBundle will also return that same object. This is to prevent back-compatibility problems with existing code, but will change at a future date.
fieldToVarfunction now operates on a switch statement instead of a sequence of
if elseblocks. It also incorporates a
forloop in place of the
exportVersionwill now return "5.12.2" for all versions of REDCap less than 6.0.0. While it is admittedly odd, this allows for consistent logical comparisons of of versions and allows better control of the package's behavior over multiple versions of REDCap.
redcapFactor, that inherits whatever class the variable becomes on export. For example, if
factors = TRUE, the new class will be
c("redcapFactor", "factor"), otherwise, it may be something similar to
c("redcapFactor", "numeric"). This is done to assist in converting factors back and forth between classes as needed (particular when using
NULLvalue is returned. See
Changes in Version 1.3.5 (2017-01-20)
Changes in Version 1.3.2 (2015-12-09)
Changes in Version 1.3.1 (2015-07-05)
apiCallto be returned correctly.
Changes in Version 1.3 (2015-03-04)
exportMappingschanged between versions 5.x and 6.0. In 5.x, the error message is "You cannot export arms for classic projects." In 6.0+, it is "ERROR: You cannot export arms for classic projects." The change causes
exportMappingsto cast an error instead of returning the character string with the error. The bug fix accomodates the error messages from both 5.x and 6.0+.
importRecordsmeta data was not previously exported when a project info object was not provided. This is now corrected
exportReports, the checkbox labels weren't being returned as factor levels when
checkboxLabels=TRUE. The behavior is now consistent with expectations.
compareRedcapVersion, a logical check was failing due to an ommitted argument in
grepl. This has been corrected.
apiCall. This wraps a call to
tryCatch. If a Gnu/TLS recv error is returned, the encoding is changed from 'gzip' to 'identity' to successfully retrieve the API response.
tryCatchcalls are added to
redcapProjectInfoto prevent fatal errors when one of the API functions casts an error. The output is modified to indicate where the problem occurred. This is most likely to affect
exportUsers. An unresolved issue behind this is logged in the issues on Github.