Close

Day 1 - but not really

A project log for Medcheck

IoT pill dispenser with alerts to ensure compliance

bsuttonbsutton 03/15/2015 at 12:552 Comments

Initial work has started with an OpenScad 3D model of the MedCheck unit.

Cartridge design is well underway.

The pill chute and collector are virtually complete.

The chute has some gaps that need to be filled. This is caused by the spiral chute logic not giving each segment of the spiral sufficient height. Need to tweak the maths.

I also have some concerns over whether the pill chute will be printable. May need to add a 'support' spiral as an arch under the chute to print the unit.

Initial work on the dump draw is complete. Still need to create the opening for the draw in the outer shell as well as adding a locking mechanism and guides to make the draw easy to open and close.

Currently the whole unit has been designed to be 3d printed. The concern is that if we want to move to a high production model (e.g. injection moulding) I suspect that we will need to do a fair amount of redesign to make it possible to mill the required moulds, but one problem at a time :)

We plan on running the unit with a raspberry pie (or similar) as we are going to need to run a simple web server on the unit. We also need to be able to add NFC and WIFI (and maybe blue tooth) to the board. I know I can get a usb WIFI unit but I'm not certain what options are available for NFC. Still need to get my head around what NFC is capable of. The core idea with NFC is to do some basic initiation between the a smartphone and the MedCheck then hand over the real communications to the WiFI. The key problem is how you get the WIFI configuration into the MedCheck. Is NFC sufficient to do this? We could push the Pie into a WIFI access point mode (I'm plan on running linux or debian on the board). This would allow the smartphone to register with the Pie and then configure the Pie to connect to the patients wifi router. This feels a little clumsy. Many WIFI routers have an auto configuration mode but I don't think we can rely on this a being ubiquitous ( I think people change their smartphones much more regularly then they change their wifi modem).

I also have some concerns about relaying on these households having a wifi modem within range. But I guess if we are going to be an IoT device this just has to be a given.

I found a simple design for a R Pie mounting bracket [need to find and give an appropraite attribution on this] as well as a R Pie model which is handy for working out the dimensions.

Going to power the whole unit with an external power supply, Hmm can I use a USB power supply?

So work over the next week.

Complete the dump chute.

Finalise the dump draw (size and position).

Work on the dump draw locking mechanism - going to use servos and a cam to drive a locking bar.

Work on the lid and locking mechanism. Want to link the dump draw and lid locking mechanism to limit the required no. of servos (may not work).

I have concerns about only allowing a phone to lock/unlock the unit. What happens if you loose/replace your phone? How do you register a new phone with the unit?

The other issue is how do we deal with servicing units. If the R Pie is dead then NFC won't work and there for there will be no way to unlock a failed unit for servicing.

One idea to deal with this is to have the locking cams' have an external key mechanism which can be used to unlock the device. I'm thinking of a large 3d printed key. We want a large key to turn the cartridge when loading with pills so we could perhaps design this key for both purposes. A carer would normally not need to leave the key onsite as they can use their phone to unlock the unit but in an emergency, or in the case that we need to service the device, the key could be used to unlock the device. Of course I am thinking about a identical key for all devices we ship. Is this an issue?

We are also considering a model where we sign a deal with large chemist chains or medical insurance companies.

The ideal is that one of the above organisations ship pre-loaded cartridges out to patients. Each cartridge would have a rfid chip which can be used to ensure the correct cartridge has been shipped.

Chemist can make money providing the service (in Australia at least many chemists offer a service where by they hold onto the patients prescription).

For insurance companies I would guess that non-compliance costs them millions of dollars each year in unnecessary hospital admissions. By providing a managed prescription service the insurance providers could potentially save themselves millions each year.

Its now late. Going to bed.

Discussions

bsutton wrote 05/14/2015 at 05:08 point

Yes one of the problems is to work out the 'lowest common denominator' for the target environment. We want to design for the future without restricting its use in the present. I saw a reference to a amazon device that uses 'sound' to configure a simple device from your phone. Kind of nice as every phone has a speaker. Issue is that it won't be as realiable as rfid.

  Are you sure? yes | no

PointyOintment wrote 05/14/2015 at 03:56 point

> Many WIFI routers have an auto configuration mode but I don't think we can rely on this a being ubiquitous

You absolutely should not rely on that. Any security-conscious user buys a router without WPS or immediately disables it, because it's an unreasonably vulnerable protocol: https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup

  Are you sure? yes | no