20
An ontological framework for representing and exploiting medical knowledge Francisco Jesu ´s Torralba-Rodrı ´guez a , Jesualdo Toma ´s Ferna ´ndez-Breis a , Rafael Valencia Garcı ´a a , Juana Marı ´a Ruı ´z-Sa ´nchez a , Rodrigo Martı ´nez-Be ´jar a, * , Juan Antonio Go ´mez-Rubı ´ b a Departamento de Ingenierı ´a de la Informacio ´n y las Comunicaciones, Universidad de Murcia, CP30071 Murcia, Spain b Servicio de Medicina Intensiva, Hospital Universitario Virgen de la Arrixaca, Carretera Madrid-Cartagena, El Palmar, CP30120 Murcia, Spain Abstract Patients on Intensive Care Units (ICUs) need continuous attention and monitoring. The patient may be connected to an alarm system, so that an alarm is triggered when the state of the patient changes. In this work, we present an ontology-based approach to reduce the influence of superfluous alarms. Our main goal was to build an intelligent system for ICUs, so that given a set of patient’s event, that system could check whether the patient meets some diagnostic hypothesis in order to keep track of his/her correct evolution. q 2003 Elsevier Science Ltd. All rights reserved. Keywords: Knowledge Management; Intensive Care Unit; Ontology 1. Introduction Nowadays, the importance of Knowledge Management (KM) is growing in the Information Society and medical domains are not an exception. In Yu-N and Abidi (1999), managing knowledge in the healthcare environment is considered to be important due to the characteristics of healthcare environments and the KM properties. The motivation for the work presented here is an ongoing multidisciplinary research project taking place between an AI group and a hospital aimed at modeling clinical events at Intensive Care Units (ICUs). The ultimate objective is the implantation of a KM system in that unit. From the ICUs clinical management perspective, we intend to have the decision making, the knowledge acquisition and manage- ment processes in knowledge bases. So, such processes will be more efficient in resources and time dimensions. On the other hand, if the clinical management of the ICUs is made through intelligent systems oriented to clinical manage- ment, then, different clinical management variables (i.e. doctors, equipment, nurses, etc.) will directly interact with pure clinical variables. An important problem in patient management is the unfolding of illness over time, so that the representation and analysis of clinical data cannot be performed without taking into account its temporal dimension (Shahar, 2000). It can be said that time is especially important when time-oriented clinical data take part of decision support applications such as determining a diagnosis or monitoring the evolution of a patient (Shahar, 1999). This work deals with monitoring and diagnosis through the use of intelligent alarms systems. According to Lawless (1994), the purpose of measuring and monitoring systems is to identify changes in variables which previous experience or physiologic knowledge suggests are likely to impair the viability of the tissues, organs, or organism. Moreover, there is strong evidence that the use of monitoring devices, if properly used, would prevent a significant number of deaths or injuries (Tinker et al., 1989). Conventional patients’ monitoring systems get physio- logical signals and process them to extract reliable information. When a certain parameter reaches a threshold, an alarm is triggered informing about the existence of an abnormal condition. Commercial patients’ monitoring systems have some important problems to overcome such as the low specificity of the alarms and the triggering of superfluous ones. Each alarm warns about abnormal values of a certain condition. In ICUs, where response time is critical, it would be desirable to have systems that apply alarm management 0957-4174/03/$ - see front matter q 2003 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0957-4174(03)00048-4 Expert Systems with Applications 25 (2003) 211–230 www.elsevier.com/locate/eswa * Corresponding author. E-mail addresses: [email protected] (R. Martı ´nez-Be ´jar); fjtr2@alu. um.es (F.J. Torralba-Rodrı ´guez); [email protected] (J.T. Ferna ´ndez- Breis); [email protected] (R.V. Garcı ´a); [email protected] (J.M. Ruı ´z-Sa ´nchez); [email protected] (J.A. Go ´mez-Rubı ´).

An ontological framework for representing and exploiting medical knowledge

Embed Size (px)

Citation preview

An ontological framework for representing and exploiting

medical knowledge

Francisco Jesus Torralba-Rodrıgueza, Jesualdo Tomas Fernandez-Breisa, RafaelValencia Garcıaa, Juana Marıa Ruız-Sancheza, Rodrigo Martınez-Bejara,*,

Juan Antonio Gomez-Rubıb

aDepartamento de Ingenierıa de la Informacion y las Comunicaciones, Universidad de Murcia, CP30071 Murcia, SpainbServicio de Medicina Intensiva, Hospital Universitario Virgen de la Arrixaca, Carretera Madrid-Cartagena, El Palmar, CP30120 Murcia, Spain

Abstract

Patients on Intensive Care Units (ICUs) need continuous attention and monitoring. The patient may be connected to an alarm system, so

that an alarm is triggered when the state of the patient changes. In this work, we present an ontology-based approach to reduce the influence of

superfluous alarms. Our main goal was to build an intelligent system for ICUs, so that given a set of patient’s event, that system could check

whether the patient meets some diagnostic hypothesis in order to keep track of his/her correct evolution.

q 2003 Elsevier Science Ltd. All rights reserved.

Keywords: Knowledge Management; Intensive Care Unit; Ontology

1. Introduction

Nowadays, the importance of Knowledge Management

(KM) is growing in the Information Society and medical

domains are not an exception. In Yu-N and Abidi (1999),

managing knowledge in the healthcare environment is

considered to be important due to the characteristics of

healthcare environments and the KM properties. The

motivation for the work presented here is an ongoing

multidisciplinary research project taking place between an

AI group and a hospital aimed at modeling clinical events at

Intensive Care Units (ICUs). The ultimate objective is the

implantation of a KM system in that unit. From the ICUs

clinical management perspective, we intend to have the

decision making, the knowledge acquisition and manage-

ment processes in knowledge bases. So, such processes will

be more efficient in resources and time dimensions. On the

other hand, if the clinical management of the ICUs is made

through intelligent systems oriented to clinical manage-

ment, then, different clinical management variables (i.e.

doctors, equipment, nurses, etc.) will directly interact with

pure clinical variables.

An important problem in patient management is the

unfolding of illness over time, so that the representation and

analysis of clinical data cannot be performed without taking

into account its temporal dimension (Shahar, 2000). It can

be said that time is especially important when time-oriented

clinical data take part of decision support applications such

as determining a diagnosis or monitoring the evolution of a

patient (Shahar, 1999). This work deals with monitoring and

diagnosis through the use of intelligent alarms systems.

According to Lawless (1994), the purpose of measuring and

monitoring systems is to identify changes in variables which

previous experience or physiologic knowledge suggests are

likely to impair the viability of the tissues, organs, or

organism. Moreover, there is strong evidence that the use of

monitoring devices, if properly used, would prevent a

significant number of deaths or injuries (Tinker et al., 1989).

Conventional patients’ monitoring systems get physio-

logical signals and process them to extract reliable

information. When a certain parameter reaches a threshold,

an alarm is triggered informing about the existence of an

abnormal condition. Commercial patients’ monitoring

systems have some important problems to overcome such

as the low specificity of the alarms and the triggering of

superfluous ones. Each alarm warns about abnormal values

of a certain condition.

In ICUs, where response time is critical, it would be

desirable to have systems that apply alarm management

0957-4174/03/$ - see front matter q 2003 Elsevier Science Ltd. All rights reserved.

doi:10.1016/S0957-4174(03)00048-4

Expert Systems with Applications 25 (2003) 211–230

www.elsevier.com/locate/eswa

* Corresponding author.

E-mail addresses: [email protected] (R. Martınez-Bejar); fjtr2@alu.

um.es (F.J. Torralba-Rodrıguez); [email protected] (J.T. Fernandez-

Breis); [email protected] (R.V. Garcıa); [email protected] (J.M.

Ruız-Sanchez); [email protected] (J.A. Gomez-Rubı).

techniques, solving (some of) the problems mentioned

before. Nowadays, there is an increasing interest in the

development of patients’ monitoring systems that are able to

produce more significant outputs (smart alarms). One way to

do that is improving the quality of the information supplied

by the alarms by using the historical temporal evolution of

the patient. An alarm can be defined as a warning of an

approaching or existing danger and traditional monitoring

systems generate an alarms when the value of a variable is

higher than a pre-defined threshold.

In Van de Aa (1990), the main problems with traditional

alarm systems are described: (a) it is impractical to set all

the individual thresholds at the beginning, or during an

anaesthetic procedure; (b) alarms are not specific; (c) a

single variable alarm cannot point to possible causes; (d)

artifacts can trigger an alarm indiscriminately (false

alarms). Van de Aa (1990) presents a layered approach to

Intelligent Alarms, which is comprised of seven layers. The

most significant layers are the fourth and fifth ones, namely,

redundancy removal and the smart alarms. The fourth layer

is in charge of detecting and removing superfluous data and,

therefore, next levels only work with necessary data. The

smart alarms layer generates the alarms by looking at

different elements such as feature values, trends, or

combinations of variables. The intelligence of the approach

resides in this layer, which needs as much a priori

information as possible about the patient.

In this work, we move from an abductive diagnosis and

monitoring approach to a consistency-based one. According

to Lucas (1998), an abductive diagnosis is formalised as

reasoning from effects to causes, with causal knowledge

represented as logical implications of the form causes !

effects, where causes are usually abnormalities or faults, but

they may also include normal situations. On the other hand,

consistency-based diagnosis finds faulty device components

that account for a discrepancy between predicted normal

behaviour and actually observed behaviour. This discre-

pancy is formalised as logical inconsistency. In our work,

this discrepancy is measured by the inconsistency between

concepts from the hypothesis and the history of the patient.

We could also state that our system performs hypothetical

reasoning, because of its capability of producing multiple

diagnoses, generating different hypotheses and testing them

in parallel. In Haimowitz, Le, and Kohane (1995), an

approach for detecting trends by matching the data to

patterns is presented. This approach, in addition to the

consistency-based and the abductive diagnosis, could be a

third approach used for diagnosing. In that work, diagnosis

is related to trend detection and the patterns matching is

based on a regression model.

In literature, ontologies are commonly defined as

specifications of domain knowledge conceptualisations

(Van Heijst, Schreiber, & Wielinga, 1997). In Shahar

(1999), a domain knowledge ontology is presented as a

theory of entities (concepts), their properties (attributes),

and their relations in the domain. Our ontological model

covers three types of relationships: taxonomic, mereolo-

gical and temporal. In medical domains (Shahar, Miksch,

& Johnson, 1998), actions and effects are not necessarily

instantaneous, but actions are considered to have

temporal extensions, that is, actions can be expected to

be performed in a time interval or a period of time

(Shahar & Musen, 1996). This characteristic is covered

by the ontological model by measuring temporality in a

fuzzy manner. In this sense, another goal of our

ontological model was to cover the temporal dimension-

ality of actions (alarms in our case). These goals have

been reached through the design and implementation of

an ontology-based system for managing intelligent

alarms. This system is capable of deciding whether a

patient meets a diagnostic hypothesis or not, by doing an

efficient management of the alarms triggering (that is, by

detecting superfluous and false alarms). As pointed out in

Haimowitz and Kohane (1993), false alarm rates are very

high in current alarm systems and they can divert the

attention of doctors away from more important tasks. But

they are not the unique non-ideal alarms; false-negative

alarms and true-positive ones with inappropriate delays

should also be avoided. In Lawless (1994), the author

found that over 94% of alarms soundings in a paediatric

ICU might not be clinically important, the patient

movement being the most common cause of the false

alarms. Therefore, a reliable reduction of redundant and

false positive alarms in ICUs is definitely needed

(Haimowitz et al., 1995). The ontological model

introduced here is used from two different perspectives.

On the one hand, it is used to model the ICU, with its

personnel, equipment, patients and so on, that is, from an

organisational point of view. On the other hand, it is

used to model the clinical evolution of the patients of an

ICU. We have focused this work on a single ICU

although this approach can easily be extended to multiple

ICUs, which could share knowledge about diagnostic

hypotheses. The alarms’ triggering that warns about the

state of a specific patient are registered as events of that

patient and they will take part in the patient’s evolution.

This evolution is specified as an ontology, which is used

to check for the correctness of the patient’s evolution and

diagnosis.

Another objectives of this work was to take into

account the occurrence of cyclical (events or sets of

events that appear more than one time). For it, an

ontology-based framework for managing cycles is

proposed in this paper.

The structure of this paper is as follows. Section 2

provides an overview of the system. In Section 3, the

ontological framework used in this work is introduced.

Section 4 describes OBIAC tool, which implements a

system that meets the requirements. The validation of the

system is validated is Section 5. Finally, some conclusions

are put forward in Section 6.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230212

2. An overview of the framework

In an ICU, different actors can be identified: patients,

medical doctors, nurses, and medical equipment (alarm

systems, beds and so on). The purpose of this article is to

show an approach aimed at building a system able to

help medical doctors to follow the evolution of their

patients, by integrating the knowledge offered by physicians

and the knowledge collected from intelligent alarm systems.

Moreover, the clinical response time is a critical factor, so

that having a system that applies alarm management

techniques is very useful to avoid false and redundant

alarms, which are the main problems of current patients

monitoring systems. It would also be desirable to have

labeled alarms, which describe pathological states of

patients. The framework has been designed to meet all

these requirements.

2.1. Clinical events management

In our environment, four main entities, which are not

totally independent one another, can be distinguished:

patient (diagnostic) hypothesis, medical staff and event.

Both the evolution of the patients and diagnostic hypotheses

are defined through a set of events. An event occurs in a

specific environment, which is determined by the patient

and his/her disease. That implies that the event must

have some type of relationship with the rest of elements

(events) that exist in its environment. The measurement of

such relationships will depend on the type of event. In case

of patient events, such relations are quantified by means of

natural numbers, whereas in case of hypothesis events, the

relations have to be measured in a fuzzy way. The reason for

such difference is that the state of the patient changes at a

particular time point, so that the temporal relation between

