-
Home Page
-
Search Page
-
Search Results
-
Doctor Profile
-
About Page
Inspiration
Our project was prompted by the sponsor "patient safety technology" challenge. Patient safety, put briefly, are the preventable errors and unsafe conditions in hospitals. It accounts for 3 trillion dollars in indirect harm annually according to the WHO. Being able to combat poor patient safety would be a great thing to do. So that's what we aimed to do.
Our original idea, however, was something much more novel. Before the start of the Hackathon, Daniel was talking about the difficult he found in collaborating with others when trying to make beats. The different styles and tempos made it difficult to match up. What if there was an AI, he pitched, that could automatically sort through libraries submitted by users and pair the best patch together? A bit niche, to be honest.
Not too far apart in time, however, Jake was talking about a surgery he had gotten recently. A septoplasty. He talked about how scary and anxious it can be to put your bodily function into the hands of a doctor you had never seen before. All he had to go off of was a referral and a thumbs up from his current doctor. When we took that sentiment in consideration with various safety concerns that goes largely unseen by the public, we came up with a new idea playing off of the beat matcher. What if we could take in the needs of someone seeking a doctor, and match it with the best healthcare that fits their needs?
And thus, Patient was born.
What it does
Patient is a specialized AI search engine that compiles all the relevant data on healthcare providers in your area and presents it in an easily navigable menu. Our innovative machine-learning solution that aggregates and analyzes information from trusted sources across the web like Leapfrog, DocInfo, OpenPayments, and Healthgrades to gather information on each individual doctor. While the all of the information of the doctors and hospitals is findable on the internet, trying to make a proper educated decision means sifting through 5 different websites and fighting outdated government webpages. With our streamlined solution, finding data on the best doctor for you becomes as easy as writing a sentence into a search box.
Easily compare the qualifications, safety records, and specialties of doctors and hospitals. Make educated decisions about your health, backed by real patient safety data and statistics.
How we built it
Early into the project, we split the workflow into 3 units to make a more comprehensive piece. Branson built a prototype for us in Figma that we then implemented while he honed our pitch and user cases. Jake designed the front-end in JavaScript using React and Tailwind while Daniel and Kelly focused on the back end and shaping the AI to provide specialized responses to the needs of each user. While our work seemed to be separate, very often would we have to come back together to exchange insights, ideas, and values to keep the project cohesive.
## Challenges we ran into
Jake, relatively new to front end coding, had trouble setting up Tailwind. What seemed to be a simple error eventually attracted a whole team of mentors crowding around his computer at one point. Once he (and the mentors) overcame the learning hurdles, he hit the ground running and was pretty rapidly able to build functional prototype. What was additionally troubling, however, was fixing margins and positions using pixel widths especially when working off of an existing mock-up in Figma.
Daniel and Kelly had a lot of trouble gaining access and navigating to the data we wanted to utilize. From obfuscated APIs to license limitations, at any given point, something was going wrong. It also didn't help that the backend was originally written in Java. Considering the amount of JSON parsing and manipulation that was required of the project, Java wasn't cutting it, and a full rewrite in Python occurred about halfway through the lifetime of the project. This challenge was accentuated with Git not allowing us to merge PR's or create new ones, which we were not able to fix before the deadline. As such, the final repository is separated across branches.
When we seemed to have gotten it all working, right as the project was closing out, we realized that one of the most crucial API's that we were working with was just... flat out incorrect. The API was giving completely erroneous information despite the website that the API was hiding behind displaying correct information. The incorrect information spoils the functionality of the search, sadly, since the bulk of our data was coming from this API.
Accomplishments that we're proud of
Jake is proud of the way our team parallelized our workflow. While everyone was doing their own tasks, we frequently asked each other for help as well as exchanging ideas. This led to a very robust work cycle, where we were all building up the solution piece-by-piece. Despite the technical limitations, our vision of the project came out to be very solid and doable with the right infrastructure.
Daniel and Kelly are very proud of dealing with an incredibly difficult to use API (Open Patients). Additionally, after finally figuring out how to use the API, our triumph was trumped by another difficulty. The AI had to navigate through an incredibly large dataset, causing extremely slow searches. They ultimately downloaded the 14.6 million line dataset and created an ultra-fast indexed SQLite database to speed up lookups. We managed to cut down lookup time from 3 minutes to 3 seconds!
Last but not least, we are very proud of our innovation abilities. Every single person on this team tried something new, be that new frameworks, new languages, programming, design, or working with data in new ways. Even if the final product didn't come out as expected, we learned so many skills that will stick with us for so long. And, if we had more time, the product we made would be extremely realistic and useful to make.
What we learned
As stated above, we all worked with new tools. However, the highlight of this project was the realization of how data is not something we can necessarily trust. Realizing that the API that we were working with was giving incorrect data was a huge wake up call, considering the fact that the site we were trying to develop was aiming to make that same data more accessible. If it was this difficult for us to find and parse the data, imagine how difficult it is for an average person looking to look for the best healthcare. We hope to work with providers directly in the future, so we can verify the integrity of the data instead of relying on an external source. Our biggest bottleneck time-wise was this very same API - so if we had the data ourselves, we would have seen increased performance across the board.
On a lighter note, we really learned how much we enjoyed each others company. Be that during our diabolical lock ins, or during our slight breaks, we made each other laugh the entire time. The 36 hours went by flying - it really feels like the hackathon just started, and that's because of the company we shared.
What's next for Patient
We aim to refactor the code to be more clear, fully connect the front end and the backend, and work with organizations such as Leapfrog group to increase the breadth and accuracy of the data Patient can provide to its users.
Log in or sign up for Devpost to join the conversation.