PRE2016 3 Groep9

Smart Medicine Dispenser System (SMDS)

Group 9 Project Robots Everywhere

Name	Student ID	Department
Chiel Düthmann	0962340	Mechanical Engineering
Dirk van Wijk	0957434	Mechanical Engineering
Jasper Hoek	0966272	Mechanical Engineering
Mark van der Pas	0946552	Industrial Engineering
Yoshi de Laat	0964351	Mechanical Engineering
Maija Rintala	0978153	Psychology and technology

---

Introduction

More and more people, especially elderly, have complex medication disciplines, with a whole range of different medicines. However it is important to take the right medicine, in the right dose, at the right time during the day. Missing a dose or taking more medicine than necessary could lead to dangerous situations, but also taking medicine that don’t go together at the same time, may have negative consequences. In 2013 almost 49,000 people older than 65 were admitted to the hospital as a result of wrong medication usage, of which 48% could have been prevented . A system that would remind the user to take their medicine by dispensing the right amount of medicine at the right moment, would prevent a big part of these situations. Other electronic devices and an active internet connection can provide extra possibilities for such a system. Therefore, our goal is to design a smart system that dispenses medicine in such a way. This system will have the basic function of a medicine dispenser: dispense the right medicines and notify the user if he/she has to take his medicines by an alarm. However, because it will be connected to the internet, there are extra possibilities for notifications on smartphone and an automatic update of the medication discipline if the doctor’s prescription changes. This wiki page will describe our project, including state-of-the-art, USE aspects, research, and the design process.

Goals

Design a simple and safe medicine dispenser

Easy to use, especially for elderly and disabled people

Smart; uses internet of things

Secure

Easy to refill

Challenges

What are critical parts of the system?

What functions should the design include?

What will the interface look like?

Who is responsible if something goes wrong?

How to design a dispenser that doesn't jam?

How will the device function without an internet connection?

How is it refilled?

Will this increase the workload of doctors?

What is the improvement over the already existing systems?

Approach

Conduct a literary study of existing technology to achieve our goals and solve our challenges

Design the prototype

Build the prototype

Program the prototype

---

Final Design

Final Design: hardware concept

After seven weeks of research and discussing about the design (a brief description of the design process can be found here) we came to a final (concept) design of the Smart Medicine Dispenser System. The findings of our research on user needs were used to come to this final design.

This section will describe the main elements of our design. This design includes both the hardware device, that can be placed inside the user’s house and the software part, with the database and the application provided for doctors and caregivers.

Main device

The main device is the device that is placed in the user’s house. Inside this device the modules, containing the pills, can be placed, the modules are described in more detail in the next paragraph. When a module is placed in the device it connects to the system. Inside the device, there is a corridor system through which the pills are transported from the modules to the tray where the pills are collected. The interaction with the user, the client of the device, is done by making use of a display on the main device. The display can for instance show instructions on how to take certain medications, more details about the display (user interface) can be found below. Inside this main device, there are some checks/‘inspections’ to ensure the system works well. One such a check is a light sensor, this sensor is located underneath the module where the pills fall out. The sensor can be used to check if a pill is dispensed and if the right number of pills are dispensed. In case there is no pill dispensed a new signal can be sent to the motor to dispense a pill, and in case there are too many pills dispensed, the user and/or caregiver can be warned. There is another sensor above the module that can be used to check the stock level of the pills inside the module, which in turn can give a signal to the user, caregiver or pharmacist that there is a need for a new medication module.

Module

The modules are the boxes with pills that can be placed in the main device as described above. For our design we chose to have boxes with dimensions of 10x10x13 cm. In practice, it will be best to provide a range of smaller and bigger modules, since it varies per user how many pills they have to take. The modules also contain the dispensing system that ensures only one pill is dispensed at a time. The dispensing system consists of a wheel with eight gaps, at the edge of the wheel. The size of the gaps and the number of holes can be varied and adapted to the type and size of the pills inside the module. On top of the wheel there is sort of stirring mechanism to ensure the pills will fall in the gaps. Underneath the wheel there is a platform with only one gap in it. When the gap of the wheel containing a pill is above the gap in the platform, the pill will fall through and is dispensed. In order to prevent two pills being dispensed at the same time, there is a small lid designed above the wheel at the location where the pills can fall through. In the module, there is a servo or stepper motor that rotates the dispensing wheel. When a module is placed in the main device, pins are plugged in, so the 'dispensing motor' can be controlled by the system. Every module will also contain an RFID-tag (Radio-frequency identification-tag). These tags will be used resulting in the main device knowing which pills are at what location in the main device.

Software

The software design consist of three parts: the cloud service, the web portal and the device client.

The cloud service

The cloud service contains the data for all users, this includes the medication discipline for every client and the history of medication intake. Next to the database function, the cloud service is also used for communication between all the different devices.

The web portal (for the professionals: doctors, pharmacists and caregivers)

It is intended that this part of the software will be integrated in the existing systems the doctor, pharmacy and caregiver use, so they don’t have to work with multiple systems. However, for our design we used a web portal for the proof of concept. The web portal has the following functions:

• Insight in medication discipline: the doctor, pharmacy and caregiver can see the current medication discipline of their clients.
• Adapt medication discipline: the doctor can adapt the medication discipline of his/her clients. This implies he/she can add or remove medicines, or change the moment a client has to take a certain medicine and thus change the dispensing moment.
• History of medicine intake of client/patient: the doctor and caregiver can see the history of the medicine intake of their client, so they can for instance see if a dose was missed.

The device client (display on the device, for the user of the device)

The device client has the following main functions:

• If pills have to be dispensed, this is done by a ‘dispense’ button on the display
• On the display, instructions on how to take certain medicines can be shown
• The user can have insight in the history of medicine intake, every time a pill is dispensed the history is updated
• From the interview with the pharmacist we got information about PRN (Pro Re Nata) or ‘as needed’ medication; medicines someone may take if he/she feels it is needed, for instance paracetamol. In this regard, our system has an advantage compared to for instance the medication roll, since the option to dispense such a pill can easily be added. The history of those pills can also be stored, since there may be a maximum number of pills per day or a minimum time span between taking these pills.
• There is an early dose option, this is useful for the users when they have to leave their house for a longer time, for instance if they go on a day out. Pills can then be dispensed early and can be taken along in a box.

