From CS160 User Interfaces Fa06

Contents 1 Introduction 2 Implementation and Improvement 3 Method 3.1 Participants 3.2 Apparatus 3.3 Tasks 3.4 Procedure 4 Test Measures 5 Results 6 Discussion 7 Workload Breakdown 8 Appendices 8.1 Consent Form 8.2 Demo Script 8.3 Raw Data

Introduction

As the number of patients in the healthcare industry grow, the quality of contact between professionals in different sectors decreases. In many hospitals, doctors work long hours while writing and signing prescriptions for their patients’ ailments. The prescription which may have errors is given to the patient who then delivers the form to a pharmacist. Without knowing the patient's medical or drug history, the pharmacist gives the drugs to the patient. The limited flow of information between the pharmacists and doctors may result in future drug or physical complications for patients.

With NextRx, a high-fidelity communication channel will be opened between doctors and pharmacists as they share information across a database. NextRx allows for a faster, safer, and more reliable information stream. In theory, the time and errors for pharmacies and doctors should be reduced.

The primary goal of our project is to design an interface to deal with digital prescriptions. This improved and unified system for prescription distribution should serve to increase patient safety. By designing an efficient system for prescription tracking, the stress on both doctors and pharmacists should also decrease.

Implementation and Improvement

Since the hi-fidelity prototype we have been working on the base functionality and the system’s interface. These changes are a direct reflection of what was voiced during the interactive prototype presentation. To start, most queries have been written and the components now share access to the permanent database structure. We have also made a slight schema revision to make the status of the prescription easier to deal with. Previously we had two status flags because we thought the doctors and pharmacists might want to know different things about the progress of a prescription. We decided it would be better for the database to contain one status field that could record three situations: either the prescription is unfilled, filled or picked-up.

One other issue we have had to deal with is that operating the pen in batched mode (docked) may not be possible until further changes are made to the toolkit. Thus, for now we are switching to streaming as a stopgap so that the pen can get some use. A related issue brought up during our presentation was a desire to see the strokes. This makes a lot of sense because we can limit the need to switch between computer monitor and hard copy of the prescription. Thus we now are displaying strokes (similar to HelloWorld) in the recognition form used by doctors. Ideally, in some future implementation we might highlight the field on the active region that pertains to the text field being reviewed.

We have also spent a great deal of time investigating handwriting recognition. After some assistance from Ron or the TAs we should be able to acquire the recognized text and throw it into our recognizer form. While we used the handwriting recognition debugger we realized that without training the current recognition is woefully inadequate. It only managed to recognize the writing of 1 member of our group “out-of-the-box.” We might suggest a different (possibly open-source) engine to Ron to improve the toolkit.

We took the time we had to make a couple of improvements to text labeling in the interface. Prompts and dialog text were reworded to sound more intuitive. These changes should hopefully lower the learning curve for learning to use the interface. Additionally some widgets were totally unnecessary while others were desperately needed and so we revised these parts of the prototype.

The last issue we looked into was the drug interaction database. Unfortunately, most websites just provide an interface to their own databases without providing any underlying access to the database itself. We tried to contact a couple of these sites and are currently awaiting a response. An option we might have to resort to is to choose one of these sites and query them automatically. The downside of this method is the required bandwidth for both the hospital and the provider. Additionally, if the site were to ever change our parsing strategy would have to change with it.

Method

Participants

Our project contains three separate components designed to be used by three separate users. Acquiring nine separate users (three administrators, three doctors and three pharmacists) can be exceedingly difficult because of the hectic schedules of these users, expounded in the introduction. Though these domain users have the most to gain their vital job must come first. Thus, we would prefer three individuals who could evaluate all 3 components in an unbiased fashion. The three participants were college students majoring in Cognitive Science, Computer Science (he has not taken 160 or any other equivalent course) and MCB (pre-med), respectively. They are all between the ages of 19 and 25. These would be non-domain users who knew what purpose the software served but were otherwise untrained in its use. This is quite in line with Marin’s “Doing Psychology Experiments” that discusses pilot study testing with less specialized participants. Technically, this is only a test to gauge our experimental procedure and quantization, so the actual user is inconsequential. However, a positive side-effect is that we can evaluate these users’ performance with our tool against the medical system currently in operation. Obviously, NextRx shows a lot of promise if untrained users, who have never dealt with prescriptions before, can use the system faster than current methods.

Apparatus

