As

FJa

b

Cc

a

A

R

R

2

A

K

K

I

M

1

Pec[asIcf

E

(0d

c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls /cmpb

n incremental knowledge acquisition-based system forupporting decisions in biomedical domains

rancisco Jesús Torralba-Rodrígueza, Vicente Bixquert-Montagudb,esualdo Tomás Fernández-Breisa,∗, Rodrigo Martínez-Béjar c

Departamento de Informática y Sistemas, Universidad de Murcia, CP 30100, SpainServicio de Medicina Intensiva, Hospital Universitario Virgen de la Arrixaca, Carretera Madrid-Cartagena,P 30120, El Palmar, Murcia, SpainDepartamento de Ingeniería de la Información y las Comunicaciones, Universidad de Murcia, CP 30100, Spain

r t i c l e i n f o

rticle history:

eceived 4 October 2008

eceived in revised form

5 July 2009

ccepted 9 November 2009

eywords:

a b s t r a c t

In Intensive Care Units doctors have to manage several alarm situations in patients. When

a doctor analyzes the state of the patient, (s)he has to decide if there is an alarm situation

and make decisions about what actions to perform. It is desirable to detect these situations

before they occur, because the solution could be easier and the doctor has more time to react.

An intelligent system could analyze the information, extract conclusions, format and order

the causes leading to the severe condition. This would be helpful for a doctor, and would

make the decision-making process easier. A system capable of performing such operations

nowledge-based systems

ncremental knowledge acquisition

edical informatics

is presented here. This is not a diagnosis application but a tool to detect alarm situations for

patient safety. A prototype capable of making retrospective evaluation of the condition of

the patients has been developed. This system is based on the MCRDR technology, which has

been extended to deal with the requirements of this domain. The evaluation of the system

is also reported in this paper.

. Introduction

atient safety has become a major issue in the last years, andxperts from different fields such as ergonomics, psychology,omputing and engineering have become involved in this area1]. Alarms are a tool to improve patient safety, because theyre used to monitor patients, inform of events and so on. Con-equently, they are widely used in critical domains such as

ntensive Care Units (ICUs). ICUs receive patients in criticalonditions, and their state requires for considerable attentionrom healthcare-related personnel. To facilitate the surveil-

∗ Corresponding author at: Departamento de Informática y Sistemasspinardo, 30100 Murcia, Spain. Tel.: +34 868884613; fax: +34 868884151

E-mail addresses: fjtr2@alu.um.es (F.J. Torralba-Rodríguez), vicente.bJ.T. Fernández-Breis), rodrigo@um.es (R. Martínez-Béjar).169-2607/$ – see front matter © 2009 Elsevier Ireland Ltd. All rights resoi:10.1016/j.cmpb.2009.11.006

© 2009 Elsevier Ireland Ltd. All rights reserved.

lance task, patients are equipped with monitoring systemswhich record physiological parameters and detect deviationspreviously defined. The number and frequency of recordedvariables is constantly increasing due to the technologicaladvances, and this continuous data flow often overwhelmsthe clinical personnel [2]. Doctors have to analyze the clini-cal condition of the patients and to detect alterations in theirphysiologic normal values. When such situations are detected,

, Universidad de Murcia, Facultad de Informatica, Campus de.ixquert@carm.es (V. Bixquert-Montagud), jfernand@um.es

alarm must be activated. Moreover, it would be useful to pre-dict such situations. So, a doctor has to observe many signalsper patient each day, and to control many patients. Conse-quently, human factors could cause errors in this task. To

erved.

s i n

162 c o m p u t e r m e t h o d s a n d p r o g r a m

facilitate their labor, we propose in this paper a system toassist doctors to analyze the condition of the patients, detect-ing which patients are in a real alarm situation.

Conventional patient monitoring systems receive phys-iological signals and process them to extract reliableinformation. In critical domains, an alarm is usually defined byestablishing some limits over different parameters. So, whena parameter value exceeds its limit, an alarm is triggered, indi-cating an abnormal condition.

For many years, commercial patient monitoring systemshave had some important problems to overcome, such as thelow specificity of the alarms and the triggering of superflu-ous ones. Each alarm only warned about abnormal values ofa certain condition. As is stated in [3], 94% of the detectedalarms in a pediatric ICU were not relevant. In this context, wedeveloped a system for detecting false alarms called OBIAC [4],which was an ontology-based system for managing intelligentalarms, capable of deciding whether patients met a diagnos-tic hypothesis and of detecting superfluous and false alarms.This system was developed for ICUs, where time response iscritical and was a joint effort between our research group andthe ICU at the Virgen de la Arrixaca Hospital in Spain. Thishospital is a complex organization with 900 beds and it hasbeen appointed as a logistic reference for another 10 hospitalsof its geographical area. This ICU has 32 beds and hosts around1400 patients a year, therefore doctors have to manage a lotof parameter values per patient every day. To manage thesevalues, the referred hospital makes use of the CareVue Sys-tem, which was put in routine use 10 years ago. However, theICU doctors asked us to develop a system which could filterout patients’ information to predict and detect alarm situa-tions in a more reliable manner than it is done currently. Itshould be pointed out that this problem is not exclusive tomedical domains but it occurs in any control-related one (seefor instance [5]).

Commercial systems have improved in the last years thedetection of false alarms, and these systems are able to pro-duce more significant outputs (smart alarms). However, thesemonitoring systems do still have some shortcomings. First,recent studies [6,7] have concluded that false alarm rates rep-resent about 75% of alarms, and they indicate patient alarmconditions only 3% of the time. As a result, doctors may ignoresome important alarms, thinking that they are false. Second,if a threshold is established a long way from the dangeroussituation, a lot of false alarms could be activated, and this isdangerous because medical staff might ignore a real alarm.However, an alarm system capable of detecting false alarmswould not be useful if that information is not delivered tothe medical doctors in the appropriate time. Third, they areusually capable of advancing abnormal conditions. This wouldallow doctors to take preventive actions. To this end, systemshave to analyze the evolution of the parameters. Fourth, whena patient is evaluated, some alarms might not be activateddue to the existence of missing values (conditions over themwould be evaluated as false). In addition to this, experts con-sidered interesting to be advised of such situations. Finally,

