PRE2016 3 Groep9
Medicine/pill dispenser system
- Group 9
| 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 medicines, in the right dose, at the right time during the day. Missing a dose or taking more medicines than necessary could lead to dangerous situations, but also taking medicines 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 (‘Vervolgonderzoek Medicatieveiligheid’). A system that would remind the user to take his medicines and dispenses the right medicines at the moment they have to be taken, would prevent a big part of these situations. The electronic devices and internet connection in your house provide extra possibilities for such a system. Therefore we are going to design a smart system that dispenses medicines. 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, literature 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
3. USE Aspects
3.1. 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.
3.1.1 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(Find source).
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.
3.1.2 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.
3.1.3 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 good so that patients can recognize when it is malfunction. 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.
3.1.4 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 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 the 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.
3.1.5. 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.
3.1.6. 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.
3.2. 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.
3.2.1. 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.
3.2.2. Elderly can live at home longer and independent
Many points related to this aspect were already discussed in part 3.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 3.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 3.1.6 are still important to note for these people.
3.2.3. 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 not necessary. For some, it might create more issues because of lack of freedom mentioned in 3.1.5. or they might not afford the technology. Doctors might become more likely to prescripe 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.
3.2.4. 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.
3.3. 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.
3.3.1. 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 possible universities or research companies.
3.3.2. 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.
3.3.3. Responsibility
The issue of responsibility was discussed in 3.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.
3.3.4. 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.
3.3.6. 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
There are various non electronic ways to assist people in taking the right medicines at the right moment. For instance the box system like in figure 1
, it consist of seven boxes, one for each day of the week, and every box has four compartments corresponding to four times of the day (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. Another existing system is the medication roll (figure 2)
. This roll consists of plastic pouches filled with the medicines for a moment on the day (which moment is indicated on the pouches). The pharmacy can provide these rolls filled with all medicines.
A major disadvantage of both systems is that the user still can forget to take his medicines, since there is no alarm, it also has no warning system if a dosage is missed, and the user can accidently take the medicines from the wrong box or pouch. Another disadvantages of the medication roll is that if there is a change in the medication discipline this cannot be changed immediately, since the medicines for the coming week(s) are already packed in plastic. Next to these systems there are also various electronic medicine dispenser systems on the market, most of them are quite basic, however there are also some more advanced ones.
Electronic medicine boxes
One of the more basic systems is the electronic medicine box, like the MedMinder (figure 3)
. . The system has 28 trays each 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.
E-Pill
E-pill (figure 4) is a round device where you load in the medication discipline for the coming days, like in the medicine box so each box contains the medicines for one moment in time. The date and time of the alarm can be set. If the user has to take the medicines, the disk will rotate to the right box, an alarm will sound and the medicines can be taken out. E-pill has some variants, but they all work basically the same.
Philips Lifeline
The device of Philips works somewhat the same as the e-pill 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. (Philips Lifeline)
Evondos E300
The Evondos E300 is a compact system where you load in a medication roll with the right doses of the medicines, delivered by your pharmacy. It gives an alarm if the user has to take his or her medicines 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 this can be notified. (Evondos)
Last few years there are more projects and product developments ongoing that work on smart medicine dispenser systems, like the one we want to create. For instance we encountered a product/project on Kickstarter, Lumma automated medication sorter and dispenser (Kickstarter, Lumma).
Electronic Pills Dispenser
A couple years ago, some students of the Technical University of Cluj-Napoca, Romania, did research towards a 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.
MED-E-LERT
The MED-E-LERT (figure 4)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.
---
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.
Software Design
The software of the Smart Medicine Dispenser System (SMDS) is comprised of three parts:
- 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[1]. 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) [2] 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[3], using the Angular framework[4], 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 [5], and uses the Kivy NUI framework [6] 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 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 Requirement
Below, the requirements for the software per user type will be listed.
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
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 (%refer to the CAD-sketches) consist of modules, which is a concept that isn't used in any of the state-of-the-art. 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, don't have to sort out the pills by itself anymore, since the pills are in different modules and sorted by the system when the pills need to be dispensed.
- The input from doctors
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. This way there can't be any misunderstanding 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.
The design process/progress
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. However 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.
References
- Vervolgonderzoek Medicatieveiligheid, opgesteld voor het Ministerie van VWS. January 2017
- Philips Lifeline. Lifeline Philips. Retrieved from https://www.lifeline.philips.com/health-solutions/health-mdp.html, 22 February 2017
- Evondos. Evondos e300 automatic medicine dispenser. Retrieved from http://evondos.com/service/evondos-e300-automatic-medicine-dispenser/, 22 February 2017
- Kickstarter. Lumma, automated medication sorter and dispenser. Retrieved from https://www.kickstarter.com/projects/402921688/lumma-automated-medication-sorter-and-dispenser, 23 February 2017
- ↑ The Go Programming language, https://www.golang.org
- ↑ JSON Web Tokens, https://jwt.io
- ↑ TypeScript - JavaScript that scales, https://www.typescriptlang.org
- ↑ Angular, https://angular.io
- ↑ Python, https://www.python.org
- ↑ Kivy: Cross-Platform Python Framework for NUI Development, https://kivy.org/
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: https://www.efarma.nl/pages/sectieinfo.asp?SUBSC=16010
- Figure 3: https://www.medminder.com/
- Figure 4: http://www.epill.com/dispenser.html