Menu

Understanding the THREAD Research Process

Understanding the THREAD Research Process

When you work with THREAD Research to build a connected health app, you don’t just get a vendor; you’ll form a strategic partnership with our team. Curious as to what that might include? Let us walk you through the TRP: THREAD Research process 

The Brainstorm
This is our first meeting together. We like to think of this as an interactive brainstorm, where we’ll put pen to paper and talk about the project. This session helps us understand the goals of the project, who the players are, and how we might go about building it. As our first step together, the interactive brainstorm gives us the foundational elements of the project. 

The Plan
We’ll take all the info gathered from the brainstorm along with any additional information about the project and put together a timeline of when we can accomplish this project. During the timeline creation, our team will also estimate time to do the tasks needed, and from there, we are able to create a statement of work for the project.  

The Specifics
As we begin the project, we’ll begin to identify business requirements and functional specifications. These two exercises help us all figure out how we want the app to work and also help to define what the end user will experience! 

The Prototype
Our process is all about letting you react to things as quickly as possible so we can continue refining and moving toward the same goal. We also believe it’s important to get a sense of user functionality early on to avoid major changes down the road. When you review, you’ll see your app designs through a workable prototype that allows your team to click around and get a sense for both design and functionality. 

The Tasks
Everything that needs to be done to bring the app to life — copy, design, programming, QA, and deployment — all have respective tasks that get assigned to team members to accomplish. We create these tasks and assign them to specific weeks in our overall timeline, and we share that with you so you can track our progress along the way! 

The Takeaway:

Why do we do things this way? Well, once upon a time, we tried an approach where we made a creative brief and then started working on the project. Inevitably, we learned new information along the way that we didn’t account for at the beginning, and the project got slowed down, became more expensive, and there were a lot more headaches for everyone. With this new process, we can get ahead of some of those headaches and account for more things upfront, so that both our team and yours knows what we are getting into before the project is underway.

We have found this process to be collaborative, informative, and successful, and if you choose to work with us, we think you’ll agree! 

Want to get started on your project today? Get in touch with Sean Vassilaros at Sean@HelloTHREAD.com

ResearchKit & CareKit: Defining the Differences

ResearchKit & CareKit: Defining the Differences

Both ResearchKit and CareKit are open source software frameworks that utilize the iPhone to gather and send health-related data. So, what’s the difference between the two? 

Their Purposes.
ResearchKit is designed for medical and health research while CareKit is designed for extending care at various patient intersections. 

Their Benefits.
ResearchKit transforms the iPhone into a powerful tool for research and simplifies the process of finding volunteer participants. It gathers continuous contextualized data that allows researchers to gain a more clear picture. 

CareKit on the other hand creates a better understanding and management around medical conditions. It empowers patients to actively manage their medical condition and share information with their doctor. 

Their Core Modules.
When ResearchKit and CareKit are used right off the shelf, there are important core modules. For ResearchKit, these include: surveys, consent, and active tasks. You can read more about them here. Beyond these core modules, new ones are constantly being built and customized.

For CareKit, the core modules are:

  • Care Card: Remotely delivers and tracks a patient’s assigned care plan
  • Symptom and Assessment Tracker: Allows patients to record objective and subjective measurements related to their medical condition
  • Insights: Provides data visualization of care plan adherence, symptom severities, and assessment performance trends
  • Connect: Shares information and allows for communication with doctors and others

Whether your objectives are care or research-related, we at THREAD Research are pioneers in both spaces and would love to work with you to help you achieve your goals.

Contextualized Research – Now Playing!

Contextualized Research – Now Playing!

Clinical research has followed a tried and true approach for many years. "If it ain't broke, don't fix it," they say. Well, we agree: it's not broken — but we do believe that it can be improved upon. To illustrate this new approach, we're using two (admittedly oversimplified) hypothetical case studies. The first is an example of the status quo. The second is a new way of conducting clinical research: what we at THREAD Research call Contextualized Research.

Current state: standard research

A man named George walks down a Southern California boardwalk. He thinks to himself "It's a gorgeous day for jog. I think I'll ..." Just then George clutches his right arm and winces, kneeling down on one knee in extreme pain.

