Hospital Compendium

A user-friendly platform to cognizantly explore adequate local healthcare while discovering its inequality.

Comment

Inspiration

Recently, many news stories have surfaced discussing anecdotes of patients being significantly over-charged for medical operations or being shocked by the high cost of their bill. According to a survey by NORC at the University of Chicago, 57% of respondents were shocked to receive a bill they thought their insurance would pay for. The study also found 53% of respondents surprised of having to pay an exorbitant amount of money to pay for physician services, 51% of respondents were surprised for paying large amounts for laboratory tests laboratory tests, and 35% of respondents were astounded for receiving unexpected bills for imaging services. Originally, I believed that to support this community unaware of or unprepared for these high medical costs, the best way to inform them would to make such information accessible by creating a platform where patients could share the costs for individual medical services to better inform the platform's community, providing patients some leverage when negotiating a bill and in some ways democratizing medicine. However, this idea presented issues of patient confidentiality and privacy due to HIPAA, variance in patient conditions that could have influenced costs, ambiguity in medical bills on what each item corresponding to, and moderating the platform to promote legitimate statements and illegitimate ones. Instead, recalling my work in a mathematical modeling competition ranking different hospitals, I decided to create a platform that compiles hospital quality and pricing information that users can use to not only evaluate the facilities, care, and price of their local healthcare facilities, but also know how the local facilities compare to that across the country. People of diverse backgrounds must seek healthcare in some form, and by becoming more knowledgeable of it both locally and across the country, we can collaborate to petition for a fairer and fitter healthcare system.

What it does

Simply, Hospital Compendium is a platform that allows users to easily search for local hospitals and learn about the prices and quality of its services. Users can search for local hospitals and see the prices for the same four common procedures, which could potentially be used as a normalized metric to compare relative prices across other local hospitals. Additionally, the platform also provides users with information on areas such as the results of surveys on patient satisfaction and the incidence rates of complications and death of certain circumstances. Armed with the knowledge of studies of patient satisfaction, the frequency of complications, and the relative prices between each hospital, users can have the necessary information to select the perfect hospital for their needs without being overwhelmed with information.

How I built it

First, databases with information regarding hospitals from the NAPSG Foundation Base Data Group and U.S. Centers for Medicare & Medicaid Services were downloaded, compiled, examined, and analyzed. This process involved searching for the optimal set databases in terms of the quantity and diversity of records, the detail and depth of measurements, and the compatibility and commonality between databases. Ultimately, the Hospital General Information, Hospital Consumer Assessment of Healthcare Providers and Systems, Hospital Complications and Death, and Hospital Payment and Value of Care databases provided by the U.S. Centers for Medicare & Medicaid Services were chosen to build the platform. After the databases were chosen, the front-end of the web application began development. The design objective for creating the front end was to capture and hold the user's attention with large graphics and platform interactivity. Hence, the prominent placement of the map powered by the Google Cloud Maps API. Dotted with markers of hospitals around the United States and centered on the user's current location, the map invites the user to explore what the platform has to offer while not overwhelming him or her with the sheer quantity of information available. Additionally, the information was delivered in points at a time for easy and terse reading that still communicates effectively. Lastly, the data storage and back-end development of the application began development. PHP was originally considered to power it, however, possible difficulties in preparing for application deployment made it an increasingly less appealing option. Hence, a framework where I had more experience was chosen to power the back-end instead: Django. The data was originally going to be stored as CSV files and have portions retrieved as they were needed. However, SQL, specifically PostgreSQL. was chosen instead as it was more ft to retrieve the databases for how it was organized and can be done so more concisely and potentially more quickly.

Challenges I ran into

The most apparent challenge of the project's development was the low human resources contributing to the development of the project. Without the diverse skill set and input of other people and the consequential improved efficiency, more time needed to be spent working on the project, more learning was the necessary skills to realize the ideas, and more time was spent to ponder difficult decisions. However, after overcoming my insecurity and doubts, my momentum working on the project increased. A longer lasting challenge the project faced was the indecisiveness on how to approach particular problems, particularly the frameworks for the back-end and data storage. I went back and forth on the two choices I was conflicted between, wasting time preparing to use tools I ultimately did not use. The last major issue for the project was the query limit for accessing Google Cloud's Geocode service to find the exact coordinates of the hospitals. Due to the requesting of almost 4800 in a short period of time, the API would not them all, resulting in only having a small fraction of that amount appearing on the map. Unfortunately, the Medicare databases were the only ones that did not provide exact coordinates for the hospitals, so their distance to a particular user cannot be found easily without an API such as Google's. The challenge that ultimately prevented the completion the completion of the project was a large number of SQL queries that needed to be made and my lack of SQL knowledge. In particular, the resolution of syntax errors and spelling mistakes halted the development of the backend of the hospital details page. Some minor more minor challenges that the project's development faced was the truncation of my computer's existing PATH variables from installing new servers and frameworks, hindering productivity, and not being used to work through the night.

Accomplishments that I'm proud of

Though I was hoping for my first hackathon to be one full of collaboration working with tools and fields I am not very familiar with, I am proud for doing exactly the opposite: applying what I already know to create a project. Starting off, I didn't think I could create a project I would be satisfied with, especially since I could not even come up a satisfactory idea to present at pitches an hour after the hackathon began. However, gradually working out from doubt into confidence balancing what I'm familiar with and what I'm not reminds me much about why I originally wanted to participate in the hackathon in the first place: the opportunity and desire to challenge oneself by learning new skills and finding new ways to apply old ones catalyzes an excitement to continue that momentum, breaking the expectations and limits one once had of him or herself and move towards the next wall of doubt to break down.

What I learned

Though I used tools I was already familiar with, I managed to pick up some additional skills as well. Javascript was and is not a language I enjoy programming with, but this experience has allowed me to better understand its interactions with the other web-oriented languages such as HTML and PHP. I have only worked with SQL once, but this experience has allowed me to work with it in different applications. Lastly, this is the first time I properly deploy the application which has been a fairly difficult process trying to fulfill prerequisites for the platforms to work and resolving potential compatibility issues with the programming languages and frameworks I was working with.

What's next for Hospital Compendium

Priority should be taken to finish the back-end of the hospital details page in order to make the project functional. Additionally, finding and recording the coordinates of the hospitals in the database would eliminate the application's dependence on the Geocoder API. With the dependence on the Geocoder API eliminated, it would also be possible to implement a feature of listing the ten closest hospitals to the center of the map by using the haversine formula. The primary area of improvement to the platform as it was conceived is to gather more data from more databases, ideally ones that mostly share the same hospitals as the ones stored in the databases on HC. Specifically, more specific information on the pricing of common medical procedures used in less life-threatening situations such as colonoscopies. Additionally, the implementation of a mathematical model my math modeling team and I developed during a competition can be used to rank hospitals for their overall and patient-specific quality. Lastly, an improved search function designed to search for health facilities specific to patients' needs should be implemented as well to improve the health of users and promote the learning of underlying problems and solutions.

Share this project:

Updates