abstraction on clinical data sequences: an object-oriented data model and a query language based on...

Artificial Intelligence in Medicine 17 (1999) 271–301

Abstraction on clinical data sequences: anobject-oriented data model and a query

language based on the event calculus

Carlo Combi, Luca Chittaro *Dipartimento di Matematica e Informatica, Uni6ersita degli Studi di Udine, Via delle Scienze 206,

33100 Udine, Italy

Received 10 August 1998; received in revised form 14 December 1998; accepted 25 February 1999

Abstract

In this work, we deal with temporal abstraction of clinical data. Abstractions are, forexample, blood pressure state (e.g. normal, high, low) and trend (e.g. increasing, decreasingand stationary) over time intervals. The goal of our work is to provide clinicians withautomatic tools to extract high-level, concise, important features of available collections oftime-stamped clinical data. This capability is especially important when the availablecollections constantly increase in size, as in long-term clinical follow-up, leading to informa-tion overload. The approach we propose exploits the integration of the deductive andobject-oriented approaches in clinical databases. The main result of this work is anobject-oriented data model based on the event calculus to support temporal abstraction. Theproposed approach has been validated building the CARDIOTABS system for the abstrac-tion of clinical data collected during echocardiographic tests. © 1999 Elsevier Science B.V.All rights reserved.

Keywords: Temporal reasoning; Temporal abstraction; Object-oriented databases; Deductive databases;Time sequences

www.elsevier.com/locate/artmed

* Corresponding author. Tel.: +39-432-558450; fax: +39-432-558499.E-mail addresses: [email protected] (C. Combi), [email protected] (L. Chittaro)

0933-3657/99/$ - see front matter © 1999 Elsevier Science B.V. All rights reserved.

PII: S0933 -3657 (99 )00022 -6

C. Combi, L. Chittaro / Artificial Intelligence in Medicine 17 (1999) 271–301272

1. Introduction

In dealing with clinical stored data, there is the need of considering them atabstraction levels higher than the one at which they are stored [13]. For example,in the case of blood pressure, database systems typically store numerical values forSBP (systolic blood pressure) and DBP (diastolic blood pressure) together with thedate of the blood pressure measurement, but usually, besides these numericalvalues, physicians need more abstract descriptions of blood pressure measurements,e.g. in terms of normal and pathological blood pressure, or in terms of normal,high, and low blood pressure. Other important abstractions concern parametertrends: ‘increasing SBP for three visits’, or ‘normal blood pressure values in the last6 months’, or even ‘sequences of periods with alternating increasing and decreasingblood pressure values’ are some sentences at the abstraction level usually consideredfor diagnostic and/or therapeutic purposes.

Recently, medical informatics has paid an increasing attention to temporalabstraction mechanisms for decision support systems, see, e.g. [13,19,26]. Thesesystems are able to automatically derive abstract descriptions of stored patient data,but only for a patient at a time; they do not allow queries concerning the wholepatient database. Moreover, a recent research topic in medical informatics isspecifically devoted to the design and implementation of powerful query languages,which allow one to specify complex temporal features on clinical data [12,13].Finally, some work in the temporal database community can also be relevantbecause it focuses on the modeling, management, and query of time sequences, i.e.data acquired sequentially over time [22,24].

The general goal of our work is to design information systems able to extracthigh-level, concise, important features from the available collections of time-stamped clinical data. Particularly, we want to provide clinicians with a querysystem to perform temporal abstraction on patients’ clinical data. We identified theintegration of the deductive and object-oriented approaches in clinical databases asa key issue in achieving our goal. The deductive approach provides us with asuitable formalism to specify the temporal ontology, the temporal reasoningactivities, and the user queries; the object-oriented approach provides us withversatile and efficient methodologies and tools for data modeling, design andimplementation of prototypes.

In this paper, we propose an object-oriented data model based on the eventcalculus (EC), a well-known theory of time and change proposed in [17], to supporttemporal abstraction on time sequences of clinical data. More specifically, weconsidered the following issues in the design of the conceptual model:� modeling time sequences;� modeling the well-known simple (or basic) abstractions, such as increase, de-

crease, stationary and state [18,25];� modeling complex (or pattern) abstractions, obtained by composing abstractions

through temporal operators (e.g. meets, starts, during) [18,25].In defining the object-oriented data model, we adopted OODAPLEX [34] as a

generic object-oriented data model, and extended it by:

C. Combi, L. Chittaro / Artificial Intelligence in Medicine 17 (1999) 271–301 273

� defining abstract data types that model the fundamental concepts of EC: timepoint, inter6al, e6ent, and property ;

� specializing the data types in order to describe the events that model timesequences, and the properties that model temporal abstractions.Finally, we validated our approach by building CARDIOTABS, a prototype for

the abstraction of clinical data in cardiology [9]. CARDIOTABS is in experimentaluse on real echocardiographic data in the Department of Cardiology of theHospital of Pordenone, Italy.

The paper is organized as follows. Section 2 provides some basic notions on (i)temporal databases, with a special focus on the management of time sequences andon object-oriented temporal databases; (ii) temporal abstraction of clinical data;(iii) the event calculus (EC). Section 3 illustrates how we use EC to model temporalabstraction on clinical data sequences. Section 4 describes the object-oriented datamodel we defined to manage the EC ontology and to perform queries for temporalabstractions. Section 5 illustrates the application of our data model to echocardio-graphic data. Section 6 examines the architecture and the user interface of theprototype we built, which is based on the object-oriented data model we definedand performs queries related to temporal abstractions on echocardiography data.Section 7 concludes the paper with a discussion of the main achieved results.

2. Background

2.1. Temporal databases, time sequences, and object-oriented temporal databases

In the database field, temporal databases gained an increasing attention duringthe last years [11,33]. Among the main research directions, we distinguish the studyof temporal data models and the definition of suitable temporal query languages[33].

A widely accepted taxonomy has been defined for the temporal dimensionssupported by a temporal database. Snodgrass and Ahn [27] identified three differenttemporal dimensions: (1) the transaction time, that is, the time at which data arestored in the database (e.g. the time at which a symptom description is entered intothe patient medical record); (2) the 6alid time, that is, the time at which the data aretrue for the modeled real world entity (e.g. the time at which the symptomappeared); and (3) the user-defined time, that is, every temporal dimension whichmight be defined by the user for a specific application and is not directly managedby the system (e.g. the symptom description may be enriched with the time at whichthe patient reported the symptom). In this taxonomy, four kinds of databases canbe defined: (a) snapshot databases, based on flat, timeless data models; (b) rollbackdatabases, which represent explicitly only the transaction time; (c) historical data-bases, which represent explicitly only the valid time; and (d) the bitemporaldatabases, which represent explicitly both transaction time and valid time and thusare both historical and rollback [33].


The proposed temporal data models, dealing with valid and/or transaction times,are usually extensions of already existing data models, as the relational model, theentity-relationship model, and object-oriented models [21,29,33,34]; similarly, querylanguages for temporal databases are based on extensions of well-known querylanguages [21,22,28,32].

An exception to this approach is represented by the research efforts in modelingcollections of data acquired sequentially over time: modeling of time sequences, i.e.ordered sequences of data values in the time domain, has been mainly consideredfor scientific and statistical databases [23,24]. The focus of these research efforts isnot on extending already existing data models with temporal dimensions, but onmodeling explicitly time sequences using ad hoc structures, and then providingadvanced interpretation mechanisms for these structures, e.g. handling possiblymissing values, applying different kinds of statistical analyses, and extractingmeaningful subsequences of values [24]. Time sequences are often modeled as anordered sequence of triplets Bs, t, a\where s is the surrogate1 of the entityinstance we are considering (e.g. an identifier of the considered patient), t is thetime, and a is the attribute value (e.g. 75 for heart rate) [24].

