Medcheck

I'm a big fan of open source and being a Ubuntu Gnome desktop user it generally fits my environment nicely.

Now I'm no CAD user, but during a former life I was a programmer, so when looking for a CAD solution OpenSCAD was a logical choice.

I've been using OpenSCAD on and off for a couple of years and generally I've been pretty happy with it.

The problem with MedCheck is that I've really felt that I've hit the wall with complexity when using OpenSCAD.

Even with a strong background in programmer and the accompanying understanding on how to structure a program, the reality is that when doing CAD you need to be able to easily visually align things. With a complex model OpenSCAD starts falling apart.

So I finally decided that I need to learn a traditional CAD tool, only problem was that running a Linux desktop makes this is a little problematic.

My first choice was to have a look at freeCAD which is actually based on OpenSCAD, so a fairly logical move and it runs on Linux. Only problem was that it was just a little too buggy, so I went looking again.

My brother (another maker in the family) then mentioned that he had come across a CAD system that was entirely web based, no install necessarily (runs using WebGL).

So with some skepticism I want a searching and found OnShape.

No, OnShape isn't open source (they raised $65M in seed funding), but to be honest after using it for a few weeks I don't care.

Its pure web based (with a beta IOS app and Android on its way) and to be honest, remembering I wouldn't know good CAD if I fell over it, it's fantastic. For a complete non-CAD user it's quite intuitive and I've managed to put a model together in a couple of weeks compared to months with OpenSCAD.

So the good news. OnShape is effectively free for Makers. The free version gives you five private model and an unlimited no. of public models (up to 5GB) , but the reality is that this is more than enough for most Makers. There is a paid pro version which allows you to store a greater no. of 'private' models and 100GB of storage. The free version has all of the features of the pro-version apart from the above noted limitations.

OnShape is still in beta but appears to be very stable. Oh, did I mention it has built in version control and multiple users can work on the same model simultaneously!

My opinion is that these guys are going to blow everything else out of the market and that makers will flock to this product.

And no I don't own any shares on OnShape, but I do know a good product when I see one.

Go try it out and find out for yourself.

www.onshape.com

Brett

Sometimes problems seem to swirl like a hurricane, ideas seem to build up a pressure in my head and then something happens, a singular problem can bring everything into focus and then everything seems to collapse down into a single clear solution.

And sometimes that idea or solution simply forces you to change everything and so it is has happened just now, minutes before the witching hour.

The problem came out of a dialogue regarding medication schedules and the realisation that often times a medication must be taken before, after or with a meal. Simply dispensing medication was no longer enough, we now need to provide instructions.

This is one of those defining problems that test the boundaries of an idea. Just how far should our design go and what problems should we try to solve.

I have a great weakness for taking too much on.

The problem is that I want elegance and simplicity and I want to do everything for everyone. The truth is that simplicity and everything are opposing ideas. But still, I'm going to try for both.

So the solution; the dispenser must have a screen.

My original premise was that the device would have a single button, it flashes when it needs to be pushed and you push the button to dispense. These were the only two actions that a pill consumer would need to worry about. The problem is that reality keeps getting in the way.

So now I need to inform them to take the medication with, before or after a meal and perhaps even remind them when to have a meal so that they can take the medication at the right time.

So a screen breaks some of my original design goals but at the same time it solves a mirade of problems that I've been trying to work around.

With a screen, we no longer need a NFC enabled phone to control the device, which means we can support iphone users again.

With a screen, WIFI configuration suddenly gets easier.

With a screen, we don't need to build a complex app for each phone OS in the market, instead a simple phone sized management web app will be sufficient.

But not just any screen. I hate microwaves and alarm clocks and fridges and the like that compromise on a dicki little screen that is essentially unusable.

We need to have a decent sized screen, which is capacitive touch and probably colour given our target audience. Fonts have to be large and clear.

So we have probably just added $300 to the price of the product, but I just don't like to compromise and the reality is that we were never targeting the low end of the market.

