Inspiration
For the first fourth of the hackathon, we spent our time iterating through a variety of project ideas. Eventually, we identified the root of our difficulties in selecting a project that was doable, challenging, and engaging to the whole group: all of all were more interested in the algorithmic side of our ideas and less knowledgeable/passionate about the specific applications or frameworks that our project ideas would be running off of. Small talk within the group eventually led us to the stable matching algorithm, which we identified as a viable project concept after having one group member whiteboard out the problem for some teammates who had never heard of stable matching. After this came a long session of brainstorming on the potential applications of the algorithm. We settled on the issue of how patients experiencing a medical emergency are matched to a hospital to receive treatment at. If ambulance drivers and paramedics were to implement this algorithm, it would help ensure that patients are brought to the hospital best suited for their needs.
What it does
Our project takes the input of a set of patients and a set of hospitals. Each patient is a defined distance away from each hospital and each hospital is given a 0-1 rating on how good they are at treating particular injuries. In the case of our project, hospitals were given separate ratings on how well they treat heart issues, liver issues, kidney issues, and brain damage issues. Each hospital is also given a maximum capacity of patients. Our project takes this information and uses it to determine which hospital every patient in our dataset should go to. This is accomplished by using patients and their ranked list of preferred hospitals - which is based entirely on the distance they are from the hospital - as the primary input and hospitals and the ranked list of patients they prefer to treat - which is entirely based on how good they are at treating the patients’ conditions - as our secondary input into our algorithm.
How we built it
Our first step was to take what we knew about the stable matching algorithm and put the algorithm into code. This step proved to be much more complex and time-intensive than expected. We had to spend a lot of time conceptualizing our problem and working through pseudocode and mapping examples by hand. After we had our algorithm, we shifted our focus to generating data to test our code.
Challenges we ran into
The most significant challenge we encountered was settling on a project idea in the first place. As a team, we had a wide array of individual ideas about what project to work on but hadn't spent time before the hackathon discussing what type of project we should focus on. Our brainstorming session that was supposed to wrap up Friday night ultimately extended late into Saturday morning. This put us in a time crunch for developing our final project.
Accomplishments that we're proud of
We stretched out the Gale-Shapely one-to-one matching algorithm to work for one-to-many matchings. We were also able to achieve stable matching for two sets with different cardinalities.
What we learned
We learned that it is essential to have an established workflow for a project and that tracing your code regularly, especially when working on a large-scale project, is very important. All team members also learned a great deal about the logic behind the stable-matching algorithm.
What's next for H2P Match
Right now, our project is built around optimizing which hospitals patients go to receive the needed medical treatment given the distance the patient is from the hospital and how highly rated the hospital is in addressing the condition. A possible next step would be increasing the complexity of the matching algorithm by taking into account factors such as the severity of the patients’ conditions and the relative location of hospitals to one another. This project could be implemented into central databases for paramedics to use when delivering the patient to the needed care center.
Log in or sign up for Devpost to join the conversation.