A few weeks earlier, George had enrolled in a clinical trial at the University of California, Irvine. He has struggled with symptoms of anxiety for years. He's tried everything, but nothing seemed to bring relief. His doctor finally recommended a trial drug called Butrax that has been rumored to be the next big thing in anti-anxiety medication. George jumped at the chance to be involved with the trial.

For the first week of the trial George experienced a significant reduction of symptoms. By week two, he was a believer — "Butrax may actually eliminate my symptoms," George thought to himself. As he walked into the trial research clinic for his weekly check up, he smiled to himself knowing that he was going to be receiving another week's supply of the once-daily Butrax. The research staff were pleased to hear of George's positive results and sent him on his way.

It was about two hours later that George found himself hunched over on that boardwalk, clutching his right arm and writhing in pain.

George had experienced a blood clot. He became the 18th patient to experience this adverse affect from the Butrax clinical trial. The researchers, as well as the drug manufacturers, hadn't seen anything like this in the lab and were baffled as to what could be causing this side effect. Butrax was looking like another highly effective drug that was simply not safe enough.

Alternative state: contextualized research

Now, let's look at this story again — but through the lens of a clinical trial augmented by a few of the many mobile research technologies available today.

Let's pick up where we left off — 18 blood clot incidents that have the researchers scratching their heads. They've come up with a few hypotheses as to what could be causing these issues. However, in this scenario, they have the opportunity to test their theories alongside the data their trial participants have been generating via their mobile devices in between weekly visits to the clinic.

The researchers first hypothesize that the blood clots could be related to high altitude. But, thanks to the geolocation data they had on each patient during and around the time of the incidents, they concluded that like George, many of these individuals were at low elevations at the time of their blood clot.

Researchers next thought the cause could be related to a possible blood sugar issue. Each trial participant had been given a wireless glucose monitor, and all 18 blood clots were associated with low blood sugar … yet there were also participants who showed low blood sugar but did NOT have a blood clot. The data also pointed to low blood oxygen levels shared by all 18, which was reported by the wireless pulse oximeter (worn by participants). But again, there were also those with low pulse-ox that did not end up experiencing blood clots.

So what was it then? Were these exceptions just lucky? The researchers could conclude from the data that if your blood sugar and pulse oxygen levels were low, that you were more likely to generate a blood clot. But that insight still didn't help the researchers connect the dots as to why these blood clots were happening.

It wasn't until they realized that prior to each patient's blood clot incident, activity levels had been high for a sustained period. Each participant in the trial wore a smart band with an accelerometer, gyroscope, and heart rate sensor that supplied this data. Finally, the researchers could see the whole picture. Of the 18 incidents, all 18 displayed low blood sugar, low blood oxygen, and had recently participated in rigorous physical activity.

Now that the researchers had this information, they could successfully complete the trial and go to market. The contextualized knowledge gained from the additional data generated by the 18 participants both rescued the trial and informed future drug development and trials.

Is this approach to trials research really possible?

The short answer — yes. All of these technologies are at our fingertips and our belief is that this is the ONLY way that trial research should be done as we move forward. Join us — this work is too important to not leverage the technologies available.

Off the Shelf: What Apple ResearchKit™ Really Provides Researchers and Where You Need to Customize

Off the Shelf: What Apple ResearchKit™ Really Provides Researchers and Where You Need to Customize

One of the most exciting new things to happen to research and the connected health movement is Apple's ResearchKit app framework. Released in March of 2015, Apple's ResearchKit promises to expand the scope, scale, and breadth of research by allowing researchers to conduct studies on mobile iOS devices and thereby reaching potential participants anywhere. With approximately 400 million iPhones currently in use worldwide (>100 million in the US alone) ResearchKit holds great promise for researchers to go well beyond their local vicinities and to tap into a broader demographic for the collection of richer, more granular data unbound by geography.

Like any new technology however, much of what ResearchKit offers requires additional development before it can be made study ready. Getting a study into the hands of the intended participant, thinking of participants as users, and collecting the resultant data in a meaningful way requires many researchers to involve themselves in things like front-end/back-end development, user interface (UI)/user experience (UX) design, social media, and digital marketing — things that might come more naturally to a Silicon Valley mobile app startup rather than a researcher at a university or medical institution where available resources might not have evolved enough to support them in the new world of connected health.