Object-oriented technology applied to the database field has some useful fea-tures—abstract data type definition, inheritance, complex object management—formodeling and managing complex information, such that coming from clinicalmedicine [4,12,15]. Three approaches have been adopted in dealing with thetemporal dimension of data by object-oriented data models and query languages[29]:1. Direct use of the object-oriented data model. For example, OODAPLEX [34]

and TIGUKAT [14] are two systems adopting this approach. In these systems,suitable data types allow the database designer to model temporal information.For example, in modeling different notions of time, OODAPLEX allows one touse the supertype point (a generic set of coordinates in a n-dimensional space),from which each user-defined or system-supported data type inherits, to repre-sent different temporal dimensions [34]. This is the approach we adopt in thispaper to model sequences of clinical data.

2. Use of other (i.e. non-temporal) extensions to the object-oriented data model, tomanage the temporal dimension; this second approach is mainly based on theconcept of annotation to support the history of attribute values for a class [29].An annotation is information used ‘behind the scenes’ by the system: in thiscase, annotations allows one to manage attributes of objects both for the currentvalues, which user can access, and for the previous values (the history), whichusually are not visible, unless explicitly examined.

3. Extension of the object-oriented data model. This approach, based on thedefinition of suitable data models to support temporal dimensions of data, isexploited in many proposals of temporal object-oriented database systems, likeTOODM [22], OQL/T [31], GCH-OSQL [12]. All these models allow one to deal

1 Surrogates are unique identifiers whose values cannot be seen by the users, but can be compared forequality [30].


explicitly with valid and/or transaction times for objects, attributes, classes,types, and so on. Suitable, full-fledged temporal types are provided to modeltemporal concepts, i.e. time points, intervals, temporal elements. TOODM, forexample, models valid times by encoding attribute values as time sequences of(value, temporal element) pairs, following an approach based on the previouslymentioned results in modeling time sequences [22,24].

2.2. Temporal abstraction

Temporal abstraction provides a concise and integrated description of a collec-tion of time-stamped raw data [13]. In medical informatics, temporal abstractionplays a central role in supplying care providers with data at a suitable level forsupporting decision-making. Temporal abstraction has been investigated in somedepth in recent years [13,18–20,25]. An analysis of the usefulness of temporalabstraction is provided, for example, by Aliferis et al. in [1], who address theproblem of providing and evaluating appropriate levels of temporal abstractionusing a common formalism for medical decision support systems.

Many representations of temporal data at high abstraction levels in medicalexpert systems were inspired by Allen’s interval-based logic [2,13]. Shahar andMusen [25,26] proposed a general framework for abstraction of time-stamped data,called the Knowledge-Based Temporal Abstraction (KBTA) framework. TheKBTA framework includes a theoretical model for time and for propositions thathold over time, a general inference method, and five specific temporal abstractionmechanisms, corresponding to the five subtasks into which the temporal abstractiontask is decomposed. The five mechanisms are context formation, contemporaneousabstraction, temporal inference, temporal interpolation, and temporal pattern match-ing [25,26]. The output of these mechanisms includes the basic abstractions of typestate, gradient, rate (e.g. LOW, DECREASING, and FAST are some abstractionsfor the hemoglobin-value clinical parameter) and a special type of abstraction(pattern), defined in terms of patterns of basic abstractions (e.g. HYPER-GLYCEMIA OVERLAPS GLYCOSURIA ABSENT in monitoring diabetic pa-tients [19]). The KBTA method has been implemented in the RESUME system [25]and has been evaluated within several clinical domains, such as oncology, therapyof AIDS patients, monitoring of children’s growth, and management of insulin-de-pendent diabetes [25]. The RESUME system uses time stamps at various pre-defined granularities as temporal primitives. These time stamps are typically offsetfrom a clinically relevant time stamp, such as the time of bone marrow transplanta-tion, the beginning of a therapy, or the date of birth of the patient (e.g. formonitoring children’s growth). Input data or output abstractions can hold onlyduring time intervals, defined as ordered pairs of time stamps.

2.3. E6ent calculus

We have adopted the event calculus (EC), a well-known theory of time andchange proposed in [17], as the temporal ontology in our temporal abstraction


approach for clinical time-oriented databases. EC is an interesting framework,because it is general, well-founded and deeply formally studied, and it has beenrecently applied also to temporal reasoning in medical domains [6,10,16].

From a description of events which occur in the real world and properties theyinitiate or terminate, EC derives the validity intervals over which properties hold.The notions of event, property, time point, and time interval are the primitives ofthe formalism: e6ents happen at time points and initiate and/or terminate timeinter6als over which properties hold. Initiated properties are assumed to persist untilthe occurrence of an event interrupts them (default persistence). We represent anevent occurrence associating the event to the time point at which it occurred bymeans of the happens(e6ent, timePoint) clause. The relations between events andproperties are defined by means of initiates and terminates clauses, such as2:

initiates (event1, property, t) �happens (event1, t) �holds (prop1, t) � ... � holds (propN, t).

terminates (event2, property, t) �happens (event2, t) �holds (prop1, t) � . . . � holds (propN, t).

This sample initiates (terminates) clause states that each event of type e6ent1(e6ent2) initiates (terminates) a period of time during which property holds,provided that N (possibly zero) given preconditions hold at instant t. The EC modelof time and change is concerned with deriving the maximal validity intervals(MVIs) over which properties hold: a validity interval must not contain anyinterrupting event for the property; a maximal validity interval (MVI) is a validityinterval which is not a subset of any other validity interval for the property. Theclause mholds– for(p, [S, E ]) returns the MVIs for a given property p : each MVI isgiven by a pair [S, E ], where S (Start) and E (End) are the lower and upperendpoints of the interval.

Chittaro and Montanari distinguished two different ways of interpreting initiatesclauses in the derivation of MVIs [7,8]. In the first one (weak interpretation), onlyterminating events are considered as interrupting events, and an initiating event e

Fig. 1. Examples of weakly and strongly initiating and terminating events.

2 In the following EC formulas we adopt the convention of beginning variable names with anuppercase letter and constants with a lowercase letter.

. Combi, L. Chittaro / Artificial Intelligence in Medicine 17 (1999) 271–301 277

for property p initiates an MVI, provided that p has not been already initiated bya previous event in such a way that p already holds at the occurrence time of e [7,8].For example, both Fig. 1b and d contain two consecutive weakly initiating events(denoted as wI) for the same property, and thus the derived MVI is initiated by thefirst of the two events. The alternative interpretation (strong interpretation) consid-ers also initiating events as interrupting events: therefore, an initiating event e forproperty p initiates an MVI, provided that there is no subsequent initiating eventfor p such that p is not terminated between the two events. For example, both Fig.1a and c contain two consecutive strongly initiating events (denoted as sI) for thesame property, and thus the derived MVI is initiated by the second of the twoevents. The weak and strong interpretation for terminating events give symmetricalresults: Fig. 1a and b show two consecutive strongly terminating events (denoted assT), and the derived MVI terminated by the first of the two events; while Fig. 1cand d show two consecutive weakly terminating events (denoted as wT), and thederived MVI terminated by the second of the two events.

As clearly shown by Fig. 1, different choices of interpretation for initiating andterminating events may change the derived MVIs. In general, this choice dependson the specific property that needs to be modeled, as we will also see in thefollowing examples. In particular, weak and strong initiates relations can be used tosupport the so-called temporal aggregation and omission [7], respectively. Forexample, consider the problem of monitoring patients who receive a partialmechanical respiratory assistance [10]. A basic requirement of the patient monitor-ing task is the ability of aggregating similar observed situations. It indeed oftenhappens that data acquired with consecutive samplings do not cause a transition inthe classification of the patient ventilatory state. In this case, temporal aggregationrequires that the subsequent samples do not clip the validity interval for the patientstate. Such a functionality can be easily supported by EC, provided that a weakinterpretation of initiates is assumed.

