PRE2023 3 Group7

Pill dispensing robot

Team and interests

Quinten Liu, 1842471, q.m.liu@student.tue.nl

Fenna Sigmond, 1696947, f.e.sigmond@student.tue.nl

Thijs Frints, 1441523, t.g.g.frints@student.tue.nl

Daniel Joaquim Ho, 1534254, d.joaquim.ho@student.tue.nl

Sven de Gruyter, 1857657, s.d.gruyter@student.tue.nl

Sjoerd van de Goor, 1557815, s.v.d.goor@student.tue.nl

Interests:

• Medical Imaging
• Physical product
• AI
• Tangible / functional product
• Danger detection or prevention
• Healthcare or elderly care

Introduction

- General introduction

- Mention why we are just focussing on software

Target Audience

We really need a general introduction and problem statement of sorts before this part

Our proposed pill dispensing system should offer help for individuals struggling with the complexities of long-term medication management, which is a wide group. The limitations of our product and the needs of different subsections within this group helps us find a target audience that encompasses a wide range but still limited set of individuals that our product will be able to help.

Problems and potential solutions

Poor medical adherence is a serious and widespread problem. By looking through the facets of patients’ and caregivers’ problems, we can find the limitations of our system and propose how our system might be able to solve them. From this we can find flaws or difficulties that our system could face.

One of the most common problem patients face is forgetting to take their medication at their prescribed times. Our product will be able to notify users about their medications when they have to take it, thus helping them in this regard. In cases that the user ignores or misses these notifications our system does not have the means to make them do it anyway. Similarly, if the patient has a lack of motivation, as patients with depression or anxiety can cause them to dismiss their medication against their interest, then our product can’t force them.

To partially solve this, our product could be able to detect whether or not the patient has actually taken the pills from the dispenser, to notify them again in case they missed the last notification or to notify a caretaker about the situation, but this still cannot confirm the patient’s cooperation as a very forgetful patient could take the medication, put it somewhere else and forget it again. Additionally, an uncooperative patient could purposefully take the medications only to throw them away as to look like they took it. The features and systems needed to circumvent this issue are currently still conceptually too complex to incentivize delving into them. This is thus our product’s main limitation.

The complexity of medication regimens also plays a role in the medical adherence of a patient. If a patient has trouble with a complicated schedule with multiple medications taken at different times of the day, in different conditions and in different ways, etc., the patient will be more prone to human error. This issue is exacerbated in the case of a caregiver taking care of multiple patients with these kinds of medication regimens. Our product solves this by storing this schedule so that neither the patient nor the caretaker need to rigorously remember it. This ability to store complex schedules however, will be limited, as there will always be medication regimens too specialized and complicated to manage for a scheduler.

Another issue regarding medical adherence is the lack of information about the medication, consequences of not taking them and side effects. A patient may not fully understand why they need to take their medications or the potential consequences of not adhering to their prescribed regimen, and some medications can cause (unpleasant) side effects, which may lead patients to skip their medication without consulting their caregiver or healthcare provider. This uneducated group is a subsection of the previously mentioned group of uncooperative patients. Our product aims to solve this issue by being able to inform the user, with the user being able to ask questions about the medicine they are taking and the system looking up answers from a database.

Found target audience

Included target audience

Our product will aim to help people who are experiencing challenges regarding medication adherence, either due to forgetfulness, human error or a tendency to de-prioritize their medication regimen, or due to a lack of understanding or fear of adverse reactions. The product should also help caretakers and healthcare providers involved in the medication management process via notifications and updates about the patients medical adherence.

Excluded target groups

It’s important to keep in mind that our product is not targeted towards people who willingly choose not to adhere to their prescribed medication regimen despite understanding its importance. These patients will not benefit from the reminders or information provided by our system if they are intentionally uncooperative. Additionally, if a patient has a highly specialized and complex medication regimen, where our system cannot adequately address the unique conditions and complexity, the product may not be suitable for them.

Storyboard

https://generated.photos/human-generator/65ecb387524d5d000b22b839

Meet Jan, an 86 year old male, living in a nursery home on the outskirts of Eindhoven. A few years ago he was diagnosed with Alzheimer and therefore forgets to take his medication a few times a week. Currently the nursing home he lives in is understaffed and the nurses cannot visit him multiple times a day to check if he takes all his medication. To give an inside in this week day by day, a description of this week is given below. Currently he takes the following medication:

-         Lisinopril, which he takes after dinner, so ones a day. This is to treat high blood pressure

-         Omeprazole, 3 times a day. To treat excess stomach acid.

-         Metformin, 2 times a day and needs to be taken with a glass of water. So in the morning and evening. This medication is used for type 2 diabetes.

Looking at the amount of medication he takes, it can be concluded that he needs to take a total of six pills, on three different timestamps and with 2 different ways. To facilitate a way for Jan to take all his medication on time and in the correct way, the nursing home decided to put a medicine dispensing robot with an integrated AI information system into his home. 

Monday

Jan wakes up to his alarm clock at 7:30, and gets out of his bed 10 minutes later. He heads to the kitchen in his home, to get breakfast. Here his medicine dispensing robot is standing on the counter, to whom he got more familiar during the last few weeks. After eating his breakfast he hears a beep coming from the robot, which is there to remind him that he needs to take his first medication of the day. He presses the button and get the two pills dispensed, with a notification that he needs to take the metformin together with a glass of water.

Afterwards he starts reading the newspaper and watches some television in his living room. When he suddenly hears the robot starting to beep in the kitchen. First he ignores it, but after multiple reminders Jan goes into the kitchen to get his dose of medication.

