“Smart” Alarm Pill Bottle

The Problem

An estimated half of U.S. patients don’t take their medications as prescribed, resulting in an estimated 100,000 preventable deaths annually. This issue is especially prevalent within elderly populations, where individuals tend to be more forgetful than their younger counterparts, and may often forget to take medications that are vital to preserving their health and quality of life. Missed doses may have a much more devastating effect upon an elderly person than a younger one, and that, compounded with declining cognitive resources and memory capacity, can increase mortality risks for elderly folks.

Many existing medical and tech companies have attempted to solve this healthcare problem. Some of these design solutions have consisted of pill bottles with elapsed time counters, which may only be effective if a patient remembers to look at their medications frequently.

Most address it by applying cutting-edge technology, incorporating ambient display interfaces on the physical bottle, and pairing them with applications on devices such as phones and tablets. These solutions fail to incorporate accessible design for the elderly: most are unfamiliar with technology. Those who are more tech-savvy are least likely to need assistance remembering to take medications. Inversely, presenting those who need help remembering basic daily functions with an unfamiliar technology that they must learn, and subsequently remember, fails to consider the initial design problem and the challenges faced by target users.

In summary, replacing the task of remembering medication doses with learning unfamiliar technology has been proven just as ineffective as the standard pill box that designers have been working to improve. I decided that more technology was not always the answer to every design problem.

My Solution

My challenge was to improve upon the functionality of standard pill bottles and their affordances without over-complicating the system through the application of technology, as many companies have tried before. I decided that technology could stay, and would have a place within my design — and rightfully so. Computers are remarkably good at something humans are not: remembering. This needed to be leveraged within my design.

The technology in my design had to be invisible, practical, and simple, in order to meet the needs of my target population.

I created a concept for a “smart” device that de-emphasized its “smart” aspect and placed more importance on familiar physical affordances. For a pill bottle, this meant presenting users with a familiar physical device that was compliant with their mental model of what a pill bottle looks like, and how it works, therefore meeting their expectations.

As a result, my design solution leverages the reminding power of computers and the familiarity of physical affordances to create a product that is accessible to its intended user.

A smart pill bottle that actually looks like a pill bottle will present a familiar item to users, and will immediately afford its use and functionality. The cap on the bottle includes a timer, programmable by a doctor or caretaker to remind the patient every time they are to take a dose. The timer expires at intervals, triggering a sufficiently loud alarm, and will not silence until the lid is removed from the pill bottle. Alarm functionality provides the salience necessary to trigger action by the user, rather than providing just an ambient option that they must remember to look at and derive meaning from.

My Design Process

I decided to begin my prototyping process by only working on the background, and building up to the foreground. This meant I would be focusing on trying to build the background technology, with the intention of it operating in the background, and as a final piece, bringing in the physical pill bottle and attaching it to the technology, to be the interface, providing a barrier between the user and the technology. I intentionally avoided reinventing the design of the pill bottle, because I believed it to be an important constant within the context of elderly patients who were missing doses of medication due to degrading memory or other conditions where unfamiliar objects/technologies would be confusing.

I began by setting up the hardware for the LCD display using the following components:

• Arduino Uno
• Small breadboard
• Jumper wires
• 10 Ω potentiometer
• 220 Ω resistor
• 16x2 LCD screen

Iteration 1, Phase 1: hardware setup

I used a tutorial diagram to set up the circuit, which involved some troubleshooting, as my LCD screen was slightly different than the one in the tutorial. When the circuit was complete, I used code from the same tutorial, and developed it further to print to the screen. Although the code compiled, and the screen was on, the screen would not print anything.

Itereation 1, Phase 2: screen printing issues

I solved this problem in a second iteration where I removed the resistor and replaced the jumpers, which formed a more solid circuit. Incidentally, the resistor had been breaking the circuit because it didn’t fit correctly into the breadboard. After some research, I realized that the resistor would just dim the screen’s back light and wasn’t necessary for functionality. Also, the jumpers, in addition to being messy, weakened the circuit. The design then consisted of the following components:

• Elegoo Uno (off-brand Arduino Uno)
• Large breadboard
• Wires (to replace jumpers in breadboard -to-breadboard connections)
• Male to female rainbow jumper wire strip
• 10 Ω potentiometer
• Pin headers (for each pin on the screen)
• 16x2 LCD screen

