Abstract: A production rules system aiding the glaucomas diagnosis is presented. Its architecture is close to the traditional production rules systems. The medical expert knowledge and data are represented as rules and facts. A specific mechanism for treating 'weak' symptoms is used. Directions for future versions development are considered. Adding a neural network module to the system is planned. It will enhance the 'weak' symptoms processing and will add learning to the system functionality.

1. Introduction

AI applications in medicine have long tradition since 1976, when the first expert system in medicine - MYCINE was developed. This article presents the first version GLAU1.0 of a production rules system for glaucomas diagnosis. It is part of a larger project [1] aimed at developing a complex of hardware and software tools for computer aided diagnosis of glaucomas. It can be used independently as tool aiding ophthalmologists in diagnosing glaucomas. It can be helpful also in the medicine student's education.

GLAU1.0 is programmed in XLISP-PLUS Version 2.1g and runs under MS-DOS for IBM PC compatibles. When the system is run it starts displaying a sequence of panels, containing texts, menus and edit-text fields. Thus it begins dialog with the user aimed at gathering some preliminary information, necessary for determining if there is glaucoma at all, and if so, to which group of glaucomas the current case belongs. Then the dialog continues with more panels, which contents concentrates on data about the symptoms important for the selected group. At last a diagnosis is proposed.

Section 2 of this article describes briefly the glaucoma disease. Section 3 presents the system architecture. Section 4 explains how medical expert knowledge and data are represented in the system. Section 5 contains notes about the current state of this work and some ideas concerning future version's development.

2. Glaucoma

The glaucoma is known as an eye disease centuries ago. It is subject of scientific research of many ophthalmologists. In fact, glaucoma is general name for group of eye diseases, which have high pressures of the intraocular fluid as their main symptom. This can be caused by some malfunctions of the complex mechanisms providing fluid circulation. Many additional clinical or functional changes of the eye can be observed. Their presence or absence is very important for the precise diagnosis.

There are four main groups of glaucomas:

· Glaucoma simplex, anguloapertum

· Glaucoma congestivum, anguloclusivum

· Congenital glaucoma

· Secondary glaucoma

Every group is divided in several subgroups, which in turn differentiate in various forms. In addition, the proper stage for some of the forms has to be determined as one of:

· Glaucoma initialae

· Glaucoma evolutum

· Glaucoma progressum

· Glaucoma absolutum, terminalae

Given such variety of glaucomas and their forms, with close symptoms in many cases, there is some possibility of erroneous diagnosis in real praxis. Hence the expert knowledge based on rich experience is of great importance for proper diagnosis of glaucomas. The following sections of this article present an experimental version of production rules system developed as an attempt to capture the expert knowledge necessary for glaucoma diagnosis.

3. Architecture of GLAU1.0

The main modules of GLAU1.0 are inference engine, rules base, facts base, interface module and main program.

· The inference engine is a forward chaining rules interpreter. It searches the rules base until a rule which left part is satisfied (i.e. its elements unify with elements of the facts base) is found. Then the right part of the rule is processed. This may or may not change the state of the facts base and the rules base status, and/or to activate the interface module. The search for another satisfied rule continues from the current stop point. Important role plays the rules base status, which is simple but efficient mean for rules base structuring. It is implemented as a global variable *status*. It value is a string and can be changed by rules right part expressions. In every moment only those rules are visible to the inference engine which names contain the value of the global variable *status* as substring. The inference engine stops when no rule matching the current *status* can be satisfied or when the value of *status* is the string "end".

· The rules base is a list of production rules having the following syntax:

(<name> <list of conditions> <list of expressions>)

<list of conditions>::=(<condition1> <condition2> ... <conditionm>)

<list of expressions>::=(<expression1> <expression2> ... <expressionn>)

<condition>::=T|<string>|(<string> <string>)|(<string> <rel> <value>)|

(<number> <rel1> <string> <rel2> <number>)|

(or <condition1> <condition2> ... <conditionm>)|

(and <condition1> <condition2> ... <conditionm>)|

(not <condition>)

<rel>::= >|<

Note: <rel1> have to equal <rel2>.

<expression>::=(set-fact <string> = <arithmetic expression>)|

(setq *status* <string>)|

(send <interface object> <message>)|

<xlisp expression>

Note: In fact the second and third alternatives are also xlisp expressions but are included here as distinct syntactic elements because of their semantic role.

<value>::=<string>|<number>

<string> and <number> have the syntax and semantics of their corresponding data types in the implementation language, i.e. xlisp.

