LoFi-Group:The JURMs
From CS160 User Interfaces Fa06
Contents |
Names and Role in Assignment
- Rayhan Lal – Served as facilitator during prototyping. Prototype description, results and discussion write-up.
- Michael Mai - Served as computer during prototyping. Introduction and mission statement and appendix.
- Utsav Shah – Served as observer during prototyping. Participants, environment and tasks.
- Jason Shangkuan – Served as greeter/mock patient/observer during prototyping. Procedure and test measures.
Introduction and Mission Statement
As the number of patients in the healthcare industry grow, the communication 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 lack of information exchange 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 will also decrease.
Prototype description
At this stage in the design process we tried to deal with more concrete specifics than in prior sections. We began with the paper UI (see figure below), looking for ways to prevent extraneous input based on the affordances of the NextRx system. The prescription form must: (1) identify the physician, (2) identify the patient, (3) give a brief description of diagnosis and (4) provide information about the prescribed medication. We modeled the design around an existing prescription form currently in use. Since the system stores doctor-pen relationships, the only trace of a doctor’s identity need be a name (and even this is only necessary so that a record exists on paper). If for some reason a pharmacy needs more information about a physician the hospital’s main line is listed in the upper-left hand corner. We assume, without loss of generality, that a patient name and medical record number uniquely identifies a patient. Thus, these are the only two fields we put on the form to identify the patient. Normally an ink impression is taken of the patient’s medical record card, but their name must still be written. Writing a medical record number should not be a terrible burden considering all the fields saved in identifying the doctor. Additional space is allocated for diagnosis to encourage physicians to be more forthcoming and descriptive. The tabular arrangement for drugs is identical to that found on the template form, only drug interactions have been removed (since these are stored and dealt with on the computer end).
As an illustrative example of our database viewer and standard implementation decisions is our secure tool for establishing the doctor-pen relationship (see figure below). For any database we list fields across the top of a table, that is, each column is a field. A row represents a complete record. By default we sort on some convenient field in an ascending or descending order. One can sort on any field and toggle ascending/descending by clicking on any column heading. An arrow will serve as a graphical reminder of how the collection is sorted. The buttons are deliberately labeled in as direct a manner as possible. Clicking “Add User” for example will bring up a dialogue which allows one to fill in the fields for a record. If anything is missing the system will throw out an error asking for the necessary fields. One can also edit existing records by selecting a row and then hitting the delete or missing/stolen buttons. The latter button would flag a particular pen. All prescriptions written after this would be voided and any computer where there is an attempt to dock, can be reported. Whenever possible we try to add descriptive text in particular frames of the interface. It is intended to be instructive for novices but not distracting for more experienced users.
The field delineator tool (see figures below) need only be run when there are changes made to the standard prescription form. The field editor opens a form stored in PDF. The user should be able to navigate this file just as he or she did in Acrobat. A sidebar takes up a fixed portion of the screen to the right of the document. Here you find precise instructions on selecting regions of interest, that is, fields with data entered with the Anoto pen that should be recognized. There will be buttons representing some common data types, and when one of these is selected a crosshair will appear, allowing the user to draw a precise box around the area where someone will write. Note this is not quite modal because after selecting the data category and creating a field you must select a type again. After creating each of these areas, one will be prompted to name the information this area represents. The user can move the small prompt and look directly at the form to decide what to enter here. This will be directly reflected as a field in the patient medication database. Unfortunately, because of the structure of a database certain conventions must be enforced in order to associate items (these are all described in the field adder prompt). If an error was made, the field can be resized and simply double-clicking the field will allow for editing the field identifier. The user then saves this file under some default name (say prescription.rsf for region specification file). For now all our other programs will use this file alone but one can imagine allowing rsf files for different forms. We would like to make all parts of the process extendable to any form or chart. Thus, the form explorer is included rather than hard-coding certain fields (basically generating the rsf file by hand). One can also export the form, once complete, to another PDF file which will contain the special Anoto dot pattern.
A doctor begins by writing prescriptions towards the end of an appointment. While the patient is still available, he or she will dock the pen and a pop-up will appear on the screen of the computer. This serves two purposes: (1) it confirms that handwriting recognition performed properly and (2) it allows the physician to specify the pharmacy the patient will pick-up his/her prescription from. All recognized fields are brought up and users can either approve or correct the data. If one opts to correct the field, and the recognition package supports training this will adapt the recognition for that user. Now for the reason we made the patient wait: after all entries are approved the system checks for drug interactions before adding to the database. If a problem is detected a summary message explaining the conflict is displayed. The doctor can view the full record, change the medication, cancel the prescription altogether or after investigating with the patient ignore the problem (if it turns out not to be an issue for some reason). Only after all issues are resolved is the record finally added to the database. If the patient’s pharmacy is known a request is sent to the pharmacy to add that user’s prescription to the pharmacy’s queue. The viewer (see figure below) opens up with all entries by default, but can be easily searched over any and all fields. This view, as opposed to that for pharmacists, displays all prescriptions even if they are no longer valid. A prescription that has already been filled will be listed in green, while unfilled prescriptions are displayed in red.
Within the pharmacy application are two views: queue and register, selected via the view menu. The queue mode (see figure below) is for those filling the prescriptions and carrying out the final transaction with the customer. Orders are by default displayed in the order they were issued. This mode is pretty static, essentially just a list of orders to be filled. When a prescription is ready, the entry is selected and a “filled” button is clicked. One important item we neglected until now is a transaction applet. When a customer arrives to pick-up their prescription, they are located on the queue and the “pick-up” button is clicked. This brings up options for selecting insurance and gives grand totals. Once an insurance provider has been set for a particular customer, the value is held as default for that customer until changed.
The register mode is for registering patients. To make things as simple as possible and to utilize all the information the physician has entered, only the patient identification is required. The pharmacist always starts by entering a patient identifier and no information will be provided until a valid identifier is entered. There are patient entry fields displayed above the usual spreadsheet representation. Any valid prescriptions are displayed and can be added to the queue by clicking on the record and then hitting the appropriate button.
The Whole System
Method
Participants
(Gender pronouns are presented at random with no implication as to the sex of the actual participant.)
Because our project deals with three distinct user groups we wanted at least one user from each group. Medical practitioners: administrators, doctors, nurses and physician’s assistants, represent our first group. The doctor we interviewed is a clinical physician at a county hospital. He spent 4 years in medical school accompanied by 2 years of clinical rotation and is serving as an attending. Our second group consists of pharmacists and pharmacy workers. These individuals bridge the gap between patient and physician, ensuring proper medical therapy is chosen and implemented. The pharmacist who assisted us works in a county hospital pharmacy and holds a PharmD degree from a prestigious university. He has been working in a pharmacy for almost 10 years. Our final group consists of the administrators and managers who make wide-spread policy decisions and design the paperwork for clinicians. These individuals also hold high security clearance and can typically be trusted with more sensitive data. The manager we interviewed had decades of experience both as a practicing clinician and medical director.
Environment
Ideally, we would have liked to simulate each participant’s work area as closely as possible. Unfortunately, fitting five people into an exam room proved to be no easy matter! Additionally, external factors such as noise could affect the performance of the user, especially in this first testing phase. We opted for a conference room because it is both spacious and quiet. The conference room had a long table in the center with enough chairs for everyone. We had our user in the center with the “computer” on the opposite side of the table. The observer monitored things from the seat to the left of the user. The facilitator communicated with the user from the other seat to the right of the user. Our greeter, mock patient and observer positioned himself near the door when greeting, in front of the doctor/pharmacist as the patient and near our other observer when serving this role.
Tasks
We had three distinct participants, so we carried out all three levels of task difficulty with each. Let us begin with the administrator. An easy task is interpreting the type of data in a field on a form. Using our form field editor interface simply formalizes this interpretation. A task of moderate difficulty is maintaining a centralized listing of physician information. In our system this simply amounts to adding a record for a doctor in the pen-doctor database. The administrator is asked to associate a physician and requisite identification for writing prescriptions to his or her unique pen. A very difficult problem (and the motivation for our project) is extracting information from written forms to create patients records. This task is fulfilled when one names the database fields in the form field editor tool.
The doctors are 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. It is important for a doctor to be able to check old patient records before consulting with them. This can be a moderately challenging task with the old methods. Searching a database is a very natural operation and the doctor is instructed to do just that. The most important task for a doctor prescribing medication is to make sure that patient receives accurate and safe drugs. After docking the pen, the physician needs to check for errors and make corrections before anything is added to the database.
The pharmacists need only interact with their own database. A relatively easy task should be adding a new prescription and beginning to fill it. We had our pharmacist check for new pending prescriptions in a database for a given patient. A slightly more difficult task is registering new patients. Once pending prescriptions are found we ask the pharmacist to add the prescription to the queue. A difficult task for pharmacists is to keep information moving smoothly through the pharmacy (from register to queue to filler to cashier). To check how our system handled this we asked the pharmacist to go through the steps from registration to payment. Under ideal situations this would be best tested with multiple individuals and at least 3 computers (one for the registrar, one for fillers and a final computer for cashiers).
Procedure
Before testing our prototype on our chosen users, we went through a few runs of the process described in Marc Rettig’s Prototyping for Tiny Fingers. We designated a user for each round and rotated through the four positions so that everyone practiced the roles once. These functions included: (1) The greeter to welcome the user and put them at ease (2) The facilitator to give instructions and to stimulate thoughts and feedback (3) The computer to simulate the response for input and output of the system (4) The observer to take notes on the events By applying the test ahead of time, we not only had practice using Rettig’s method, but also we were able to fix obvious mistakes in our prototype so these would not bother our participants during the actual tests. For the testing with the actual participants, Rayhan was the facilitator, Jason was the greeter and took the role of a mock patient, Michael was the computer, and Utsav was the observer.
After choosing our participants and getting their approval to test our prototype, 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. Jason carried out the procedure when we were at the hospital meeting with the participants. The test process stated that everything would be done on paper. Some sheets were used to represent the prescription pad (the paper user interface) and others were used as the computer display that the participants eventually interfaced with. The user is supposed to pretend that the interface is fully functioning while Michael simulates the behavior by bringing up the proper page. The benefit section of the form mentioned that the results of the test could contribute to a system that would make prescription writing more safe and secure. 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 consent form was signed, Rayhan acted as the facilitator going over the details of how the test was going to work. He started by briefly going over the tools and their purpose. These included the form field editor, the doctor database that holds patient records, the methods for syncing the pen with the computer, and the pharmacy database. As mentioned in participants, there were three distinct individuals who would use the system: administrators, doctors and pharmacists. Since the form is not hard coded, Rayhan started administrative participants with the field editor. As the user specified areas to be filled and the types of data, Michael would bring up the corresponding screen. The administrator was also introduced to the doctor-pen association database and asked to add and remove doctors from the database. While working with the doctor, Jason acted as a possible patient of the user. As a patient, Jason would run through a pre-scripted scenario of needing a prescription, which the user would utilize the Anoto pen and our very general simulated prescription form. After the user filled out the prescription form, Rayhan would then move on to the next step of syncing the pen with a computer. When the pen was plugged into the sync, Michael popped-up the doctor database interface. As soon as the pen is docked with new prescriptions a screen is brought up to confirm the recognition. If there are conflicts with the patient record and the prescription, the user is prompted to confirm or go back and make changes. The prescription is then sent electronically to a pharmacy of the patient’s choice. Finally, we interact with a pharmacist for the last module in the application. Using the doctor’s input from the previous interview we populated the pharmacy database with several fictitious entries and the one pertaining to Jason. Jason again played the role of patient and the pharmacist was asked to queue Jason’s prescription. We also asked the pharmacist to evaluate the behavior of the tool utilized by those who actually fill the prescriptions. At the end of each interaction, we filled out a post-evaluation questionnaire with the user and discussed observations and concerns. Finally we thanked all users for their time and openness.
Rayhan made sure to only introduce the function of the system and not guide the user while he or she interacted with the interface. Michael also only echoed the behavior of the computer without providing anything beyond the “programmed” behavior. As we looked over the results of the evaluation and notes made by Utsav, we paid close attention to the issues that caused the largest delays or created gaps in conceptual understanding. Afterwards, we discussed all the concerns or successes of the prototype and made modifications to our interfaces.
Test Measures
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. Ultimately the goal is to make prescription processing as easy as possible. Though current processes may be rapid they allow for an unacceptable number of errors. Since we incorporate error handling in our interface we allow for some increased delays over current methods.
Another item we tracked were the number of errors that occurred in each test and when they occurred. 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. As we redesigned our prototype we made certain to address each of these.
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 user groups performed fairly well with the various interfaces. They particularly liked the descriptive buttons and instructions on the tools themselves. This was something that they “had not seen before.” 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.
Let us begin with the administrators who tested the doctor-pen database and form field editor. As soon as the manager located the add user button, inserting physician data into the database proved simple. The user also easily manipulated existing fields. There was a question about double-clicking a record to change a field. We explained that because we were trying to be secure, accessibility is limited to the two functions described. The operations were performed smoothly with only enough time used to read the various prompts. The tool that gave us far more difficulty was the form field editor. The administrator had a hard time understanding the conceptual background. She suggested a demonstration might be useful, but the sample we would provide in help is the form she was currently working on. She also did not understand the reason for the slightly convoluted naming convention. There were many moments where she was frozen in contemplation, but without understanding the reasoning the interface can appear unwieldy. Another issue we had overlooked was the naming of types according to C-style conventions (e.g. string and Boolean). To a non-programmer these terms may seem utterly alien. We noticed that she made liberal use of the copy/paste feature for the different regions. The manager would copy fields she had created before, paste them in, resize and rename. In the end she stated she would be completely comfortable maintaining the pen-doctor database (rated 9), but is much less certain about the form field editor (rated 6).
The interaction with the doctor revealed important but less critical issues. Interactions with the database went smoothly: conflicts were corrected and data was added effectively. One major issue we noticed was the predilection for writing outside of the designated fields. The user explains that since space is at a premium on charts and forms, whatever space is available is used. We asked if the form was possibly too cramped, but she claimed it was actually pretty spacious. The tendency seemed to be, first and foremost, a matter of habit. The doctor also seemed to like the search interface of the database, comparing it to what one would find at a library. The physician also expressed a desire to have the type of drug interaction listed. The interactions were generally smooth throughout, with some minor pauses during the first dock. The participant said she was just reasoning through what was going on. She rated the doctor database tools an 8.5 overall.
The pharmacist seemed to have the easiest time with the system once we explained the set-up. He liked the fact that there was only minor data input needed on his part to get the information. In his words “the buttons tell you just what to do.” He estimated this system would save hours of typing in a regular work week. The only comment we received was that the billing system might be more complicated than our prototype reveals. A minor cosmetic issue brought up was that yellow or even gold might be hard to see from a distance. Since this is the main color fillers will be looking for it should certainly have heightened visibility. The pharmacist very much liked the idea that the individual prescribing the medication would have to go through automated checks. The system is very much tailored to the needs of the pharmacist and aside from brief pauses to read the interactions were smooth. He commented “this will reduce our work considerably” and gave the system a 9.5.
Discussion
The ratings scale:
- I don’t agree this is a usability problem.
- Cosmetic problem
- Minor usability problem
- Major usability problem: important to fix
- Usability catastrophe: imperative to fix
Our major concern is the difficulty with the form field editor which we would classify as a 4 or potentially 5. There are a couple of ways to fix this issue, some easier than others. The simplest would be to scrap the idea of customized forms and just define fields a priori. This savagely curtails expandability but gets rid of the weakest link in our project. The other technique might be to keep the tool for developers or perhaps database analysts. They can generate the region specification files and the Anoto dot prints. This group should have a much better understanding of what is going on at the lower level. Another solution suggested by the administrator involves using drop down boxes to make naming much simpler. A more minor usability problem (3) is that of the field types. Upon our next revision we will use more straight-forward names.
The problem of the doctor writing into inappropriate fields also has several possible solutions. The severity of the issue depends a lot on users; if they are willing to change immediately then it is only a minor usability problem (3). If R3 supported it, we could just follow the stroke and take the field to be that which contains the majority of the stroke. Another option would be to just do something graphically, on the paper. We could include a warning somewhere on the prescription, darken the delimiters between fields or decrease the writing area in relation to the field size. It is hard to tell whether doctors would necessarily heed these warnings. However, if they recognize that the handwriting recognition is suffering (and consequently they must do more retyping) they may be more willing to change. This negative reinforcement certainly is not ideal and could lead to contempt for the system if the relation is not made to “writing outside the lines.” Depending upon the information source we are using to check drug interactions, explicitly stating the conflict might be feasible. We will investigate our options before the next revision and come to a decision about whether this can be done reasonably.
For the pharmacy tools we feel the results are very good. The font color issue is a minor cosmetic problem (2) while the billing system will probably need more work and is a 3. Before the next revision we will reexamine the current billing interfaces and hopefully glean some good insight from these systems. We will immediately darken the font color for pending prescriptions on the queue. The reason we chose red, yellow and green was to simulate traffic lights. Red indicated stop because the prescription is waiting to be processed. Yellow means the prescription is in mid-transit waiting to be filled. Green indicates the prescription is good to go. The metaphor seems fitting so we will try to choose a darker shade of yellow to maintain it. Another option is to use a darker background color and lighter versions of the colors for the foreground. In any case these are minor coloration issues which can be settled by some trial and error.
In general the experiment was a wonderful test of the interface and gave us considerable feedback. We received feedback from all user groups that reflects more than just the individuals we interviewed. There was very little functionality that was untested but of course our sample size was small and the experiment cannot reveal the needs and difficulties of all potential users.
Appendix
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 testing the low-fidelity prototype 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 ______________
Script
Greeter/Mock Patient: Jason
Facilitator: Rayhan
Computer: Michael
Observer: Utsav
For Everyone
Greeter: Hello sir/madam. I am Jason and these are my group members: Rayhan, Michael, and Utsav. 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.
Facilitator: 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.
I will be facilitating you through the exercises and tasks today. You will be interacting with Michael who is playing the part of the computer interface, Jason and Utsav will be recording data during the entire session. (For doctors/pharmacists: Jason will also play the role of a mock patient to afford more realistic interactions.) Do you have any questions before we begin the testing exercise?
We will be providing you with a paper model of our interface for the NextRx. The paper interface is used to keep the cost of prototyping low as well as provide quick feedback and changes.
For purposes of detail-hiding we have not included the usual title bar, minimize, maximize and close buttons one would find on most Windows computers. The reason for this is simply because the program should be platform-independent. If at any time you would like to use these functions just let us know and we will simulate them. Running across the top of each interface window, the menu options can be accessed by tapping on the interface. The double lined boxes represent buttons that can be tapped as well. The scroll bars can be used if there is more data then is viewable on a screen. Any keyboard input on your part will be simulated through Michael, who will write directly on the forms.
For Administrators
Facilitator: This is our interface for a doctor-pen database. Please add a physician, feel free to make up any fictions 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! The next tool we want to present you with is a little more subtle. It is used to identify fields on a pre-existing form, such as a prescription sheet. We have taken the liberty of altering a prescription form acquired from a hospital. The file is located in C:\Forms\Prescription.pdf. Please open the file; we have provided a Windows-like interface but again the actual layout will depend on the platform from which the application is running. Now that the form is open please designate different areas on it. Again, thinking out loud will be very helpful to us. (If they seem to be having difficulty, remind them not to worry – it is a failure of the interface not them.)
Fantastic! Now that you are done, I’d like you to save the active regions and export the PDF with dot pattern.
For Doctors
Facilitator: This is a prescription pad one of your administrators helped us design earlier. You’ll notice a simulated 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 Jason who will play a 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. You may want to note what pharmacy Jason would like his prescription filled at, it will be useful later. 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 if you’ll give me the pen I’ll “dock” it. 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 we present you with the database itself. We’d like you to start by showing us how you’d search for John Smith, who has a medical ID of 123456789. Again, thinking out loud will be very helpful to us. We have simulated a medication error here; please identify how you would deal with it.
For Pharmacists
Facilitator: 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. Jason will serve as a customer/patient who is bringing in a valid prescription and his ID. Please register him. Now queue his pending prescriptions. 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, Jason will interact with you to finally purchase his 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.
