MediGuard

Inspiration

The medical industry is fraught with complexities, increasing the likelihood that patients receive burdensome surprise medical bills. In fact, researchers have found that a staggering 80% of American medical bills had some sort of error in them, resulting in billions of dollars in erroneous debt. MediGuard was born out of the desire to combat these inequities and support the financial wellbeing for victims of such errors.

What it does

MediGuard implements an unsupervised machine learning model in order to classify medical invoices with varying degrees of risk for fraud or error.

Our project starts by training a model and generating risk scores for various medical procedures and their corresponding prices. Then, users can upload their invoices to the website and our program will automatically extract important information such as the cost of the procedure. If needed, users have the ability to manually input corrections to this information as well.

Next, we compare the risk score using the data from the user's invoice and the initial risk score for the specified medical procedure. Upon comparing these two values, MediGuard will alert users about the likelihood that their medical invoice contains errors or fraud.

How we built it

In order to scan medical invoices, we used the Tesseract OCR (Optical Character Recognition) Engine along with openCV in order to take in an image of an invoice as user input and return the extracted information from this invoice. The user also has the option to manually input necessary information.

Our machine learning model is an AutoEncoder that was trained on a data set consisting of information from over 100,000 medical professionals. This data set was made up of information including the service provided by the healthcare provider, the amount billed by the healthcare provider, the amount covered by Medicare, and more. For our purposes, we assume that most of the data in the set is "normal" when we trained the model and used these assumptions to identify anomalies in our data set. Using the anomaly scores generated by our model, we were able to identify anomalies in the data we used to test the model by comparing whether or not there was an increase in anomaly score. Based on the change in anomaly score and the initial anomaly score of the given procedure, we were able to classify fraud or errors as either being highly likely, likely, or not likely, providing users more insight about their medical invoice.

Our frontend was created using the Streamlit framework and gives users the option to upload a file containing the medical invoice that they want to detect errors or fraud in. Users also have the option to manually input any information that was incorrectly scanned. Then, based on the input provided by the user, we generate an anomaly score for the given invoice and report the fraud or error risk to the user.

Challenges we ran into

One of the primary challenges we faced was learning how to adequately leverage a very limited amount of open-sourced data sets containing information about medical errors or fraud in invoices. Many of the data sets we initially searched through did not match our specific requirements, and therefore, we had to adapt our approach and think of creative ways to leverage existing data.

Moreover, when attempting to combine the different components of our project into one cohesive application incorporated with our Streamlit site, we were forced to reorganize each component so they could effectively function with each other. Additional planning beforehand would've helped avoid this obstacle.

Additionally, we initially had our model train every time we attempted to render our Streamlit site, which meant that our site would take minutes to load and not be practical for users. To get around this challenge, we trained our model and saved it externally and simply used this already trained and saved model when rendering our site. This helped reduce the time required to run our program. However, while attempting to save our model, we ran into a lot of difficulty such as Tensorflow not being compatible with Apple M1 chips or our model saving incorrectly when attempting to save the model using pickle or joblib. We ultimately were forced to work extra hard to redesign the model and were ultimately able to load the model once at the start, saving lots of time.

What we learned

Developing MediGuard was a very informative experience. We gained experience working with more complicated machine learning techniques and innovating with existing data sets to solve novel issues. We also learnt what it takes to incorporate a machine learning model into a working application.

What's next for MediGuard

While MediGuard currently supports error and fraud detection for over 100,000 healthcare providers and insurance coverage from Medicare, we hope to expand the scope of this project. For example, using data from various insurance providers and additional healthcare service providers could allow us to support fraud and error detection for far more users.

Additionally, we hope to further validate the model by expanding our dataset of medical invoices known to contain fraud or error to more effectively determine the accuracy of our model.

Additionally, we attempted to implement the Procedure Price Lookup API which allows individuals to find the average price based on the Healthcare Common Procedure Coding System (HCPCS) Code for the procedure they received. This would help users compare how much they were charged with the average price for their procedure to help further identify errors or fraud. However, doing so required having an American Medical Association (AMA) License, which none of us have access to.