they do not usually facilitate Knowledge Management activi-ties, which have been considered important in the last decadedue to the characteristics of healthcare environments and theKM properties [8,9].

b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

Another important issue is that these systems usuallyrequire experts to do a previous analysis. Hence, ICU expertsusually determine the patient condition based on monitor-ing, clinical analysis and patient observation. The informationobtained from the analyses is used to decide whether it is asituation of alarm and if a reaction is needed. Given thesefacts, an intelligent system seems to be capable of support-ing the expert to make a decision. In fact, intelligent alarmsystems are attracting the interest of clinicians as stated in[10], because those systems allow for the reduction of the falsealarm rate. An example can be found in [11], where a CBRapproach that might be used to reduce false alarm rates ispresented.

In practical settings, an intelligent alarm management sys-tem should be capable of evaluating a particular state byusing the values of the relevant parameters, for which case allthe necessary parameters values must be known beforehand.Thus, the system should be flexible enough when interpret-ing conclusions, because a conclusion can occasionally bereached if a particular condition is defined over a non-relevantparameter. In this case, the system should indicate that theconclusion might be more concrete (or, in some cases, dif-ferent) if the value of a non-considered parameter changes.Should that happen, the system would suggest the expert toconsider such a parameter to check whether the conclusionchanges. Our main goal has been to design an alarm sys-tem capable of detecting truly physiologic changes situationsfor ICU patients (tripping intelligent alarms), which takes allthese considerations into account. This system was not con-ceived to be a diagnostic application but to warn doctors aboutpotential physiologic changes situations which could require apreventive action. The system will showing to the doctors theinformation about patients in a more descriptive way, show-ing the altered signals and their relations with other signals,that is, filtering the useful information. On the other hand,the system will be able to identify patients that could be inalarm situation to allow doctors to take actions, that might bepreventive or active. It has to be considered a support for thedoctors, who will make the final decisions and define the rulesto be applied by the system.

The technology used to develop such a system should meetthe following requirements: support experts, and be exploitedand maintained by experts, that is, without the participationof computing experts. Ripple Down Rules (RDR) [12] and theirevolution, Multiple Classification Ripple Down Rules (MCRDR)[13] meet these requirements. In particular, MCRDR has beenused to develop our system. RDR has proven its efficiency andperformance in (real) practical problems. It was initially vali-dated by the development of PEIRS [14], a large medical expertsystem for the interpretation of chemical pathology reports.Other studies have been published in different environmentssince then, like control applications, as in [15], heuristic search[16], document management [17] or image processing [18]. Allof these studies prove that it is an efficient and effective knowl-edge acquisition methodology [19].

MCRDR is an evolution of RDR in which more than one inde-

pendent classification can be correct at a time. The applicationof MCRDR to define alarm situations may provide a globalvision of the system, because it allows to associate differentparameters. Thus, alarms might be defined by including con-

c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171 163

dgwodepts

isdhMlS

2R

Racltc

Csbwcirtbcseb

bsariRk

Fig. 1 – SCRDR binary tree for living beings.

itions over several parameters. In this way, the expert mayet a quick view of the system. However, some extensionsere needed to incorporate MCRDR into our solution, since theriginal MCRDR technology does not provide mechanisms forefining rules that: (1) compare the values of the same param-ters at different time points; (2) compare the value of twoarameters through a certain function; (3) compare parame-ers with more than one value; and (4) provide a time-basedorting of the input case conditions.

The structure of this paper is as follows. Some technolog-cal background about MCRDR is provided in Section 2. Thisection includes the limitations of MCRDR for the appropriateefinition of alarms in critical domains. Section 3 describesow these limitations have been overcome by extendingCRDR. The system is described in Section 4. The lessons

earned and the future plans are discussed, respectively, inections 5 and 6.

. Multiple Classification Ripple Downules

ipple Down Rules (RDR) are both an incremental knowledgecquisition technique and a knowledge-based system (KBS)onstruction methodology. It is based on a user-centred phi-osophy, in which experts provide knowledge by justifyingheir conclusions. That is, they explain why their opinions areorrect.

There are two main approaches when using RDR: Singlelassification Ripple Down Rules (SCRDR), and Multiple Clas-ification Ripple Down Rules (MCRDR). SCRDR is based on ainary tree whose nodes are constituted by if, if-not rules,hich are rules with two branches: one is activated if the

ondition is true and the other is activated if the conditions false. The input case is checked against the contents of theoot node in the tree. If the case holds for the node condition,his is stored and the algorithm continues by exploring the ifranch. Otherwise, the if-not branch is explored. This processontinues until there is no rule to evaluate left. The conclu-ion is then the one associated to the last rule fired. If thexpert detects a mistake, this can be corrected by adding newranches. Fig. 1 depicts a typical structure of a SCRDR tree.

However, one conclusion is not enough in some domains,ut multiple ones are needed. For example, in an ICU alarmystem several alarms could be activated simultaneously andll of them have to be known by the expert in order to make the

ight clinical decisions. This can be managed by the variantntroduced in [13], namely Multiple Classification Ripple Downules (MCRDR). MCRDR allows multiple conclusions from anowledge base to be obtained, while keeping the advantages

Fig. 2 – Part of an MCRDR tree.

and strategy of RDR. In MCRDR, an n-ary tree is used; i.e., a rulemay have multiple refinement rules. A conclusion is providedby the last rule satisfied in a pathway. All the children of asatisfied parent rule are evaluated, thus allowing for multipleconclusions. The conclusion from the parent rule is only givenif none of the children are satisfied. Fig. 2 represents a part ofthe MCRDR tree that has been built by using our system in anIntensive Care Unit (ICU).

