University of Portland
School of Engineering
5000 N. Willamette Blvd.
Portland, OR 97203-5798
Phone 503 943 7314
Fax 503 943 7316
Final Report
Project Lost R. Sucker
Contributors:
Scott Lukenbaugh
Keith Hernandez
Approvals
Name
Dr. Willshire
Date
Name
Date
Dr. Lillevik
Insert checkmark (√) next to name when approved.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
.
Revision History
.
.
Rev.
Date.
0.9
04/14/04 .
FINAL REPORT
PROJECT LOST R. SUCKER
1.0
04/17/04
UNIVERSITY OF PORTLAND
REV. 0.9
UP-CS-TR-04-03
PAGE II
Author
S. Lukenbaugh
K. Hernandez
Reason for Changes
Initial draft
Make corrections suggested by
our advisor.
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
.
Acknowledgements
.
. to thank our industry representative, Mr. Tony Harold, for his contributions
We would like
in helping us .
create professional quality work. We would also like to thank our advisor, Dr.
Mary Jane Willshire,
for helping us with the many drafts of our documents. Finally we
.
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE III
would like to thank Miss Lynda Jenson for the idea of automating the syringe compatibility
chart.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
.
Table of Contents
.
.
Summary.......................................................................................................................
1
.
.
Introduction ..................................................................................................................
2
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE IV
Background .................................................................................................................. 3
Methodology ................................................................................................................ 4
General Description ................................................................................................................................4
Deliverables .............................................................................................................................................5
Graphical User Interface ..................................................................................................................5
Knowledge Base ..............................................................................................................................6
Syringe Compatibility Prototype ......................................................................................................6
Results .......................................................................................................................... 7
Technical..................................................................................................................................................7
Process ....................................................................................................................................................8
Conclusions ...............................................................................................................10
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
List of Figures.
.
Figure 1. Block Diagram of.Syringe Compatibility Program .........................................................................4
.
Figure 2. Example of GUI ..............................................................................................................................
5
.
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE V
Figure 2. Lost R. Sucker UML Diagram. .......................................................................................................7
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
List of Tables .
.
.
Table 1. Lost R. Sucker Deliverables.
...........................................................................................................5
.
Table 2. Key Lost R. Sucker
. Milestones. ......................................................................................................8
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE VI
Table 3. Lost R. Sucker Project Risks...........................................................................................................9
Table 4. Interface Optionals ....................................................................................................................... 10
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
1
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 1
Summary
The purpose of this document is to give its readers a clear overview of the Lost R Sucker
production process. Lost R. Sucker is a project that tests the compatibility of drugs in a
syringe. The implementation process consists of an interface, which displays all relevant
information to the user, such as the drugs to be compared and the result of the
comparison. The interface also provides an easy way to access the information contained
in the knowledge base, which is the software component responsible for the comparison
results. JESS, an expert system shell, is used to create the knowledge base. Java is the
primary language to implement the interface and JESS, a java derivative, is the expert
system that is used to implement the knowledge base. The compatibility of these two
languages and our familiarity with Java is the reason we choose to use them.
The majority of this “Final Report” document is based upon the discussion of the
developmental process. This section covers the assumptions, milestones, risks, and
contingencies that surfaced during the development of the project. Our assumptions
included receiving an academic license for JESS, learning to use JESS effectively,
obtaining exemption or approval from the Institutional Review Board, and we would be
able to devote ten hours a week during the implementation stage. Our risks simply list our
assumptions along with an appropriate severity factor. Refer to Table 3 for further
information. Some specific milestones for the Lost R. Sucker project were completion of
the interface, knowledge base and a successful merger of the two. For a complete list of
the project milestones please refer to Table 2.
Our contingencies for receiving/learning/using JESS were to make a two by two matrix
with a look-up table. If difficulty arose in linking the knowledge base to the Interface, we
would have programmed a matrix directly into the GUI source code. Furthermore, only
the developers will test and use the completed product if the IRB exemption or approval
had not been given. Only the last contingency had to be implemented because the IRB
panel never got back to us.
Furthermore, we include some improvements to our project that future developers may
want to implement in similar projects. However, we reserve the rights to this project and
any of the contingency forms of this project.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
2
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 2
Introduction
A technical report of the design for the syringe compatibility program is provided in this
document. Project Lost R. Sucker, is designed with its intended use as a reference to the
compatibility of two drugs in a syringe by medical personnel. All components are
described from the developer’s perspective and are intended for technical personnel to
gain insight into the intricacies of project Lost R. Sucker.
An outline of the document is as follows: A background of the Syringe Compatibility
Program, which includes a justification for the creation of the program. Following the
background are the requirements of the project, which begin with a simple block diagram
that demonstrates how a user will operate the Syringe Compatibility program. The first of
the three requirements is the Core Functionality requirement, which specifies the
necessary steps in the order in which the product was completed. The last two
requirements relate to the completion of the interface and the expert system. The
interface is a GUI (Graphical User Interface) that consists of a pair of controls to select the
drugs, another control that obtains an answer from the expert system’s knowledge base
and displays that answer in a window or text box. The requirements for the expert system
are to return the comparison to the interface, and hold in its knowledge base the
comparison of all combinations of drugs.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
3
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 3
Background
Currently, most hospitals use a visual chart to determine syringe drug compatibility. This
can lead to mistakes when tired medical personnel miss-read the chart. We believe that
determining the compatibility of drug pairs in an automated manner will be more beneficial
then looking at a chart, in that it is more efficient and extremely accurate, as more and
more hospitals move to a computerized charting system. To our knowledge, there is no
comparable syringe drug compatibility program available. Therefore, we felt it was
advantageous for us to create such a product.
In order to create this program, we used an expert system shell in Java called JESS. We
could have used a data structure such as a matrix with a table lookup, however, we had a
strong desire to learn about expert systems. The Java platform was chosen so that the
graphical user interface, or GUI, could be easily designed and programmed. Also, Java
has many libraries that proved to be beneficial in the implementation of the project.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
4
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 4
Methodology
Our program allows medical personnel to quickly and accurately ascertain whether or not two drugs are
compatible within a syringe. Once the program is initialized, the user has the ability to select the
different drugs to be compared. The user will then select a compare function to compare the two drugs
that they want to put in a syringe. The selected drugs are compared by the expert system’s knowledge
base. An answer is then sent to the user through the user interface. A block representation of the
system is present in Figure 1.
Interface
Expert
System
Access
User
Comparison
of Drugs
Compatible
Not
Compatible
Figure 1. Block Diagram of Syringe Compatibility Program
General Description
There are two main components for this program: an expert system and an interface. The
expert system includes a knowledge base of all the possible compatible combinations of
drug pairs that can be searched with only one rule. This knowledge base tells the
interface whether the two selected drugs are compatible or not. The interface consists of
two controls that list all of the drug names. The interface has a different control that
activates the comparison function of the expert system. The results of the compare are
reported in a text box.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
.
Deliverables
.
.
For project Lost
Sucker there were four deliverables as shown in Table 1. These
. R. required
deliverables include
documentation as well the Syringe Compatibility prototype.
.
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE 5
Table 1. Lost R. Sucker Deliverables.
Number Technology
1
2
3
4
Software
Software
Document
Software
Deliverable
Graphical User Interface
Knowledge Base
Test Case
Syringe Compatibility
Prototype
Graphical User Interface
Below, in Figure 2, is an example of the GUI the medical personnel will interact with to
accomplish the comparison of the two drugs that are to be mixed in the syringe. The
actual GUI is not displayed because of complications with placing it in this document.
Answer
Figure 2. Example of GUI
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
Knowledge Base
.
. base contains all possible combinations of the different compatible pairs of
The knowledge
.
drugs. If two. drugs are not compatible, then the default is that they are incompatible
because only the compatible drugs are in the knowledge base. The knowledge base is
.
searched with one lengthy rule. The interface will interact with the knowledge base by
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE 6
passing the information back and forth between the interface buttons and the text box.
Syringe Compatibility Prototype
The prototype will be the final product of the project, and will demonstrate the
implementation of the requirements as they are described in the functional specifications
document.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
5
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 7
Results
This chapter contains the bulk of the document and includes two main sections: technical
and process. In the technical section, we describe how our design works and in the
process section we compare our plan to our actual activities.
This chapter includes two main sections: technical and process. In the technical section
below, a UML diagram of how the project is linked together is shown. The two main
components of the prototype software are divided into two separate classes, with support
from predefined JAVA libraries and JESS libraries for the GUI and Knowledge-Base
classes respectively. Following the technical section is the process section, which
includes the milestone table set forth by us in the first semester and a severity chart. The
severity chart follows the milestone table and indicates the milestones we were most
worried about completing on time or even completing at all. The severity has three
distinctions high, medium and low.
Technical
GUI
+compareButton: JButton
+rightMenu: JComboBox
+leftMenu: JComboBox
+textbox: JTextField
+autoComplete(string): void
Knowledge_Base
+search: Rete
+Compare(string, string): int
Rete
jess
+executeCommand(Fill
in variables)
JButton
JComboBox
JTextField
Figure 3. Lost R. Sucker UML Diagram.
The GUI is responsible for displaying the components that the user sees and interacts
with. The GUI also waits for a mouse click to send data to the appropriate method. The
Knowledge_base is responsible for storing the possible comparison values as well as
searching for the comparison that the user sends from the GUI. Jess is a library that the
Knowledge_base uses for the search and storage of comparisions. Rete is the algorithm
within JESS that does the searching.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
.
Process
.
.
The following.assumptions were made for this project.
.
 We assumed we would receive an academic license for JESS.
