Teleheath - Team 8 (PainTrackr)


COVID-19 has resulted in a rapid expansion of the Telehealth industry. It was previously simply a growing industry but now has to quickly adapt to new circumstances as patients avoid leaving their homes and clinicians encourage patients to use Telehealth services when possible. To reduce the risk of patients and clinicians contracting COVID-19, our team determined that increasing the effectiveness of Telehealth was one of the best options to eliminate unnecessary exposure to the virus.

In order to improve communication and efficiency, our team has created an application, PainTrackr, to assist chronic pain patients in easily reporting their symptoms and conveying that information in a comprehensive overview for clinicians. Among other functions, PainTrackr enables patients to record their soft symptoms and keep track of medications. Additionally, the application compiles the patient’s data for the trailing two weeks into a report, which the patient can send to their doctor. The overarching objective of the application is to increase the effectiveness and viability of patient and clinician interactions in order to reduce the spread of COVID-19.

Team Members

Ash Fowler (Software Engineer, Senior Computer Science at Rose-Hulman Institute of Technology) Ash conducted research on what databases and applications would work best for our desired functionality. They also created the base for the low fidelity prototype and programmed the high fidelity prototype. Additionally, they programmed the Android Application.

Patrick Haimbaugh (Software Engineer, Junior Computer Science at Purdue University) Patrick helped decide what technologies to use for the application, such as IOS or android, and what kind of database would best suit the app. He also consulted with mobile developers in the field to get a better understanding of what was feasible for the time frame.

Jacob Haggarty (Business Development, Sophomore Finance, Accounting, and Business Analytics at Indiana University in Bloomington) Jacob acted as a liaison between the Pro Squad and the Go Squad during this challenge. As a business analyst, Jacob compiled business-side research essential to our ideation process and built the presentation for our final pitch.

Claire Mihalko (Business Analyst, Junior Chemical Engineering and Chemistry at Rose-Hulman Institute of Technology) Claire was responsible for documentation of meetings and work materials for effective team communication. They also were responsible for completing most of the abstract and working on the content for the pdfs. They also conducted interviews with industry professionals.

Alex Smith (Project Manager, Junior Biology at Washington University in St. Louis) Alex was responsible for scheduling all meetings with the team as a whole and the Go Squad meetings. He also interviewed two doctors and gathered their insight on the product. He created the pdfs that were eventually submitted into DevPost.

Jayanth Tatikonda (UX Design, Sophomore Biomedical Engineering at University of Michigan) Jayanth put together the initial design and algorithm for the application. He also implemented feedback about user experience from a healthcare entrepreneur. Additionally, Jayanth kept the Pro Squad on track and helped develop the method for clinician and patient interaction.

Research and Decision Process

Our team conducted market research and consulted the SMEs to identify the types of patients that would benefit from the most help, as well as the service that was most viable. From this, we learned that the 3 primary sectors of the Telehealth market are:

  1. Medical Devices and Hardware
  2. Software
  3. Virtual Physician Visits

Additionally, the major segmentation of the market is for these 5 conditions:

  1. Congestive Heart Failure
  2. Diabetes
  3. Chronic Obstructive Pulmonary Disease
  4. Hypertension
  5. Mental Health

Based on this research, our team decided to create an application to help chronic pain patients manage their conditions and better communicate with their clinicians in a virtual format. This application is practical as it makes virtual appointments more valuable and viable in order to reduce or eliminate the need for in-person appointments. We decided to focus on patients with chronic pain because the market is not saturated with existing products for this condition and under normal circumstances patients would need to go in regularly. We also decided that our early adopters would be chronic pain patients in COVID-19 hotspots looking for a new way to manage their symptoms and communicate with clinicians.

Solution Iteration Process

We conducted extensive research using professional databases such as Mintel Academic and IBIS World to construct a detailed image of our consumer and the industry. This researched allowed us to move to the brainstorming stage and sketch a low-fidelity prototype on paper. This prototype allowed us to look at and interact with a tangible product in order to better understand the potential functionality, user interface, and organization of our application. As new information from our research was learned, we planned to adapt the application to our needs.

After consulting with SMEs and other industry contacts we learned that it is most effective for patients with chronic pain to record information about soft, non-quantitative, symptoms. We also learn that it is best to communicate the information in a comprehensive report so clinicians can easily attach the information to the patient’s Electronic Medical Record. We next developed a high-fidelity prototype using Figma in order to ease future progress and expansion of our app. This prototype allowed us to do preliminary testing and further determine the concepts and functionality of our product in a manner that was similar to our final product.

After limited user testing by a person with chronic pain, we learned functions focusing on goals and quality of life are incredibly important. We ultimately used Android Studio and Firebase to create our final app and build its function. These final functions include the ability to add/edit symptoms, add/edit medications, view educational resources, achieve badges, and look over previous data.

Key Metrics


  • Impressions from ads
  • Videos
  • Interstitial
  • Offerwall

Customer Discovery

  • Number of Downloads
  • Number of Daily Users, log in instances
  • Customer Reviews

Technical Architecture

GitHub Repository

High-Fidelity Prototype (Figma)

Firebase Schema Firebase Schema

Android Mobile Application Architecture Android Mobile Application Architecture

Key Tools, Libraries, and Frameworks

  • Android Studio (in Kotlin): We chose to use Android Studio in Kotlin to code our mobile application because it was a language and program our team had used previously. Given we only had 5 weeks, we believed Android Studio would allow us to develop the primary features for our application.

  • Figma: We used Figma to design and improve our high-fidelity prototypes. Figma made it possible to detail the look of our final product as well as play around with interactions within the application.

  • Firebase: Firebase was used as our database to store information as well as work with user authentication. Firebase was chosen because it allows for real time data syncs across devices, splitting data across multiple databases, and allows for users to access their data while offline, pushing changes when the connection is restored.

  • MPAndroidChart Library: MPAndroidChart’s Library was used to plot user data as it is a free open source library with many powerful plotting tools and animation features.

If Given Another 5 Weeks...

Interview More Potential Customers

  • We were only able to interview a limited number of people from our target markets, so we would interview more people. We would talk with a minimum of 10 more patients and clinicians before finalizing our design.

  • We were also unable to do user testing outside of our team (one team member is a chronic pain patient), so we plan on finding 10 patients and testing the application for a week with them. Additionally, we would conduct A/B testing, to finalize choices for individual elements of design.

Prove Our Adaptability

  • The current state of the application is the minimum viable product. That being said, our application retains full functionality and highlights unique features that provide value to the patient. As outlined in our presentation, our ideas for the expansion of the application include:
    • Increase the functions available for chronic pain patients, such as adding physical therapy regimens and tutorials.
    • Ideas to encourage patient interaction, user retention, and increase the number of users. These are primarily social interactions, such as adding a function for a friend circle and giving the option to post to a specific hashtag, #PainTrackr, to share their progress.
    • Ideas to increase the number of conditions the application works with; these changes would be mostly minor depending on the condition.

Solidify Our Revenue Streams

  • Build a user base before increasing user costs. Initially, we would start with in-app ads, later moving to a Pro+ v. Lite model, and finally a subscription-based service.

Increase Our Outreach

  • Develop strategic partnerships with large hospital systems, enabling us to build a larger market for our product and encouraging patient use through the way of their doctor.


“Chronic Pain Information Page.” National Institute of Neurological Disorders and Stroke, U.S. Department of Health and Human Services,

Login. (n.d.). Retrieved July 24, 2020, from

Kiesel, Laura. “Chronic Pain: The ‘Invisible’ Disability.” Harvard Health Blog, 28 Apr. 2017,

Built With

+ 3 more
Share this project: