Inspiration

When I was a child, my uncle was diagnosed with cancer and had his limb amputated. He was prescribed opioids to deal with the pain, and while I don’t remember much from the time, what I do remember is that the only thing stopping him from overdosing on the very medication given to help him was the flimsy lid on a standard pill bottle. I discovered at a young age that it’s so much easier to get hooked on such highly addictive medication than you think - and it all starts with a prescription from your doctor. By giving patients drugs like opioids in a standard pill bottle, there is literally no oversight and doctors have to fully rely on the patient’s self control to adhere to their prescription. And this doesn’t just cause problems for the patient - in fact, insurance companies waste $78 billion every year just to pay for corrective medication when patients overtake medication. Today, we are running on an outdated system that allows for easy nonadherence to addictive medication. Our project, PillBot, is the answer.

What it does

PillBot is a device that only dispenses medication according to the doctor’s prescribed schedule. Our device is inexpensive, and integrates seamlessly into a pharmacist’s workflow. This way, a pharmacy can dispense opioids into our device and give it to the patient as a cost-effective alternative to the pill bottle. At home, our device’s restrictive dispensing would make it impossible for patients to overtake or divert their medication. Additionally, when the patient presses the button to dispense a pill, the timestamp is recorded. This adherence data is automatically sent to our HIPAA compliant data platform, which performs predictive data analytics to recommend future treatment.

How we built it

We began the concept of PillBot (called "LocPill" at the time) at the September PennApps last year. During that hackathon, we came up with the concept from scratch and ended up with a massive, clunky, circular pill dispenser not unlike many of the B2C pill dispensers out there. Since then, we've been working to make PillBot into a full blown startup and have been constantly iterating to keep size and cost down. Last week, we ordered and had delivered a PCB board with components to fit within a potential smaller housing container than the large and bulky ones we had previously used to house Arduinos. During this particular PennApps, we not only rapidly iterated a mechanism to dispense a single pill reliably with one rotation of a custom 3D printed part that fits inside our container (previous iterations would either jam or not dispense any pills at all), but also designed and finished a marketing website showcasing our product and made substantial progress connecting the backend structure of our site to the physical hardware. We also were able to design and link the frontend and backend pages for pharmacies uploading prescriptions to the PillBot and doctors viewing adherence data.

For backend, we decided to use Google's gRPC and ESP (a HTTP to RPC proxy) to broker the communication between the clients and servers. Even though this approach had a significant learning curve, we can now take advantage of the built in audit logging and tracing, and to use the automated documentation generator to produce API docs from protocol definitions. Additionally, we picked Firestore over MongoDB because it abstracted away the scalability issues linked with MongoDB (and it recently entered GA with 99.99 SLA, which certainly cannot be achieved if we manage our own mongo clusters). We used kubernetes, Google Cloud build, and Google container registry to automatically CI/CD our backend software from the developers to the clusters on gcp. For infrastructure management, we used Hashicorp Terraform to manage our infrastructure scattered across GCP, Cloudflare, and some other minor providers. The CICD system automatically applied terraform changes as the developers merge infrastructure changes to master. The secret management is currently done on gcp kms, however we plan to migrate it to hashicorp vault soon. for interservice communication, we use the built in Google IAM policies and service accounts, which is proven to be very extensible.

Overall, we've had to make many tough infrastructure choices in a short span of time, and we hope those choices will continue to support our scaling in the years to come.

Challenges we ran into

Since we only had one night to figure out a very complicated dispensing mechanism, one of the biggest challenges we faced was being able to iterate rapidly. While a 3D printer is perfect for rapid prototyping, each version of the custom spinner part took a little over an hour to print, meaning we often spent a lot of time designing new iterations while waiting for a print to finish, only to discover the idea we had iterated off of would not work. Another big challenge we faced was pushing the website live. We finished coding the website at around 5:48 AM, and it was a big struggle to push it up as certain files had gone missing, there were issues with naming image files with capitalized letters, etc. In general, while we had a lot of fun iterating different designs, it was sometimes frustrating to find the CAD model we had spent hours designing and another hour printing just simply wouldn't facilitate a single pill drop well.

Accomplishments that we're proud of

When we finally hooked up the motor to our customized 3D-printed case and spun our element, the moment a single pill fell through the slot was cause for huge celebration after hours upon hours of designing and redesigning. Getting a 3D printed device to reliably tilt a single pill into a slot and dispense it was extremely difficult, and it was very rewarding when we finally got it working.

What we learned

One of the really important skills we learned (or at least got practice doing) was how to rapidly switch mental gears when on a tight time crunch. When we spent the past few hour designing a CAD model, while waiting another hour for it to print, we had to switch mindsets and write code for backend dev or the frontend marketing site, for example, and then immediately switch back into the hardware mindset when the print finished.

What's next for PillBot

By the end of the month, we want to complete construction of PCB+components and finalize hardware design while locating a dedicated mentor to support us through the process of getting a Penn Medicine medical device trial. In the next few months, we want to start looking into mass manufacturing device and continue setting up our medical device free trial. Hopefully by April/May, we can begin beta testing our device at Penn Medicine and start preliminary business talks with PBMs and pharmacies.

Share this project:
×

Updates