Let us suppose that when pH is low (i.e., <7.36), a rule isactivated and potential acidosis is the conclusion. Hence, ifthe expert sees that pCO2 is high, the rule might be mademore specific by adding a new child to the last conclusion.This would evaluate pCO2 and, if pCO2 is high (i.e., >46), itwould alert the danger of respiratory acidosis. So, when anotherpatient with similar conditions is analyzed, the alert of poten-tial respiratory acidosis would be activated.

The experts can correct the system, which learns suchchanges. However, the correction of the rule base has somelimitations. For example, all the doctors of the ICU of a hos-pital must use the same protocol, and a group of doctors willmanage the rule base. So, in collaborative environments, therule base must be defined by consensus.

MCRDR can be used to develop systems in which the sta-tus could be analyzed by triggering some alarms when someparameters reach a defined limit. An alarm might be definedby taking into account a set of parameters, which may beeither a signal (i.e., pH, glucose, etc.) or a calculated value(i.e., the average over the last 3 h or the maximum over thelast 24 h of a signal). However, the doctors perceived thatMCRDR had some limitations for their clinical objectives. First,MCRDR cannot work with conditions in which a parameteris compared to its previous value, which could provide infor-mation about trends, and this could be helpful for predictingdangerous situations (i.e., if the pH is high but the currentvalue is lower than previous measurements, the doctor couldreconsider the action to take). On the other hand, the expertssuggested that the evaluation of a parameter could dependon other parameter values, so they had to be compared. Forthis purpose, some concepts have to be implemented in the

methodology. This would allow the definition of potentialalarm situations in many different ways. An example follows(where v is the value of A):

s i n

164 c o m p u t e r m e t h o d s a n d p r o g r a m

• v > x where x is the limit for A (i.e., glucose > 150): “A alter-ation”.

• A grows up k %—it means that it goes up more quickly thanexpected (i.e., glucose increases 10%): “A alteration”.

• v > c ∗ z where z is the value of B and c is the comparisoncoefficient (i.e., diuresis/hour > 2.5 kg): “A alteration”.

In this example, the three rules may have the conclusion “Aalteration” associated, and therefore three different alarmscould be triggered to warn about the same conclusion (maybeproviding slightly different details). From the clinician’s per-spective, this can be confusing and even stressful, and thisproblem is caused by the limitations of MCRDR in terms ofoutput visualization when new types of conditions are added.Consequently, how the information of a conclusion is sent tothe medical doctor is an important issue for this work, andone that had to be analyzed.

New condition types would allow experts to define a newrule in different ways. On the other hand, users would preferto introduce all conditions by (only) one rule. To do that, “OR”conditions are needed. One way to allow to experts to createrules with “OR” conditions and transform them into rules withonly “AND” conditions has therefore to be investigated.

On the other hand, an MCRDR conclusion is defined bya text which defines the abnormal situation. But sometimesthis is not enough because some different situations could bedefined by the same conclusion. Thus, conclusions triggeredat the same time might be shown as the same conclusion butaccounting for their respective details, so making the analysiseasier. Finally, including advices in the conclusions is usefulfor experts, because they can recommend the actions to take.For instance, if pH and K (potassium) are high, the advice mightbe Acidosis. Monitor K; this means that the patient has Acidosisand the amount of potassium should be monitored.

3. Design of the solution

In this section, a series of extensions to MCRDR are describedin order to meet our research objectives. These extensionsallow MCRDR systems to overcome the limitations describedin Section 2.

3.1. MCRDR extensions

The extensions described in this section have been the basisfor developing the knowledge-based system presented in thispaper. These extensions include new types of conditions, newpossibilities for analyzing the results of the reasoning processand the output, and the definition of new types of condi-tions proposed by doctors, so allowing systems to detect moremeaningful alarms.

3.1.1. New types of conditionsFirst of all, doctors suggested us the possibility of defining acondition between the current and the previous values of a

parameter. To this end, MCRDR must be modified in order toallow more than one value for the same parameter, so thatthe values can be chronologically ordered. In this work, vari-ations in conditions can be included in two ways: (1) absolute

b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

variations: the new value is x units higher/lower; and (2) rela-tive variations: the new value is x % higher/lower. This kind ofrule allows experts to evaluate the parameters evolution too.So, experts could know when a situation is evolving towardsabnormality, and preventive actions might then be taken.

On the other hand, comparisons between different param-eters are needed. Sometimes, knowing whether a parametervalue belongs to its expected range requires a comparison withanother parameter (i.e., the diuresis of a patient is sometimescompared to the weight). The definition of such comparisonrequires a coefficient, because two values of different param-eters are usually not directly comparable (in the example,diuresis is measured in ml/h and weight in kg).

3.1.2. Results analysisFor a rule-based system, the simplest way to show the reasonswhy a conclusion is fired is to show the conditions of the firedrule. However, this is not enough when the most importantinformation is the system status, and whose value indicatesthe action(s) to take. Another important issue for an expertis the last value of a given parameter, because it defines thecurrent trend, which may affect the decision to make.

In our approach, the information received by the expert iscondition type-dependent, as described next:

1. Conditions involving a limit value: Both the current andthe previous values constitute the important informationfor the expert, whereas the limit is not usually relevant. Forinstance, when a condition such as A < x is activated (i.e.,pH < 7.36), the expert has to receive information like:

A has a low value. It has descended from y to z, where x isthe limit for A, z is its current value and y is its previousvalue.e.g.: pH has a low value. It has decreased from 7.38 to7.34.

2. Conditions involving a dramatic change of a parametervalue: The current and previous values are the most impor-tant items, although in this case the limit for the changecould be interesting, because it could be unknown or nontrivial. For instance, when a condition like A > x % is acti-vated (i.e., pCO2 increases more than 20%), the expert hasto receive information like:

A has increased quickly from y to z (x%).e.g.: pCO2 has increased quickly from 33 to 40 (20%).

3. Conditions including a comparison between parameters: Inthis case, the current value, the previous one, the parame-ter and the coefficient are shown because the expert needsto know what relation has changed. Moreover, both the pre-vious and the current values for the compared parametersare also shown, because they might be the altered value.For instance, when a condition like A > c*B is activated (i.e.,diuresis/hour > 2.5*weight), the expert has to receive infor-mation like this:

A has changed from y to z > c*B(y′)

where B is the compared parameter, c is the coefficient and y′

is the previous value for B.

e.g.: Diuresis/hour has changed from 190 to 210 > 2.5*kg (80).

c o m p u t e r m e t h o d s a n d p r o g r a m s i n b

3Ticdn

3ItsmwTtma

vspbcpf

Fig. 3 – Detailed conclusion for modified ICP.

.1.3. OR conditionshe new condition types allow experts to define a new rule

n several ways: with a limit, with a % change, an absolutehange, comparing it to another parameter. Users prefer toefine the conditions using one rule, so OR conditions areeeded. For instance, the following four rules:

R1: {A ∧ B → C, A′ ∧ B′ → C, A ∧ B′ → C, A′ ∧ B → C}Example: The problems of cerebral perfusion pressure (CPP)may be caused by alterations in the average arterial pres-sure (AAP), although there might be other causes. The controlof both signals is performed by using limit in absolute andrelative terms, using for this purpose OR conditions. In thisexample, C stands for the conclusion “problems of cerebralperfusion pressure”).R1: {CPP < 70 ∧ AAP < 90 → C, CPP decreases 10% ∧ APPdecreases 10% → C, CPP < 70 ∧ APP decreases 10% → C,decreases 10% ∧ AAP < 90 → C}This rule might be defined by the following rule with OR con-ditions, given that MCRDR systems work better with ruleswith only AND conditions, like in R1. To do so, the systemmust be capable of transforming OR conditions into ANDones:R2: (A ∨ A′) ∧ (B ∨ B′) → Ce.g.: R2: (CPP < 70 ∨ CPP decreases 10%) ∧ (AAP < 90 ∨ APPdecreases 10%) → C

.1.4. Definition and visualization of conclusionsn MCRDR, a series of conditions activates a case. In general,his case contains a textual description of the informationhown to the expert as the conclusion. In complex environ-ents, it may be interesting to group different conclusionsith the aim of defining one conclusion with different details.his is useful because, if some of these conclusions are simul-

aneously reached, they can be shown to the user in a groupedanner. Thus, the system would be more informative becauseglobal analysis can be performed more easily.

Let us suppose a medical environment in which a highalue of the intracraneal pressure (ICP) can be due to two rea-ons: (1) increase of temperature (T) and (2) increase of CO2

ressure (CO2 P). Let us also suppose that the knowledge-

ased system (KBS) has the rules shown in Fig. 3. In thease that a patient has suffered an ICP alteration with valuesCO2 > 44, T > 38, the system would show the three possibilitiesor ICP.

Fig. 4 – Detailed conclu

i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171 165

Sometimes it may be important to advise the expert ina particular situation. This situation is similar to the previ-ous one, except for the fact that the main conclusion is notachieved by the condition values but it identifies a situationto be controlled. Let us consider the case of an acidosis (pH ishigh). In this case, we might want to indicate that the level ofpotassium (K) has to be monitored if it exceeds some value.Note that we are not stating that the acidosis is provoked bythe increase of potassium, but it is a factor to control. Fig. 4shows the representation of a potential acidosis (respiratoryacidosis), and the advice to control the K value.

Hence, in this approach a conclusion is structured as fol-lows: <conclusion; detail; advice>. There are situations inwhich some conclusions are fired by the same conditions (orconditions that have the same or less information). These con-clusions might be defined in different branches at the decisionMCRDR tree. So, there are different conclusions with simi-lar reasons. Normally, when an expert sees a conclusion, anaction is taken, trying to deactivate the conclusion. In thosecases, only one of those conclusions, the most relevant, shouldbe triggered. For this purpose, minor rules are defined. Giventwo rules A and B, A is said to be a minor rule of B if the con-ditions of A are contained in the set of conditions of B. In thiscase, it is also said that A is less significant than B.

Finally, the conclusion has to be ordered for visualization.In our approach, the rules having one or more conditions overthe same parameter are shown in a grouped way. This is veryuseful for analyzing the causes of a situation and taking theright action. The rule shown at the top of the group is the mostrelevant. A rule is said to be the most relevant if its condition setis the one with most different parameters. This conclusion willbe followed by all the rules having at least one common param-eter with it. These related conditions will be identified by thesymbol “*”. This process is recursively executed to obtain thefinal structure.

Given the set of conclusions {Acidosis-respiratory, ModifiedpCO2, Modified diuresis/hour} with the following descriptions:

• Acidosis-respiratory: pH < 7.36 ∧ pCO2 > 46• Modified pCO2: pCO2 grows by more than 20%• Modified diuresis/hour: diuresis/hour decreases more than

30%

Acidosis-respiratory is the most relevant (note that the prin-cipal conclusion is acidosis and respiratory is the conclusiondetail, which is shown when the principal conclusion isexplained, not here), and Modified pCO2 is related to it becauseit provides information about pCO2 evolution and Modifieddiuresis/hour has no relation to their parameters. This set of

conclusions would be visualized as follows:

Acidosis*Modified pCO2

Modified diuresis/hour

sion for acidosis.

s i n b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

166 c o m p u t e r m e t h o d s a n d p r o g r a m

3.2. Technological description of the solution

Traditionally, a series of reasons for the failure of expert sys-tems in biomedical domains have been identified [20]: (1) pooruser interface; (2) systems are considered a menace by doctors;(3) the systems are too theoretical; and (4) lack of integrationwith existing information systems. The first objective of thesystem presented here was to take these issues into accountto increase the chances of success.

