PRE2015 3 Groep3

Group Members

Student ID	Name
0903288	J.J.P. Beckers
0909421	N.J.A. Frints
0911264	R.G. Hup
0896239	S.J.W. Maas
0924760	H.V.C. Ramchurn
0923126	G.M. van Vliet

Pharmacy Service Help Robot

Nowadays getting your medicine at the pharmacy takes more time than you have. In the last couple of years the waiting times at the pharmacy have improved a lot. However, most people have a busy agenda these days. This means that the waiting times are still a big problem. In addition, the society expects a 24-7 service. The current system cannot come up to these expectations.

When we were searching for a solution for this problem the idea of the Pharmacy Service Help Robot - or MEDispenser, as we called the system - came up. The use of this robot will improve the waiting times, because getting your medication via this robot will be a lot faster than via regular employees, especially in busy pharmacies. The users will be able to retrieve the medicines that they need from the robot. This will apply both for prescription medicines and OTC (over the counter) medicines. Since most medicines require an explanation about the use, the robot will be capable to explain this to the users.

Not only will the system help the customers of the pharmacy, but it will also help the pharmacist themselves. Taking over some parts of the current job of the pharmacist, results in them having more time available. With this they will be able to assign their time better and work in a more flexible way. It will also help with the increasing need for staff in the medical industry.

An important remark about this concept is that this robot will only be a tool that takes over a part of the pharmacist’s job. The Pharmacy Service Help Robot will not change anything to the current protocols.

Goal

Decrease waiting time

It is generally known that waiting times at pharmacies can be long. To verify this statement, literature research and both qualitative and quantitative research has been done.

According to NIVEL (Netherlands Institute or Health Services Research) , the average waiting time in a pharmacy, both public and private, is 9.2 minutes, with a standard deviation of 6.0 minutes. This includes queueing with other customers and waiting for the pharmacist to fetch the customers medicine. While a large part of the respondents (41,6%) states that they have to wait for 5 minutes or less, a significant part of respondents (44,6%) states that they have to wait for 10 minutes or more.

While these numbers represent both public and private pharmacies, the public pharmacies do have longer waiting times, with an average of 18 minutes. Respondents that are using public pharmacies stated that a waiting time of 7.5 minutes is most desirable. It could therefore be concluded that a significant part of pharmacy customers, both private and public, do not meet this desired waiting time.

As the average waiting time at public pharmacies is significantly higher than the average of both public and private pharmacies, it could be concluded that private pharmacies do have significantly shorter waiting times than public pharmacies. This could be confirmed by the dutch Mediq pharmacies, which state that their average waiting time is 1.77 minutes .

The conclusion could be made that the waiting time at pharmacies is acceptable in a lot of cases, but does not meet the desired values in other cases. While private pharmacies generally provide fast services, public pharmacies do lack such rapidity. By implementing the concept of a robotic pharmacy service help, the waiting times could be reduced, as a robot is faster than humans regarding fetching medicine, performing the majority of checks and dispensing the medicine to customers.

Solve the pharmacist and assistant shortage

Another known issue is the shortage of pharmacists or pharmacy assistants. In Belgium the amount of pharmacies decreases yearly with dozens. In 2015 there were 4942 pharmacies, this is 60 less than the amount of pharmacies in 2013.

The amount of vacancies in the pharmacy branch is growing. “It seems to be going the positive way” is what Irene Wolff said. The amount of vacancies has grown for the first time since 2011. The growth of these vacancies is looked at as a positive thing, since this increases the job opportunities for the pharmacists and assistants. However, what if these pharmacists and assistants remain absent? That is where our Pharmacy Service Help Robot comes in.

It is capable of assisting the pharmacist in such a way, that the presence of an assistant becomes unnecessary. This would decrease the amount of open vacancies, which we believe is a positive thing.

Research

Interview

We had decided to conduct an interview with a pharmacist, so we could expand our understanding of the current pharmacy system. We managed to get an appointment with Ellen Jansen, who works at Pharmacy Fellenoord. On the 24th of February two group members (Chiel van Vliet & Sil Maas) went over to the pharmacy and asked Ms. Jansen some questions. Both the questions and the (translated) answers can be found here: Media:Pharmacistinterview.pdf‎.

