Healthc Inform Res Search


Healthc Inform Res > Volume 18(4); 2012 > Article
Kamel Boulos: Expert System Shells for Rapid Clinical Decision Support Module Development: An ESTA Demonstration of a Simple Rule-Based System for the Diagnosis of Vaginal Discharge



This study demonstrates the feasibility of using expert system shells for rapid clinical decision support module development.


A readily available expert system shell was used to build a simple rule-based system for the crude diagnosis of vaginal discharge. Pictures and 'canned text explanations' are extensively used throughout the program to enhance its intuitiveness and educational dimension. All the steps involved in developing the system are documented.


The system runs under Microsoft Windows and is available as a free download at (the distribution archive includes both the program's executable and the commented knowledge base source as a text document). The limitations of the demonstration system, such as the lack of provisions for assessing uncertainty or various degrees of severity of a sign or symptom, are discussed in detail. Ways of improving the system, such as porting it to the Web and packaging it as an app for smartphones and tablets, are also presented.


An easy-to-use expert system shell enables clinicians to rapidly become their own 'knowledge engineers' and develop concise evidence-based decision support modules of simple to moderate complexity, targeting clinical practitioners, medical and nursing students, as well as patients, their lay carers and the general public (where appropriate). In the spirit of the social Web, it is hoped that an online repository can be created to peer review, share and re-use knowledge base modules covering various clinical problems and algorithms, as a service to the clinical community.

I. Introduction

An expert system is a system embodying specialist expertise, e.g., medical knowledge, and intended to solve real world problems that normally would require a human expert such as a specialist doctor [1].
Expert system tasks include interpretation, planning, scheduling, diagnostics, design, prediction and forecasting, monitoring, instruction, control, repairing, debugging, knowledge publishing and retrieval, intelligent interfaces and front-end processors. Clinical scenarios where expert systems might prove helpful include diagnosing disease, recommending therapy, tutoring clinical students, and controlling medical devices (the latter is sometimes achieved in combination with fuzzy logic technology).
Expert systems offer a number of advantages to their users, including knowledge retention and consistency, knowledge accessibility and distribution, cost reduction, in addition to their potential use in simulations (discovery learning), education and training.
Expert system shells (ESS) are skeletal expert system programs or, in other words, expert systems that have been "emptied" of their knowledge. They offer an easy starting point for expert system building by letting developers concentrate on creating the knowledge base, without having to build everything including the inference engine and user interface from scratch. However, using a shell to build an expert system might seduce the developer into oversimplifying the application domain because shells are inflexible, in that it is difficult to modify, or change the way they work, both with regard to representation of knowledge and the inference mechanism [2].
An expert system life-cycle will have the following stages: feasibility study, knowledge engineering, design, implementation, testing and validation, maintenance and knowledge updating when necessary (to avoid "knowledge rot"; if code can be easily understood, it can be more easily maintained by maintenance engineers who were not involved in the initial design).
This paper demonstrates the use of an ESS to build a simple rule-based system for the diagnosis of vaginal discharge. The author chose a well-defined, small-scale problem from the fields of gynaecology and venereology. The purpose of the system is to (clinically) evaluate vaginal discharge that may be abnormal in color, consistency, odor, and/or quantity, and reach a provisional diagnosis. The system can diagnose the following conditions: non-specific discharge as, for example, with pregnancy or contraceptive pills; pelvic inflammatory disease; bacterial vaginitis (bacterial vaginosis due to gardnerella and mixed); trichomonas vaginitis; vaginal thrush (candidiasis); vaginal foreign object; cervicitis and cancer cervix (no attempt is made to differentiate between the two conditions, which share the symptom of blood-stained discharge after intercourse); allergy to deodorant douches or spermicides; herpes genitalis.

II. Methods

1. Feasibility Study of the System

Expert systems have been successful in problems that require a heuristic approach to problem solving. However, not all heuristic problems are amenable to expert system solution. Therefore, an expert system project should always begin with an evaluation of the appropriateness of the technology.
The 'telephone test' has turned out to be an effective measure for determining those problems that are amenable to expert system solution [2]. According to this test, if a domain expert can solve the problem via a telephone exchange with the end-user, then an expert system can probably be developed to solve the problem.
The rationale underlying this test lies in the fact that the expert will have access to no additional information arising from other sources and the user will be able to describe the problem verbally. On the other hand, if the user is unable to describe the problem verbally, or the expert is unable, based on the telephone dialogue alone, to conclude a reasonable solution, then development of an expert system is likely to fail.
Our problem (crude diagnosis of vaginal discharge) can be solved via a telephone call, and is therefore amenable to expert system solution.
Other criteria to consider in a feasibility study are total costs of the system and availability of expertise (human experts in the problem domain acting as sources of knowledge). As the system that the author chose to develop was a small and simple one, costs were not an important issue, and being a medical doctor himself, he did not require external expertise for this particularly simple problem.

2. Knowledge Elicitation and Knowledge Acquisition

Knowledge elicitation is the process of obtaining knowledge about the domain from the human expert, while knowledge acquisition is the whole process of converting the extracted knowledge into a form suitable for use in an expert system.
The expert system builder must gain some familiarity with the problem domain by understanding its basic terminology and concepts, before attempting to elicit and gather knowledge from human experts and other sources. For medical systems, three knowledge sources can be used: clinical data, literature, and experts.
Expert knowledge is the most difficult source for knowledge acquisition. Interviewing is the most widely used knowledge acquisition technique for eliciting this kind of knowledge, but is not an easy method and needs good planning and preparation to succeed. The knowledge acquisition phase of expert system development is widely recognised to be the major "bottleneck" in the development of expert systems.
For this system (crude diagnosis of vaginal discharge), the fact that the author was the expert system builder and the human "expert" (source of knowledge) at the same time helped a lot and solved many problems. Knowledge must always be verified for correctness, and all possible problem scenarios need to be investigated in detail, taking into consideration all possible outcomes. To further ensure that the author's knowledge is accurate and complete (in the context of this particular problem with small demands), the author checked relevant clinical textbooks, such as the chapter on sexually-transmitted diseases in [3].

3. Knowledge Representation (Using Production Rules)

The system was implemented using production ('if-then') rules: if condition(s) then action(s). The 'if' portion (left-hand side) describes a problem-solving situation, in the form of one or more than one condition (antecedent(s)) combined with AND (conjunction) and OR (disjunction). These antecedents must be true in order for this rule to be applicable. The 'then' portion (right-hand side) describes the set of action(s) or consequents (an advice in the form of a text message in the case of the current system) that follow if the rule is applicable.
Production rules can be implemented easily in various existing ESS. For the current demonstration, the author used Expert System Shell for Text Animation (ESTA), a readily available ESS created in Visual Prolog [4].

4. Practical Stages Involved in the Design of the Demonstration System

These included 1) isolation of an area of the medical domain for prototyping and targeting a decision to be prototyped; 2) creation of a Mockler chart (dependency chart; Figure 1) [2]; 3) creation of a decision table (Table 1); and 4) rule extraction (from the decision table) and encoding using ESTA.
The author used pictures (attached to parameters) and 'canned text explanations' extensively throughout the system (Figure 2) to enhance ESTA's shallow explanation facility (mere rule trace when user presses the 'Why' button; does not give the real reason or "deep theory" behind a question or conclusion), and also add an educational dimension to the system for medical students and patients. Pictures are used in the system's consultation dialogues to emphasise the meaning of different questions and help the user select the appropriate answer if the patient's condition matches the photo shown.

