Flatten the curve. From Instagram to news articles to talk radio, everyone is talking about what we can do to help flatten the curve of coronavirus infections and slow down the spread. It's why we are all self-isolating at home, far away from work and school and other people. But what if we could flatten the curve while also raising the line? There are two main parts to the stereotypical "flatten the curve" diagram. The curve itself describes the rate of infection and the flattening of the curve describes spreading out the cases over time. The second part, however, is the line representing the maximum health care system capacity. This line does not have to be a constant, we can raise this line by more effectively using our ventilators and hospital beds, bringing in more doctors, and also by distributing coronavirus and non-coronavirus patients evenly among hospitals. This last point birthed HospiFind, which will help everyone both flatten the curve and raise the line.

What it does

Hospifind is a web application that helps patients find the best hospitals to go to in their area. The hospital interface allows hospitals to enter information regarding their supplies, such as available hospital beds, ICU beds, ventilators, coronavirus tests, and more. The patient interface requests information such as the patient's mode of transport and details regarding the patient's symptoms, as well as potential coronavirus risk factors. Synthesizing all of this data together, Hospifind locates and ranks the nearest hospitals to the patient based on where the patient would be most likely to get the best treatment, and also lower their risk of infection if they are not a coronavirus patient. In addition, it prioritizes maintaining the influx of patients of each hospital such that hospitals do not overload.

How we built it

We start by using a web-scraping protocol to collect information on each hospital in the US, such as their name, address, location (in longitude and latitude) and the number of beds they contain. We then calculated the rest of the hospitals' information (such as ICU beds and ventilators) using a program that simulates hospital data (based on published studies) and how the data changes daily. This simulation allows for the estimated data to constantly be updating. In addition, we incorporated a hospital interface such that hospitals can update the data themselves, so we can use their actual data rather than our simulated data. Once the hospital data was complete, our patient interface surveys the patient and uses AWS to pass the data to our backend (since we used AWS to host the web application). Our backend starts by using the Google Maps API to find the 10 closest hospitals (based on time and mode of transport) and sent those 10 hospitals along with the patient data to the "brain" of the application. The "brain" of the application is a decision tree-like structure that takes inputs from the hospital's and patient's data and provides an output of how good of a match they are. The "score" outputted is then used to rank the hospitals and the rankings are sent back to the frontend for display. Our frontend uses an interactive Google Maps display with the rankings of the hospitals on the side such that the user can pick the hospital they would like to go to and then be provided with direction to that hospital.

Challenges we ran into

Over the course of this project, we ran into many challenges. The ranking system that calculates the score was very difficult to create due to the lack of training data. Hence we had to create many formulas to condense the data so it gives a proper output. These formulas required much fine-tuning such that it can accurately create the rankings in various situations. Another challenge we ran into was in collecting the data itself. The web-scraping had a lot of errors since we got banned from the website containing our data. Finally, it seems like this always is a challenge, we had issues connecting the various parts of our application together.

Accomplishments that we're proud of

We are really proud of integrating and creating this project due to its usefulness in today's world. This is a huge problem that has surfaced recently and our project addresses it with an efficient solution. The algorithm behind our project took a lot of time and although it can be improved upon, we are really proud of how we got it to work.

What we learned

We learned that solving real-world problems are not easy, especially since there is a lack of data to help solve it. We really took this lesson to heart and it inspired us to keep moving forward with our projects since we enjoy taking on challenges.

What's next for Hospifind

In order for Hospifind to implemented in the real world, we need access to more data. Simply web-scraping the data is not enough, and although there is plenty of data of hospitals, they are all privately-owned or cost a decent amount of money to access. This increase in data will allow for our decision-making model to become more accurate, our simulations to become less of an estimate and more the actual numbers, and for our users to get the best response possible. In addition, if hospitals begin to use the hospital interface, our data will also become more accurate. While our model currently is used only for New York, we are currently expanding to the US (we have the data we just need to apply it). Once we get more data and our model improves, our next goal will be to expand beyond the US and to other countries. These other countries, especially third-world countries, have hospitals overflow more frequently than that of the US and its use in said countries will be far more substantial, especially after the coronavirus pandemic.

Important Note

To prevent unauthorized usage of our Google Maps API key we removed it from our website. The website below will work for the hospital portal, and in our video we showed how the website would function for a patient with a working API key.

Try It out



amazon-web-services, beautiful-soup, css, google, google-maps, html, javascript, python

Devpost Software Identifier