In a previous blog post, we talked about the benefits and challenges of ResearchKit and ResearchStack. These frameworks can help researchers reach a larger audience, make electronic informed consent easier, and lower the time and cost required to develop a research application. Even with this, there is still a lot of software development required before you can get your app out to people. In order to save data from your study, there needs to be a backend where the app can send participant data to be managed and processed by researchers. Unfortunately, this can require significant custom development that results in a bill that is too large for the average study.While every study has different requirements, many mobile research studies have a lot in common. Almost every study needs a place for participants to register, sign in, update their profiles, and send their electronic consent. These participants generate data for the study through taking surveys, playing games, or connecting devices to their phones to take physical measurements. These similarities made us ask a simple question: what if we could save researchers time and money by building a backend that meets the needs of most research studies?We set out to do just that. We would build a backend that would handle these needs while still being flexible enough to handle any study's data. What we came up with was a suite of tools that fall into three main components: a Participant API, a Researcher Portal, and a Researcher API.
The Participant API
The bread and butter of our backend is the Participant API, which handles all of the communication with smartphones running a study application. In addition to handling participant authentication and consent, it provides a hybrid approach to data that requires specific data in some parts, but allows the study designer to use whatever data they would like elsewhere. As an example, when a Survey is sent from the study app to the backend, there are certain things that are required, like the ID of the participant who took the survey, the time the survey was completed, and what type of survey it is. Outside of these few things, the application is free to provide whatever arbitrary data it would like to. For example, consider a weight management application that might have a calorie counting or weight tracking component. Data could be input from an on-screen survey, collected from a smart scale or Fitbit, or taken in from third party services like GoogleFit without any additional work on the backend.Participant profiles work in the same way. There are some fields that are required, like email, but some researchers may want to store data about the participant that is custom to their study. Taking the same example as before, the study may ask the participant what their current or ideal weight is when they are registering.
The Researcher Portal
Once participants are using your app, there needs to be a way to access and manage the data they are sending. The Researcher Portal provides a web application that allows researchers to sign in and manage their application. From this panel, researchers can create new studies, access participant and survey data, and find documentation for the Participant and Researcher APIs. This is also where electronic informed consents can be found and downloaded.
The Researcher API
While the features mentioned above were designed to cover most use cases, there will be times that a study has needs to go above and beyond what the backend can offer. Instead of modifying the backend in those cases, we are working on a Researcher API that allows additional applications to extend the functionality of the suite. Things like live analytics, data dashboards, and tools to help format data can be built outside of the backend and integrated into the final solution.We have gotten great feedback on the suite so far, and are excited to get it out there to more people. By not having to develop a custom backend per study, researchers and the organizations they work for can receive a ton of benefits from switching to a solution like this.One server can handle multiple studiesSince the backend does not use a custom data structure, many studies can be run from the same server, saving operations and maintenance costs.A common backend lowers the barrier of entry for researchersWith a common backend, the cost of a common backend can be split at an organizational level instead of at the study level. This enables smaller studies to be able to leverage the power of a mobile research study.Since the API is the same across studies, an organization saves time in the app development itselfThe mobile application can be started sooner and use existing interface code to reduce the total time taken to get a mobile research study into the hands of users. There is also a significant amount of testing time that is saved since the backend is already a production-ready product.