FINAL REPORT
PROJECT LOST R. SUCKER
REV. 0.9
UP-CS-TR-04-03
PAGE 8
We did receive an
academic license for JESS without any trouble.

We assumed we would obtain enough knowledge to use JESS and implement an
expert system for the project. This proved to be troublesome in the beginning, but we
allotted enough time to overcome this obstacle and went on to implement the expert
system.

Ten hours a week was enough time to complete the prototype of the project. This
was accurate.

The project receives exemption or approval from the IRB. We never heard back from
the IRB panel. However, this was a peripheral part of the project.
Table 2. Key Lost R. Sucker Milestones.
Number
Description
Original
Previous
10/31/03
1
2
3
4
5
6
7
8
9
10
11
12

Product PreApproval
Functional
Specification
Project Plan
Design Review
TOP’s Approval
Interface
Knowledge-base
Merge
Testing
Prototype
Release
Founder’s Day
Final Report
Present
04/12/04
09/29/03
09/29/03
09/29/03
10/23/03
10/23/03
10/23/03
11/07/03
12/05/03
01/30/04
02/20/04
02/27/04
03/12/04
03/27/04
03/30/04
11/07/03
12/05/03
01/30/04
02/20/04
02/27/04
03/12/04
03/27/04
03/30/04
11/07/03
1/19/04
2/13/04
02/27/04
03/18/04
03/26/04
04/02/04
04/05/04
04/13/04
04/19/04
04/13/04
04/19/04
04/13/04
04/20/04
The Design Review was late due to winter break. It would have only been a week late
otherwise. This was due to our lack of knowledge on what was required for the
document.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
.
.
.
.
TOP’s approval looks late because the due date was changed from what was printed
.
at the beginning of the year. This is also the case for the Final Report.
.
Numbers.6-10 were late due to complications with the installation and implementation
of JESS..
.
FINAL REPORT
PROJECT LOST R. SUCKER