A more detailed description of the software's features can be found in the Software features section.

How the system works

When a user has to take in their medication he/she will be notified by an alarm, it is possible to add the option to (also) get a notification on your smartphone. The dispensing of the pill(s) will start when the user hits the dispense button on the display. At the moment the pill(s) is/are in the tray, the user can take it out and take the pills, meanwhile instructions on how to take the specific pill can be displayed on the screen. If more pills have to be taken at the same moment they may all be dispensed at once. Since most medications have an expiration date, pills can only be stored in the modules for about one month. When the pills have to be refilled the pharmacy will get a notification, so a module can be prepared and provided to the client. These modules can be delivered by a delivery service of the (local) pharmacy, as is done these days for the medication rolls. For vulnerable users, for instance elderly with dementia, the employee delivering the modules may also replace the modules in the main device, to ensure this is done correctly.

Follow up research and development

Of course our design is just a concept and not a fully developed system, that is ready for use in practice. There are different aspects of our design that need to be investigated further in order to deliver a complete and user friendly system. Some of those aspects are:

• What are ideal sizes for the modules?
• Is it beneficial to have a module where pill strips are placed in, so it needs a mechanism to press pills out of the packaging?
• Is it possible to add an extra check to ensure the user actually takes his/her medicines and not only dispenses them?
• How to implement the software part for the professionals (e.g. implement in current system or design a complete new system), therefore research has to be done on the preferences of the users of this system (doctors, pharmacists and caregivers).
• A critical part of the system is that it is connected to the internet, how will the device function if the internet connection fails?

---

Prototype

A major goal of our project was to come up with a prototype of the device we designed, in order to demonstrate how it operates and test how it functions in practice. Since for the design of the system we mainly focused on the module and the software (also the most critical parts of the system), we only included these parts in the working prototype. This section will describe (the building of) the prototype.

Hardware

Based on the CAD sketches, we started building the module. The first component was the wheel for the dispensing the pills. Since the wheel is a design specific component, we chose to 3D print it. This wheel is glued to a 180 degree servo and placed in the module ‘casing’. The complex part of the module casing (part around the wheel, funnel and lid) is also 3D printed, as well as part of the casing around this ‘complex part’. Underneath the 3D printed part there is a small case made of wood. This part is used for holding the servo and to ensure the prototype remains upright. For our prototype we only included this small part of the casing, since that is sufficient for testing the dispensing mechanism.

The prototype is controlled by a Raspberry Pi (with touchscreen), for the software and the display, in combination with an Arduino for the servo control.

Prototype electronics

• Raspberry Pi 3 (model B) + touchscreen
• Arduino Uno
• 180 degree servo
• Wires
• Power source (small accu)
• Voltage regulator (LM2596s Step Down Module Voltage Regulator)

Software

The device client part of the software runs on the Raspberry Pi and the graphical interface is shown on the touchscreen attached to the Raspberry Pi. The other parts of the software, the cloud service and web portal, work as described in the Final Design section. Technical details about the layout of the application architecture and the database, the programming languages used, and the code repository can be found in the Software Design section on this wiki.

Testing

When testing the prototype, sometimes the dispensing of the pills (in our case Mentos gums) didn’t go well, since two or no pills were dispensed. This was a hardware problem, mainly caused by the type of servo used. The servo used in the prototype has a range of only 180 degrees, this means at some point the servo has to change rotation direction and therefore the same gap in the wheel will be above the ‘fall through’ location two times in a row. Thus the probability a pill falls in that gap before the gap is above the 'fall through' location is much lower. By using a motor that can keep rotating in the same direction all gaps will make a full rotation before they are above the 'fall through' location. The other parts of the prototype functioned very well, as can be seen in the demonstration video of the software features. This video shows the different functions of the display on the device and the dispensing of the pills by the module.

• Some pictures of the prototype
• 

  Prototype of the module filled with 'pills'

• 

  Gear filled with 'pills'

• 

  Prototype of the module

• 

  3D printed dispensing wheel

• 

  3D printed part of the module

• 

  Base of the module

---

USE Aspects

User

The primary users of the automatic pill dispenser are the patient and pharmacists that have direct contact with the device daily. The secondary users are the doctors and employees of the pharmacy that do not have direct interaction with the device but are involved with it through their work. The tertiary users are the manufacturers and repairmen of the device.

Possibility for independent living

The main benefit of this technology will be patients being able to live independent longer in their own homes. Often times, the elderly and disabled have to move on to assisted living, as they can’t be trusted to take care of their medication anymore. Studies have shown that elderly thrive better when they can continue living at home as long as possible.

Though the device will not be able to fully guarantee that the patients take their medicine on time, it will be able to at least alert the care works if a dosage was missed. Thanks to this, the care workers will be able to save time by only having to visit the patient when they’ve missed a dosage.

The requirements for independent living do still require the patient to be relatively mobile and in their right mind.

Safety and accuracy

This device will guarantee more safety to the patients, as their dosage will be exactly right and given at the right time. As the device will also be easy to use for all user groups, less errors should happen in patient care and lots of time will be saved. Studies have shown that facilitating communication between clinicians and patients in regards to medicine is beneficial to the patients , and this is exactly what our technology aims to do.

Trust in the system

The implementation of the system raises some concerns about privacy and security. If the device is connected to the internet, it will be very important to have the information encrypted so that unwanted parties will not be able to gain access to it. The problem of hacking is also possible, if the device is not properly secured. It is possible someone might hack the device to dispense too much medicine or none at all. An elderly or disabled person who blindly trusts in the system might not find this strange, which might end up severely hurting them.

Because common sense seems to be required in the use of the system, some mistrust in the device seems to be good so that patients can recognize when it is malfunctioning. However, too much mistrust might lead to problems as well. If the user does not believe that the device is giving them the right amount of medicine, they might take it upon themselves to trick the device into thinking they’ve taken their medicine. This again, might lead to severely hurting the patient. Another problem with too much mistrust in the device is that the patient might feel the need to check with the doctor or pharmacist if their dosage is right very often, and checking this will add to their workload.

Solution to these problems could be giving the patient a note which tells them when their device is supposed to work and what it is supposed to dispense. In this way, if the patient feels unsure, they can first check the note before calling the doctor or pharmacist.

Responsibility

One of the biggest challenges with this technology is to find out who has the responsibility if things go wrong. To deduce what sort of rules assignment of responsibility should have, we have to think of different cases.

Patient missing dosage because of device malfunction. It seems obvious that the manufacturer should be the one responsible here. As the goal is to create as safe and easy to use system, the manufacturer should take the responsibility when it fails. The company should follow the same warranty policy as many other technology companies; the user is covered in case of the device breaking or malfunctioning as long as no external tempering has been done to the device.

Patient taking the wrong dosage because of wrong prescription or incorrectly filled medicine containers. Both of these situations are examples of medical malpractice and therefore the doctor who made the prescription or pharmacist who filled the containers incorrectly is liable. The employers of these persons could also be seen as responsible in the case that they have not provided them with proper training but in this case the personnel should’ve taken it upon themselves to express their concerns about lacking proper training. There is one last party that could be seen as seen as responsible in this case; the manufacturer. If the user interface is unclear in how the prescription should be entered or read and this leads to an error, the manufacturer can be blamed for the incidence. As long as the design of the interface is developed and tested extensively with medical professionals, the manufacturer can argue that the incident did not happen because of their design but because of human error.

Missing the dosage because of patient’s human error. In this situation, the intuition is to immediately blame the patient, which will in most cases be the right choice, especially if the user tricks the device to think they’ve consumed their medicine. However, the situation gets more difficult when the patient misses their dosage because they’re too old or disabled, for example because they are sleeping or confused. This is exactly the case that the device is supposed to solve, as it will alert a health care provider about a missed dosage, who will then be able to come and check that everything is okay. If the patient still ends up missing their dosage, the responsibility will be on the health care provider.

Lack of personal freedom in taking medicine

An important thing to note is that this device limits the patient’s personal freedom in some ways. One main way this happens is because the patient is limited to staying at their house when their dosage is due. Because activities are important especially in the lives of the elderly, there can be negative mental effects from for example not being able to join a family member or a peer for a walk.

This situation could be improved by adding an option for the patient to tell the device if they aren’t going to be home at some time. This could either send a request to a health care provider to ask for the medicine to be dispensed now so that they can be consumed at the appropriate time or by being able move the dispensation time by a few hours if the timing isn’t as strict. This of course will increase the work load of the health care providers as well as complicating the user interface by adding more options.

Neglect

As this technology will allow the patients more freedom for independent living, it means that they do not need as much assistance from care workers. A downside to this is that for some people, these care workers are the only human interaction they get and automating this process will lead to more lonely people which in turn will cause mental issues. Some might purposefully miss their medicine in order to get another human being to visit them, which wastes time of the workers and puts the patient in danger.

The technology also distances the care providers from the patient by putting in a middle-man which might make them see the patient as less real and human and therefore affecting their care solutions. Doctors might sway towards prescribing more drugs instead of seeking other treatment options, as it is an easy and safe solution for the patient and less work for them. These problems root themselves in already existing societal issues, such as elderly loneliness. Though the technology might worsen the situation for the patients, it also helps many by giving them more freedom. The technology itself can’t really improve the loneliness aspects for the patients since this is a problem that has to be solved on a more societal level. It is still important to take note of this issue in designing the system.

Society

The society that will be affected by this technology includes the multiple groups. The elderly and the disabled will be the main customers of this development so they as a whole are affected, as well their care workers and families. This device will also shape the way the medical industry takes care of patients, so medical institutions are also being affected.

Keeping healthcare affordable

As there will be fewer mistakes in medication intake, fewer people will need hospitalization or doctor’s appointments. The possibility to live longer at home will also decrease the amount of people who need to be placed in a care facility . All of this amounts to less costs for the patients as well as hospitals.

Elderly can live at home longer and independent

Many points related to this aspect were already discussed in part 1. In this section, more societal aspects will be focused on; mainly how it will affect the elderly and disabled that do not need or yet use this technology.

As more elderly and disabled are able to live at home, issues of loneliness have a chance to improve or worsen depending on the conditions. It is possible that these people could form stronger networks amongst each other and stay active together through the newly acquired freedom(note issue at 1.5.). This is overall a very positive development thanks to this technology.

If not enough people live nearby to the patient, these support networks might be difficult to form. Overall, this should be improving thanks to the technology, as more people will be able to stay at home and there are better changes that someone in the same situation as you will be living close by. The issues mentioned in 1.6. are still important to note for these people.

Health care workers

Something that needs to decided is if the responsibility for programming the dispensation of the medicine belongs to the doctor or the pharmacist. As the doctor knows the patient’s background better and can discuss the different options for taking the medicine, it would make sense that they write the plan and then send it to the pharmacist to program into the device. This might however increase the workload on both doctors and pharmacists and take away from time that could be spent on seeing other patients.

Though health care providers will have more time as they only need to go visit the patients when a dosage is missed, the workload might also increase as people miss their medicine and they have to go check there. The checkup could also be arranged by the way of a phone call to save time. If many people are prescribed to take their medicine in the morning and many of them miss their dosage, it is unclear what priority order should the worker go check up on them.

Because of the time saved, the doctors might refer more and more people to use these systems even if it is not necessary. For some, it might create more issues because of lack of freedom mentioned in 1.5. or they might not afford the technology. Doctors might become more likely to prescribe patients with medicine rather than looking for alternative options. Therefore, the doctors need to also evaluate ethically if it is necessary to recommend the patients towards this technology.

Less worrying for family and neighbors

This might seem as an obvious positive aspect of this technology but again the lack of worrying might lead to neglect by the patient’s loved ones. Knowing that the machine will take care of the patient might make family members feel that the patient is being taken care of and therefore not visit.

In the case that the device fails in notifying a health care provider about a missed dosage, no one else might think to go check on the patient which might have fatal consequences.

Enterprise

The enterprises of this technology are the parties that will financially benefit from using this technology. The main enterprise will of course be the company manufacturing the device but it is important to also note that pharmacies and pharmaceutical companies will benefit from this technology as well.

Lobbying

In the early days of the technology, the manufacturer will have to make themselves known to doctors, pharmacies and the public as a viable option. This is often done with the use of lobbyists who try to influence different parties about the benefits of the product or service.

Working together with pharmacies, pharmaceutical companies, doctors and patients will also help their cause as well as teamwork with universities or research companies.

Profits if the technology is adopted into wide usage

As the technology becomes more widely used, the manufacturer will gain profits. This in return will allow the company to invest into more research for creating an even better device.

Responsibility

The issue of responsibility was discussed in 1.4. It is in the best interest of the manufacturer to create a product that leaves as little responsibility to them in case of a malfunction. Best ways to achieve this are by making the device as secure, safe and easy to use as possible. These aspects have to be vigorously tested in order to argue that they are not liable.

Training of the repairmen, pharmacists and doctors also falls under the responsibility of the manufacturer.

Reduced costs in employment

As this technology will decrease the amount of workers needed in pharmacies as well as health care workers, this will mean reduced costs for the employer. However, the workers who will keep working will need to be trained to use the device, which on the other hand might increase costs.

Mistrust in technology

In the early days of this technology or the case of a malfunction that can be confirmed to the fault of the manufacturer, the public might lose trust in the technology. This could lead to doctors and patients avoiding the use of this technology.

In the worst case scenario, certain pharmaceutical companies might ban their drugs from being used in these devices. This could be detrimental to the technology’s success. The best way for the manufacturer to avoid this situation is to take responsibility and improve their design until a more acceptable version can be created. Working together with pharmacies, pharmaceutical companies, doctors and patients is the surest way to achieve a good outcome.

---

State of The Art

Existing medication reminder systems

There are various (non-)electronic ways to assist people in taking the right medicines at the right moment during the day. The most important state-of-the-art around the medication boxes is mentioned below.

The classical medication box system

The classical box system like in figure 1, is the most obvious state-of-the-art since that is the everybody's view when talking about pillboxes

Figure 1: A simple medicine box

. It consists of seven boxes, one for each day of the week, and every box has four compartments corresponding to four times of the day, for example; morning, noon, afternoon and evening. The user can simply take out the box in front and take the medicines out every time this is needed. This state-of-the-art is mainly used on a daily basis at home.

Medication roll

Another existing system is the medication roll, in figure 2 there is a picture of such a medication roll

Figure 2: Medication roll

. This roll consists of plastic pouches filled with the medicines for a moment during the day, which moment is indicated on the pouches itself. The pharmacy can provide these rolls filled with all medicines. In most cases these medication rolls are packaged and filled by packaging machines from (for instance) Baxter . These medication rolls are commonly used these days, not only by (elderly) living on their own, but also by caregives in elderly home.

Electronic medicine boxes

One of the more basic electronic systems is the electronic medicine box, like the MedMinder (figure 3)

Figure 3: Electronic medicine dispenser box

. The system has 28 trays, each of which can be loaded with one dosage. For how many weeks/days the dispenser can be filled depends on the number of dosages per day, for instance with two dosages per day the dispenser can hold two weeks of medication. If a dosage has to be taken, the right compartment will unlock and a led will blink. The system can be extended with different types of reminders (like a bracelet), a telephone connection and a medical alert function.

MED-E-LERT

The MED-E-LERT (figure 4)

Figure 4: MED-E-LERT

is a round device where you load in the medication discipline for the coming days, it can simply be seen as one of the first evolved classical pill boxes. The MED-E-LERT is an automatic pill dispenser, the date and time of the alarm can be set. The working principle is pretty straightforward; if the user has to take their medication, the disk will rotate to the right box. Thereafter, the user will get a notification by the implemented alarm clock of the MED-E-LERT. This can be provided until six times a day and 7 days a week.

Philips Lifeline

The device of Philips, the Philips Lifeline , works somewhat similarly as the MED-E-LERT device. The medicines are loaded into cups and placed into the dispenser. An extra advantage of the system of Philips is that it can connect to the telephone line, so someone can be notified if a dose is missed.

Evondos E300

The Evondos E300 is a compact system where you load in a medication roll (Baxter rolls), as mentioned before, with the right doses of the medicines. It gives an alarm if the user has to take his or her medicine and by a push on the button the right medicine dose comes out. This system has a display where instructions on how to take the medicines can be shown and it is connected to the caregiver’s Telecare system by the internet. So when medicines are not taken they can be notified.

Electronic Pills Dispenser

A couple years ago, some students of the Technical University of Cluj-Napoca, Romania, did research towards an electronic pill dispense system that could replace the classical weekly pill box, see for example figure 1. Their idea was realized by making a round tube, called the package, containing 7 circular containers, which logically are one for each day of the week. These containers were divided in 5 part, where one compartment wasn't used in order to avoid losing the pills from the container. The remaining four compartments are used to place pills in for four times during that day; morning, noon, evening and bedtime for example, but that is just programmable to the needs and times of the user.

Last few years there are more projects and product developments ongoing that work on smart medicine dispenser systems, similar to the system we want to create. For instance we encountered a product/project on Kickstarter, Lumma automated medication sorter and dispenser .

Shortcomings of the state-of-the-art

There are a lot of shortcomings in the above mentioned systems compared to the desired device. The most important ones will be discussed in this paragraph. First of all the user actions, these are still needed in every state-of-the-art mentioned above. Whether it is sorting the pills out, which is needed in every system or setting timers manually on the device itself. However, this isn't always possible for elderly, or disabled people, so pre-programmed timers would be a solution to solve this problem. Next to the user actions, there is the need of checking the user by the caregiver for instance. Nowadays, the caregiver needs to go around to check whether the medication is taken or not, but with the implementation of internet connection, which makes the device smart, this problem can be solved and it will be possible for the caregiver to check the medication usage from a distance. However, the already existing systems don't support an internet connection. Lastly is the interaction with the doctor, which takes all the above points in consideration. Since the users feel more confident with such a system if a doctor is included in the process of the system. When the system is connected to the internet, this connection to a doctor is possible.

---

The distinguishment

As already mentioned there are a couple of already existing classical pillboxes and some evolved pillboxes (see state-of-the-art). However, they aren't yet implemented in the society since they aren't seen as valuable. As a group, we wanted to make a smart pillbox that could be implemented in the existing medical care. This is a very difficult task with a lot of aspects that come with it, for example: the user centered design, who are the users and what do they prefer according to such a system.

The system will be distinguished from existing systems using the following points:

• The usage of modules

The design of the pillbox (Final Design) consist of modules, which is a concept that isn't used in any of the state-of-the-art around this subject. This makes the system very easy to use and flexible, in special when the medication prescription changes, in the long run. Next to that the modules also make it easier for the user itself, since the elderly or whoever is using it, doesn’t have to sort out the pills by itself anymore. The medication is sorted out by the system itself during the preparation of the medication. The information needed for the system to sort out these pills are the input from doctor into the system.

• The input from doctors

Just as mentioned above, the doctors are able to simply type in the information for the medication needed. This will result in a pillbox that is being programmed from distance by the doctor, which counters the problem of misuse by the users itself. Next to that, there shouldn’t be any misunderstandings from when to take which medication, since the doctor programs it from its desk at the hospital.

• The system is smart

The system is connected to the internet, which makes it possible to let the doctor communicate with the pillbox from distance.

---

Research on user needs

In order to improve our design, we set out to gather user feedback. We decided to do this in the way of interview with a pharmacist and questionnaires with elderly. The main goal was to find out aspects that we hadn’t thought about and figuring out how to improve trust in this kind of a system.

Interview with a pharmacist

Summary of the interview with a pharmacist: File:Interview Pharmacist.pdf

The interview with the pharmacist turned out to offer us a lot of new insights into how our technology can be helpful as well as what problems it faces.

Firstly, we focused on what the interviewee perceives to be the current problems with prescriptions for the elderly and disabled. They first confirmed that one of the main problems is that it is hard for the patients to remember what every pill does, when to take it and they sometimes forget which medicine to take, especially if they use a high quantity of different medicines. He listed that the hardest part of his job is to know if the patient is using the medicine correctly, especially if the patient has misconceptions about what is correct. They also mentioned that about 2-3% of the hospitalizations are due to wrong medication. These are problems that we had also perceived to be a main issue, and are trying to solve with our technology.

Next, we discussed what potential he sees in our technology. He believed that this system would help people that often forget to take their medicine, but didn’t seem convinced that the system would guarantee that the medicine is taken the right way. He notification for when the medication isn’t taken was found important, as then the problem can be addressed before it has any big consequences. The interviewee brought up the point that some pills require to be in their packaging, so that they do not go bad. Removing pills from packaging has negative influences on the expiration date, and there are for example some pills that have to be consumed within 8 hours of taking them out of the packaging. We had not considered this aspect in our design but we will try to take it into account in further development.

In regards to the refilling of the containers, the interviewee believes it would increase the pharmacy workers’ workload, as they’d have to take the pills out of the strips first to be able to fill the containers. He also thought that a notification about needed refills is necessary, because the patients can’t perceive how many they have left.

Additionally, the fact that there are some medicine that should only be taken when necessary was brought up. With these pills, it would not be possible to add a timer to when the pill needs to be taken, which might complicate our system. To address this, we want to implement a button that the patient can use to dispense these “if necessary”-pills that is also linked to their daily limits. Some benefits of our system compared to the medicine roll were that you can add a module that is only needed for a few days and that these “if necessary”-pills can be implemented.

Overall, this interview offered us a lot of insight into issues we have to address, such as the packaging concerns and “if necessary”-pills.

Questionnaire at elderly home:

The questionnaire prepared for the visit at the elderly home: File:Questionnaire Dutch.pdf

To make a decent innovation it is necessary to have insight in the relevant USE-aspects. To gather information of what the users actually desire in such an innovation can be done in different ways. Our choice was to conduct a questionnaire towards the users of the technology. First of all the target audience, which in our case are the medication users, need to be found for the research. This resulted in a visit at an elderly home, The Annenborch in Rosmalen, which is a perfect place where a lot of elderly live. We saw elderly people as our main users since the older a person gets, the more medication is needed, because of the deterioration of the human body. After a visit at the elderly home and some mail correspondence, we got our permission to do the questionnaire, and soon after, we were able to visit the elderly home. However, after some chats with the residents, which are the elderly, we came to a quick conclusion; The elderly weren’t able to write anymore and their medication was being taken care of by the caregivers at the elderly home.

As we didn't want to go home without any results, we resorted to talking with them during their coffee break. Although this didn't give us the desired result, we asked them how they thought about the concept of a machine sorting and reminding them to take their medication in a non-formal interview procedure. Some said they were independent enough and had a good enough memory to take the medication by themselves, while others said that the innovation would be an addition to their daily routine if they lived on their own. When asked more in-depth about the problem of failing memory, it was recognizable that the memory and their health, which could be a result of the memory, decreased as they age. So just such an invention to remind them to take their medication isn't good enough since help is needed with everything during their day and not just with medication. Nevertheless, the pill dispenser could extend their independency for sure and will be an addition to their daily routine.

The talk with the elderly was very informative, but the information about the usefulness of the innovation couldn't be tested with the elderlies. We went to the receptionist and asked whether we were able to meet the caregivers, which the elderly told us about, to ask them some things about their medication dispensing and sorting system. In no time, we were helped by a caregiver that was able to answer our questions. It turned out that they indeed take care of the medication of the elderly, but that it is done just on stated times during the day; for example: after breakfast and after dinner. The result about how they dispensed the medication wasn't that special since all the medication is brought to them in Baxter rolls coming from the pharmacy, so they do not sort out any of the medication, this will be done at the pharmacy.

• Conclusion of the questionnaire/research

This means that the questionnaire isn't fulfilled, so no conclusion can be drawn from that perspective. However, resulting from the chat with the elderly, it can be seen that they, as expected, do need help with their reminding of medication as they age. So the implementation of the smart pill dispenser would be an addition to their home, and will, in turn, extend their independency. The acting around the medication is done by the caregiver on set times during the day, the medication to be spread is brought to them by the pharmacist.

---

Software Requirement

Based on some of the findings from the user research requirements for the software were compiled. Below they are listed per user type.

Patients

• Should be able to view whether they have any doses to be taken
• Should be able to dispense a dose

Doctors

• Should be able to log in to MySMDS
• Should be able to view a list of available medicines
• Should be able to view their patients
• Should be able to view their patients' doses
• Should be able to add a dose for one of their patients
• Should be able to edit a dose for one of their patients
• Should be able to remove a dose for one of their patients
• Should be able to view the dose history for one of their patients

Pharmacists

• Should be able to log in to MySMDS
• Should be able to view a list of available medicines
• Should be able to add a new medicine
• Should be able to edit a medicine
• Should be able to remove a medicine
• Should be able to view their customers
• Should be able to view whether a refill of a certain medicine is due for one of their customers

Caretakers

• Should be able to log in to MySMDS
• Should be able to view a list of their patients
• Should be able to view the dose history for one of their patients

---

Software Design

The software of the Smart Medicine Dispenser System (SMDS) is comprised of three parts:

Figure 5: Schematic layout of the application architecture

Figure 6: Database ERD

• The cloud service which contains the data for all users and also is the main hub for all communication between users and devices
• The web portal, which allows professionals such as doctors and pharmacists to change doses or get alerts when refills are due respectively
• The device client, which is the software that runs on the medicine dispenser. Besides releasing the doses, it also provides a graphical user interface for the patients where they can see what doses are due

The architecture of the entire system is schematically presented in figure 5, and the layout of the database is described with the entity relation diagram in figure 6.

Cloud Service

The cloud service is a server program, written in the Go programming language. For its data storage it uses a relational SQL database (PostgreSQL in this case). Clients can communicate with this service using a RESTful JSON API, optionally in combination with a WebSockets based API called the "dispatcher" which provides real-time updates on data to the client. Once a client user is authenticated, it has to send a JSON Web Token (JWT) with each subsequent request which the service uses to authenticate the user. Based on the role of the client, certain actions will be available or unavailable.

Web Portal

The web portal (MySMDS) is an application which can be used through a web browser, and is meant for professionals to monitor and change the medication usage of their patients. It communicates with the cloud service through HTTP and WebSockets. The application is written in TypeScript, using the Angular framework, amongst several other libraries.

Device Client

The device client is the software that is running on the device (Raspberry Pi in this case). It has its own internal database which contains a relevant subset of the database in the cloud. It is written in Python , and uses the Kivy NUI framework to provide a graphical user interface. It communicates with the cloud service through the HTTP REST API, and for a set time interval, it pulls the relevant data from the service and updates its own local relation SQL database (MySQL) if any changes have occurred. When a dose has been taken, it will also communicate this back to the cloud service.

Code Repositories

All code written for the project is openly available on GitHub, and can be found under the following URLS:

• Cloud service + web portal: https://github.com/DirkWillem/0LAUK0-project
• Device Client: https://github.com/DirkWillem/0LAUK0-Project-DeviceClient

Hosted version

A hosted version of the application is available on the following URL: https://smartmedicine.herokuapp.com

In order to log in, test users for the most important user types have been created with the following credentials:

Doctor
    Username: doctor
    Password: doctor.password

---

Software features

For the proof of concept several features have been implemented. These features can also be found on the hosted version. Below, the most important features will be outlined.

Doses

In the web application, the doctor can add, edit or remove doses. Each dose has a title (like "morning medication"), and a description, in which the doctor can write any required additional information that should be displayed on the screen when the dose is ready to dispense. For each dose, the medications that must be dispensed and the amount of medications that must be dispensed for that dose can be set. (The amount of medications that must be dispensed is stored in the DoseMedications intersection table, which can be seen in the ERD). Finally, each dose has a "dispense after" and a "dispense before" field, which dictate when the dose can be dispensed. In the case that a dose should be dispensed overnight, the "dispense after" field can be a later timestamp than the "dispense before" field and SMDS will understand that this dose should be dispensed overnight.

History

When a dose is dispensed, a DoseHistory record is created, which keeps track of when a certain dose was dispensed. In both the device client and the web portal, users and doctors respectively can see whether and when a dose was dispensed. In the web portal, a doctor can also see whether and how many PRN medications have been dispensed per day. In the list of history entries, the web portal will show how many of the doses have been dispensed. As SMDS keeps track of when a dose was created, the history won't display doses as not dispensed in days where the dose did not exist yet.

Because of implementation of the data, and constraints because of the database query language, history is only visible for days where one or more doses have been dispensed. This could be circumvented by choosing a different user interface layout in the web portal, or sacrificing some performance in the cloud service by calculating all dates.

PRN medications

PRN medications are a feature that enables doctors to prescribe medications that can be taken on a as-needed basis (known as PRN or "Pro Re Nata" medications). To prevent the patient from taking too many of these medications the doctor can choose to set certain constraints to these medications. The constraints that are implemented are a maximum number of times the medication can be dispensed per day, and a minimum interval between taking the medicine. On the device client, the user can see these constraints in the list, and also what the current status of the PRN medication is. This means that when there is a maximum daily intake, the user can see how many he has taken today, and when there is a minimum interval, the user can see what the last time he took the medication was. If a medication cannot be currently dispensed because of one of the constraints not being met, the dispenser will display what the earliest time is the medication can be dispensed again. When determining whether a medication can be dispensed, SMDS will take all set constraints into account and only dispense the medication when all of the set constraints are met. This means that if, for example, a medication can be taken twice per day, and there is a minimum interval of 4 hours, if the medication was taken on 22:00, the next time the medication can be dispensed at 02:00 the following day (as that is the first time all constraints are met again).

Live data updates

SMDS includes two forms of live data updates, one in the web portal and one in the device client.

In the web portal, WebSockets are used on the client side to receive live data updates from the cloud service. This works through a feature in the cloud service called the Dispatcher, a pubsub (publish/subscribe) based API over WebSockets which enables any client to subscribe to messages from the service. When any mutation to the database is made in the service, a message is sent to all subscribers on the relevant subject so they know to update their local data.

The device client uses a less sophisticated version of live updates, as it fetches the latest data from the service on a set time interval. It then determines which entities in its local database are missing, outdated or not existing in the cloud service anymore, and updates its local database, as it assumes the data on the service is always the right data. Though it is not very sophisticated, for many end users this will probably be enough as a few seconds or minutes delay on a data update is not a lot of time compared to the time-scale the user interaction happens.

Screenshots of the features

Below, screenshots of some of the features described above are shown, both in the web portal and in the device client.

• Screenshots of the some features in SMDS
• 

  Doses

• 

  Dose history

• 

  PRN medications

Demonstrational video

A video describing some of the features of SMDS with the actual used hardware be found on YouTube here.

---

The design process

Figure 7: CAD sketch of first module design

Figure 8: CAD sketch of pill dispense mechanism

Figure 9: Axle can be removed to change the gear

This part of the wiki page describes our design progress per week, it contains the main struggles and important choices.

Week 1

The first week was a startup week. After the subject was chosen, we started with discussing about the design of the dispenser and we determined the requirements of the design. While discussing about the design, it appeared that the dispense mechanism will be the crucial and most complicated part of the design. This mechanism has to dispense one pill at a time, without getting stuck and damaging the pill, and because there is a large variety in shapes and sizes of pills, this will be a complicated problem. Various mechanisms were discussed and we decided that the best option was to have a wheel/disk with a gap customized for one type of medicine. This wheel will be integrated in a module, so for every similar type of pill there will be a module with a wheel/disk, for instance one for round (paracetamol shape) pills, one for capsule shapes, etc. We also discussed how we will build the prototype, what materials, electronics, etc. The prototype will contain an interactive display, we will use a Raspberry Pi with touchscreen for this function. For the dispense mechanism we need a servo or stepper motor and an Arduino for controlling them. The frame of the prototype will probably consist of wood, however it will be necessary to 3D print most of the design specific parts, like the wheel/disk with gap.

Week 2

In the second week most time was spent researching the state-of-the-art, literature, etc. and a big part of the software was designed.

Week 3

In the third week the work on the design was resumed. A first CAD sketch of a potential module was made (figure 7), this design would be for round (paracetamol shape) pills. The pills are stacked in the ‘tubes’, disk 1 will turn until a pill falls through the hole in disk 2. The advantage of this design is that it is almost impossible to accidently dispense two pills at once (instead of one) and pills won’t get stuck. However a major disadvantage of this system is that the pills have to be loaded one by one, since they must be stacked nicely in the tubes. An alternative is to have some kind of funnel and a wheel/disk with gap beneath the funnel. This would take away the disadvantage of stacking the pills in tubes, since the pills can just be dropped in the funnel. However this will increase the chance that two pills get stuck in the narrow part of the funnel, therefore we have to find out what the best shape is to prevent this.

Since the system will have a separate module for every type of medicine, every module must have a motor/servo to dispense the pills, then there are two options where to place the servo:

In the module (connect it to the system by simply plugging in the electronic pins)

• Advantage: it is easy to connect a module to the system.
• Disadvantage: the modules will be quite big and more fragile.

On the system (connect the modules by a gear)

• Advantage: smaller and less fragile modules.
• Disadvantage: more difficult to connect modules to the system.

Carnaval holiday

Because of the huge variety in pills it is hard to make one module that suites all. To make the product as efficient as possible we want to make one pill general module that is easy adaptable for different sizes of pills. To accomplish this, the machanism that dispenses the pills can easily be interchanged, the axle can be removed and the gear corresponding to the pills can be placed inside the module. This way the module can be used for all different sizes of pills, only the gear has to be designed to fit the specific pill.

Some things that have to be taken into account are to make sure that the pills can't fall out when the module isn't placed inside the system, this can be done with a mechanical lock/slider that opens when the module is placed inside the system. Also the prevent the pills from getting stuck, a stirring mechanism can be attached to the same axle als the gear. And to prevent elerly from opening the module it is possible to add a lock to the lid of the module.

Week 4

This week we mainly discussed about a number of details concerning the design. For this moment we will assume the motor/servo will be placed on the system, this is also implemented in the CAD sketches. This makes that the module needs a place where the axle of the wheel in the module can be connected to the servo. This connection will be made by a pyramid shape extension of the axle (figure 8), by using this pyramid shape the module can be easily connected to the system. A small, but still important aspect, is that this axle will not protrude. Therefore there will be gap around the axle, where it can be connected to the system. This gap can also be sealed by the pharmacy to make sure that the module is not used before it is placed in the system. The fact that the module has no protruding parts, makes the module more robust, less vulnerable, and safer and easier to transport.

Another point of discussion was what part of the module will be modular and therefore specific for every type of pill, the whole module or only the wheel in the module. The main advantage of making the whole module specific for one type of pill, is that also the funnel, in particular the end of the funnel, can be adapted to the pill size. However, since there is a huge variation in shapes and sizes of pills, this will probably be a costly solution. The other option is to make the wheel in the module replaceable, such that the wheel can be replaced by taking out the axle. In this case only the wheel has to be specific for one type of pill and the pharmacy can just replace the wheel if there is a change in someone’s medication discipline.

As mentioned earlier the dispensing part will be the most critical part of the system. Therefore we have to be able to test if our dispensing mechanism will work. Since there is a huge variation in shapes and sizes of pills, and our dispensing mechanism is adapted to one type of pill, we won’t be able to prove that the mechanism will work for every type. However we want to test the mechanism for some basic, common shapes, for instance the ‘normal’ disk shape (paracetamol shape) and capsule (shape). We are working on a way to simulate the dispensing process and we hope this will work out, since then we can easily adapt the 3D model if necessary, and test with various shapes. The other option would be to 3D print some wheels for various pill types and test it empirically. If it appears that the pills get stuck in the funnel, we may have to adapt the shape of the funnel or add some kind of stirrer that moves if wheel is rotated, since we don’t want to add a separate motor for this function.

Since one of our goals is to design a safe and reliable medicine dispenser, the system must contain some features to check if it is working correctly, for instance to check if the right amount of medicines is dispensed. Probably the best way to check this is by using a light sensor. This sensor can be placed just beneath a module, so that it detects when a pill falls out. This solution is easy to implement in the system and not very expensive.

