Due to some problems, you should watch either of these two videos:
Inspiration
Years ago I woke up to the death of my grandma, the person who had raised me. She was lying on the bed, lifeless, her heart not beating, her face growing cold with the humid summer air. We immediately called 911, though it took them no less than an hour and a half to arrive, and by the time they did, she was gone. It wasn't until next year that I learned her death was preventable, if only they were faster, she would still be well. And because of this, we're choosing to take our shot at one of medicine's biggest unsolved problems - transportation. Let's stop the deaths, shall we?
This is also a problem that almost no one has tried to solve in almost any proportion, which baffles me because it truly is important.
What it does
Mediquick is an application composed of 3 standalone parts:
- The Client App
- The Driver App
- The Web Dashboard
The client app is geared towards users and is freely downloadable. It contains the option to add your personal information such as your name and notes about you that the hospital should know (we're adding image support soon too). The app is structured in a way that makes it easy for people to get help, fast. We've also started coding facial and fall detection to alert the authorities if your health gets considerably worse, though I doubt we'll finish that by the end. The main goal of the app is to provide an effortless way to get help and see where your help is, and how much time they will take to get there.
The driver app is similar to the client app, but is geared towards drivers of medical vehicles, rather than clients themselves. The app gives you a driver id and enlists you, along with your location, into a pool of possible drivers. From there, once a patient is added, you might get selected for picking up said patient at which point a screen will pop up asking you to accept or decline. Given that you accept, you will get a directional maps either through or embedded mapping system or google maps. When your drive is done, you may end the "mission". Note that the drivers are not chosen at random, but by taking into consideration their distance from the user.
The web dashboard is a general "God's View" of everything going on in the system. Through it, you can view all the ongoing missions and bump up queue priority for those waiting to get help, based on what you know and are allowed to do. The dashboard also gives you a map, a way to see every participant at once. We were planning to implement VOIP over the dashboard so that you could also call and talk to clients real-time over the internet, but we didn't quite finish the implementation.
How we built it
Our first step, as always with serious projects, is creating personas of people who might need help. This wasn't too hard, as almost everyone sometimes needs help, so we were driven to create our personas as diverse and different from one another as possible.
This lead to the creation of Jay and Etna, a child and an old woman. Jay is most likely proficient in using technology unlike Etna who just wasn't born in that generation, this presents the app's biggest challenge: How do we create a UI that's uniquely accessible to everyone? The answer we found, one button. Based on this and a lot more research I can't thoroughly explore here, we settled on a perfect initial sketch for our app, aka the perfect lofi design. We followed what's commonly referred to as the double diamond design process to end up with the hifi designs you'll see below
After the lofi designs, creating the hifi ones was relatively easy. We chose to do a bit of a double bearing here, since we settled on using a relatively complex design pattern while we were building the web app, but ended up having to down-scale it to look good and simple on mobile. In any case, it worked, so here are some of the results:
The next step, or sort of parallel step was development. I personally spent around 5 hours attempting to set up flutter for development, and that was surely our biggest problem. I had to learn a whole other language and develop targeting a whole platform I'd never developed for before. Thankfully, it worked out and I was able to finish most of our features in time.
The dashboard was a pretty quick task, since I'm very good at react and my teammate Alice handled the maps, which became a bit of an issue but were alright. One of the hardest parts of the dashboard, where firebase came in handy, was making sure that all the resources were kept in sync properly throughout the system. We ensured this by using firestore onSnapshot callback methods, combined with a small REST API / "microservice" platform on firebase functions. We worked with chakraui, which provides things like buttons mostly premade, though quite a bit of styling was imperative. Another thing I'm proud of is breaking my own record for implementing authentication in an application, I just mentioned that cause yeah, ~2 minutes.
The client mobile app was the one we developed first, and boy was that a pain. First of all, setting up flutter on your machine isn't easy for some strange reason, especially when you have to learn a whole other language during a hackathon. Nevertheless, I cried for 4 hours until a circuit shorted and made it work, so I could start developing. At first I couldn't get intellisense to work, meaning that today I've read around 150 pages worth of documentation both on dart, material-ui, and flutter. Dependencies in dart are horrible, so we had to use firebase functions instead of accessing the database directly, aka we used the "traditional" approach.
The driver mobile app was actually significantly easier, mostly because it shares around 30% of its code with the client mobile app. Dependencies again were a bother, so I ended up having to actually write files to the filesystem to save data which is just a wild concept and a crime I never thought I'd commit. But in any case, this app also used flutter, dart, firebase, firebase functions, firestore, a dash of java, and a ton of pain :). Same as the other one.
Btw the song is in e minor (blues)
Challenges we ran into
Well first of all I've never used flutter or dart before in my entire life, meaning that, as I've mentioned, due to my intellisense not working I had to read about 150 pages of documentation. I might've spent about a gigabyte in history storage. Aside from that, a big challenge came from the fact that me and my teammates are in different timezones, 7-8 hours apart. Thankfully, my creative approach to solve this was just not sleeping, and by my rambling on in this document you can tell it worked. Aside from that, everything went pretty smoothly.
Accomplishments that we're proud of
I am now a dart / flutter master. I'm kidding, though I can code dart now! Alice learned how to use maps and Keval got better at react. Honestly, I think this is the most "real-world-influential" project I've ever done for a hackathon, and I'm quite proud of that.
What we learned
Solving the transport problem isn't easy, but if a highschooler could do it in 2 days what's going on, world healthcare? In truth, I came to the realization I've come to many times before, and it's quite the grim one. No one's fixed the issue yet because there isn't a large monetary gain for the individual from very old people not dying on their way to the hospital, and since we live in a society fueled by "free market" capitalism, frighteningly moving towards more and more privatization, something like this could never have been allowed to exist outside of lovely communities like hackathons. So thank you, from the bottom of my heart, for giving us a space where we could create such an idealistic project!
What's next for mediquick
Since 1/4 of us is an American citizen, there isn't much we could do. But nevertheless, I will personally keep upgrading the app, for example adding VOIP support to make it quite a bit cooler, mainly because I've learned a lot over these past 36 hours or so.
Log in or sign up for Devpost to join the conversation.