REV. 0.9
UP-CS-TR-04-03
PAGE 9
Table 3. Lost R. Sucker Project Risks.
Number
Severity
Description
1
High
Learning how to use JESS, an expert system.
2
High
Creating an expert system.
3
Medium
Receiving JESS academic license.
4
Low
Linking the knowledge base to the interface.
5
Low
Our project does not receive exemption from
IRB

Our risk assessment ended up being very accurate. The risks that proved to be the
most difficult were the risks that had the highest severity on our risk chart. None of
our risk assessments were changed nor did they need to be.

We ended up spending slightly more time on our project than predicted, but we made
our schedule in such a way that it did not cause panic within our group. We did not
have a budget. We used the computer labs for our project and they proved to be
adequate.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH
FINAL REPORT
PROJECT LOST R. SUCKER
Chapter
6
.
.
.
.
.
.
.
.
.
REV. 0.9
UP-CS-TR-04-03
PAGE 10
Conclusions
The Syringe Compatibility program allows overworked medical professionals to quickly
and accurately determine the compatibility of two different drugs. The expert system and
the interface are the two key components of the program. The knowledge base is key to
determining the compatibility of the two selected drugs. Whereas, the interface is
responsible for relaying the input and output information of the knowledge base in a userfriendly manner.
In implementing project Lost R. Sucker, the following technologies were used: Java, JESS
(the expert system software). The three main components of Lost R. Sucker consist of:
The GUI, the knowledge base, and the device layer. The knowledge base tells the
interface whether the two selected drugs are compatible or not. The interface consists of
two controls that will list all the drug names. The device layer also has different controls
that the GUI uses to activate the comparison function from the expert system. The results
of the compare are reported in a text box at the bottom of the GUI.
This project was a success. We met all of our goals and assessed the risks of this project
correctly. The following are suggestions for our interface to make it more efficient and
increase use-ability.
Table 4. Interface Optionals
Opt. Num.
100
101
102
103
UNIVERSITY OF PORTLAND
Optionals
Have the pull down menus filter for what the user inputs.
Have a window that flashes the result of the comparison.
Invoke the comparison when the second drug is selected.
Add sound to announce the outcome of the comparison.
SCHOOL OF ENGINEERING
CONTACT: S. LUKENBAUGH