Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
User-Centred and Driven Knowledge-Based Systems for Clinical Support using Ripple Down Rules Debbie Richards Department of Computing Division of Information and Communications Sciences Macquarie University Sydney, Australia Email:
[email protected] Abstract Ripple Down Rules (RDR) are a case-based reasoning technique that have been developed in answer to the need to provide a way of maintaining large KBS in domains where knowledge and practice are continually being reviewed. RDR are based on the view that knowledge is not an artifact but something that is "made-up" to fit a particular situation. In keeping with this, maintenance and context are key issues. RDR offer a number of features that make it particularly suitable for clinical support. These features are: knowledge is captured, changed and validated within the local context of cases; KA is simple and designed to be performed by the domain expert; and the use of cases, difference lists and the exception structure are intuitive and natural for experts. In medical domains, ownership and control of knowledge are seen as important issues and the ability to build a KBS without the need for a knowledge engineer is a real plus. The ease of developing and maintaining an RDR KBS means that it is feasible for individual pathology laboratories to customise the system to suit the local knowledge which they contain. This paper describes RDR, how they provide an environment for interacting with the knowledge according to the decision situation of the user and some results-to-date in the area of pathology.
1. Introduction: Building Acceptable KBS While Ripple Down Rules (RDR) are a knowledge acquisition (KA) and representation technique that have been applied in a wide range of domains, it is in the field of clinical pathology that RDR have had and continue to have the greatest success. Unlike many medical expert systems that have never been deployed, RDR knowledge based systems (KBS)1 are being put into routine use. A key reason why RDR have moved from the computer laboratory to the pathology laboratory is that they address
the four dimensions of acceptance of medical expert systems identified by Preece [35]: technical, ergonomic, organisational and ethical. Many expert systems only consider the first dimension of technical competence. RDR are a different paradigm from mainstream approaches in that KA is a simple task performed by the pathologist who is responsible for and has control over the knowledge acquired. The ability to tailor and control the system allows a better "ergonomic" fit to the individual pathologist as well as an "organisational" fit to the laboratory. An "ethical" fit is supported by allowing the incorporation of practice guidelines used by the particular laboratory and suggested by medical bodies. The interpretation provided by the system is checked by the pathologist which provides quality control and results in two expert opinions for each report (if the pathologist disagrees with the system’s comment the report will be amended and the KBS updated). The interface and style of interaction is transparent [50] and fits well with the domain and the users. The incremental nature of KA allows for the knowledge base to evolve as new cases are seen in keeping with the view that knowledge is never complete. Additionally the use of cases is natural in this domain and the use of exceptions and difference lists are easily understood by experts. In the next section we look at two important issues that affect the acceptance of knowledge-based systems: ownership and control; and the human-computer interface. In Section 2 we look in greater depth at RDR and pathology systems using this technology. Section 3 considers human-computer interaction (HCI) using RDR including: how KA and inferencing are performed as well as recent research which allows the user to ask a variety of different types of questions according to their decision situation. Section 4 includes a case study evaluating the combined use of RDR and Formal Concept Analysis [49] for modelling, explanation and learning purposes using a blood gases KBS. Section 5 concludes with consideration of other similar research and future directions.
1 The terms knowledge based system and expert system are used interchangeably in this paper.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
1
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
1.1 The Importance of Control and Ownership Since the advent of the computer, users have come of age and want to have control of the application [33, 40]. Users of experts systems do not want to relinquish decision making to a machine [20, 27]. In the case where the user is an expert this concept is easily accepted. However various research efforts have shown that novices also wish to be in control of the decision situation. Kidd [25] studied discussions between experts and novices where it was shown that the novice wanted to be able to propose solutions, evaluate remedies and have the remedy explained. The process was a form of negotiation. Kidd argues that the user approaches the activity with intentions, expectations and constraints. The ES needs to assist the user with exploring the ’remedy space’ by a process of evaluation and comparison. Hender and Lewis [19] consider control to be a key issue in the design of user interfaces for expert systems. Experts want control and want to be able to validate and alter the knowledge. This involves understanding the reasoning process used by the system and the justification for the recommendation. They believe novices are more likely to accept the expertise offered without as much scrutiny but want a better interface to improve access to the knowledge. We go on to look at interface issues next.
1.2 Human Computer Interaction Issues Mainstream KA approaches require complex analysis of the domain before KA can take place [46]. This has resulted in a preoccupation with knowledge modelling rather than user requirements and systems designed for knowledge engineers rather than experts or end-users. By simplifying the KA technique and making the user responsible for KA and maintenance we are able to focus more on user requirements elicitation rather than knowledge elicitation. Lack of attention to HCI issues is identified as a major contributing factor to the poor acceptance of early expert systems [27, 39]. Typically interaction was offered in consultation mode where the user is asked some questions and a recommendation is made by the system. Consultation mode has been criticised as inappropriate for user control, visibility and user initiative [1]. Clancey [7] has found it to be ‘superficial” as the line of questioning approach does not allow the user to build a model that they can manipulate. We look at alternatives to this mode later in section 2.3. The mismatch between the way the user is required to interact and a way that suits the user’s mental model can be viewed as a breakdown [50]. “The ability to resolve breakdowns adaptively is a basic human cognitive capacity” [47, p.15]. There is a considerable body of research into adaptive systems. This covers problem-
solvers and learning systems, such as Soar [26] and Prodigy [3] and reflective learning systems such as Teiresias [12], MetaAqua [36] and Autognostic [43]. Some of these systems are able to detect a success/failure, assign credit/blame and revise beliefs of/repair the system. While not achieved by all of these systems they all share a common goal, perhaps with the exception of Teiresias, to perform learning independent of human intervention. The RDR approach is to keep the human-in-the-loop and is interested in building user-adaptable systems rather than self-adapting systems. The system reported in this paper learns by helping the user to learn about their domain, reflect on the knowledge and incorporate any new insights into the system. The system offers a wide range of activities and leaves the user to select the tools appropriate for their purpose. A system that will be widely acceptable to clinical pathologists must support the ability to tailor the system to fit with the laboratories local knowledge and local practice. Allowing the user to decide how to use the system is seen as a better alternative to creating systems that anticipate what the human wants to do, such as systems that include user models [4, 44]. The simplicity of KA as described in section 2.2 aims at minimising system breakdowns by providing an intuitive environment. This close match between the way the expert performs the task and the way the RDR system behaves is a key reason for its success. In addition, the ability to directly interact in a wide range of user-selected modes described in section 2.3 addresses the users desire for system flexibility, system usability and user control.
2
What are Ripple Down Rules
RDR were developed in answer to the problems associated with maintaining a large medical KBS. It was observed that experts did not give explanations of why they had chosen a particular recommendation but rather they tended to justify their conclusion based on some feature/s of the case [8]. This observation resulted in an emphasis on capturing knowledge in context by storing of the case that prompted a new rule to be added. The unwanted side effects associated with typical rule-based systems [42] were also avoided by the development of the exception structure which is designed to localise the effect of additional rules. The emphasis on maintenance has resulted in a KA technique that is failure-driven (rules are only added in response to a wrong conclusion) and which not only supports but expects incremental system development and on-line validation of knowledge. Until recently, the major success for the RDR approach has been the Pathology Expert Interpretative Reporting System (PEIRS) [14], a large medical expert system for pathology laboratory report interpretation built by experts with minimal intervention of a knowledge engineer.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
2
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
PEIRS is one of the few medical ES that have actually gone into routine use. It went into operation with 198 rules and expanded over four years into over 2000 rules, covering 12 different tests in a number of subdomains, including blood-gases, thyroid, liver functions, endocrines and catecholamines. The total development time was around 100 hours and requiregd a small amount of time each day, approximately 15 minutes, of the experts time to maintain the system. The development of 10 rules per hour for RDR is outstanding compared to industry standards of only 2 or 3 rules per day [13]. The pathologist’s role was to check the comments and modify the rules which gave the wrong conclusions. While it did not eliminate this work for the pathologist it was much quicker than writing the comment, as 95% of cases were correct. A comment based on expert knowledge which has been reviewed by a human expert adds value to the report as it means that comments are more likely to be consistent and that each interpretation is based on two opinions. None of us, the patient or the physician, would want to drop the human out of this loop but a second opinion is always advisable. Despite the random order in which knowledge is added, simulation studies have shown that the RDR approach of correcting errors as they occur produces KBS that are at least as compact and accurate as those produced by induction [10, 11]. RDR are an incremental KA technique and are well suited to domains where new cases are seen on a regular basis as in pathology. Rather than try to describe the whole domain up front, knowledge is acquired and maintained as needed. While a number of implementations of RDR exist there have been two main implementations: the original single classification and more recently multiple classification RDR (MCRDR). PEIRS used single classification RDR but current research and the commercial version of RDR uses MCRDR.
2.1 Multiple Classification RDR MCRDR have been developed to handle classification tasks where multiple independent classifications are required [21, 22]. This method builds n-ary trees and consists only of exception branches. A better description may be sets of decision lists joined by exceptions. In contrast to single classification RDR, all rules attached to true parents are evaluated against the data. Figure 1 shows an example MCRDR showing two levels of decision lists. An MCRDR is defined as the quadruple , where P is the parent rule, C are the children/exception rules and S are the sibling rules within the same level of decision list. Every rule in the first list is evaluated. If a rule evaluates to false then no further lists attached to that rule are examined. If a rule evaluates to true all rules in the next list are tested. The list of every true rule is
processed in this way. The last true rule on each path constitutes the conclusions given. Rule 1: a,c È C1
Rule 3: e È C4 Rule 6: f,e È C6
Rule 0:
Rule 2: a,d È C2
True
Rule 8: i È C7 Rule 5: g,hÈ C5
Rule 4: k È C3
Rule 7: d,g È C5
Rule 9: i È C7 Rule 10: a,h È C8
Figure 1: An MCRDR KBS. The highlighted boxes represent rules that are satisfied for the case {a,d,g,h,k}. We can see that there are three conclusions: Class 2(Rule 2), Class 5 (Rule 5) and Class 8 (Rule 10).
Simulation studies [22] have shown MCRDR to be a superior representation to the original RDR structure by producing knowledge bases that mature more quickly and are more compact even for single classification domains. It is conjectured that this occurs because more use is made of expertise rather than depending on the KB structure [21]. For the domain of chemical pathology the ability to assign multiple classifications to an individual case was important as there are often a number of comments that are applicable depending on the combination of features in the case. Rather than having to create classifications that were in fact combinations of classifications it was possible to identify these individually, resulting in quicker coverage of the domain and fewer rules [13]. The use of RDR in clinical pathology is not limited to PEIRS. A commercial version of MCRDR is currently in use in over a dozen pathology laboratories covering a range of difference tests and diseases. The system is known as LabWizard and is being developed by Pacific Knowledge System (PKS). The system has been well accepted by pathologists and other laboratory workers. Users have found the system easy and friendly to use and the acquisition of knowledge has been rapid. For example, one system with over 7,000 rules was developed at a rate
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
3
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
of 1 rule per minute. We plan to perform some detailed case studies comparing the experiences at different laboratories but some interesting results have already become apparent. A few of the sites were already using expert systems to assist them in the analysis of results. It has been found at these sites that there is a tendency to encode the same knowledge and use the system in the same way as in the previous systems rather than to look afresh at the domain and at practise to take advantage of the superior technology. It appears that the users need to broaden their view of the role of the technology to become more creative in the knowledge they "make up". To a large extent it means that the laboratories need to expand their business goals to match the potential of the tool. Such a situation is a classic example of technology push versus market pull and the dilemmas that arise in a commercial environment. Another outstanding issue is the incorporation of guidelines that would be used as the base of the system on top of which laboratories can add local knowledge. This is another hard question as there is no clear agreement on which guidelines are widely acceptable and which guidelines are appropriate for customisation. There is some current work which allows knowledge bases to be compared and combined [37] which could be applied so that knowledge from one practice could be incorporated into another practice. Future directions for the commercial system include: on-the-fly model building where the expert not only rejects a report but indicates the reason and the system automatically updates the rule-base; use of natural language in specification of the conditions; the development of collaborative KBS across laboratories (one is proposed in the area of lipids); and reorganisation of the KBS to improve the clarity of the explanations and to reduce maintenance time.
3
Interaction in Ripple Down Rules
This section looks at the typical KBS modes of interaction such as KA, maintenance and validation as well as some more explorative modes including critiquing, causal modelling, explanation, tutoring, what-if analysis, hypothesis testing and student modelling. All of these modes are particularly relevant to medical domains where it is common to have domain experts (e.g. the clinical pathologist) and novices (e.g. interns) dealing with the same knowledge and where decision making will involve a number of strategies and different types of interaction.
3.1 KA, Maintenance and Validation Patient cases naturally occur in the pathology domain, which would be true of most medical domains, and are the driving force in KA using RDR. In single classification
RDR, only one case is associated with each rule. In MCRDR there may be multiple cases that must be distinguished from the current case. In the KA approach developed, the expert performs as inference on a case and is given a system assigned conclusion. If the user agrees with that conclusion they run the next case. If they do not agree they chose to add a new rule which assigns a new conclusion. The conditions for the new rule are based on information in the current case and one of the cornerstone cases associated with the rule that gave the misclassification. The expert picks some feature which distinguishes the two cases. A difference list between the current and cornerstone case are provided for the user to assist in this task. The cornerstone list of cases is evaluated to test if other cornerstone cases are also distinguished by the new rule. If a case is satisfied by the rule the expert must add extra conditions to the rule to distinguish this case. This continues until all related cornerstone cases are distinguished. Remarkably the expert provides a sufficiently precise rule after two or three cases have been seen [22]. The user may also decide to stop an incorrect conclusion instead of replacing it with a new conclusion. This is achieved by adding a stopping rule which has a null conclusion in the same way as adding other types of rules. The process is summarised in Figure 2. Set up empty KB
Run pathology case
System assigns conclusion. Expert evaluates.
Expert agrees
Expert disagrees
Assign new diagnosis. Pick features in case (using difference list) Figure 2: The KA process in RDR. The dramatic difference between the simple RDR approach to KA and mainstream approaches that require complex modelling hinges on the fundamental differences in the philosophical foundations of these approaches. RDR does KA with minimal analysis [9] on the basis that experts use what is in their head to "make up" a solution to fit the situation. The capture of behavioural knowledge based on cases appeared to offer a solution which avoided trying to understand what went on inside the experts head.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
4
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
Mainstream approaches to KA rely on the development of a model of the domain knowledge and a model of the reasoning processes of the expert. The development of such models is complex and difficult and requires a KE to mediate between the expert and the ES. In RDR there is no clear distinction between the building of the system and initial knowledge acquisition, the maintenance phase and even use of the system for reasoning. All three activities are performed as part of the KA process, although it is possible to perform inferencing as an activity on its own for the purposes of consultation. As was shown in PEIRS, an RDR system can be set up quickly with minimal assistance from a knowledge engineer and then maintained completely by the expert. Since the same system is used for KA and inferencing it allows validation at KA time by performing an inference on the case which prompted the new rule. The general RDR approach to V&V has been briefly presented and is based on the use of cases to ensure no new rule misclassifies a previously classified case. Extensions to the RDR approach to verification and validation include computer-assisted validation using formal concept analysis [49] and off-line verification, using rough set theory [32]. For further discussion and evaluation of incremental verification and validation of RDR see [23].
3.2 Critiquing. Critiquing has been described as a system style where the user can receive advice from the computer, have their own decision critiqued and be able to override the recommendation of the computer [39]. Miller [31] claims that such an approach is often more suitable, especially in medical domains, where it is inappropriate for the system to tell the user what to do. Critiquing does not offer a “do this” generic solution but provides a way of supporting the expert and providing that support in a way that is based on the user’s thinking and style of practice. One such system is the Therapy-Helper Project (T-Helper) [28] which has become part of the EON Project [45]. The Eon Project is concerned with protocol-based care. Online patient data and knowledge concerning protocols from a wide range of clinical information systems are used to determine when a protocol applies, to recommend a course of treatment and “to critique patient care that deviates from recommended practice patterns” [45, p.1]. In RDR, critiquing is offered at the conclusion and rule levels, in keeping with the KA approach. When a user decides to assign a new conclusion (the first step in developing a new rule), the user may select a conclusion and click the critique button to have the new conclusion evaluated against all other paths (rules) that gave the same conclusion. If those rules are inconsistent with the current case the user is notified of the anomaly. By showing the
user the rules in conflict they can either change their conclusion, select an existing rule to add a refinement to, add a new rule higher in the tree or add a stopping rule to stop the conclusion being reported for this case (and any others with the same features). In MCRDR/FCA the user may input their own recommendations and have the system either state that it agrees or show how the system would reason about the same case. The user is able to override the system’s conclusion but is offered an explanation of the system’s plan so that the user may contemplate whether they missed something important. As described in Section 4 and shown in Figure 4, the MCRDR/FCA abstraction hierarchy provides some understanding of the relationships and structure of the knowledge.
3.3 Causal Modelling. Knowledge in many medical domains is causal. The ability to depict the knowledge as a causal model enhances the physician’s ability to understand, apply, teach or modify that knowledge. The explanations given by Lee and Compton [29] are in such a form and are known as a CMOD model. Referring to a graph which showed how the final conclusion fitted in with the known findings Clancey comments: “for the purpose of teaching, this graph could perhaps be the best way to reify the process of diagnosis” [6, p.56]. Lee and Compton [29] have reused heuristic knowledge so that it provides causal explanations. They argue that causal models provide more useful explanations, particularly for learning, than those missing causal links but that construction of such explanations is difficult. The CMOD algorithm provides a way of automatically generating the links. The model is also useful for validation as it is checked for consistency each time a heuristic rule is added. If links are missing or wrong the model is modified automatically or with user assistance. As is recorded in point 1 of the dialogue in Section 3, line diagrams may also be used to suggest causal relationships or to clarify where an apparent causal relationship is in fact invalid.
3.4 Explanation and Tutoring A key feature of early expert systems was their ability to offer an explanation of the reasoning process. This was typically done in the form of a rule trace. While the rule trace was a valuable feature, it had various shortcomings. In particular the rule trace was not user-friendly. Clancey [5] makes the point that students should not just be able to confirm a diagnosis but they should be able to learn under what circumstances that conclusion should be considered and what other possible diagnoses explain the data. This is supported through the RDR exception structure by
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
5
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
offering not only an explanation of why a particular conclusion was given but also why other conclusions had not been given and what values could be altered to reach another conclusion. The rule pathways provide a deeper view of the knowledge because they provide the history and context in which a rule exists. The cases associated with each rule support another contextual dimension of explanation. The impetus for providing better explanation stems from the attitude that if the user understands why the ES came to a certain conclusion or asked a particular question then the user is empowered to use the knowledge in a better way. An alternative and possibly contentious suggestion [13] is that explanation is not really so important in deciding whether to accept advice. Rather, the lack of trust stems from a lack of system credibility. If statistics were kept regarding the number cases seen and correctly classified, it would be possible to determine the accuracy of the system and let the user evaluate the system’s credentials before deciding to accept the current conclusion. This strategy has been implemented for RDR KBS [13, 15]. The suite of features, known as exceptions, prudence and credentials, collects various statistics and determines when a system is acting within its knowledge boundaries. RDR offers an alternative view to existing explanation research. The focus of much explanation research is on providing a detailed line of reasoning to the user. It is argued here that a different approach to explanation is worth considering since we do not really understand what expertise is and how an expert arrives at a conclusion. It may be that if we provide the user with enough information on the circumstances under which the rule was meant to apply and the relationships of that rule to other rules, which is offered to a large extent by the RDR structure, the user can develop a line of reasoning that works for them. The RDR toolkit supports the user in performing explanation and tutoring through: the rule trace which can be visually represented as a tree; rule and tree browsers; traces and extended traces; the test pathways screen for comparing two rules or one rule against all other rules; the knowledge structured into an abstraction hierarchy as shown in the concept matrix or lattice (Figure 4); the ability to select numerous views of the KBS on which to focus and the ability to compare the models in different KBS [37]. The user is free to use and reuse knowledge in any of these ways according to their current needs and preferences. The case study in Section 3 gives an example of how the line diagrams may be used for learning about a domain
3.5 What-if analysis, Hypothesis Testing and Student Modelling The ability to test out different scenarios is an important human activity as evidenced by the popularity of spreadsheet software which contributed to the widespread acceptance of the personal computer and Decision Support Systems (DSS) in the 1980s. RDR supports ’what-if’ analysis by allowing the user to add or delete attributes or alter one or more values in a case and then look at the result.. Hypothesis testing is a more specialised application of ‘what-if’ analysis because the user starts with an expected outcome and explores various scenarios in pursuit of confirming or disconfirming their hypothesis. A major problem with ‘what-if’ systems is that people tend to avoid “disconfirming evidence” [34, p.366]. The use of ES for hypothesis testing is seen as superior because there is expert knowledge which can be used to show inconsistencies in the reasoning process. For example, the work by [16] found previously published assumptions (hypotheses) could not account for all the results they had and prompted further exploration and refinement of the hypotheses. Similar work on a smaller scale but using the same data was performed by [30]. In section 4 (point 6) it is shown that the FCA line diagrams can be used to propose a hypothesis which can be tested and refined by using some aspect of the original line diagram to generate a new line diagram. Student modelling is another exploration type of interface the key difference is that a profile of the student is often used to guide the interaction. User models often require the use of stereotypes which can be problematic as “tailoring based on a bad user model is probably worse than no attempts at user tailoring at all” [4, p.7]. Given that the emphasis in MCRDR/FCA is on user control and system flexibility we do not want to restrict the user, even a student novice, in what they are able to do. There is however the opportunity for a user to test out their knowledge about a domain. In a study performed by the Health Insurance Commission (HIC) of NSW [48], RDR were used to develop a KBS to detect fraudulent practitioner behaviour. As part of the process, the HIC had an expert classify the practice profiles of 1,500 medical practitioners. A member of the computer department then used these cases to develop a KBS. Through the use of RDR it was soon realised that there were many inconsistencies in the classifications assigned by the so-called expert. If the RDR KA technique had been followed the expert would have been presented with the cases and been forced to provide consistent conclusions as each rule was being built. RDR would have forced the expert to review his knowledge of the domain particularly where he held conflicting opinions. This would have also saved a duplication of effort and would
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
6
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
have resulted in a set of well-classified cases and a validated knowledge base.
4. A Case Study of the Use of MCRDR/FCA for teaching in the Blood Gases Domain A number of case studies and a survey have been conducted to evaluate the usefulness of the MCRDR/FCA approach for learning about a domain. The case studies involved using a number of MCRDR KBS from different domains and exploring the knowledge using the MCRDR/FCA tool. The observations made from these explorations were presented to relevant domain experts for their opinions. In this section, extracts of the results from a case study for the Blood Gases KBS, known as 105, are included. As preparation for the meeting, 11 line diagrams were drawn based on selections the domain novice thought might be useful. One of the line diagrams is shown in Figure 4. In a real teaching system the student would be more directed and probably be given questions to pursue or have questions that had arisen from other learning situations such as reading or a lecture. A brief synopsis was made of each diagram in one to ten sentences. Any reference to particular parts of the diagram were removed and resulted in one and a half pages of written description of what had been learnt about the domain. The one and a half pages were given to the expert for comment. Only part of the dialogue is reproduced here. A full account can be found in [38]. Observations are numbered, the experts comments follow and remarks of the novice are italicised.
1.
Selected conclusion family %RK. The key features of the case to consider for this class of conclusions are BLOOD_PH and BLOOD-PC02. All rules are concerned with BLOOD_PH being high or having been high (over 7.45) except for rule 30 which concludes %RK002 when BLOOD_PH is NORMAL, BLOOD_BIC is LOW and BLOOD_PC02 is LOW. As was noted earlier there appears to be an inverse causal relationship between BLOOD_BIC and BLOOD_PH and the fact that BLOOD_BIC is LOW may indicate that BLOOD_PH is expected to become HIGH. If BLOOD_PH has been high at any stage then an increase in BIC and decrease in PH and BIC will give the conclusion %RK004.
The expert thought this observation was okay but had a problem with the last sentence. While he was seeing a patient, I looked again at the diagram and at what I had written and saw that “then an increase in BIC” in the last sentence should have read “then an increase in PC02”. When I changed this the expert was satisfied but was not completely sure as he could not remember what the meaning of conclusion code %RK004 which I later found meant “Resolving respiratory alkalosis”. The expert said that I had a misunderstanding of the relationship between Blood-Bic and Blood_PH. He commented that if you told an expert that Blood_Ph was low they would say the Blood_Bic should be low. The conclusion %MC002 for metabollic compensation resulted in the situation being reversed and unusual so it was misleading me into thinking that this is a common occurrence.
This was useful in identifying and correcting a misconception that I had. I had formed a hypothesis of an inverse causal relationship between Blood_Ph and Blood_Bic but this was generally not so and had only occurred because of an anomalous situation.
Figure 4: The concept lattice in MCRDR/FCA for the conclusion %MC002- “metabolic compensation.2”.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
7
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
2.
The conclusion family %MK was selected. The attributes to consider for these conclusions are BLOOD_PH, BLOOD_BIC and BLOOD_PC02. The two rules for %MK003 use the conditions DECR(BLOOD_PH)=TRUE and MAX(BLOOD_BIC)>=27. If BLOOD_BIC is decreasing then the conclusion %MK003 should be given otherwise the value of BLOOD_PC02 should be considered. The concept “HIGH(BLOOD_PH)=TRUE and NORMAL(BLOOD_PC02)=TRUE” may represent a higher concept that could be labelled as indicative of a particular type of patient condition.
The expert said that HIGH(BLOOD_PH)=TRUE and NORMAL(BLOOD_PC02)=TRUE did represent a higher concept which could be described as there is something wrong that needs further investigation.
3.
The values used by the %RK and %MK conclusion families are similar and indicates that there is a close relationship between these two families
The expert pointed out that the use of K in the classification code meant that the PH was high. Whether the conclusion was R or M depended on a refinement of the initial rule/analysis based on Ph.
It was therefore natural that these two conclusion families were related since they were both based on a High PH. I had not realised such a naming convention. This also takes us back to point1 where it was noted that %RK002 was the only rule that didn’t require BLOOD_PH to be HIGH when all other similar rules did have this A-V pair. However, the coding used by the expert for the conclusion code has implied that this conclusion typically applies when BLOOD_PH is HIGH even though it was not present in the case that prompted the rule to be added. 4.
If BLOOD_PH has been high at any stage then an increase in PC02 and decrease in PH and BIC will give the conclusion %RK004-""Resolving respiratory alkalosis". Yes that seems right. Although I would qualify that if the PH has been HIGH and the PCO2 was LOW at the same time and BIC was not HIGH (at least this would be the usual case) 5.
Selected clause MIN(BLOOD_PO2). Only the rules which conclude %OX006 use this attribute and function. The key to this conclusion is a low BLOOD_PO2 level. The only other attribute that is considered is seen in rule 42 where the condition AGE