To ease these challenges, Apple has done some great work in determining what most mobile app studies will need. For instance, most studies will likely want to conduct surveys, perform tasks, and will require a user consent process. Apple has provided these basic study elements as out-of-the-box modules, which in turn can provide a big boost in getting started. Extending these modules, and building beyond them to create a meaningful ResearchKit app, is where the real work begins.

So, how do you get started? To determine this, you’ll need to know the answers to the following five questions:

What does ResearchKit provide off the shelf?

Let's start with what ResearchKit is. ResearchKit is a framework that provides core modules — it is not a fully functioning app right off the shelf. These modules are useful, and in most cases required, for conducting studies in a mobile app environment, as well as for satisfying IRB and HIPAA requirements. Included in the ResearchKit framework are the following:

MODULES

  • Survey Engine: The survey engine provides the core module for building out the shell structure of your surveys. In this form, the survey will be very basic and will likely require some additional development and design depending on the complexity and branching logic of the survey questions.
  • Visual consent flow: The visual consent flow module provides a customizable template to explain the details of your study and obtain a signature from the participant. This is almost always presented in the beginning of the app experience and is typically required by your institutional review board (IRB) or ethics committee. The consent flow can also be used as an opportunity to educate and qualify your participants through a simple questionnaire.
  • Active Tasks: Active tasks are used to invite users to perform activities under semi-controlled conditions, using iPhone sensors to collect data (you can view examples of active tasks here). Active tasks are where you can get really creative with your study, and typically where a lot of your additional development will be focused. For instance, when THREAD Research built EpiWatch, we incorporated a timed walking and resting activity that involved Apple Watch for gathering heart rate and accelerometer data. We see active tasks as a great opportunity to explore the possibilities of ResearchKit by using real-time data to engage the participant in new ways, such as gamification, and research as intervention.

TOOLS

  • Examples in Objective C and Swift programming languages
  • API documentation (for interfacing with your app’s back-end)

What will need to be customized in order to satisfy the study requirements?

Most Researchkit app projects will need customization and development beyond what the basic modules offer and, in fact, I recommend it. By using an iPhone app, participants are no longer in a controlled study environment, and are instead susceptible to habits of content consumption in other apps, attention spans, and user preferences.

Your app needs to keep them engaged to keep them coming back. That brings us to AppCore. AppCore is a layer built on top of ResearchKit and forms the core of the five initial ResearchKit apps. It includes:

  • Dashboard with progress graphs
  • JSON serialization and deserialization

AppCore is still a work in progress and is not as simple to customize as the basic core modules because it is not available in stand-alone form. The work to utilize any part of AppCore in its current state will require a much higher degree of customization and development as it needs to be extracted from one of the open source ResearchKit app projects that use it (can be found here). One of THREAD Research’s biggest focuses is to make AppCore more accessible to researchers and their institutions.

What kind of user interface and user experience design elements can be incorporated so that participants will remain engaged?

One of the best examples of how customization can improve user engagement is the dashboard. The dashboard is a great way to capture the interest of the participant by showing them a visually pleasing representation of their own data, as well as comparisons with other participants.

In the PRIDE study, THREAD Research developed a stunning dashboard which illustrates a “Participants Like Me” graph which users have found to be very engaging. Since the data shown on the dashboard is dynamic, a user can come back each day to see the change in the latest results of their own data, as well as that of their cohorts.

To read more about design and usability, please read our blog post on usability and why it’s important for your mobile study.

How will the data be collected?

ResearchKit does not include a data management solution but the framework can be used with the backend service of your choice. Consideration should be put into the provider’s data privacy and security practices, and you should ensure that those practices satisfy HIPAA compliance.

Other considerations that should be evaluated in your backend provider search:

  • ResearchKit API documentation to determine how your app communicates with your backend
  • How your data is collected
  • How you will gain access to your data
  • Where you plan to conduct your study
  • What your required reach will be
  • How much participation you expect to have
  • What your scalability requirements are

Every study has different requirements and there are a number of services to choose from. My recommendation is to look for a service that can maintain your backend for you so that you don’t have to worry about uptime and server upgrades, and which utilizes a secure and reliable cloud infrastructure such as Amazon Web Services (AWS).

How can I get my study into the hands of more participants?

