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.

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].

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].

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.

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).

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].

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).

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 (http://expertise2go.com/) [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.