The challenge in medical research
Medical research faces a significant challenge when it comes to study recruitment and retention. Many studies target potential participants in-person by asking patients while at their doctor’s appointments, or by hanging flyers around the office, waiting room, or hospital. Others send out loads of snail mail or email. With this approach, only a limited sample can be reached, and out of those, a smaller number will be eligible — and out of those, an even smaller number will enroll! Clearly, studies would benefit from larger enrollment, but reaching potential participants is a bear. And with all of that effort (and cost) expended on enrollment, what about keeping your participants engaged in the study longitudinally?
With much of the general population owning a mobile device, it is easier for researchers to get through to potential participants via their smartphone than to hope an eligible participant happens to walk into their research facility. And as for the participants, interacting with their smartphone is a much more convenient, natural way to be involved in a study than to physically travel to different sites or manage their mail.
Apple ResearchKit: the dawn of a new era for medical research?
Even with all of these benefits to using mobile devices to perform research, software is expensive and rarely the specialty of researchers. The time, money, expertise, and resources needed to build an app often make for an insurmountable barrier for researchers to use the technology. Apple released ResearchKit as the first step to reducing this barrier.
ResearchKit is an open source iOS framework that helps medical researchers, alongside developers, build research study apps faster. Developers can leverage its code snippets to incorporate ResearchKit’s core functionality of eligibility verification, obtaining electronic informed consent, enrollment, and the collection of survey information and data from active tasks (using the available iPhone hardware).
Released in March of 2015, ResearchKit was touted as beginning a new era in medical research. In this new world, apps would be easy to build and release using ResearchKit’s open source code, and enrolling large numbers of participants would be as easy as publishing an app in the App Store.
Why the Slow Adoption of ResearchKit?
In fact, simultaneous to the release of ResearchKit, five medical research applications using the ResearchKit framework were published on the Apple App Store. One of these, Stanford’s MyHeart Counts study, enrolled 10,000 participants in its first day(!), something that researchers said would have taken at least one year and some 50 medical centers to accomplish using traditional methods.
Despite this and other successes, only a couple dozen apps in the eighteen months since ResearchKit was released have made their way into the App Store and the hands of research participants. We haven’t seen wide adoption despite clear evidence for the power of mobile applications to significantly improve the medical research landscape. Why not?
To answer that question, let’s take a more detailed look at the components necessary to build a research study application. At a minimum, there are three necessary components:
- A way to gather data from participants (we’ll call this the mobile app)
- A place to send and store the data collected from the phones (a backend)
- A way for researchers to access the data (a researcher portal)
Let’s consider these pieces one at a time.
1. Mobile App: A way to gather data from participants
Your research participants engage with your study through the iPhone. And here’s where ResearchKit comes in: it provides a scaffolding and code snippets to facilitate building many standard pieces of a research application, like informed consent and basic surveys. By providing this, using ResearchKit can likely cut development time and expenses for an iPhone research application by up to half.
On top of this scaffolding, most apps will have some customization in the code (for various behaviors, designs, or data collection) that will need to be added. For example, the cool custom facial recognition functionality programmed into Duke’s Autism & Beyond research app took some extra effort on top of what was supplied by the Research Kit framework. But even with little-to-no customization, an iOS developer will still need to tie everything together.
2. Backend: A place to send and store the data collected from the phones
Your study collects data from numerous participants (hopefully hundreds, even thousands!). All of this data, collected from each participant’s iPhone, needs to be sent and stored in a single, secure location. We can call this the “backend,” which would include at minimum a database, but could also include custom study behavior such as participant/data randomization. Especially with health research, data privacy and security are paramount, adding to the time and expense to build an effective and safe backend.
Unfortunately, ResearchKit does not include any of this. Whether you choose to use ResearchKit or to build a custom user interface (aka the “front-end”), the cost to build the backend of the app is exactly the same as it would have been without the framework.
3. Researcher Portal: A way for researchers to access the data
Let’s say you have successfully built an iPhone app for your research participants and are sending that data to a secure backend. At this point, you would still be missing a central piece of your research study – how you access this data! After all, you need to see, export, and manipulate this valuable data to respond to your hypothesis and to draw conclusions. We call this the researcher portal.
A good researcher portal could be something as simple as a button that allows you to export your data as a CSV file, but even this minimal option has lots of hidden elements. Where do you go to click this button, accessing your data? How do you ensure privacy and security – that only the people who should have access can see the data? While none of these problems is insurmountable, it adds additional necessary complexity to your software, which at the end of the day translates to more time and money needed to build your research application.
ResearchKit does not provide any of the pieces needed for the researcher portal, either.
As we’ve described above, an effective mobile research application needs three components: a mobile app (to gather the data and disseminate information), a backend (to store the data and information), and a researcher portal (to manipulate and explore the data). Currently, ResearchKit only addresses the first component – building the iPhone application with which the participant engages – but not the others. Overall, ResearchKit decreases the time and money required to launch a medical research application, but it doesn’t effectively reduce it enough to bring a complete application within budgetary reach of most medical researchers. There’s still significant time and expense for the backend and portal. And we feel that this is what has slowed the adoption of ResearchKit and mobile medical research studies, in general.
All in all, ResearchKit is an excellent start. It has created a standardized set of building blocks for mobile research applications (and ResearchStack promises to do the same for Android users) – but it’s just the start. For us, the next step is to create complementary standardized software for the backend and researcher portal portions in these apps to lower the barrier of time and expense even further. To bring it within reach of medical researchers. We’re excited to say that we’ve done that. You can learn more about it in our next post!