So you've built your ResearchKit app, now what? Well, now you have to submit it for review by Apple and get it released into the App Store. But then what? How do you let participants know about your study? The answer of course is spreading the word through multiple channels.

To help inform you on some interesting ways to increase study participation and engagement for your research app, I recommend the following blog posts:

Maximizing Patient Enrollment Through Social Media

Applying a Social Currency Model to Increase Mobile Research Engagement

At THREAD Research, our mission is to answer every human biological question, but we can’t do it alone. I encourage you to develop your study for ResearchKit and reach out to us for any questions you might have. ResearchKit may not be an out of the box solution, but with some good planning, savvy development, and well executed customizations, you can provide an extraordinary study experience with the potential to reach well beyond what has been possible before.

Helpful Links

The ResearchKit framework, including modules and tools can be found and downloaded from GitHub here, https://github.com/researchkit/researchkit

Design guidelines for ResearchKit apps can be found here: http://researchkit.org/hig/index.html

API Reference for ResearchKit can be found here: http://researchkit.org/docs/index.html

Maximizing Patient Enrollment through Social Media

Maximizing Patient Enrollment through Social Media

Can you think of any single activity that you do for over an hour each day, aside from your commute? Well, according to GlobalWebIndex, the average user spends 1.72 hours per day on social media. It has quickly become one of our major consumption channels and its usage expands beyond "socializing."

We are beyond justifying IF social media is a valuable component to achieving business goals. But in order to use social media to improve enrollment and engagement in mobile research efforts, we must seek to understand HOW to leverage it. We’ve found that there are three critical components to leveraging social media strategy for mobile research: identifying your social media audience (your potential patient pool, but also the greater support community), understanding the types of content that are relevant to them, and knowing how to spark a movement within this group.

1, 2, 3's of leveraging social media to maximize enrollment:

  • Identify your social media audience: Once you have identified your patient population, you need to identify where that population’s “social neighborhood” is. Where do they spend time online? That is where your message should live. If you are a researcher, know that your partner communication agency or in-house social media manager will be able to gather this data for you.
  • Understand content and context preferences: Does your audience prefer to read bite-sized pieces of content (think mini magazine articles), do they consume more videos, and do they over-index in quiz and interactive content consumption? Again, it’s important for your content to live within the context in which your potential patient pool is engaging with social media.
  • Seek to spark a movement: Remembering that your patients are not scientists, and perhaps not as motivated by the sheer collection of data. The message to them must answer the imperative question in marketing—that is “what’s in it for me?” If your message can express what the patient gets out of participating in the study (understand their sleep patterns, help solve a long-standing public health concern), then you are on your way to sparking a movement because you are cultivating a motivated patient set.

Social Media Done Right

The Amyotrophic Lateral Sclerosis (ALS) Ice Bucket Challenge is a fantastic example of social media engagement done right. Now, it’s important to note that the goal of the challenge was not to enroll patients in a mobile study (although apps like mPower show us that research apps have utility to examine neurological conditions that affect fine motor skills).

The team behind this program understood that their audience most often frequented Facebook (the only major platform that allowed video at the time), posted “look at me” style posts, and loved social capital. The mere act of videotaping oneself pouring ice over your head and calling out another person sparked a movement. A movement so large, in fact, that it took ALS’s average fundraising efforts for that time period from $1.9 million to $31.5 million.

They achieve the 1, 2, 3's of leveraging social media:

Identify your audience: Friends and family of those living with ALS

Understand content and context preferences: Mobile video with a viral component

Seek to spark a movement: By participating in the challenge, and encouraging others to do, they’re getting positive social recognition for doing a good deed.

They didn't ask their audience to be overt about their support for ALS via a post, but rather asked them to play online video tag for a good cause. They didn’t try to provide disease education, fundraising goals, or needs, which might have made more sense to the organization. Harnessing the power of social media often requires that a brand put the audience’s goals ahead of the organization and leave the educating to other channels.

Usability and why it’s important for your mobile study

Usability and why it’s important for your mobile study

Usability is like a well-designed bathroom. I should be able to go into one and expect toilet paper within an arm’s radius of the throne, a soap dispenser close enough to the sink so that I don’t drip water everywhere, and a wastebasket that I can practice my Stephen Curry pull up 3 pointer. When restaurants began replacing their old hand dryers with Dyson Airblades, the construction of the new technology hinted at how I should interact with it and provided just enough direction in the form of a pictorial, should need more assistance figuring it out. It was new, but also familiar.