III. Results

A simple rule-based system for the crude diagnosis of vaginal discharge was built using ESTA (Figure 2). The system runs under Microsoft Windows operating systems and is available as a free download from the author's server at (size, 837 kB; included in the distribution zip archive are both the program's executable ['vagdisch.exe'] and the commented ESTA knowledge base source [code] in a separate document in PDF format; to run the system under Microsoft Windows, simply unzip the distribution archive, launch 'vagdisch.exe' then open the 'Consult' menu and click 'Begin Consultation').

IV. Discussion

1. System Limitations

The problem of vaginal discharge is dealt with in this system in a simplified manner (but still practically useful and also suitable for the purpose of this demonstration). No attempt has been done to expand/cover all possible differential diagnoses/subsets of some of the conditions diagnosed, e.g., pelvic inflammatory disease (acute, subacute and chronic types) or herpes genitalis (vs. other causes of genital ulceration such as Behcet disease).
Patient age and laboratory diagnosis (e.g., pH of vaginal fluid, amine test, microscopic examination of a smear, etc.) have not been included for the sake of simplicity, and as such, the system remains a pure clinical exercise. No treatment recommendations are made, although these could have been added easily to the final advice messages, for example, "bacterial vaginosis (gardnerella vaginalis): metronidazole (Flagyl) 400 mg twice daily for 7 days; should be avoided during pregnancy, and ampicillin given instead in a dose of 500 mg 4 times daily for 7 days".
The system does not incorporate uncertainty or provide for the assessment of various degrees of a sign or symptom such as 'always marked', 'usually marked', 'may be present', 'usually present', 'usually absent', 'absent', etc. (only present or absent, 'yes' or 'no' states are allowed.) This could have been useful for assessing vulval pain or irritation. However, despite all these "compromises", the system performs perfectly well and correctly as intended in its current state.
Herpes genitalis (especially primary attack) is associated with marked vulval pain/sore when lesions are on the vulva (the system relies on this marked pain/soreness as one of the criteria for this particular diagnosis). Candidal, gardnerella and trichomonas vaginitis are usually associated with different degrees of vulval irritation/sore, but also have characteristic discharges (regarding color, odor, and consistency) upon which the system relies for making a diagnosis. The contraceptive pill, intrauterine devices and pregnancy can cause a vaginal discharge, but there should be no accompanying pain or vaginal irritation (the system relies on this absence of pain/soreness as one of the criteria for this particular diagnosis).