two hypothesis events cannot be specified so precisely as for

patients because there can be differences between different

patients. Therefore, a fuzzy measurement is required for

quantifying such relations. In particular, three fuzzy

relationships have been used in this work: (a) approximately

x time units later; between x and y time units later; (c)

exactly x time units later.

There are events whose existence determine a particular

diagnosis or that constrain heavily the possible diagnoses.

There may also be events that cannot occur if the patient

suffers from a particular disease. All these issues can be

summarised in four criteria.

Criterion 1. It follows from the requirement of the

existence of a series of events for a particular disease. It

establishes the minimum set of events that have to be

present in the evolution of a patient so that the correspond-

ing diagnostic hypothesis is acceptable.

Criterion 2. It establishes which events cannot appear

in the evolution of a patient diagnosed with a specific

disease. Let us suppose that the patient P suffers from C

and the diagnostic hypothesis for such disease implies

that the events A and B are incompatible in the context

of this hypothesis. Then, if A and B appear in the

evolution of the patient P then C is not a valid diagnosis

for P.

Criterion 3. It establishes the possibility of admission for

series of events whose existence is not compulsory for the

existence of a particular disease. That is, even though minor

events/criteria specified in the diagnostic hypothesis do not

appear in the evolution of the patient, the diagnosis for the

patient would not become invalid.

Criterion 4. If the hypothesis is defined along some days

(i.e. 10 days) and the patient evolution is less than this

quantity (i.e. 5 days), there should be events in the

hypothesis that cannot appear in patient evolution, because

it is not the moment (these events will be called ‘Future

Events’, because they must appear in the future). So, when

checking a patient evolution with a hypothesis, these events

do not have to be taken into account.

The sets of events defining particular diagnostic

hypotheses are not usually linear throughout the timeline

but they contain cycles, which are ordered sets of events that

may occur more than once to the patient. Therefore, this

special type of cyclical events must be modelled in a

particular way. For this purpose, a diagnostic hypothesis

will be comprised of individual events and cycles. On the

other hand, the evolution of the patient will be comprised of

individual events and the occurrence of instance of the

hypothesis cycles must be detected. To do this the following

general algorithm for checking whether the evolution of the

patient follows the pattern indicated by a specific diagnostic

hypothesis will be followed:

1. If the diagnostic hypothesis contains cycles, then detect

such cycles in the patient’s evolution.

2. If some cycle is found, then replace the individual

events that are part of the cycle by the cycles that

appear in the patient’s evolution.

3. This step is comprised of two actions.

a. Check whether the event-related criteria are met.

b. Check the temporal consistency between the

diagnostic hypothesis and the temporal evolution

of the patient.

4. If both are consistent, then it is acceptable that the

patient evolves according to the diagnostic

hypothesis.

Moreover, the resulting system will assign a value to the

hypothesis. This value will be a measure of the accuracy of

the diagnosis process, in such a way that the closer the

evolution of the patient is to the hypothesis, the higher the

value will be. Therefore, the hypothesis will not be accepted

unless its associated value is greater than a determined

threshold. This threshold will be established manually by

the user, so that the degree of exigency imposed to the

system is variable.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 213

2.2. Other framework’s possibilities

One of the problems with traditional patient monitoring

systems is the existence of false alarms, that is, alarms that

are triggered but that do not have any real influence on the

patient’s evolution. When the correction of a diagnostic

hypothesis is checked, the system labels alarms as either

positive or false, and it will not take into account the false

ones in the process of detecting whether the patient meets a

specific temporal pattern (i.e. a diagnostic hypothesis) or

not. A problem comes up when a false alarm is not false as

such but it has been forgotten by the medical doctors when

they have specified the temporal pattern of the hypothesis.

As a consequence of carrying out the process of checking

whether both ontologies, the one representing a diagnostic

hypothesis and the other one representing the patient

evolution, are consistent, the system will be capable of

discovering events, if any, from the patient ontology that do

not belong to the diagnostic hypothesis. This might happen

due to different reasons, such as a false or a missing alarm.

In this case, medical doctors could have forgotten an event

or the event could be medically unknown when the

hypothesis was constructed. The framework has been

designed so that the system asks experts (medical doctors)

whether the new alarm must be part of the diagnostic

hypothesis. In case their answer is affirmative, temporal

constraints should be added to the event to establish its

relationships with its environment (disease).

The system will help to make the decision about a

patient’s diagnosis when this is not clearly known. It could

be thought that the patient has the diagnosis proposed by a

medical doctor, but diagnosis in ICUs is frequently

uncertain. Then, we could try to test the patient’s evolution

with different hypotheses. The system will allow for this

partial testing process by selecting the patient and the set of

diagnostic hypotheses to check. This request would result in

a set of possible diagnostic hypotheses whose temporal

pattern is met by the temporal evolution of the selected

patient. Each candidate hypothesis would then be given a

value according to the different tests made and the best

candidate. If this value is greater than the threshold

established by the expert, then the hypothesis will be

acceptable for the patient.

3. The ontological framework

3.1. Ontologies in medical domains

Ontologies have been used for representing knowledge in

clinical domains, although they have been used for different

purposes. In this section, some examples are mentioned. In

Schulz and Hahn (2001), an ontology engineering frame-

work for the anatomy domain is proposed. An ontology has

also been used in the NeoGanesh system (Dojat et al., 1997)

and in the Deja Vu system (Dojat, Ramaux, & Fontaine,

1998) to model the world into two types of entities: (1)

atemporal entities, used to model the observed system, and

(2) temporal entities, used for modelling the evolution.

YAQ (Uckun, Dawant, & Lindstrom, 1993) is another

example of ontology applied to model-based reasoning in

physiologic domains. RESUME (Shahar & Musen, 1996) is

another system that uses ontologies in medical domains.

3.2. Ontologies in this work

An ontology is viewed in this work as a specification of a

domain knowledge conceptualisation (Van Heijst et al.,

1997). In addition, ontologies will be represented here by

means of multiple hierarchical restricted domains (MHRD)

in a similar manner to that employed by other authors (see,

for instance, Eschenbach and Heydrich (1995)). In particu-

lar, we term MHRD to a set of concepts holding the

following:

† They are defined through a set of attributes, so that the

presence of axioms between these attributes will not be

considered.

† There can be taxonomic relations among concepts, so

that attribute (multiple) inheritance is permitted.

† There can also be mereological and temporal relation-

ships among the concepts.

In addition to this, the ontology representation schema

adopted here includes ‘structural’ axioms, that is, axioms

drawn from the proper structure of the ontology. It should be

clarified that defining ontologies without non-structural

axioms does not mean that this sort of axioms cannot be

defined as a (part of the) specification of a conceptualisation.

What we do is to split up the classic definition of ontology

(i.e. the one including structural and non-structural axioms)

into two parts so that we term ontology to the whole

specification of a conceptualisation excluding non-struc-

tural axioms.

Taxonomic and partonomic relationships have widely

been used in ontological models and they are considered as

basic relationships to be covered by an ontological model