We wanted a quiet setting for our testing so we opted for a medium size room in Soda Hall. The room had a big table where all of our equipments stayed nicely and about five chairs. We used an IBM ThinkPad laptop for our graphical user interface and database. A Nokia SU-1B digital pen was used for writing. Our prescription form with dot pattern (paper UI) was printed on a high-resolution system in Soda. We also used a stopwatch to measure the timing for each task and a regular pen and paper to note all the events, confusions and errors experienced by our users.

Tasks

We have three distinct participants, having different tasks for all of them. The administrators’ main job is to oversee the doctors and serve as “trusted sources” of information. Our task for them is to maintain a centralized listing of physician information. Keeping track of all doctors is a relatively simple task and is accomplished just as easily with NextRx. In our system this simply amounts to adding a record for a doctor in the doctor-pen database. Adding or removing users can also be carried out by clicking on the appropriate button. Adding and removing a user is the easy task we will be evaluating. Organizing this information can be a more challenging task especially when it spans departments and hospitals. We allow the administrator to view the database in a nice organized tabular form. To measure performance here, we will ask a user to search for a given doctor with certain properties by sorting. A very difficult task is safeguarding and remembering all identifying information for a doctor. Add user will add the information about a new physician and his pen identification number. The secure database is additionally safeguarded by the administrator. This task is harder to measure, because time is not the factor but rather security. We assume that a database management system which has been password-protected is reasonably secure.

We focus more on various tasks of the doctors since they’re the only users of the Anoto pen itself. The easiest task for the physician is just writing the prescription itself. This task remains simple because the user does exactly as usual, except using the Anoto pen to fill out the form (paper UI). We ask the user to perform just this task, ensuring that they take no longer to fill in the information than with the current pads. It is important for a doctor to be able to check old patient records before consulting with them. This can be moderately challenging task with the old methods. With our system, the doctor can easily search the database which is a very natural operation. Again we measure performance here, by observing how quickly a user can find a patient. The most important task for a doctor prescribing medication is to make sure that patient receives accurate and safe drugs. Our system won’t update the database until doctor makes corrections for those things that we can automate checking. That is, after docking the pen, the physician needs to check for errors and make corrections before anything is added to the database. In the current implementation this amounts to having the right data type but we will soon be including more advanced drug checks. Here, we check that the user can in fact catch simple mistakes in recognition.

The pharmacists have their own view of the database and need only interact with their own database. A task for pharmacists is to register new patients. The user gets valid prescriptions by searching through the database by entering patient information. Once pending prescriptions are found, the prescriptions can be added to the queue by hitting the appropriate button. A moderate task is sorting priorities, we can include any field to keep track of what needs to be done urgently and then sort by it. We have not introduced priority flags yet, but we did ask users to fill prescriptions for those who have been waiting the longest first. A difficult task for pharmacists is to keep information moving smoothly through the pharmacy. Our system provides queue and retrieve mode for pharmacist to check the flow of information. We tried to ascertain whether the users could see the effect their actions in register mode had on the queue. If a single inexperienced user working on only one computer could tell what was happening, then surely pharmacists with two computers in the different views could do the same.

Procedure

After choosing our participants we provided each with a consent form that we also discussed verbally with them. The consent form contained the test process, benefit and goals of the prototype test, guarantee of anonymity, and the option to retract participation in our test. Finally, we made sure the only trace of a participant’s identity was their signature on the consent form. We emphasized the participant could opt out at any time if they felt uncomfortable (and their feedback would not be used in the study). After the formalities we took our users to a quiet room to test our prototype. We started our testing process by giving them a short demo of our system as described below in script section. After that we decided to test one user at a time to have less biased opinions of our interface. We chose the order of the participants randomly. We kindly asked other two users to step out of the room while the first user is being tested.

We explained to the participants our three distinct user groups and informed them that they’ll play all three roles and carry out corresponding tasks. Each user was started in a different role so that after using three participants no one would be biased with the position they started from.

We will start by discussing the procedure used on the administrator. We explained to the subject the duties of an administrator in general and with our system. With our system, an administrator’s main job is to maintain a doctor-pen database and to achieve that goal he or she should be able to manipulate the data in the database. We gave the user the task of adding a new user, in other words, adding all the necessary information for a new doctor and his/her pen. After the user completed that task successfully, we asked the user to organize the database as desired by sorting any data fields in the interface.