So now I feel purged. The pressure has been released in my head and I can go to bed. Perhaps I will come back to this blog in the morning and do some re-editing and re-thinking.

So need to nail down some design requirements so that we can finish off the db design.

As with any project getting the db design correct at the start will save a lot of pain and suffering later on in the project. To get the db design correct we need understand what we are trying to achieve with the overall system.

So some key questions and answers:

Q. Is the system 'device' or 'patient' centric?

A. Patient centric. We may even see a patient with multiple devices if they live at multiple locations or have dispensing needs beyond the capacity of a single device. Of course over a patient's life time they may have multiple devices (upgrades, failures). In either case we need to support the concept of multiple devices.

Q. Can a device have multiple cartridges?

A. The current design only allows for a single cartridge to be inserted at a time. A future design may allow 2 or more cartridges to be loaded into a single dispenser. Even with a single cartridge model we still expect each device to have more than 1 cartridge. Basically one in the device and the second one ready to be pre filled and then swapped into the device.

Q. Can a device have multiple patients?

A. At this point we don't foresee a single device dispensing to multiple patients. We have had some thoughts about a retirement home module that contains multiple cartridges with a cartridge per patient, but this is a long way away from any serious consideration.

Q. Can a patient be their own Carer?

A. Certainly. This is largely about the permissions model (e.g. who has permission to do what)

Q. Can a patient be their own Practitioner?

A. Whilst this isn't very likely (and perhaps not safe) it may be possible. But I think its fairly save to ignore this scenario.

Q. Can multiple devices be located at the same address?

A. This has to some extent already been answered. The reason I raise it again is that it has other possible ramifications. If you have two devices that are being used by TWO different patients, what is the risk that a patient will take a pill from the wrong dispenser.

I've suggested elsewhere that this could be dealt with by using an rfid bracelet which is used to identify that the correct patient is access the device.

Q. Can we share mediation descriptions between patients?

A. I've had some thoughts about using photos of tablets to help carers identify tablets when clearing the dump draw. I'm hoping that having access to a photo of each tablet that we might reduce the errors when recovering dumped tablets. The problem is that photos may not be sufficient for reliable identification and the size, shape and colouring of tablets may change over time and from manufacturer to manufacturer.

If the look of tablets from a given manufacturer is stable and photos are sufficient then sharing the medication descriptive data between patients may be beneficial. e.g. we load the data/photos once and then share the data between all patients.

I don't have sufficient information to make an informed decision on this one. As such I'm going to be conservative and assume that we won't share medicine data between patients.

Q. What type of scheduling do we need to allow for? Are there common patterns that we can provide or does the scheduler need to be fully customisable?

A. My experience with generic schedulers is that they are hard to use and hard to understand (just look at cron). As such I'm inclined to go with a template idea. Basically we load a set of standardised schedules into the system. When setting up a schedule the carer select an appropriate template and then does some simple customisation.

e.g.

Three times a day before a meal.

Three times a day with a meal.

Three times a day after a meal.

Before Bed

So this raises some issues that I've not previously considered. How do we convey information such as 'take before eating'. It also raises questions about timing. If I eat my meals at the same time every day then the dispensing schedule is easy, but if I have more irregular eating habits then a fixed schedule may not work. In some ways this is partially covered off by the concept of a 'travel pack'. The travel pack idea is where I'm off for an outing and won't be home for lunch therefore I need to take my tablets with me. The system can be configured to allow a patient to have the system dispense tablets early. This same sort of process could work for before/after/with food issues.

That still leaves us with the problem of how do we remind the patient that they need to eat the tablets with food, before food or after food.

More ideas/questions to come.

For your viewing pleasure, I've just uploaded a first pass attempt at an ER (entity relationship) diagram.

You can see it in the image gallery.

So there are a couple of questions around how we are going to communicate with the medcheck device.

In this case I'm not talking about NFC/RFID/bluetooth etc, but rather how the central medcheck site will talk with the medcheck device.

The reality with home routers is that the devices will all be nat'ed so we are unlikely to get direct access to a devices.

