FinalPrototype-Group:The JURMs
From CS160 User Interfaces Fa06
Contents |
Final Report
Names and Role in Assignment
- Rayhan Lal – Report, poster and speaker during presentation.
- Michael Mai – Code, development and fixes.
- Utsav Shah – Report and slides for presentation.
- Jason Shangkuan – Code, development and added functionality.
Problem and Solution Overview
Documentation is a large part of any clinician’s life. The healthcare industry is dedicated to the preservation of mental and physical well-being. It is quite unfortunate that this noble effort has not been able to utilize the digital technology currently available. Organizing all this data becomes a much simpler problem if it can be digitized. Information about patients, diagnoses, and medications is of particular importance. It is for these reasons that we have decided to create NextRx as a means of recording, organizing and checking prescriptions electronically. Medical professionals work long hours and are fallible; they can make mistakes when prescribing medication. Prescriptions should not be open to interpretation. Furthermore, patient communication is incredibly varied. A patient might not remember or report information that could be vital. These mistakes can, in the worst case, cost lives and in the best case pose an inconvenience to patients, doctors and pharmacists. Currently, the patient is the only means of contact between the doctor and the pharmacy. Errors on either side can be made without the other side knowing or correcting them. Clearly, an automated system to verify prescriptions would be useful in mitigating these issues. With the introduction of NextRx, a high-fidelity communication channel will be opened between doctors and pharmacists. With the implementation of a patient database, NextRx allows for a faster, safer, and more reliable prescription-medication interaction. With our system, physicians would still write prescriptions as before but with Anoto pen. They also have a way to crosscheck patient information before the records get updated in the database. Patients will still receive hard copy as before but hopefully with our system, there won’t be any critical mistakes in their prescription. In the end, this reduces time and errors for both pharmacies and doctors while increasing the patient’s well-being.
Target User Group
Administrators and Doctors
Medical practitioners: administrators, doctors, nurses and physician’s assistants, face the burden of transcribing all observations and orders. They represent one-half of our user base and the group that will be less directly helped by our tool. These individuals receive career-oriented training for 2-4 years at specialized schools, they then gain experience through clinical training at a hospital and continue their career here or some other healthcare institute. Their first duty is always to the patient and they generally feel happiest when they can restore an individual’s health. As a broad generalization, they dislike paperwork and find that it can sometimes get in the way of providing the best quality of service. Filling out more forms, charts and orders means less time for them to care for patients and thus reduces their satisfaction.
Pharmacists
Pharmacists are trained in fields including pharmacology, chemistry, pharmaceutical chemistry, physiology, anatomy, biochemistry and hepatology. Pharmacists are a critical source of medical knowledge in clinics, hospitals, and community pharmacies in general. They bridge the gap between patients and physicians to ensure that proper medical therapy is chosen and implemented in the best way possible. They have many roles but more traditional and common role is to provide general health advice and specific details to patients about disease states and medications. In general, pharmacists enjoy advising patients on how drugs can help them keep them healthy. They dislike making anyone wait for medication and delays in reading prescriptions. The pharmacists chief priority of is quickly dispensing medication to patients.
Tasks
Administrators
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. 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. 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. We chose these tasks for the administrators because they seem to fall under their current job duties. Although their current duties don’t involve interacting with any database, our implementation lets them view the database in an organized tabular format which is easy to interact with.
Physicians
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). 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. 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. We chose these tasks since most of the tasks are already performed by the doctor. Also, physicians want prescriptions to be secure, but not involve so much verification the forms become a nuisance. Ideally, only the most basic information should be necessary. It is desirable to have automated methods for checking prescriptions that do not require looking up information recorded on paper. Additionally, the doctor prefers not to rewrite the same prescription for the same patient. It is a time-consuming task and major annoyance when a prescription is lost. They would like to have an account of all prescriptions and be able to reissue one on-the-fly with little hassle.
Pharmacists
The pharmacists have their own view of the database and need only the information in their own view. A task for pharmacists is to register new patients. He or she can get valid prescriptions via a search 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. 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. These tasks resemble most of what they do in their daily routines. Like administrators, our tasks require pharmacists to interact with the database but our implementation hides the details. Also, pharmacists would prefer to have all their prescriptions sent electronically because it is easier for them to place prescriptions in the queue and keep electronic copies. Patients would prefer to have the prescriptions sent electronically so that they know the prescriptions will be filled and do not have to worry about losing the physical copy or waiting in long lines to get it registered.
Design Evolution
After Low-Fidelity Testing
Form Field Editor
Our UI changed quite a bit over the course of the semester. Some changes were due to implementation issues while others were the result of evaluation by domain and non-domain users.
Our original sketches involved the use of a field form editor. This tool (figure 1) need only be run when there are changes made to the standard prescription form. The field editor opens a form stored in some common format (pdf, for example). The user navigates the file just as he or she did with the native application that created it. 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 where data is entered with the Anoto pen. The buttons on the side represent 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. 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). Other components 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). Rather than worry about computerized form generation, the system will open whatever digital version of the prescription sheet design the printing company has created. This creates a very minimal step that nearly anyone can perform.
As one can predict, the implementation of this tool is quite difficult. It would make a better toolkit component than a part of our project. The biggest change in our design came as a result of our low-fidelity prototype testing; we decided to scrap the idea of having customized forms and just define fields a priori. 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. This savagely curtails expandability but also gets rid of the weakest link in our project.
Figure 1: The now defunct form field editor
Other changes
Since our users liked the view of our database from the initial sketches during low-fidelity prototype testing, we decided to keep the same view and ensured it by utilizing Glazed Lists, more details on which can be found in the next section. Some minor changes were made to database viewer and other pharmacy tools. Our users found it hard to read text on some of our tools. As a result, we thought of darkening the font color or choosing some other color scheme. However, upon final examination we decided to use a status field in our database to indicate progress of the prescriptions. It was a better option since it made sense to have a field that shows the status of the prescription in our database. Other options may have sufficed but we didn’t want to take chances with coloration issues. Most of the pharmacy tools remained the same as the initial sketches with some minor changes to billing interface. A minor change, necessary for the paper UI was the addition of a “done” button at the bottom of the form. The clinician hits this button to indicate he or she is finished with the prescription. Because we only have one dot pattern we need to have some timestamp to delineate one prescription from the next.
After Pilot Study
No major changes were made after we conducted the pilot usability studies. However, we did have to change some of the button names and rename the fields in the database to ensure more clear understanding of what they convey. The “add/done” buttons in the add doctor dialog was a continual cause of frustration for our users. 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. As shown in figure 2 below, the button name is renamed to “Add doctor to database”. We have also fixed the arrows indicating drop-down menus. To avoid confusion we also revised the name “issued” to “time issued” in the doctor’s search dialogue.
Figure 2: Refined add doctor dialogue
Evaluation Techniques
Although both the tests were equally important for betterment of our design, we feel that low-fidelity testing has helped our design the most. The biggest change in our design, the form field editor, came after low-fidelity testing. It was much easier to make the change here since the prototype was on paper and we did not have to worry about implementation details. After the testing we realized that some of the functionality would take quite a bit of time to implement. The tools users had problems using gave us the opportunity to come up with better alternative solutions. The low-fidelity testing was also invaluable because we tested our prototypes with our target user group. Domain users have experience in the field and schemas for dealing with prescription information. Overall, both the techniques helped us to make our design better and we have tried to improve usability after each iteration.
Final Interface
Final UI Design
Features and Design
Our interface is composed of three distinct units meant for each of our three user groups. It is designed to facilitate each of the tasks described in the above section. The components include: an administrative utility for managing physicians, a clinician tool for monitoring and adding prescriptions and a pharmacist’s tool for managing prescriptions and completing transactions.
Our system provides a database for doctors and their corresponding pens (Figure 3), so the only trace of a doctor’s identity need be a pen ID. 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 of the prescription sheet. We assume that a patient name and medical record number uniquely identifies a patient, thus we put those two fields on the form to identify a patient. Normally in hospitals, an ink impression of the patient’s medical record card is taken but in our system their name needs to be written. Additional space is allocated for diagnosis to encourage physicians to be more forthcoming and descriptive. To simplify design, we have only allowed one drug per sheet. Adding more would just involve replicating code.
Figure 3: Administrator's Tool
For any database we list fields across the top of a table, that is, treating each column as a field. An entire row represents a complete record for that table. As mentioned above, using glazed lists allow us to nicely arrange our data in a tabular form. By default some convenient field is sorted in an ascending or descending order. Again, with glazed lists we can sort on any column by clicking on the column heading. The buttons are deliberately labeled in direct manner for ease of use. For example, the button “Add User” performs exactly what it says. Clicking that button will bring up a dialogue box (Figure 2) which allows user to fill in the fields required for a record. All the fields must be filled otherwise our system will produce an error informing user to fill in missing fields. One can also edit existing records by selecting a row and clicking the “Delete User” button. These features connect into the doctors table of our database for permanent storage and access.
The paper UI (Figure 4) is the doctor’s first link to the system. It is designed around an existing form currently in use by doctors. As in the figure, a physician needs to identify himself/herself (for hard copy purposes only), identify the patient by writing his/her name and patient medical record number, write a short description of diagnosis and provide necessary information about the prescribed medication. We also added a done button to finish off the prescription. It’s a way to indicate the prescription has been written and the form should undergo handwriting recognition.
Figure 4: Prescription Sheet
Because of limitations in the toolkit at the time of production, we were forced to give up on batched mode input from the pen. Instead, we switched to streaming which meant some alterations to our design. A program runs in the background, collecting strokes (Figure 5). It was suggested by the staff that we show the strokes we have received, so the sheet (with strokes) is displayed as they are streamed. The tool serves two purposes: (1) it confirms that handwriting recognition is 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. 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 (Figure 6) 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 status field is used to indicate whether or not prescription has been filled.
Figure 5: Recognition Dialogue in Transition
Figure 6: Patient Browser with Search Drop Down
Now, moving to the pharmacy, a pharmacist can select two different views from the view menu. The retrieve mode (Figure 7) is used for adding the patient prescription to the queue. In order to retrieve patient information, a pharmacist has to enter patient’s name and medical record number. All the valid prescriptions will be displayed in a tabular form and can be added to the queue by selecting the record and hitting the “add” button. The queue mode (Figure 8) is simply used for patients whose prescriptions are yet to be filled. Orders are by default displayed in the order they were issued. When a prescription gets ready, a pharmacist can select that row and click on the “filled” button and when patients come to pick up the prescription, he/she can click the “pick-up” button and carry out the final transaction (Figure 9). The transaction tool has built-in calculator functionality for computing sub-totals and the final cost. In all cases a status field indicates whether or not prescription is processed or is ready for pick up.
Figure 7: Retrieve Mode
Figure 8: Queue Mode
Figure 9: Transaction Dialogue
Implementation Details
We used postgreSQL, an open source database management system to keep our patients and doctors records in an organized manner. To connect our java code with this database, we made use of JDBC driver which allows us to connect to a postgreSQL using database independent java code. Next, for our graphical user interfaces, we used list transformation in java, which is called GlazedLists. It’s a great tool since it allows us to produce results in a nicely organized list using java swing. It provides some great features such as dynamic filtering and live sorting by clicking on the arrow button. Though quite useful, these features were slightly difficult to use in our implement. This was mainly due to a lack of documentation, though the developers were quite responsive.
What was left unimplemented
There were several components that we would have liked to implement but because of time constraints we were unable. On a positive note though these features are useful, they would not be exceedingly difficult to add. The database architecture makes things quite extensible and performing many operations on the data is practical.
It turns out that acquiring pen IDs is currently not supported in the toolkit. We use a wizard of oz technique to specify the ID in the physician’s recognition dialogue. The toolkit will hopefully provide this functionality in the future. A related feature we did not implement because of time was the ability to record a missing or stolen pen. Adding the field to the database would not be difficult. However, because of limited functionality in the toolkit and the network programming required to report this information we did not feel it would be the best use of time.
As discussed the toolkit does not fully support batched mode, so our design had to be somewhat shifted to support streaming. We would very much like to switch back to a batched model when it is available in the toolkit. Additionally, the handwriting recognition is currently far too poor out-of-the-box. Customization of settings and constraining vocabulary might yield better results. Automatically training based on user corrections could also improve recognition. A superficial feature that would be nice in the future is highlighting the fields one is correcting. Improving search facilities in the clinician database would make filtering prescriptions simpler.
Aside from some text formatting the pharmacy tools currently support all operations we intended. Additional tables would eventually be added to the underlying database to carry drug pricing information.
Oral Presentation
Poster
Added: 12/04/06