During the afternoon the nurse comes into his home to check in on him. She also checks the robot to see if Jan took all his medication. They have a small chitchat, before she leaves Jan’s home. Just before dinner Jan decides to lay down in living room chair and falls partly in sleep. One and a half hour later he awakes by a beeping sound, it is the medication robot. He slowly walks to the robot to see a notification on it that he is already half an hour late on his schedule. So he presses the button to get his medication out, which also shows him a message that he needs to take the Lisinopril after he eats his supper. Being a bit confused, since he took a nap just before, Jan did not eat supper yet. He therefore presses the button of the robot again to get more information about eating before taking the pill. The robot gives him more information and Jan decides to start eating supper and leaves the medication laying in the robot. Half an hour later the robot starts to beep, since the medication is still laying there, Jan quickly takes it and starts to prepare for bed.

Tuesday

The routine for Tuesday follows a similar pattern to Monday. Jan wakes up, takes his morning medication, and enjoys breakfast. The robot reminds him to take his midday dose of Omeprazole, ensuring his stomach acid is regulated throughout the day.

Just after the lunch a nurse comes into his apartment to refill the machine for the first time. Jan looks a bit strange at the nurse since he has not seen this happening earlier, which is noted by the nurse. She ensures him that she is carefully adding his medication into the robot, so he has enough medication for the following 4 weeks.

During the afternoon Jan goes out for a walk and do get some groceries at his local market. Before going home, he decides to sit down near the market and watches some people walking by. While walking home he remembers that he needs to eat dinner before taking his evening medication. So he eats his meal when he got home and hears the robot beeping just a few minutes later.

Wednesday

Wednesday starts a bit different compared to the final two days for Jan. He forgot to turn on his alarm clock yesterday evening. So around 9:00 he gets woken by a beeping sound, the medication dispensing robot! But Jan is completely not aware that the sound he hears is from the robot, so he forgets his medication. At 11:15 a nurse comes into his room and hears the robot beeping, she askes Jan if he already took his medication. To which Jan answers that he does not remember. At that moment the nurse opens the app that functions together with the robot. Here she sees that the medication that needs to be taken in the morning is still in the robot. So she makes sure that it gets dispensed, and help Jan to take it. She also tells him that for this day his scheduled medication will be two hours later for the rest of the day. Which the robot already mentioned on the LED-screen and in the app.

Around 15:00 the robot starts beeping again, Jan’s afternoon medication! He takes it and afterwards heads to the common room in the nursery home. Here he talks with some of his fellow elderly people and plays some board games, before the shared dinner the nursery home serves every Wednesday. He then walks back to his apartment to get his final dose of medication out of the robot.

Thursday

Every Thursday the nursing home organizes an elderly gym session, in which Jan always participates. This sessions always starts at 8:30 and therefore starts before his normal medication schedule. Luckily for Jan the robot knows that Jan is going the exercise in the morning and therefore gives a beep an hour earlier then normal. So he can take his medication earlier and therefore he still gets it.

Just after lunch the robot beeps for the second time, and Jan knows he needs to take only one pill. Finally he rests a bit before the television before making some dinner for himself and waits for his final dose of medication of the day.

Friday

Friday starts just as Monday and Tuesday, Jan wakes up to his alarm and eats his breakfast before hearing the beep of the medicine dispensing robot. He takes out his medication after pressing the button on the robot.

After his lunch and the midday medication take-in moment, Jan gets a visit from his two grandchildren Tony and Lisa. They chitchat a bit and play a few boardgames, before Tony and Lisa prepare dinner for their grandfather. Which Jan really appreciates, around 19:00 the three hear a beep. Tony and Lisa both don’t know where it is coming from and ask their grandfather if he knows. To which Jan answers that that is his new assistant to remind him of taking his medication. Lisa goes and has a look at the robot and sees all features that it has and askes Jan if he finds it useful. After thinking for a bit Jan answers with that it was strange at the start, but that he now feels a lot better about using medication and that he takes it more strictly. He then walks to the machine and presses the button to get his medication out and shows Lisa that it even has an option to get more information about his medication.

Preliminary Functional Requirements

App

• AI integration to understand speech
• AI integration to process natural language inquiries about medicine in the specific context of the patient
• AI integration to process natural language outputs to spoken language
• Software to memorize and on time inform about medicine intake
• Remember which medicine was taken
• Admin-client distinguishment in access to schedule

State of the Art

Available Products on the Market

DoseControl device by MedControl Systems.

When it comes to the state of the art of medicine dispensing, there are currently two types of solutions: passive and active. The passive solutions are the standard pill boxes that allow the patient to sort the medication into smaller compartments based on which day the medication needs to be taken. Active solutions are the autonomous solutions that dispense medication, notify the patient, and even notify the caregiver when medication should be taken. This project aims to implement an active medication solution.

The passive solution comes in a variety of options, usually being a plastic container with sub-compartments for the storage of medication. These are the more traditional pill boxes, where the user needs to sort the medication beforehand into the correct sub-compartments. This type of solution tends to only hold enough medication for a week, requiring the containers be refilled and medication sorted every week by the user, where human error could play a role. This solution does not include any form or reminders, rather a container of all the medication that should be taken at a specific time. This still requires the user to remember to take the medication.

Hero Smart Dispenser by Hero Health.

The alternative is an active device, of which there are three alternatives: DoseControl, the Hero Smart Dispenser, and Philips Spencer. The first device, DoseControl, is a radial pill box that can remind the user to take their medication. The medication still needs to be sorted into their respective compartments, and the time of medication intake set. However, once that is done, the device will rotate the medication compartments such that the next compartment is aligned with the dispensing hole. The device then rings like an alarm clock, and can send a notification via the app if it is set up on the user or care givers phones. This is already an improvement to the pill boxes, but still requires the periodic refilling and organizing of the medication into the compartments. This device also does not have a form of confirmation that the medication has been taken from the device. This is a relatively affordable device, currently available in the EU. Similar devices from other companies are also available.