(Borst, 1997; Schulz, Romacker, Faggioli, & Hahn, 1999;

Shahar & Musen, 1996). Temporal relationships have also

been used in clinical domains and they are considered to be

significant. Moreover, various qualitative and quantitative

temporal relationships can exist between measurements and

interventions. In particular, temporal relationships are

essential in our domain (i.e. in ICUs) to model the temporal

evolution of a patient and the temporal relationships

between the different events of a patient’s clinical history.

Regarding partonomic relationships among concepts, the

(mereological) part-of ontologies defined here will be

supposed to hold irreflexivity, and asymmetry. On the

other hand, although there are other properties that may be

present in partonomic ontologies, we will constrict our-

selves to analyse partonomic organisations by taking into

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230214

account the previous (mereological) properties and some

other (new) attribute-based ones. Concerning temporal

organisations, this type of organisation can be seen as

temporal graphs/networks in a similar sense to that used in

Wainer and de Melo Rezende (1997). In order to represent

possibility, the membership function has been used. This

function has been used, for instance, in Jones, Harrison, and

Lowe (2001) and Lowe, Harrison, and Jones (1999) for

modelling fuzzy trends.

3.3. Some ontological definitions

Some ontological definitions are introduced in this

section. Such definitions will be used in next sections.

These definitions have already been used in Fernandez--

Breis and Martınez-Bejar (2000a,b).

Definition 1. Equivalent concepts. Two concepts A and B

belonging to different ontologies are said to be equivalent if

their respective sets of attributes are equivalent (their

attributes have the same names) and their respective sets of

parent and child concepts are also equivalent (each parent

concept of A has an equivalent concept amongst the parent

concepts of B or one of them has no parents).

Definition 2. Equivalent ontologies. Two ontologies A and

B are equivalent when for every concept c belonging to A

there is a concept c0 in B such as c and c0 are equivalent.

Definition 3. Inconsistent concepts. Two concepts A and B

belonging to different ontologies are inconsistent if they

have the same name, their respective sets of parent and

children concept are equivalent but they have no common

attributes.

Definition 4. Inconsistent ontologies. Two ontologies A and

B are inconsistent if there is a pair of concepts c1 and c2; one

belonging to A and the other one belonging to B, such that

c1 and c2 are inconsistent concepts.

3.4. Ontological representation of cycles

A cycle can be seen as a (sub)ontology whose root

concept is the name of the cycle and each particular event is

a mereological child of that root concept. However, some

assumptions and properties concerning cycles should be

introduced:

† A cycle is a leaf node of the ontology that specifies the

diagnostic hypothesis.

† The events included in a cycle cannot appear in the rest

of the diagnostic hypothesis (i.e. the ontology).

† The events included in a cycle must be independent of

the events that are not members of the same cycle.

A cycle can be more formally defined as follows.

Definition 5. Cycle. A cycle Cy(t) is a set of concepts

(events) {c0ðtÞ; c1ðtÞ;…; cnðtÞ}; holding the following prop-

erties:

1. The events included in the cycle cannot appear in the rest

of the diagnostic hypothesis.

2. There can only be temporal relationships between ciðtÞ

and cjðtÞ i . 0; j . 0; i – j:

3. c0ðtÞ is the root of the cycle and it is the mereological

parent of the other cycle events.

4. The cycle is a leaf node of the ontology that specifies

the diagnostic hypothesis.

Now, provided that a cycle can be seen as an ontology,

functions to check for both the equivalency and the

consistency among two cycles can be defined.

Definition 6. Cycle_equivalency. Let cycle1(t) and cycle2(t)

be two cycles. Then, it is said that they are equivalent

cycles, written cycle_equivalency (cycle1(t), cycle2(t)) if

equivalent_ontologies (cycle1(t), cycle2(t)).

Definition 7. Cycle_consistency. Let cycle1(t) and cycle2(-

t) be two cycles. Then, it is said that they are consistent

cycles, written cycle_consistency (cycle1(t), cycle2(t)) if

not (inconsistent_ontologies (cycle1(t), cycle2(t))).

Therefore, when checking whether two ontologies are

consistent or equivalent and the current concept is a cycle

then the corresponding function for cycles will be applied.

3.5. Ontology-based consistency

Now, the algorithm to check for the consistency between

the temporal evolution of a patient and the diagnostic

hypothesis must be modified since cycles can appear in the

model. The algorithm used is described in the following

lines. First, let us introduce an example that will be useful

for illustrating the process. Let us suppose that the

diagnostic hypothesis is given by Table 1. The hypothesis

is comprised of a set of individual events X0; X1; X2; and X3

and two cycles, Cycle1 and Cycle2. Moreover, the

diagnostic hypothesis is formulated in a way so that

Table 1

The diagnostic hypothesis

Event Time

X0 0 min

X1 Approx. 5 min after X0

X2 Approx. 3 min after X0

X3 Approx. 10 min after X1

Cycle1 Approx. 2 min after X1

Cycle2 Approx. 3 min alter X2

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 215

the members (events) of the set {X1; Cycle1} must appear

compulsorily in the evolution of patients for the disease

under question.

Each cycle is defined in the following way. Cycle1 is

comprised of the events E1 and E2; so that E2 occurs after

E1: Cycle2 is comprised of the events E3 and E4; so that E4

occurs after E3: There is not a quantified delay between the

occurrence of events E1 and E2; nor between E3 and E4: Let

us also suppose that there is a patient connected to our

system through an intelligent alarm system. Thus, the

temporal evolution of that patient could be defined by the

sequence of events shown in Table 2.

Step 1. Checking for the existence of cycles in the

diagnostic hypothesis. In this step, the ontology that

represents the diagnostic hypothesis must be checked in

order to know whether it contains cycles or not. In case

cycles are not included in the diagnostic hypothesis then, go

to the Step 4 of this algorithm. The input of this step is the

ontology representing the diagnostic hypothesis, and the

output is a boolean value that indicates whether the

algorithm must go to Step 2 or 4.

In our example, through this step we check whether the

diagnostic hypothesis contains cycles and it can be observed

in Fig. 1 that the hypothesis contains two cycles, Cycle1 and

Cycle2 so that Step 2 is the following step of the algorithm.

Step 2. Identifying cycles. In this step, the cycles

included in the diagnostic hypothesis must be searched in

the temporal evolution of the patient. For it, the individual

events of each cycle are individually identified in the

patient’s ontology. Once all the individual events of a cycle

have been found, the cycle’s internal temporal consistency

must be checked. In case the cycle is not consistent, both

ontologies are directly labelled inconsistent, so that the

algorithm returns the inconsistency found. The inputs for

this step are the ontologies that represent the patient’s

temporal evolution and the diagnostic hypothesis. The

output is the set of cycles included in the diagnostic

hypothesis identified in the patient’s temporal evolution.

When analysing the example ontology shown in Table 2

that represents the temporal evolution of the patient under

question, the individual events of both cycles are found. In

particular, Cycle1 occurs twice during the period of time

covered by this example, and Cycle2 just once. First, all the

appearances of Cycle1 should be identified. For it, its

individual events must be searched in the ontology. An