Temporal omission is useful when dealing with incomplete sequences of events[7]. As a simple example, consider a patient receiving mechanical respiratoryassistance; the patient can be connected or disconnected to the device. The situationcan be described by means of the property 6entilator(Connection), where the valueof Connection can be connected or disconnected, and two events: connect (resp.disconnect), that changes the status of the connection from disconnected to con-nected (resp. from connected to disconnected). While two connect (resp. disconnect)events cannot occur consecutively in the real world without a disconnect (resp.connect) event in between, it might happen that an incomplete sequence consistingof two consecutive connect events e1, e2, followed by a disconnect event e3, isrecorded in the database. In such a case, a strong interpretation of initiates allowsEC to recognize that a missing disconnect event must have occurred between e1 ande2. However, since it is not possible to temporally locate such an event, the validityof the property 6entilator(connected) is derived only between e2 and e3, and e1 isconsidered as a pending initiating event.


3. Modeling abstraction on time sequences in EC

We have applied EC to perform two different abstraction activities in temporalclinical databases:1. Simple abstraction considers raw time-stamped clinical data and derives MVIs

for properties concerning those data; these properties allow the evaluation ofabstractions analogous to the basic abstractions of type state, gradient, rate, asdefined by Shahar and Musen in [25,26], and to simple abstractions, as definedby Larizza et al. in [18,19]; examples of simple abstractions are increase,decrease, stationary, state.

2. Complex abstraction considers MVIs and their temporal relations in order toderive compound abstractions, analogous to the pattern special type of abstrac-tion, as defined by Shahar and Musen in [25,26], and to complex abstractions, asdefined by Larizza et al. in [18,19]. Complex abstractions are defined relatingtwo properties by a temporal operator: for example, one could define the‘unstable trend’ abstraction for the systolic blood pressure parameter as asequence of alternating increase and decrease properties for that parameter.

3.1. Modeling e6ents

Following the approach proposed in [24], the value of temporal data is definedfor some entity (e.g. a patient) at a given time (e.g. March 12, 1997), and for anattribute of that entity (e.g. heart rate). The type of event we use to model theacquisition of new temporal data is recei6e(Surrogate, Attribute, Value), whereSurrogate is the entity surrogate (see Section 2.1), Attribute is the name of an entityattribute, Value is the attribute value. The occurrence of an event E at time T ismodeled by the clause happens(E, T). A temporal sequence of data (hereinaftertime sequence) is modeled by a sequence of clauses happens(E, T).

More specifically, in our considered medical domain, we associate a recei6e(Pat,Par, Val) event to each recording of a value Val of a parameter Par for a patientPat. For example, an event recei6e(‘John Smith ’, heartRate, 60) indicates that avalue of 60 bpm has been measured for the heart rate of the patient John Smith. Ifwe denote this sample event as e1, then happens(e1, 1997/8/3/11/30) means thatthe specific measurement of heart rate refers to time 11:30 h and date August 3,1997. At the level of raw time-stamped clinical data, the database contains orderedsequences of many recei6e occurrences for different parameters and for differentpatients.

3.2. Modeling simple abstractions

We define four EC properties, representing simple abstractions:� increase(Surrogate, Attribute, Rate), i.e. the value of an attribute (Attribute) of

an entity (identified by Surrogate) increases over a time interval with a rategreater than the specified one (Rate);


� decrease(Surrogate, Attribute, Rate), i.e. the value of an attribute of an entitydecreases over a time interval with a rate greater than the specified one;

� state(Surrogate, Attribute, AbsValuesSet), i.e. the value of an attribute of anentity can be classified over a time interval into qualitative values (e.g. normal,high) belonging to AbsValuesSet ;

� stationary(Surrogate, Attribute, Threshold, A6erage), i.e. the value of an attributeof an entity over a time interval is inside a range such that the difference betweenmaximum and minimum value is not greater than a given threshold (Threshold);the property also includes the average (A6erage) of the attribute values.All these properties are derived from the event occurrences in the time sequence

considered for the abstraction task.To show how we define simple abstraction activities, we consider the property

increase(Pat, Par, Rte), meaning that a parameter (Par) for a patient (Pat) isincreasing with a rate greater than the specified one (Rte). In EC, one can requirethat a recei6e event initiates an increase property for a parameter if the immediatelyfollowing recei6e event for that parameter reports a value that has increased at leastwith the minimum specified rate. The interpretation of the initiation has to be weak(see Section 2.3), because a sequence of events satisfying the conditions should beaggregated together in a single abstraction. Formally, this can be expressed as:

wInitiates(receive(Pat, Par, Val), increase(Pat, Par, Rte), T) �happens(receive(Pat, Par, Val), T) �first–after(T, receive(Pat, Par, Val1)) �Val1\Val*(1+Rte).

i.e. a generic event recei6e(Pat, Par, Val) weakly initiates a property increase(Pat,Par, Rte) at time T, if that event happens at T, and two conditions are satisfied: (i)there is a subsequent recei6e event (retrieved by the clause first–after) reporting avalue equal to Val1 for the same patient and parameter, and (ii) Val1 is greaterthan Val increased at the given rate (Rte).

For the termination, one can simply state that a recei6e event terminates anincrease property for a parameter if the two above-mentioned preconditions are notboth satisfied. The interpretation of this termination has to be strong (see Section2.3), because the first event which does not satisfy the two conditions should leadto an immediate termination of the property. Fig. 2 shows an example of anincrease abstraction with specified minimum rate 0 (i.e. any positive rate of increaseis accepted). The upper part of the figure shows in bar form the value returned byeach of the measurements, while the lower part shows which recei6e eventsconcerning the measured value are weakly initiating or strongly terminating theproperty: the first three events are weakly initiating the property, because theysatisfy the two above-mentioned preconditions, the fourth and the fifth are stronglyterminating the property because they violate the second and the first of the twopreconditions, respectively.


Fig. 2. An example of an increase abstraction for the heart rate of patient John Smith.

3.3. Modeling complex abstraction

The second type of abstraction activity performed by our system combines theproperties described above to define more complex abstractions: a compoundproperty is defined by specifying the temporal relations which must hold between itscomponent (possibly compound) properties. Considered temporal relations arestarts, meets, during, o6erlaps, equal, finishes [2]. The interval of a compoundproperty is the union of the two MVIs of the component properties. Two additionaloperators, union and intersection, are used to identify any kind of overlappingbetween the MVIs of the component properties: the first returns the union of thetwo component MVIs; the second returns the intersection of the two MVIs.

We represent complex abstractions in EC by means of properties of typeTempOp(Prop1, Prop2), where Prop1 and Prop2 are the component properties,and TempOp represents the considered temporal relation between them. Forexample, the composition of properties Prop1 and Prop2 through the relationduring is defined as:

mholds–for(during(Prop1, Prop2), [S, E])�mholds–for(Prop1, [S1, E1]) �mholds–for(Prop2, [S, E]) �S1\S � E1BE.

Let us consider, for example, the time sequence related to heart rate measure-ments for the patient John Smith. The complex abstraction ‘increasing of heart ratewith saturation at high values, for the patient John Smith’ can be represented bythe following compound property:

meets(increase(‘John Smith’, heartRate, 0),equal(stationary(‘John Smith’, heartRate, 5, Average),

state(‘John Smith’ , heartRate, [high])).


The two components of this complex abstraction are a simple abstraction(increase) and a complex one (equal); the two component properties are related bythe temporal operator meets.

It is worth noting that starting from the simple abstraction properties (increase,decrease, stationary, and state) and combining them into compound properties, it ispossible to model the horizontal temporal inference mechanism, as defined in [25]:this mechanism determines an abstraction as a temporal join (� ) of two adjacentabstractions (e.g. increase � decrease=non-monotonic over the union of the twoconsidered intervals). The join operator defined in [25] corresponds to a compoundproperty based on the meets relation in our model: for example, the abstractionincrease � decrease is equivalent to the compound property meets(increase,decrease). Several abstractions (e.g. non-increasing, non-decreasing, non-monotonic)can be defined in this way.

4. The object-oriented data model

We extended the OODAPLEX data model, described in [34], to deal with the EContology. OODAPLEX basic features are object identity, encapsulation, complexdata types, single inheritance and polymorphism [34]. Extending and using anobject-oriented data model provides us with many advantages in dealing with theEC ontology for temporal abstraction: information hiding allows us to distinguishexternal behavior of objects (i.e. events, properties) and implementation details,hidden to the user; inheritance allows us to reuse software specification, specializingonly suitable subparts of code (for example, we define the general features ofproperties, and then refine this definition to suitably model each specific property);type checking and the availability of a procedural language for the implementationallow us to build efficient algorithms for MVI derivation.

4.1. A short introduction to the OODAPLEX-based data model

In the following, we briefly introduce the main concepts of the OODAPLEX-based data model we adopted.

4.1.1. ObjectsAn object represents a real world entity (a device, a patient) or an abstract entity

(a diagnosis, a risk factor). The basic feature of an object is its identity, which isimmutable, persists for all the object lifetime, and does not depend on either thefeatures or the behavior of the object. Identity is given by an identifier, called OID(Object IDentifier).

All objects are abstract, and are composed by an interface and an implementation.Objects features, relationships among objects, and operations on objects aremodeled by functions, which are applied on objects. A function is composed by aninterface (the name of the function and the signature of the function) and by animplementation.


4.1.2. TypesObjects having the same features and behavior are grouped in types (e.g. integer,

person). A type specifies the functions which can be applied on its instances, i.e. onobjects of that type. Types are themselves objects of type Type [34]. Two specialfunctions types and extent are defined for Type : the function types returns the typeof a given object; the function extent returns the set of objects in the database fora given type. Some basic primitive types are in the data model, i.e. integer, real,boolean, string, with their usual functions. The user is allowed to define new types.

4.1.3. Composite typesComposite (aggregate) types, as sets and tuples, can be recursively defined, by

type constructors, starting from basic types or from user-defined types. A set typeis denoted as {X}, where X is a type (i.e. the type of set elements). Instances of {X}are sets of objects of type X. A type sequence is denoted as Seq(X), where X is atype (i.e. the type of elements in the sequence); instances of Seq(X) are ordered setsof objects of type X. For the type sequence, suitable functions allow one to retrievethe first object, the last one, the object in a given position of the sequence, and soon. A type tuple is denoted as [A1:X1, A2:X2, . . . , An:Xn ], where Xi are types and Ai

are distinct names; objects of type tuple are n-ary tuples, each element Ai being oftype Xi.

4.1.4. FunctionsFunctions are defined by type constructors. A function type is denoted as

(D�C), where D is the domain type and C is the co-domain type. An instance oftype function is a partial function mapping objects of extent(D) into objects ofextent(C). Functions will be used to suitably model temporal data.

4.1.5. Type hierarchyThe generic type object is the common root of all types in the inheritance

hierarchy; the type nil stands at the bottom of this hierarchy (the only instance oftype nil is null).

4.1.6. NotationO :T denotes an instance O of type T ; if f(O1:T1�O2:T2) is a function and O :T1

is given, f(O) denotes the application of the function f to the object O ; the resultis an object of type T2. If T2 is a function type (TD�TC), we denote as f(O)(A) theapplication of the function f, with a suitable argument A :TD, to the object O ; theresult is an object of type TC.

4.1.7. Time modelingFollowing the approach proposed in [34], time concepts are modeled by suitable

user-defined types: in this way, it is possible to model different abstract timeconcepts. Different concepts of time point (e.g. for discrete time or continuous time)are modeled by specializing the type point. The type point is a generalization ofdifferent concepts of point: its interface is composed by functions for the equality


operator (= ) and the ordering relationship (B ). Different subtypes of pointoverload the = and B functions, and redefine their implementation to model, forexample, total versus partial order, or dense versus discrete domains. Additionalfunctions can be defined to support other temporal information and operations,such as different granularities, abstract identification of time points (e.g. 1998/10/3), and time arithmetic operations (1987/7/8+5 days). The set type {point}, and itssubtypes obtained by specializing the type point, allow one to model different timeconcepts such as time spans or repetitive events. The subtype inter6al of {point} isused to model time intervals on a monodimensional time axis.

4.1.8. QueriesQuery bodies are defined using expressions which denote objects [34]. Simple

expressions contain variables or constants, more complex expressions are built withfunctions and composite objects (sets, tuples, and sequences). A set-related expres-sion is built according to the following syntax:

{6ariable in set–expression where boolean–expression}

For example, the expression:

{o in extent(T) where boolean–expression}

returns the set of the objects of type T, for which boolean–expression is true.Boolean expressions are first-order formulas, composed by functions applied onexpressions, using the standard logical connectives (and, or, not) and the quantifiersfor all and for some. The construct the allows one to consider an object in a set; theconstruct for each allows one to iterate over a set.

4.1.9. An exampleAs a comprehensive example of the above concepts, we introduce the following

type definition:

type person is objectfunction name(P:person�N:string)function children(P:person�C:{Person})function age(P:person�A:integer)

type patient is personfunction therapies(P:patient� f:(T:time�Th:{therapy}))function ward(P:patient�D:division)


The type patient inherits from the type person (i.e. a patient has a name, an ageand children); the function children returns, for a given object P of type person, aset C of objects of type person. The type patient has two additional functions, oneproviding information on therapies for a given patient, the other indicating thedivision, where the patient is hospitalized. The function therapies provides, for agiven object P of type patient, and for a given object T of type time (subtype ofpoint), the set Th of therapies for the patient at a specific time point.

To conclude the example, let us consider the following query:What are the drugs administered to the patient John Smith on December 12,

1997? The following OODAPLEX query will give the requested result:

for the p in extent(patient) where name(p)= ‘John Smith’for each Th in therapies(p)(1997/12/12)drug(Th)

end

4.2. Modeling EC e6ents and properties

The data model we propose provides the basic types e6ent and property toproperly model the corresponding concepts of EC. These types are defined asgenerally as possible to easily allow specialization of both concepts. The type e6entis characterized by the function time, returning the time at which the consideredevent happened:

type event is objectfunction time(E:event�P:point)

We forbid the direct instantiation of objects of type e6ent ; only instances ofsubtypes of e6ent, having additional functions for the complete representation ofspecific events, will be allowed.

The type property allows one to express the main features of a property: beinginitiated/terminated by an event, and holding on a time interval.

type property is objectfunction Ei(P:property�E:event)function Et(P:property�E:event)function MVI(P:property�I:interval)function eventSequence(P:property�S:Seq(event))function mholds–for(P:property� f([S:Seq(event), I:integer]�nil))function initiates(P:property� f(E:event�O:boolean))function terminates(P:property� f(E:event�O:boolean))


An instance of type property corresponds to a property holding on a MVI. In theabove type definition, functions Ei, Et and MVI, applied on an instance of typeproperty, return the initiating event, the terminating one, and the MVI of thatobject, respectively. In other words, these functions allow one to read the state ofan instance of type property. The following two functions are used by the system toproperly instantiate objects of type property : the function e6entSequence builds andreturns the sequence of objects of type e6ent (i.e. direct instances of a subtype ofe6ent) which can initiate or terminate the MVI for an object of type property ; thefunction mholds– for returns a function3 able to derive the MVI of a property on thebasis of an event sequence (returned by the function e6entSequence) and theposition from which MVI derivation has to start inside the sequence. To derive aMVI, the function mholds– for uses the auxiliary functions initiates and terminates,describing which events initiate/terminate the given property.

There are no objects which are direct instances of the type property ; functionsinitiates, terminates and e6entSequence are abstract functions for the type property :they are inherited and suitably redefined in its subtypes, allowing one to specializethe concept of property in actual properties of the modeled domain, which can beinstantiated.

4.3. Modeling time sequences

In this section, we will introduce types for modeling events representing temporaldata; then, we will describe the type hierarchy for different abstractions on timesequences; finally, we will present logical steps for the evaluation of queries on theobject database.

4.3.1. E6ent types for time sequencesIn the object-oriented data model, each event recei6e(Surrogate, Attribute,

Value), with its time of occurrence, is mapped into an object of type recei6eE6ent,a subtype of e6ent. A time sequence is represented by a sequence of objects,instances of type recei6eE6ent.

The type recei6eE6ent is defined as follows:

type receiveEvent is eventfunction surrogateType(E:receiveEvent �T:Type)functionsurrogate(E:receiveEvent �O:surrogateType(E:receiveEvent))function surrogateLabel(E:receiveEvent �L:string)function attributeType(E:receiveEvent �T:Type)function attributeName(E:receiveEvent �N:string))function value(E:receiveEvent �V:attributeType(E:receiveEvent))