One of the most important findings of the interview was that Ms. Jansen stated that 2 minutes is about the minimum time required for a pharmacist to get the requested medicine to the customer. Most medicine take notably more time to deliver to the customer. Ms. Jansen explained that most of this time is spent on checks; scanning medicine package, checking contents of medicine package, etc. This means that if we manage to automate these checks we could greatly improve on the time it takes to give a customer his medicine.

We also found that the current system of explaining to a customer how his/her medicine should be taken and when it should be taken, is far from perfect. Ms. Jansen explained that there are a lot of foreign people who come to pharmacy Fellenoord and often they speak neither Dutch nor English. This means that when the pharmacist gives the obligatory written and verbal explanation of the medicine, he or she can only really hope that the customer understood this. This is another problem that our idea could solve, for instance with an interface that has different language options. This way, non-Dutch speakers can still understand the explanation, because it is given in their native language.

Mr. Jansen also mentioned that she had noticed that were a lot of budget cuts coming through in the pharmacy sector. Budget cuts can easily lead to a lack of employees, which would worsen the current conditions (longer waiting times). Our new pharmacy robot could possibly solve this as well, simply by being more cost-efficient in the long run. Eventually the pharmacies will have lower costs without jeopardizing the quality of their work.

After the interview we finally got a chance to look at the "behind-the-scenes" part of the current pharmacy "vending machine", which is only used for repeated prescriptions. We already knew that this system sends a code via an SMS message to the customer, which he/she can type in to the touch screen of the machine to get their medicine. The user-interaction part is outside of the building, like a cash dispenser. However, now we got to see how the medicine is put into the machine. The same checks have to be performed before the medicine can be put in the machine. After the checks are done, the pharmacists scans the medicine package with a scanner connected to the machine and the SMS message is automatically send to the customer. Then the pharmacy selects a size of the box she wants to store the medicine in and the machine grabs a box of the right size and holds it behind a small window. The pharmacy then opens that window and puts the medicine in the box and lets the machine put the box back in its place in the storage area. Ms. Jansen explained that at larger pharmacies they have too many repeated prescriptions, so they keep the medicine in the machine for a limited amount of time.

Questionnaire

Questionnaire results - pie chart of the waiting times

To gain more knowledge on the customer experience in pharmacies, we decided to create a questionnaire on the subject. The questionnaire had two multiple choice questions, one “yes/no” question and six open questions. By asking people to fill it in via social media we managed to get a total of 90 responses.

Our main finding during the analysis of the data was that 56.6% of the participants stated that they usually have to wait longer than 5 minutes before they got their medicine. 14.4% usually wait longer than 10 minutes, sometimes even up to 30 minutes or more. This means that for the majority of pharmacies there is room for improvement concerning the waiting times.

Another interesting finding is that 83.3% of the participants state that they usually have a prescription when going to a pharmacy. This suggests that prescription medicine is the main reason for people to visit a pharmacy, meaning that changing the way pharmacies handle the sale of prescription medicine will have the biggest effect on the overall customer experience.

After giving a description of our Pharmacy Robot concept we asked the participants whether or not they thought it would help speed up the process of getting medicine at a pharmacy and whether they would use the system. 67% of the participants did in fact think our concept would improve the current pharmacy system, especially concerning the waiting times. Interestingly enough, only about 42% percent of the participants stated that they would want to use the Pharmacy Robot over the normal pharmacist (or assistant). Most of the people that did not want to use the Robot explained that they would not trust the Robot as much as they would trust a pharmacist (or an assistant) or that they would miss the explanation of the intended use of the medicine. The latter is simply caused by the fact that we did not give a very detailed explanation of our concept, because we were afraid it would bore people too much and that it would result in less serious answers and thus worse data. However, the lack in trust might be an actual problem, because 25.6% of the participants indicated that they would be afraid of the system malfunctioning and giving them the wrong medicine. However, this is a phenomenon that we have seen before, namely with the introduction OV-chip card system. There used to be tons of articles (like this article and this one) going around about the lack of trust in the system, whereas nowadays it is, for the most part, widely accepted as the current public transport system (as described in this article about increase of trust). So, maybe it is just a matter of giving people time to get used to the system and let their trust grow.

Trust

In order for our idea to be successful, we need the customers to trust the system. So, we did some research on subject. We found a lot articles relating to 'trusting automated systems', but only a few that actually contained conclusions leading to specific concepts that we might be able to incorporate into our system.

