The night before HackRU, we looked at the list of sponsors and saw Merck listed as one of them. Being a Biomedical Engineer, Nick figured this would be one of the very few oppurtunities he would get at a hackathon to do a healthcare hack that would be both impactful and utilize his set of expertise.

Doctors, although great at what they do, are not always perfect. We have all watched drug commercials, where the list of problematic conditions, side effects, and precautions seems to drag on and on, making many question if a drug is even worth taking. We figured that instead of hiding this information at 250 words per minute or in size 3 text at the end of a commercial, we could empower the consumer by allotting them easier and more digestible access to this information.

What it does

RxCheck allows patients to input their medication and existing conditions, cross checking for potential prescription violations within our database.

Further, RxCheck offers the option for a user to input their email address and phone number, and if any potential new information or recalls are made available, RxCheck will notify the patient immediately.

How we built it

  1. Coded automized request bot in Python that would access the FDA drug label API (
  2. Used PyMongo to transfer request data into MongoDB (server refreshes all data from the API based on preset time intervals, we presumed that a weekly update would be a sufficient compromise).
  3. Built front end with HTML/CSS/JS (graphics, user inputs, etc)
  4. Established user notification functionality through Twilio (Text/Call) and SendGrid (email)

Challenges we ran into

BAD. INTERNET. This was particularly frustrating, as only 2 of our 4 group members had stable internet connections. Our third member only had connection ~50% of the time (with extremely low bandwith, which made sending get requests quite problematic), and the other had connection for a bit more time, but had intermittent disconnections.

On a more contextual basis, we got scared once we saw that the list of drugs (~70,000 entries) would have taken about 8 hours to parse based on the limit of 240 requests per minute by the FDA API. We took quite a bit of time figuring out how to circumvent this, but then we realized that each request could handle up to 100 drugs, which completely solved this problem.

Although the FDA requires manufacturers to list product features/warnings in accordance with the SPL, this doesn't require them to normalize synonyms, and this made the data harder to categorize. Examples include Diabetic/Diabetes/Glucose Intolerance, Pregnant/Pregnancy, Breastfeeding/Nursing/Milking/Lactating, and many more.

Also, there are identical replicates of entire drugs in the database, which caused a significant amount of errors in our autofill and substring parsing functions.

Accomplishments that we're proud of

Two things we value most about this project are its large potential userbase (anybody who takes a prescription drug) in addition to the streamlining of medical documentation (ease of access). This data is made publically available through the FDA API as well as individual manufacturers' product pages, but these are esoteric and difficult methods for the vast majority of patients. Also, building an extensive 'living' system that will potentially interact with the user in the future is something that goes a long way towards ensuring patient health and security, without requiring constant fear/paranoia of checking news headlines.

What I learned

The FDA , despite having a very easy to use API for their drug database, seems to have quite a few redundant variables in their system (12 different variables that all say 'warning'?). They do a fairly good job with the documentation by asserting which variables may be most valuable by listing the general prevalence across OTC/Rx drugs. Again, just a minor gripe that was solved with a few test requests that gauged the specifics of their database formatting.

However, the biggest thing that we learned and were shocked at, is the poor job the healthcare industry (government included) does in ensuring that people who need pertinent recall or medical conflict information (the patients), receive it. We are genuinely concerned that there isn't some sort of legislation in place that mandates notification of patients by pharmaceutical manufacturers, pharmacies, or medical institutions. Intuitively, this doesn't seem to be in the best interest of big pharma firms (class action lawsuits), but we genuinely believe that their moral responsibility to the patients/customers could be prioritized better than it is currently is by sponsoring a system such as RxCheck.

We strongly believe that commercials paid for by law firms firms recruiting victims should never be a primary source of recall information, just as size 3 text and hyperspeed reading of warning labels shouldn't be the norm for drug advertisements.

What's next for RxCheck

Expanding functionality around our core values of empowering the patient to take a proactive role in ensuring proper medication.

On more of a 'big data' front, compiling a database of inputs (medication and comorbidities/diseases) could potentially be used for population frequency analysis; revealing causational trends that could spur interest in particular factor interactions. More often than not, this data contains many pieces of confidential information, preventing it from being accessed by anybody except those with specific clearance. By opening up healthcare data to more people, we could take steps towards more quickly solving some of society's biggest health issues.

Built With

Share this project:


Nicholas Walsh posted an update

Thanks MongoDB for the prize! Out of all of the the moving parts in our project, we were able to rely on MongoDB to work flawlessly and as expected, giving us more time to focus on other problems we ran into along the way.

Log in or sign up for Devpost to join the conversation.