<arithmetic expression> is 'normal' (infix) expression, where operands can be numbers, facts with numeric values or xlisp expressions that evaluate to numbers.

Rules of condition satisfaction:

<list of conditions> unifies the facts base when every condition in the list is satisfied.

T is always satisfied.

<string> is satisfied when it equals a member of the facts base.

(<string> <string>) is satisfied when it equals a member of the facts base.

(<string1> <rel> <value1>) is satisfied when there is a fact (<string2> <value2>), <string1> equals <string2>, <value1> and <value2> are numbers and <value2><rel><value1> is true.

(<number1> <rel> <string1> <rel> <number2>) is satisfied when there is a fact (<string2> <value1>), <string1> equals <string2>, <value1> is a number and <number1><rel><value1> and <value1><rel><number2> are true.

(or <condition1> <condition2> ... <conditionm>) is satisfied if at least one <conditioni> is satisfied.

(and <condition1> <condition2> ... <conditionm>) is satisfied when every <conditioni> is satisfied.

(not <condition>) is satisfied when <condition> is not satisfied.

· The facts base is a list of facts. A fact is either <string>, either (<string> <value>).

The first case is used to denote a fact, which is true, and we call it simple fact.

The second case denotes a fact, which has a set of possible values, and <value> is member of this set. We call such facts variables.

· The interface module supports the interface with the user and the archiving of data on disk. It is programmed entirely in object-oriented style. Its high level objects are panels containing menus, text and edit-text fields. Their methods are invoked by expressions in rules right parts or directly by the main program. The different parts of the user dialog are organized as sequences of method invocations that result mainly in filling the facts base.

· The main program in general organizes the work of the other modules and takes some archiving functions. It tests if the main obligatory symptoms for any glaucoma are present and starts the inference engine to work independently on data for the right and left eyes.

4. Rules, Facts, Interface

The previous section concentrates on the architecture of GLAU1.0 and the structure and functionality of its modules, regarded from computer science point of view. This section explains how the medical knowledge and data are represented as rules and facts.

Currently the system has expert knowledge, which enables it to carry out the following decision tasks:

1. to decide if the disease is glaucoma at all;

2. to classify the case at hand as belonging to one of five groups (Glaucoma simplex, Glaucoma congestivum, Congenital glaucoma, Secondary glaucoma, Other glaucoma);

3. to determine the form of Glaucoma simplex (two possible forms are considered);

4. to determine the stage of Glaucoma simplex as one of initialae, evolutum, progressum and terminalae;

5. to determine the form of Glaucoma congestivum (six possible forms are considered);

The knowledge related to task 1 is represented procedurally as part of the main program. The rest part of the expert knowledge is represented as production rules. Via the rules base status mechanism (explained in section 3), these rules are divided in three groups - one related to task 2, another related to tasks 3 and 4, and one more for task 5. Several of the rules are used to activate interface procedures and/or to change the rules base status (i.e. they act as metarules).

It is characteristic for the glaucoma diagnosis that there is large number of symptoms (weak symptoms) which alone have no decisive power. But when they appear in specific combinations with other 'weak' symptoms, the final decision can be greatly influenced. The current version copes with such symptoms by introducing facts with numeric values called counters. There are rules which if a given 'weak' symptom is present, add a number corresponding to the relative 'strength' of the symptom to the appropriate counter. The sums accumulated in the counters play important role in determining the form of glaucoma.

From mathematical point of view, counters are equivalent to multivariable linear polynomials, whose coefficients are determined by the expert ophthalmologist.

When a particular case is considered, the data about the symptoms and some personal information, needed for the archive, are entered via the interface module by the user. The interface module represents these data and personal information as facts, which are stored in the facts base and thus they become accessible for the inference engine.

At the present moment GLAU1.0 works with more than 80 rules. The total number of considered symptoms is 88. The user interface is organized as set of 11 different panels.

5. Conclusion

The presented system was tested on about 200 artificial examples. Now it is in the beginning of a real data testing period. This will also be a period of collecting and preparing a large diversity of real cases, which later will be used for off-line testing.

Further development of the program system resulting in new versions can be done in several directions:

· Transferring the system under MS Windows. Possibly the interface module will be reprogrammed entirely. This will improve the user interface significantly.

· Embedding the system in a larger specialized environment. Part of the medical data will be automatically provided by other software and hardware tools, specialized for measuring particular symptoms data. The archiving and referencing to previous cases can be greatly improved by providing interface to a data base management system.

· Implementing the mechanism of 'weak' symptoms processing as a specialized module. Some preliminary research [2] shows that neural network models are very appropriate for this task. This will add learning capabilities to the system functionality.

References