The MCRDR system has to be capable of showing the reasonfor the triggering of an alarm to the expert, so that (s)he maydirectly see the causes of the problem, so having a chance ofremoving redundant information and so on. Hence, the tech-nological solution has to guide the expert in order to find thecauses of the problem. The following decisions were maderegarding the design of the system:

• Each group of final conclusions, independently of the cir-cumstances under which these were reached, is shown tothe expert.

• The conditions of each final conclusion are summarized inthe explanation. The conditions that have led to the conclu-sions are shown in the common part, and those conditionsthat are included in other ones are removed.

• Minor conclusions are removed.• The explanation of each condition includes both the current

and the previous values of the parameters involved in therule activation.

So, our most ambitious objective was to make the outputeasily understandable for humans. The experts do not needa system which gives them some conclusions extracted froma decision tree, but a system capable of removing redundantinformation and ordering the conclusions. Each conclusionmust be explained, because they need to see the causes of agiven situation so that the information analysis can be easierfor them.

4. Prototype description

A software prototype has been developed to support doc-tors when they evaluate patient-related alarms in ICUs. It hasbeen developed under the guidance of the professionals at the“Virgen de la Arrixaca” Hospital, which has one of the mostadvanced ICUs in Spain, and as it has been aforementioned,it is the logistic reference for other ten hospitals in the Regionof Murcia.

The groups of doctors designed collaboratively the rules tobe used in the system, and one doctor acted as manager ofthe rule base. This doctor was in charge of making the deci-sion in case of conflicts, introducing the rules in the systemand making corrections when needed. The input of the systemrepresents the patient status and it is defined by the valuesof the parameters which are being checked for the patient.The system evaluates such a condition and outputs a set of

conclusions, which are accessed by the doctors. These canmodify/correct conclusions if they think these are wrong sothat the modified conclusions are learnt by the system in orderto take them into consideration for further sessions.

Fig. 5 – Adding/modifying rules.

There are two main entities in this prototype, patients andrules, so the system must provide mechanisms for their man-agement. Patients are the target of the evaluation, whereasrules are the elements used to describe the knowledge basethat will be used for evaluating the patients’ conditions. Thefacilities offered by the system for managing patients andrules are described next.

4.1. Rules management

After logging into the application, the doctor has to selectwhich rule base will be used, since the system is capable ofmanaging different sets of rules. Moreover, the expert canchange the rule base at any time by selecting the Change Rulesbutton on the main screen. This is required because a rule setcould be useful for some kinds of patients but not for others.The aim is to allow groups of doctors to classify rules by type ofpatient. For instance, doctors find it interesting to separate therules for neurological and for cardiac patients because someconditions of blood pressure could present a danger for car-diac patients but could be relatively normal for neurologicalones. In the evaluation of the tool only one set of rules hasbeen used.

The selection of the rules is important, because it will deter-mine the reasoning process followed by the system. As alreadymentioned, the group of doctors may decide to modify therules, so the reasoning process of the system would automat-ically be adapted to their new considerations. In particular,the doctors can perform the following rule-related opera-tions: adding/modifying a conclusion, adding a multiple rule(including OR conditions), and renaming a conclusion. Theseoperations have to be executed by the rule manager once thedoctors have agreed to make such changes.

4.1.1. Creating/modifying rulesThere are two options for defining a new rule. Fig. 5 illustrateshow this operation can be done. The doctor must define theconclusion (description, details and advice), and then (s)hemust establish the conditions for the conclusion activation.The definition of such conditions is based on patient events.

The addition of a condition requires the doctor to followthese steps:

Select the type of condition and click Edit button (Fig. 5). The

system is capable of managing different types of conditions:• Normal: These conditions define the limit of the parame-

ter. The normal condition CI = 2.5 stands for CI has the value2.5.

c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171 167

4Atttst

•

•

Tlabf

or add a new event to the current patient (‘New Event’ button).The selection of this last action would display the event editorscreen, which is shown in Fig. 9. This would allow to define ormodify the value of one of the events registered in the system.

Fig. 8 – Create/modify patient page.

Fig. 6 – Definition of an incremental base condition.

• Evolutive: These conditions define relative evolutive con-ditions. The condition CI growths >2.5% stands for the %increase of the value of CI is higher than 2.5.

• Evolutive base: Similar to Evolutive, but defining a limitvalue. The condition CI grows >2.5% with limit 10 stands forthe % increase of the CI value is higher than 2.5, and its valuecannot be higher than 10.

• Incremental: These conditions define absolute evolutiveconditions. The condition CI growths >2.5 stands for theincrease of the CI value is higher than 2.5.

• Incremental base: Similar to Incremental, but defining alimit value. The condition CI growths >2.5 with limit 10stands for the increase of the CI value is higher than 2.5, andthe value cannot be higher than 10.

Note: CI represents the Cardiac Index parameter.

The conditions editor (Fig. 6) is then displayed and this isused to define any type of condition.Define the values of the condition, which depend on the typeof condition.Click on Modify. This would return to the screen shown inFig. 5.Go to step 1 if any other condition must be added.Click on the OK button when all the conditions have beenadded to the rule.

.1.2. Creating multiple rulesmultiple rule is a rule defined by OR conditions. Each mul-

iple rule can be transformed into a set of rules containing allhe options defined by OR conditions. To define a multiple rule,he Add Multiple Rule button must be clicked on the conclusionscreen. The Multiple Rule editor is then displayed. It is similaro the one shown in Fig. 6, but it has two new buttons:

New level: It allows a new set of OR conditions to be created.This is a set of conditions which activates the conclusion ifone condition holds.Accumulate condition: The selected condition(s) is/are addedto the active level as an OR condition for the current set.

he expert can see the sets of conditions created. For eachevel, a conclusion must be introduced, and will be added as