Next we discuss the procedure for doctors. The first task as a doctor was to write a prescription for a patient using Anoto. As mentioned above, the user was provided with our paper UI and an Anoto pen. The second task was to make sure all the information that appears on the dialogue box recognized by the recognition software matches the prescription. The whole point of this task is to make sure no wrong medications are prescribed before updating the database. After successfully completing this task, we had our user to search the database by any field to get the desired information about the patients.

Finally, we discuss the procedure for pharmacists. Our user now dons the role of a pharmacist, whose main function is to read patients’ prescriptions and fill them accordingly. We gave the user a task of retrieving new patients’ prescriptions by providing necessary patient information and hitting the appropriate buttons. After that we asked our user to queue up all the valid prescriptions so that they could get filled. Lastly, we asked the user to complete the transaction by hitting the appropriate button in the queue mode.

We debriefed the finished participant and expressed our gratitude for their time. Then we swapped out the finished user for an unfinished subject and followed the same procedure outlined above. We again make close observations about their approach to the interface and any problems they had running the system. We also paid close attention to the issues that caused the largest delays or created gaps in conceptual understanding. The section below provides more information about the test measures and their importance.

Test Measures

Our test measures included number of errors users made, number of times users were confused about something and asked us questions, number of times users expressed their positive feelings about the interface and total time the users took to finish the tasks for the given user.

Part of our iterative evaluation cycle involved making quantitative measures. We tracked the number of steps and time the user took from writing the prescription to processing the request at the pharmacy because the ultimate goal is to make prescription processing as fast and safe as possible. Though current processes may be rapid they allow for an unacceptable number of errors. We decided to measure these things to find out the difficulty of our interface. For example, by tracking the number of errors that occurred in each test and when they occurred, we can make necessary changes to make our interface more user-friendly. We kept a table of the different steps and sections of our process. With each test, we marked the sections that had an error and made a note on the details of the error.

Another aspect of quantitatively tracking the test was to time confusion on the part of the user. If the user was stuck, we emphasized that they should tell us and describe the issue. We recorded the thought processes and time throughout the steps leading to the issue.

We also asked the user to rate the experience on a scale of 1 to 10. 1 represents a difficult and troubling experience and 10 represents an incredibly intuitive and pleasant experience.

Results

Overall the users groups performed fairly well with the various interfaces. They particularly liked the more descriptive buttons on some of the interfaces. This was something that they “had not seen.” The subjects did very well manipulating the data in tabular form. Virtually no mistakes were made during this interaction. Some of the other tools for which the user had no pre-conceived schemas or metaphors caused a bit of frustration. We state the time taken to complete each task and paraphrase the thought process and comments made about the interface by the user. (All gender pronouns used here are assigned at random; they have no bearing on the actual sex of the participant).

We started by testing him with the database that doctors interact with. The total time he took to complete these tasks was about 4 minutes and 22 seconds. He finished his first task in one minute, which was to write a prescription form using Anoto pen. There weren’t any confusions or errors for that task. Since the hand writing recognition is not in place, a person serving as the “computer” entered the fictitious recognition. Assuming all the information was correct on the dialogue box, he almost missed to select the pharmacy since we were missing a drop-down arrow. He said it didn’t look like a drop-down menu without the arrow. He had then no problem hitting the appropriate button and updating the database. That task took him about 1 minute and 10 seconds. Then we had him do the task of searching the database. He searched over various fields several times and was happy with our search functionalities. This task took him about 2 minutes and 12 seconds, there weren’t any major questions or confusions he expressed doing that task. Next in the position of administrator, he took a total of 2 minutes and 20 seconds to finish. He spent most of his time adding the new user since some of the data fields such as DEA No. and MD ID code were foreign to him. Then he was confused about which button to click in order to update the database since our buttons are named “Add” and “Done”. He paused after entering all the information wondering about which button to click to move forward with the task. We then explained to him that clicking “Add” button adds the entry to the database and “Done” closes the window meaning all the users are added. Our interface allows the users to add multiple entries without closing the window. After he understood that, he was okay with it but suggested that we should only have one button to avoid confusion. He had no problem sorting different fields as it was simply done by clicking the arrow on the header. Finally, we gave him the tasks of a pharmacist and he took approximately 2 minutes and 40 seconds to finish them. He had no problem retrieving patient’s prescription, finishing the task in 40 seconds. After that he selected the prescription and hit “Add to queue” button and paused for some time as nothing happened. But he quickly recalled from our demo that there were two views of this database and changed the view to “queue” mode and was happy to see his prescription in the queue. After that he had no problem hitting the appropriate button as the buttons were “very descriptive” and finishing off the transaction. Those two tasks took him about 2 minutes and told us that pharmacist tasks were much easier than the other two. Overall, he rated our system 7.5 out of 10.