Your mobile study has to be a well-designed bathroom. A participant should be able to navigate though your study easily and be able to accomplish set tasks without getting flustered or confused, which can lead to drop-off or faulty data. This is where the usability of your app has to shine. And for tasks that are researcher-driven, we have found that there are two key parts to achieving optimal usability: directive and user experience.

Directive

Since the launch of ResearchKit, some members of the research community have voiced their concerns about data integrity because the tasks are performed without the supervision of a proctor. In order for participants to provide accurate data, the app has to provide clear directive and leverage technology to aid the participant in completing the task.

Within ResearchKit, tasks are pushed to participants in the form of Activities. These Activities can be as simple as a multiple-choice survey, or as complex as setting up an additional device that may be required for your study.

In any scenario, its important to think about what you are asking the participant to do, and how he or she will be executing this activity. Let’s say for a muscular dystrophy mobile app study there is an activity that tests for arm stability. The participant is to hold the phone in one hand and extend his arm straight out in front of him for 1 minute, then switch to other hand and perform the same task. Here are two ways we can approach this.

  1. Provide an image of how the phone should be held with a countdown timer to let the participant know when to switch hands.
  2. Provide an image of how the phone should be held with a countdown timer to let the participant know when to switch hands. When the minute is up, provide haptic feedback (a vibration), alerting him that it is time to switch hands.

The second option with the addition of haptics drastically improves the usability of the app. A minute can be a long time and a user may become momentarily distracted by something else during this time. Switching hands late may result in false positives.

User Experience

The dynamic that changes with a mobile study app is that the participant is no longer on your time; you are on their time. She is not in your office at your disposal. She is at home and at work, with numerous opportunities for distractions and interruptions. Participants want the mobile research experience to fit into their lifestyle.

They want familiar controls and an exceptional user experience that they have been accustomed to from their iPhone or Android devices. While she may expect these things, the experience should almost feel invisible to her. Sometimes the best experience is to feel as if every control, button, or tool, is right where she expects it to be; it should not be overstated, it should simply be right.

When designing your mobile study app, rely on what users already know. Leverage their phone’s native operating system user interface (UI) when possible, allowing for a cohesive experience that marries right into the device that she considers an extension of her. Consider gesture controls — swiping, pinching, force touch — that are now second nature to the average smartphone user.

When introducing a new feature or an improvement upon an existing feature, like the Dyson Airblade, evaluate how the end user will approach it, what familiar or new experience you want him or her to feel. Do you need 20 different customizable ways to achieve the same task? Or is one or two streamlined ways sufficient? Some times a doorknob just needs to be a doorknob.

Let these two tenets be your guardrails when designing the usability of your mobile study. Of course the design will change and pivot depending on your participants. Your study’s cohort age, mobility, eyesight, and a number of other traits will ultimately guide the design process. The most usable bathroom doesn’t always translate to a modern hands-free experience; a bathroom at a senior home will have handrails, brighter lighting, lower shelf heights, and rubber mats to prevent slipping. All in the name of usability.

Securing Funding for Your Mobile Research: It Starts With Your Research Grant

Securing Funding for Your Mobile Research: It Starts With Your Research Grant

Research conducted in 2015 from the Pew Research Center paints a compelling picture about how Americans are using mobile technology, particularly "smart phones" with internet access, as part of their daily life. A few tidbits:

  • 64% of American adults now own a smartphone (Approx 158M according to 2015 U.S. Census Data)
  • 62% of those smartphone owners have looked for health-related information through their smartphone in the last year (Approx 98M)

While this data is certainly not surprising, it is indicative of a big opportunity when it comes to patient data in medical research. But acknowledging the opportunity is only half the battle—how do researchers bake this into their grant writing process to make mobile research a reality for them?

It comes down to augmenting three key segments of the well-known grant model:

  1. Methodology
  2. Budget
  3. Timing

And adding a section that may potentially be new to some of us: technology.

Methodology: Define your data collection methods

Here's where it's important to define if mobile data collection will be a companion to traditional (i.e. in-clinic, hand-written surveys) means of your data collection, or the primary means of your patient data collection. There are emerging models that offer a spectrum of utility for mobile health (mHealth) research applications:

Traditional: In-clinic visit, self-reported offline surveys (no mHealth component)

Hybrid: In-clinic visits + patient "homework" (i.e. mobile data collection)

Mobile: Patient mobile data collection (all mHeath)

Depending upon your target funding source, you may find varying levels of comfort with more novel data collection approaches. The National Institutes of Health (NIH) and other organizations have allocated funding particularly for mHealth research, so that is a great indicator that utilizing mobile health for primary data collection is not so far fetched.

Once you define your methodology based upon the models above—and for the sake of this information we're assuming at least the hybrid model will be your intended methodology—you need to further define the use of active or passive mobile data collection:

ACTIVE DATA COLLECTION:

This is the most straight forward use of mHealth apps as it stands today. This is mostly defined as surveys completed by the patient. Apple's ResearchKit has several off-the-shelf modules ready to go, including a survey module, consent, and active tasks (which invites patients to complete specific tasks).

PASSIVE DATA COLLECTION:

The automatic collection of "sensed" patient data as it is available through custom or off-the-shelf solutions like Apple's ResearchKit. Right now this includes accelerometer data (speed in which the phone moves), and gyroscopic data (tilt motion) with the iPhone, so the utility of those can be applied to certain conditions, but would most likely be within the context of an "active task" mentioned above. Where passive data collection gets exciting is on the Apple Watch, which allows for more biometric data to be collected including heart rate and physical activity. The use of the Watch in app form must be coupled with a phone app, so there are certain costs of entry in this form of data collection. It also requires that the patient have an Apple Watch, which has a lower adoption rate at present than the iPhone.

Budget:

Creating line items for everything you need is difficult when you're unfamiliar with the technology solutions you will ultimately need. That said, you will need to allocate cost for:

App discovery: What you would like your mobile research app to do vs what is actually feasible with the available technology

App design: The money associated with creating the visual interface that your patients will experience with as they participate in the surveys, active tasks, etc.

App development: The money associated with building the app itself, as well as any testing of or maintenance to the app to make sure it works and can be improved as you get initial patient feedback

A third-party design vendor will be able to furnish any hard costs for you associated with planning for, designing, and building your app. Your job in the grant writing process is to collaborate with a vendor early on to help you establish these costs. Another option is to partner with another researcher who has received grant money for an app and ask for their input.

An element to consider in working with an app vendor is their ability to provide all of the aforementioned services. Will they design the app based on your specifications, but need help actually building it? If so, you may need another third-party collaborator. This is an important and often overlooked area of clarification. If you do not allocate budget for design, or allocate budget for development with a vendor who does not also design your app, you could run into a funding obstacle.

Alternatively, if you are affiliated with an academic or research institution, you may be able to tap into their technology team (or Information Technology group) for some of these services, which may bring down the cost. Many institutions have a technology team that can assist researchers, and the projects they work on now include the building and maintenance of online registration databases for clinical trial enrollment. If you're unsure what services your institution provides, reach out to a technology representative and inquire. You may be surprised at the breadth of services they offer.

Timing

Creating time-based milestones for a mobile research app is largely dependent upon the complexity of the app. A very basic app comprised of consent and survey modules with very little design can be spun up in as quickly as 3-4 weeks. But the important thing to remember here is that an app is only as effective as a patient's willingness to use it. The more intuitive the design, the more added features prompt user engagement, then the more qualitative and quantitative data you will derive from your research app.

It is important to balance the benefits of having a quickly developed app versus a highly usable app. If the goal is quality data, you may want to allow more timing (and budget) in your grant for discovery and design.

Technology

For some, this is an entirely new element to their existing grant format. But mobile health apps require information on the intended technology solution because the complexity of the solution will impact budget, timing, patient reach, and so forth. It absolutely cannot be omitted for any mHealth research grant application.

By and large your technology solution will be focused on software – that is the actual application for patient data collection. But you will need to explain how you're collecting data, where the data will be stored, how you will keep that data secure, and how you will access that data to analyze your findings.

Data collection: Data will usually be collected through your mobile application (how the patients will provide that data, and how patients will consent to the provision of their data, should be covered in your methodology)