• Our main finding is that the level of trust people have in system is mainly determined by the performance of that system on a task (Hancock et al., 2011) (van den Brule et al., 2014). This means that if the pharmacy robot is consistently faster than a pharmacist (or assistant), while still being able to give the customer the necessary information, the customers will trust it easier. Also the environmental situation appears to have some influence on the level of trust. This might be a good reason to have the user interaction part of the system located inside the pharmacy (like we intended in the first place), as opposed to the current repeated prescription system, of which the UI is outside of the pharmacy. There you, as a customer, are standing on the street, with people walking by you constantly. Inside the pharmacy it will be much quieter and much more pleasant, and thus increase the level of trust in the system.

• A commonly used strategy to increase the public trust in a new system is to let the concept be known before implementation (Hengstler et al., 2016). By letting people get used to the idea of this new system and with the use of good PR, the trust can grow before the system is actually used. Also, by inviting some people to try out the system, you can not only get useful feedback, but also have people spread the word about their personal experiences with the system. If done right, this could have a major positive influence on the trust in the system.

• Another very interesting finding is that the more anthropomorphic features (name, gender, voice, etc.) the system has, to more people expect it to do well on a task (Waytz et al., 2014). In this particular research participants drove an autonomous car using a driving simulator. One car was just able to control the speed and the steering, whereas the other one also had some anthropomorphic features. "Behavioral, physiological, and self-report measures revealed that participants trusted that the vehicle would perform more competently as it acquired more anthropomorphic features." So, the more an automated system (mentally) resembles a human, the more trust it gains from its users.

From all what we learned from research, we have decided to implement a few things. Test will be conducted with users to gather feedback to further improve the system. Further we decided to set specific performance conditions which have to be met. These are create to ensure that the performance of the machine will not affect the trust in a bad way, but will only lead to an increase in trust. The conditions are mentioned in the table . For the anthropomorphic features, we decided that adding a voice' and making the machine ask the customers questions will show that the machine has some form of intelligence. We decided not to add a specific name and gender to the machine, since it will be a public machine and these are more suited for personal machines.

Security

The security aspect of such a system can be feasibly proven by similar functioning already existing systems; such as an ATM, a ticket dispenser at the station or a vending machine. An ATM is a good example as it incorporates important and secured transactions. If a PIN code is wrongly written 3 times, the bank card is blocked; in the pharmacy robot case scenario, the person will have to move to the counter and interact with the pharmacist instead of the machine in case of security issues or too many wrongly answered questions. This ensures that the transactions and process of each user in that setting is undertaken carefully and safely. As for the payment method, it is not new to society and has a presence in almost all shops or vending machines; making that part of the usage of the concept more user friendly and with already existing methods of ensuring security.

USE

Users

For the users and their needs, we can divide them into three different groups. These are the primary users, secondary users and tertiary users. Each of these will be discussed in order below.

• Primary users, are the users directly into contact with the technology. In our situation these are the customers of the pharmacy, who will interact with the system to retrieve their repeated prescriptions and other medicines, and the pharmacists themselves, who will have to manage the storage of the medicines, keep track of what the machine is doing and adding repeated prescriptions. For the customer, the system will have to be easy to use. The user interface (UI) will have to be developed in such a way, that people will be able to use it without much training and experience. Another important need is that the system will have to work as efficient, and preferably faster, than the regular pharmacist now. Without this there is no real need to use the system. Finally, people will need to trust the system. Since no longer a human will be providing them, they might not initially trust the system and thus will not want to use it. This needs to be included into the development, so that such trust in the system can be improved. For the pharmacist the same needs hold. If they have to go through a lot of training to use the new system, it will be hard to implement the system in the pharmacies, and if the system will not be faster than current conventions, then there will also be no reason to use the system.

• Secondary users, are the doctors and other employees of the pharmacy. They will not work directly with the new technology, but still work in the same environment. For them the same criteria hold for the pharmacist. In some cases they might need to use the system, so they need to able to work with it without much training.

• Tertiary users, are the manufacturers. These will develop and produce the systems which will be used in the pharmacies. These will benefit by the profits gain from investing in this technology. This is further elaborated in the 'Enterprise' part of this section.

Society

For society the implementation of this technology will lead to an improvement in the overall experiences people have going to pharmacies. With this system in place, waiting times can be reduced and people will have a happier experience.

Enterprises

Multiple enterprises could benefit. On one hand there are the companies developing this technology. These will gain profits form making and selling it to pharmacies. Also by continuing to further develop the system and providing support to the pharmacies, will they be able to gain profit.

