A Personalised Patient Information System Using GRAIL

In this paper we describe and assess the use of the GRAIL knowledge representation in the development of an advanced personalised patient information system. The patient information system uses natural language generation techniques from Artificial Intelligence which enable the content and wording of medical information to be personalised automatically. The GRAIL representation is extended to generate text from the stored medical and patient information. We assess the benefits and limitations of the GRAIL approach, comparing it with the use of an ad-hoc knowledge representation based around the Read code hierarchy. Introduction In previous work [1] we have argued the benefits of personalised patient education systems, and described an architecture, based on Artificial Intelligence techniques, for the development of such systems. We describe a system for providing information for patients with diabetes, which selects information relevant to the patient, and presents it as a hypertext document. Our approach centres on the idea of having a structured knowledge base representing medical knowledge in a declarative, objective way, some information about the patient (possibly taken from the medical record), and a set of rules for determining what to say, extracting relevant information from the knowledge base depending on the information about the patient. This is illustrated schematically in figure 1. The text generation rules both select the content and determine how a particular fact should be conveyed (as a sentence). This latter task is sometimes referred to as sentence planning and includes things like deciding on whether to convey a list of items as one sentence or many, and deciding what pronoun to use. In our previous work we based the medical knowledge base on the Read code hierarchy. In essence, each Read code (in the application area to be considered) was represented as an object, with isa relationships (e.g., ischaemic heart disease isa circulatory disease) between Patient Information Medical knowledge Personalised hypertext information. Text generation rules Figure 1. A Knowledge-Based Personalised Patient Information System objects based on the hierarchical organisation of Read codes. Additional information about an object (say, Diabetes Mellitus) was represented as attributes or slots of that object (e.g., we would have a symptoms slot for diseases). The text generation rules were represented in an ad hoc language, with rules associated with object classes. So, we could have a rule associated with the disease class which stated how a text page for a disease should be constructed, based on information in the knowledge base + patient data. More detailed rules would state how individual facts should be conveyed (e.g., informing the patient about the symptoms using the form: “The symptoms of DISEASE are: S1, S2 and S3”.) We recognised three problems with this approach: • There are problems with the use of the Read code hierarchy: 1. Some concepts are assigned more than one code depending on their context and related concepts appear in quite different places in the hierarchy. 2. There is no notion of multiple inheritance, where a concept can have more than one parent class. 3. Every possible concept might be enumerated and be assigned its own code. There is no framework for combining or modifying existing concepts. • The language used to represent the content selection rules was too general, allowing arbitrary rules (using any constructs of the programming language), making the system hard to maintain. • There was no mechanism for checking the validity of medical data entered. It was quite possible to, for example, enter a code for a part of the body in a symptom list. These problems suggested the use of a more structured representation language for both medical knowledge and content selection rules. GRAIL, used by the GALEN project [2] seemed a good choice, being designed as a general knowledge representation language, yet tailored to the needs of medical terminology. It: • Allows multiple inheritance, and allows new concepts to be composed from existing ones. • Provides a constrained, well defined yet flexible language, with corresponding benefits in maintaining and checking rules and medical knowledge. GRAIL is also similar, as a knowledge representation language, to LOOM, used in related projects in the USA [3]. In the rest of this paper we describe the design of a system using GRAIL, and our conclusions based on attempts to use this system in a practical project. A Grail-Based System In our new design, medical knowledge, patient information and content selection rules are all written in GRAIL. Much simplified examples are given below of each type of knowledge. The first two define some knowledge about lymph node metastases, a type of cancer, while the third gives information about a particular patient who is being treated for this problem. Problem newSub Cancer hasName “cancer”. Cancer newSub LymphNodeMetastases hasName “lymph node metastases” hasLocation LymphNodes hasCause Cancer hasDescription "secondary tumours of the lymph nodes" hasPossibleTreatment [chemotherapy radiotherapy surgery]. Patient newSub JoeBloggs hasName “Joe Bloggs” hasAge 50 hasProblem(LymphNodeMetastases hasTreatment chemotherapy) In addition, we have rules which describe how to select content to generate some text output, for example: PatientDetails hasFocus Patient text “your name is ” insert hasName text “and you have” insert hasProblem with ProblemDesc. ProblemDesc hasFocus Problem link describeProblem Focus insert hasName. We can query the system to find the text (and hypertext links) associated with a particular concept. This defines a page of text to be output, which can be passed to a hypertext viewer and presented to the user. The two preceding rules produce the following output, in which the words “lymph node metastases” link to a new page of information. Your name is Joe Bloggs and you have lymph node metastases. The rules for generating text about lymph node metastases differ depending on whether the patient is being treated for this problem or not. describeProblem hasFocus (Problem which hasTreatment) insert Problem text “ are “ insert hasDescription text “ which result from “ insert hasCause with ProblemDesc text “Your treatment for this problem is “ insert hasTreatment with TreatmentDesc. describeProblem hasFocus Problem insert Problem text “ are “ insert hasDescription text “ which result from “ insert hasCause with ProblemDesc text “Possible treatments for this are “ insert hasPossibleTreatment with TreatmentDesc. The output for Joe Bloggs would use the first rule and is therefore: Lymph node metastases are secondary tumours of the lymph nodes which result from cancer. Your treatment for this problem is chemotherapy. For a patient who had asked for information about lymph node metastases but was not undergoing treatment for them, the second sentence would read: Possible treatments for this problem are chemotherapy, radiotherapy and surgery. Cancer and chemotherapy are hypertext links in themselves. Clicking on cancer creates a screen for cancer using a similar rule to the one describing lymph node metastases. Clicking on chemotherapy would create a further screen which describes chemotherapy in general and also when appropriate the patient’s own chemotherapy treatment (rules not shown here). Our personalised patient education system’s expertise lies in deciding how to present medical information to the patient [4]. It must take into account what information is relevant to each patient. It must select a style of presentation with suitable wording, and finally it must generate coherent sentences. Further discussion of the issues and techniques in generating natural language for patient information will be found in [5]. This differs from the emphasis of more conventional medical expert systems, where the system reasons about medical knowledge to assist a medical professional in making a diagnosis or in choosing a treatment. Our system presents the patient with the diagnoses and treatment recommendations that have previously been made by doctors. We use the GRAIL representation to store this existing medical information, general and patient-specific. We have also extended the GRAIL representation to generate text and to select content for information presentation.