3 This function returns a null value (of type nil), because it modifies the internal state (deriving thevalue of the MVI) of the given object of type property.


The function surrogateType identifies the type of the object to which themodeled time sequence is related (e.g. the type patient); surrogate refers to theobject itself; surrogateLabel returns the label of the object which will be used bythe user in the query language (e.g. the name of a patient); functions at-tributeType, attributeName and 6alue provide type, name, and value of the at-tribute, respectively. For example, let us consider temporal data concerning theheart rate measurement for the patient John Smith. The measurement on July 26,1997 is 74 bpm; the occurrence of this measurement can be modeled in EC withthe predicate happens(recei6e(‘John Smith ’, heartRate, 74), 1997/7/26). Assumingthat the type patient models patient data in the database, and that the object O oftype patient contains data of the patient John Smith, the considered event ismodeled by an instance E of type recei6eE6ent such that: time(E)=1997/7/26,surrogateType(E)=patient, surrogate(E)=O, surrogateLabel(E)= ‘John Smith’,attributeType(E)= integer, attributeName(E)= ‘Heart Rate’, 6alue(E)=74. Inthis way, a time sequence of heart rate measurements for the patient John Smithis modeled as a set of objects of type recei6eE6ent, for which functions attribute-Name, surrogateType, surrogate, surrogateLabel return ‘Heart Rate’, patient, O,and ‘John Smith’, respectively.

4.3.2. Property types for abstraction on time sequencesWe manage all the features common to simple temporal abstractions, by defin-

ing a suitable specialization of the property type. Fig. 3 shows, according to thenotation of Booch’s class diagrams [3], the type hierarchy based on the types e6entand property for modeling abstraction on time sequences.

The type simpleAbs (simple abstraction), subtype of property, contains somefunctions linking a property with the objects representing time sequence data;some other functions model the temporal aggregation/omission mechanisms forthe evaluation of MVIs. There are no objects which are direct instances of thistype. The type simpleAbs is defined as follows:

type simpleAbs is propertyfunction Ei(P:simpleAbs �E:receiveEvent)function Et(P:simpleAbs �E:receiveEvent)function surrogateType(P:simpleAbs�T:Type)function surrogate(P:simpleAbs�S:SurrogateType(P:simpleAbs))function surrogateLabel(P:simpleAbs�L:string)function attributeName(P:simpleAbs�A:string)function eventSequence(P:simpleAbs�S:Seq(receiveEvent))function mholds–for(P:simpleAbs�

f([S:Seq(receiveEvent), I:integer]�nil))function wInitiates(P:simpleAbs�

f([S:Seq(receiveEvent), I:integer]�O:boolean))function sTerminates(P:simpleAbs�

f([S:Seq(receiveEvent), I:integer]�O:boolean))


Functions Ei, Et return initiating and terminating events for a given object oftype simpleAbs ; functions surrogateType, surrogate, surrogateLabel and attribute-Name have the same meaning described for the type recei6eE6ent ; the functione6entSequence, given an object of type simpleAbs, evaluates and returns the se-

Fig. 3. Type hierarchy of property-related types. In this diagram amorphous blobs represent types. Typenames are written inside the blobs. Blobs representing type constructors, as Seq, present a solid-line boxdenoting its actual parameter. Different kinds of relationship are depicted in the diagram using linesconnecting types. Inheritance relationships are represented by a line with an arrowhead. The arrowheadpoints to the supertype, and the opposite end of the line designates the subtype. ‘use’ relationships (i.e.relationships defined by suitable functions for the considered type) are represented by lines with a circleat the end denoting the using object; the type at the other end denotes the part whose instances are usedby the using object. Relationships are adorned with their cardinality, applied to the target end of anassociation.


quence of objects of type recei6eE6ent, representing the time sequence associatedto the considered property. The function mholds– for redefines the correspondingfunction of the supertype, exploiting temporal aggregation and omission in thederivation of MVIs, by using the functions wInitiates and sTerminates, whichimplement the weak interpretation for initiating events and the strong interpreta-tion for terminating events.

The type simpleAbs has a subtype corresponding to each simple temporalabstraction (increase, decrease, state, and stationary), in which functions wIni-tiates and sTerminates are suitably redefined. Moreover, additional functions inthese subtypes are specific to the different kinds of abstraction: for example, inmodeling the property increase(Surrogate, Attribute, Rate), the correspondingtype will consider the argument Rate by a suitable function, which returns therate of increase:

type increase is simpleAbsfunction rate(P:increase�R:real)function winitiates(P:increase� [S:Seq(receiveEvent), I:integer]�O:boolean))function wterminates(P:increase�

[S:Seq(receiveEvent), I:integer]�O:boolean))

To model compound properties, we define the type compoundAbs (inheritingfrom type property) as follows:

type compoundAbs is propertyfunction tempOp (P: compoundAbs �TO:string)function prop1(P: compoundAbs �P:property)function prop2(P: compoundAbs �P:property)function mholds–for(P: compoundAbs �

[S1, S2:Seq(property), I, J:integer]�nil))

Given an object of type compoundAbs, the function tempOp returns a stringrepresenting the considered temporal relation; functions prop1 and prop2 returnthe two objects of type property (or of a subtype of it), composing the complexproperty.

The function mholds– for allows the complete instantiation of the consideredobject of type compoundAbs ; the object is described by functions prop1, prop2,Ei, Et and MVI. More specifically, the function mholds– for returns a functionthat, given two sequences of objects of type property and two indexes on thesesequences, determines the MVIs for the compound property.


4.4. Querying the database

In the following, we will show how a query, expressed in EC syntax, is evaluatedon a database built according to our object-oriented data model. We assume thatthe part of database which represents the events (i.e. the objects of type re-cei6eE6ent) cannot be modified during a query session; this assumption is consistentwith the execution of abstraction-related queries, which are usually performedoff-line. When new data on events is entered into the database, all the objects oftype property (or of a subtype of it) in the database are deleted and a new querysession starts. We use the following EC syntax (discussed in Section 2.3) to querythe database about a property:

?-mholds–for(Prop, [S, E ]).

Let us assume that we are dealing with the first query to the database. Inanswering the above query, given the extents of subtypes of e6ent, representing timesequences related to the considered property, instances of subtypes of property arecreated as follows:1. An instance Op of type P corresponding to Prop is created.2. The object Op, using the function E6entSequence, determines the sequence of

objects of e6ent type, representing the time sequence associated to Prop.3. The function mholds– for(Op) ([E6entSequence(Op), 1]) derives the first MVI of