On the other hand you have the pharmacies and other pharmaceutical companies who will be using this system. These will benefit from having reduced costs for employment. Also, since the system will take over part of the current tasks, the pharmacist are able to work more flexible.

Implementation

Pros and Cons Table

The most important points while taking the implementation of this concept into account are things such as identity verification, issuance of non-prescribed medicines and the human assistance required to supervise and ensure the good functioning of such a system. These points are crucial for the optimum advantages that this system is supposed to bring forward.

Working through the concept as a project though, do bring certain pros and cons into consideration. For these pros and cons see the picture on the right.

For how to best introduce this system to society, we found some tricks in our research of trust of how best to do this. Once we have finished our prototype, we will try to let pharmacists (and doctors) test it and provide us with feedback (if there is any time left). Since they will have to work with the system, they will want to make sure that everything will work in the current system and that the safety of the patients will not be in danger with this automation. From this feedback the system will be improved and afterwards customers of the pharmacy will be able to test the it. This will provide us with additional feedback from the users perspective of how they experience the system. They will not so much focus on the medical aspects, but more focus on how well they can interact with the system and generally see if they like it. Having these test will improve the trust people have in the system and will gradually introduce the system to them instead of just putting the system in a pharmacy out of nowhere. Finally, after all these tests the system will be ready to be put into a pharmacy. It can be done in a few to start and see how things go and form this it can be expanded to more and more pharmacies. In the end the system will have to have a positive influence in the experience people have in a pharmacy and with these steps in the implementation. We think the system will be able to achieve this.

The system

In the current state of the art in the pharmaceutical industry there are only a few automated systems. The rest is still done (for the major part) by humans. One of the automated machine currently in use, is a machine to pick up your repeated prescription. It basically is a big vending machine outside of the pharmacy where you are able to pick up your medicine. Once your repeated prescription is at the pharmacy, the pharmacist performs all the regular checks and then puts the medicine into the machine. Next you will receive a SMS code to retrieve your medicine from the machine.

Since there are a lot of improvements to be made with automated systems, our project will focus on doing that. Now the storage of the medicine is all done manually. Everything is put into place by the pharmacists and once they need a certain medicine they will go to the storage and retrieve it themselves. Because we want to expand the current system of the repeated prescriptions to a bigger system, the whole storage of the pharmacy will be automated. All the medicines will be stored in an automated storage system. Multiple interfaces will be present for either the pharmacist to use or for the customer getting their medicine. The pharmacist will be able to store the medicines in the systems once they are delivered to the pharmacy and be able to retrieve all of them freely again. The user will be able to retrieve their repeated prescriptions as well as general medications like aspirin and bandage via another machine present at the pharmacy.

Flowchart of the system

We have seen that not all checks performed by the pharmacist are able to be automated. When the pharmacist has to open the box of the medicine to check if it is the correct medicine and if it is the correct dose, is one of these checks which (with currently present technologies) is not possible to perform by robots. Therefore we have chosen to automate as much as is possible with current technologies. This has resulted in the separation between the two different uses of the new system.

The flowchart (on the left) shows how the general process within the pharmacy will work with our newly developed system.

As can be seen, the storage is shared for both uses. Once the medicines are delivered, they are quickly checked (by opening the boxes) and then put into storage. Now a couple of different things can happen.

If a customer is going to the pharmacy to retrieve a medicine for the first time or a medicine where tight checks have to be performed, they will have to go to the present pharmacist. But now instead of having to retrieve the medicine requested themselves, the pharmacist can simply ask the machine to retrieve the specified medicine for them. While the machine is doing this, the pharmacist is able to ask the customers all questions necessary and check whether or not he is allowed to use it. Once this has all been done, the machine will have delivered the medicine and the pharmacist will only have to check if it is the correct medicine and has the right dose. This will reduce the time for these situations.

