Since the early 1970s, researchers in computer-based medical reasoning have begun to recognize the potential benefits of applying symbolic reasoning techniques in clinical domains (see Chapter 3). One such research group is the Heuristic Programming Project at Stanford University. The first medical reasoning program developed by the project, known as the MYCIN system (Shortliffe, 1976), adopted symbolic processing techniques largely in response to a conviction that computer-based consultation systems, in order to be accepted by physicians, should be able to explain how and why a particular conclusion has been derived. Such systems should also be able to incorporate, organize, manipulate, and update large quantities of medical knowledge. Subsequently, a series of additional medical application programs using MYCIN's techniques has been created.

Turing's test (see evaluation) smart instruments, 345

Chapter 10 Chapter 11 Chapter 12 Using Rules The Evolution of MYCIN's Rule Form The Structure of the MYCIN System William van Melle Details of the Consultation System Edward H. Shortliffe Details of the Revised Therapy Algorithm WiUiam J. Clancey Building a Knowledge Base Knowledge Engineering Completeness and Consistency in a Rule-Based System Motoi Suwa, A. Carlisle Scott, and Edward H. Shortliffe Interactive Transfer of Expertise Randall Davis Reasoning Under Uncertainty Uncertainty and Evidential Support A Model of Inexact Reasoning in Medicine Edward H. Shortliffe and Bruce G. Buchanan Probabilistic Reasoning and Certainty Factors J. Barclay Adams 55 67 78 133 149 159 171 209 233 263

Steps toward a theoretic foundation for complex knowledge-based CAI.

Rephrases the question and gives examples of recognized responses.

In this book we have presented experimental evidence at many levels of detail for a diverse set of hypotheses. As indicated by the chapter and section headings, the major themes of the MYCIN work have many variations. In this final chapter we will try to summarize the most important results of the work presented. This recapitulation of the lessons learned should not be taken as a substitute for details in the sections themselves. We provide here an abstraction of the details, but hope it also constitutes a useful set of lessons on which others can build. The three main sections of this chapter will reiterate the main goals that provide the context for the experimental work; discuss the experimental results from each of the major parts of the book; and summarize the key questions we have been asked, or have asked ourselves, about the lessons we have learned. If we were to try to summarize in one word why MYCIN works as well as it does, that word would be flexibility.

This chapter describes an oncology protocol management system, named ONCOCIN after its domain of expertise (cancer therapy) and its historical debt to MYCIN. The program is actually a set of interrelated subsystems, the 1 primary ones being: 1. the Reasoner, a rule-based expert consultant that is the core of the system; and 2. the Interviewer, an interface program that controls a high-speed terminal and the interaction with the physicians using the system. The Interviewer is described in some detail in Chapter 32. This chapter describes the problem domain and the representation and control techniques used by the Reasoner. This chapter is based on an article originally appearing in Proceedings of the Seventh IJCAI, 1981, pp. Used by permission of" International Joint Conferences on Artificial Intelligence, Inc.; copies of the Proceedings are available from William Kaufmann, Inc., 95 First Street, l.os Ahos, CA 94022. Another program, the Intemctor, handles interprocess communication.

A number of computer programs have been developed to assist physicians with diagnostic or treatment decisions, and many of them are potentially very useful tools. However, few systems have undergone evaluation by independent experts. The task evaluated was the selection of antimicrobials for cases of acute infectious meningitis before the causative agent was identified. MYCIN was originally developed in the domain of bacteremias and then expanded to include meningitis. Its task is a complicated one; it must decide whether and how to treat a patient, often in the absence of microbiological evidence. It must allow for the possibility that any important piece of information might be unknown or uncertain.

Here we consider the logical bases for rules: what kinds of arguments justify the rules, and what is their relation to a mechanistic model of the domain? We use the terms "explain" and "justify" synonymously, although the sense of "making clear what is not understood" (explain) is intended more than "vindicating, showing to be right or lawful" (justify).

This chapter explores a number of issues involving representation and use of what we term meta-level knowledge, or knowledge about knowledge.1 It begins by defining the term, then exploring a few of its varieties and considering the range of capabilities it makes possible. Four specific examples of meta-level knowledge are described, and a demonstration given of their application to a number of problems, including interactive transfer of expertise and the "intelligent" use of knowledge. Finally, we consider the long-term implications of the concept and its likely impact on the design of large programs. The context of this work is the TEIRESIAS program discussed in Chapter 9. In the earlier chapter we focused on the use of TEIRESIAS for knowledge acquisition. Here we focus on the classification and types of knowledge used by TEIRESIAS. In the most general terms, meta-level knowledge is knowledge about knowledge. Its primary use here is to enable a program to "know what it knows," and to make multiple uses of its knowledge. As mentioned in Chapter 9, the program is not only able to use its knowledge directly, but may also be able to examine it, abstract it, reason about it, or direct its application. This chapter discusses examples of meta-level knowledge classified along two dimensions: (i) specificity character (representation-specific vs. domain-specific), and (ii) source (user-supplied vs. derived). Representation-specific meta-level knowledge involves supplying a program with a store of knowledge dealing with the form of its representations, in particular, their design and organization. Traditionally, this design and organization infor-This chapter is an expanded and edited version of a paper originally appearing in Proceedings of the Fifth IJCAL 1977, pp. Used by permission of International Joint Conferences on Artificial Intelligence, Inc.; copies of the Proceedings are available from William Kaufmann, Inc., 95 First Street, Los Altos, CA 94022. IFollowing standard usage, knowledge about objects and relations in a particular domain will be referred to as object-level knowledge. Type declarations are a small step toward more explicit specification of this information, especially as they are used in extended data types and record structures. As we discuss below, this sort of information, along with a range of other facts about representation design, can be employed quite usefully if it is made explicit and made available to the system.