the object Op. If subsequent events in the sequence remain to be processed, themholds– for recursively creates another object of type P and derives the nextMVI. The process stops when the event sequence has been completely consid-ered. The objects of subtypes of property created during the query evaluation aremaintained into the database. It is worth noting that, if it is not possible toderive any MVI for the given property, the only instantiated object Op has aMVI having null as value.

4. When all objects representing the considered property have been evaluated, thesystem returns the required results, i.e. the MVIs and values for some property-specific parameters (e.g. the average of the attribute values for the propertystationary).

For example, the query ‘find the MVIs over which the heart rate of the patientJohn Smith is normal’ will be expressed by the following EC query:

?-mholds–for(state(‘John Smith’, heartRate, [normal]), [S, E ]).

To answer this query, steps 1, 2, and 3 create that part of the extent of type state(the set of objects of type state), composed by objects having functions surro-gateLabel, attributeName, and AbsValuesSet, returning respectively ‘John Smith’,‘heartRate’, and ‘normal’. Step 4 returns derived MVIs for the objects of type state,through the function MVI.


Let us now assume that some queries have been already evaluated on thedatabase: the previously described creation steps will be followed only if objects forthe given property are not yet in the database. If these objects are already in thedatabase, it is sufficient to query the database itself: since it is not possible tomodify data stored in the event database during a query session, the objectsmodeling the required property are certainly up-to-date with respect to storedevents. For example, in the case of the previous EC query, the followingOODAPLEX-based query is first tried on the object-oriented database:

for each p in extent(state) wheresurrogateLabel(p)= ‘John Smith’ and attributeName(p)= ‘heartRate’ andAbsValuesSet(p)={‘normal’}

MVI(p)end

Only if the evaluation of the above query returns an empty set (i.e. there are noobjects of type state having functions surrogateLabel, attributeName, and AbsVal-uesSet, returning ‘John Smith’, ‘heartRate’, and ‘normal’, respectively), the foursteps previously described are performed; otherwise, the final result of the EC queryis obtained without instantiating new objects in the database.

5. An application of the data model to echocardiographic data

In this section, we illustrate a specific application of the general data modelpreviously presented to the abstraction of cardiological data. In particular, we focuson the quantitative data produced from the echocardiographic test. This test, beingboth harmless and clinically relevant, is periodically repeated during several yearson high numbers of cardiology patients.

5.1. Collected echocardiographic data

Information collected during the echocardiographic test is recorded in a report.The echocardiographic report is logically organized in sections which group homo-geneous data. Data is of quantitative and/or qualitative nature, with the possibleaddition of free text (e.g. conclusions, notes, and annotations) allowing the physi-cian to express some observations in natural language. The main sections in theechocardiographic report are:� General section, which includes the date of the test, patient personal data (name,

date of birth, . . .), and some patient physiological data (height, weight, bloodpressure, heart rate, . . .);

� M-Mode section, which includes dimensions of the cavity and of other heartstructures along standardized axes;


Table 1The considered quantitative parameters from the echocardiographic test

ACRONYMPARAMETER

Echocardiographic parameters :LVEDDLeft ventricular end-diastolic diameterLVESDLeft ventricular end systolic diameterIVSTInter ventricular septum thicknessPWTPosterior wall thicknessLALeft atrium diameterAMVAortic maximal velocityAMGAortic maximal gradientAVAAortic valve areaSPPSystolic pulmonary pressureMVAMitral valve areaFSShortening fractionAOAortic root diameter

Deri6ed parameters :BMIBody mass index

Left-ventricular end-diastolic volume LVEDVLVESVLeft-ventricular end-systolic volumeEFEjection fractionLVMLeft ventricular mass

Other parameters :HHeightWWeightHRHeart rateSBPSystolic blood pressureDBPDiastolic blood pressure

� 2D section, which includes the results of analyzing bidimensional images toevaluate the shape and function of the heart structures;

� Doppler section, which analyzes blood flows (e.g. speed, pressure gradientthrough aortic valve, . . .) through the heart valves;

� Final section, which includes the conclusions of the report, which can beexpressed either in free text or choosing among a set of pre-defined sentences.Table 1 lists all the parameters we considered (most of which come from the

M-Mode section), paired with the acronyms used hereinafter to reference them.The cardiologist performs two different abstraction activities in the analysis of

patient data:� a simple abstraction activity that highlights the trends of variation in the data,

aggregating successive measurements (obtained consulting the medical record ofthe patient), into higher level concepts (e.g. ‘left ventricular pump functionstationary during the last 6 months’);

� a complex abstraction activity that looks for specific temporal relations amongabstractions concerning various parameters (e.g. ‘an increasing trend for themaximum aortic speed which overlaps a decreasing trend of the aortic valvearea’ indicates a progressive stenosis of the valve with possible unbalancedcirculation).


5.2. Modeling echocardiographic patient data

Every measurement of patient data is modeled with an object of recei6eE6enttype, which uses functions to represent the surrogate of the patient, the consideredparameter, the measured value, and the time of occurrence of the event. Theconsidered parameters are those defined in Table 1. Hereinafter, we will use properacronyms to refer to such parameters (e.g. PWT will be used to indicate posteriorwall thickness). In the database schema, the type patient models patient personaldata. This type groups the information about the patient identification code (patId)and the personal data, such as first and last name, address, sex, and date of birth.An appropriate function is defined to describe each of this data. Therefore, thepatient type can be defined in the following way:

type patient is objectfunction patId(P:patient�ID:string)function name(P:patient�N:string)function address(P:patient�A:string)function sex(P:patient�S:string)function dateOfBirth(P:patient�T:time)

The relation between the temporal data and the patient to which it refers ismodeled by the function surrogate of the type recei6eE6ent, which returns the objectof type patient. The function patId returns a label for the identification of theconsidered patient: it corresponds to the label of the surrogate returned by thefunction surrogateLabel of the recei6eE6ent type. As an example, we consider thetemporal data concerning the measurement of the AO parameter for the patientJohn Smith, who is identified by code 2254. Suppose that the measurementperformed during the echocardiographic test of 26 August 1997 is equal to 3.5 cm.Assuming that there is an instance O of patient in the database, such thatname(O)= ‘John Smith’ and patId(O)= ‘2254’, then the considered measurement ismodeled by an instance of recei6eE6ent such that: surrogateType(E)=patient,surrogate(E)=O, surrogateLabel(E)= ‘2254’, attribute(E)= ‘AO’, at-tributeType(E)=real, 6alue(E)=3.5, time(E)=1997/8/26.

After the information coming from the echocardiographic report is represented,we are able to identify and model the temporal abstractions which are moremeaningful in the considered domain; Table 2 shows some of the simple abstrac-tions used by the cardiologists involved in this study [9]. As we have done withevents, we link each property to a patient and a clinical parameter. For everyconsidered echocardiographic parameter, the increase and decrease abstractionsmust be specified by choosing a minimum rate of change in the data (Rate). Forexample, in order to determine the trend in a sequence of LA measurements, it isuseful to define which is the minimum rate of change, allowing one to classify theincrease or decrease of the parameter as fast or slow.


A reference value for the maximum oscillation in the data (Threshold) has to bedefined for the stationary abstraction of each considered parameter: the stationarydefinition assumes the availability of a (domain-dependent) threshold value, underwhich the variations with respect to the average are considered not meaningful. Forsome parameters which tend to be usually stable, even a very small variation isclinically meaningful; on the contrary, for parameters which are usually scarcelystable, only large variations turn out to be clinically meaningful.

Finally, to differentiate the changes in the data due to the evolution of theclinical state of the patient from those due to spurious data, the derivation of theMVIs for the stationary property has been provided with the capability of identify-ing and ignoring isolated peak values (spurious data).