The Hero Smart Dispenser is a device that has 10 compartments for medication, meaning that it can store up to 90 days worth of 10 different medications. This device is setup to play an alarm noise when it is time to take medication, and dispense the medication according to the prescription. The device is also connected to an app, and both the caregivers and patients can receive notifications when it is time to take medication. The Hero dispenser also has a button on it, which the patient has to press in order for the medication to be dispensed. This also allows for a second notification to the caretaker informing them that the patient has taken the medication from the machine. The app that comes with this device tracks data such as dosages taken, missed, and when medication was taken. This dispenser makes it quite easy for the users to refill the medication, and easy for the caregivers to remotely check on the adherence of the patient. This device is only available in the US, with similar products also being available in the US. This device is available on a subscription basis, directly from Hero.

The final active device is Spencer, which is made in collaboration between Phillips and Spencer Health solutions is a medical adherance device, which dispenses medication. Spencer is by far the most technologically advanced device, allowing for dispensing for on the go, video calls with a medical professional, and is made to be data driven. Spencer is compatible with different Bluetooth health monitoring systems, which can be displayed on the screen, or visible to care administrators. The device is also easily refillable, although it will come in a proprietary box designed for within the dispenser. This device also comes with an app, and the same functionalities on the device can be accessed via the app. The device does ask for how the patient is feeling during the day, such as when medication is being dispensed. This way it can also monitor the general wellbeing of the patient, and relay necessary information to a caregiver. This is a really positive feature, but may be annoying for the user. Spencer can be deployed to patients at no extra cost when a home care giver deems it necessary, and can be provided via the patients home care organisation. It is unclear if Spencer can be provided when it is not deemed necessary, or if it can be provided to everyone upon request.

This project aims to create an active solution, similar to that of the Hero dispenser, with an application such that notifications, dosages, intake, and medicinal information can be given via an AI. The aim is to have the device be prescribed to patients via hospitals for long-term medicine intake in order to aid the patient and informal care givers.

Medical Adherence

The problem we are trying to address with our product is a lack of medical adherence, predominantly because of forgetfulness. While it’s important to justify the design choices of the product, consulting existing literature and state-of-the-art products in this domain will accelerate the project's development by using existing knowledge.

Effectiveness

One very crucial question to ask is how effective this type of technology has been in addressing medication adherence. In fact, low-cost reminder devices like pillboxes, pill bottle toggles and cap timers do not improve adherence in nonadherent patients, as found in a 50.000 patient data review by Niteesh et al in 2017. Unfortunately, this is the technology most used by people and the easiest to find on the market at the moment. Meanwhile, electrical medical adherence products (MAPs) are not very popular among patients. a review of many peer-reviewed studies testing the effectiveness of electrical MAPs assessed whether MAPs improve adherence and identifies and describes common features of electrical MAP devices. The conclusion was made with the data of 37 qualifying studies with a sample size of 4326 patients. The conclusion is that MAPs have a definite ability to improve adherence by up to 49%. And more specifically, devices that were integrated into the care delivery system and that were designed to record dosing events were most associated with improved adherence.

MAPs also all had 5 common characteristics overall:  

• recording dosing events and storing a record of adherence
• audiovisual reminders to cue dosing
• digital displays
• real-time monitoring
• providing patients with adherence performance feedback

Thus it can be concluded that the development and use of MAPs is by all means very relevant as they greatly improve the medication adherence of patients in general, even though they are not commonly used, while low-cost common medication adherence devices seemingly do not improve this statistic at all. Integrated delivery systems and recording dosing events are features that improve adherence the most.

[I'm not done I'm still adding stuff]

Baxter Rolls

The Baxter roll, named after the pioneering company in its production, is one state-of-the-art solution for managing multi-medicine medication schedules in healthcare and private settings. Baxter rolls are comprised of an arrangement of connected transparent plastic pouches, each housing specific medications tailored to the patient's regimen. Printed on each pouch are details including the patient's personal information, medication types and dosages, and scheduled consumption times. Pharmacists, in collaboration with healthcare providers, carefully curate these rolls in accordance with prescriptions, typically spanning one to three weeks, thereby alleviating the burden of daily medication organization for patients.

The utilization of Baxter rolls has multiple advantages. By condensing medication doses into individual pouches, the clarity of medication intake is enhanced, simplifying the administration process and mitigating the risk of dosage errors. Moreover, research suggests a notable improvement in patient adherence to prescribed regimens. However, despite these merits, the Baxter roll is not without its inherent drawbacks.

Foremost among its limitations is the restriction to solid oral dosage forms, such as pills and capsules, excluding injectable or inhalation medications within the roll. Consequently, patients requiring a combination of dosage forms encounter only marginal improvement from Baxter roll usage in managing their medication regimens, due to necessary supplementary dispensing mechanisms. Furthermore, the rigidity of the Baxter roll renders it less adaptable to changes in medication prescriptions, posing logistical challenges and potential disruptions to treatment continuity. Privacy concerns also arise, as the patient's personal details emblazoned on each pouch may be susceptible to inadvertent exposure to third parties, compromising confidentiality and data security. Additionally, the slightly costlier nature of Baxter rolls compared to conventional medication packaging models presents a financial barrier, potentially limiting widespread adoption and accessibility.

In conclusion, while the Baxter roll enables improvements in medication administration, its efficacy is reduced by its limitations. Some of these challenges, including specific details on in what circumstances the medicine must be taken, can be addressed to improve patient trust and adherence.

Promising dispense prototypes

An important part of our design will be the dispense function. Research already lead to promising designs and prototypes that could be an inspiration in this project. For example the autonomous pill dispenser by Chawla. In this project some important requirements are stated and a design is made that showed how these requirements can be met. first the requirements and than the design concept will be given:

• The device should be able to isolate a single pill from a group, regardless of the size and shape of the pills.

• The device should be able to contain multiple types of pills in case the patient takes more than one medication.

To achieve a fulfillment of these requirements a devise with cones were used to isolate the pills and a rotating mechanism, in which a servo motor was used to ‘dispense’ the pill, where it could be obtained by the medicine taker. The results of the prototype are promising, and we could use the cone design to dispense the pills in our prototype, however it should be looked into if the pills can be obtained easily, also for people with motoric problems.

Furthermore, a smart pill dispenser presented by Casciaro et al, gives another example of a mechanism, that could be used in our project to dispense the medicines. In this design "a slot is divided in two sections, one containing electrical and mechanical components and one containing a flexible belt with teeth molded onto its internal and external surface. The internal teeth allow the belt to rotate around two pulleys, one of which is driven by the stepper motor. The larger external teeth allow to keep the pills. When the belt rotates, the pills move together with it, and when one of them arrives in the lower part of the belt, it falls off the tooth and simultaneously the servomotor opens the inferior lid and drop out the pill through a special opening located at the bottom of the dispenser, from which the patient can take it". This design seems to be flawless in dispensing the right medication and the right amount because of the teeth that only let 1 pill go through, but it should be further researched if pills cannot get stuck and if different types of pills can be put into this machine. Also, the systems seems to be more expensive and difficult to realize. Furthermore, in the paper some other possible requirements came forward such as a contact sensor to know whether the medication is taken or not.

AI in customer service

To enable a system to address customer questions, or in the context of the pill dispensing robot, patients' questions, research shows that having AI integrated into chatbots has a positive influence on customer service. Further research into the methods in which companies develop AI chatbots shows the importance of using personalization and intelligent routing for interactions with such systems. Furthermore, the author mentions the importance of suggestions, providing the user insight into which information they can retrieve, as well as personalization, such that the system improves its interactions with the user over time.

Notification ideas

A study about reminders for taking medication at fixed times vs at automatically time-shifted based on sensor data, showed that using the adaptive reminders the medication adherence (how fast people take the medication and user friendliness) is higher. However, this time-based approach is not always the best as “for example, a reminder is triggered when the user is eating, whereas the medication should be taken after meal”.

The pillbox system collects real-time sensor data from a smart home environment and analyzes the user's contextual information through a computational abstract argumentation-based activity classifier. Based on user's different contextual states, the smart pillbox will generate reminders at appropriate time and on appropriate devices. This is quite complex and probably not manageable in this project but the idea of the notifications being at certain times to improve the medication adherence might be useful in this project.

Goals of review:

• Find state of the art
• Find what was done; what worked, what did not work. Perhaps reach out to the members of groups of previous years to ask for further details
• Medical technology state
• Pill dispensing specifics
• Elderly technology interaction
• Privacy and ethics of the technology

Literature Review of already existing medicine dispensers

General Literature Review of comparisons, effectiveness, and ethics regarding MAPs

Literature Review Fenna

Stakeholders and their interests

Problem statement

The general problem we are trying to solve with our product, and we’ll have to analyse surrounds the subject of medical adherence, the ability for a patient to keep following their medicine regimen. The problem is that medicine adherence is hard to keep high for certain people, be it voluntarily, because they don’t want to, or involuntarily, for example when the patient is forgetful. To identify the full problem statement, the most important stakeholders and their interests in the pill dispensing robot are identified using literature and interviews.

There are many stakeholders that share an interest in our problem, of which a handful are relevant and important to our product. These groups of stakeholders can be divided into three categories: User, Society and Enterprise.

Users

The most important stakeholder to a medical self help device are the patients using it, as they are the ones taking medication. The patients are people that have trouble taking medication on time, or could use help in managing their medication schedule. A device like ours does not address the group of people who do not want to take their medication, only people who are forgetful or find managing their medication hard. The device can assist with medication adherence, which will be done by making a schedule for the medication, alert the patient when to take medication, instructions for taking their medication, and answering questions they might have.

Another group of users of the device is informal caregivers. These users will interact with the machine by setting the device up for the patients in their homes, inputting the medical prescriptions into the device, and refilling the medication. They can also use the device to monitor the medical adherence of the patient. This device aims to help the caregiver provide care for the patient when they are not physically present by automating the task of reminding the patient to take their medication throughout the day. The device can help a general practitioner get a better insight on the medical administration of a patient.

Society

When it comes to the societal aspect of the device, a major stakeholder are governing bodies. The government, specifically the EU parliament is responsible for legislation and regulations regarding medical assistance devices such as this one. National governing bodies would also decide what reimbursement policies there are for this device in the context of healthcare programs and health services, which doesn’t influence the implementation of the product but vastly changes the access and availability of it to the average consumer (Forsberg et al., 2000). They thus play a key role in deciding how these devices can be implemented and will contribute to society.

Enterprise

The companies that decide to produce such devices need to design the product such that the users are kept in mind. The hospitals and pharmacies that are partnered with these companies can provide the device to the user should a medical professional deem necessary, as well as provide the medication for within the device. Health insurance companies could also incorporate such a device into their insurance plans for people who need it.

Ethical Aspects

Having a robot replacing tasks a human would do comes with its concerns. Patients are still human, and need to be treated ethically. When it comes to a robot to take over tasks a care taker would do, it is important to not take away the human touch of care givers in healthcare and preserve human dignity. This is also to not seem like the care being given is being automated. This device should improve independence for the patient, such as assisting a dementia patient in self-management tasks, such as medication intake.

Shift of responsibility

Something to consider when conceptualizing a medication adherence device like ours is what effect it might have on not only the patient, but the caretakers too. Several ethical considerations arise regarding the responsibilities of caretakers. One of which revolves around the responsibilities that are taken away from caretakers due to the use of such products, as well as the new responsibilities that may be imposed on them.

