PRE2019 4 Group5

MediGO

Group members

Name	Student number	Study
Danielle Paige Gillam	1227637	Psychology & Technology (ICT)
Lucia Kalkman	1335529	Electrical Engineering
Annemijn Cissy van der Lande	1239822	Psychology & Technology (Robotics)
Dajt Mullaj	1286722	Computer Science
Fabiènne Pascalle van der Weide	1004980	Psychology & Technology (ICT)

Introduction

Nowadays, more and more automated technology in the vehicles industry is making its entrance in society. With the current situation of COVID-19, people are forced to live in social distancing societies , which results for some social groups in major challenges to continue living in a normal and healthy way. One of the major issues society is facing is maintaining the health of people who have to stay home, but still need to receive their medicines. Delivery robots could give an outcome in this situation and might give perspectives for after the COVID-19 influenced society. These robots are already in use, in several situations, environments and forms. Furthermore, they are currently experimenting with these delivery robots for multiple purposes.

Problem Statement

MediGO logo

This project will explore how to implement a system of autonomous robots for the delivery of medicine and goods to the elderly and sick people. The system could then be used in hospitals to help the staff with intensive care units and for deliveries from pharmacies directly to houses or elderly homes. To sustain an efficient delivery scheme the project will develop a prototype for a multi compartment robot. Each compartment will contain medicine for a specific delivery, so that in a single trip the robot will visit multiple houses or contain all the drugs for each elder of an elderly home. The prototype will consist in demonstrating the robot’s multi compartment system. To do that an app will be developed and hardware representing a robot with more compartments will be assembled. The app will have an option to log in as a user or as a pharmacist/caretaker. The robot will simulate compartments opening or closing and it will have a board to take inputs. As a user you will be able to order medicine through the app, which in turn will display a password to type on the robot’s board. When such action is performed the correct compartment containing the requested medicine will open. The system, as specified before, could also be used to perform deliveries within the hospital's ground in order to prevent the spread of infectious diseases among the healthcare staff.
The system, furthermore, will be designed and implemented to specifically perform deliveries of prescription's drugs. Because of its purpose the system has been called MediGO, and a logo for it has been developed. The logo will appear on the different parts of the prototype, to characterize the project. The logo has been designed to resemble the green cross symbol that is used as a pharmaceutical sign in numerous nations.

Objectives

• Research the state of the art of the current autonomous delivery robots.
• Understand the requirements for delivery robots in the medical field.
• Design and implement a multi compartment system that can lock each compartment by means of a password and communicates with an external application to set said passwords.
• Test the system to understand its limitations and improve its functionalities.

State of the Art

Delivery robots for medicine

The types of robot forms that are currently under study and first use, can be subdivided into two areas: vehicles at the ground and in the air. The great advantage of using air-based delivery robots, like drones, is the reduced amount of interaction. However, traffic regulations are currently undefined. For the ground-based vehicles, both aspects named before are the opposite in here.
Another distinction that can be made, is the environment in which the delivery robot will perform. Currently, there are view hospitals in which robots are used to transport medicines to the patients. This is an example of inside transportation, minimizing path planning and the amount of traffic, but maximizing its demand for room recognition. Also one pharmacy has used delivery robots as an experiment by transporting the medicines to care-units where nurses took over the packages. The overall attitude towards this user experience was fine, but is influenced by the fact that both stakeholders had to minimally interact and were not involved in the technical liability issue. This is an example in the field of an outside environment where the robots had to face a lot of traffic and path planning, but less on room-recognition, since it delivered a package to one care unit.
Furthermore, the purpose of transport can vary a lot. At the moment, drones and ground vehicles are mostly transporting goods like food and medicines, both giving an outcome for people who have transport difficulties or are not able to go outside because of their health. In Wuhan for example, the delivery robots are both already in experimenting use. For food, real-time and path planning are really important. Another important aspect is its capacity of carrying a large amount of goods. It is therefore more common that riding vehicles carry these goods, whereas medicines are in smaller amounts but are more often carried by drones due to safety reasons. Currently, the only robot delivering medicines has the main purpose to act in emergency situations where normal vehicles do not easily have access. The drone is called ‘Avy’ and is broadly used in war regions or remote and congested areas. Time plays a role in this as well, for instance: warm food needs to be delivered fast and vital donor organs need to be brought fast in war areas. We can conclude that the goal of the service provided can therefore play an important role in the design choices.
Lastly, the types of technique can be distinguished, since this varies a lot per delivery robot. We will discuss this by looking at path planning, coördination & recognition, mechanics and AI in general.

Path planning/scheduling

Finding a feasible route of movement can be challenging for autonomous vehicles. Multiple algorithms are therefore proposed to improve its efficiency and safety on their path. These algorithms differ for robots that are returning or non-returning . Also the use of GPS systems is a common tool in scheduling. Furthermore, a newer tool has been designed by making use of pedestrian flow, in which it adapts to the pedestrian potential equation based on the route estimation model . When making a path planning outside, often a SLAM system is used, helping the robot to deal with the huge maps of city centers. It provides a large map of the surrounding environment . This system takes the type of roads into account, traversability and provides a method for localization in dynamic environments . Lastly, there are also central systems already that can map where all other robots are currently located, to generate as a pick up / order system, solving many problems in the communication between robots implementation on a larger scale .

Coordination & object recognition

A method for coordination is iGPS, this is working with ceiling cameras . Another commonly used technique combination for coördination and object recognition is making use of artificial intelligence, ultrasonic sensors and cameras . An example of this is the FedEx SameDay Bot — which looks like a cooler on wheels — is designed to travel on sidewalks and along roadsides to deliver small orders to homes and businesses . This type of robot successfully passes objects on their way, like trash cans, skateboards etc. Moreover, another example is Amazon Scout devices; also using cameras and sensors for its planning and cöordination . Furthermore, there are also robots that are capable of recognizing and distinguishing between rooms , making use of intelligent machine vision .

Mechanics

First of all, when looking at the ground vehicles, they have to face several problems on the road, so good mechanics are essential. At the moment, a wheel and track hybrid robot platform exists which is highly applicable to various urban environments. The developed robot platform has all advantages of track and wheel. Furthermore, this hybrid concept is highly energy-efficient because of its less-friction using wheels only on navigating flatland . Moreover, new developments in the technologies of drone delivery are aircraft design, battery improvements, and control software. They could transform this industry and, consequently, society as a whole .

Finally, we should not forget to look at the current attitude people have towards this upcoming innovation. This is dependent on the perspective we look at. Current studies show this broadly, by making a distinction in the type of stakeholder. Random people in traffic for example will have different attitudes towards the robot than the receivers of the good . Also the environmental footprint raises discussions: drones are a relatively sustainable transportation method, but the production is not. However, one thing that is universal is that the delivery robot should be in balance with safety, ease of use, environment, goal and efficiency. Dependent on the welfare of the society, attitudes towards robots might differ.

Lock Systems

DHL/PostNL Lockers

In 2017, the first DHL Lockers could be seen in the Netherlands . Instead of a delivery at your home, you can choose to let your package be delivered in one of their yellow lockers. In the Netherlands, there are 3000 DHL Locker points, so there is always one close to your house and they're accessible day and night. If you've sent your parcel to a locker, a unique code will be texted or emailed to you. With this code, you can open your locker. PostNL has a comparable service. Their orange lockers can also be used to send or receive parcels and can also be opened with a unique code (that gets send to you by email or SMS).

Pharmacies with machine for "take-out"

BENU is one of the leading healthcare providers in the Netherlands. One service BENU pharmacies provides is the take out machine for all kinds of medication . The service is free, you don't have to wait in line when picking up medication and in most pharmacies it is possible to pick up medicine 24/7 when using this machine. The medicine can be achieved by entering a unique code (sent to you by SMS or e-mail) and your birth date for veryfication. Multiple examples of these machines exist.

Digital locks

There is a number of companies that specialize in digital locks for houses, vaults and other property. On example is by using keycards to digitally lock any door . The benefits are that they can be easily used for multiple doors, they can provide restrictions for certain times or acces levels, they fit nicely in a wallet, and they can configure and reconfigure access using the same card. Disadvantages are that you still need a physical token and that many keycards can be easiliy hacked using inexpensive devices. Another example is the company digilock . They sell digital locks for lockers, workplace and personal storage, for healthcare and also to secure buildings or rooms. A third company is VaultLOCKS, that trades in electronic lock boxes, mainly for people that often rent property . The owner can send a secured code to open de door to the renter as soon as he/she arrived at the location, which saves the owner a lot of time travelling.

Limitations and issues

There are multiple problems before autonomous delivery robots can be fully used. In the following part the major issues will be stated that are currently holding back the implementation of delivery robots. One of the main problems is the attitude of society about automated vehicles. There are concerns about the safety of the transport, such things as hacking could cause problems. However, there are other concerns people have. For example whether more people will get unemployed when delivery robots are widely spread. People are also wondering whether a robot can reach every location, climbing stairs or entering a building could be difficult. People also think that for example a sidewalk robot should not hinder pedestrians, which causes even more things to take care of when designing the robot.
Another problem are all the technical issues. Is it possible for a robot to reach a higher efficiency, improve time and reduce cost and energy consumption. Will a robot be as reliable as a human? It should be able to deliver something within the same time and guarantee that the product arrives. The biggest technical issue is the navigation and the interaction with the environment. This means the robot should always know where it is and where it’s goal is, but also what happens around him. What are possible dangers and what is the best possible way to get where it should be. Especially with a lot of individuals who don’t follow the same paths it can be difficult for a sidewalk robot to avoid them all. The current technology is still struggling with this.
The final issues are the regulations. For UAV’s there are special regulations, and they are not allowed to fly everywhere, however, self-driving cars counter the same issues. They are not allowed on the road because of many ethical issues and some technical liabilities. The last option are sidewalk robots, which don’t have to meet as many regulations, but they are also difficult because pedestrians are hard to model and follow less strict paths. All the different regulations in different countries and all the parts that are still very vague make it difficult to really develop delivery robots. Also questions like who is responsible for the robots mistakes make it less attractive to start working on delivery robots.
The current medicine delivery drone, is not convenient for the purpose of extending the capacity and for the help for elderly having reasons holding them back to go by themselves to the pharmacist to gain their medicines. There is therefore a need for a medicine service for elderly that is efficient, convenient, contactless but still human friendly in use. It should be able to carry large amounts of medicines.

Stakeholders analysis

There are a number of different stakeholders when it comes to the field of medical delivery robots. Here the main stakeholders within the scopes of users, society and enterprise will be presented and discussed. Furthermore an ethical analysis will be performed in order to evaluate the different ethical issues that the stakeholders might have regarding the MediGO delivery system and how those issues affect the design choices of the system.

USE perspectives

Users

The primary users of medical delivery robots are those who directly interact with the robot. Therefore elderly people who require medicine deliveries will fall into this category. These patients will have to have sufficient understanding of how to interact with the robots and respective applications. Pharmacists will also be considered primary users as they will have to interact with the robot in order to fill it with sufficient supplies for respective patients and understand the operation of the application and robot. These users will be considered the most in the design process as they will use the robot for its purpose, and so interface design choices as well as technical design choices will be made in order to best accommodate these users. The families of the elderly people are considered the secondary users, the MediGO system provides comfort for the families as they do not have to worry about their elderly parents or grandparents forgetting about collecting their prescriptions or leaving the house, especially during the COVID-19 pandemic, and risking infection.

Society

Within society there are a number of stakeholders, the first being the Government. The Government are responsible for laws and regulations regarding the medical delivery robots, this includes traffic regulations as well as ethical laws.

The second stakeholder that is a part of the societal perspective is nurses caretakers and doctors. As well as being direct users of the robots in terms of stocking them with medicine, the medical delivery robots impact them in a less direct manner too. For example in the midst of a pandemic or an outbreak of disease, the fact that these health care workers are able to send a delivery robot to infected patients means that they reduce the risk of being infected themselves. Hospitals themselves are also stakeholders and due to the fact that hospitals are commonly hotspots for these outbreaks the reduction of infection of their staff will help prevent understaffing. The reduction of the spread of disease will additionally help society as a whole as well as reducing stress on governments.

The final societal stakeholders are people who encounter the medical delivery robots on the streets while they are performing their delivery or pick-up tasks. These individuals play an important role in the fabrication of laws and regulations as their lives will be affected by the robots without any direct gain from them. For example the possibility of disruption in pedestrian traffic or even the vandalisation of the robots will motivate respective regulations.

Enterprise

Within the scope of Enterprise the main stakeholders are the technical companies which are developing the medical delivery robots as well as the hospitals and pharmacies with which they are partnered.

Ethical Analysis

There are many ethical considerations that come with the use of autonomous robots, especially within the medical world.

This ethical analysis will be loosely based upon the Beauchamp and Childress model which uses the following core principles for considering ethical issues :

• Beneficence
• Nonmaleficence
• Autonomy
• Justice

The most obvious and direct risk of any assistive technology, is the potential of physical harm. However there are also more issues that may be less obvious. In a study conducted on a delivery robot used in multiple departments of a hospital, Mutlu and Forlizzi discovered that different patient groups had different emotional reactions to the robot. Cancer units were not accepting the robot, finding it annoying, while postpartum units were accepting the robot and calling it delightful.

The results of this study suggest that different user populations can have completely different views or experiences with the same robot. These opinions could be due to a number of social or cognitive reasons. Because of the wide variety of possible reactions to robots in these situations it is important to take into consideration a wide range of user perspectives. According to previous experiments , it has also been demonstrated that some users form emotional attachments to robots that they were interacting with, some even having the impression that a robot would miss them when they were gone, which is beyond the capabilities of modern robots. Humans have a strong tendency to anthropomorphise objects with human-like features like a face or eyes. Such personification may be unintentional, occurring because a caregiver refers to the robot as ‘him’ or ‘her’. This anthropomorphism assigns greater intelligence to the robot than it truly has. The same can be said for robots that communicate via a natural human voice. These emotional attachments are misleading and could be seen as a form of deception and lead to too much trust in the robot which is unethical.

Autonomous car presenting anthropomorphic features

In order to mitigate this deception as best as possible, in the case of our robot technology, it must be made clear from the instance that any user sees the robot that its main purpose is delivery and not communication or medical advice. However other studies have found how in the car industry a certain degree of anthropomorphism can increase user's trust in autonomous vehicles . Keeping both view points in mind, the MediGO delivery robot will be designed without real human features such as a face, realistic eyes or a human voice, but will present basic aspects of anthropomorphism, like the headlights of a car. In addition to this, before any technology is deployed, it is critical to explain to all users involved what the capabilities of the technology are as well as possible. However, this can be unrealistic in the scope of delivery robots as uninformed bystanders (for example people on the streets that encounter the robots) will be exposed to them often, full disclosure can be difficult in these situations.

The risk of further isolation due to decreased human contact due to replacement with robots is also an ethical consideration. Particularly for populations that are known to suffer from isolation, including the elderly. However, in this case the costs of the medical delivery robots outweigh the benefits especially for those who are unable to collect their medication alone due to mobility or cognitive reasons. Here there is a tradeoff between getting vital, possibly life saving medication via an autonomous robot and the risk of further isolating a user and it is clear that the former is too important to disregard the use of these delivery robots.

Another ethical issue with delivery robots that arises is in terms of privacy. These robots will have access to sensitive information about a patient such as their home address and the medication which they take regularly. Because this information also needs to be shared with the pharmacist and in some cases caretakers, it is important in this case for the users to sign an informed consent to understand exactly which information of theirs is accessed. For instance, a user might not realize that the robot’s camera could record video, the camera should therefore be an obvious feature of the robot so that everyone who sees it understands that it has this feature. Furthermore, it is very important to make sure that the capabilities of a robot are sufficiently explained beforehand so that a user has been as well informed of a model of the robot’s abilities as possible.

Another justice-related issue when discussing robotics in socially assistive settings is the notion of responsibility: Who should be held responsible if or when things go wrong? Error in robot functioning could occur due to user error, or an error of the robot itself. The difference is not always clear between these and so there is a blurry line of moral responsibility. For example the user error could be a result of poor instructions or false expectations due to the aforementioned deception. In this case it is difficult to say who should be held responsible if something does not go to plan. In the case of robot error, the problem could be in the design, hardware, or software of the robot, meaning that the responsibility belongs to the designer, programmer, manufacturer, distributor, or retailer. However this is difficult as most software licenses explicitly absolve the software developer of responsibility, and the same goes for most manufacturers. Therefore the role of responsibility is difficult to ascribe to one particular party. However there are more tangible errors that have clear links to responsibility. For example, if the wrong medication is loaded into one of the robots compartments for a particular patient, it is clear that this responsibility belongs to the pharmacist who loaded the robot.

Requirement analysis

During the requirement analysis phase of the project three main steps were undertaken. During the first step the stakeholders needs were collected. To do that several one to one interviews were conducted by the team members. The second step consisted in creating measurable requirements from the gathered needs. During the third step, instead, several security requirements were defined. Finally, at the end of this section, an overview of the system at this stage of the development processes is presented.

Collecting the stakeholders needs

To identify current problems and needs regarding the delivery of medicine using robot, interviews with the different stakeholders were conducted. Specifically the primary users (elderly), as well as pharmacists, and caretakers were interviewed. For each one of these groups a set of questions was created to be used during the interviews. According to Griffin and Hauser (1993) in order to gather 90% of the users needs between 20 to 30 interviews must be conducted. In this regard our team managed to interview a total of 20 stakeholders. The questions that were asked and the transcripts of the responses can be found here. Below are reported the needs that were gathered from the different interviews with the stakeholders. The needs are presented within the user segment they were collected from.

Elderly needs

1.	The robot needs to be user-friendly and understandable for elderly, every action should be intuitive.
2.	A human-like feature (face / eyes) would be nice, but functionality is more important, a voice would be nice.
3.	We need to have a lock system that gets opened by a password/code/app/card that somehow identifies the user.
4.	The password is set up with the pharmacist and is delivered by some means to the user.
5.	The password should be easy to input in the robot, preferably with a simple keyboard.
6.	Deliver on certain, known time slots.
7.	The robot should be able to notify the user that it is at the door.
8.	The robot needs to alarm someone if it expects something is wrong (door doesn’t get opened for example).
9.	The robot (either drone or walking/driving) should be recognizable as belonging to the pharmacy.
10.	The compartments (or at least one/some) should be cooled, since some medication need that.
11.	Don’t let the robot drop the medicine on the doormat (dangerous for pets).
12.	The robot could carry also some indication about the medicines from the pharmacist inside the compartment, in form of a written note for example.

Caretakers needs

13.	It should be "tested" if someone is still clear-headed and independent enough (also physically) to use our delivery system (or decide the person responsible for this).
14.	(In a care home) The robot should have a way to monitor if people actually correctly took their medicine.
15.	The elderly can entrust the caretaker to keep track of the deliveries, which the caretaker can schedule and set.
16.	Set protocol for “not normal situations”, meaning for example a precise set of action the pharmacist will do to inform the caretaker if some information needed for the delivery are missing before attempting the delivery.
17.	If the password is lost can be resent via sms or letter or notified on an app.
18.	Ability to plan in advance which medicines must be delivered on which day.
19.	Possibility to subscribe to the delivery service directly at any pharmacy or at the doctors office.
20.	A smart system to decide the delivery routes and moments is needed.

Pharmacists needs

21.	Separate sachets or clear labels are necessary to not accidentally swap medicine.
22.	People need to be at home during delivery. Smart route planning / notifications for the users are useful.
23.	Cooled compartments for medication that needs to be kept cold.
24.	Option to offer counselling.
25.	Easy to understand application.
26.	QR codes to offer extra info for the patient.
27.	Tracked deliveries.
28.	Option for patients to give feedback.
29.	Database to keep track of the prescription medicines that still have to be delivered or have been already delivered to a certain patient.

Requirements engineering

Using the stakeholder’s needs that were gathered during the interviews a set of system requirements was constructed. The requirements are semi-formal and are written following the syntax defined in the ISO 29148 standard . When defining such requirements it was ensured that they were consistent, complete and practically feasible. They are therefore directly traceable to the stakeholder’s needs.

The delivery system, to parallel the different users segments, was divided into three subsystems: a "tool" used by the pharmacist, a "tool" used by the elderly or the caretaker, and the robot’s compartment system. At this stage of the development processes what precisely is meant by tool is not yet specified. Indeed based on the subsequent requirements, during the next development processes, the specification, it will be decided which technology will be better suited to fulfill said requirements (a desktop application over a phone application for example). For each one of previously stated subsystems different requirements were defined.

Pharmacist’s Tool

The system in this case is the pharmacist’s tool. The tool should be able to communicate with a database containing the customer's details and medication’s needs to retrieve the required information and reserve a compartment of the robot for a specific customer.

To clarify the actors that are involved with the system we include a list of actors with their goal:

• Pharmacist: fill the robot’s compartment with the correct medicines.
• Patients database: hold the details and medication’s list for each patient.
• Delivery Robot: reserve a compartment for a specific patient.

To define precisely the requirements is helpful to also identify the inputs and outputs. We use the interpretation that inputs are received from the actors and outputs are sent to the actors.

Inputs				Outputs
ID	Name	Rational		ID	Name	Rational
IN-P01	inPatientID	Receive patient details identifiers from pharmacist		OUT-P01	outQuerySend	Query the database for the patient details.
IN-P02	inQueryResponse	Receive patient details from database		OUT-P02	outAvailable	Message to the robot asking which compartments are still available.
IN-P03	inAvailableP	Receive request to display available compartments from pharmacist.		OUT-P03	outReserve	Send a message containing the patient information and the desired compartment to the robot for a compartment reservation.
IN-P04	inAvailableR	Receive a list of the available compartments from the robot.		OUT-P04	outOpen	Send a request to open a compartment to the robot.
IN-P05	inReserve	Receive request to reserve a compartment for a specific user from the pharmacist.		OUT-P05	outClose	Send a request to close a compartment to the robot.
IN-P06	inOpen	Receive request to open a compartment from the pharmacist.		OUT-P06	outDepart	Send a request to start the delivery to the robot.
IN-P07	inClose	Receive request to close a compartment from the pharmacist.		OUT-P07	outUpdate	Send a message to the database containing the updated customer information (which medicines have been delivered for example).
IN-P08	inDepart	Receive request to start the delivery from the pharmacist.		OUT-P08	outPatientDelivery	Send patient details update regarding the delivery date and time to the database.
IN-P09	inCompleted	Receive signal indicating the completion of a delivery from the robot.		OUT-P09	outLock	Send a request to lock a compartment to the robot.
IN-P10	inPatientDelivery	Receive patient details update regarding the delivery date and time from the pharmacist.		OUT-P10	outUnlock	Send a request to unlock a compartment to the robot.

Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.

• R-P1 The application shall display a list of the patients subscribed to the delivery service which is ordered by the date the patient must receive the delivery
  Source: Needs 6, 18, 19, 25, 29.
• R-P2 When inPatientID is received from the pharmacist, the tool shall send outQuerySend to the database within 0.2 s.
  Source: Needs 29.
• R-P3 When inQueryResponse is received from the database, the tool shall display the patient’s details within 0.2 s.
  Source: Needs 29.
• R-P4 When inAvailableP is received from the pharmacist, the tool shall send the message outAvailable to the robot within 0.2 s.
  Source: Needs 21.
• R-P5 When inAvailableR is received from the robot, the tool shall display the available compartments within 0.2 s.
  Source: Needs 21, 25.
• R-P6 When inReserve is received from the pharmacist, the tool shall send the message outReserve to the robot within 0.2 s.
  Source: Needs 3, 21.
• R-P7 When inOpen is received from the pharmacist, the tool shall send the signal outOpen to the robot within 0.2 s.
  Source: Needs 3, 21, 25.
• R-P8 When inClose is received from the pharmacist, the tool shall send the signal outClose to the robot within 0.2 s.
  Source: Needs 3, 21, 25.
• R-P9 When inDepart is received from the pharmacist, the tool shall send the signal outDepart to the robot within 0.2 s.
  Source: Needs 6, 22, 25, 27.
• R-P10 When inCompleted is received from the robot, the tool shall send the message outUpdate to the database within 0.2 s.
  Source: Needs 27, 29.
• R-P11 When inPatientDelivery is received from the pharmacist, the tool shall send outPatientDelivery to the database within 0.2 s.
  Source: Needs 6, 18, 20, 22.
• R-P12 When the pharmacist requests to lock a compartment, the tool shall send outLock to the robot within 0.2 s.
  Source: Needs 3.
• R-P13 When the pharmacist requests to unlock a compartment, the tool shall send outUnlock to the robot within 0.2 s.
  Source: Needs 3.
• R-P14 When the pharmacist requests to lock a compartment, the tool shall generate a compartment's password within 0.2 s.
  Source: Needs 3.
• R-P15 When the pharmacist locks a compartment, the tool shall send the compartment's password to the elderly/caretaker's tool within 0.2 s.
  Source: Needs 3.

Elderly and Caretaker’s Tool

The system in this case is the elderly and caretaker’s tool. The tool should be able to communicate with a database containing the customer's details and medication’s needs to update specific information, like desired time for the delivery and notify the elderly or caretaker when the robot arrived at destination.

Actors with their goal:

• Elderly/Caretaker: track the delivery and add patient delivery details.
• Patients database: hold the details and medication’s list for each patient.
• Delivery robot: deliver the medicine to the patient.
• Pharmacist: make sure that the elderly is able to retrieve the medication.

Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.

• R-C1 When the elderly/caretaker updates the delivery date and time, the tool shall send a message to the database to update its information only if the current delivery has terminated or does not start for at least two hours.
  Source: Needs 15, 18, 20, 22, 27.
• R-C2 When the caretaker requests to visualize the patient details, the tool shall display the patient information, containing which prescriptions have been already delivered for the current period and which not, within 0.2 s.
  Source: Needs 14, 29.
• R-C3 When the robot arrives at the patient’s home, the tool shall display a notification indicating the arrival within 0.2 s.
  Source: Needs 7.
• R-C4 When the robot departs from the pharmacy, the tool shall display a notification indicating the departure and the content of the delivery within 0.2 s.
  Source: Needs 7.
• R-C5 If the elderly/caretaker wants to know the compartment's password, the tool shall display the password within 0.2 s.
  Source: Needs 17.

Robot’s compartment system

The system in this case is the robot’s compartment system. This part represents the delivery robot, more specifically its delivery method. Further on the robot’s compartment system will be simply referred to as the robot. It is therefore important to remember that the requirements here specified only address the behavior of the delivery method, not of the complete functionality of a delivery robot (like route planning or autonomous driving). The robot should be able to communicate with the tool of the pharmacist to retrieve patient’s details and reserve compartments and with the tool of the elderly/caretaker to track the delivery.

The list of actors with their goal is extended to include sensors and other hardware components:

• Pharmacist: fill the robot’s compartment with the correct medicines.
• Patients: elderly that needs to retrieve their prescription medicine.
• Elderly/Caretaker: track the delivery for a specific patient.
• Position sensor: detects when the robot arrived at a delivery destination. Because we are not interested in developing a moving robot the position sensor is simply a time sensor that sends an input (signaling the arrival to a destination) after a set amount of time from the delivery departure.
• Memory: keep track of which compartment is assigned to which patient and the details needed for the authentication.
• Keyboard: collect the password of a compartment from the environment (patients).
• Device communicator: send and receive signals from the pharmacist’s and elderly/caretaker’s tool, which are running on another device.
• Bell: device used to notify the elderly of the arrival of the robot.
• Compartment: can open, close and lock the compartment.
• Compartment sensor: checks if the compartment is empty.

In this case it is again necessary to also identify the inputs and outputs. We use the interpretation that inputs are received from the actors and outputs are sent to the actors.

Inputs				Outputs
ID	Name	Rational		ID	Name	Rational
IN-R01	inAvailable	Corresponding to OUT-P02, is a message received by the device communicator requesting which compartments are still available.		OUT-R01	outAvailable	Corresponding to IN-P04, is a message sent by the device communicator indicating which compartments are still available.
IN-R02	inReserve	Corresponding to OUT-P03, is a message received by the device communicator requesting to reserve a compartment and containing the patient’s details.		OUT-R02	outOpen	Send a message to a compartment requesting to open the compartment.
IN-R03	inOpen	Corresponding to OUT-P04, is a message received by the device communicator requesting to open a compartment.		OUT-R03	outClose	Send a message to a compartment requesting to close the compartment.
IN-R04	inClose	Corresponding to OUT-P05, is a message received by the device communicator requesting to close a compartment.		OUT-R04	outDepart	Send a message to the device communicator to indicate to the elderly/caretaker that the delivery departed.
IN-R05	inDepart	Corresponding to OUT-P06, is a message received by the device communicator requesting to start the delivery.		OUT-R05	outArrived	Send a message to the device communicator to indicate to the caretaker that the delivery arrived.
IN-R06	inArrived	Receives a signal from the position sensor indicating the robot arrived at the delivery destination.		OUT-R06	outDest	Send a message to the memory indicating that the medicine has been delivered at the current destination.
IN-R07	inDest	Receives a message from the memory indicating which is the next destination.		OUT-R07	outBell	Send a signal to the bell to notify the patient of the arrival of the robot.
IN-R08	inPasswod	Receives an input from the keyboard indicating which password has been imputed by the patient.		OUT-R08	outLock	Send a message to a compartment requesting to lock the compartment.
IN-R09	inLock	Corresponding to OUT-P09, is a message received by the device communicator requesting to lock a compartment.		OUT-R09	outUnlock	Send a message to a compartment requesting to unlock the compartment.
IN-R10	inUnlock	Corresponding to OUT-P10, is a message received by the device communicator requesting to unlock a compartment.
IN-R11	inNoResponse	Is a message received by the position sensor (remember the latter is really only a time sensor) when the robot has arrived at the destination but no password has been tried for five minutes.
IN-R12	inEmpty	Signal received from the compartment sensor indicating the compartment is empty.

Following are the requirements for this system, which are identified by a unique identifier. Furthermore each requirement has a source indicating from which need it originated.

• R-R1 The compartment on the robot shall be each identified by a different number and a different color.
  Source: Needs 21.
• R-R2 When a medicinine is placed in a compartment, the robot shall ensure that the medicine does not gain or lose more than a 1℃ for at least 5 hours.
  Source: Needs 10, 23.
• R-R3 When inAvailable is received from the device communicator, the robot shall send outAvailable to the device communicator within 0.2 s.
  Source: Needs 21.
• R-R4 When inReserve is received from the device communicator, the robot shall save in the memory the details of the patient and the assigned compartment within 0.2 s.
  Source: Needs 3, 21.
• R-R5 When inOpen is received from the device communicator, the robot shall send outOpen to the requested compartment within 0.2 s.
  Source: Needs 3, 21.
• R-R6 When inClose is received from the device communicator, the robot shall send outClose to the requested compartment within 0.2 s.
  Source: Needs 3, 21.
• R-R7 When inLock is received from the device communicator, the robot shall send outLock to the requested compartment within 0.2 s.
  Source: Needs 3, 21.
• R-R8 When inUnlock is received from the device communicator, the robot shall send outUnlock to the requested compartment within 0.2 s.
  Source: Needs 3, 21.
• R-R9 When inDepart is received from the device communicator, the robot shall send outDepart to the device communicator within 0.2 s.
  Source: Needs 6, 15, 22, 27.
• R-R10 When inArrived is received from the position sensor, the robot shall send outArrived to the device communicator within 0.2 s.
  Source: Needs 6, 15, 22, 27.
• R-R11 When inDest is received from the memory, the robot shall send outDepart to the device communicator within 0.2 s.
  Source: Needs 6, 15, 22, 27.
• R-R12 When inPassword is received from the keyboard, the robot shall send outUnlock and outOpen to the specific compartment only if the password is correct.
  Source: Needs 3, 5.
• R-R13 When inArrived is received from the position sensor, the robot shall send outBell to the bell within 0.2 s.
  Source: Needs 7.
• R-R14 When inEmpty is received from the compartment sensor and the compartment is open, the robot shall send outClose and outLock to the compartment within 0.2 s.
  Source: Needs 1.
• R-R15 When inNoResponse is received from the position sensor, the robot shall send a notification to the pharmacist and the elderly\caretaker (through the device communicator) within 0.2 s.
  Source: Needs 8, 16.
• R-R16 When inPassword has been received from the keyboard and inEmpty has been received from the compartment sensor, the robot shall send outDest to the memory within 0.2 s.
  Source: Needs 20, 27.
• R-R17 The robot shall have drawn the MediGO symbol over its structure.
  Source: Needs 9.

Security Requirements

The security requirements engineering is divided into three main parts. In the first part an access control matrix is defined in order to define which stakeholders can have access to which resource. This way attack's from the inside can be mitigated (a patient cannot change the data regarding another patient for example). During the second part the authentication issues and requirements are defined, trying to mitigated the attack's coming from the outside (how to prove someone is a legitimate user of the delivery system). The third part, instead, defines the requirements of a strong and easy to remember password, to be used when opening the compartments of the robot. Finally the fourth part asses how patients are identified and registered into the system and also treats a security issue that is not related to a cyber attack. Indeed it specifies how a patients will be deemed safe to use the system or when a caretaker must use the system for them.

Access control policy

In order to construct a control matrix, where access to each resource is defined for every stakeholder, an access control policy was defined. The access control policy captures the meaning of the intended high level policy by specifying who (subject) is trusted with which resource (object) to do what (allowed actions). Following are the requirements defined for the access control policy of MediGO.

• The pharmacist maintains a database containing the information about the elderly subscribed to the delivery system (with also the delivery dates and times).
• Doctors can add, remove and modify the information about the elderly subscribed to the system (but not the delivery dates and times).
• The elderly can read only the information about themselves.
• The elderly can modify the delivery times and dates regarding their deliveries.
• The elderly can read their compartment’s password when the delivery departs.
• The pharmacist reads and sets the compartment’s passwords for each delivery.
• The caretaker can read only the information about the elderly they look after.
• The caretaker can modify the delivery times and dates regarding the deliveries of the elderly they look after.
• The caretaker can read the compartment’s password when a delivery for the elderly they look after departs.

Role Based Access Control Matrix

The different high level policies can now be expressed in terms of rights that users within a certain role have. The role based access control matrix, indeed, gives a simple specification of the access control policy. In this matrix there is a row for each role and a column for each resource. This results in a field for each combination of a role and a resource. The rights that that the subject has on that resource, i.e. allowed actions, are filled in this field.

Role \ Resource	Elderly details	Password	Date and time delivery
Pharmacist	Read	Read/Write	Read
Doctor	Read/Write	No access	Read
Elderly	Read	Read	Read/Write
Caretaker	Read	Read	Read/Write

Defining the matrix is fundamental in trying to mitigate malicious or erroneous use of the delivery system by its users. Indeed the implementation will have to respect the matrix's entries, not allowing, for example, a patient to change the type of prescribed medicine without consulting with a doctor first. Furthermore in the matrix is also specified to which degree each action is permitted. Indeed a patient can see the password of only the compartment reserved for him, while a pharmacist can set and see the passwords of every compartment.

Authentication

In the second part of the security requirements we define the authentication requirements, so that an external attacker can not claim the identity of one of the patients.

We previously defined the access control policies with roles different users could take. However a role is just an example of a property (or attribute) of a user, to which we might link a right to. Using the concept of attribute, the NIST (The National Institute of Standards and Technology (NIST), a US federal institute) electronic authentication guide defines an identity as:

An identity is a set of attributes that uniquely describe a person within a given context.

Several preceding studies distinguish three types attributes, or authentication factors, that can uniquely identify an identity::

• Knowledge-based factors (something you know)
• Possession-based factors (something you have)
• Biometric-based factors (something you are)

Some studies also acknowledge a fourth type:

• Somewhere you are / someone you know

We then identify two types of authentications that make use of these authentication factors: single factor authentication and multi-factor authentication.

Single factor authentication

Examples of single factor authentication are possessing an ID card that by swipe technology authorizes access into a facility or the traditional user-password scheme. The latter has the following features:

• Easy to implement
• Requires no special equipment
• Easy to forget
• Can be susceptible to shoulder surfing
• Security based on password strength
• Lack of identity check
• Cost of support increases

However, regarding security, there are some issues with this the single factor authentication. There are a lot of rules and algorithms that can generate strong passwords, but this are generally very difficult to remember. In order to do so people write them down, which makes the system way less secure. Therefore we identified in multi-factor authentication, a better requirement for the authentication processes of MediGO.

Multi-factor authentication

Multi-factor authentication makes use of two or more of the factor categories (and not using multiple examples of the same factor). A well known example is inserting a credit card (something you own) and typing in the pin code (something you know). Another example that is used a lot (in E-banking or investment sectors) is the combination of a password (something you know) and a token (something you own). For our delivery system the patients, to open the compartments will have to authenticate themselves using two authentication factors.

Password

The delivery system will make use of a password to open the different compartments. An important requirement for the security of the system is that:

• The password should remain secret, and only known to the specific patient and the pharmacist.

In order to better specify this requirement is necessary to make use of the concept of entropy, which captures how hard a secret is to guess. If the entropy (expressed in the number of bits needed to represent the hidden information) is n then one needs on average half of 2ⁿ guesses to find the secret. Therefore a more specific password requirement is:

• Achieve an entropy where the attacker, if guessing, must try at least 50000 passwords to open the compartments and 100000 passwords to log in someone else's account within the database.

To combat weak passwords, furthermore, an extra requirement is:

• The password must be randomly generated.

Because the robot needs to check the identity of the users connecting to it, a list of unprotected passwords might have to be stored in. However this makes the robot an attractive target for an attacker, as gaining access to its memory will reveal all the passwords for each compartment. A commonly used solution to protect stored passwords is to only store the hashes of the passwords, not the passwords themselves. Hash functions produce a fixed size output for any length input and are one way (irreversible) and collision resistant (hard to find inputs that give the same output). When a claimant provides a password the robot hashes it and compares it with the hash value stored for the claimed identity. A well chosen hash is collision resistant and therefore this method is just as good as comparing the entry directly with the identity’s password. Therefore the last password requirement is:

• Save the hashes of the passwords in the database, rather than the unprotected passwords, for verification purposes.

Furthermore as specified in the previous section strong passwords are hard to remember. Because the system must be user friendly and target the elderly, a password that is hard to remember is an issue. The solution that we identified is to use shorter passwords but that can be used only one time, an OTP (one time password). This was even if an attacker manages to find out the password only a single delivery is compromised:

• Use a OTP for each delivery.

In order to use an OTP, however, the tool of the pharmacist must communicate with the elderly/caretaker's tool and send the password to the latter each time a delivery is executed. In order to prevent and protect the system from man in the middle attacks the following requirement was defined:

• Passwords must be encrypted by the pharmacist's tool before being sent and must be decrypted by the elderly/caretaker's tool once received to be used.

Classification of the elderly users

The first step in classifying the elderly is to identify them. Indeed while the previous section treated how the patients can authenticate themselves, here will first be treated how they will register into the system and therefore identify themselves. Furthermore it will be treated also according to which metric the elderly patients can be deemed safe to use the MediGO system independently or if they need assistance from a caretaker.

Identification

Because the elderly must first go to the doctor in order to get prescribed the medicine they must assume, it seemed fitting that the doctor would also register them into the delivery system if required. In order to register them into the system the doctor can then also check their identification and also check if they would be able to use it independently applying the metric we defined in the next subsection. However the doctor now needs also to have access to a "tool", like the pharmacist, that communicates with the database in order to add patients to it or remove them. We can then define the last sentence as a new requirement:

• R-D01 When a patient subscribes to the service, the doctor's tool must add the patient's details to the database.

Metric to identify independent users of the system

To develop a metric to identify which users can use the system independently we looked at three other famous metrics: MMSE score, CPS Score and the Netherlands care home codes.

The Mini-Mental State Exam (MMSE) is a brief test of cognitive impairment used widely to screen for dementia. The original test, developed by Folstein et al (1975), includes questions about orientation, attention, recall, and language. Galasko et al (1990) developed a shorter version of the test (Modified MMSE) that is as sensitive as the complete test. A score of 23 out of a possible 30 is recommended as the cut-off score for dementia (Folstein et al 1975).

The CPS scores range from 0 to 6, with 0 indicating intact cognitive function and 6 very severe impairment. The scores are below reported with their respective meaning.

• CPS=1 Borderline intact;
• CPS=2 Mild impairment;
• CPS=3 Moderate impairment;
• CPS=4 Moderately severe impairment;
• CPS=5 Severe impairment;
• CPS=6 Very severe impairment.

The Netherlands care home codes are established by a nationwide medication safety policy. They are defined in the following way:

• Code 1. Completely independent, takes care of everything on their own
• Code 2. Has the roll with medication in own management. Carers and/or pharmacy delivers roll weekly
• Code 3. The medication is given per separate time
• Code 4 The medication is given per separate time and carers make sure it is taken as well

The healthcare staff working at the care homes decides the code for each resident. People with cognitive problems usually have a code 3 or 4. With code 1 or 2, the user is responsible for taking their own medicine. Instead with code 3 or 4 the carer is.

To determine if a patient is or is not independent and cognitively capable enough to make use of the delivery service the GP will have to do a MMSE score test or an CPS score test. The GP will then check if the cognitive capacity is lower than 22 as MMSE or lower than 3 as CPS. If this is not the case a patient could show symptoms of dementia. Furthermore the GP needs to screen the patient to test if he or she falls within the code 1 or 2 (independence). If both test result in the required score, the patient will get personal access to the system. If both or only one of the tests doesn't result in the required score, the patient will still be able to use the system, but only if assisted by a caretaker, who will have access to the system. The caretaker needs to be home to accept the medicines of the delivery robot. Furthermore, in order to sustain the capacity of the service the GP will also prioritize the subscription to the system for patients with mobility problems and for patients that must strictly follow the social distance rules because of their health.

Physical security

Not only digitally, but also physically, the MediGO robot could be attacked on its way to or from a customer. The compartments that contain the medication should be locked secure enough, so that it is made sure that no violations can occur, or that attempts at least will be noticed as soon as possible.

Locks (mainly for buildings and houses, but also for vaults and other products) can get a SKG certification . This certification is given to the lock if it withstands multiple tests and attacks. The Dutch government recommends people to secure their doors and windows with locks with an SKG logo, which results in 90% less chance of burglary.

• Cracking a lock with SKG* (one star) should take a burglar at least three minutes with simple tools (screwdriver, crowbar) and less if he has more advanced tools.
• A SKG** (two stars) lock can withstand at least three minutes if the attacker has advanced tools.
• A SKG*** (three stars) lock is the best and can stop a burglar with heavy tools for at least five minutes.

Because the products that the MediGO robots transport are rather sensitive and expensive, the compartments should be as secure as possible. The locks should be at least SKG**, such that someone can intervene within three minutes. In addition, an alarm should sound when the robot senses that someone tries to open it or pick it up to take it with them. The navigation system of the robot should be able to sense when it is too far off route, so that the responsible company will get a notification and can prevent products from getting stolen. Also, the materials of the robot itself should be strong enough to withstand attempts to break it.

System Overview

In this section an overview of the system at this stage of the development processes is given. This is done by means of use case diagrams and by describing a scenario in which examples of different stakeholders of MediGO are described while interacting with the system.

Use case diagrams

The following use case diagram captures the main use cases of the system and the different actors that are involved in each of them.

Use case diagram of the delivery system

The previous use case diagram is shown here again, but this time the different functionalities are grouped depending on which "tool" offers them.

Use case diagram where the subsystems of the delivery system are highlighted inside rectangular boxes.

Personas and Scenario

To illustrate the needs of the envisioned user group, the following personas were created:

• David and Maria, an elderly couple
• Tom, a home caregiver
• Betty, an old lady
• Samantha, a pharmacist

Below, these personas are combined in a scenario that gives an overview of the system as a whole.

David and Maria

David (76) and Maria (73) are married for almost 50 years and are living together peacefully in their terraced house in a village in the Netherlands. David has some trouble with his heart, for which he needs medication every day and Maria has very painful rheumatism for which she has to inject medicine once every few weeks. They both have a smartphone and luckily, their children and grandchildren helped them understand how to use it. When they want to install a new app, they need to ask for help, but once the app is installed and explained they know how to use it pretty well. David and Maria take a stroll every day to keep active, but during the COVID-19 outbreak, they are more careful when it comes to going outside and seeing other people, and they sometimes find it difficult to enter shops or pharmacies as they are relatively crowded.

Tom

Tom is 36 years old. He works in home care and really likes his job. It really pleases him to know that he can help these people stay at home a bit longer by regularly visiting them and helping them with whatever they need. For some people, he only needs to pick up medication (because they are not mobile enough themselves anymore), but after that, they can use them and do everything else on their own. This takes a lot of time, which he prefers to spend with people that really need his assistance with cleaning, taking medication, washing, or just having a nice conversation.

Betty

90 year old Betty still lives at home. Her husband died 12 years ago, but she refuses to leave their home to go to a care home. She’s got too many memories here. In the last few years, her family really saw her health declining. She needs more and more medicine and has dementia on top of that, so she also regularly forgets to take them. That is why they applied for home care. Now, someone comes to visit Betty every day to check on her and help her with tasks that she cannot do herself anymore. The home care helps with cleaning, picks up medication from the pharmacy, helps with managing Betty’s agenda, makes sure she takes her pill on time and whatever she needs besides that.

Samantha

Samantha (31) works in a pharmacy in Eindhoven, she has worked there for 5 years and loves to interact with her regular customers, who are primarily elderly patients. During the Covid-19 outbreak Samantha is worried about how some of these patients are collecting their medication, as many of them have serious medical conditions. Sometimes family members come in to collect it but some elderly patients do not have any family to help them with this task and so they come to the pharmacy themselves. This is particularly worrying because recently the pharmacies have been extremely full as people have begun to panic and buy more medication than usual, and it is difficult to maintain social distance within the pharmacy, leaving the elderly at a higher risk for infection. Samantha believes that the pharmacies should be decongested, both for her and her colleagues safety and her patients. She is willing to try out new techniques to make this possible.

Scenario

In the pharmacy where Samantha works the robot delivery service is used for some time now. At the beginning of her day, Samantha checks the planned deliveries and fills the compartments with the right medication. The information in the database tells her exactly which medication goes in which compartment, such that each customer get the right medication. The best route is also already calculated, so Samantha and her colleagues have nothing to worry about. When all the compartments for the first delivery are filled, she sends robot on its way, so she has plenty of time for other clients in the pharmacy.

David and Maria already received a notification with a reminder that the robot would visit them today with their medicines. They indicated their prefered delivery time slot themselves when they placed the order and were still able to change this up to 24 hours in advance. Today, the day of the delivery, they are able to check the expected time of arrival in more detail, so that they know at what time they have to make sure to be home. When the robot arrives at David and Maria's house, they get another notification.

Now that the robot is here, they open the door and the robot says hello. They enter the code, but it turns out to be wrong. A cross appears on the screen and the robot tells them that they have to try again. They enter it again, and this time it is correct. The correct door automatically opens and they get their medication out. The robot wishes them a good day and leaves. David and Maria have some questions about one specific medicine, but they are able to check the details on the spot, which they really appreciate about this system.

Tom is going to Betty to help her with her delivery of today. With the track and trace feature of the system, he is sure that he is there on time. When robot arrives, he gets message, opens the door, enters the code, and gets Betty's medicines out of the robot. Since Betty cannot do that herself anymore, Tom is responsible for everything that has to do with her medication and the robot delivery service. He is glad that not just everyone can use this service, because he knows the danger of the effects that that could have. He helps Betty take her medication for today and checks if the next delivery is already planned.

Meanwhile, the robot is on its way back to the pharmacy, ready for some more deliveries later this day. Passers-by all recognize the robot, because of its appearence and features.

High Level Specification

The specification analysis phase of the project is divided in two sections: high level specification and low level specification. This sections will treat the high level specification. In the requirements analysis the concept of "tool" was used to describe the system at the healthcare staff end (pharmacists and doctors) and at the user end (caretakers and elderly). Here that concept will be specified, detailing which technology or system will have to be implemented. Furthermore it will be specified which type of robot will perform the deliveries. We will be able then to state how the multi-factor authorization method will be implemented and also which tool will be used to create the database.

Database

Currently, the database used by pharmacists, including all information about every medicine, is called the G-standard. The drugs list, including licensed, unlicensed medicines and medical devices that are dispensed in the pharmacies, are obtained in this database. All pharmacy information systems are able to integrate this database. For the use of their information systems, a variety of systems is currently in use. In general, the only patient information dispensed is the type of medication and its amount and repetitions. An example of a system like this is the care system ‘Apro’.

The MediGO database system can be created in MySQL, for example, and be hosted where the G-standard database is hosted now. In the low level specifications the relational tables that are part of the database design will be presented.

The MediGO database will replace the G-standard database as it integrates most of its current functionalities, but also provides new ones to three different parties (patient, doctor/hospital and pharmacist), with particular care to the patient. Indeed the G-standard database cannot be accessed independently by the patient and is not implemented to facilitate the delivery of medicines.

Doctor and Pharmacist application

Currently every GP has a computer on the office's desk from where prescriptions can be filled and patients data can be checked on previous records. Most pharmacists also have a computer in the pharmacy from where they can retrieve prescriptions or check medicines information. Therefore because doctors and pharmacist already posses a computer at work, we decided that the MediGO tool at their end should be a desktop application. The application will be implemented in Java and offer the choice to log in as a pharmacist or a doctor. As stated in the requirements the program will be communicating with the database, and depending on who logged in it will permit or not modifications of the patients data.

Use case diagram of the delivery system

User application

Deciding the user end application required more effort than the healthcare staff end did. Indeed while caretakers would prefer to work with a smartphone applications, during the interviews some elderly expressed concerns with using the technology. However we had also to take into account that following our security requirements we needed to implement a two factor authentication method and use a one time password (OTP). Therefore we had to find a compromise where both user groups were satisfied and the security requirements were not compromised. We then developed 4 possible solutions and presented these solutions to the elderly participants, that we interviewed while collecting the users needs, in order to decide which solution was the best. The first solution is composed by a simple security token that makes use a built-in screen to display the generated authentication data. The second solution uses a complex security token that would have a bigger screen compared to the previous token and offer more functionalities rather than just display the authentication data. The third solution makes use of SMS to communicate the password to the user. The final solution is by using a mobile application. In the following table all the solutions are compared against the main functionalities that were identified in the requirements phase and that were reported on the use case diagram.

• 

  Simple Token

• 

  Complex Token

Use case		Simple security token (and website)		Complex security token		SMS		Mobile application
Get the password		The user presses the button on the device and on the screen the password appears.		The user selects the option “Show password” and the password appears.		The day before the delivery, the user receives an SMS with a one time password. They have also a password (or birth date) they use every time in addition to the OTP.		The user selects the option “Show password” and the password appears.
Notify when the robot is outside the door		The device has a small speaker which makes an alert when the robot is at the door (it can also make an alert 30 minutes before the arrival).		The device has a small speaker. It makes an alert when the robot is outside the door.		The user receives an SMS when the robot has arrived.		The app will display a notification.
Check future and current delivery times and dates		This would be done through calling the pharmacist or using a website that also has a tracking option.		The user selects the option “Show delivery dates” and the next delivery date shows on screen.		The user receives an SMS when the robot is one hour away. For future deliveries, the user get messaged when it is time to place a new order. To have an overview of future deliveries, the user will have to call the pharmacy.		The user selects the option “Show delivery dates” and the next delivery dates shows on screen.
Change future delivery times and dates		This would be done through calling the pharmacist or using a website, the user would select a new delivery date and time from the website or discuss with the pharmacist which dates and times are available and the pharmacist would change this information for them.		The user selects the option “Set delivery dates” and a calendar shows on screen. The user goes through the dates and selects the one that it wants. Then different time slots show on screen and the user then selects the one that it wants.		When a new delivery is almost needed (a few days / a week before), the user receives an SMS with the request if he/she wants to call the pharmacy to indicate what is their preferred delivery day and time (morning or afternoon).		The user selects the option “Set delivery dates” and a calendar shows on screen. The user goes through the dates and selects the one that it wants. Then different time slots show on screen and the user then selects the one that it wants.

The different options were therefore presented to the elderly participants of the interviews. They were asked to rate each option from 1 (least liked) to 10 (most liked). We decided to use a relatively big scale in order to better capture how the users were feeling about each options. The results are presented in the table below.

Users	Simple security token (and website)	Complex security token	SMS	Mobile application
Participant 1	5	7	2	9
Participant 2	5	7	6	8
Participant 3	8	5	7	5
Participant 4	6	8	9	10
Participant 5	6	8	7	9
Participant 6	8	7	9	6
Participant 7	8	9	7	6
Total	46	51	47	53

In the following table the responses from the costumers were ranked from most liked option, as a 1, to least liked option, as a 4.

Users	Simple security token (and website)	Complex security token	SMS	Mobile application
Participant 1	3	2	4	1
Participant 2	4	2	3	1
Participant 3	1	3	2	3
Participant 4	4	3	2	1
Participant 5	4	2	3	1
Participant 6	2	3	1	4
Participant 7	2	1	3	4
Total number 1	1	1	1	4
Total number 2	2	3	2	0
Total number 3	1	3	3	1
Total number 4	3	0	1	2

Maybe surprisingly the option that most best received is the mobile application one. The finding can be explained by the fact that the elderly feels intimidated by technology even without knowing what the technology actually works. However when the functionalities were explained, their simplicity compared to the other possibilities, might have made a few of the interviewees start appreciating the mobile application option more. To further support the claim that the elderly is growing supportive of smartphones and applications is the fact that in the Netherlands more than 50% of the elderly owns a smartphone.

The app will be developed in Android studio for Android phones. This was selected as the best options given that Android Studio well integrates Java. Like the healthcare staff application also the user app will offer the possibility to login to two different "roles" of users: elderly or caretakers.

Use case diagram of the delivery system

Compartment's lock system

During the requirement phase of the project, the authentication method for the compartment's lock system was defined to be a multi-factor one and that it would make use of a OTP. In order to achieve the former requirement the system will identify the users by a knowledge-based factor and a possession-based factor. The knowledge based factor will be composed by the credential (username and password) the user needs to know to log in the application. The possession-based factor will be composed by the actual app which in this case will work like a security token visualizing a password for the delivery.

The second requirement for the lock system was to make use of an OTP. To do that the pharmacist needs to encrypt the password before sending it to the user, which in turns needs to decrypt the password. That will be achieved by implementing an asymmetric cryptographic algorithm. In such algorithm a public key (that will be known to the pharmacist) will be used to encrypt the password and a private key (that will be known to the user) will be used to decrypt the password. The asymmetric algorithm that will be used is RSA.

The robot will need to store the hashes of the passwords as specified in the requirements. The hash function that will be used will be selected from the SHA-2 group.

Compartment system OTP encryption and decryption scheme

Robot

A sidewalk robot was chosen as the best candidate for the MediGO delivery system. The regulations for sidewalk robots are much more lenient than for drones, especially in urban areas. In addition to this, this type of vehicle has a higher carrying capacity than a drone and therefore is the most suitable solution.

The GoDrone web service is an iterative web map used by the Dutch government to illustrate where it is permitted to fly a drone. Drones are not allowed to fly, or are subject to very restrictive regulations, in areas that are marked in red. As previously stated regulations on sidewalk robots are more lenient than drones in urban areas. It is possible to check on GoDrone that most, if not all, major urban areas are marked in red, making the use of drone impossible. Below are reported the areas of Amsterdam and Rotterdam as an example.

Amsterdam GoDrone area

Rotterdam GoDrone area

System overview

In this section an overview of the system at this stage of the development processes is given. This is done by means scheme of the complete delivery system and by a sequence diagram.

Overview of MediGO delivery system

The sequence diagram shows a high level view on how the different parts of the system communicate with each other. Here is depicted a sequence that starts from a patient going to the doctor and subscribing to the system, setting the delivery dates and picking up the delivery.

Overview of MediGO delivery system communication with a sequence diagram

Low Level Specifications

This sections will treat the low level specification. It will be specified how data is stored in the database. In the high level specification it was defined that the healthcare staff would have a desktop app. Now it will be specified which activities will this app perform. For the user side it was decided to develop an Android app. A design of the user interface will developed and presented for feedback to a potential user. For the robot, in the high level specification section, was simply decided that a sidewalk robot would be developed. Here, instead, the design of the robot will be presented. Finally in this section a more detailed analysis on how the compartment's password is handled by the different components of the system will be performed.

Database

To illustrate how the database will store the different data, the following relational tables have been designed. A relational table is an ordered set of columns. In this section each table will be designed so that the data can be queried by the applications to retrieve the desired one. The rows represent a tuple of data, and the ones provided are examples of possible costumers, pharmacist or doctors.

The first table stores the data belonging to the costumers of the service. The patient ID is a primary key of the relation. It will have to be set up during the subscription to the system.

Patient ID		First Name		Last Name		Username		Password (Hash)		Medicine name		Next delivery date		Past deliveries
03451		Barend		de Jong		barend.dejong		DF5675T		Amoxicillin		14/07/2020 10.00 - 14.00		1096
02566		Karen		Smit		karen.smit		3R60HB3		Clobetasol, Digoxin		21/07/2020 17.00 - 21.00		1445, 1232

The second table stores the data belonging to the pharmacists. The pharmacist ID is a primary key of the relation. It will have to be set up every time a pharmacist is added to the system.

Pharmacist ID		First Name		Last Name		Username		Password (Hash)		Pharmacy		Delivery performed
25903		Vincent		Hals		vincent.hals		DDB675B		Merret		1445, 1232, 1096

The third table stores the data belonging to the deliveries. The delivery ID will uniquely identify a delivery and can be used to reference the delivery data from the other tables. It has to be set up when a delivery is performed.

Delivery ID		Delivery date		Patient ID		Pharmacist ID		Medicine name
1445		10/06/2020 10.00 - 14.00		02566		25903		Clobetasol
1232		01/06/2020 17.00 - 21.00		03451		25903		Digoxin
1096		28/05/2020 10.00 - 14.00		02566		25903		Amoxicillin

The fourth table stores the data belonging to the doctors. The doctor ID will be the primary key of the relation.

Doctor ID		First Name		Last Name		Username		Password (Hash)
30987		Dirk		Janssen		dirk.janssen		RT7890T

The fifth table stores the data belonging to the medicines. The medicine's name will uniquely identify a medicine.

Medicine name		Description
Clobetasol		Clobetasol propionate is a medicine that's used on the skin to treat swelling, itching and irritation.
Amoxicillin		Amoxicillin is an antibiotic. It's used to treat bacterial infections, such as chest infections (including pneumonia), dental abscesses and urinary tract infections (UTIs).
Digoxin		It’s used to control some heart problems, such as irregular heartbeats (arrhythmias) including atrial fibrillation.

It can be noticed that some of the relations have an ID attribute even if both a username and a password attribute are present. Indeed the latter once would be sufficient to uniquely identify a row, however an ID attribute has been added in order to have a simpler attribute to query when certain data is needed.

Healthcare staff application

As specified in the high level requirements the healthcare staff application will offer the possibility to login as a doctor or a pharmacist. In order to further specify the system is necessary to distinguish between two types of pharmacists. The first type is simply an employ of the pharmacy that will perform the deliveries. The second type is the manager of the pharmacy. Indeed there must be someone responsible for a pharmacy registered in the system. The responsible pharmacist will therefore manage the accounts associated to a particular pharmacy. In this sense it can remove or add pharmacist profiles depending on which pharmacist are employed at the current time. To permit this actions the relational table of the pharmacist, stored in the database, should contain one more attribute pointing at the ID of the pharmacist responsible for the particular pharmacy where the profile is employed at. For a responsible pharmacist this attribute will point at its own ID.

It is now possible to construct an activity diagram showing which actions the healthcare staff application goes through when a delivery is performed. In the diagram belowed the actions are highlighted in three different colors. Red identifies actions that can be performed when a doctor is logged in, green identifies actions that can be performed when a responsible pharmacist is logged in and yellow identifies actions that can be performed when a normal pharmacist is logged in. In the diagram there are two initial nodes symbolizing a doctor adding a patient (therefore generating tokens into the action "add patient") and a responsible pharmacist adding a pharmacist (therefore generating tokens into the action "add pharmacist"). When a pharmacist then fills and locks a compartment, he/she can decided to fill a new compartment for a different patient or send the robot to perform the delivery.

Activity diagram of the healthcare staff application

User application

To interact with the system, the user has to download an application on their smartphone. Depending on how independent and cognitively well the user is, the user him- or herself can download this app, or a caregiver can be responsible for all interaction with the system. The app can be used to place new orders, to change the date of existing orders, to check the expected time of arrival of the current delivery, to get an overview of all medications, and maybe most importantly, to receive a code to open the correct compartment of the robot.

Literature

The literature on how to develop an app for elderly people was consulted. The following important results were found:

• Text: use a font size between 12 and 14 pt; use readable fonts, such as Sans Serif fonts (e.g.: Arial, Verdana); use a single line spacing; avoid bold, underlining or italics; avoid specific words (e.g. “nickname”, “FAQ”); repeat contents, avoiding not key information; avoid capital letters, acronyms, and abbreviations; avoid scroll text; use calibration systems (e.g.: word prediction, swabbing and automatic correction).
• Graphic aspects: use a sharp contrast between color background and text (in detail: use dark writing on clear background); use a uniform texture; adapt object and button size/dimension; use a border for pop-ups; use clear and concretes graphic elements, avoiding the ones far from reality; use metaphors close to everyday life; create coherent interfaces; design rich UI; offer an overview of the elements of the interface; avoid moving UI elements; use multi-layered interfaces; develop the applications in landscape (horizontal) view rather than portrait (vertical); maintain a stable landscape; use a combination of labelling and icons; adequately separate the different buttons; use explicit buttons rather than slider or cursor buttons.
• Colours: prefer complementary colours in order to use a sharp contrast (e.g.: orange and blue, white and black); use few colours; avoid pastel colours; avoid blinding light.
• Sounds: avoid sounds too quiet and blunted.
• Command input: use single touch rather than multi-touch; use a voice interface; design the interaction process with a specific gesture-based method, establish a “hot area” around the buttons; use tactile input joined with haptic input.
• Output: provide instant feedback (e.g.: after touching an icon, change colour); use multi-sensorial feedbacks (e.g.: tactile feedbacks joined with/rather than sounds or haptic output).
• Basic features: combine touch-based and slide gesture interaction; use adaptable/customizable setting/interfaces (customizable fonts, icons, combination colours, button size, windows size, contrast level, sound level, on/off sounds, vibration/haptic effects); use social features; guide users with tutorials, frequent feedbacks, introductory videos on how use the application and the related technologies included into the device; use “help systems” (e.g.: frequently asked questions, send a message with a question); use a stable menu interface, with a not deep information architecture; focus application features and tasks; get user to set technologies into application (e.g.: GPS, etc.).

Functionality

In the requirement analysis, the general functions that the application has to contain are listed. When applying for the service with the GP, the user needs to indicate who will be the one responsible for the app. This can be the user him/herself or a caregiver. It is also possible to have multiple accounts for one user (in case the user and a caregiver both want the app), but when registering, one person should be designated to be the main account holder. This person receives the credentials to make every decision and change and the other person gets the credentials to only view. Assuming that the user and his/her caregiver know each other, they are responsible to come to agreements about delivery times etc themselves. After installation of the app, the person needs to indicate if he/she is a caregiver and, in that case, there is an option to pair multiple accounts to the app, so that switching between them is easy.

Every user (elderly or caregiver) who gets an account, receives a letter from the pharmacy with a username and a password. These can later both be changed in the app if wanted. When logging in for the first time, the app asks the user to choose a 5-digit code that he/she has to enter every time the app is opened. This is because the app contains sensitive information, like the medication the user takes. After choosing this code, the app asks if the user wants to set this code as his/her account password as well, since it might be easier to remember for the user if the two are the same. As extra security, the login code also has to be entered every time the user requests the code for opening the robot to minimize the chances that the wrong person gets to the medication locker.

The application has a main menu with the following options:

• Get code: This button is only available on a delivery day. When pressed, the app shows the code that is needed to open the right medication locker of the robot.
• Follow my delivery: This button is also only available on a delivery day. This feature shows the expected delivery time and the delivery process.
• Delivery calendar: Here, an overview of the planned deliveries can be found. The user can plan new deliveries or change the date or time slot of an existing one.
• Overview medications: This contains a list with all medications the user takes with the amount and times he/she needs to take them.
• Profile: Here, the user can find the details about his/her account (name, username, password) and is able to change them.
• Help: This is a question mark symbol that, when pressed, shows a quick tutorial with an explanation of all the apps features and functions.

Testing of draft design

Based on the findings in the literature, combined with the desired features and functions, the following graphic user interface was designed.

This draft was printed on paper and tested with a 67 year old woman (who has also been interviewed in previous steps and corresponds to Participant 3 in the table present in high level specification where the scores for each user end option were reported). Although she did not indicate the app as her preferred tool for this project (compared to the other three options we discussed with all interviewees), she really liked how it looked and thought it was quite easy and intuitive. After seeing the design, she said that we might have changed her mind and prefers this app over the other options after all. She usually does not like challenging, new technologies, but she noticed that this app is really easy to understand and use. She liked the option to get a tutorial after the first login and all functions, buttons and actions make sense to her. However, in the second screen (choosing between user and caregiver), the icons that we used now are somewhat confusing, since one is male and the other is female. But this was just a minor comment. Another aspect we might need to change (again, just a small detail) is the home screen on days that there is no delivery. She liked the fact that there is a message that tells her that there is no delivery and thus no code today. She can imagine that she would mistake the date and might expect a delivery on a day that there is actually none planned, so in that case it is nice to see that and to be able to check the delivery calendar again. However, the second grey button might be unnecessary or even make it confusing. "Why have buttons that I am not allowed to press anyways? A single explanation is enough, the second only causes confusion." Another thing she had some comments about was the fact that she only had to log in once (and could not even log out in the current interface). Especially when the overview of all medications used can be found in this app, she expected at least some kind of password login every time you would open the app. All apps with this kind of sensitive or important information have it (banking app, health insurance app, digiD, etc), so she would really want and expect it for this one as well. It might even be the case, that there is one extra check moment every time the user presses the "get code" button, comparable to the extra code when transferring money in a banking app. Besides this, she did not really have a lot of complaints. She thinks that the help function could look like a quick tutorial of every screen in the app with a small explanation of all the buttons. And for the medication overview, she thinks it could maybe look a bit like a checklist that a lot of patients already receive from the pharmacy now (she will probably send an example picture as soon as she can get hold of one). This would contain a list of all the medicines a user takes, with per pill an explanation of the function and an overview of when to take them (and how many at every exact moment). She knows this checklist is often used in combination with a baxterroll.

Placing and adjusting orders

For every user, the medicines he/she needs to take can be found in the database. Per medicine, it also says how often, when, and how much should be taken. To know how many times a certain medicine should be delivered in total, a calculation is performed in the system. This amount of deliveries depends on the amount of medicine that can be delivered in one delivery and the duration of the total cure. The system combines the knowledge about all different medications a user needs for a known period of time and decides when the user will need a new delivery. Within a specified period of a few days, the user can then indicate their prefered day and time slot for the actual delivery. Note that the last day of this period is still a few days before a new box / bottle of medication is actually needed, to prevent dangerous situations if a certain medication is not delivered in time. Also, note that the first day of this period is specified as well, in order to prevent people from ordering everything at once, which can lead to an (intentional or accidental) overdose.

In case an order is not yet placed a week before the "delivery period", the app sends a push notification to remind the user to do this. Of course, the user can also plan it in advance, so in that case a notification is not needed. If the order is still not placed two days before, the app sends another push notification. The user receives another one one day before, and every day during the specified period. If there are only three possible days left, a notification gets sent to the pharmacy. The pharmacy will then call the user to plan a delivery and ask the reason that the user was not able to plan one him-/herself. If there appears to be a problem with the app or the user, a reconsideration can be made if this user is still allowed to use the system, or that he/she will need to appoint a caregiver to help him/her. If there is a logical reason that the user did not place an order and both parties are convinced that it was a single occurance, the user can keep using the system. The pharmacist can point out the help function in the app if the user seems to need a reminder and explanation of the functions.

Compartment's lock system

As stated in the high level specification sections the lock system uses a OTP password that is encrypted with a RSA public key. In order to do that it must be specified how the key pair is generated. When the user subscribes to the system he/she will receive the credentials to log in the app. During the first log in the app will generate a RSA key pair and store the public key into the database. The relational table of the patients must therefore have a further attribute which stores the associated public key. The RSA private key will remain stored into the smartphone application. At this point when the pharmacist retrieves the patient's data will also retrieve the RSA public key. It can then use this key to encrypt a number sequence and send the encrypted sequence to the user application. The latter will then decrypt the sequence and display the numbers that must be pressed on the robot's keyboard. As stated in the high level section the pharmacist app will also hash the non encrypted password and send it to the robot, so that the latter can associate a compartment to a password. When the patient does actually digit the number sequence from the robot's keyboard, the robot will hash the received password and confront it with the one stored into memory. If the two hashes match then the robot will open the compartment. A sequence diagram is used to illustrate the communication of the different system components parts involved into the compartment's lock system.

Sequence diagram compartment's lock system

Robot

Appearance

Type & size robot

In the high level specification we decided that we would implement a driving robot. In this section we will specify its characteristics. The driving robot with have six wheels (three on both sides). We have chosen for 6 wheels, since this makes movement at different edges more feasible. This technique has been used as well in other delivery robots. For the size of the robot, different things have been taken into consideration. An experiment took place in which the attitude towards robots with different heights was measured. They used robots that all had the same width and length and were respectively 0.6m, 1.2m and 1.8m tall. The robots were box shaped (so findings could be different for humanoids, but that is irrelevant for our delivery robot) and approached subjects from 3m at a maximum speed of 0.4 m/s. The participants also filled in some questionnaires. The study and the questionnaires showed that the subjects felt most anxious with the 1.8m robot, but some also were somewhat anxious with the 0.6m robot. 1.2m turns out to be the best height for a box-shaped, driving robot. The robot should also not be too wide, since it has to fit through doors. The standard width of a door in Europe is 63, 68, 73, 78, 83, 88, or 93 cm so the robot should be at most 60cm wide. It also has to be able to move easily and make smooth turns, so the length should not be too long. In addition, between 31,7% and 32,6% of the population lived in an apartment/flat in the Netherlands in 2015 , so the robot might also need to be able to fit in an elevator. According to regulations of the Dutch government, an elevator should be at least 1.05m by 1.35m . The robot will have a length of 1.20m. This is also based on the fact that the robot will be still in balance and can carry enough medicines. Furthermore, it should be big and heavy enough, such that people will not be able to vandalize it or take it with them.

Color, lights and shapes

The color of the MediGO robot is a combination of white and blue. This has to do with the fact that white is associated with the medical world, since it symbols ‘healing’. We have chosen to use in our logo blue as well, since this color stands for loyalty and calmness. We want the elderly to be kept calm and not scared with the robot and we want the robot to be loyal; you can count on it. A cross is used since this is associated with the medical world.

Anthropomorphism

Furthermore, the car will have two lights at the back and two lights at the front. This decision has is already explained in the ethics section.

Size and amount medication lockers

The compartments in the robot should be big enough to be able to transport almost all kinds of medication to the user. A pharmacist said that it is difficult to decide what size the compartments should be, because it really differs per person. Some people only need a small box, but some need an entire bag full. One kind of medication take-out machines, used by a lot of pharmacies, has containers with sizes 130x100x175mm, 150x100x275mm and 250x140x275mm, checked by the pharmacist. Multiple pharmacies that use this machine tells their customers that they can't use the machine if the products would not fit in a shoebox .

Our delivery robot has compartments on both sides. Since the total width is 60 cm, the compartments can be a maximum of 27cm long (to leave some space to enclose them). However, to maximize the capacity, we considered as well the minimal delivery. If 3 standard medical packages are put on each other, they will still fit in our minimum compartment: 10x11x27. We therefore decided to have the size of the compartments as follow: (width x height x depth): 20x22x27cm, 20x10x27cm, 10x11x27cm, so all kinds of delivery sizes can be done. The spread in deviation of the 3 is chosen by the fact that multiple pharmacists have told us about the deviation in order size, but it is also really varying per day.

The decision is made to use drawers (and not stationary lockers with a door to open them). This is because it is easier to retrieve products from above than to reach all the way in the robot. Especially for elderly who are not that flexible anymore and might have trouble bending down. It is important to note that these drawers are attached to the robot and cannot be completely taken out of it to prevent them from getting stolen or forgotten to put back in. In the lockers, the medication will be delivered just how the user is used to. If the user only has a few and usually gets them at the pharmacy in seperate boxes, the locker will contain these boxes. If the user is already used to (or prefers) a baxterrol, because he/she has a lot of different pills to take at specific moments, the locker will contain this baxterrol.

Side view (right) of MediGO robot

Inside view (right) of MediGO robot

Side view (left) of MediGO robot

Top and front view of MediGO robot

Functionality

Lock system

The user can enter the code that he/she received in the app on the keyboard on top of the robot. The keyboard consists of the numbers 0 to 10, a red "backspace" (if the user wants to remove the last digit) and a green "enter" to submit the code. The system gives feedback by showing the numbers that the user types on an lcd. When the code is correct, the word "correct" is shown and the robot says this as well. The locker will light up and open (so that the user does not have to touch the door) and the user can get the drawer out of the robot. (*See section Communication). If the code is not correct, the screen shows the word "incorrect" and the robot tells the user this as well. In addition, when the code is incorrect three times in a row, the robot tells the user to call the pharmacy and shows the phone number on the screen (*See section Communication).

Error conditions

It is possible that the interaction between the robot and the user is not optimal. Things can happen that result in the robot being left behind or unanswered when the action sequence is not completed yet. The robot needs a way to respond to these situations, to minimize potential problems.

First of all, it is possible that the door does not get opened when the robot has arrived. This can mean that the user did not see the notification on their phone, that the user is not home, or that he/she is not capable of opening the door for another reason. The first action the robot takes, is to send another notification to the app after 30 seconds, which will hopefully be seen by the user in time. In the app, the user gets the option to indicate that he/she is not home, so that the robot knows it can leave. If, after the second notification, the user still does not open the door within a minute, a request gets sent to the pharmacy to call the user. The pharmacist can check if everything is okay and ask about the reason the door does not get opened. It is possible that the door gets opened after this, which means nothing needs to be done and the normal action sequence can continue. It is also possible that the user is indeed not home, in which case the pharmacist lets the robot know it can leave. The last possibility is that the user also does not answer the phone, which can mean something is seriously wrong. The pharmacist will let the robot know it can leave and call the emergency contact of the user. This person can check on the user and take action accordingly.

The second problem that can occur is that the user does not enter a code to open his/her locker after the robot asked for this. The robot can ask the user to check the app again for the code, but if there is still no interaction within 10 seconds, the conclusion can be drawn that something goes wrong either with the app or with the users understanding of the system. The robot should then suggest that the user calls the pharmacy. The pharmacist can ask the user what went wrong exactly and help accordingly. This can mean help them with understanding and using the app, or give them the code verbally for this one time and figure out a solution for future deliveries.

Another problem can be that the user did manage to open the locker, but then leaves the robot (for whatever reason). If the robot does not have a camera, or if it cannot use it to identify people because of privacy reasons, the only way it can sense that the user left is by noticing that the drawer does not get closed. This can have three different causes: The user simply forgot to close the drawer after taking the medication out, the user got distracted and forgot the robot completely (with the medicines still inside), or something is seriously wrong (the user fell, had a heart attack, had a seizure, etc). If nothing happens with the robot for 30 seconds, the robot will send a notification to the app that tells the user that the robot is still outside. It will also tell the user that the locker should be closed (in case the user is within sound reach). If the locker gets closed then, the robot knows the actions are all completed and leaves. If nothing happens for another 30 seconds, the pharmacy will call the user. It is possible that the user just forgot and did not look at their phone. In that case, the locker gets closed and the robot can leave. If the phone is not answered, the emergency contact will be called and he/she will be responsible to check on the user and take the right action. If the robot does have a camera, it can perform these actions when it sees that the person left (instead of only when the drawer is not closed).

In all cases, if a delivery has not taken place or was not completed, the user has to plan a new delivery as soon as possible in the app.

Communication: Speech & Lights

We have chosen to use speech and lights as an extra form of communication. The speaker will be placed into the proposed mouth of the car, used to perform basic chat functions and the lights, functioning as eyes at the front, will have to move and flickr according to the volume of speech.

We do not want the robot to chat by speech recognition, since this will be too human like. However, we want it to perform a basic chat. Underneath you will find the basic sentences it needs to perform:

>Hello, I am here to deliver your medicines<
>Please get your code in your app and type the code onto the keypad attached on top of me<
Nothing happens for 10 seconds
>Please get your code in your app and type the code onto the keypad attached on top of me<
Nothing happens for 10 seconds
>Please call you pharmacy to see if they can help you. The phone number can be found on the screen.<
>If you enter the code, press a green mark if you want your delivery<
The code is typed in
The code is correct, the locker will light up via a LED.
>Correct, your medicines are now available, please pick the drawer that lighted up and push it back if you have taken your medicines out.<
OR
The code is incorrect
>The code is incorrect, please try again and make use of the red cross button if you accidentally typed in a wrong digital.<
The code is incorrect three times in a row
>You've entered the wrong code three times. Please call your pharmacy to get a new code to open your locker. The phone number can be found on the screen.<
The medicine box does not get closed for 30 seconds
>The locker is still open. Please close you medicine locker.<
The medicine box is pushed back
>Well done, enjoy your day and see you next time<

Planning & time scheduling optimization

The vehicle routing problem is studied a lot by different researchers. Usually, it is represented by weighted simple graph. The nodes are customers and the arcs the shortest paths computed according to a single criterion (like traveling cost, distance or traveling time). An alternative approach exists, which is multigraph representation . This approach takes multiple attributes into account and can thus also plan the optimal route with operational constraints. A popular example of this is the Vehicle Routing Problem with Time Windows (VRPTW). Here, customer requests to deliver within a specific time window are satisfied and still the optimal route is found. This is, for example, really important with perishable products. Some research is also done into path planning with Heterogeneous Multirobot Teams already. For our delivery robots, the multigraph representation seems to be a good approach. Users need to be able to indicate a prefered time window (just like with DHL/PostNL and other delivery services now), but it is not feasible to guarantee that delivery is at the exact same time every time. Of course the window can be indicated long before the actual delivery, so if it is a regular customer, this window can be the same every time.

Implementation

Here we will describe the final implemented product consisting of the Database, healthcare application, user application and the prototype of the robot compartment lock system. For a more detailed overview of the whole MediGO system this video can be referred to: https://youtu.be/DkQm9wYwZvk

The code for the User Application can be found here: https://github.com/DGillam/MediGOUSER

The code for the Healthcare Application can be found here: https://github.com/DGillam/MediGOHEALTHCARE

The code for the prototype lock system can be found here: https://github.com/Lucia2is50/Arduino_group5_Robots_Everywhere

Database

Firebase company's logo

The tool selected to implement the database is Firebase Realtime Database. Firebase has been chosen as it provides real-time database and back-end as a service and it also provides client libraries that enable integration with Android, iOS, JavaScript, Java, Objective-C, Swift and Node.js applications. Furthermore is possible to secure the patient's data by using Firebase server-side-enforced security rules.

Following the low-level specification, we created 5 collections: patients, pharmacists, deliveries, doctors and medicines. Collections differ from relational tables as they store data in documents, not rows and columns. After some testing we refined the aforementioned collections since their introduction in the low-level specification and also discovered that 2 more collections were necessary to add: caretakers and pharmacies.

The final defined collections contain documents that follow the following structure:

Patients		Deliveries		Pharmacists		Caretakers		Doctors		Medicines		Pharmacy
address		current		deliveriesPerformed		birthday		email		description		address
birthday		deliveryDate		email		email		firstName		medicineName		name
caretaker		emailPatients		firstName		firstName		lastName
doctorEmail		emailPharmacist		lastName		lastName		password
email		id		password		password		publicKey
firstLog		medicines		pharmacy		patients
firstName		pharmacy		responsible
lastName		robotID
medicineCurrent
deliveries
medicinePast
nextDelivery
otp
password
pastDelivery
pharmacy
prescriptionSignature
publicKey
token

The data field containing the passwords do in the implementation contain the actual user's passwords (with the exception of the one time password which is encrypted). In the ideal system, as indicated in the specifications, the passwords would be stored after being hashed.

We further explain some of the data fields of the collections, for which the name alone is not sufficiently self explanatory.

Patients:
caretaker: Email of the caretaker the patient is associated with. If the patient is independent this field is set to null.
firstLog: Boolean field indicating if a patient ever logged in the system before.
doctorEmail: Email of the doctor who prescribed the medicines.
medicineCurrent: List containing the medicines the patients is currently on and their intake indications.
deliveries: List containing the deliveries the patient has received.
medicinePast: List containing the medicines the patients was on and for which the treatment terminated.
nextDelivery: Field indicating the delivery date and time the patient is expecting his next set of medicines. If the delivery has not yet been set this field is equal to the empty string.
otp: Field containing the encrypted one time password the patient needs to type into the robot to open the right compartment. If no delivery is currently coming this field is set to the empty string.
pastDelivery: Field indicating the date and time of the last most delivery.
prescriptionSignature: Field containing the digital signature of the prescription (medicineCurrent) performed by the doctor.
token: field containing the registration token of the device the patient used to log into the app. This will be used to send a notification to the correct device.

Deliveries:
current: Boolean variable set to true if the delivery is currently being performed, set to false once the robot returns to the pharmacy.
emailPatients: List of emails of patients involved in a specific delivery.
medicines: Map containing a key: patient involved in a delivery and values: respective medication delivered for that patient.

Pharmacists:
deliveriesPerformed: List containing all the deliveries which the respective pharmacist has performed
responsible: This is a boolean variable that is set to true if the pharmacist has the ability to manage other pharmacist employees

Caretakers
patients: List containing all of the patients which this caretaker is responsible for.

Healthcare staff application

The healthcare application has been implemented, has previously stated, in Java. Once the application was completed a jar file, containing all the needed dependencies, was build. Using the free software Launch4j an exe file was constructed from the jar one. In this way the desktop application was build to be run in a Windows machine. However it is possible from the source code to build an application that can run on any operating system. The application has several java classes used to build the user interface. Furthermore the healthcare staff application has 3 main classes used to processed the data and query the database, provide the security features to the system and to calculate distances between addresses.

The application has been implemented as a Java Maven project, using Netbeans as the IDE. Once the application opens the user is asked to select a language and then specify their job. The app has been implemented to only support the English option, has all the functionalities would be the same in any other language.

Language selection page.

Job selection page.

Credentials page.

Error message login.

Once the job has been specified the user is asked to insert their credentials, username and password. The credentials are used to query the database. If a user in the doctor or pharmacist collections, with the desired username and password exists, then the user is logged into the application, if not then an error message is displayed. In order for the desktop app to communicate with the database the Firebase dependency is installed. Then the Firebase Admin SDK is added to the application.

To establish a communication the service account key is downloaded from the database as a json file. The key is then retrieved by the application and used to authenticate itself with the database.

Doctor Login

When the doctor logs in its main page is displayed. From there the doctor can then decide if to add a patient to the system or if to check the current medications a patient is on. A button has also been added to offer the possibility to log out. The first time a doctor logs in a RSA key pair is generated. To do that the java class Cipher is used. The public key is then saved in the database, while the private key is stored in a text file on the doctor's computer. Ideally the doctor's private key would be stored in the local database for the clinic where the doctors works, that is not accessible from attacks coming from outside the local network of computers of the clinic. Further restriction can then be implemented by the clinic in order to ensure that the private key cannot be accessed by other doctors. The doctor's key pair will then be used to digitally sign the prescriptions of the patients.

Doctor main page.

Add Patient

When the doctor adds a patient several fields need to be filled in. Each button that responds to a list selection is enabled only if an item is selected.

Add patient's information page.

After the personal details as name, surname and birthday, the doctor can add several medicines to the patient's profile. Each medicine can be selected from a list which retrieves all the medicines present in the database. Once the doctor selects the desired medicine to add to the prescription, he/she can then visualize a more detailed description of the medicine or directly add the medicine by writing the intake indications. The medication will then be displayed on the patient's prescription. The described processes is shown in the following pictures.

Search for the desired medicine.

Visualize medicine's description.

Insert intake indication.

The doctor after completing the prescription will add the first delivery date, by consulting the patient. The delivery date can then be modified by the patient from the phone app if desired. The final field to be added is the address. A new form will be displayed, when the button is correct button is pressed in order to add the patient's address. Once the latter is field in the application will processes which is the closest pharmacy to the patient, and will automatically assign the patient to the such pharmacy. To calculate the distances between addresses the Google Maps API is used.

Address form.

Error message when not all the data is filled in.

Once all the data has been filled in by the doctor, the button Add Patient can be pressed. A new form will be displayed asking the doctor if the patient passed the independence test. However if the doctor forgot to fill in all the patient's information an error message will be displayed. The independence test is based on the user's classifications tests defined in the requirement section. If the patient passed the test then the doctor will have only to add the patient's email and password. The password is auto generated by the application and can be changed by the patient's app successively. The email is used to identify the user in the database. Indeed because email addresses are unique, they can uniquely identify a user. Is possible however also to implement the system without tying it to email addresses. Indeed this can simply be done by generating an unique identifier for each new user, which must then be given to the user, so that can be used by the latter to login into their application.

Determine if the patient is independent.

Add email and password to an independent patient.

Message when patient is added to the system.

If the patient, instead, is not independent, he/she will be added to a caretaker. The assigned caretaker could already have an account in the system, in which case his/her name and email will be displayed by the application in a list. If the caretaker does not have a MediGO account a new account can then be created and the patient will be assigned to the newly created caretaker account. When the patient's data is finally added to the database a message is displayed confirming the operation.

List displaying the caretakers accounts in the system.

Form to add a new caretaker.

Check Patient

Message when no patient is found in the database.

Message when the patient's prescription is updated.

When the doctor decides to check the patient's data, it will first need to search for the patient's account in the system. To do that a form will be displayed the patient's name, surname and birthday must be added. If the query to the database returns an empty object then an error message will be displayed. If not a form showing and overview of the patients data will be displayed. From such form the doctor can add medicines to the prescription, modify intake indications or remove medications from the current prescription. Furthermore the doctor will be able to visualize for each current medication when the treatment started and for each past medication when the treatment ended. If the doctor wants to remove a medicine, he/she will be asked for the reason why the treatment is ending. Once the prescription has been updated the doctor can save the changes.

Form to check a specific patient.

Form where the patient's data is displayed and where the prescription can be modified.

The doctor must indicate why a treatment is over.

Pharmacist Login

When the pharmacist logs in the main page is displayed. The pharmacist's main page is different if the pharmacist is a manager or not. Indeed if the pharmacist manages the other employees at the pharmacy, the database will store true logical value in the boolean field responsible. Depending on the latter, then, the main page will or will not contain an option to manage the employees of the pharmacy.

Main page of a non responsible pharmacist.

Main page of a responsible pharmacist.

Manage employees

Message when new employee is added.

Message when the employees list is updated.

When the responsible pharmacist opens the window to manage the employees of the pharmacy, a list displaying the name and email of the latter is displayed. The pharmacist can then decide to select an employee and remove him/her, or decide to add a new employee. When a new employee is added a new form must be filled with the details and credentials of the new employee. In such form is possible also to indicate if the new employee will have the same privileges of a responsible pharmacist. Finally the responsible pharmacist can decide to save the changes.

Employees list.

Form to add a new employee.

Make a delivery

When the pharmacist wants to make a delivery the computer must be Bluetooth connected with the robot. In this implementation it was first used the java library Bluecove to do that. However when developing the prototype due to independent testing of the different parts caused by the Coronavirus pandemic, the Bluetooth communication was developed independently of the desktop application. The Robot section of Implementation will explain how the latter was done.

Make a delivery form.

Message when no patients selected the desired delivery date and time.

Message when the prescription is valid.

Message when not all medicines have been confirmed to have been added.

Once the communication is establish the pharmacist can prepare a delivery. A form will display the robot id and a list of the free compartments. The pharmacist can then choose a compartment to allocate to a patient. The first time a compartment is allocated, the delivery date and time must be inserted. If no patient indicated the selected delivery date and time, an error message will be displayed. On the contrary if some patients indicated such dates their name and email will be presented to the pharmacist. The latter can then choose any of the patients and start allocating the medicines. When doing so the software will check if the prescription if valid, by verifying the digital signature. If the signatures is authenticated then a form displaying the medicines the patient needs will be shown. The pharmacist can then fill the compartment and confirm with the app when he/she s done doing so. To finish this process, however, he must confirm in the app that each medicine has been added, if not an error message will be displayed. When each step is completed the pharmacist can then see which compartment has been allocated to which patient. Furthermore a one time password composed by six digits will be randomly auto generated and displayed together with the patient's email. The pharmacist can then either make a new allocation, deallocate a compartment or start the delivery. When the delivery is started, the information, containing the encrypted otp, is passed to the database and the user is notified using the Firebase Cloud Messaging API. In the notification will be also displayed the approximate arrival time of the robot. To calculate the arrival time the software uses the Google Maps API and calculates the distances between the pharmacy and the patients addresses. Then creates a path by recursively going to the next closest destination. When the final path is processed and the its length calculated, assuming the robot moves at a speed of 6 km/h, the application calculates the different times of arrival.

Form where the delivery date is selected.

Form where the patient to allocate to the compartment is selected.

Updated make a delivery form.

Check past deliveries

When a pharmacist decides to check the deliveries two lists will be displayed in a new form. The right most will present the current deliveries of the pharmacy. The pharmacy can select one of these deliveries and visualize more detailed information, like which patients is the delivery serving and which medicines is the delivery transporting. The deliveries are identified by a timestamp and the email of the pharmacist that performed it. When a robot returns from a delivery the pharmacists can then confirm the delivery has been performed by selecting it from the list and pressing the button Confirm robot returned. The left list instead will display past deliveries. The pharmacist can decide to visualize either the past deliveries that he/she performed or all the past deliveries his/hers pharmacy performed.

Form where current and past deliveries are displayed.

Form where additional details of the delivery are displayed.

User application

The user application has been implemented using Android Studio and is written in Java. Therefore the application currently is only supported on Android operating systems but it can easily be implemented for iOS too. The application is connected to the Firebase project to read and write data. The draft design of the application has largely been kept in the final design with a few changes.

Upon opening the application the user is asked to select their language of choice between Dutch and English. For time purposes only the English option has been implemented. After the language has been selected the user indicates whether they are the patient receiving the medication or if they are a responsible caretaker.

Patient Login

Once the patient option is selected, the user will be required to fill in their credentials (email and password) that has been given to them by the doctor. The credentials will then be checked in the database and if they exist, the patient will be logged in and directed to the home page. Upon the first login, the user will be prompted to change their password to a personalised password. On the home page the user is greeted and there are 5 buttons which can be pressed to open new activities.

Change password prompt.

New password check.

Old password check.

The first is the “Get Code” activity. This activity is where the one time password for the delivery can be retrieved. If there is no delivery scheduled the text field will specify this. If there is a delivery scheduled the user will be able to see their 6-digit code for that specific delivery alongside brief instructions to use this code.

The second button is the “Track My Delivery” activity. Here the user will be able to get an approximate arrival time of their delivery that is currently on its way. If there is no delivery coming, again the application will specify this.

The third activity allows the user to plan a new delivery or view their past deliveries. To plan a new delivery the user will have to select a date using a date picker and then select a timeslot from 2 options. They will then have to click “Save” to save this selection to the database. The date picker has a restriction on which dates are available to select to avoid the user planning too many unnecessary deliveries. The im implemented delivery system works on a monthly basis and so the user is only able to select days 3 weeks after their previous delivery (or their first delivery entered by the doctor when they sign up). They will have a one week period to choose a date in order to leave some flexibility. In the original design a calendar was used to choose these dates, however to avoid cluttering the screen and to allow the large font size to be maintained a date picker was selected instead. In the activity where the user can view their past deliveries there will be a list containing each delivery. Each delivery will contain the date and time of the delivery as well as the medications that were delivered.

The fourth activity is the medication overview, here the user can see a list of medications that they are currently prescribed along with the intake directions and the start date of the prescription. The user can also see a list of previous prescriptions that they were taking along with the start date, end date and the reason why they were taken off this medication.

The final activity is the profile activity. Here there is the patient's personal information like email, birthdate and address. These cannot be edited within the application to avoid missing or wrong information being added but if they wish to change this information they can contact their doctor. The user can logout from their profile in this activity and change their password. In order to change their password the user is required to fill in their old password for security reasons. They also have to enter their new password twice in order to make sure that it has been entered correctly. There are various checks for these entered passwords so that if a mistake is made it is easy for the user to determine where the mistake has been made.

Language selection activity.

User selection activity.

Home page activity.

One time password activity.

Track delivery activity.

Plan delivery activity.

Past deliveries activity.

Current medication activity.

User profile activity.

Change password activity.

Caretaker Login

If the caretaker option is selected, again they will have to fill out their personal credentials to log in. These are checked with the database and if they are correct the caretaker will be logged in. The first activity they see will not be the homepage but instead a list of the patients which they are responsible for. They then select the patient which they would like to monitor and the homepage will then open.

Most of the activities are the same as the patient login, retrieving the selected patients data from the database. The profile activity is slightly different as it contains the caretakers personal information and also gives them an option to change their password as their patients do not have personal passwords. There is however an option to view the personal details of the respective patients too.

Notification Feature

A feature which both Caretaker and Patient have is that they are notified by the app when their delivery is on its way. This is implemented only when the delivery is sent out by the pharmacist, but ideally if the app could also communicate with the robot itself it would also be notified when the delivery has arrived. This could be implemented if the robot was connected to the Internet of Things. The current notification is linked to the token of the users device and appears even if the device is locked. The notification contains the users name and the approximate time of arrival of the delivery.

Notification feature.

Robot

The hardware part of the robot consists of multiple parts. This being the microcontroller, a keypad, an LCD screen, the bluetooth to connect to the app and an opening system for the compartments. In this project, multiple communicative devices are used. This means that using multiple serial ports are needed. Normally serial pins 0 and 1 are used for communication with the computer, the rest are used for communication with different devices. In the pieces of code presented below just 'serial' will be used. However, do notice that when really building the robot multiple serials would be used.

Prototype

Microcontroller

The microcontroller that has the best specs to work with the other components of the robot is the Arduino Mega 2560. This board has 54 digital i/o pins and 16 analog inputs. The second best options was an Arduino Nano, this board is the board with the most pins after the Mega. However, it would still be tight to assemble all the components. This board does not have built in wifi or bluetooth so we will need to use a separate component to make communication possible. Because the robot will need multiple communicative components attached a microcontroller with multiple serials are needed, which also directly points to the Arduino Mega over most other Arduino's. Of course using such a board is only meant for building the prototype. Eventually you would want to print it all on your own board.

Keypad

The keypad is used for clients to enter their birthdate and password. The keypad we decided to use is one from adafruit . This because it is not hard to work with and has very clear buttons. We will use the 10 numbers for the password, the left lower corner to go back and the lower right corner to confirm. For the prototype the keypad is used as it is, however, in the design we would want to put different symbols on the lower corners, to make very clear what they are there for. The best library for this keypad is the following.
Keypad Library for Arduino
Authors: Mark Stanley, Alexander Brevig
Contact: mstanley@technologist.com
Contact: alexanderbrevig@gmail.com

The following code can then be used to 'create' the keypad in the code, after which we can use the other functions in the library to read the keypad.

const byte rows = 4; //four rows
const byte cols = 3; //three columns
char keys[rows][cols] = {

 {'1','2','3'},
 {'4','5','6'},
 {'7','8','9'},
 {'#','0','*'}

};
byte rowPins[rows] = {5, 4, 3, 2}; //connect to the row pinouts of the keypad
byte colPins[cols] = {8, 7, 6}; //connect to the column pinouts of the keypad
Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, rows, cols );

LCD screen

The keypad does not give feedback to the user. However, since we think it is really important the the user, especially since we are working with elderly. To do this we decided to use an LCD screen. For the prototype that will be the following component https://www.tinytronics.nl/shop/nl/display/lcd/lcd-display-16*2-karakters-met-witte-tekst-en-blauwe-backlight. To control this LCD the LiquidCrystal Library can be used, having easy to use built in functions. The brightness of both the text and the background can be made adjustable by using digitally variable resistors. This means the brightness could change with the time of the day to increase user friendliness. We are using a differnt Arduino, however, the following figure shows the schematics to connect the LCD.

Bluetooth connection

To make the robot available for the webapp the decision was to use Bluetooth, one component that is usable for this is the hc05, this component can work as either a slave or a master. In our project it weel need to function as a slave. The computer needs to connect to it, and then it is possible to send data to the module. The Arduino needs to register the incoming data. The following picture represents how the hc05 should be attached to the Arduino in the most simple way.

An example project can be found here: https://howtomechatronics.com/tutorials/arduino/arduino-and-hc-05-bluetooth-module-tutorial/.

Total system

Now the components that are used for the prototype are chosen it all has to be put together. This means creating a code that will recceive passwords sends from the pharmacists app, setting them for the correct compartment and opening the right compartment when the user enters a correct compartment. The pinout can be found in the table below. The 5V and ground of the Arduino were used to power all the component according to the schedules found above.

Arduino	Component
digital 2	keypad 2
digital 3	keypad 3
digital 4	keypad 4
digital 5	keypad 5
digital 6	keypad 6
digital 7	keypad 7
digital 8	keypad 8
14 tx3	rxd hc-05
15 rx3	txd hc-05
digital 22	LED 1
digital 24	LED 2
digital 43	lcd 14
digital 45	lcd 13
digital 47	lcd 12
digital 49	lcd 11
digital 51	lcd 6
digital 53	lcd 4

Theoretical

There are certain parts for which the time is missing to implement. This is a description of how those parts should be implemented.

Total system

For the total system in the end one would want to take all the used parts of the processor and print an own board, connected to all the components needed. Furthermore there are multiple parts which should be added to the code. First would be a way to keep track of which compartments are empty and which are still full. Also a way to confirm to which robot the computer is connected should be added. This means sending an ID number over to the computer which can then check whether it has the right robot.

GPS

The way to track the robot and have it to send an alert when it arrives can be done using a GPS module. A GPS module works by intercepting the signals transmitted by satelites, it calculated the distance using the time it takes to send a receive messages. With information from multiple satellites it location can be computed. An example is the NEO-6M module, that one uses an antenna to be even more precise. Connected to an uno it would look like this, the LCD and potmeter can be left out.

Limitations

Battery and distance

The system is currently limited for its battery capacity. It is therefore really important that the distance beforehand is set with the full amount of battery, so no inconvenient situation will occur like running out of battery when not everything has been delivered. A future solution for this problem could be to make use of solar to sustain the power or to implement electrical charge points in cities. However, due to costs, the analysis has now made to see this as a future challenge.

Locks

The idea is to use a solenoid bolt in a solenoid valve like system so the drawer automatically moves out when the correct code is entered. It is beneficial that the user does not need a handle to open it, because it will make it harder to break into the robot without having the right code. The drawer would be hooked behind the piece of the solenoid valve which can retract. When it retracts a spring causes the drawer to open. It can be pushed back into closed position.

Lock system while closed

Lock system while open

The problem with this system is that it does not have a mechanism that automatically closes the locker. This function is, however, needed in case the user does not close the drawer and the robot decides to leave (see section error conditions).

Another option for the lock system would be to let the robot open and close the compartment with a linear actuator. That means using the principle shown in the picture below, which convert circular motion into a linear motion, this could be used to push a compartment out, and later retract it. This takes up more space than the idea that is mentioned above, however, the robot would be able to close the compartment itself. Also this way there is no verification whether the user actually emptied the compartmart, because the robot will close it itself instead of the user having to do that.

Flats/apartments

Because a lot of people live in flats or apartments, especially elderly, it would be very useful if the MediGO robot would be able to enter these buildings. It turns out, however, that this brings some challenges.

First of all, the robot should be able to ring the correct doorbell at the entrance of the building. For people who don't live in a flat, the need to ring a doorbell is less present, because the user receives a message on their app and can then open the door. However, in a lot of flat buildings, the user has to open the door from their apartment with a button that only works after the actual doorbell downstairs is rang by the visitor. There are examples of delivery robots that are already able to ring a doorbell . The ANYbotics robots use sophisticated sensors that scan its environment and make a digital map in real time, which makes it possible to ring the doorbell with one of its four legs. This would have to be combined with a text recognition algorithm to recognize the name of the user and press the corresponding doorbell. This is already a challenge on its own, but there are also building that don't have one doorbell per resident, but that have a keypad on which the correct house number should be entered to ring the right bell. This would require really smart sensors and algorithms.

The second obstacle for the delivery robot is the elevator. The robots that are currently able to use the elevator are mainly used in hotels, which means they have options to set up the robot for this specific elevator. It is even the case that the robot's software communicates with the elevator . This is a problem in our case, since the MediGO robot would need to operate every elevator it comes across. Even if the robot is able to press the button to call the elevator, it also needs to choose the right floor. This means either that it should be able to read, search for the house number and choose the corresponding floor, or that the database should already contain this information. But then it is still difficult to recognize a number on a button and press the right one. In addition, a lot of elevators are a so-called Faraday cage , which are metal enclosures that can block out electromagnetic waves. This means that communication with the robot is really difficult while in the elevator, which causes some problems.

For the first and the second problem, comparable measures are needed. There are multiple options that might solve the problems, but more research needs to be done into this. First of all, the MediGO robot will need some kind of mechanical arm to operate doorbells and buttons. Besides that, the most important issue to solve is the ability to read and recognize text in order to choose the right buttons. Artificial intelligence and smart neural networks could play a roll in this. It might be an option to let users make a picture of the interfaces the robot will need to handle and indicate the right buttons to push before the first delivery. The software will recognize the right buttons more easily, which can make the entire interaction go more smoothly.

Another challenge for the MediGO robot is to manoeuvre through the halls of the building and navigate to the right house number. Especially in buildings with multiple stories, there are still problems with using GPS for indoor positioning. Also roof material, wall materials, the number of walls and the closeness of surrounding buildings negatively impact GPS availability. Another method for indoor positioning should thus be used to increase the accuracy. Options are WLAN/BLE based positioning, map-matching, magnetic field fingerprinting, and motion tracking using sensors. All of these have advantages and disadvantages. The most accurate navigation might be to combine multiple methods, but more research is needed into the feasibility and affordability of this.

MediGO company

One of the stakeholders of the MediGO delivery system is the MediGO company. The need for this company came up during the process, which is why it is not elaborately described in the stakeholder analysis. The company will be responsible for initiating and maintaining the entire system, including the doctor and pharmacist accounts and the robots. It also has an important role in damage and ensurance issues. However, it is not really thought out yet what the structure and function of this company will be exactly. There should be a department that deals with damage and maintenance of the robot, there should be a department that intervenes when the robot alarms them, there should be someone that thinks about ensurance and contracts with pharmacies and there should be people that handle the database. How exactly this should work, however, needs more research.

Damage & Insurance

The company MediGO will be in charge of the repairs and would ideally have an integrated alarm system when the robots are violated and/or damaged. Ideally, the robot would send a signal to the company MediGO, having the location of the robot and the damage/stealing signals, to inform the pharmacist and check-upon the situation; does the situation acquire a visit from the company, the pharmacist or the police? The idea is to make use of an alarm system and let this be part of the company mediGO as a suborganization. Financially, mediGO will be only held responsible for the maintenance that is caused by fabricable defects, within 3 years of guarantee. However for all other damage or stealing damage, mediGO will not be held responsible and the pharmacist will need to assign for an insurance at an insurance company if they want to be partly or fully covered when certain things like damage and stealing occur.

Capacity, locker usage and route optimization

Every pharmacy that will potentially use the MediGO system and service has a different size and number of patients. This is why each pharmacy can estimate the number of MediGO delivery robots that they will need themselves. This makes it difficult to indicate how exactly the system will handle the assigning of the right lockers to the right orders. Products vary in size and the robot has compartments of different sizes as well, but there are different ways in which the system can handle this and appoint medicines to drawers. The system should take the size of the order into account and make sure the entire order fits in the drawer. This seems rather doable, since most orders will fit in the smallest compartments and only exceptionally large orders need the biggest compartments. Most people use only 1 to 4 different kinds of medication and it is also possible that those will not be delivered at the same time. However, it becomes more difficult if the pharmacy has multiple robots, because then it is not only a matter of dividing the order over the lockers of one robot, but the route optimization will also play a role. It seems most natural that the adresses and time slots will have the highest priority in this optimization challenge. When the routes are calculated and the robots are appointed to certain customers, then the packages will be divided over the lockers of this robot. The assumption that most orders will fit in the smallest compartment is still valid and if there really is a problem, a solution can be to appoint two medium lockers to one order instead of one big locker. However, the expectation is that these problems will not occur too often and that practice and experience will show how big of a problem it will actually be. In that case, a reconsideration of the locker sizes should take place.

Approach

To achieve the objectives of the project five main parts of the development process have been defined: research, requirements analysis, specification analysis, implementation and testing. To better tackle each phase regular group meetings every week have been set. During these meetings the tasks for the current development processes phase are assigned to each team member.

Group organization

Each week a different group member occupies the position of chairperson. The responsibility of the chairperson is to establish an agenda before the meeting and mediate the discussion through the topics that are set in the agenda. Furthermore the chairperson must take the minutes of every meeting during that week and act as a representative of the group during the tutor meeting. The chairperson role rotates through the members in the team.

Chairperson Rotation

Week 1	Week 2	Week 3	Week 4	Week 5	Week 6	Week 7	Week 8	Week 9
Mijntje	Dajt	Danielle	Fabiènne	Lucia	Mijntje	Dajt	Danielle	Fabiènne

Development process

Development Process

The first phase of the development processes of the project is the research. During the latter the literature is consulted to establish the state of the art. Moreover the problem statement is specified and the different stakeholders are analysed. A comprehensive plan is set to fix the deadlines of the other phases.

The second phase is the requirements analysis. This is a fundamental step of the development processes as the requirements will define the functionality of the project. A cost-benefit and risk assessment analysis will cover the requirements for every part of the project. The ethical evaluation will focus on the requirements for the application and the compartment system prototype, while the survey will focus on the requirements for the navigation simulation.

The third phase of the development processes is the specification analysis. During this phase the requirements are formalized using UML diagrams. The design of the user interface of the app is defined and the hypothetical maps that the delivery robots must navigate are designed in NetLogo.

The fourth phase is the implementation. The application code is written in Swift, creating an app compatible with devices supporting iOS, the hardware for the compartment system is assembled and the NetLogo program for the delivery simulation is written.

During the fifth and final phase of the development process the system is tested and a demo is finally created.

Planning

From the approach a plan for the development process was created. The plan is illustrated in the following figure using a Gantt table.

Gantt table of the planning

Task Division

During each development process phase the different task composing it are subdivided between the group members.

Research			Requirements			Specification			Implementation			Testing
Task	Group member		Task	Group member		Task	Group member		Task	Group member		Task	Group member
Determining subject	All		Risk Assessment	All		App Users	All		App User	Danielle		Test system	All
Set up Wiki	Fabiènne		Cost-Benefit Analysis	Fabiènne, Mijntje		App enterprise	Dajt		App enterprise	Dajt		Make demo video	All
Approach	Dajt, Danielle		Ethical perspective	Danielle		Robot compartment system	Fabiènne, Mijntje		Robot compartment system	Lucia		Update Wiki	All
Planning	Fabiènne, Dajt		Make survey	All		Update Wiki	All		Update Wiki	All
Literature search	All		Analyse data survey	All
Introduction	Mijntje, Fabiènne, Dajt		Update Wiki	All
State of the Art	Lucia, Mijntje
Stakeholder analysis	Danielle
Update Wiki	Fabiènne, Danielle, Dajt

Milestones

By the end of week 2 the problem statement, introduction, stakeholder analysis and state of the art must be completed. This will conclude the research phase.

By the end of week 3 the survey on people’s attitudes towards our proposal and delivery robots in general, the risk assessment, and different analysis must be completed. This will conclude the requirements phase.

By the end of week 4 the analysis/conclusions of the survey and a semi-formal model of the system must be completed. This will conclude the specification phase.

By the end of week 6 the first implementation of the apps, lock system and navigation system must be completed. This will conclude the implementation phase.

By the end of week 7 the adjusted version of the apps (after testing/interviewing) and a demo video must be completed. This will conclude the testing phase.

Deliverables

The final product will be a system to distribute/deliver medicine to those in need (elderly in most cases), including:

• An application with the choice to log in as a user (elderly/caretaker) to order medicine and open the compartments of the delivery robot.

• An application with the choice to log in as the pharmacist or doctor to set the passwords for the compartments and the targets the delivery robot must visit or to prescribe medicines to users.

• A hardware system to secure and open the compartments, which can communicate with the application.

Logbook

Week 1

Name	Total hours	Tasks
Danielle	3.5	Introduction lecture [1.5], meeting [0.5], literature research (source 5-11) [1.5]
Lucia	3	Introduction lecture [1.5], meeting [0.5], literature research (source 22-26) [1]
Mijntje	3	Introduction lecture [1.5], meeting [0.5], literature research (source 18-21) [1]
Dajt	3.5	Introduction lecture [1.5], meeting [0.5], literature research (source 14-18) [1.5]
Fabiènne	4	Introduction lecture [1.5], meeting [0.5], literature research (source 1-4, 11-13) [1.5], wiki page [0.5]

Week 2

Name	Total hours	Tasks
Danielle	7.5	Meeting [2], images (Approach/Stakeholder) [1.5], stakeholder analysis [2], update wiki [0.5], tutor meeting [0.5], interview questions [0.5], informed consent editing [0.5]
Lucia	8	Meeting [2], state of the art [5], hardware research [0.5], tutor meeting [0.5]
Mijntje	9.5	Meeting [2], state of the art [7], tutor meeting [0.5]
Dajt	9	Agenda [0.5], meeting [2], approach [2], planning (tables) [2.5], problem statement [0.5], update wiki [1], tutor meeting [0.5]
Fabiènne	8	Meeting [2], literature research (source 27-30) [0.5], planning [0.5], references [1.5], update wiki [2], tutor meeting [0.5], contacting people to interview [0.5], interview questions [0.5], informed consent forms [0]

Week 3

Name	Total hours	Tasks
Danielle	9.5	Contacting pharmacists [1.5], conducting interviews [3.5], transcribing interviews [1.5], update wiki [0.5], meeting [1], tutor meeting [0.5], summarize needs interviews [1]
Lucia	5	Meeting [1], tutor meeting [0.5], conducting interview [1], transcribing interview [0.5], summarize findings [0.5], contacting pharmacists-to-be [0.5], research compartments [1]
Mijntje	1.5	Meeting [1], tutor meeting [0.5], due to illness no other work done
Dajt	9.5	Meeting [1], tutor meeting [0.5], contacting elderly and caretakers [1.5], conducting interviews [5], transcribing interviews [1.5]
Fabiènne	12.5	Preparation interviews [0.5], conducting interviews [2], transcribing interviews [3], update wiki page [2], meeting [1], tutor meeting [0.5], summarize needs interviews [1], research lock system [1.5], research cognitive classification [1]

Week 4

Name	Total hours	Tasks
Danielle	9.5	Tutor meeting [0.5], meeting [1.5], ethical analysis [4], appearance [2], personas [0.5], research [1]
Lucia	10	Tutor meeting [0.5], meeting [1.5], requirements design and hardware engineering [6], research tracking [2]
Mijntje	10.5	Tutor meeting [0.5], meeting [1.5], classification responsibility [3], appearance [1.5], research GP - pharmacist system [2.5], reading others material [1.5]
Dajt	11	Tutor meeting [0.5], meeting [1.5], security research [2], requirements engineering [5], needs [1], update wiki [1]
Fabiènne	10.5	Tutor meeting [0.5], agenda [1], meeting [1.5], personas [0.5], update wiki page [2], lock system [2.5], route planning/optimizations [1.5], scenario [1]

Week 5

Name	Total hours	Tasks
Danielle	12.7	Tutor meeting [0.7], meeting [1], overview decisions [1.5], research into password system [1], research database [3.5], creating database [3], Programming User App [2]
Lucia	9.2	Tutor meeting [0.7], meeting [1], consulting users [1], research lock system [6], meeting with Mijntje about lock system [0.5]
Mijntje	11.7	Tutor meeting [0.7], meeting [1], overview decisions [1], consulting users [1.5], prototypes lock system [1], prototypes complete robot [4], Research Database responsibility [2], meeting with Lucia about lock-system [0.5]
Dajt	12.3	Tutor meeting [0.7], meeting [1], overview decisions [1.5], consulting users [1.5], security [2], user case diagrams [1.5], Programming Pharmacist App [4]
Fabiènne	11	Tutor meeting [0.7], meeting [1], overview opinions [1.3], consulting users [2], research dimensions [2], read other materials [1.5], update wiki [1], user app UI [1.5]

Week 6

Name	Total hours	Tasks
Danielle	16.5	Meeting [2], tutor meeting [0.5], update wiki [2], user app [7], database [5]
Lucia	13.7	Meeting [0.7], tutor meeting [0.5], meeting with Ruud vd Bogaert [0.5], hardware [12]
Mijntje	14.5	Meeting [2], tutor meeting [0.5], meeting Fabiènne user app UI [0.5], meeting Fabiènne lay-out wiki [0.5], meeting Fabiènne prototype design [1], designing prototype [1.5], updating the wiki and rewriting inconsistencies [3], research about database current pharmacy system [2.5], storyboard as preparation of video script [2], functionality consistency [1]
Dajt	19	Meeting [2], tutor meeting [0.5], update wiki and create diagrams[13], healthcare app [3.5]
Fabiènne	15	Meeting [2], tutor meeting [0.5], capacity+size+flats research[1.5], meeting Mijntje user app UI [0.5], user app UI [2], test user app (+ prep) [1.5], meeting Mijntje lay-out wiki [0.5], rewrite and update wiki [3.5], meeting Mijntje prototype design [1], designing prototype [2]

Week 7

Name	Total hours	Tasks
Danielle	27	Meeting [1.5], tutor meeting [0.5], user app & database & healthcare app [25]
Lucia	8	Meeting [1.5], tutor meeting [0.5], preparing to work on hardware [6]
Mijntje	10	Meeting [1.7], tutor meeting [0.5], meeting Fabiènne [0.3], research & writing responsibility section [1.5], reading and updating wiki [1.5], functionality appearance [2], anthropomorphism [0.5], research current pharmacy care systems [2]
Dajt	27	Meeting [1.5], tutor meeting [0.5], user app & database & healthcare app [25]
Fabiènne	10	Meeting [1.7], tutor meeting [0.5], scenario [0.5], user app [1], physical security [2], meeting Mijntje [0.3], reading and updating wiki [1.5], limitations flats/appartments [1], references [1.5]

Week 8

Name	Total hours	Tasks
Danielle	27	Tutor meeting [0.7], meeting [1.3], user app medical app and database [25]
Lucia	21.8	Tutor meeting [0.7], meeting [0.6], soldering [1.5], 3x4 Matrix [2], LCD [3], Bluetooth [7], Combining [7]
Mijntje	13	Tutor meeting [0.7], meeting [1.3], meeting Fabiènne [1.5], updating the current state of the art [1], limitations battery capacity research + section writing [1], writing section Responsibility and research[3], script writing of video [4], pharmacist call about database and system use [0.5]
Dajt	27	Tutor meeting [0.7], meeting [1.3], user app medical app and database [25]
Fabiènne	10	Tutor meeting [0.7], meeting [1.3], meeting Mijntje [1.5], placing/adjusting orders [1], limitations flats [1], error conditions + communication [1.5], presentation script [1], limitation lock system [1], presentation [1]

Week 9

Name	Total hours	Tasks
Danielle	31.7	Tutor meeting [1], meeting [0.7], user app medical app and database [18], video recording and editing [6], wiki [6]
Lucia	13	Tutor meeting [1], bug fixing [10], wiki [2]
Mijntje	11.2	Tutor meeting [1], discuss with Fabiènne about script [0.5], meeting [0.7], writing the second draft of the script [4], recording voice over [1], updating the wiki [4]
Dajt	31.7	Tutor meeting [1], meeting [0.7], user app medical app and database [18], video recording and editing [6], wiki [6]
Fabiènne	11.7	Tutor meeting [1], discuss with Mijntje about script [0.5], presentation script [1.5], presentation video [7], meeting [0.7], updating wiki [1]

Week 10

Name	Total hours	Tasks
Danielle	3.5	Meeting [0.5], wiki [3]
Lucia	3.5	Meeting [0.5], wiki [3]
Mijntje	0.5	Meeting [0.5]
Dajt	3.5	Meeting [0.5], wiki [3]
Fabiènne	0.5	Meeting [0.5]