This may make several issues difficult. Firstly, we won't have direct ssh access to the device (despite a suggestion otherwise in a previous log) so how do we manage devices.

The obvious answer is that we need the device to call home. https is the obvious protocol for the device to send any notifications to us. We can also use a similar technique to long polling (without the long bit). The idea is to device check in on a regular basis (and may be initiated by a phone tap on the device) to see if the central system has any instructions for the device. This is often referred to 'phoning home' (no ET references please, it was a completely crappy film. Can anyone tell me why ET was able to fly to catch the ship at the end, but couldn't fly to catch the ship at the beginning. If he had only flown at the start it would have saved us all from having to sit through a complete load of rubbish).

So using the phone home concept the medcheck will use a two phase approach.

Every 'n' seconds the medcheck phones home by making a https request to the medcheck central server(s).

When a medcheck admin needs access to the medcheck device he instruct the medcheck server to return an 'ssh connect' command to the device.

On seeing the 'ssh connect' command the device issues an ssh request such as:

sh -N -R <port>:localhost:22 <user>@cmdserverhttp://.medcheck.com

The 'ssh connect' command also sends a port and one time use 'user' account (actually we probably one to send an one time use certificate - need to do some research here). We don't want to give the device any real access to our systems see need to look into how we secure the ssh connection from the device.

Once the device connects to us we can then connect to the device by:

ssh -l piUser -p <port> localhost

So we now have a basic method of secure communications. We still need a means of authenticating the device. We can use the device's Mac address or its RFID (will it have one of theses) or do we need a public key.

The actual protocol over https can just be REST we don't need anything fancy.

Some likely commands

PUT: Error: <Error Code>, <Error Message>

PUT: Notification <Warning Code>, <Warning Message>

PUT: Notification <Notification Code>, <Notification Message>

GET: Command - used for the phone home process

So with the hardware design slowly...... taking shape its time to give a little thought to the software pieces.

Essentially we are going to need a number of pieces of software:

1. Medcheck dispenser's firmware
2. Phone App(s)
3. Patient/Carer website
4. Practitioners website
5. Management website
6. Brochure ware

So lets have a poke at each of these and think about what they might look like.

Firmware

At this point we are considering the Banana PI as it supports most of the hardware interfaces that we need. As such we can probably drop one of the cut down linux OS on the PI and use Java to develop the firmware (yes I'm a java developer. I can do C/C++ but it's not necessary and it's not worth the additional pain).

So what does the firmware need to do.

Firstly operate the basic hardware on the device which includes:

• dispense pills when dispense button pushed
• operate buzzer/flasher for dispense button
• lock/unlock dump draw
• lock/unlock dispenser lid
• operate dump bridge
• rotate cartridge
• rotate cartridge into insert/remove position
• connect to LAN via ethernet or WIFI
• download dispensing timetables
• send error/warning alerts
• flash 'touch me' light when error/warning occurs
• transmit warning/error messages to phone when phone touches dispenser
• interact with phone to obtain WIFI connection details
• update carer website when pills dispensed

Phone App

The Phone App is intended to provides some basic management functions and manage any direct interactions with the device.

The trick here is to provide just enough functionality from the phone to make the experience feel fantastic without getting carried away trying to implement functions which are better off done via the Carer website.

So the key Phone App functions will be:

• configure WIFI for dispense
• unlock dispenser
• lock dispenser
• receive warning/error messages from the dispenser (via NFC or WIFI or bluetooth)
• check the status of the dispenser (what exactly this means I'm not certain).
• * probably needs to be able to do this locally (touch the machine) and remotely
• receive notifications of late dispense actions (although this may be better done via SMS)
• receive reminders that a cartridge is due to be changed
• check the status of the cartridge and the next fill date
• pause the dispenser - no further dispensing actions until unpaused.
• mark a specific slot to be dumped (I'm thinking of a remote change of mediation that may need to be done in a hurry).

Carer/Patient Website

The Carer website is where the majority of the dispenser management will occur.

• configure medication schedule
• print cartridge fill guide for specific date range
• authorise third party to manage medication schedule
• view errors/alerts from dispenser
• unlock dispenser
• lock dispenser
• check status of dispenser
• view log of dispense actions
• view date of next cartridge change
• set alert thresholds for notification on late dispenses
• login/logout
• view session history
• log cartridge change (needs to be linked to the fill guide)
• safely modify medication schedule part way through cartridge rotation (still requires cartridge change out).
• assistance to empty/sort tables from dump draw (pictures of different tablets might be useful to aid in identification). This one makes me nervous as what happens if a pill is mis-identified?
• Enter key data about patient including photo for clear identification by Practitioners. At a minimum: Name, Address, DOB, Insurer, Patient identification no.
• View billing history
• Make payment for access to medcheck website.

A wild thought just popped into my mind.

What if we have a household with multiple Medcheck dispensers? This sounds great except that we then have the added problem of ensuring that the correct patient is using the correct dispenser.

So how do we deal with this?

• Finger print scanner
• Facial recognition
• Tattoo
• RFID bracelet

Yes Tattoo was intended as a joke, but no wait...

RFID bracelet seems the most practical and reliable, particularly given that many patients wear medical bracelets anyway. We could configure the dispenser to only dispense when the dispense button is pushed and the RFID bracelet is near. (So what exactly is the range of an RFID?)

Practitioner Website

We probably won't build the practitioner website the first go around. The idea is to allow a practitioner to managed multiple Patients medication schedule

Major concern is that a Practitioner may end up managing multiple medcheck patients and there is therefore a risk that they may mis-identify the patient's medication schedule that they are working on. The intent is to display a photo of the patient in the top right hand corner of the site at all times. This should provide a strong confirmation to the practitioner that they are managing the correct Patient's schedule.

The practiitioners Website should allow the Practitioner to:

• configure medication schedule
• print cartridge fill guide for specific date range
• authorise third party to manage medication schedule (what are the legal issues around this?)
• view errors/alerts from dispenser
• unlock dispenser
• lock dispenser
• check status of dispenser
• view log of dispense actions
• view date of next cartridge change
• set alert thresholds for notification on late dispenses
• login/logout
• view session history
• log cartridge change (needs to be linked to the fill guide)
• safely modify medication schedule part way through cartridge rotation (still requires cartridge change out).
• assistance to empty/sort tables from dump draw (pictures of different tablets might be useful to aid in identification). This one makes me nervous as what happens if a pill is mis-identified?
• Enter key data about patient including photo. At a minimum: Name, Address, DOB, Insurer, Patient identification no.

Management Site

This one is for us to manage users.

• add/Delete/Disable/Enable/Edit user details
• bill users
• report on user activity
• refund payments
• credit account balance
• debit account balance
• check patient device status
• upgrade device firmware

There is a big issue about what access we should have to patient data. The more data we have access to the greater our risk of staff or hackers misappropriating data.

We do need detailed access to the device status and probably its logs in order to diagnose problems.

This opens the whole question of device management, release cycles etc. Given we are using linux on the device we can use apt-get and a repository to push out firmware updates. Do we need something more sophisticated to device management? We will be able to access the device via ssh so on device management should be easy provided its connected to the inet. What can we do if the device won't connect to the inet. The most common problem we can expect to see if people not been able to connect the device to WIFI or inet.

Medcheck is all about taking pills, so having an optimal mouth is critical to Medcheck's success.

Now don't get me wrong, I'm an evolutionists, but sometimes you just need an Intelligent Designer's hand involved to get the best results.

Given we don't have any Intelligent Designers here abouts, it looks like I'm going to have to get involved :D

For sometime, I've been concerned about the mouth of the MedCheck dispenser when used by people with low hand mobility. Arthritis for instance, is likely to be a common disease amongst our demographic.

The current design requires the user to scoop the tablets out of the dispenser, probably into a cup and then take the tablets. This requires a moderate amount of dexterity.

So an alternate design might be to dispense directly into a cup.

Introducing a cup creates some problems of its own and greatly increases the complexity of the design. But lets ignore those problems for a moment and explore the path.

Missing cup

If the cup isn't in the dispenser or isn't properly seated in the dispenser then you can't dispense tablets.

Given that we expect our demographic to potentially have memory issues, misplacing the cup is highly likely.

So for a cup design to work we need several things.

1. The cup must be easy to insert/remove

2. It should be hard to mis-align the cup

3. MedCheck must be able to detect a missing cup

4. If the cup goes missing we need a simple way to find the cup.

5. Can we turn the cup into a travel pack?

So lets go through each of these one at a time.

Easy insertion/Alignment

So in my experience these two things are at opposing poles. A device that ensures correct alignment often tends to make it hard to insert the device. The only way to see if we can get a nice balance is to do some design work. Where is that Intelligent Designer when you need one?

Missing Cup Detection

The simplest solution is some type of micro-switch, but I don't love moving parts and from experience they tend to compound the alignment problems. My wife has one of those over-priced Thermomix's (which she loves; but she would have to say that given what she paid for it) and it uses a microswitch to ensure that the lid is closed and its always a bit of a bitch to close properly (and one imagines that they have a few intelligent designers chained to a work bench somewhere in Germany).

The other solution is some type of field device. RFID is one possibility and then we can add DRM to the cups, so you can only buy the cups from us :D . Whilst I joke about DRM, its actually not a bad idea as it would ensure that the correct cup is inserted and that no pills will be lost due to 'cup misalignment'.

Make cup an iBeacon device

If you haven't had a look at iBeacon or better still altBeacon its worth a gander.

If I've understood the tech correctly, its essentially a low power Bluetooth protocol that outputs a gps style signal. The signal can be used to determine the current distance from an object with a beacon attached. Some of the implementations allow the determination of a distance and a direction via triangulation, if multiple beacons are deployed .

iBeacon is Applies copyrighted (as that a word) name for a blue tooth low power protocol. Apparently some of these beacons can operate for two years on a small battery. AltBeacon is a more open standard that works across Android devices and it looks like there are beacons that can talk to both Apple and Android.

So back to the cup. Given our demographic losing/misplacing a cup seems highly likely. So designing the cup as a bluetooth device which can beep and buzz when you loose it, seems like a cool idea. If you then go further and add the beacon technology to the cup you can use your smartphone to locate the cup.

We wouldn't be able to use the triangulation technology of the beacon as we will only have two potential beacons the cup and the medcheck.

Hmm, maybe thats not actually true. I think I read somewhere that your phone can also act as a beacon. Does that mean with cup, medcheck and the phone we can actually do triangulation or do we need a fourth device? I'm pretty sure that the gps system needs at least 4 devices but that is probably to do with the need to calculate altitude which we don't.

Make the cup a travel pack

So if we are going to make the cup intelligent why not put a timer in the cup and add a lid.

If you are going out for the day you can get medcheck to 'pre-dispense' your medication into a cup. When the medication is dispensed the unit also programs the cups timer. When its time to take your meds, you cup beeps, flashes and vibrates.

You can then have multiple cups pre-programmed for doses during the day when you are traveling further.

I have to say, that I love this idea and it does justify further investigation.

Summary

At this point I'm going to put this idea on the backburner as its a fairly complex addition and we have our work cut out for use getting the rest of the model done. If we make some stunning progress on the rest of the system I would like to come back and revisit this idea.

The travel pack idea really does need to be looked at. What about a standalone product - a programmed travel pack.

Just after I mentioned Apple's wall garden, I managed to hammer my head straight into it.

So it turns out that iphone 6 (IOS 8) supports NFC, well sort of.

With that typical Apple 'stuff you' attitude, they only allow NFC usage for Apple Pay.

I really have to ask why people buy Apple devices, it must be the nice Apple boxes they come in.

So in the meantime 'stuff you Apple'.

Found this somewhat useful link on installing an Android App via NFC:

http://developer.android.com/guide/topics/connectivity/nfc/nfc.html#aar

Now need to find the same for IOS.

Should we support Windows Phone?

Nope.

So we started a conversation about set-up and installation of MedCheck.

I was focused on the technical details, but Tristan came from quite a different perspective. To use Tristan's words, he was looking for that 'Apple experience' when unpacking the box.

Whilst I hate many things about how Apple conduct their walled garden, you have to give them credit for creating great hardware and that fantastic Apple out of the box experience.

So how do you achieve that 'Apple experience'.

Simplicity and in Tristan's words once more; 'no white is too white', hmmm.

To me the simplicity must be in hardware and in the initial setup, but to be honest I'm not too keen on white :)

So the hardware:

The MedCheck unit will be a single barrel about 20 cm wide by 30 cm high.

The unit will have two ports, power and ethernet, with cables supplied for both. We are hoping that we can put the power pack inside the unit (we have plenty of space at this point) as we find external power packs ugly and messy.

When you un-box the MedCheck it will come with a single page setup guide.

• The guide will show how to plug in the power cable.
• Power the unit on.
• Wait for the red light to start flashing.
• Touch your phone to the 'Touch Phone Here' panel.

The 'Touch Phone Here' panel is where the magic and simplicity start.

I should note that we have some concerns about the reliance on NFC and a smartphone. While there are high rates of penetration of smartphones (in Australia its over 78%) not everyone has a smartphone and not all phones have NFC and not all NFC phones have NFC enabled. Reality is that we need to start with a target audience so smartphone with NFC enabled is where we are going to start.

We have intentionally not put a screen on the device, as we wanted to ensure that we didn't end up with a Microwave/Video player interface. As such the smartphone screen is going to be the device's screen. What that means is that if the device wants to say something, then it needs to communicate with your smartphone screen. Once the device is setup, communications will mostly be easy. During setup and if the device looses its internet connection, life gets more difficult. This is where the 'Touch Phone Here' (TPH) panel comes into its own, along with the associated flashing red LED. Whenever the device needs attention the LED on the TPH panel will flash. Touching your phone on the TPH panel allows the device to communicate with your phone via NFC and the phone will then take the appropriate action or display a message such as an alert or an error message.

So on powering the device up for the first time, the TPH LED will flash.

The users touches their Phone to the TPH panel and the device instructs the phone to download the MedCheck application (is this even possible?).

Once the MedCheck application is installed the registration wizard kicks into life.

The registration wizard will ask for basic details which will primarily be your email address (to handle forgotten passwords).

The wizard will then contact the MedCheck Web Application, create a user account and register your MedCheck device (during the initial NFC exchange the device will provide a unique ID such as the unit's MAC Address).

The MedCheck Web Application will email the user a login link, that will prompt them to create a password for accessing the MedCheck Web Application.

The MedCheck application will then begin the internet setup by asking the user if they want to use the ethernet cable or WIFI.

Depending on the answer the system will instruct the user to plug in the ethernet cable or enter the WIFI access point name and password.

The MedCheck app will then prompt the user to tap their phone on the device which will send the WIFI access details to the device (if WIFI was selected).

The device will then connect to the internet and register with the MedCheck Web Application. The MedCheck phone will be waiting for the registration and will notify the user once it completes.

If the device is unable to register, it will flash its TPH LED. When the user taps their phone on the device it will provide error information to the MedCheck phone app which will then assist the user in resolving the issue.

At the end of the above process the device is configured and ready to operate.

As a signal to the user that it is ready (apart from the MedCheck phone app informing them of same) the unit will rotate its cartridge to ensure its is properly positioned and then open the devices lid ready for loading.

At this point the user will be encouraged to log into the MedCheck Web Application and start entering a medication schedule. Once the medication schedule is complete they will be able to view and print a Filling Guide along with instructions on how to fill the cartridge.

We expect our main market to be Carers. Most Carers would have the device delivered to their own home and are likely to want to register and initially fill the cartridge away from its final location. As such the device needs to be able to be re-registered on a new network when it is moved to its final location.