2. Production Rules: Pros and Cons

Production rules, as used in this demonstration system and other clinical systems such as [5], closely relate to human reasoning and can express heuristic knowledge. This makes rule-based systems easy to build in comparison with other methods for representing knowledge such as semantic networks, frames, propositional and predicate logic. Another feature of production rules is modularity, enabling knowledge bases to be constructed incrementally, step by step. Blocks of rules can be independently written and added to a rule base at different times, and checked for correctness.
However, rules, especially heuristic ones, often offer only shallow explanations (when using simple rule trace facilities), making the use of rule-based systems as learning tools somewhat difficult, unless they are modified to explicitly include deep ("theoretical") knowledge. Furthermore, the source code of systems containing a large number of rules (>200) can be difficult to follow and debug. Finally, rule-based systems have an inherent inability to learn in that they do not have the ability to modify themselves [1,2].

3. Rapid Development, Prototyping and System Evaluation

Our demonstrator system is a rather simple and straightforward one, but more complex systems in real-world must be continuously and rigorously evaluated and updated as necessary. Prototyping is fundamental when building expert systems. An initial rapid prototype (with just one main goal and few rules, as in the case of our current system) should be built and refined an "unlimited" number of times based on feedback and evaluation results from real users and/or experts (the latter might ask for amendments or exceptions to the rules). Our system could and probably should be expanded more in future iterations to address the above mentioned limitations.
This type of prototyping is called incremental prototyping since the remainder of the development will proceed with incremental advances on the first prototype. Gradually, the problem's domain can be expanded by carrying out further knowledge acquisition and testing until the system is "complete" and performs satisfactorily.
The prototype may also turn out to be unsatisfactory (unforeseen shortcomings that were unidentified during the feasibility stage, ineffective software tool/shell or knowledge representation formalism, bad user interface, etc.), in which case it might be discarded or major changes considered (throwaway prototyping).

4. ESTA and Other ESS for Rapid Clinical Decision Support Module Development