rule (as a child of each rule of the previous level). There wille a rule for each OR condition and for each parent rule (i.e.,or each rule of the previous level).

Fig. 7 – Example of new rule.

4.2. Patients management

The main window of the application shows the list of patients.Once a patient is selected, the corresponding data are shownon the right-hand side. These data contain values of patientgeneral properties including age or entrance date and the com-plete series of values for the different relevant physiologicalsignals. The doctor can then take the following actions relatedto patients: creating patient, launch the evaluation process,update patient data, and add a new event to the patient. Letus now describe each of these operations.

Fig. 7.

4.2.1. Creating and modifying patientsIf the options for creating or updating a patient are selected,the patient editor page is shown (see Fig. 8). In this page, all thepatient general data can be modified. Some important data areshown to help doctors to make decisions (i.e., some allergieswill restrict the applicable treatments).

From this page, the user can add/update the patient infor-mation (‘Add’ button), create another patient (‘Other’ button)

Fig. 9 – Create/modify patient events page.

s i n

168 c o m p u t e r m e t h o d s a n d p r o g r a m

In Fig. 9, the value of pO2 is defined. The value can be either anumber or a literal. The corresponding buttons have the samemeaning as in the rest of buttons, since the application hasbeen designed by applying usability criteria.

4.2.2. Evaluating patientsThe condition of an existing patient can be checked by thedoctor by selecting the appropriate menu option. Then, theextended MCRDR methodology introduced in this work isapplied, and a set of conclusions is shown to the doctor. Thestructure of the output (see Fig. 10) is described next:

Conclusions: The different groups of conclusions reached bythe system are ordered by affinity. An ‘*’ is added to thoseconclusions which have a parameter in common with theprevious one. For instance, “if (1) conclusion 1 is related to con-clusions 2–4; (2) conclusion 3 is related to conclusion 2; and (3)conclusion 5 is not related to any other conclusion” the outputwould have the following structure:

Reasons: If we select a conclusion, then the reasons for itsactivation are shown in this area. This system is a really impor-tant facility for the expert, because it offers an explanation ofthe situation problem in terms of events. The reasons can beexplored in different ways: Human (Intelligent) Style and Clas-sic (Machine) Style. Fig. 10 corresponds to the first one, whereasthe second one would display the tree of rules that have beenfired.

Reviews: Some parameters are eventually not consideredin the evaluation of some patients because they are not being

measured for those patients. Hence, some rules arenot activated because of these missing values. However,the doctors should be warned of these missing values,because the conclusion could be more precise if they wereknown.

4.3. Implementation

This prototype is a web application, whose development hasbeen based on the J2EE framework, which allows softwareapplications to be developed and maintained in a simple, flex-ible and efficient way. The user interface was designed in

b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

collaboration with the medical team of the ICU of the abovementioned hospital. It was modified several times to adaptit to the real needs of the doctors involved. The interface hasbeen tested by using Internet Explorer and Mozilla Firefox. Notonly was the user interface agreed with the medical team, butalso was the functionality incorporated into the system. Thedevelopment of this prototype was monitored by them and theprototype was regularly tested by the final users. This allowedus to measure the effectiveness of the system and to includenew functionality demanded by the doctors.

The system makes use of XML to represent the rules, sofacilitating the exchange of rule bases among different sys-tems. Each rule base is thus stored in an XML file. An XMLSchema has been used to represent rules. An example of ourXML rules is shown next:

In XML, entities and attributes are identified. A RULE nodehas three attributes, namely, conclusion, advice and details.In this case, the conclusion of this rule is Acidosis, the advicefor the doctor is Observe K, and no details have been defined.Each rule is associated to a number of CONDITION enti-ties. Each CONDITION has a series of common attributes:the event (e.g., POT), the operator applied (e.g., greater than)and the type of condition (e.g., normal). Depending on thetype of condition, extra attributes such as value (e.g., 5.0) aredefined.

XML has also been used to represent the types of condi-tions. The conditions xml file is the key to manage a dynamicset of condition types. This file contains the definitions of theconditions types used in the application. Each type is definedby referencing the classes which implement its functionalityand user interface, and their subsumed condition. An entry tothis file is shown next:

<CONDITIONTYPES> defines the types of conditions. Each<TYPE> defines a condition type, where name stands for theunique identifier for the type, class for the Java class that imple-ments its functionality, and editor for its user interface Javaclass. For each <TYPE>, <SUB> tags might be defined. Thesetags allow the simplification of the analysis of the systemoutput, because the attribute name stands for the subsumedtype of condition. With this structure, the implemented sys-

tem is not only extensible, but configurable too, because ifan expert thinks that one condition type is more impor-tant than another, (s)he could change the definition in thisfile.

c o m p u t e r m e t h o d s a n d p r o g r a m s i n b

5

Ithh

•

•

•

•

Fig. 10 – Checking page.

. Lessons learned

n Section 3, some well-known problems related to expert sys-ems in medical domains were presented. How these issuesave been considered in the system development presentedere is explained now:

The user interface is poor: The system interface for med-ical doctors allows a patient to be selected and her/hisconditions to be checked, so it guides the doctor to doher/his tasks without (offering) distracting elements. More-over, doctors are given the possibility of correcting thesystem when wrong (system) conclusions are identified bythem.The system is perceived by doctors as a menace not a sup-port: A significant effort has been made to clarify the role ofthe system to the medical doctors. It is a support for theirmedical activity, so that medical doctors can save time andhave a lot of relevant information, which they need aboutthe patients’ evolution easily and quickly available in thissystem. The system provides them with conclusions andexplanations also.The approach is theoretical: Both the design of the method-ology and the system have been carried out from a practicalperspective. Final users have actively participated in thedesign of the system functionality and interfaces. One ofthe doctors reviewed them twice a month, and played therole of rule manager. He discussed the possible modifica-tions and improvements with two colleagues, although incase of disagreements, the most supported option was cho-sen, and the manager had the quality vote. All the threedoctors are currently part of the team responsible for thesystem maintenance.Lack of integration with existing information systems. Amodule capable of capturing data to build the system inputcases is needed for our system to work. The nature andcharacteristics of this module depend on the informationsystem features available at the medical unit, so this has not