Our second user started in the role of pharmacist. The tasks for the pharmacist took him about 3 minutes and 10 seconds. He spent about 1 minute and 45 seconds in the retrieve mode, retrieving different prescriptions and sorting them. He mentioned that sorting was “really cool.” He suggested that maybe we should make “status” field bold since that’s what is most important to the pharmacists. He spent another minute or so in the queue mode, sorting various fields again and switching back and forth between “queue” and “retrieve” mode to confirm his prescriptions were added correctly. He spent rest of the time on the transaction dialogue box and suggested that we should add an option of “Other” in the insurance provider drop down menu. Next, as an administrator our second user took 1 minute and 38 seconds to finish. He also shared the first user’s frustration with the “Add/Done” button combination. He felt that it was good because it lets you add multiple users at one go. He said it was only a one-time confusion so “it’s not a big deal”. Moving on to the tasks for the doctors, our users took half a minute to complete the first task which was to write a prescription form. Other tasks took him a total of 2 minutes and 30 seconds. He had no problem interacting with the dialogue box that confirms all the fields before updating the database. He said it was “pretty straightforward”. He had several issues with our search functionalities as the “Reset” button didn’t do what he thought it would. He also mentioned that data field “issued” wasn’t clear since when he tried to search by that field he wasn’t sure what to enter. He suggested that we should change it to “Time issued” to avoid confusions. Overall, he rated our system 7 out of 10.

Our third user started in the role of administrator. She took 1 minute and 10 seconds to finish the administration tasks. She said it was good that we kept all the information about doctor’s identity in the database because doctors are sometimes referred by their codes. She liked the look of our database and mentioned that “it’s very simple to use and it’s very similar to windows search application”. She had problems removing the entries from the database as it removed the wrong entry from the database. She completed the tasks for the doctors in 2 minutes and 27 seconds. She had no problem writing prescription with Anoto pen and confirming the entries afterwards. She spent most of her time doing the search and mentioned that we should let users search by all the fields rather than three, which is what we currently have. She took a total of 3 minutes to complete the pharmacist tasks. She had no problems retrieving the prescriptions but suggested that we should clear out the text in the field after the prescriptions have been retrieved. We also observed as she hit “retrieve” button multiple times, it produced the same result even though the entry was already in the database. Just like the first user, she was confused about what to do after she clicked “Add to queue” button. After we instructed her to switch to “queue” mode, she had no problems finishing up the remaining tasks. Overall, she rated our system 8.5 out of 10.

All three users mentioned that the idea for the project was really good and by fixing some of these errors and adding more functionality, it could become extremely beneficial for doctors and pharmacists.

Some summary statistics:

Timing

Administrator

• Mean = 2 mins 8 secs
• Standard Deviation = 41 secs

Doctors

• Mean = 3 mins 27 secs
• Standard Deviation = 47 secs

Pharmacist

• Mean = 2 mins 57 secs
• Standard Deviation = 15 secs

Errors

Administrator

• Mean = 0.6667
• Standard Deviation = 0.5774

Doctors

• Mean = 0.6667
• Standard Deviation = 1.1547

Pharmacist

• Mean = 1
• Standard Deviation = 0

Confusions/Questions

Administrator

• Mean = 2.333
• Standard Deviation = 1.155

Doctors

• Mean = 2.6667
• Standard Deviation = 1.1547

Pharmacist

• Mean = 2
• Standard Deviation = 0

Discussion

First we note that overall ratings have dropped since the low-fidelity prototype. We do not feel this is due to design, but rather problems and time constraints in transitioning from our hand-drawn prototype to code. Some of the issues that came up are a direct problem with the backend. GlazedLists is the reason for the deletion problem encountered by the third user. Though serious, this is not so much an interface problem as it is a programming bug. Additionally, users who have no background in prescription handling may have been slightly more frustrated with the metaphor than veterans in the field. In fact participant three, who gave us the highest rating, was the pre-med student. Her rating may be due, in part, to the fact that she was more familiar with the prescription-filling model.

It should also be noted that aside from checking the recognition of the data (which is expected to add to the doctor’s time), all management of the data was faster for our non-domain novices than the methods we discussed in the contextual inquiry. Handling prescriptions in the pharmacy took about half the time (granted conditions were ideal). So the system certainly has the potential for improving speeds which wastes less of the patient’s valuable time in line.