For the other situation; if a user calls for their repeated prescription, the pharmacist will use the same system to retrieve the medicine and will perform the regular checks they do now. Once this has all been done, the medicine will be put back into storage but with an extra (digital) label, stating that it is a repeated prescription for that particular person. Once this has all been done, the user will get a message saying that he or she is able to pick up their medicine. To make sure that the system can validate the identity of the user, a membership card of the pharmacy will be used. Once the user comes to the pharmacy to retrieve their repeated prescription, they will simply walk up to the machine and check their membership card. Once this is checked, a screen will popup saying that the user has a repeated prescription present, ready for pickup. Now the user can select to retrieve the medicine. He or she will also be given the option to buy extra medicines. A menu will appear where the user is able to select the medicines they require. If a certain medicine is selected, a screen with info about the general use of the medicine will appear and the user will have to confirm that this is indeed the medicine they wanted. If confirmed, a number of question will be asked regarding the current state of the user (if required for giving the user that specific medicine). Once these questions have been answered, the medicine will be added. Now the user will have to pay for all their medication and once this is done, the machine will retrieve them all from storage. Finally the locker/dispenser at the bottom of the machine will open and the user can get all their medicines.

From the above it can be concluded that the complete system of the Pharmacy Service Help Robot will consist of multiple different parts. The major parts are: the storage system, the user interface and the controllers. The system will physically be split up in the different parts. We will especially focus on the implementation of the user interface(s). The other parts are already developed or / and can be developed in the future.

Storage

The storage systems we will use are already developed and in use in many places. This allows us to not have to focus on this aspect when developing our system. We can however explain in further detail how this storage will work in our situation. We already said that in the current situation everything is done with manual storage and to improve on this we not only want to put the repeated prescriptions in the automated storage, but make the entire storage of the pharmacy automated. This means that even if someones goes to the pharmacist to get a medicine for the first time, so not via the automated machine, the pharmacist will still have to go to the automated storage to retrieve the medicine. The big gain here is the time. Since now the machine will grab the medicine for the pharmacist, they can in the meantime ask questions and explain to the user how to take the medicine.

All of this results in having to put all the medicines into one big storage. This will consist of the medicines only the pharmacist is allowed to hand out, the over the counter medicines and the repeated prescriptions. Once medicine is delivered to the pharmacy, the pharmacist will check them. Afterwards they will scan them, so that they are entered into the database of the storage and the system, and then they will be given to the storage. Now the storage machine will put them into the corresponding sectors. These sectors are made to allow a person, if necessary, to quickly check the storage without having to search everywhere to find the medicines. Now all medicines are in the storage system. If a repeated prescription medicine is requested by a customer, the pharmacist will simply retrieve it form the storage (or order it if not present) and perform all regular checks. Afterward it will get an extra label stating it is a repeated prescription for a specific person and then it will be put back into storage. Now the storage knows that this is a repeated prescription and a customer will be able to retrieve it from the machine.

User Interface

User Interface

The user interface is the part of the system that we will be focusing on. It needs to abide by certain criteria:

• User friendly to all age groups
• Understandable and clear information
• Touch screen or easy and well defined buttons and command points
• Available in most useful languages
• Able to interpret same medicine compositions but with different business or marketing names
• Able to scan customer/membership cards

The global cliënt-interface will be something like this:

• Step 1: Scan your card
• Step 2: Interface (screen) interaction
  • Screen 1: 'Repeated prescription' or 'OTC medicine' selection
  • Screen 2: Medicine selection
  • Screen 3: General information about the medicine and an option to add it to the shopping basket
  • Screen 4: Questions about the medicine (only for OTC medicine)
  • Screen 5: Return to screen 2 or continue (when all the medicines are selected)
  • Screen 6: Payment
• Step 3: Pay and get the medicines from the dispenser

The different screens according to the different options chosen by the users have to be comprehensible and straight forward to make the people more confident in using it; especially when dealing with health related issues, people might be wary of inserting or pick the wrong option or information. The color theme, as we consider it, is more advisable to be kept green and white (As shown in the picture), as these are the colors that people usually associate with pharmacy already nowadays.

Design of the user interface machine

Design of the user interface machine

The current system is a vending machine in the wall, which is not that attractive to place inside a pharmacy. To make the machine more attractive and to complete the concept, a design for the user-interface has been made. See the picture on the right and the pdf (Media:design_UI_machine.pdf) for an image of this design.

For the design it has been chosen to make an machine that stands in front of the wall instead of in the wall. Although, it should be against a wall, because the machine should be connected to the automated storage. The shapes of the machine are as round as possible to make it look more friendly. A green cross, which stands for (health)care, is incorporated in the design to make it visually more appealing. The user interface screen and the payment terminal are placed inside a niche to give the user more privacy. Underneath the screen a help button and a cardscanner are located. The help button is a physical button to make it more noticeable. The dispenser is placed directly below the niche where the screen etc. is located.