For the property state, the set of qualitative values is {low, normal, high}, where,for each echocardiographic parameter, the cardiologists defined how to evaluateranges for the qualitative values, also on the basis of existing clinical studies onspecific populations. Some of these ranges are patient-specific and are computedtaking into account sex, height, weight, hearth rate, age, and (optionally) bloodpressure.

6. The CARDIOTABS system

We followed the previously described approach for the design and the implemen-tation of CARDIOTABS (CARDIOlogic Temporal Abstraction System). As aresult, the system is characterized by a sharp distinction between the reusablegeneral aspects, related to the object data model for temporal abstraction, and theapplication-related aspects, focusing on echocardiographic data. Two additionalgoals we have pursued in developing CARDIOTABS have been: (i) integration ofthe system with an existing clinical database; (ii) addition of a simple graphical userinterface.

Table 2Simple abstractions of echocardiographic data

PropertyAbstraction

State(LVDD, high)Ventricular dilatationAortic dilatation State(AO, high)

State(LA, high)Atrial dilatationMaintained LV pump function State(EF, [normal, high])

State(EF, low)Reduced LV pump functionInter Ventricular Septum Thickening State(IVST, high)

Increase(LVDD, 0)Increasing LV dimensionFast increasing LV dimension Increase(LVDD, 2)

Stationary(LVDD, 0.4)Stationary LV dimensionStationary(EF, 15)Stationary LV pump function

Decreasing LV pump function Decrease(EF, 0)Decrease(EF, 30)Fast decreasing LV pump function


Fig. 4. CARDIOTABS software architecture.

CARDIOTABS has been tested in a real cardiological setting (the CardiologyDivision of the Hospital ‘Santa Maria degli Angeli’ in Pordenone, Italy), where thecardiological database contains more than 78 500 medical records [5,9]. We focusedspecifically on patients which underwent several echocardiographic visits.

6.1. System architecture

CARDIOTABS has been developed on a Windows platform, using an object-ori-ented visual tool (DELPHI 2.0). The system is composed by three modules: theData Abstraction Module (DAM), which implements the object-oriented data modelfor temporal abstraction; the Data Acquisition Tool (DAT), which acquires datafrom the clinical database and exchanges I/O information with the user interface;the Graphical User Interface (GUI), through which the user interacts with thesystem. Fig. 4 depicts the overall architecture of CARDIOTABS. The DAT moduleis application-dependent: it receives user queries from the GUI and manages thedata flow from and to DAM; the DAM module is responsible for the creation andstorage of objects corresponding to events and properties. Data flow from DAM toDAT is composed by objects of type property, results of the given query; the DATmodule sends the GUI values for MVIs and for other results of the given query.


6.2. Query formulation

CARDIOTABS allows the user to compose the query through a graphicalinterface, where the user assembles the suitable abstraction query through menuchoices and insertion of desired parameter values. GUI also shows the correspond-ing EC syntax for the query assembled by the user. CARDIOTABS allows one toperform queries (i) on a single patient, by selecting the patient ID data; (ii) on aselected set of patients (possibly the result of previous queries).

Fig. 5 shows the GUI during the formulation of a single patient query. The queryconcerns the stationary property with the following arguments: the patient surro-gate (Patient ID : 2254), the considered attribute (parameter: ejection fraction), thethreshold around the average value (Threshold : 15%). The corresponding query inEC syntax is shown in the upper part of the window.

When formulating a compound property, the user has to define the interval-based temporal relation to use in composing the properties. After this choice, theuser can select the two component properties; if the component properties arethemselves compound, the user will be guided to follow again the same steps for thedefinition of a compound property.

Fig. 5. An example of a single patient query formulation in CARDIOTABS. The query will retrieve theMVIs of stationarity of ejection fraction, with a threshold of 15%, for the patient having 2254 as ID.


Fig. 6. An example of a patients set query in CARDIOTABS. With the checkbox (query on a patientsset) in the upper part of the window, the user selects a query on a patients set; the considered propertyis compound. After the choice of the relation (intersection) and the definition of the first composingproperty (state(PatID, LVEDD, [high ])), the user is entering the arguments for the second composingproperty (increase).

Fig. 6 shows a query on a patients set. The considered set is composed by thepatients which underwent a cardiosurgery for aortic valve prosthesis implantation.For these patients, it is important to monitor prosthesis functionality. The consid-ered compound property thus concerns a pathological situation (‘ventricular dilata-tion combined with an increasing trend of the ventricular diameter’). The temporalrelation is intersection ; the first composing property is state of attribute LVend-diastolic diameter with high values (high); the second composing property isincrease of attribute LV end-diastolic diameter.

6.3. Output presentation

The result of a query consists, for each of the considered patients, in the MVIs(if any) during which the specified property holds. MVIs are displayed in the usualform [S, E ] together with some additional information. For queries on patients sets,CARDIOTABS provides global results (how many patients with at least one MVI,how many patients do not meet the requirements of the query, . . .) and, for each


patient who satisfies the query, the derived MVIs. The user can also save the queryresult (i.e. the reference to the set of patients having at least one MVI) and use itfor further queries; this way, complex queries can be performed in several successivesteps. The user can also navigate through results related to different patients.

The graphical representation of the results allows the visualization of informationcoming both from abstraction properties and from raw data. Both MVIs and raware represented on a two-axes plane, where the x-axis represents the timeline, andthe y-axis represents the dimension of the attribute considered in the property. Forthe stationary property, MVIs are located according to their temporal dimensionand to the evaluated average of the attribute value; all the other properties arelocated according to their temporal dimension at the bottom of the plane. If thereare compound properties dealing with different attributes, a graphical representa-tion is provided also for each considered attribute. We include two displayexamples: Fig. 7 illustrates the presentation of the results provided by CAR-DIOTABS for the query of Fig. 5, and Fig. 8 for the query of Fig. 6.

Fig. 7. Example of presentation for the results of a single patient query.


Fig. 8. Example of presentation for the results of a query on a patients set. Graphical display is providedfor a patient at a time.

7. Conclusions

The goal of our work is to provide clinicians with automatic tools to extracthigh-level, concise, important features of available collections of time-stampedclinical data. This capability is especially important when the available collectionsconstantly increase in size, as in long-term clinical follow-up, leading to informationoverload.

The approach we have proposed in this paper exploits the integration of thedeductive and object-oriented approaches for clinical databases. The former pro-vided us with a suitable formalism to specify the temporal ontology, temporalreasoning activities, and user queries; the latter provided us with versatile andefficient tools for data management and implementation of the prototype. The mainresult of this work is an object-oriented data model based on the event calculus tosupport temporal abstraction. More specifically, the goal of describing the concep-tual model of temporal abstraction based on EC has been achieved in the followingway:� time sequences are modeled with sequences of instantaneous events;� simple abstractions are modeled by properties increase, decrease, stationary and

state ;


� complex abstractions are obtained by composing properties through temporaloperators (e.g. meets, starts, during, . . .).The definition of a data model to handle time sequences and the temporal

abstraction task was achieved through the following phases:� we adopted OODAPLEX [34] as a generic object-oriented data model;� we extended it with abstract data types which model the fundamental entities of

EC (time point, inter6al, e6ent, and property);� we specialized the data types in order to describe the events that model time

sequences, and the properties that model temporal abstractions.The resulting data model is both generic and extensible: its generality allows one

to apply it to other domains besides cardiology; the possibility of extending it isguaranteed by the definition of independent data types for EC entities, which arereusable for different temporal reasoning tasks besides temporal abstraction. More-over, the object-oriented approach facilitates future extensions or specializations ofthe considered types of abstraction. Finally, computational problems of the imple-mentations of EC in declarative languages such as PROLOG [8] are more easilyfaced by means of the procedural language supplied by the object-oriented DBMS.

