The anatomy of a ResearchKit-based application

The five initial ResearchKit-based applications share a common software architecture. One based on a layered architecture using common software components in order to provide a similar user experience and application functionality. While ResearchKit offers a wealth of opportunities for different types of research applications, the following figure describes a generic architecture that's common to what the initial ResearchKit-based application employed. Using a layered architecture and common components, a developer may create the basis for a family of applications. Such a framework could be used to address the needs for multiple applications at a reduced cost and increased software quality, as shown in the following diagram:

The figure describes a generic architecture that can form the basis of a ResearchKit-based application. Using a layered approach, the architecture has features described in the following paragraphs.

A central Data Model that services the needs for the upper layers and components. This layer includes the following components:

• A data upload component that is responsible to upload data, track the success or failure of the upload attempts, retry failed upload attempts, and clean up the data that has been successfully uploaded.
• A data download component that either periodically or on-demand, downloads new task schedules, survey contents, and news about the study that the researchers desire to share with participant.
• A data archiving component that packages the data to be uploaded to the studies backend server or other destinations. This component can support one or more formats. A key feature of this component is to ensure the confidentiality of the data prior to uploading it to the data collection service. The five initial ResearchKit-based applications used the Cryptographic Message Syntax (RFC 5652) in order to wrap the data for safeguarding.
• One or more passive data collector components. With the participant's explicit permission, these components could collect the data from the various sensors on the device and then trigger a data upload. For example, in order to determine whether the participants were socializing or homebound, a number of the initial ResearchKit-based applications collected relative displacement of the device location. Relative displacement allows the researchers to determine socialization, while avoiding collecting sensitive location data.

An on-boarding process will be common for ResearchKit-based applications. During this process, the applications could present background information about the study, collect any required demographic information, and perform the consent process (a ResearchKit-based activity). This layer includes the following components:

• A consent process component that performs the informed-consent process. ResearchKit supports this activity and provides many features to shape this feature.
• A service signup component, if it is necessary for the participant to provide some kind of login credential or identity with a data collection service.
• For applications that retrieve data from HealthKit, a HealthKit permissions component could inform the participant in one place as to which data will be collected and why. This would be an excellent place to allow the participant to opt out of the collection for one or more HealthKit parameters.

Given the potential sensitive nature of ResearchKit-based applications, the identity and authentication of the application user as a study participant should always be determined prior to allowing a user to use the application. As a variety of data, events, time triggers, and so on could be input in to the authentication process, this component may best be implemented as a state machine.

Once a user has been authenticated (gone through the on-boarding process and authenticated), the heart of this theoretical application's user interface is the dashboard. The dashboard layer includes the following components:

• A to-do activities component that displays a list of activities that the researchers wish the study participants to accomplish. These activities can include ResearchKit-based tasks (for example, surveys) or custom tasks that do not employ ResearchKit. An example of the latter would be a news component, where the researchers share ongoing information about the study in general.
• A task results component, where the application shares the results or summary of the results for completed tasks. If task-aggregated results are available (either baked in the application or downloaded via the data download complement), the application could inform the participant how they are performing with respect to the study's population norm.
• A preference component that allows the participant to customize the application to serve their need. This would be an excellent place to allow the participant to opt out or opt in to the collection of specific data parameters. Additionally, this component could serve as the vehicle to allow the participants to withdraw from the study.

The top component in this layered architecture is the user interface component. This component provides the heart and soul from a user's experience point of view. This component will also address any branding requirements levied by the research institution.