Clone this wiki locally
These materials are for informational purposes only and do not constitute legal advice. You should contact an attorney to obtain advice with respect to the development of a research app and any applicable laws.
ResearchKit Framework Best Practices
This page documents lessons learned while developing and testing applications using the ResearchKit™ framework.
Contribute to the Community
Our hope is that users of the ResearchKit framework will contribute new modules (surveys, active tasks, data visualizations, etc.) back to the community so that researchers around the world can leverage these both for new studies and to simplify reproducing the results that others have reported. See Contributing.
If you would like to see new features but don't have the resources to build and contribute them yourself, do file a bug in our issue tracker so that the community as a whole can evaluate all options when allocating resources.
Participant safety and well being should be central to any study conducted using the ResearchKit framework. For best practices, you should consider seeking review of your research study by an IRB or Ethics Committee (EC). In many cases, this may be required by law.
The Consent functionality in the ResearchKit framework is only intended as a tool; the details of the Consent functionality in your application are your responsibility.
Primary guidance should come from your IRB or EC, but here are some additional resources that may help you consider the issues.
- The iOS Developer Program License Agreement includes relevant requirements for health-related research:
Apps conducting health-related human subject research must obtain consent from participants or, in the case of minors, their parent or guardian. Such consent must include the (a) nature, purpose, and duration of the research; (b) procedures, risks, and benefits to the participant; (c) information about confidentiality and handling of data (including any sharing with third parties); (d) a point of contact for participant questions; and (e) the withdrawal process.
The FDA has recently released draft guidance on electronic informed consent: Use of Electronic Informed Consent in Clinical Investigations, Questions and Answers
Consider including a cryptographic signature to protect the consent process.
Consider the level of identity verification required to obtain a valid consent.
Consider whether you can provide for prospective participants to ask additional questions once they have reviewed your consent material. This is a key aspect of in-person consent, and in some studies it may be very important to preserve this.
If your study may recruit minors as participants, you must ensure that you are obtaining consent from the parent or guardian rather than from the minor.
Participants should have granular control over what data they choose to share with the study.
If you intend to share the collected data with other researchers, participants must be able to control whether their data is included in this.
Participants should be able to leave a research study at any time if they so choose.
Participant privacy is a core value. Research apps should ensure highest levels of security to maintain the privacy of one’s data.
Transparency builds trust. Participants should be told up front exactly what enrolling in the study would mean for them, what data they are contributing, and who may have access to the data.
Use touch ID or PIN access to control access to your app, if your app records or displays personal data.
Do not use iCloud to store health information.
The flip side of privacy is data security.
Use the highest level of file protection possible for the given use case. Usually this should be
NSFileProtectionCompleteUnlessOpen. This way, files stored by your app are encrypted automatically whenever the device is locked.
Do not keep personal data for longer than necessary for your app to function.
When transmitting data via networks that terminate SSL early, or when contemplating a store and forward mechanism of any kind for your research data, consider an extra cryptographic wrapper for the data to protect it end to end. For example, a Cryptographic Message Syntax (CMS) envelope, the same technology used in S/MIME, can be used to encrypt data before transmission.
Apple builds products to be accessible to people with disabilities by default, and the ResearchKit framework should meet this standard. While certain tasks and activities and their corresponding results might be more relevant to perform and view by sighted users, or users with certain diseases, it is important that all UI can be explored and navigated using VoiceOver, Apple’s built-in screen reader for the blind. Failing on this promise could leave users stuck in areas of ResearchKit apps that are inaccessible, or even make them unwilling to consent to relevant studies, because of insecurity caused by inaccessibility.
As a minimum, when adding new UI to the ResearchKit framework, follow these steps:
All UI elements should be reachable with VoiceOver enabled, and have proper accessibility labels.
Add accessibility hints and traits to describe UI elements whose purposes might be difficult to describe with just a label.
Actions such as tapping, swiping and other interaction with UI elements, should be possible to perform with VoiceOver enabled.
When possible, follow the accessibility conventions and patterns embraced by Apple's own apps.
Refer to the Accessibility Programming Guide for iOS for more detailed information.
Embed the ResearchKit framework as an embedded dynamic framework in your app.
Give your ResearchKit tasks context by using instruction steps at the beginning of your task. This also allows for clean presentation of any requests for data access.
If your tasks and questions are maintained in a database, have unique keys for them and propagate these through ResearchKit model objects like
ORKOrderedTaskand into ResearchKit results.