Data storage: The patient data has to go somewhere for you to be able to access it. That somewhere is usually a server at a fixed location, or in a cloud-based location, wherein you and your other investigators will have access to it.

Data security: The most important aspect of data storage is security—you must have means for keeping the digital data secure, just as you would with a locked file cabinet for your hard copy patient records. HIPAA compliancy must be adhered to and referenced in your grant submission.

Data analysis: How will the data be served to you once it has been collected? There needs to be an understanding of what computer database application will receive your data and make it possible for you to analyze your results. The benefit with several off-the-shelf data applications is that they offer HIPAA compliant security on their portion of the data storage and transfer. That is to say, their receipt of the data and presentation of the data meets HIPAA compliance criteria.

This is an introduction to the elements that will be impacted when submitting for a medical research mobile application grant. Speak with your institution and fellow researchers on what services are provided that may assist you as you develop your mobile research idea. Once you have a comprehension for all the steps involved, the grant submission is just a matter of documenting your idea.

Good luck!

Applying a social currency model to increase mobile research engagement

Applying a social currency model to increase mobile research engagement

Demonstrating long-term mobile research engagement is perhaps one of most discussed topics in mobile research today. Will patients engage beyond the first 30, 60, or 90 days? Will we be able to get the full amount of data we need? These are surely questions researchers are asking themselves as their first mobile research app launches.

Engagement requires a coordinated effort between the study parameters, the actual design and usability of the mobile app, and the surrounding marketing effort to sustain engagement. This marketing effort could be as small as a monthly e-mail check in with your study population. Or it could be a full-blown social currency program that let’s study participants be rewarded for and show their pride in participation of your study.

A big caveat to this is sensitivity to the patient population. An outward-facing social program is certainly not appropriate for mobile research apps focused on conditions with a perceived stigma—direct marketing to that patient population is the best way to maintain this group’s privacy while supporting engagement.

Social Currency in a Nutshell

Social currency is your cause’s (or study’s) value in its ability to be shared with your patient population or the public at large. Any marketing effort that allows them to “belong” to your study and be part of the greater good is where that value lies. It can extend beyond the study to the actual population or disease state that is the focus of the study. If there is any pride of participation in the study that would compel a participant to want to let the world know, that’s social currency. And leveraging that can do wonders for engagement.

Rewarding Study Participation with High-Quality Social Content

The omnipresence of social media in our daily lives has made content curators of us all. Think of it this way: when do you post to Facebook? After making a sandwich, when taking out the trash, or at your daughter’s high-school graduation? Probably the graduation, right? And do you pick and choose what you share with your group, saving only the most relevant and powerful content to associate with? In doing both of these—sharing the graduation (not the sandwich), and only sharing the most credible news article, you are in essence curating content. You are your own social media editor.

With a social currency program, you are giving your study participants credible, "feel good", accomplishment-based content they can share with their community. This is the digital version of the check plus on the chalkboard. This is the “I Voted!” sticker on lapels in November. This is the pink donor indicator on your Driver’s License. It tells the world "I am participating in something meaningful…take a look!"

So a social currency content model could look like this:

  • Every participant can download a “I’m a Participant” Facebook Profile Picture
  • Participants that participate every day for one month in mobile research app get a congratulations notification they can share via social media
  • Participants that post every day for two months in the mobile research app get a congratulations notification they can share via social plus a customizable Facebook profile picture
  • Additional content can be deployed for longer engagement periods

Again, the point here is to reward higher engagement with more credible, shareable content. The content must be worthy of a share, it must make the participant feel good and excited in order for it to be shared.

Why Social Currency Content Helps Your Mobile Research

What we're looking to do here is two-fold:

  • Increase engagement within your study population and
  • Get the halo effect of others outside of the study seeing your patient population share content related to your research

It's not difficult to do, but it does need to be designed into your study experience so that the patient feels instant gratification once they’ve reached a new level of engagement. This becomes a key component of your mobile research retention efforts—this can be a “set it and forget it” aspect of your app that supports your patients without having to make unique outreach efforts to specific patients (which is a high cost activity better used for customer service efforts or medical questions).

With social currency content wrapped around your mobile research app, you will see your research app become quite the social media sensation. It’s definitely a new era for research, but with patients now responsible for their own engagement, this is the new way to play on their court.