appearance of E1 is found at the time point 5 min 50 s and

one of E2 at 7 min 37 s so that the (internal) temporal

constraint associated to Cycle1, namely that E2 occurs after

E1; is met and therefore the cycle is identified. A second

appearance of E1 is found at 15 min 13 s and the second one

of E2 is found at 16 min 7 s as well. On the other hand, the

cycle Cycle2 is also identified in the patient’s evolution. Its

individual events are found at 7 min 25 s ðE3Þ and 8 min

ðE4Þ:

Step 3. Inclusion of the cycles. The alarm system is

not capable of detecting cycles but warning about

individual events, which may or may not belong to a

cycle. The previous step is in charge of detecting the

existence of those cycles in the patient’s evolution. The

individual events identified in the evolution of the patient

as part of the cycles defined in the corresponding

Fig. 1. The ontology after including the cycles.

Table 2

The patient’s evolution

Event Time

X0 0 min

X2 2 min

X1 4 min 20 s

E1 5 min 50 s

E3 7 min 25 s

E2 7 min 37 s

E4 8 min

X3 14 min 45 s

E1 15 min 13 s

E2 16 min 7 s

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230216

diagnostic hypothesis are replaced by their respective

cycles in the patient’s evolution. Each individual event

has an occurrence time assigned to it so that the cycle

that replaces a set of events must also be assigned an

occurrence time. In particular, the occurrence time

assigned to the cycle will be the occurrence time of

the first event included in the cycle. In case the same

cycle is identified more than once in the patient’s

evolution, the cycle will only appear once while the rest

of appearances will be removed from the evolution of the

patient. The inputs for this step are the inputs for Step 2

and the output of Step 2. The output is a new ontology

representing the temporal evolution of the patient but in

which the cycles are included.

Example. In our example, the ontology representing

the evolution of the patient would be transformed into

the one shown in Fig. 1.

Step 4. Checking for the consistency of the patient’s

evolution and the diagnostic hypothesis. For this purpose,

the procedure is the same as the one used in the method

without cycles. For this step, a cycle will be considered as a

simple node, since checking for the consistency only takes

into account the temporal relationships and the occurrence

times for each event/cycle. Then, there will be two

ontologies, representing the evolution of the patient and

the diagnostic hypothesis, respectively. Moreover, the

consistency of these two ontologies will be checked by

means of the function consistent_ontologies.

Example. At this stage, it must be checked the

consistency between the diagnostic hypothesis and the

patient evolution. For it, it can be seen in Tables 3 and 4

the temporal measurement for the events belonging to the

corresponding temporal chains. Both ontologies are

consistent from a temporal point of view since the

occurrence time of each patient event belongs to the time

interval established in the diagnostic hypothesis. Therefore,

the patient can be diagnosed the disease specified by the

hypothesis.

Step 5. Finally, the event-related criteria must be

checked. In this example, the evolution of the patient is

applied the criterion stating that X1 and Cycle1 are events

that have occurred to the patient.

4. OBIAC tool

In this chapter, we will explain how this tool works.

Once the OBIAC tool is launched, the main window is

displayed (Fig. 2). There, the user should be able to see the

list of patients that exist at that particular time within the

system. They will appear in the list labeled ‘PATIENTS’. In

the list labeled ‘HYPOTHESIS’, the list of hypothesis that

exist at that particular time within the system is shown. On

the right hand-side, the information of the selected patient is

shown. Such selection is made by clicking on the name of

the corresponding patient.

By clicking on the button labeled ‘Patient Evolution’ or

by selecting the option ‘Patient ! Evolution’ in the menu,

the description of the patient evolution since its entrance is

displayed in natural language in an independent window

(Fig. 3).

In order to see the expected evolution of a hypothesis, the

user has to use the option ‘Hypothesis ! Expected

Evolution’ (Fig. 4).

The menu bar in the main window permits users to create

and modify the elements of the system.

4.1. Adding patients and hypothesis

The first element to consider is (obviously) the patient.

To create a new patient, we will select ‘Management !

New Patient’, and then, the new patient window should be

opened (Fig. 5). In that window, the following patient data

are input: name, age, diagnosis and entrance date (this field

is automatically set by OBIAC but it may be changed), if he/

she is diabetic and/or hypertensive, and the medicament

allergies that he/she suffers (including comments that were

necessary, i.e. alternative medicament). Moreover, a

registration number should appear. This number is assigned

by the system, and it cannot be modified. It will be useful to

identificate patients (especially if they have the same name).

To introduce a diagnosis for the patient, this may be chosen

by selecting it in the combobox labelled ‘Possible

Diagnosis’, where all the hypothesis kept by the system

appear.

Once the patient data has been introduced, then, by

clicking on the ‘Add’ button, the patient will be inserted into

the system database. Then, the buttons ‘Add Other’ and ‘Add

Event’ will be activated, so that new patients or events for

Table 4

The patient’s evolution

Patient evolution Exact occurrence time

X0 0 min

X2 2 min

X1 4 min 20 s

Cycle1 5 min 50 s

Cycle2 7 min 25 s

X3 13 min 15 s

Table 3

The hypothesis

Hypothesis Fuzzy occurrence time

X0 0 min

X2 Approx. 3 min

X1 Approx. 5 min

Cycle2 Approx. 6 min

Cycle1 Approx. 7 min

X3 Approx. 15 min

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 217

the new patient may be defined. It must be taken into account

that the Add button is disabled once the new patient is added,

because this patient cannot be added again. By clicking on the

‘Done’ button, the new patient window will be closed.

New hypotheses may also be created through the option

‘Management ! New Hypothesis’, and then, the new

hypothesis window is opened (Fig. 6). In that window, the

hypothesis description (i.e. ‘arrythmias’) is introduced. As

for creating patients, once the new hypothesis is added,

events and new hypotheses may be defined.

Patients and hypothesis are composed of events. An event

is a fact that is produced in a patient (or hypothesis) at a

specific moment. Moreover, events may have an associated

magnitude value (i.e. increase of temperature ¼ 0.5 8C).

This value may be numeric (i.e. obtained through a

medition), but sometimes, medicians prefer using literal

values (i.e. corporal temperature is very high). In OBIAC,

both options are permitted.

4.2. Adding events

If we want to add a new patient event, we have to choose

the option ‘Patient ! Add Event’ after selecting the patient

in the main window (or clicking on Add Event when

creating a patient as it was stated before). In that case, the

new event window will be opened (Fig. 7). There, the

description and the value of the event must be introduced.

To introduce the event description, the user may introduce

either a new description or select an existing one.

To introduce the event value, the user may insert a

numeric value and/or select a fuzzy one (a literal value)

from the combobox labelled ‘fuzzy value’. The possible

Fig. 2. Principal OBIAC window.

Fig. 3. Patient Evolution window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230218

diffuse values are: ‘very-high’, ‘high’, ‘middle-high’,

‘middle’, ‘middle-low’, ‘low’, ‘very-low’ (Fig. 8).

After introducing the event data, the event is inserted into

the system database by clicking on the Add button. When