To make sure that the pills will not get stuck in the funnel, a simple simulation was made to check if they got stuck. In the first simulation the pills, which were in this case paracetamol, couldn't even get through the funnel even when only one was used, so the funnel had to be made bigger. In the second simulation the pills couldn't fit trough the funnel because they blocked eachother. The solution for this problem is to stir the medicine or let the funnel vibrate so they will come lose.

The main system must also know which pills are at what location and thus know what pills are inside a module. For this moment we think a RFID (Radio-frequency identification)-tag is the best solution for this, mainly because it is already used for similar applications.

Main station/system

Before this week we mainly focused on the module design, this week we started designing the rest of the system where all the electronics are and where the modules are placed in. There are some things we have to take into account when designing this system:

• There should be place for several modules
• Between the modules, there should be place for the motors where the module can be connected to
• The system must be as compact as possible
• The pills must be collected in one tray (that can be taken out)
• Preferably a system that can easily be expanded if more modules are needed, for instance when more persons in the use the same system.

The first design (figure 10) met the most important requirements, however it is quite big. The main disadvantage of placing all the module at the same level is that there is a lot of room lost, since the ‘slide’ where the pills fall onto has to be quite steep. Therefore we chose to adapt this in the next design (figure 11 t/m 15).

In the second design there are two levels with modules. The pills of three modules in a row fall into the same shaft and all the shafts come together, so the pills will be dropped in one tray. We chose to place some kind of stairs in the system (figure 14), since this is the most simple solution to prevent pills falling such large distance. The advantage of this design is mainly the more efficient use of space.

• Some pictures of the main station design
• 

  Figure 10: First design for the system (lxwxh: 530x300x250)

• 

  Figure 11: Assembly improved design (lxwxh: 310x300x550)

• 

  Figure 12: Exploded view

• 

  Figure 13: Shaft for the pills

• 

  Figure 14: Zigzag shaft from the upper part to the bottom part

• 

  Figure 15: See through corridors

Week 5

There had to come a solution for the problem of the medication becoming stuck in the beginning of the funnel hole. This week we found 3 solutions for this problem:

• A vibrating motor disk

This is a small motor(see picture...) that shakes the medication inside a module. This will result in the medication trying to fall through the funnel hole again, if this doesn't work then the process repeats itself until it works. The working principle is very similar to a sieve. However, this motors can be added anywhere on the sides of the module, this should be done on tactical places to make sure the vibrations are strong enough to re-mix the medication.

• Rotating internal funnel with bumps on the sides
  

  Figure 16: Wheel for the new dispensing mechanism
  

  Figure 17: Inside of the module, with the new dispensing mechanism

With this rotating funnel it is possible to make a kind of vortex which is very likely to make the stream of medication come through the funnel fairly easy. This can also be seen at the sink hole, if there is too much water there will arise a vortex to drain the water the fastest. This idea can be realized by placing a gear to the funnel so it is able to turn around.

• Paintball hopper

Since the paintball guns aswell have a funnel in the top of their gun for their ammo, which is called the paintball hopper, there is also a problem of balls getting stuck inside the funnel hole. However, they made a plastic part to place just above the funnel hole to deflect the force that is put on top of the medication above the funnel hole. This way it is easier for items to fall into the funnel hole, the same principle would hold for the rotating funnel, but in that case the centre above the funnel will hold medication aswell.

Week 6

After the interview with the pharmacist we got some hints about existing systems that dispense pills. We decided to look further into these systems, since we were struggling finding a good solution to prevent pills getting stuck in the funnel. To produce the existing medicine rolls (see State-of-the-art) it is also necessary to dispense pills one by one, so there are already various mechanisms that reliably dispense pills. The Yuyama PROUD machines use a mechanism that could improve our concept and make our system more reliable. It is stated that the PROUD machines have a counting accuracy of 99.999%. Therefore it is beneficial to use a variant of this proven concept for dispensing, since we won’t be able to test our previous idea extensively to provide the same accuracy measures in a few weeks. Therefore we will use their mechanism with some adaptions, so it can be used in our modules. In our new dispensing mechanism there will again be a wheel with holes (figure 16) (like in the first idea), however the wheel will now be placed horizontally and there will be one hole beneath it, so a pill will fall through if the hole from the wheel is above this hole. Instead of the funnel there will just be a rectangular shaped box above the wheel (figure 17). In order to prevent pills remain lying on the middle of the wheel, it will have small slopes on top of it. We also placed a small lid above the hole so only one pill can fall through at a time.

Since the wheel is now placed horizontally in the module, instead of vertically, also the connection to the main system will be different. There are a number of options:

• Add some gears in the module so the same connection to the main system can be used
• Adapt the main system so the gear can be connected on the bottom of the module
• Place the servo in the module, even though we earlier decided not to do so

We decided to place the servo in the module for our prototype, since otherwise it will probably become quite complicated if we have to use gears. However for the ‘real’ system it is possible to use these gears and keep using the same connection to the main system.

---

Planning

This part describes a general planning of our project, including important milestones.

Week 2

Literature study (state-of-the-art)

Define objectives + deliverables

Week 3 + Carnaval holiday

Determination of all functions of the robot (pill dispenser)

Designing the pill dispenser paper so we know what to order

Determine what functions the prototype will have and how we will build it (materials, electronics, etc.)

Literature study (continued)

Start on software design

Week 4

CAD sketch (based on sketch on paper)

Gathering + ordering parts needed for the dispenser prototype

Week 5

Finish software, build prototype

Week 6

Finish prototype

Week 7

Test prototype

Week 8

Final presentation

Finish wiki

Every week

Update wiki with project and design progress, including description of the state-of-the-art and USE aspects.

---

Sources

Figure 1: http://www.winkelmetzorg.nl/a-15208551/medicijnendoos-of-pillendoos-met-alarm-hulpmiddelen-met-alarm/pillendoos-met-braille-medicijnendoos-met-braille-medidaily-pillen-bewaar-opbergdoos/

Figure 2: http://www.efarma.nl/pages/sectieinfo.asp?SUBSC=16010

Figure 3: http://www.medminder.com/

Figure 4: http://www.epill.com/dispenser.html