been considered here, but it will be taken into account forfurther work. In our system, the patients’ data were man-ually input into the system by doctors, which takes themsome time, but they agreed to do this given their interest

i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171 169

in the potential of this research result. The development ofan integration module has not been possible to date due tothe legal need for a commercial agreement with the com-pany that manages the Health Information System at theHospital.

By proceeding in this way, we ensure an initial acceptance ofthe system among the final users, which is important, since itconstitutes the essential matching between the expectationsand ambitions of the system’s final users and developers.

The system prototype has been installed in the ICU at thehospital in question and it has been tested using data fromreal patients and a rule base created by participant medi-cal doctors. Patient test cases were generated by the doctorsusing retrospective and present information of 43 real criticalneurological patients belonging to that ICU. Fourteen signalswere used in this validation: intracraneal pressure (ICP), arte-rial average pressure (AAP), cerebral perfusion pressure (CPP),CO2 pressure (CO2 P), O2 pressure (O2 P), glucose, sodium (Na),temperature, lactate, CO3H, pH, potassium (K), systolic arterialpressure (SAP) and diuresis. CO2 P and O2 P have been mea-sured in blood. For the generation of each test case, the doctorsonly considered those values corresponding to the previouslyselected signals. The 14 signals were not considered for all thepatients. The doctors decided which signals had to be con-trolled for each patient. The rules have been designed by usingout of danger limits for the patients and by controlling theevolution of the parameters.

After the generation of the test cases, the doctors inputthem into the system in order to obtain the corresponding con-clusions. The knowledge base was initially empty, so it wasincrementally constructed by following the MCRDR philoso-phy. To do that, the doctor used test (irreal) patients, describingideal situations and defining the rules to apply. One of thefundamental parameters for evaluating the usefulness of thesystem is its correctness. In this work, correctness is measuredby evaluating the conclusions suggested by the system. Anoutput of the system (a conclusion) has two components fromthe clinical perspective: (1) the patient is in a potential alarmsituation; and (2) the alarm is something concrete. The systemwill provide a correct answer if both components are right. Themedical doctors were in charge of evaluating the correctnessof the system. For this purpose, a knowledge base of 115 ruleswas created and so were 43 cases of patients. No errors weredetected in the activation of the rules in these 43 cases, so thissupporting the correctness of the system. The definition of theknowledge base and the testing process has taken about oneyear of work and meetings between the system administratordoctor and the developing team.

On the other hand, it has to be taken into account that thereare many accurate knowledge-based systems that are not con-sidered useful by the final users and consequently, they neveruse them. The usability and usefulness of the system was eval-uated by the doctors. The evaluation process was performedby 23 doctors of the referred ICU. None of them were part ofthe team that participated in the design and testing cycles of

the system during its development. The participants have dif-ferent expertise, ranging from recently graduated doctors tovery experienced ones. A questionnaire was designed to eval-uate five features of the system. The participants were asked

170 c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171

Table 1 – The results of the questionnaire.

Aspects to evaluate 5 4 3 2 1 Average

The system is easy to use 7 13 3 0 0 4.17

aluat

r

The system is helpful for my workThe system is preciseThe response time of the system is good in comparison to manual evThe integration of this system with the current system is beneficial

to give one of the following values to each feature: (5) verygood, (4) good, (3) average, (2) bad, and (1) very bad.

The results of the questionnaire are shown in Table 1. As itcan be seen in this table, the system can be said to be easy orvery easy (average 4.17) to operate. The usefulness of the sys-tem was not so strongly supported (average 3.13). We considerthis result normal because the users (i.e., the doctors who par-ticipated in the evaluation process) did not use the system fora long time. Nevertheless, we believe it is positive that only13% of the opinions were negative. The accuracy of the sys-tem was positively valued by all the doctors (average 3.65).The same trend can be found for response times and the ben-efits of integrating this system with that of the hospital. Forthese three questions, the average values were, respectively,3.65, 3.82 and 3.91.

6. Future work

Our ultimate research objective was to contribute to the devel-opment of knowledge-based systems capable of supportingbiomedical experts in their daily activity. They have to observea lot of signals per patient and a lot of patients per day, andhuman errors may occur. We wanted to offer them a tool capa-ble of detecting potential alarm situations and give them themost important information for solving those situations. Thesystem presented in this paper can be seen as a step forwardtowards this objective. In relation to this, several (types of) rel-evant research activities are envisioned by working in differentdimensions, as described next.

First, new types of rules may be researched and included inthe methodology. In this sense, the inclusion of trends is themost relevant, since it would allow for comparisons with notjust the previous value. Another interesting issue is the def-inition of formulae including other values. This has a doubleinterest. On the one hand, calculated parameters are normalin biomedical domains. For instance, the arterial pressure iscalculated by using the systolic and diastolic pressures. Onthe other hand, this might also be useful for comparing two(biomedical) parameters. For instance, if we have the param-eters A, B and C, conditions such as A > 10*B + C might bedefined. The inclusion of fuzzy values in the conditions wouldalso be interesting, since it would allow, for instance, the man-agement of different alarm levels, depending on the fuzzyvalue of the activation conditions.

Further research on MCRDR is also in our plans. In order toconvert MCRDR into a technology suitable for systems whereactivation values change, the modification of the knowledge

base should not increase its complexity unless strictly neces-sary. In this sense, the following operations will be researched:rule removal, creation of rules in non-leaf nodes, or dynamicvalues for limits. Finally, another interesting future objective

0 7 13 2 1 3.131 13 9 0 0 3.65

ion 2 15 6 0 0 3.822 17 4 0 0 3.91