Pharmacist-interface

Also a pharmacist-interface will be needed, because the pharmacist will need to interact with the system. This interface will consist of multiple parts. The most important one of these is the log to keep track of everything that is happening with the machines. Every time a person picks up a medicine, the transaction will also be displayed on the log. Here the pharmacist can see which person picked up which items. The quantity and the time of the pick up will also be displayed. The pharmacist will also be able to see transaction which were cancelled, due to allergies or the person not understanding how to use the medicine. Other features are an overview of the medicines currently present in the storage of the system and a list of all the users in the system. The pharmacist is able to edit the users information with this list. Also new users can be added to the system and repeated prescription can be made.

Controllers

From the flowchart it can be seen that multiple controllers will be needed to make the system work. Multiple checks are always performed to make sure that the user gets the right medicine. One of the most important things is to check whether the user is not allergic to the medicine or is already taking other medicine which can cause problems if taken together. In our system this will be done by checking the database of the user and asking the user questions via the user-interface. In the database the physical state of the user and all the medicines the user is already taking, need to be listed for the system to work. However, the questions are also important, because a database cannot be trusted 100%. By comparing all this information, the system will be able to check if the user is allowed to receive the medicine.

Another important controller is the one checking if the medicine gathered from the storage is the correct medicine. This controller will have to check if the (contents of the) box correspond to the requested medicine. The pharmacist will check before the medicine is placed into the storage if the box and the medicine inside correspond. When this is correct, the pharmacist will add a label to the medicine, specifying which medicine (+ the dose of the medicine) is in the box. This makes it a lot easier for the system to check the medicine, since it is hard for a machine to open a box and look into it. If the medicine has been retrieved from storage, the controller will check via the barcode on the label if it is the same as requested by the system. If this is the case, the medicine can be given to the user and if not, another attempt will be made to retrieve it.

Smaller checks to see whether the user has selected the correct medicine and if the user understood the explanation of how to take the medicine are simple and will not need an advanced controller to work.

Size of Dispenser

The height of the dispensing machine is the most important point for the overall size of the object; aside of the size of the screen which should be around a tablet screen size. The height is important as per the users who have a range of height themselves, and especially for people who are on wheelchairs should be able the reach the screen or tilt the screen in an appropriate angle for use. The estimated height would be around 1.20 meters.

The inclination of the screen would provide the users with a non-reflecting screen and avoid glare to obstruct the visual; however, having a screen that can be tilt at any (almost any) angle at the users will might be more helpful to deal with the difference in height of the users.

The width of the dispensing machine would then be set proportional to the height according to the blueprints, as the width does not really have a direct influence on the user experience.

The height of the “call for help” button on the over hand also has a direct impact on the user experience for similar reasons as the height. The button should be low enough for people on wheelchairs to reach for instance.

Results

To design the user interface, we have chosen to use a website as a proof of concept. The results of our work can be found on the following web page: MEDispenser

Conclusion

The goal of the concept of the Pharmacy Service Help Robot, or the MEDispenser, is to reduce waiting times and solve the shortage of pharmacists and assistants. Literature research has shown that a few things can be improved in the pharmacy to solve these problems.

The literature learned that reducing waiting times in public pharmacies is more necessary than in the private pharmacies (See: Goal). Because of this, it is expected that the concept in the public pharmacy will provide a larger reduction in the waiting time than in the private pharmacy. In the quickest (private) pharmacies it might even be the question whether the MEDispenser actually will decrease waiting time / time someone needs in the pharmacy. Unfortunately, on the basis of the current research it is not possible to mention an exact time to show how fast it is for a person to retrieve medication by using the system. To do this, it is necessary to build a complete system, in which i.a. the automatic storage need to be deal with.

However, what can be concluded is that the implementation of the MEDispenser in the pharmacy will provide a larger distribution of customers. Not everyone requires the help of the pharmacist, because a large proportion of customers could be handled by the system. Consequently, a customer does not have to wait for any other customers, or at least wait for fewer customers, because several queues will be formed. This results in shorter waiting times for every customer.