Iteration 2: the screen and buzzer both work!

An advantage of switching to a larger breadboard was being able to build the buzzer’s circuit within the same system. To the previous components, I added:

• Small buzzer
• More wires

Once the hardware was in place, I developed code to initialize the buzzer, which consisted of writing a function called toggleBuzzer() that turned the buzzer on and off.

The next step was developing code to create a countdown timer, and integrate that with the buzzer code. This was the most challenging aspect of my design process. Because nobody had done a project like this before, there was no open-sourced code that perfectly matched my needs. I was able to find open source code for a countdown timer online. I analyzed the code line-by-line to understand what it did, and was able to change it to integrate with the LCD and buzzer code.

This was an iterative process, and took significant time investment. To access my completed code file, click here.

The last step was adding the interactive piece of the design: the pill bottle. I soldered a piece of wire to a battery compartment spring, which I glued to the inside of the pill bottle cap. Because I drilled a hole in the cap, I placed a piece of shrink tube over the wire to protect it. Then, I soldered a wire to a battery contact (like you would find in a TV remote, flashlight, etc…), which I glued inside the pill bottle in a position where it would touch the spring and complete the circuit when the cap was closed. I connected each wire to Arduino analog pin 2 and GRD. This part of the project was not especially time-consuming, but it was the most critical, as it consisted of the interactive portion of the project.

Inside of pill bottle

Interior bottle cap design

Finally, I put everything together, and tested it out. I had to fix a few minor bugs, but it worked! I uploaded the code to the Arduino, and plugged in a 9V battery as a power source. I also taped the Arduino to the breadboard just to assist with easy packaging for transport and handling.

The completed prototype

Here is a demo video that displays the project concept, as conveyed by the prototype.

Prototype Demo

During my design process for this project, I utilized various making skills, including circuitry, micro-controllers, soldering, and lo-fidelity prototyping. An understanding of each skill was critical to troubleshooting bugs, and subsequently, the success of the project.

Computational Thinking Skills

I was able to approach this project in a manageable way by decomposing the problem space into discrete and manageable tasks that I could solve methodically.

I began by dividing the background (technology) and foreground (physical interface) into two categories.

I broke the technology into three separate tasks: printing to an LCD display screen, initializing a buzzer, and incorporating a timer functionality to bring the two previous tasks together.

I further divided the first two tasks into their respective hardware and software components in order to create a discrete sequencing of tasks that would slowly build up the project. The timer was primarily a software task on its own.

I split the physical interface into two tasks: system and integration. This allowed me to focus on putting together a physical system, and then attempt to integrate it with the background technology I had already built. This phase of the project required a bit of iteration between tweaking the technology and physical elements so they would integrate smoothly.

Reflection

One of the most important things I learned during this project was perseverance. At times during the software work with this project, I was frustrated to the point of wondering whether I had bitten off more than I could chew with this project. There were times I wanted to give up and just say that I couldn’t figure it out. But with determination and caffeine and several sleepless nights, I was able to integrate the software.

I was also able to make strides in overcoming my apprehension in working with microcontrollers and code. I have had an inherent fear of coding ever since my first programming class, and overcoming this fear and believing in my ability to create and manipulate code has been very difficult for me. Selecting a project that challenged me to use microcontrollers has been the beginning of a new mindset for me. Instead of shying away from my weaknesses, I am challenging myself to confront them and grow stronger with experience.

That said, next time, I would give myself more time to troubleshoot and work with the software side of the project. Now that I am comfortable with setting up the hardware for a project like this, I will be able to allot more time to developing the code, and minimize long, frustrating crunch-time sessions. This project had a very short timeline to begin with, so taking that into account and giving myself more time to grow in weak areas is important.

Overall, this project was a major triumph for me in my SI career. This was my first experience going through the complete process of brainstorming an issue, and developing and prototyping a design solution. Since I had never done it before, I was unsure about how realistic my goals for this project were. Now that it is finished, I have experience with project planning given a specific timeline, and will be able to have a better idea of how to plan a project, and what expectations to set for myself in the future. Developing these skills are important to me as an Information major with a UX Design concentration, and I believe they will help me both in my academic and professional careers.

Thanks to Dr. Garcia for her help and insight in this project.

For reference list, click here.