IoT Medication Management

An internet-connected solution for monitoring and scheduling a patient's medicine dosages.

Comment

Inspiration

When consuming a prescription medication, consistency is vital. As such, the ability to monitor a medicine dosage schedule remotely presents a lot of benefits to the patient. A patient can use it to monitor their own schedule, or it can be used to keep better track of an ill loved when a visit is not possible. We wanted to make this monitoring process easier by providing an IoT based device.

What it does

The device is designed to remotely monitor a medicine's patient dosage schedule by monitoring their medicine container's location, keeping track of time, and monitoring the dosage time (set over Node-RED). If the set dosage time arrives and the medicine has not been picked up off of the designated platform on that calendar day, an alarm is triggered. If the medicine is picked up off the platform within one hour of the set dosage time, the alarm is disabled and the medicine is logged as having been taken. The dashboard also enables users to update the next dosage time as desired.

How we built it

Sensors

Force sensitive resistor, Real-time clock

Actuators

RGB LED, Speaker

The essential components of our device are (1) the force sensitive resistor, (2) the real-time clock, and (3) the alert system. The force sensitive resistor (FSR) is used as a platform for a patient to leave their medicine container on. In order to detect whether or not the container is on the platform, the FSR is set up with a fixed resistor as a voltage divider, whose output is connected to a SAMW25 GPIO pin. When there is a container on the platform, the output will read digital HIGH, and when there is not, it will read digital LOW. The real-time clock (RTC) is used for the device's timekeeping and alarm features. It is intended that the user sets the time of day they are supposed to take a dosage in Node-RED, which is programmed as an alarm on the device (a feature of the RTC). If the patient hasn't picked up the container off of the platform by the time the alarm time is reached, the device will trigger an alert. The alert system features an RGB LED and a speaker/amplifier, to alert the user to take a dose.

The Node-RED interface enables the user to:

Check if the container is on the platform

Check the last time a dose was taken

Change the set dose time

Manually trigger alerts on the device

OTAFU & Bootloader

The device also features over-the-air-firmware-update (OTAFU) capability. In our current implementation, when the device boots awake, it enters the bootloader code (at NVM address 0x00). This code checks the contents of the attached SD card and searches for a file called AppUpdate.bin. If it finds this file, its contents are written into NVM at the application address (0xB000), and then it jumps to the application. The code also incorporates a CRC-32 checksum to verify the written firmware. If the file is not found, it is assumed that the device was just flashed directly from the IDE and it jumps to the application. To trigger an OTAFU, a button on our Node-RED dashboard can be clicked to trigger a download of AppUpdate.bin from the SEAS server. Once the file is downloaded onto the SD card, the device performs a software reset and enters the bootloader.

Command Line Interface

When connected to a PC serial port, the device can be directly interacted with by sending (and receiving) information over USART. While a majority of this information is possible to obtain through Node-RED, this makes testing and development much easier for the engineer. The possible functions include:

getDoseTime: Returns the dosage time, set in Node-RED.

lastDoseTime: Updates Node-RED with the last dosage time.

doseToday: Updates Node-RED with whether or not a dose was taken today.

medicine: Checks whether or not the medicine is on the platform.

Challenges we ran into

One of the foremost challenges we ran into on this project was the force sensitive resistor, and specifically, the limitations it imposes. This off-the-shelf component has a threshold for the weight it can accurately detect, and we found that an empty pill bottle was not enough weight to gather an accurate detection. For our purposes, we used a pill bottle filled with candy to simulate the medicine container, which was enough weight to accurately and reliably tell whether or not the container was on the platform.

Due to errors in design and late arrival of components in the lab, the project is still plagued with hardware challenges related to our custom PCB. While work is still being done to flash the microcontroller and work with the external peripherals on the board, our current application code has been developed primarily on the SAMW25 Xplained board. We were able to breadboard a majority of the peripheral components to test the code, including utilizing a breakout board for the RTC.

What we learned

-Component selection based on goals, power consumption and budget

-PCB Design in Altium & best practices

-Power management design

-Microchip Advanced Software Framework

-Cyclic Redundancy Check

-The importance of bootloaders

-Debugging practices in an Integrated Development Environment

-HTTP Protocol

-MQTT Protocol

-Dealing with a hardware assembling firms and handling associated adversity.

What's next for IoT Medication Management

The foremost goal is to continue the board bring-up process, so we can flash our current application code and abandon the mess of wires between our development board and the breadboard.

As discussed, we had to deal with the hardware limitations imposed by our force sensitive resistor. A more efficient implementation would incorporate a capacitive sensor (or maybe even a MEMS based device); this would improve sensitivity while reducing the size of the device.

Future implementations and developments would incorporate other internet-connect devices to make the alerts more clear to the user. Instead of an RGB LED, we could use connected Hue lights (or even flashing a lamp on and off with a relay). Another option would be to connect to a Home Assistant or other connected audio system in one's home instead of our onboard amplifier and speaker. These improvements seek to make the device completely accessible to the user, effectively incorporating our product into their daily lives in a seamless manner.

Finally, an upgrade to the power supply and management sub-systems would solidify and stabilize this accessibility. This entails designing the device to incorporate a battery rather than a USB powered supply, requiring power-management through hardware and software such as brown-out detection and sleep mode functionality. Coupled with an upgrade to the FSR, this could potentially yield a portable device.

If this prototype were pursued as a commercial venture, it would need to clear compliance hurdles. Most notably, all systems that are used to transmit, receive, store, or alter electronic protected health information need to pass HIPAA IT compliance.

Built With

  • altium
  • atmel-studio
  • c
  • samd21
  • samw25
  • winc1500
Share this project:

Updates