ESTA is very easy to learn and use, requiring minimal training and no previous coding experience, which makes it ideal for busy clinicians who can use it to produce and share various clinical knowledge bases and decision support modules of simple to moderate complexity, targeting clinicians in clinical practice (as an 'aide-mémoire', to ensure consistent clinical practice across the organisation and embed and enforce clinical guidelines in practice), medical and nursing students (for training and education purposes, e.g., by offering virtual clinical consultations with virtual patients), as well as patients, their lay carers and the general public (where appropriate; for example, to support decision making in self-management and first aid scenarios and educate patients/carers about various options that might apply to their conditions).
ESTA has been used for creating knowledge base modules to solve problems in different disciplines such as agriculture [6] and clinical medicine (e.g., ophthalmology [7]). An ESTA Web interface (running on a Microsoft Internet Information Services [IIS] Web server) is also available that can load and run knowledge bases (the same files with '.kB' extension used by the Windows desktop version of ESTA, but stored on the server) in a standard client Web browser over an intranet or the Internet. It should be possible to "package" and publish/share the client Web interface as a platform-neutral Web app for consumption on client mobile devices (smartphones and tablets). Other easy-to-deploy Web-based ESS also exists such as e2gLite ( [8].
In our demonstration system, canned text provides extended explanations (Figure 2). Canned text uses previously prepared text to enhance explanations, but can also mislead some users into overestimating the system's capabilities (because they may believe they are communicating in natural language with the system). However, clinicians can and should also use canned text to fully document/cite, embed and link to their sources of clinical evidence, such as systematic reviews and other references from Medline, specific sections of clinical guidelines, etc., within any clinical knowledge base they create.
With tools such as ESTA and e2gLite, clinicians can rapidly become their own 'knowledge engineers' and develop concise knowledge base modules of simple to moderate complexity. In the spirit of the social Web and its mashups, it is hoped that an online open access repository will one day be created and hosted by some trustworthy entity to peer review, publish and share knowledge base modules covering various clinical problems and algorithms, as a service to clinicians and students. The source of these modules should be offered in such a format (e.g., well commented, with human readable annotations) that makes it easy for others to reuse, edit/update, merge and expand the knowledge bases, and contribute back to the community, as well as to verify and update the underlying clinical evidence they are building on. The repository should adopt proper versioning and metadata practices to track the different revisions/versions of a given knowledge base module. Although ESS such as ESTA have been around for quite a long time now, this vision of a community repository of clinical knowledge base modules has yet to materialise.


No potential conflict of interest relevant to this article was reported.


1. Cawsey A. The essence of artificial intelligence. 1998. New York (NY): Prentice Hall.
2. Darlington K. The essence of expert systems. 2000. New York (NY): Prentice Hall.
3. El-Ghamriny M. Ghamriny's manual of clinical dermatology. 2011. 8th ed. Cairo, Egypt: Kasr El Ainy Medical School.
4. Prolog Development Center. ESTA: expert system shell for text animation [Internet]. c2012. cited at 2012 Dec 1. Broendby, Denmark: Prolog Development Center; Available from:
5. Kim JA. An implementation of nursing diagnosis expert system using VP-EXPERT. J Korean Soc Med Inform 1996;2(1):59-73.
6. Prasad R, Ranjan KR, Sinha AK. AMRAPALIKA: an expert system for the diagnosis of pests, diseases, and disorders in Indian mango. Knowl Based Syst 2006;19(1):9-21.
7. Asghar MZ, Khan AR, Asghar MJ. Computer assisted diagnoses for red eye (CADRE). Int J Comput Sci Eng 2009;1(3):163-170.
8. Khan FS, Razzaq S, Irfan K, Maqbool F, Farid A, Illahi I, et al. Dr. Wheat: a Web-based expert system for diagnosis of diseases and pests in Pakistani wheat. Proceedings of the World Congress on Engineering 2008 Jul 2-4. London, UK.
Figure 1
Mockler chart for diagnosis of vaginal discharge. IUD: intrauterine device.
Figure 2
User interface enhancement: pictures (attached to parameters) are used in the system's consultation dialogues. The value of a parameter is determined by the user's answer to a question. When such a question is posed during consultation, the user will have the option to ask the Expert System Shell for Text Animation (ESTA) to 'explain the question' (the 'Explain' button) if the knowledge engineer has provided an explanation in the parameter's explanation field. For this system, the author used 'canned text' extensively to enhance ESTA's shallow explanation facility (mere rule trace via the 'Why' button).
Table 1
Decision table for the provisional diagnosis of vaginal discharge (the system's goal)

FO: foreign vaginal object, abd_lowpelv_pain: abdominal or lower pelvic pain/tenderness, allergic_deod: allergic to deodorant douches or spermicides, birth_control_preg: on birth control pills, IUD, or pregnant, blood_stained: blood stained discharge esp. after intercource, dyspareunia: pain during sexual intercourse, fishy_gray_disch: fishy smelling, gray discharge, frothy: profuse and frothy trichomonas discharge, genital_blistr_sores: vginal, anal or groin blisters/sores, green_yellow_foulsmell: yellow-green, foul smelling discharge, heavy_normal_disch: normal but heavier than usual discharge, vag_pain_irrit: marked vaginal pain or irritation, white_curd_disch: thick, white, and curd-like/cheesy discharge.

Share :
Facebook Twitter Linked In Google+ Line it
METRICS Graph View
  • 3 Crossref
  • 8   Scopus
  • 3,661 View
  • 42 Download
Related articles in Healthc Inform Res


Browse all articles >

Editorial Office
1618 Kyungheegung Achim Bldg 3, 34, Sajik-ro 8-gil, Jongno-gu, Seoul 03174, Korea
Tel: +82-2-733-7637, +82-2-734-7637    E-mail:                

Copyright © 2024 by Korean Society of Medical Informatics.

Developed in M2community

Close layer
prev next