The previous paragraph immediately brings us to the goal of solving the shortage of pharmacists and assistants. One MEDispenser could help a part of the customers. When a number of MEDispensers are situated in a pharmacy, fewer pharmacists and assistants are required to handle all customers as quickly as possible. In other words, there are fewer pharmacists necessary to form the same number of queues. Of course, there will always be (older) customers who would like to be helped by a person, because of the fact that they do not understand the system or do not ‘like’ computers. For this reason, it will be necessary that one pharmacist is present in the pharmacy. In addition, there also remain still tasks that cannot be done by a machine at this moment with the current pharmacy protocols and techniques. Examples of these tasks include the control of the medicines in the boxes.

To conclude: the Pharmacy Service Help Robot will solve a large part of the problems within the pharmacy. However, before the system is able solve all the problems, it still takes some time / work. By building the interfaces we have tried to show that there is a future for this concept. We tried to do this by making these interfaces as easy as possible with all necessary protocols, questions etc. incorporated in it.

follow-up research

Before the concept can be introduced into the pharmacy and society, there is still much research to be done. A good next step is, in our opinion, proper testing of the interfaces with both the pharmacists and the customers (we were unfortunately not able to do a proper test). On the basis of these tests, the interfaces can be improved. Later research will mean that the entire system needs to be built and tested.

After testing and improving, the system can be implemented in the pharmacy. During the implementation in the pharmacy the users should be properly introduced to the system in order to gain confidence.

Much later, when there are more possibilities, the tasks, which are unlikely to automate at this moment, can be included. For example: checking the medicine inside the boxes. These techniques will, however, be relatively easy to add to the system at that time by, for example, placing a module before the "medicine-input compartment”.

Planning

The Gantt-chart for a good overview of the planning

On the right a Gantt-Chart is shown that we made in the beginning of the project to get a good overview of the planning. We tried to stay with it as much as possible. To see which groupmember did which tasks, take a look at the Logbook Group 3.

Reflect on the planning

In week 1 the concept is devised. In the first instance, the problem had to be defined. When this was known, we came up with the solution for the problem: the concept. After developing the concept a little, research was required into i.a. current systems. The problem, the concept and the research needed to be presented in presentation 1 (week 2).

After presentation 1 we received feedback about our concept etc. The feedback had to be processed in week 2, before presentation 2 (week 3). An important part of the feedback was that the research should go deeper to support the problem better. Unfortunately, we could not finish this before presentation 2 because we wanted to interview a pharmacist and we wanted to distribute questionnaires. These things, however, took more time than expected. Also the concept had to be devised more and needed to become clearer.

During processing the feedback we already started to implement the system. We also got the instructions for the wikipage after presentation 1, which resulted in the fact that we needed to start working on this as well. We started doing this dedicated in week 3. The feedback of presentation 2 did not get any better. As result, we needed to do a lot in week 3 to convince the teachers that the problem was a real problem and that the concept was great.

In week 4 we had to describe the concept detailed, because during the meeting on Monday it became clear that this was not done enough. This was the most important thing that we needed to do this week. Furthermore, we started working a little on the implementation of the concept. We started with investigating how we could implement our concept. We had done this to start implementing in week 5.

We started working on the implementation of the users-interface in week 5. First we all thought good about all the different screens, searched for a list with medicines that we could use in the simulation database and thought of the questions that needed to be asked. In the end of week 5 we divided the work to take a better look at all these aspects.

During the meeting on Monday in week 6 we heard that we had to work harder. To prevent that we would not be able to reach the deadline, we started working really hard in this week. We decided how all the screens of the users-interface would look like and a part started implementing this. Also a part of the group started working on the pharmacist-interface. The data for in the simulation database was completed, the questions were worked out properly and a drawing of the machine was made.

During week 7 we tried to finish the interfaces. However, it was more work than we thought, so unfortunately we did not finished it. Furthermore we worked on the wiki to complete the description of our concept and process.

In week 8, 9 and 10 we finished the project and prepared the final presentation. In first instance, we tried to complete the system in time that we could do some user-tests. After finishing the implementation there was some time left for user-testing, however there would no time be left to process the results of these tests properly. Because of this, we decided to skip the user-tests. During these weeks we also tried to describe the concept, process etc. on the wiki as detailed as possible. The most parts were already written, but needed some expansion or improvements. Of course, also the presentation was prepared.

During week 11 we improved and expanded some parts of the wiki to answer the questions that were asked at the final presentation.

Files

• Media:Concept_presentation_group3.pdf
• Media:Feedback_presentation_group3.pdf
• Media:UI_screens.pdf
• Media:Specific Medicine Questions.pdf