Clearly, there are some issues all participants had. The “add/done” buttons in the add doctor dialog was a continual cause of frustration. The done button was used because initially populating the doctor table is laborious enough without having to click “add user” after every entry. Obviously the wording here may not have been the best. The clearest solution is to change the name to something like “add user and insert another.” We think taking the button out altogether is not a good idea, since one user actually liked the idea once it was explained.

Other issues are a result of a lack of time to add in particular widgets. For example, we were planning to throw in the arrows to indicate a drop-down. However there were other more pressing concerns, so we did not have a chance. We will certainly add the arrows in for the next iteration.

Another issue brought up was the search functionality. We have changed the design since the initial low-fidelity prototype to make coding easier. The first issue with this three-field search is that it constrains the user to searching over only three fields. The second is fields like issued don’t have an obvious search parameter. After all, no one can be expected to keep track of the exact second their prescription was added to the database. The name is easily changed to time issued, but we must also fundamentally change the way we search for prescriptions by timestamp. One possibility is to allow for searching over a range of values. What should also be placed by the timestamp search is the exact format for its entry. From what we have observed most individuals would not need to search over more than three fields, but limiting it seems arbitrary and is bound to catch some user’s attention. If time permits we may revert to our low-fidelity design, though it is fairly difficult to code. In terms of functionality the original design also affords searching with ORs as well as ANDs.

Transitioning between queue and register modes is not too much of a concern. In reality we would expect register mode to be on desktop consoles where someone is registering patients and queue mode to be on some big display which all fillers could interact with. Superficial issues like bolding the status field can be taken care of easily. Sorting on status would also be advisable because that is the first way most users would divide the data. A secondary sort on priority or date issued would also be useful.

Workload Breakdown

• Rayhan Lal (25%) – Helped write queries, investigated drug interaction database (see implementation section for more details) and compiled everything for final write-up.
• Michael Mai (25%) – Investigated handwriting recognition, wrote ink viewer for confirmation area, troubleshooting and support. (See implementation section for more details).
• Utsav Shah (25%) – Conducted experiments, collected data and integrated it into various sections of the report.
• Jason Shangkuan (25%) – Worked with GlazedLists, performed UI cleanup, linked elements of project. (See implementation section for more details).

Appendices

Consent Form

CONSENT FORM FOR PARTICIPATION IN A STUDENT RESEARCH PROJECT FROM THE UNIVERSITY OF CALIFORNIA BERKELEY

NextRx User Interface Project

NextRx is an integrated system, utilizing Anoto pen technology, designed to provide a faster, safer, and more reliable prescription. Using the NextRx applications, medical professionals and pharmacists can help record, organize, and check prescriptions electronically. Overall, the NextRx system is designed to reduce time and errors for both pharmacies and doctors while increasing the security for patient prescriptions. Currently, the project is under low-fidelity prototype, drawn and set-up on paper for quick and easy changes. You will be asked to assess and walk through the basic functions of the system. Your input during each step of the prototyping is highly valued and appreciated.

I, _____________________________, have been asked and agree to participate in the pilot study of the NextRx system. The information gathered in this study will only be used to aid in the development of the application as a Human Computer Interaction project. I understand that the study will preserve my anonymity, and no identifying information will be used in order to maintain privacy. I also understand that participation is voluntary and I may refuse to answer questions, refuse to participate, or withdraw at any time.

I AGREE TO PARTICIPATE IN THIS RESEARCH PROJECT AND I WILL RECEIVE A COPY OF THIS CONSENT FORM.

PARTICIPANT'S SIGNATURE ____________________________ DATE ______________

• PERSON OBTAINING CONSENT:

I have explained to the above named individual the nature and purpose, the potential benefits and possible risks associated with participation in this research. I have answered any questions that have been raised and I will provide the participant with a copy of this consent form.

RESEARCHER'S SIGNATURE ____________________________ DATE ______________

Demo Script

Hello sir/madam. I am Utsav, a student taking CS160 and along with my group consisting of Rayhan, Jason and Michael. We are a group of Berkeley students working on a project for our CS160 User Interface course. Our interface project is designed to make use of the Anoto pen technology. The pen is designed to record exact pen strokes made on paper and send the data to a computer to save it as a digital copy. With our interest in the medical industry, we decided to create an application to assist doctors and pharmacists digitize and combine their data. We would like to thank you for agreeing to participate in testing our prototype of the NextRx. This prototype testing session will last approximately half an hour. Please read over and sign this consent form before we continue. If you have any questions or concerns, feel free to stop us at any time.

