REDCap is a popular web-based application developed at Vanderbilt University that enables clinical investigators to easily create surveys and manage study data in their research. The REDCap consortium consists of thousands of academic and non-profit organizations across the globe who host REDCap servers and ensure HIPAA-compliant data storage, management, and access.

Gene Doe takes advantage of REDCap’s API to provide a comprehensive deployment of REDCap functionality on mobile devices. The API is used both for downloading an investigator-authored protocol to the iPhone such that it can be rendered as a mobile application, and for uploading collected data to the same institutional instance of REDCap for data management and analysis. The following is a summary of how Gene Doe integrates with REDCap.

1.    Data Collection Instruments
a)    Data Collection Instruments are the primary construct in REDCap for developing surveys and databases. Investigators may create multiple instruments for each study, each with a collection of questions to ask study participants. A response type for each question is specified, which include: 
(1)    Multiple Choice, Single Answer
(2)    Multiple Choice, Multiple Answers
(3)    Text
(4)    Visual Scale
(5)    File Upload

b)    Branching logic may be defined for questions, such that follow-up questions depend on answers given previously by the study participant in the current or prior sessions, or data provided by investigators about the study participant during on-boarding.

c)    Data validation ensures that text responses provided by the study participant are the proper data type. Our platform uses these specifications to present the appropriate user-interface element for easy data entry. Data types include:
(1)    Date (multiple formats)
(2)    Datetime (multiple formats)
(3)    Email
(4)    Integer
(5)    Letters only
(6)    MRN (10 digit)
(7)    Number
(8)    Time (multiple formats)

d)    Calculated fields take for responses the result of calculations based on prior responses from the current or past sessions. These can be combined with branching logic to create sophisticated algorithms and interactions with the user.

e)    Field annotations are used to pass commands to the mobile app to perform specific actions. The commands consist of simple dot syntax and dictionary constructs to direct an advanced featured set at a prescribed time. For a complete list, please see Appendix A. Examples include:
(1)    statusPost.screening.pass
(2)    statusPost.survey.play_audio[“file":"theaudiofile.mp3","auto_advance":"true"]
(3)    researchkit.activetask.motor.gait_and_balance["intendedUseDescription":"Evaluating your gait","duration":20]

f)    Piping allows a participant’s response to a previous question to be used in an expression elsewhere in REDCap’s configurations. For example, when the user responds that their headache was severe, a subsequent question could ask “Was your severe headache on one side?” This feature is primarily used in question text as shown but is supported elsewhere in our implementation of REDCap’s API. 

g)    Metadata Instruments are not a REDCap feature per se, but precisely named data collection instrument fields may be added to each event to capture metadata related to each session with the user. We recommend adding the following text fields to an instrument called “metadata,” and configure REDCap so that this instrument is used in every event. 
(1)    statuspost_start - collects a session start datetime
(2)    statuspost_end - collects session end datetime
(3)    statuspost_event - collects the events scheduled datetime
(4)    statuspost_status - collects current status of a session: scheduled, waiting, in progress, completed, canceled, or missed.

2.    Events 
REDCap Events are used to support longitudinal studies, which is always the case in studies designed for Gene Doe. Our implementation supports:
a)    Multiple Arms 
b)    Multiple Data Collection Instruments per Event
c)    Arms may represent traditional arms of a study, or stages of a study. Specifically, Gene Doe supports moving study participants from one arm to another. 
d)    Repeating Events are implemented, and used in Gene Doe to support On-Demand, Collector, and Ad-Hoc Events as part of our enhancements covered below. 

3.    API 
Platform applications communicate with each institution’s REDCap instance using Secure Socket Layer encrypted messages to the REDCap Application Programming Interface (API). The API is used to download the study protocol as authored by the investigator, and upload collected results by the app. To support Gene Doe, the institution REDCap API must be available from public networks. An API security token should be requested from the investigator account and issued by the REDCap administrator. The token is used by the mobile app and server applications for communications with the API. The token is stored in the investigator’s private CloudKit database.

4.    Enhancements
Additional features are supported that cannot be efficiently defined in REDCap alone and are therefore configured in the investigator dashboard as the study is published for testing on our platform.

a)    Default event times are rotated daily when multiple sessions are scheduled on a single day. The default times can be replaced with custom times as each participant is enrolled to a study. Random timeframes, rest periods, and weekend times are supported.

b)    Custom Events are events that have been created in REDCap, that have special meaning to the platform. Since REDCap does not have an annotation field for each event as it does for instrument fields, we reference these events for their specialized purpose during study publication. Indicating an initialization event is the only requirement for the platform.

(1)    Initialization Event is required for all Gene Doe studies, and at a minimum calls for a Data Collection Instrument containing a field with “participant_id” as the record ID. For studies employing Share Requests, additional fields may be included with the Data Collection Instrument where responses are expected to be provided by the investigator prior to the user enrolling in the app. These fields can be used to drive branching logic for later user sessions. For example, an investigator may indicate that the user is prescribed a particular class of drug so that questions can be directed at side effects.

(2)    Screening Events are shown first when a user shows interest in joining a study and are to ensure only proper users are enrolled as defined in the study’s Institutional Review Board-approved protocol. Screening Events are not required in all circumstances. Screening events should use Data Collection Instruments with branching logic to direct users responding correctly to screening questions to a field with a “statusPost.screening.pass” command in the field annotation. Only these users will be allowed to move forward in the study onboarding process.

(3)    Demo Event specifies an event to run when the user selects “Demo” in the app. This gives the opportunity to quickly see what a session will look like as soon as the app is installed, and before scheduled sessions begin.

(4)    Investigator-Provided Data indicates that the event is to be completed by the investigator, not the study participant. Investigators provide responses directly in REDCap prior to the study participant enrolling in the app. Responses provided can be used to drive branching logic and piping for upcoming user sessions.

(5)    On-Demand Events are not scheduled and are available to the user at any time. These events are marked as “repeating” events in REDCap, such that they can be completed as often as needed. These are primarily used to allow study participants to document an event, such as a headache, or having a cigarette, and can include questions to characterize the event and provide instruction or feedback.

(6)    Collector Events are used by the device to upload passively collected sensor data. These events are marked as repeating events in REDCap to support the continuous uploading of those data during the user sessions, and periodically from the background. 

(7)    Ad-Hoc Events are not scheduled, and instead are triggered in response to some other event. Examples include triggering an Ad-Hoc event at some future time based on the response to a question in the current session, or exceeding a certain value collected from sensors. Ad-Hoc events are marked as repeating events in REDCap.

(8)    Scheduling Events give users the ability to customize the timing for daily scheduled events, and results provided override those defined for the study. Instrument descriptive fields should be used to explain the purpose for each daily scheduled session slot before giving the user the opportunity to select a time.

(9)    Random Event Groups provide the opportunity to randomize the event shown during a scheduled session slot. All scheduled events for a day belonging to the same random event group are considered during randomization. By using different Data Collection Instruments in each event belonging to the group, this feature allows considerable variety in sessions with the user.