Top 5 Key Considerations when Building a ResearchKit Appby Chintan Patel, PhD
ResearchKit is an open source library released by Apple in 2015 which has opened up unprecedented opportunity to conduct research studies on mobile devices and already within a year or so of its launch about two dozens such apps have been released and we anticipate a lot more to come in the days ahead.. The library provides several useful modules to create consent, conduct surveys and display charts and graphs and importantly access user data via device sensors or local device data store (HealthKit). However, there are several key architecture decisions that are left to the research app developers to make and these require careful consideration. We outline 5 of the major issues that need to be taken care when developing ResearchKit apps. Once these 5 key considerations are dealt with, you’re ready to build a great research study mobile app.
1. Participant Signup and Identity Matching
A very common research study workflow that you will need to consider is offline consent and recruiting. Depending on the study, Participants maybe recruited in-person (in a hospital, clinic) by the research team and then asked to download the research study app. The challenge in this scenario is how to tie and match the identity of the actual participant signing up in-person and the person downloading the app. To make the matters worse, these apps are available openly on the App Stores (iTunes, Google Play), hence anyone can download and be part of the study.
To overcome these issues, we recommend using one of the following methods:
- Unique Participant Code: The research investigator uses her study “administrator” login (web or mobile application) to generate a participant specific code that is required to be entered by the participant after they download and open the app for the first time. Note that this requires that the code generating app or computer is easily accessible to the researcher. Also patients need to manually type that code into the app, which may be error prone.
- Email Matching: Another approach is to enter the participant’s email in the “administrator” login and simply require the participant to use that particular email when signing up or sending them the unique code in the mail invite.
- QR Code: A more sophisticated approach would be print out a QR code that the participants can scan using their phone. There can be 2 QR codes, one that opens up the iTunes app store and second one to identify the participant uniquely.
- Open access/Data Ignore policy: A low tech approach would be to let everyone sign up on the app and during the data analysis phase, only include the data of participants that were registered in-person. Note, that since all users of the study app must go through the mobile consent process, they have technically given the permission to use their data and depending upon the actual study setup, this “extra” data may prove to be of additional value.
2. Data Storage and Connectivity
Generally research study apps send the data collected as part of the study to a secure remote server. This presents a new set of challenges in terms of data security and maintaining device connectivity to the Internet. Consider the following scenario:
A research study participant fills in a 15 screen survey in a New York City subway and presses “submit”. Since the app is not connected to the Internet and depending on how it was programmed, it might loose all the data or crash badly. The participant has to re-enter all data again.
The key decision for the app developer is to ensure such scenarios and program the app in such a way so as to prevent such data loss and frustration among participants who are volunteering their valuable time for the study. We describe some battle-tested approaches to handle such scenarios:
- Sync/Offline Storage: One of the ways to ensure data connectivity issues is to store a copy of the data on mobile device before sending it out to the server. In case of failure, the app can retry when internet connection is reestablished . For apps that have simple APIs, Parse Platform SDK provides an open source library that takes care of such syncing issues. Note that this approach is limited to scenarios where the amount of data to be stored/synced is small.
- Connection Check: A straightforward approach is to hook into the app’s life-cycle event when it becomes active, so that if the Internet connection is not available, the user is prohibited from entering any data. A message as shown below can be used if the connection is unreachable.
3. Security and Protecting Privacy
One of the most important considerations in building a research mobile study app is to ensure the security and privacy of the participants data. With mobile applications the data can be potentially accessible to third-party apps. Moreover the participants can potentially lose the device or it might get stolen. All such scenarios need to be considered to maintain data integrity and security.
We recommend some of the following approaches to ensure security of your research study app:
Mobile Audit Log: As part of maintaining a audit logs, one of the standard practices is to store the log at a database or API access level to keep track of all the data access events. However, with mobile apps not all actions on the device lead to a database query on the remote server. To capture all the actions performed on the device, an “event” tracker needs to be added that tracks different screens and actions made by the user. More on this to be added later.
4. Opt-Out and End of Study
All research study apps should provide a mechanism for participants to opt-out of the study at any point in time. Also the participants should be notified once the study ends.
We recommend following best practices for such scenarios:
- Data Collection: In general, mobile research apps that collect active or passive data (from Wearables, Sensors, HealthKit or Google Fit), data collection should stop after the study ends. The participants should also be notified via a push message or via email that their data will no longer be collected once the study has ended (this should also be cleared explained in the consent process). Alternatively, the participants can be allowed to share/collect the data if it helps them in other ways, for example, a mood tracking study app might also have uses to participants beyond the study for self quantification or similar health related purposes. In such scenarios, we recommend letting the patients use the app but storing a participant study end date to enable proper scientific data analysis and separation of “study” data from user data
- End of Study Survey: If the study requires a end of study survey or opt-out survey, it could be triggered by using a push notification after the duration of x days of joining. The end of study survey can also show options whether the participant wants to continue to use the app after the end of study or simply end their participation.
- Study End Screen: If study does not require participants to enter data or use the app after the study end date, then we suggest displaying a end of study screen (see an example below). This also makes it clear to the participants that the app is no longer collecting data from the device.
- Data Sharing: We also encourage allowing participants to download their own data. This can be triggered via a button in the app that sends an email with a CSV file with all the data collected. It is also a good practice to share the study results and finding in the form of publications, blogs, or press releases. For studies that can de-identify data, we also recommend sharing all participants data and analysis scripts for public use through Github or other mechanisms. This can be used as a case study to recruit participants for your future studies.
5. Apple Guidelines
After you are done with the iOS app development, there is one last hurdle to overcome before launching the study. Submitting your app through the Apple App Store review process – it may take anywhere from 4-7 days for initial and subsequent reviews (although recently, we have noticed the review times go down to 24-48hrs for post launch reviews). The review process will check several things including:
- App Icon: As opposed to normal iOS apps, the ResearchKit apps recommend an icon that is split in half showing the sponsoring institution and the app purpose. See some examples below:
Exceptions are possible as with the case of America Walks (email us to know why
- Battery usage: All apps that use background fetch to update the data or send data to servers require an explicit line about battery use. Here it is:
“Use of the study App may cause some device battery usage but this would be minimal.”
- HealthKit usage: If you app is using HealthKit for data storage or retrieval, then it has to go through another checklist regarding UI/UX and data-use from HealthKit.
In this blog, we have highlighted few key considerations that are integral to developing a ResearchKit study app that require customization beyond the basic modules. In our next article on the series, we have discussed considerations around HIPAA for ResearchKit mobile study app. Keep reading!