the data base is updated, we can add other event pushing

Add Other button, or start the ‘Edit Event’ window pushing

Edit Event button (we will see this window later).

4.2.1. Hypothesis events

We can add hypothesis events in similar way as for

patient events, by selecting the option ‘Hypothesis ! Add

Event’ after having selected a patient, but there are some

differences (Fig. 9).

Hypothesis events are facts that are expected to appear in

patient evolutions. But not all the patients develop all the

Fig. 4. Hypothesis expected evolution.

Fig. 5. New Patient window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 219

events with the same magnitude (i.e. patients that suffer flu,

their fever will be between 37 and 40 8C. Hence, a flu

hypothesis saying that fever will be exactly 38 8C cannot be

defined. So, when introducing the hypothesis event value in

the field ‘Numeric Value’, two numeric values defining a

range (i.e. for event ‘fever’, such values would be 37 and 40)

are expected.

In addition, there are events, which are incompatible

in the context of a hypothesis. If such events appear in

the same patient evolution, such hypothesis must be

rejected. So, after creating an event, its incompatible

events may be defined by clicking on the button labeled

‘Incompatible’.

On the other hand, not all the patients develop all the

events. There are events, called major events, which are

compulsory for concluding that the patient is developing the

diseases. However, other events, called minor events, are not

compulsory. This quality of the event is input by selecting

‘Major’ or ‘Minor’ in the combobox labelled ‘Type’. The

value ‘kLaterl’ can be chosen for delaying this qualification

(Fig. 10).

Moreover, some ‘minor events’ are more important than

others. For this purpose, a priority value must be selected

from the combobox labelled ‘Priority’. The possible priority

values are: very-high, high, middle-high, middle, middle-

low, low, very-low (Fig. 10).

Fig. 6. New Hypothesis window.

Fig. 7. New Event window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230220

4.3. Editing events

After creating hypothesis or patient events, they can be

edited by selecting a patient (or hypothesis) in the main

window and either selecting ‘Patient (or Hypothesis) !

Edit Event’ or clicking on the Edit Event button once the

event has been added. Then, the Edit Event window is

opened for the selected patient or hypothesis (Figs. 11 and

12). There, the event values (i.e. numeric and/or diffuse) and

its temporal relations can be edited.

Another event of the selected hypothesis (or patient)

without closing the window, by selecting it in the combobox

labelled ‘OBSERVATION’. The type and the priority of

events can also be changed. Finally, incompatible events

may also be checked and modified.

4.3.1. Temporal relations

Once hypothesis events have been introduced, time

relations between hypothesis events must be defined in

the Edit Event window. In the list labelled ‘Temporal

Relations’, all the relations between the edited event and

the rest of selected hypothesis (or patient) events appear.

A temporal relation between patient or hypothesis

events can be added by clicking on the ‘New’ button,

edited by clicking on the ‘Edit’ button in edit event

Fig. 8. Event diffuse value.

Fig. 9. New Hypothesis Event window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 221

window, or removed by selecting it and clicking on the

‘Remove’ button (Figs. 11 and 12).

In this window, a new relation between the current event

and another patient (or hypothesis) event can be defined. To

indicate that the chosen event will occur before, the user will

choose ‘BEFORE’. If the chosen event must occur after,

‘AFTER’ will be the selected option (Fig. 14).

Now, the relation type must be selected. There are three

types of relations, namely (Fig. 14):

† Exactly: Event A will occur exactly x s before/after

Event B.

† Between: Event A will occur between x and y s before/

after Event B.

† Approximately: Event A will occur x s before/after Event

B (^20% error).

Finally, the time delay is specified. This is introduced by

using two sets of comboboxes accounting for temporal

categories (i.e. seconds, minutes, hours and so on). If the

relation type is ‘Exactly’ or ‘Approximately’, the second set

will be ignored (Fig. 14).

A temporal relation is correct if there is not any cycle

between temporal relations (i.e. a before b, b before c, c

Fig. 10. Type and priority values.

Fig. 11. Edit Patient Event window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230222

before a), and there is not any other temporal relation

between the same events. If the temporal relation is not

correct, an error message will appear.

Editing a temporal relation. On the other hand, a

temporal relation can be edited by selecting it and clicking

on the Edit button. The relation would be displayed and the

user may modify it as in the previous case. The functionality

of this window, labelled ‘Editing a link for the event’, is the

same that we have described before (Figs. 13 and 14).

4.4. Creating/editing incompatible events

The window shown in Fig. 15 appears when the user

wants to edit incompatible events. There, all the events,

which are incompatible with the current event, are

shown. The list of the existing system events is also

shown.

The dialog for creating a new incompatible event (see

Fig. 16) is displayed by clicking on Add Event. This

window is similar to ‘New Hypothesis Event’ one, although

in this case the Add Other and Edit Event buttons and the

combobox to select the description do not exist. Moreover,

there is not type nor priority value.

4.5. Creating/editing cycles

In order to describe cycles, the option ‘Hypotheses !

Add Cycle’ must be selected. Then, the ‘New Cycle’

window will be opened (Fig. 17). As for hypothesis events, a

Fig. 12. Edit Hypothesis Event window.

Fig. 13. New/Edit Temporal Relation window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 223

code (generated by OBIAC) will be assigned to it. Its

description, type and priority value must be specified.

Once the cycle is introduced, its events must be defined.

The ‘New Cycle Event’ window will be shown by clicking

on Add Event. This window is exactly the same as the one

for creating hypothesis events (see Fig. 9).

All the events appear in the list labelled as ‘Cycle Events’

followed by its numerical and fuzzy values (i.e. ‘EventD

{from 0.2 to 0.4} {Low}’). If one is selected, the ‘Edit Cycle

Event’ window will be opened with the event data. Event

values and temporal relations between cycle events may be

added, edited, or removed as for hypothesis events.

However, cycle events can only be related to cycle events.

A cycle can be considered a sub-hypothesis into a

hypothesis. On the other hand, the cycle, as an element of

the hypothesis, has type and priority values and it can have

incompatible events.

4.5.1. Editing cycles

Fig. 18 is the corresponding window for editing cycles.

This window is similar to the New Cycle window with small

differences. First, on the top of the window, the hypothesis

Fig. 14. New/Edit Temporal Relation window options.

Fig. 15. Incompatible Events window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230224

cycle description field appears in a combobox where the

cycle to edit is selected. On the other hand, the Add button

has been changed by the ‘Update’ button, which is used to

update cycle data (not cycle events data) in system database.

Finally, there is not an Add Other button.

4.6. The diagnosis process

OBIAC allows for comparing the patient evolution with

a diagnostic hypothesis to confirm a particular diagnosis. To

do that, the option ‘Patient ! Check’ is provided. The user

Fig. 16. Create Incompatible Event window.

Fig. 17. New Cycle window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 225

must select a patients and a set of candidate hypotheses for

performing such checking. There are some aspects that must

be taken into account when checking patient evolutions with

hypotheses.

4.6.1. The accuracy problem in OBIAC

Patients who develop the same disease usually show

different symptoms. If all hypothesis events appear correctly

in the patient evolution, the hypothesis must be accepted,

but it would be wrong to use only event occurrence times for

such measurements. So, OBIAC evaluates how much the

patient evolution approximates the hypothesis description,

taking into account parameters such as the type and priority

values of the hypothesis events.

First, Major events must always appear correctly in the

patient evolution. If a Major event does not appear in such

evolution, the hypothesis is rejected. If all the Major events

appear in patient evolution, the error in Minor events must

be calculated. For this purpose, a hypothesis value (HV) is

calculated by using all hypothesis events (except Future

Events) priority values. This priority value is fuzzy, but

numeric values are required for this computation, so that a

numeric value must be assigned to each fuzzy value, as

follows:

Diffuse value Numerical value

Very-high 7

High 6

Middle-high 5

Middle 4

Middle-low 3

Low 2

Very-low 1

To establish the HV, OBIAC will sum all the non-Future

Events priority value.

Once HV has been calculated, the value for the patient

evolution, and the measurement of the hypothesis compli-

ment (HC) must be obtained. For it, the system will sum the

non-Future Events priority value of those events that appear

in patient evolution correctly (with correct value, and in

expected time). Finally, HV and HC are compared.

Concretely, the percentage of HV that is complimented in

patient (HC) is calculated. This is the compliment value of

the hypothesis (CV).

CV ¼ ðHC £ 100Þ=HV

Now, a threshold value to accept or reject the hypothesis

must be established. It is called the ‘Acceptation Value’.

This can be done by using the option ‘Management !

Acceptation Value’.

Some observations about the acceptation value must

be made. If it is equal 100%, no minor event can fail.

On the other hand, if it is equal to 0%, all minor

events can fail. In this latter case, if all Major events

appear correctly in patient evolution, the acceptance of

rejection of the hypothesis will be independent of Minor

events.

4.6.2. OBIAC diagnosis information

OBIAC compares the patient evolution with the

hypothesis, which represents the expected evolution.

These are the possible outputs for this process:

† Case 1. Patient evolution fulfils exactly the hypothesis.

† Case 2. Patient evolution fulfils every major events but

not every minor events.

Fig. 18. Edit Cycles window.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230226

† Case 3. Patient evolution does not fulfil every major

events.

† Case 4. There are incompatible events.

In the first case, the hypothesis is completely accepted.

For Cases 3 and 4 the hypothesis will be rejected. For Case 2

the response will depend on the priority of the events that

have failed, the HV (priority value of all events) and the

acceptation value established at this moment.

In each case, the application output is shown to the user,

as well as the reasons for the decision made, and, if the

hypothesis is accepted, it will show information about future

events and false alarms. So, the application output is as

follows:

† Case 1 (Fig. 19). It will appear an acceptation window,

followed by a window with Future Events (if there is

almost one). Then, a window with the events (if there is

almost one) that are part of a cycle in the hypothesis, but

do not form one complete or have errors is displayed. It

should be noticed that if the cycle appears once, the event

that represents it is accepted as correct, but it could have

other occurrences with errors. Finally, the false alarms (if

there is almost one) are shown.

† Case 2. It will appear the list of inconsistent events with

the reason of the failure (i.e. ‘INCONSISTENT

VALUES’). Next, the resolution (i.e. acceptance or

rejection) and the percentage of compliment of the

hypothesis are shown.* If the hypothesis is accepted, future events and false

alarms lists (as in Case 1) are shown. The events that

appear in the hypothesis but not appear in patient (if

there is almost one), called expected events, are also

displayed. If there are expected events, it may mean

that those events have not been noticed in the patient

(someone may be forgot to do it), so it is important to

take them into account (Fig. 20).* If the hypothesis is rejected, the list of expected events

(if there is almost one) is shown (Fig. 21).

† Case 3 (Fig. 22). The list of inconsistent events, major

and minor, as well as the failure reason is displayed.

Next, the rejection window (without HC value) appears,

followed by a window with major events that have failed.

Finally, if there is almost one, the expected events are

listed.

† Case 4 (Fig. 23). In this case, the list of incompatibilities

and the rejection window are shown.

5. Validation of the system

The system described in the previous sections has been

validated across ICU domain which is a very a particular

domain. When a patient enter in a ICU, the diagnosis has

been done. Physicians and ICU personal normally control

that the vital constants values of patients are normal. Next,

we briefly describe how OBIAC can be used in this domain.

In most situations, physicians must describe vital constants

as cycles when describing a particular hypothesis. There are

two manners to do it:

† Describing each vital constant to control as a cycle, so,

each cycle contain an event that describes the event range.

† Grouping events (each group is a cycle). For example,

vital constants that are controlled in every ICU patient

(cardiac frequency, arterial pressure, etc.), and those that

are particular for each hypothesis (for example, in craneal-

encefalic traumatism, medicians will control intracraneal

pressure and other specific values).

Fig. 19. Example of Output in Case 1.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 227

On the other hand, the controlled vital constants values of

patients will be introduced in the application. When ICU

staff inputs patient data the patient evolution can checked

against his/her diagnosis. If there are any problem with

the events of a cycle, there will appear the ‘Faults detected

in Cycle events’ window. The ICU personal can see in that

moment the event priority and type, and will know whether

the fault is an emergency.

Fig. 20. Example of Output in Case 2 (hypothesis accepted).

Fig. 21. Example of Output in Case 2 (hypothesis rejected).

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230228

6. Discussion and conclusions

In this work, we have presented to framework for

managing intelligent alarms in order to monitor patients’

state in ICUs. The motivation for the work described eats

from to Spanish Government-funded project whose objec-

tive is to perform KM in ICUs. This aspect has been

considered necessary elsewhere (Yu-N & Abidi, 1999).

There, managing knowledge in the healthcare environment

is considered to be important due to the characteristics of

healthcare environments and the KM properties. For it, the

management of medical terminology and its evolution is

considered to crucial element (Oliver, Shahar, Shortliffe, &

Musen, 1999). The main technology used in this work has

been the ontology. Ontologies have previously been used to

do temporary abstractions. Thus, in Shahar et al. (1998) an

ontology-based approach facilitates acquisition, mainten-

ance, sharing and reuse of the required storm-abstraction

knowledge. As stated in Schulz et al. (1999), for medical

domains it is not adequate to have only taxonomic and

mereological constraints. Physiological events have tem-

porary dimensionality as well. Therefore, we must take this

into account for choosing the kind of ontological model to

uses. Our approach exploits the significant advantage of

ontologies, namely, reuse, since existing ontologies may be

easily reused for constructing new ones which are related to

the previous ones (i.e. similar hypotheses, similar ICUs,

etc.). The use of ontologies we have made in this work

intends to achieve the same goal as the parameter-properties

ontology that appears in Shahar and Musen (1996).

The ontological temporality has been exploited in this

work mainly for modeling the temporal evolution of patients

and diagnostic hypotheses. In Allen (1984), 13 possible

temporal relationships are specified although they can be

seen as seven and their respective inverse, except in the case

of the ‘equal’ relation. In our work, the unique temporal

relation used has been the AFTER relation which has the

BEFORE one as its counterpart. In the aforementioned

work, a general theory of action and time was pursued and

actions have both starting time and duration. On the other

hand, our work only needs to have information about the

instant or time interval at which an alarm is triggered. Since

in this work we do not focus on the event duration itself, but

on the event sequence, the temporal relations that appear in

Fig. 22. Example of Output in Case 3.

Fig. 23. Example of Output in Case 4.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 229

that work concerning duration of action have not been

considered.

In this work, hypotheses and temporal evolution of

patients are confronted in order to know the correct

diagnosis for a patient, while in Shahar et al. (1998) we

could find equivalent figures for them. The equivalent for

hypotheses are clinical guidelines, obtained during design

time from (medical) experts. During the execution time we

would have the patient’s state, which could be considered as

the equivalent to the temporal evolution of the patient in our

system. Our approach follows a similar philosophy, and our

higher level concepts could be considered to be the

diagnostic hypotheses together with the ontologies that

represent the temporal evolution of patients, although our

system does not try to create temporal abstraction in the way

done in RESUME (Shahar & Musen, 1996). In this sense, it

can be said that our approach is closer to the TrenDx system

(Haimowitz & Kohane, 1993) given that our goal is not to

abstract from the data but checking for the correctness of a

particular diagnosis and suggesting when the diagnosis is

unknown. The approach presented in Haimowitz et al.

(1995) is similar to our approach because both works

implement some kind of pattern matching.

The framework will allow to automatically decide

whether a patient meets a diagnostic hypothesis or not, by

doing an efficient management of the alarms triggering (that

is, by detecting superfluous and false alarms). In Lawless

(1994), a wide classification of alarms is made. There,

alarms can be false, induced and significant. In our work,

induced alarms (provoked by staff manipulation of the

patient) are considered false ones.

Acknowledgements

We thank the Spanish Ministry for Science and

Technology for its support for the development of the

system through projects FIT-150200-2001-320 and FIT-

070000-2001-785, and Seneca Foundation through projects

PL/3/FS/00 and PI-16/0085/FS/01.

References

Allen, J. F. (1984). Towards a general theory of action and time. Artificial

Intelligence in Medicine, 23(2), 23–154.

Borst, W. N (1997). Construction of engineering ontologies for knowledge

sharing and reuse. PhD Thesis, University of Twente, Enschede, The

Netherlands

Dojat, M., Pachet, F., Guessoum, Z., Touchard, D., Harf, A., & Brochard, L.

(1997). NeoGanesh: A working system for the automated control of

assisted ventilation in ICUs. Artificial Intelligence in Medicine, 11,

97–117.

Dojat, M., Ramaux, N., & Fontaine, D. (1998). Scenario recognition for

temporal reasoning in medical domains. Artificial Intelligence in

Medicine, 14, 139–155.

Eschenbach, C., & Heydrich, W. (1995). Classical mereology and restricted

domains. International Journal of Human-Computer Studies, 43,

723–740.

Fernandez-Breis, J. T., & Martınez-Bejar, R. (2000a). A web-based

framework for integrating knowledge. Industrial Knowledge Manage-

ment: A Micro-Level Approach, 123–138.

Fernandez-Breis, J. T., & Martınez-Bejar, R. (2000b). A cooperative tool

for facilitating knowledge management. Expert Systems with Appli-

cations, 18(4), 315–330.

Haimowitz, I. J., & Kohane, I. S. (1993). Automated trend detection with

alternate temporal hypotheses. Proceedings of the 13th International

Joint Conference on Artificial Intelligence, 146–151.

Haimowitz, I. J., Le, P. P., & Kohane, I. S. (1995). Clinical monitoring

using regression-based trend templates. Artificial Intelligence in

Medicine, 7, 473–496.

Jones, R. W., Harrison, M., & Lowe, A. (2001). Computerised anaesthesia

monitoring using fuzzy trend templates. Artificial Intelligence in

Medicine, 21, 247–251.

Lawless, S. T. (1994). Crying wolf: False alarms in a pediatric intensive

care unit. Critical Care Medicine, 22(6), 981–985.

Lowe, A., Harrison, M. J., & Jones, R. W. (1999). Diagnostic monitoring in

anaesthesia using fuzzy trend templates for matching temporal patterns.

Artificial Intelligence in Medicine, 16, 183–199.

Lucas, P. (1998). Analysis of notions of diagnosis. Artificial Intelligence,

105.

Oliver, D. E., Shahar, Y., Shortliffe, E. H., & Musen, M. A. (1999).

Representation of change in controlled medical terminologies. Artificial

Intelligence in Medicine, 15(1), 53–76.

Schulz, S., & Hahn, U. (2001). Parts, locations and holes-formal reasoning

about anatomical structures. Lecture Notes in Artificial Intelligence,

2101, 293–303.

Schulz, S., Romacker, M., Faggioli, G., & Hahn, U. (1999). From

knowledge import to knowledge finishing automatic acquisition and

semi-automatic refinement of medical knowledge. Proceedings of

Knowledge Acquisition Workshop.

Shahar, Y. (1999). Timing is everything: Temporal reasoning and temporal

data maintenance in medicine. Joint European Conference on Artificial

Intelligence in Medicine and Medical Decision Making. AIMDM’99,

Aalborg, Denmark, Berlin: Springer, pp. 30–46.

Shahar, Y. (2000). Dimension of time in illness: An objective view. Annals

of Internal Medicine, 132(1), 45–53.

Shahar, Y., Miksch, S., & Johnson, P. (1998). The Asgaard project: A task-

specific framework for the application and critiquing of time-oriented

clinical guidelines. Artificial Intelligence in Medicine, 14, 29–51.

Shahar, Y., & Musen, M. A. (1996). Knowledge-based temporal abstraction

in clinical domains. Artificial Intelligence in Medicine, 8(3), 267–298.

Tinker, J. H., Dull, D. L., Caplan, R. A., Ward, R. J., Cheney, F. W. (1989).

Role of monitoring devices in prevention of anesthetic mishaps: A

closed claims analysis. Anesthesiology, 71, 541–546.

Uckun, S., Dawant, B. M., & Lindstrom, D. (1993). Model-based diagnosis

in intensive care monitoring: The YAQ approach. Artificial Intelligence

in Medicine, 5, 31–48.

Van de Aa, J. J (1990). Intelligent alarms in anaesthesia. Thesis,

Technische Universiteit Eindhoven, The Nederlands

Van Heijst, G., Schreiber, A. T., & Wielinga, B. J. (1997). Using explicit

ontologies in KBS development. International Journal of Human-

Computer Studies, 45, 183–292.

Wainer, J., & de Melo Rezende, A. (1997). A temporal extension to the

parsimonious covering theory. Artificial Intelligence in Medicine, 10,

235–255.

Yu-N, C., & Abidi, S. S. R. (1999). Evaluating the efficacy of knowledge

management towards healthcare enterprise modelling. Proceedings of

the International Joint Conference on Artificial Inteligence.

F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230230