February 15, 2016

In January, the Office of Research Informatics hosted a ResearchKit Summit. For those of you not familiar, ResearchKit is a programming toolkit released by Apple, in 2015, that provides a common way to enroll participants in your study and to gather survey and activity data using their phone or tablet. This is a really powerful new addition to our technology toolbox for conducting research as it allows us to greatly expand the reach and scale of our studies; the heart research app launched with ResearchKit enrolled 30,000 participants in the first two weeks. But, being an iOS only solution, it has the potential to greatly bias study results so it isn’t a panacea to research. The summit was well attended, with chairs for 120 and easily 150 attending, and there were presentations about ResearchKit by Apple Education, the look-and-feel of ResearchKit apps by Ricky Bloomfield, and about two studies leveraging ResearchKit at Duke: Autism & Beyond and The Sixth Vital Sign. (One lucky attendee even won an iPad.) As one of the lead developers  for the Autism & Beyond app, it was rewarding to see how well participation in the study was going and that the quality of the results was exceeding our expectations.

ResearchKit provides a lot of opportunities for research teams, but there are several key things that are desperately needed at Duke to facilitate and greatly reduce the cost of conducting research by leveraging ResearchKit. I’d like to touch on three: a patient facing research portal, a unified back-end, and an Android solution.

One key component of ResearchKit is it’s ability to consent study participants on their personal Apple devices (iPhones, iPads, and iPod Touches). This drastically reduces the amount of personal interaction we have with participants and has its own set of pros and cons. Obviously, if we aren’t purposeful with our consent language there is a greater chance they won’t really be informed, but the reduction in costs related to consent and the vast participant pool… the possibilities of putting a research portal into the hands of the public  is huge. Imagine signing into a research portal and seeing not only a list of studies you’ve participated in, but also that, because of your participation, 23 papers were published, 3 investigational drugs were brought to market, 6 new diagnostic tools were developed, and 18 subsequent studies were launched  (and by the way, would you be interested in participating in one of them?) Since the portal is integrated with your EHR, you could see additional studies not only based upon your interests, but also your health record and geographic location [Hmmm,  what studies are going on near me that I might be qualified  for?] This could spark a new style of two-way, community driven, communication and really engage the public and show them why their participation is so important. As an aside, the consent capabilities in ResearchKit don’t need to be limited to research – patients are consented everyday for surgeries too.

But while ResearchKit helps us collect data, it doesn’t provide a way to send that data from the device back to Duke. And building custom back-ends is expensive. They generally  are never re- used. We keep building them again, and again, and again; each time creating something similar to the last but adding something unique to meet the exact needs of that study.  We really need to change this pattern.  Are all studies the same? No. But we can create a shared back-end,  reusable for just about every study, that we invest in heavily at first and then incrementally enhance as we move forward. There will always be the need to add some bit of functionality that is localized to a specific study, but we can facilitate this in the architecture of the back-end so that we don’t need to recreate the wheel over and over again. [Imagine if we had a similar, shareable toolkit for the mobile apps as well.] We would obviously need a solution to extract the data from this back-end into a location and format suitable for analysis, but that’s doable (and repeatable) as well.

Lastly, in many ways, the biggest limitation to using ResearchKit is that it is only available on iOS devices. While actual statistics are not easily obtained, Android holds roughly two thirds of the mobile market globally,  while iOS holds the remaining third. In countries like the US and Great Britain, the ratio is much closer with iOS holding 40% of the market, but in most other countries Android use has a significant lead (often due to economic reasons alone.) There are two separate efforts to bring ResearchKit to the Android platform, ResearchStack and Applied  Informatics, but no studies have been launched  using them yet. ResearchStack is a freely available, open source solution and they are trying to make porting ResearchKit apps to their framework fairly simple if developers  follow a common pattern used by the 5 original  ResearchKit apps, while Applied Informatics’ solution is fee-based. I’m convinced that without a healthy solution for the Android platform, ResearchKit will never reach its full potential.

I’m excited to see these things come to fruition in the coming  months and years. If you’ve got some ideas or a potential project, we’d love to hear more. If we don’t have an exact fit for your idea / project within DIHI, I’m sure we’ll be able to point you in the right direction.  Contact DIHI, regarding collaborative opportunities, here.

 

Mike Revoir,

Solutions Architect, DIHI