The proposed approach has been validated by building the CARDIOTABSsystem for the abstraction of clinical data in cardiology. The system allows twotypes of clinical decision-making support: (i) aggregation and abstraction of largeamounts of stored data with identification of significant features for each patient;(ii) evaluation of specific relations between clinical findings and trends of numericparameters on the whole patient database or on selected subgroups of patients.CARDIOTABS is in experimental use at the Division of Cardiology of the Hospitalof Pordenone, Italy. In particular, it is proving to be useful on patients with manyassociated follow-up visits. We are currently planning further clinical validation andmuch closer integration to the departmental information system [5] for a routineuse of CARDIOTABS.

Acknowledgements

We thank Dr Domenico Zanuttini, head of the Division of Cardiology of theHospital of Pordenone, Drs Gian Luigi Nicolosi and Francesco Antonini Canterinfor their valuable help in focusing the relevant medical aspects of echocardiogra-phy. Eugenio Cervesato helped in the integration of this work with the clinicalinformation system. Roberta Cervesato had a main role in designing and imple-menting CARDIOTABS during her Master thesis.

References

[1] Aliferis CF, Cooper GF, Pollack ME, Buchanan BG, Wagner MM. Representing and DevelopingTemporally Abstracted Knowledge as Means towards Facilitating Time Modeling in MedicalDecision-Support Systems. Combi C, Shahar Y., editors. Special issue on time-oriented systems inMedicine, Comput. Biol. Med. 1997;27:411–434.


[2] Allen JF. Maintaining knowledge about temporal intervals. Comm ACM 1983;26:832–43.[3] Booch G. Object-oriented design with applications. Reedwood City: Benjamin-Cummings, 1994.[4] Cattell RGG. The Object Database Standard: ODMG 2.0. San Francisco: Morgan Kaufmann,

1997.[5] Cervesato E, Nicolosi GL, Zanuttini D. Computerized network organization design for clinical

patient data management of cardiology department, Computers in Cardiology 1990. Los Alamitos:IEEE Computer Society Press, 1991:625–8.

[6] Chittaro L, Del Rosso M, Dojat M. Modeling Medical Reasoning with the Event Calculus: anApplication to the Management of Mechanical Ventilation. In: Barahona P, Wyatt J, Stefanelli M,editors. Artificial Intelligence in Medicine 1995. Berlin: LNAI 934, Springer Verlag, 1995:79–90.

[7] Chittaro L, Montanari A, Peressi E. An Integrated Framework for Temporal Aggregation andOmission in the Event Calculus. In: Rzevsky G, Adey RA, Tasso C, editors. Applications ofArtificial Intelligence in Engineering X. Boston: Computational Mechanics, 1995:47–54.

[8] Chittaro L, Montanari A. Efficient Temporal Reasoning in the Cached Event Calculus’. ComputIntell 1996;12:359–82.

[9] Chittaro L, Combi C, Cervesato E, Cervesato R, Antonini-Canterin F, Nicolosi GL, Zanuttini D.Specifying and Representing Temporal Abstractions of Clinical Data, by a Query Language Basedon the Event Calculus, Computers in Cardiology 1997. Piscataway: IEEE Press, 1998:633–6.

[10] Chittaro L, Dojat M. Using a general theory of time and change in patient monitoring: experimentand evaluation, Combi C, Shahar Y, editors. Special issue on time-oriented systems in Medicine,Comput. Biol. Med. 1997;27:435–452.

[11] Clifford J, Tuzhilin A, editors. Recent Advances in Temporal Databases, London: Springer, 1995.[12] Combi C, Cucchi G, Pinciroli F. Applying Object-Oriented Technologies in Modeling and Querying

Temporally-Oriented Clinical Databases Dealing with Temporal Granularity and Indeterminacy.IEEE Trans Inform Technol Biomed 1997;1:100–27.

[13] Combi C, Shahar Y. Temporal reasoning and temporal data maintenance in medicine: issue andchallenges. Combi C, Shahar Y, editors. Special issue on time-oriented systems in Medicine,Comput. Biol. Med. 1997;27:353–368.

[14] Goralwalla IA, Ozsu MT, Szafron D. Modeling Medical Trials in Pharmacoeconomics Using aTemporal Object Model. Combi C, Shahar Y, editors. Special issue on time-oriented systems inMedicine, Comput. Biol. Med. 1997;27:369–388.

[15] Keravnou ET. Engineering time in medical knowledge-based systems through time-axes andtime-objects, in: Chittaro L, Goodwin S, Hamilton H, Montanari A, editors. Third Int. Workshopon Temporal Representation and Reasoning (TIME’96). Los Alamitos: IEEE Computer SocietyPress, 1996;160–167.

[16] Keravnou ET, Washbrook J. A Temporal Reasoning Framework Used in the Diagnosis of SkeletalDysplasias. Artif Intell Med 1990;2:239–65.

[17] Kowalski R, Sergot M. A logic-based Calculus of events. New Gener Comput 1986;4:67–95.[18] Larizza C, Bernuzzi G, Stefanelli M. A general framework for building patient monitoring systems.

In: Barahona P, Stefanelli M, Wyatt J, editors. Artificial Intelligence in Medicine 1995. Berlin:LNAI 934, Springer Verlag, 1995:91–102.

[19] Larizza C, Bellazzi R, Riva A. Temporal abstractions for diabetic patients management. In:Keravnou E, Garbay C, Baud R, Wyatt J, editors. Artificial Intelligence in Medicine Europe 1997.Berlin: LNAI 1211, Springer Verlag, 1997:319–30.

[20] Larizza C, Moglia A, Stefanelli M. M-HTP: A System for Monitoring Heart Transplant Patients.Artif Intell Med 1992;4:111–26.

[21] Navathe SB, Ahmed R. Temporal Extensions to the Relational Model and SQL, in [33], 92–109.[22] Rose E, Segev A. TOOA-A Temporal Object Oriented Algebra. Proc. Eur. Conf. on Object-Ori-

ented Programming. Berlin: LNCS 707, Springer Verlag, 1993; 297–325.[23] Schmidt D, Kotz Dittrich A, Dreyer W, Marti R. Time series, a neglected issue in temporal

database research?, in [11], 214–232.[24] Segev A, Shoshani A. A temporal data model based on time sequences, in [33], 248–269.[25] Shahar Y, Musen MA. Knowledge-based temporal abstraction in clinical domains. Keravnou ET,

editor. Special issue on temporal Reasoning in Medicine, Artif. Intell. Med. 1996;8:267–298.


[26] Shahar Y. A framework for knowledge-based temporal abstraction. Artif Intell 1997;90:79–133.[27] Snodgrass RT, Ahn I. Temporal Databases. IEEE Comput 1986;19:35–42.[28] Snodgrass RT. The temporal query language Tquel. ACM Trans Database Syst 1987;12:247–98.[29] Snodgrass RT. Temporal object-oriented databases: a critical comparison. In: Kim W, editor.

Modern database systems, the object model, interoperability, and beyond. Reading: AddisonWesley, 1995:386–408.

[30] Snodgrass RT, editor. The TSQL2 temporal query language. Boston: Kluwer Academic Publishers,1995.

[31] Su SYW, Chen HHM. Modeling and Management of temporal data in object-oriented knowledgebases. In: Proc. Int. Workshop on an Infrastructure for Temporal Databases, Arlington, TX 1993;HH-1–HH-17.

[32] Tansel AU, Arkun ME, Ozsoyoglu G. Time-by-Example Query Language for Historical Databases.IEEE Trans Softw Eng 1989;15:464–78.

[33] Tansel AU, Clifford J, Gadia S, Jajodia S, Segev A, Snodgrass RT. Temporal Databases. Theory,design and implementation. Redwood City: Benjamin-Cummings, 1993.

[34] Wuu GTJ, Dayal U. A uniform model from temporal and versioned object-oriented databases, in[33], 230–247.

abstraction on clinical data sequences: an object-oriented data model and a query language based on...

Documents