Caregivers play a crucial role in the medication adherence management of patients. Especially in those with poly-medicated regimens and dementia patients. It’s currently important to train caregivers to understand the disease the patient has, as well as the importance of medication adherence in patients as to reinforce it to ensure optimal treatment and is thus recommended. (Segarra et al. 2022) This task can be very hard to perform consistently for some caregivers, especially if they deal with multiple patients. With the use of smart pill dispensers, some of the tedious work can be alleviated. They can automate medication dispensing and reminders, reducing the direct responsibility of caretakers to physically administer medications at specific times, especially helpful when they have to deal with complicated or frequent dosage. Though, this responsibility would not disappear. It would be shifted to the device, and possibly thus to either the programmers or company of said device.

In return, caretakers, or patients self-medicating, would need to bear new responsibilities related to the oversight and maintenance of the smart pill dispenser. Foremost, the caretaker still has to confirm the medication adherence of the patient by interpreting the data they receive from the device, like recognizing patterns in the periods of non-adherence and correlating it to a potential barrier causing it, communicating with the patient or a healthcare provider when needed. The caretaker also needs to maintain the device by refilling, programming the patient’s regimen into it and troubleshooting technical issues, which does ask for a different set of skills from the caretaker. Additionally, caretakers might become responsible for ensuring that sensitive health information is protected from unauthorized access or misuse in accordance with the wishes of the patient, as many devices have configurable privacy settings to consent on the sharing of health information with the device company.

So, with the introduction of a smart pill dispenser like ours, caretakers are relieved from the tedious task of memorizing or planning the medication regiment of one or more patients, and are instead tasked with maintaining the device and interpreting the medication adherence data. In general, caregivers given the option for a device like this will highly prefer to choose it (Forma et al., 2022), so the change of responsibility is generally seen as positive.

Responsible use of the guidance system

Our information guidance system is based on ChatGPT’s API, which is known to produce inaccurate information. On average, worryingly to some, ChatGPT produces 72-77% accurate clinical decisions. However, our guidance system will not be making clinical decisions for the user and should not be used in this way. Instead, our guidance system looks up and informs the user about existing clinical information and data when requested. Assessing the reliability of ChatGPT’s raw model, medical information had a reliability of 5.5 out of 6 on a Likert scale, as found by Johnson, D. et al. (2023). Seeing as our system will have the LLM looking up data from fed files, the accuracy might be higher, though this needs to be tested to know for sure.

The fact that the system is not always accurate is not hidden to the user and will be acknowledged. Thus, people who buy this product, like caregivers or forgetful people at home, will need to understand this and try to be more critical of answers given to them. These users bear the responsibility for how the guidance system is used and the decisions made based on the output. Furthermore, they are advised to not ask the guidance system

Interview

Patient

1. Would you prefer to have this device be portable? Why or why not? (Stationary/portable)
2. How do you take your medication on holiday or days out?
3. Do you want to be able to take medication with you while on holiday? (Ability to take doses away from home)
4. Do you prefer physical buttons or touchscreen to interact with the device? (Buttons/touchscreen)
5. How many different medications should the machine hold? (Amount of different pills)
6. How often do you get more medication from the pharmacy? (Storage capacity)
7. How would you like to be notified to take medication? What notification method works best for you? (Notification)
   1. When the medicine is ready, the machine plays a noise and produce a light signal. It will also send a phone notification after 5 minutes if not taken. Would this be a nice way to be reminded?
8. Would you prefer to fill the machine with pre-packaged rolls or pills from a bottle? (refill)
9. How do you currently get your information about your medication? How would you like to receive information about your medication? (Information)
10. What are suggestions for the device that would make it better to use? (General/ending)

Caregiver

1. How does responsibility surrounding medicine intake currently work?
2. Do you check that the patient has taken their medication?
3. What would you like to be notified about? (Amount of monitoring/ validation)
4. How do you want to be notified that the patient has to take/ has taken the medicine? (Notification)
5. Would you prefer to fill the machine with pre-packaged rolls or pills from a bottle? (How to refill)
6. What is the current protocol for medicine intake? Which aspects should the device do? (Security)
7. What are suggestions for the device that would make it better to use? (General/ending)

Robot Hardware and Design

Robot Description

We have designed a small (portable?) robot to act as an medication adherence aid for chronic/long-term medication therapy. The robot is to be used as a home product of the patient and can remind the patient to take their medicine (on-time). The robot can contain multiple types of solid medication and is able to release predefined doses per time period as set by the caretaker or patient. When the time comes for a patient to take their medication, the robot will notify the patient via its built-in LED screen and speakers. The combination of audio and visual stimuli is used to ensure that the patient takes notice of the robot and is reminded of their medication. In the case that the patient would like more information about their medication, as they would get in the information leaflet provided in the package commonly bought, the user presses a button and the LED screen and speakers will inform the patient.

Block diagram of the ideal design of the pill dispenser.

Base state diagram of the main part of the robot, where the dispenser is an already existing system

Full Dispenser System

The main differences that come with the full dispenser and the system we wish to implement is that the full system also takes care of the dispensing aspect of the device. Since this has been done successfully by a number of companies, the team decided to focus on the information aspect of the device. An information system has not been implemented yet, and the addition of the information module will help aid in the medication taking process.

Hardware

When it came to the hardware design for the prototype, the team came up with two possible solutions. The first solution uses all the components that the team ideally wants to use to create a full prototype. The second solution is to maintain as much functionality as possible, while making it as cheap as possible for the device to be competitive in the market. This second solution came about to allow the device to be more accessible to the consumer. Regardless of the solution chosen for this device, the components necessary are defined by the functionality the device should have. To define the function requirements of the device, the following block diagram was made. The device needs a:

• processor to store and run the software, as well as to interact with the other components of the device.
• button for multiple functions. The user can press it to dispense their medication once a notification has been sent out. This will also turn off the notifications. It can also be used to get more information about medication.
• screen to display information about the medication, prescription, and can also be used to notify the patient by flashing.
• battery or power cord to power the device.
• speaker for auditory notifications. It can also be used for verbally informing the patient about their medication or prescription should the patient want that.
• servo motor and controller to dispense the medication from the storage containers.
• storage method for the medication to be dispensed.
• collection tray to collect the dispensed medication, which can then be removed by the patient to take the medication.
• sensor to check if the user really took the medication out of the tray and sends a notification if the medication is not taken out.
• body to house all the components.

When it came to the ideal system, the processor of choice was the Raspberry Pi 4B for its versatility, and the capabilities of Bluetooth and WiFi. This way, the device can communicate with the app on the users phone. For the display, a 7" Raspberry Pi compatible touchscreen display was chosen for its large size, and its compatability with the processor. In terms of power, there are two options. The first is to plug the Raspberry Pi into a socket, which would make the device stationary, and the second being a battery. To check battery life, different operating modes and battery capacities were checked with PiJuice. This yielded a 12000mAh battery with a battery life between 9-12 hours. These components are the most important, and are the most costly. The remaining components are relatively cheap, and their functionality is straight forward. All components were found on TinyTronics for ease of ordering. The components are shown in the table below.

Ideal Device Hardware

Function	Component	Price	Functionality
Processor	Raspberry Pi 4B	€62.50	WiFi and Bluetooth Compatible
Screen	7" TFT LCD	€60.00	7" Touchscreen, Compatibility with processor
Battery (Optional)	12000mAh LiPo	€36.00	9-12 hour battery life
Speaker	Speaker	€2.00	Produce sounds
Speaker Amplifier	Amplifier	€8.00	Interface between processor and Speaker
Button	Button	€3.50	For dispensing medication
Sensor	Pressure Sensor	€3.50	Detecting whether medication was taken from the tray
Housing	Spool of 3D Print Filament 1kg	€10.49	The price is for half the spool, which is likely what the device will need

This setup will cost a total of €185.99 if the battery is included, or €149.99 if it is plugged into a wall. This is quite expensive for a device to add to a dispensing device. This could be turned into a dispensing machine with the addition of medication storage and servo motors, which would require a redesign for the 3D printed housing, and the addition of servo motors for dispensing. This would not add significant costs to the device. However, the chosen components are a much higher specification than necessary, which can be replaced by cheaper components. The competitor DoseControl device costs €139 according to their website, so the target is to select components that can still operate the required software while reducing the costs below that of the DoseControl device. The table below outlines cheaper alternatives of components for the information module.

Cost Efficient Hardware

Function	Component	Price	Compromise
Processor	LilyGo ESP32 with Built in Screen	€22.50	WiFi and Bluetooth Compatible, Lacks Storage Space
Screen	Built into Processor	€0	2.2" display, no touchscreen
Storage	SD Card 16GB	€5.75	Storage for SD card slot
Battery (Optional)	2500mAh LiPo	€8.50	Could not quantify battery life. Estimated 5 hours battery life
Speaker	Speaker	€2.00	Produce sounds
Speaker Amplifier	Amplifier	€8.00	Interface between processor and Speaker
Button	Built into Processor	€0	For dispensing medication
Sensor	Pressure Sensor	€2.50	Detecting whether medication was taken from the tray
Housing	Spool of 3D Print Filament 1kg	€5.25	The components are smaller, so only 1/4 spool is expected

This setup is significantly cheaper and more compact than the ideal setup, with most of the costs going only to the processor, which has built in WiFi, Bluetooth, and display. The main disadvantage of this setup is the significant reduction in screen size and battery life, should the battery be included. Due to the smaller nature of these components, the amount of 3D filament will be less. The total cost with the battery is €54.50, or €46.00 excluding the battery. This significantly undercuts the DoseControl device, and could be more accessible to people financially.

Affordability

Some more affordable state-of-art products that are similar to the "DoseControl" device are available on online marketplaces such as Amazon from 35 euros onwards. Like the products described in the state-of-art section, they provide apps and reminders both auditory and visual to remind patients of their medication.

None of the products researched have an integrated information system on the product itself. For our system to be used widely, we want to manage costs so that the product does not burden the user. An overview of preliminary potential hardware costs is below.

• Computer
  • Raspberry Pi 4 ~ 35 dollars
  • Arduino Uni Wifi Rev2 - 47 euros
  • Arduino Rev3 SMD - 23 euros
• Display
  • Raspberry Pi Touch Display 3.5 Inch ~ 25 euros
  • Waveshare 4 inch Display ~ 35 euros

Information System

Requirements:

• Patient must be able to receive medical information about their medication
• Easy to use system
  • simple application
• Accessibility
  • Combine reading & listening

Optional:

• Emergency Button
• Contact Button

Software

Sjoerd - Add explanation of software and AI

Fenna - Literature review AI in EU

Sven - Experiment with the AI

Input signal diagram

Diagram with the possible inputs that can be given to the robot

Diagram the possible routes can be seen. From this we can see which possibilities the user has and therefore what the robot needs in its system. Looking at the diagram we see that the three main components that are needed to let this part of the system function are the Raspberry Pi, the button and the LED-screen/speaker combination.

The button is needed to so the robot knows when the user wants more information or wants the pills to be dispensed.

The LED-screen and speaker are there to show all information and the schedule of the user.

The Raspberry Pi in this case is the main information source of the robot, it will send signals to remind the user of their schedule and give more information when this is asked.

The final component in this diagram is the weight sensor, which is purely used to check if the user takes their medication out of the tray after it is dispensed.

Medical Databases for Information

Local Application

In the Netherlands, medication available in the Netherlands is sorted and information regarding medicine is stored in a public database called the "Geneesmiddelen Informatie Bank". On the website the medication name is entered and if not specified, various versions are shown to the user. Given that the patient does not know what version/from what distributor the medication comes from, this is information that should be stored in the robot when medication is stored. Each page for the medication will indicate the method of administration, its use, the patient information leaflet, and the product characteristics. For use within the Netherlands, this system can then be used to inform the patient.

There is also the "Bijwerkingen Centrum Lareb" which can be used to find or report side effects of medication. In the case that the user is not satisfied with the information provided by the database, they can be brought into contact with the center to find if any other information is available or what they are experiencingis related to their medication.

Global Application

Some global databases exist such as WebMD's A to Z Drug Database and Drugs.com but these have limits to the vastness of their information. A simpler solution would be to supply the robot with the medical information upon storing the medicine. PDFs or similar files of information leaflets are available on medication supplier websites as mandated by law. By supplying the robot directly with the information, it does not need any net connectivity to research the consumer medicine information (CMI) at the request of the patient.

For the case of the specific type of medication, if this information is stored within the robot upon storing/refilling of the medication, and routing the name to the general name known by the patient it would have the correct information to fill into the database and receive the necessary information. This solution would also make sure that there was no misinterpretation of the patient's medication type and the information is retreived faster. A file type retrieval instead of a website would also allow reading the information to be more practical as website layouts can be less clear when transferring to an internal system, especially with text-to-speech functions.

Integration and Security

From the information given above, the workings can be described as the patient pressing a button/stimuli and needing to enter for which medication the information is needed. As some medications have uncommon names and pronunciations/spellings and to make the system more robust, the patient can be given their options as buttons on the screen or as options said aloud to which they would reply which one.

For home use and control applications, the robot does not need to know any patient information and only the medication it is provided. In the case that connection to the GP or apothecary is needed, the robot can keep the security of the information of the robot by, again, only having the needed information about the medication and doses but not patient data. The connected supervisor of the medication would have that information at their disposal due to their contact with the patient but would not need to load this information into the robot.

Summary Interview

First a short description of the interviewee will be given. She works as a self-employed caregiver in the home care sector. This entails that she goes to her clients that live by themselves or with their families. Her clients are quite diverse. A great number of her clients are elderly, but she also has clients that are children or young grown-ups that live with their parents. Most of the clients take medicines that she brings to them and she talked about some problems that she came across.

The clients of the second interviewee mostly take their medicine themselves. However, she has had multiple examples of clients forgetting to take their medicines, and thus sometimes worries that the clients will forget their medication again. The reasons why medications are forgotten are mostly the times when a client is not at home and comes home late and therefore forgets the medicines. A portable medicine dispenser might be a solution to this problem. However, she does see a problem that if the portable dispenser is only used when the clients go away from home that they might forget the medicine dispenser instead of only the medicines.  A different example of a solution that one of her elderly clients uses is an alarm clock that drops a small bag of medicines when the medicines must be taken. However, she does not get notified if a client has not taken their medication, she only finds out if she visits them. She was interested in the idea of notifications for her to know if the medication is taken, but also mentioned that she did not need to know that her clients took their medicine every time they took them with a notification, but a log would be a better alternative. Furthermore, it also differs per client, for example a notification if medication is taken from a client that has never forgotten their medication would not be needed.

An example of a client that needs to grind their medicines before they take them suggests a function that a medicine dispenser in the future that could prepare the medication beforehand would be ideal. (However, this would be very complicated and not in the scope of this research.)

The information system could, according to her, help her with answering questions when she is not around. However, she explained that most of her clients know everything they need to know about their medication. On the other hand, in some cases where the client gets new medicines or has a lot of different medicines, the information system will be helpful as for some clients it could be hard to remember new descriptions or a lot of different ones. For specific situations, for example in where a client is ill (for a different reason than where they take their medication), this system would be perfect, she mentioned. (However, the information should be correct, and this could be a problem in this special situations).

Privacy Requirements

-       A patient can give their permission to use personal data, if they have received all the relevant information about the possible consequences and the reasons for data sharing.

-       Assumption of patient’s permission to share information

-       In the case that no Personally identifiable information (PII) is used, data can be shared

https://www.knmg.nl/actueel/dossiers/beroepsgeheim/medisch-dossier

-       Caregivers that need access to information to care have permission

-       Professional secrecy can expire for scientific research purposes

-       Caregivers can share information that is directly relevant to their work

https://www.regelhulp.nl/onderwerpen/kwaliteit/beroepsgeheim

-       Organizations outside of healthcare can obtain health data but must fulfill the confidentiality obligations

https://www.autoriteitpersoonsgegevens.nl/themas/gezondheid/gezondheidsgegevens-gebruiken-en-delen/gezondheidsgegevens-delen-met-derden#algemene-regels-gegevens-delen

For robot/app:

Compartmentalization of data can be done to avoid the necessary use of private data. The robot would have no access to PII and only to relevant information; the type of medication and doses. The caregiver or doctor connected with the robot would have that information and for example: connect the medical dossier to a number that would be shared with the robot. The only viewer of personal data would be the doctor/caregiver, already having the patients permission.

Norm for data security in healthcare called NEN 7510, publicly available in the Netherlands

-       Data can only be given and used when:

o  Caregiver needs to carry out an activity for which data is needed

o  There exists a healthcare relation between person and patient to which the data is connected to

o  Data is needed in support of an activity

https://www.nen.nl/zorg-welzijn/ict-in-de-zorg/informatiebeveiliging-in-de-zorg

For interview/survey:

-       Caregivers can give information not pertaining to a specific patient as long as no PII is given

-       With permission of the patient, caregivers can give more in-depth information (since our research does not pertain to the patient themselves it is most likely not necessary)

Legislation on AI

EU AI Act

First regulatory framework proposed in 2021 to ensure that AI system use in the EU is transparent and should be overseen by people. AI systems that are of unacceptable risk will be banned. These include:

• Cognitive Behaviour manipulation
• Social Scoring
• Biometric identification/categorization
• real-time & remote biometric identification systems

AI like ChatGPT needs to adhere to EU copyright law and transparency requirements such as:

• Content disclosure
• design for illegal content prevention

GPT-4 is a more advanced model that according to the EU poses systemic risk and should undergo more evaluation for public use.

The regulatory framwork defines 4 levels of risk:

• unacceptable risk
• high risk
  • management, logistics and administration of processes and people in applications incl. governmental, judicial, educational (ex. transport infrastructure, exam scoring, credit scoring, evidence evaluation)
  • will need risk assessment/mitigation and human oversight, high robustness, security, accuracy
• limited risk
• minimal risk

The AI act was approved on the 13th of March by the European Union. There are compliance timelines to which developers need to adhere to with their AI systems.

• 6 months after entry into force
  • unacceptable risk AI is prohibited
• 9 months after entry into force
  • General Purpose AI codes of practice must be finalized
• 12 months after entry into force
  • General Purpose AI codes of practice now apply
  • review and ammendments on prohibitions

Informal planning

Week 1		Week 2		Week 3		Week 4
Literature review + summaries Relevant groups’ work	A A	Literature discussion Functional requirements Target audience & problem	A	Designing Preliminary software Components + feedback + order needed		Finalize components Software prototype 3D modelling of product
Week 5		Week 6		Week 7		Week 8
Software done Assembly done 3D Printing done		Iterate on software or add app Solve problems		Solve problems Prepare presentation Begin cleaning up wiki		Present Clean up wiki

A = All, Q = Quinten, F = Fenna, T = Thijs, D = Daniel, Sv = Sven, Sj = Sjoerd

Time spent

Week 1:

All	1st meeting (2h)
Quinten	Researching SotA (2h); Finding and reading relevant papers regarding medication dispensers (3h); Finding and reading relevant papers regarding ethics and elderly care (2h)
Fenna	Research State of the Art (1h); Robot specifications (2h); Research Product Design (1h); Research Use Case (2h)
Thijs	Looking at already functioning medicine dispensers (1.5h); Reading papers on dispensing robots and summarizing them (4.5h); look at ethics for medication rules (0.5)
Daniel	Research what has been done/state of the art (3.5hr); Dispensing Specifications (1.5hrs); EU regulations, medical technology state, privacy and ethics of the tech (3.5hr);
Sven	Research on state of the art/dispenser mechanisms (1,5h); Research AI implementation by notifications (1,5h), naming requirements/specifications (1h)
Sjoerd	Setup wiki (2h); process annotations of first meeting (1.5h); Read documentation OpenAI and Google for insight into which we can use (3h)

Week 2:

All	Feedback Monday meeting and evaluation (1h), Meeting 23-2-24 (1h) see minutes
Quinten	Transfer and ordering of data to wiki (2h)
Fenna	Privacy Research (1.5h)
Thijs	preliminary design options research (2.5h)
Daniel	Identifying Stakeholders (1h), Interview Questions (2h), Data requirements (0.5h)
Sven	start identifying stakeholders and specifying the target audience (1,5h), translate and improve interview (1h)
Sjoerd	Create prototype AI implementation, with testing and prompt engineering, using API documentation (4h)

Week 3:

All	Feedback Monday meeting and evaluation (1h)
Quinten	Literature Review incorporation into stakeholders (3h); Responsibility shift (4h)
Fenna	Product description (1.5h); Incorporation Literature review (2h)
Thijs	Start making a design for the machine and block diagram of systems needed (6h)
Daniel	Cleaning up Interview Questions (1h); Incorporating Literature Review into Wiki (4h);
Sven	Connecting to informal caregivers to plan an interview/prepare, (3h); incorporating Literature review (2h)
Sjoerd	Cleaning up Interview Questions (1h); Incorporating Literature Review into Wiki (2h);

Week 4:

All	Feedback Monday meeting and group discussion (2h)
Quinten	Analyzing common adherence problems via literature (2h); Finding limitations to solving these problems (3h); Finding and formulating a target audience from found limits (2h); General literature review (1h); Outlined a problem statement (2h);
Fenna	Research medical information availability (2.5h); Investigating information possibilities and state-of-art solutions (2.5h); Brainstorm information system components (1.5h); Research affordability devices and components (2h)
Thijs	Research medication commonly used by elderly and a week in the life of an elderly person (1.5h); make the storyboard (5h); make a base state diagram and research into functions (2h)
Daniel	Brainstorm (3h); Incorporating Literature (2.5h); Investigating Hardware and cross compatibility (4h); Adding Hardware to wiki (1h);
Sven	Research Spencer (Philips) and Medido (2h); preparing new interview and having it (4h).
Sjoerd	Collect functional requirements app (1h); Generate data flow diagram and model modalities (1h); Investigate existing models adjusted for new requirements (3h); Setup software environment for app (3h due to bugs); Find base app to save time (2h);

Week 5:

All	Feedback Monday meeting and evaluation (1.5h); Friday Meeting (1.5);
Quinten
Fenna
Thijs	Make input diagram (3.5h); Proofread wiki (1.5h); start making input diagram into digitalized system (not finished yet) (2h)
Daniel	Editing and Proofreading Wiki(2h); Cheaper alternatives Hardware(4h);
Sven	Summarizing interview and important conclusions (2h).
Sjoerd	Develop app (file upload, medicine question button, API fixes, updating dependencies, streamlining usage) (6h); Writing Wiki entry on app development (2h);