## Introduction

Today, America's healthcare system is plagued with gaps and inefficiencies. Before visiting a new healthcare provider, patients are unable to compare various healthcare providers before choosing one that best suits them. After their visit, healthcare providers must call patients individually to check in on how they're doing and answer any questions that patients may have. There is no standard system that patients can use to give feedback and frequent non-urgent updates to their healthcare providers. That's why we made Thrive!

## Our solution

Thrive is a platform that aims to guide patients at every step of the process of seeking and receiving care. Patients can search for healthcare providers and read reviews on them before scheduling an appointment. After visiting the doctor, Thrive will remind them to take any medications they were prescribed and leave a review for the healthcare provider they visited. Doctors and patients can easily communicate with each other through the in-app chat feature. As more and more patients submit feedback and ratings, doctors can see how they compare to their peers and what areas they can improve in.

The iOS app is geared towards patients who are on-the-go and need a simple, streamlined process of submitting daily feedback and writing reviews about their healthcare providers. The desktop app is geared towards healthcare providers, who need an easy way to monitor and communicate with many patients at once.

## Building it

Our team of three has experience across iOS development, web development, and UI/UX design. Knowing that our goal was ambitious, we scoped our goal for the hackathon to create a working prototype that demonstrates the value proposition of the idea. We took the divide and conquer approach to accomplish this - as Katy iterated on the development of UI/UX designs, Matt and Magnus developed them in the iOS and web apps (respectively).

## The learning experience

This was our first time working with a location-based API that runs in the background and sends push notifications when a certain threshold has been reached. We struggled a bit with the data structure and setting it up with our own database / backend, but it worked out well at the end and we use it now in our notifications. We are planning to keep the API after this project and add more features, to get more data about our users. We also gained more experience working with Google's Firebase.
## Inspiration

We've never worked with vehicle APIs before, yet we spend a good amount of time in vehicles. Additionally, we noticed that the Ford team was extremely nice and readily gave feedback on ideas.
We wanted to explore this domain, and utilize modern technologies to bolster existing cars in a land-rush go-to-market scheme.

## What it does

SafeLink is an app for drivers and monitors.
Utilizing ODBII data and camera input, SafeLink monitors a driver's behavior, and provides a live feed for a trusted other to watch. If the driver is acting in an unsafe manner, the monitor is notified of such behavior (excessive acceleration, excessive RPMs, turning without using turn signals, excessive speed, not staying within the lane, and more).

## How I built it

Android app.
Streaming API made possible by Firekast.
OpenCV enabled via an AWS Lambda function running on S3 images (frames from video).

## Challenges I ran into

OpenCV and Cognito.

## Accomplishments that I'm proud of

OpenCV and Cognito. Video streaming.

## What I learned

Tough.... Have to work within server costs...

## What's next for SafeLink

Open-source!
## Inspiration

We were inspired by several issues users addressed within the healthcare industries and our own current experiences. By browsing through current news and statistics in the healthcare sector, as well as the push towards remote options after the pandemic, we found that there is a lack of remote connectivity options for patients. Furthermore, doctors' diagnoses often lack transparency and accessibility as they are usually kept within the clinic and not with patient. We sought to solve this problem by creating an application that helps user's to better understand their health.

## What it does

Our application strives to enhance and improve patients' relationships with their doctors by connecting with them remotely. We target key pain points that users have addressed in our secondary research. Users outline that they have trouble booking appointments with their doctor. They address that they have trouble tracking their own prescriptions and medication. Lastly, they discuss that they have trouble understanding their diagnosis beyond the doctor's office.

To remediate these pain points, we created these key features. The first feature is a booking appointment feature that allows the user to book appointments virtually with their doctor according to both schedules. The second feature is a prescription tracker that reminds users when to take their medications and shows the doctor's instructions for it. The last feature is a monitoring feature that shows the user's diagnosis over time. Using the data from monitoring and methods of machine learning, we also create an essential risk assessment that suggests areas where the users may be at risk and should contact their doctor.

## How we built it

We designed the product on Figma and built the backend using Express and Node.js. The database was stored using SQLite3, and the frontend was built using React.

## Challenges we ran into

In order to inform our patients ahead about how much at risk they are to develop a heart disease based on their general health metrics, we implemented a logistic regression data model in scikit learn machine learning library in Python. To do so, our model was first trained on a dataset available freely on Kaggle and then the trained model was used on a patient's health records. However, due to lack of time, our model could not be efficiently trained to yield a higher accuracy. Moving forward, we consider training our model on different datasets as well so its well equipped to better predict risks of other health issues.

In addition, during the initial brainstorming stage, we brainstormed many features which could not all be implemented due to the time constraints of the hackathon. To address this, we prioritized the most important features of the application and moved lower priority and more time intensive features to future development. During brainstorming, we also had trouble laying out a clear flow for the app, but the flow improved as we discussed it more.

Structuring the backend was also a challenge, as we had to brainstorm an efficient way to store many types of data in our app, including health metrics, doctor information, prescriptions and appointments. In the end, we developed a database schema to store data effectively and be able to retrieve it easily before coding it in.

## Accomplishments that we're proud of

We are very proud that we were able to plan and implement this comprehensive product which helps people connect with their health, with doctors and improve their overall well-being.

## Acknowledgements

The cleaned dataset used to train our logistic regression model was available to us from Kaggle: <https://www.kaggle.com/datasets/alexteboul/heart-disease-health-indicators-dataset?resource=download> which is a cleaned version of <https://www.kaggle.com/datasets/cdc/behavioral-risk-factor-surveillance-system>.

Both of these dataset are CC0: Public Domain licensed.

## What we learned

Teamwork is crucial. We collaborated and strived to create the best product with our respective skillsets. We learned about the entire product creation process, from designing the frontend and backend, research and implementation of the product. We learned how to collaborate well with a tight deadline and to create a cohesive product.

## What's next for OPatience

* Further training of the ML algorithm to improve accuracy of prediction
* Enhancing security of data storage in the backend
* User onboarding process