Our project, the NextRx, is designed as a means of recording, organizing, and checking prescriptions electronically for quick and accurate information transfer between doctors and pharmacists. With the implementation of a patient database, the NextRx will allow for a faster, safer, and more reliable prescription-medication interaction.

Do you have any questions before we begin the testing exercise?

We will be providing you with a computerized model of our interface for the NextRx system. Be aware the system is in a development state so do not assume it will necessarily function correctly. You will play the part of an administrator, doctor and pharmacist. Let me start by giving you a quick overview of the system and what each component is designed to do. Feel free to interrupt for questions.

<Open administrator tool>

This is the administrator’s tool it allows trusted people to add or remove doctors from the system. The table holds an association between various doctor IDs and the ID of the pen he or she carries.

<Get paper UI>

This is our prescription sheet; you will be filling this in for some fictitious patient based on the data I provide to you.

<Open prescription verification tool>

This is a tool for physician’s which allows them to check that the recognition performed by the computer software is accurate. Once it is verified here the prescription will be added to a database. <Click to transition to doctor database>. Here is the doctor database it basically contains one entry for every prescription, various search operations are provided.

<Open pharmacy tools> This is the pharmacy tool it has entries for prescriptions just like the doctor database, only certain details are hidden. There are two view modes, one for those registering patients initially and the other for filling the prescriptions and completing the transaction.

I know that tutorial was brief, but we need to test how intuitive the interface is without explaining all the details. If you have any question about the general process of prescription filling feel free to ask now.

OK then, we’re ready to begin I will assign you a role and give you instructions. Do the best you can and remember if something slows you down or gives you pause, that is our failure and certainly not yours. Please report to us anything that comes to mind during the evaluation of this interface.

<Utsav chooses random role now>

Administrators

This is our interface for a doctor-pen database. Please add a physician, feel free to make up any fictitious data you like. Be aware that this data may be presented to others. If you have any thoughts to share while running through this interaction please share them with us. Great job! Now please remove the user you just added. Again, thinking out loud will be very helpful to us. Using any means at your disposal, please find for us Doctor X (chosen at random). (If they seem to be having difficulty, remind them not to worry – it is a failure of the interface not them.) Fantastic! We are now done with the administrator’s task if you would like a break please feel free to let us know.

Doctors

This is a prescription pad; you’ll notice a dot pattern over certain regions. The pen we are giving you reads in that dot pattern to determine its position on the page. The areas also specify certain fields that are added to a database when the pen is docked at a nearby computer. Pretend we are at the end of an appointment and you are prescribing certain medication for some fictitious patient. Please fill in the prescription sheet with whatever fictions data you like. Be aware that this data may be presented to others. If anything comes to mind while filling out the form, please let us know. The next interactions will generally occur while the patient waits so you can question them about other drugs they may be taking.

Great job! Now during this process the data is sent via either Bluetooth or a USB dock to the computer. The screen here is used to verify the computer’s recognition of your writing is accurate. It appears automatically for each prescription upon docking. Please verify the recognition of the prescription you wrote a few moments ago. Once again, you have done well. Now once you are done verifying, the database itself will be displayed. We’d like you to start by showing us how you’d search for Patient X (chosen at random), who has a medical ID of f(X). Again, thinking out loud will be very helpful to us.

We are now done with the doctor’s task if you would like a break please feel free to let us know.

Pharmacists

You will be dealing with a specialized database interface that is closely associated with the other components of the system. If a doctor knows the pharmacy the patient will be picking up his or her prescription from, it is automatically added to the queue. Otherwise a patient must present a prescription and identification. Entering the identification in register mode causes a database query for unprocessed prescriptions. A customer/patient brings in a valid prescription and his ID. (Give data for someone who has prescription). Please register him. Now find and queue his prescription X (chosen at random). Please share any thoughts you might have about the system with us.

Well done! Now we’ll see how the system works with fillers and cashiers. In queue mode you can see pending prescriptions, please show me what you would do if you just finished filling a prescription and wanted to mark it ready for pick-up. Now, that the prescription is ready please handle the purchasing of the medication. Again, thinking out loud will be very helpful to us.

For Everyone

Thank you once again for testing our prototype. Your input is highly valued and will be used to improve the quality of the interface.

Raw Data

For more detailed recorded data see the results section.

---