InteractivePrototype-Group:The JURMs
From CS160 User Interfaces Fa06
Contents |
Prototype
Report
Names and Role in Assignment
- Rayhan Lal – Found constituent packages, set-up database, README and speaker during presentation.
- Michael Mai – Coded swing (no easy task), took screenshots for presentation.
- Utsav Shah – Did write-up, slides for presentation, helped with postgreSQL.
- Jason Shangkuan – Worked with GlazedLists, did much of the coding and practiced timing for presentation.
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 medium 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’ll also have a way to crosscheck patient’s 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.
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. 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 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. In the current implementation this amounts to having the right data type but we will soon be including more advanced drug checks.
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. He or she can get 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. 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.
Revised Interface Design
One of the biggest changes as result of our lo-fi prototype testing is the idea of form field editor. This tool turned out very difficult after testing it with our users. 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 thought of ways to fix this issue, some easier than others. One way to go about it is to have developers or perhaps database analysts use the tool. 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. It turns out that’s bit tedious and complicated so we decided 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 pharmacists complained about font color issue on the pharmacy tools. Our use of gold and green colored text to represent different situations had some visibility issues with the pharmacists. As a result, we thought of darkening the font color or darken the background color and lighten the text color in the foreground. However upon final examination we decided to use a status field in our database to indicate progress of the prescriptions (figure 4). 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 would have worked as well but we didn’t want to take chances with coloration issues.
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.
Overview of the UI implemented
First of all, here are some implementation details that went into building our user interface. 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.
Starting off with paper UI, we have a very easy to use prescription form. It’s designed around an existing form currently in use by the 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 move onto different prescription form after a physician hits the button.
Our system provides a database for doctors and their corresponding pens (figure 1), 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. 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. The tabular arrangement for drugs is identical to that found on the template form, where essential information such as strength and quantity is provided by the doctor.
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. 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.
After the doctor docks the pen a pop-up will appear on the screen of the computer (figure 3). 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. 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 4) 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.
Now, moving to the pharmacy, a pharmacist can select two different views from the view menu (figure 5 and 6). The queue mode (as shown) 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 “filled” button and when patients come to pick up the prescription, he/she can click “pick-up” button and carry out the final transaction (figure 7). The retrieve mode (as shown) 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. Again, the status field indicates whether or not prescription is processed or is ready for pick up.
What was left out and why
Due to time constraints, we couldn't implement the search functionalities for our doctors to use. As shown in the figure 4, doctors can search over any fields to get desired information.
Prototype Screenshots
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
