QuickSave

[Patient] The "Patient" side of the application. Note the visual simplicity that makes it clear the functionality of the buttons.
[Provider] Screen that shows once a request is sent.

Inspiration

In this world, many people are unfortunately stuck in sticky situations. Sometimes, these sticky situations are real emergencies where every second is critical. However, we've all heard of horror stories of first responders not showing up on time, going the wrong way, or taking forever to find a house. Such an issue we thought needed to be addressed, leading to the development of QuickSave.

What it does

QuickSave utilizes the network. "Patients", or those who are in need of help, send a request to the network. From there, the network responds to the patients in the form of "Providers" who are capable (and qualified) to give that help.

How we built it

We built QuickSave from scratch. We built Patient/Provider applications for iOS using Swift 4 and built the backend on Ruby and SQLite3. Our team didn't have any idea what project we were going to work on going into the hackathon and thus proceeded through ideation, design, and creation within the entire 36 hours.

Challenges we ran into

Developing this app wasn't easy. First, we realized the need for two applications, in order to clearly isolate those who are receiving or providing help (or both). This was inspired by many user/provider models out there, including Uber and HealthTap. However, this also meant that we essentially doubled our work in order to create two functional apps.

This application was also difficult for the all the connections that were required. The Patient and Provider halves of the application had to interface, which was something we somehow needed to solve (our solution: Apple Push Notification Service, APNS), we needed to connect to the backend (our solution: AFNetworking), and we needed to synchronize everything (our solution: SQLite db to support the system).

We also ran into issues setting up the backend service. Unfortunately, none of us have touched backend development much before. Many the occasional script here and there, but that was usually when the backend was already set up correctly. This time, we had to set everything up from mostly scratch, running into numerous cryptic issues along the way.

There was also the issue of securing storing users in the database. It couldn't just be plain text. We spent several hours searching up, and attempting to implement, solutions that could work. We eventually decided to use bcrypt by the time of our final submission.

Accomplishments that we're proud of

We are proud to say that we have developed a functioning backend service, and two functioning iOS apps that are capable of interacting with each other. Our backend service has API support for both Patient and Provider halves, supporting secure registration and login using trusted encryption software. It is able to make and return SQLite queries in the form of JSON objects that can be easily parsed by almost any platform (scalability!) We somehow managed to work out the kinks of Apple's Push Notification Service, which allowed us to send notifications from one device to another! The provider receives a notification for requests, and a screen pops up showing preliminary information about the request.

What we learned

*How Ruby works. Seriously though. The syntax looked so much like python, but it wasn't python. It was also weird to wrap our heads about setting up a backend service and how that actually works. *Encryption standards. We got familiar with the words "hash" and "salt", and learned why hashing algorithms for encryption should be purposefully slow! We also found that bcrypt is a relevant software to use for encryption,

What's next for QuickSave

*UI Uplift - So much time was spent figuring out how ruby works that we had to fudge the UI a little *Profiles - Let providers add profiles and users provide relevant information for customized matching *Settings - Add settings for applications