Contents

Proper identification of pathogenic bacteria from a tissue sample or culture is critical to diagnosing bacterial illness or infection and deciding a proper course of antibiotic treatment. In addition, identification is often needed on a time-sensitive basis in order to start treatment or consider other diagnoses as fast as possible. Direct microscopic examination and fast staining procedures are critical in identifying bacteria and can be performed in almost any lab, but more than 60 species of pathogenic bacteria are frequent causes of disease. Differentiating between these possible pathogenic bacteria, in addition to recognizing non-pathogenic bacteria which frequently colonize healthy patients, can be difficult for lab personnel not trained extensively in microbiology.

The Bacteria Identification Applet walks users through a series of simple tests to determine what type of disease-causing bacteria is present in a culture or sample based on simple staining and morphological characteristics. The applet provides graphical examples to benchmark the results against, minimizing the chance for errors.

The primary goal of the project was to learn about collecting and encoding knowledge. The knowledge contained in the Bacteria Identification Applet is formatted for biologists, not the average laboratory technician. Therefore, the information needed to be phrased in plain English with visual examples to be as accessible as possible. This is where the project expert comes in. Lisabeth Hall, a first-year student at the University of Washington School of Medicine was instrumental in describing the terms in plain English and visual examples. The clear verbiage allows technicians to perform the bacteria analysis, while only requiring knowledge of how to perform the tests.

The secondary goal is quite arbitrary but important to the author. I wanted something that was refined to the point where the finished product could be used in industry. A text-based interface was fine for the academic requirements of this project but is generally disliked in industry. I decided to make the finished product accessible enough that it could be given to a lab where these types of analyses are performed.

The third goal was to make the system expandable. Approximately 50 bacteria are known by the applet but many more fit within the scope of the analysis. To be truly useful, the program must have the ability to grow or adapt. Therefore, was an important component of the scope and design of the applet.

The applet contains a status window that tells users what tests to perform and what to look for in their results. A dynamic, context-specific set of buttons allows them to choose their answer from the choices supported by the applet. A graphical display window shows users what the possible choices look like so they can easily choose which best represents the contents of their petri dishes. Finally, the applet displays all possible bacteria in the Candidate Bacteria window. As users narrow down the characteristics of their bacteria, the list of potential candidate bacteria is updated to show only those that match the current knowledge.

The program is a fairly standard Java applet which requires a Java-enabled web-browser. Users just type in the URL of the applet and wait for it to load. Users with modem connections will need to wait for the approximately 400K of applet classes and images to download. When the applet starts, it leads users through a simple "point & click" interface to deducing what their cell culture contains.

The program is designed to implement a truth table via the JESS expert system. The table does not allow back-tracking so that made the design a bit easier. The design of the program is significantly inelegant as it operates as a state machine. There are 27 unique states that the program can move through.

Each state contains a text descriptor which shows up in the main message window, a set of buttons leading to available child states, and an optional graphic. The states are not formatted in any structured manner such as a Java class. Instead, there are 27 named constants representing the various states. The function redrawWindow() contains an enormous switch statement with a case clause for each state. The case clauses then assert the fact attained by reaching the current state, display the state’s descriptive text string, draw the state’s result buttons, and optionally draw the state’s graphic. Messy!

The JESS expert system is reset() when the applet is started. When facts are asserted, its run() method is called which eliminates non-candidate bacteria by retracting their facts. JESS 4.4 defines an event handler called retractFact(FactObject) which is called whenever a fact is retracted by the inference engine. I used this event handler to keep the bacteria in the Candidate Bacteria display current. The benefit in this design is that it eliminates abstraction of the contents of the knowledge base. I don’t need to keep a separate array of bacteria facts and make sure it stays current.

The functional design that I implemented is a middle-ground between the most and least optimal implementations that I considered. When I proposed the project, I did not have a good feel for how long it would take to design and code the application. To ensure that I could deliver what I promised, I proposed a range of implementations. The most ambitious implementation was a Java applet whereas the least ambitious was an application in VBA through Access 97.

The optimal Java applet would run JESS on the server. When a client applet connected to it, they would agree on a port, the server would spawn a new JESS thread that listens on that port, then the client would connect to it. When the core functionality of the applet is running on the server, several benefits are realized:

1. If the knowledge base contains proprietary information or algorithms, they are kept significantly more secure as they are never sent to the client.
2. The server hardware could be scaled up or down to accommodate the number of clients required. (Client hardware prerequisites are significantly decreased too.)
3. The system could "learn" new bacteria if the applet implemented it. If the client tells the server to learn a new bacteria, it could write the bacteria’s specs to the .CLP file containing the knowledge base. The current "server-less" approach would require the ability for clients to overwrite the .CLP file which is VERY insecure. The information about the .CLP file is sent to the client, the client has write access on the server, and the format of the bacteria is known. Malicious users could exploit this to produce undesirable results.

The least ambitious approach included the CLIP ActiveX control as the inference engine. The control is designed to be dropped into an application to facilitate CLIP functionality. I started with this approach because I did not have enough time to write the aforementioned Java applet. The control did not work as advertised in Access97, had poor documentation, and was a fringe option from the start. Another class project used this control without problems in Visual Basic. There must be some fundamental requirements that Access97’s VBA environment does not provide for this control.

The problems encountered in this core component forced me to allocate borrowed time to this project in order to create a Java applet. The JESS implementation was much more straight forward and actually produced better product. The current Java implementation is portable to all Java-enabled web browsers whereas the Access97 implementation excludes the entire UNIX community.

If I had another month to work on this project, I would implement the ability for the applet to learn new bacteria. This is very important in keeping the application current. Products that do not grow with their environments are abandoned – that’s not the acceptance level that I am aiming for. The bacteria list can be expanded in the current implementation but it requires some knowledge of the CLIP language and editing of the .CLP file. This is undesirable because one mistake (accidentally editing a rule instead of a bacterium) can cause the entire logic of the application to change.

Another feature that would improve the functionality of this application is to allow the addition of tests to further narrow the bacteria. When users get to the end of the decision tree, they are often left with a list of bacteria instead of a single bug. In reality, they must still determine what type of bacteria they have so they must use another tool. If this application could be told that another test could be performed to differentiate between bacteria, it could greatly expand the application’s functionality.

Expert System design & coding is not all that different from object-oriented programming. It is a paradigm that requires a designer to think a little differently than usual. It is a powerful way to represent extensible knowledge that can be applied to everything from telephone technical support to meal planning. In this case, bacteria identification benefits from this way of modeling human reasoning. The technology works to streamline the process of selecting treatment for patients, potentially saving lives.