is to provide a fuzzy comparison between a current case andthe corresponding cornerstone case in the MCRDR system,because direct comparisons do not always have the same use-fulness when dealing with numeric values. A difference of twounits might be very significant for one particular parameter(attribute) value, but not for another, depending on the rangeof possible values.

Finally, we aim to combine this system with other ICU-relevant KBSs. Thus, the system could be integrated with thatpresented in [4] to ensure the consistency of the clinical data.Another research activity has to do with standards for rep-resenting biomedical information. We are investigating thepossibility of using the ISO13606 for representing electronichealthcare records. This would allow us to benefit from clinicalknowledge and information management technologies suchas those presented in [21,22].

Conflict of interest

The authors declare no conflict of interest.

Acknowledgements

This work has been possible thanks to the Spanish Ministry forScience and Education through the projects TIN2006-14780,TSI2007-66575-C02-02 and BIO-TEC 06/01-2005.

e f e r e n c e s

[1] J. Edworthy, E. Hellier, Fewer but better auditory alarms willimprove patient safety, Quality and Safety in Health Care 14(2005) 212–215.

[2] S. Charbonnier, On line extraction of temporal episodesfrom ICU high-frequency data: a visual support for signalinterpretation, Computer Methods and Programs inBiomedicine 78 (2005) 115–132.

[3] S.T. Lawless, Crying wolf: false alarms in a pediatric ICU,Critical Care Medicine 22 (6) (1994) 981–985.

[4] F.J. Torralba-Rodríguez, J.T. Fernández-Breis, R.Valencia-García, J.M. Ruíz-Sánchez, R. Martínez-Béjar, J.A.Gómez-Rubí, An ontological framework for representing andexploiting medical knowledge, Expert Systems withApplications 25 (2) (2003) 211–230.

[5] E. Kyriakides, J. Stahlhut, G. Heydt, A next generation alarmprocessing algorithm incorporating recommendations anddecisions on wide area control, in: Proceedings of the IEEE2007 PES General Meeting, Tampa, Florida,

2007.

[6] F.E. Block, L. Nuutinen, B. Ballast, Optimisation of alarms: astudy on alarm limits, alarm sounds, and false alarms,intended to reduce annoyance, Journal of ClinicalMonitoring and Computing 15 (1999) 75–83.

i n b

Sánchez-Cuadrado, D. Moner, R. Valencia-García, M. Robles,A semantic web-based system for managing clinical

c o m p u t e r m e t h o d s a n d p r o g r a m s

[7] L. Biot, P.Y. Carry, J.P. Perdrix, A. Eberhard, P. Baconnier,Evaluation clinique de la pertinence des alarmes enreanimation, Annales Francaises d’Anesthesie et deReanimation 19 (2000) 459–466.

[8] J. Wainer, A. de Melo Rezende, A temporal extension to theparsimonious covering theory, Artificial Intelligence inMedicine 10 (1997) 235–255.

[9] C. Yu-N, S.S.R. Abidi, Evaluating the efficacy of knowledgemanagement towards healthcare enterprise modelling, in:Proceedings of the International Joint Conference onArtificial Intelligence, Workshop on KnowledgeManagement and Organizational Memories, 1999.

[10] J. Edworthy, E. Hellier, Alarms and human behavior:implications for medical alarms, British Journal ofAnaesthesia 97 (2006) 12–17.

[11] F. Hartge, T. Wetter, W.E. Haefeli, A similarity measure forcase based reasoning modeling with temporal abstractionbased on cross-correlation, Computer Methods andPrograms in Biomedicine 81 (1) (2006) 41–48.

[12] P. Compton, R. Jansen, A philosophical basis for knowledgeacquisition, Knowledge Acquisition 2 (1990) 241–257.

[13] B. Kang, P. Compton, P. Preston, Multiple classification rippledown rules: evaluation and possibilities, in: The 9thAAAI-Sponsored Banff Knowledge Acquisition forKnowledge Based Systems Workshop, 1995.

[14] G. Edwards, P. Compton, R. Malor, A. Srinivasan, L. Lazarus,

PEIRS: a pathologist maintained expert system for theinterpretation of chemical pathology reports, Pathology 25(1993) 27–34.

[15] G. Shiraz, C. Sammut, Combining knowledge acquisitionand machine learning to control dynamic systems, in:

i o m e d i c i n e 9 8 ( 2 0 1 0 ) 161–171 171

Proceedings of the 15th International Joint Conference onArtificial Intelligence (IJCAI’97), Morgan Kaufmann, 1997, pp.908–913.

[16] G. Beydoun, A. Hoffmann, Incremental acquisition of searchknowledge, International Journal of Human-ComputerStudies 52 (2000) 493–530.

[17] B. Kang, K. Yoshida, H. Motoda, P. Compton, A help desksystem with intelligence interface, Applied ArtificialIntelligence 11 (1997) 611–631.

[18] M. Park, T.M. Cao, J. Jin, L. Wilson, Multiple classificationripple down rule and fuzzy set in computer arded diagnosis,IFAC (2003).

[19] T.M. Cao, An analysis of incremental knowledge acquisition,Ph.D. Thesis, University of New South Wales, 2006.

[20] H.A. Hathfield, J. Wyatt, Philosophies for the design anddevelopment of clinical decision support systems, Methodsof Information in Medicine 32 (1993) 1–8.

[21] C. Martínez-Costa, M. Menárguez-Tortosa, J.T.Fernández-Breis, J.A. Maldonado, A model-driven approachfor representing clinical archetypes for semantic webenvironments, Journal of Biomedical Informatics 42 (2009)150–164.

[22] J.T. Fernández-Breis, M. Menárguez-Tortosa, C.Martinez-Costa, E. Fernandez-Breis, J. Herrero, J.

archetypes, in: Proceedings of 30th Annual InternationalConference of the IEEE Engineering in Medicine and BiologySociety, 2008.