Representation of Medical Guidelines Using a Classification-Based System [original]

Representation of Medical Guidelines

Using aClassification-Based System

C, Heinlein] K. Kuhn2 P. Dadaml

lDept. Databases and Information Systems

2Dept. Internal Medicine

University of Ulm, D–89069 Ulm, Germany

{heinlein.dadam} @informatik.uni-ulm.de

kuhn-k@dulruu51 .bitnet

Abstract

MedicaJ guidelines play an increasing role in selecting diag-

nostic and therapeutic steps under the aspects of effective-

ness, invasiveness, and costs. To work directly on patient

data already available in electronic form, they should be in-

tegrated into amedical information system. In order to de-

velop a“medical guideline module” (M GM )managing and

applying guidelines to patients, a“knowledge level” repre-

sentation of guidelines is necessary which reflects the struc-

ture of medical knowledge and matches medical processes.

Furthermore, adirect transformation to the “symbol level”

is needed. We use anested, frame-like structure on the

knowledge level and show that aclassification-based knowl-

edge represent ation system (CBKRS) is principal ywell

suited for the symbol level. To facilitate the usage and to be

independent of aparticular CBKRS, we introduce an inter-

mediate level called “intelligent object system” (10 S). It is

developed by augmenting asimple data model for descri-

bing complex objects with prototypes and implications as a

means to classify objects and to draw inferences based on

this classification. Finally, the transformation of guidelines

to prototypes and implications is described.

1Introduction

Medicine of today is confronted with exploding costs, expo-

nentially growing knowledge, high specialization, and high

informational needs. Increasingly, medical guidelines are

used to select adequate diagnostic and therapeutic steps

under the aspects of effectiveness, invasiveness, and costs.

These guidelines are intended to bring recent scientific re-

sults from the literature and from expert physicians into

medical practice. For given medical problems of apatient,

they suggest necessary (“indicated”) steps, warn about side-

effects or contra-indications, and remind of preparatory

measures. To work directly on patient data already available

in electronic form, they should be integrated into amedical

information system. The consult ation style should be vari-

able from active guidance for unexperienced users to merely

issueing cert tin warnings for experienced physicians.

Permission to co ywithouf fee all or part of this material is

granted provided tat the copies are not made or distributed for

direct commercial advantage, the ACM copyright notice and the

title of the publication and its date appear, and notice is given

that copying is by permission of the Association of Computing

Machinery. To copy otherwise, or to republish, requires afee

and/or specific permission.

CIKM ’94- 11/94 Gaitherburg MD USA

@1994 ACM 0-89791 -874-3/94/001 1,.$3.50

In this paper we describe the design and prototypical im-

plementation of a“medical guideline module” (MGhf) for

managing and applying guidelines to patients, which is part

of amedical information system. Major challenges in devel-

oping this MGM have been:

●

finding an abstract (“knowledge level”) representation

of medical guidelines reflecting the typical structure

of medical information and knowledge; it should be

reusable, extensible, and naturally understood by ex-

pert physicians;

identifying essential (abstract )inference mechanisms

matching medical processes;

establishing adirect transformation to aconcrete

(“symbol l~vel” )representation.

Section 2describes the structure of medical guidelines and

an abstract representation by means of nested frames, as

well as the basic inferences necessary to apply guidelines

to patients. Section 3identifies these inferences as classifi-

cation problems naturally being solved by aclsssification-

based knowledge representation system (CBKRS). It also

identifies the essential CBKRS features needed by the MGM

and defines acorresponding functional interface called “in-

telligent object system” (10S) which abstracts from apar-

ticular CBKRS and provides asmall and uniform interface.

Section 4describes the transformation of abstract,

frame-structured guidelines to concrete “symbols” of the

10S and demonstrates their application to actual patients.

In section 5we will discuss related and future work.

2Abstract Representation and Inferences

Medical Guidelines

The complexity and general structure of the medical guide-

lines we consider can be illustrated with the following exam-

ple. Aspecific cause for the common disease arterial hyper-

tension (elevated arterial blood pressure) can be identified in

asmall minority of patients only, but apatient may be cured

if this cause is detected. To rule out an endocrine disease as

one of these causes, aseries of diagnostic steps should be per-

formed. Typically, results determine subsequent steps, and

it would be uneconomic or too invasive to perform all tests

at atime. So, basically, only potassium and creatinine will

be determined from ablood sample, and an ultrasonography

examination of the kidney region will be performed. If e.g.

hypokalemia (decreased potassium in the patient’s blood) is

415

found, the suspicion of primary aldosteronism (which can be

caused by atumor of the suprarenal gland) will be risen, and

the aldosterol and renin serum/plasma levels should be de-

termined. Next steps—again depending on the outcomes—

may follow and finally lead to asurgical intervention.

This example is translated into the frame-like structure

shown in figure 1in astraight-forward and natural way.

The essential parts of aframe are conjunctive conditions

(disjunction and negation will be discussed in section 5),

and steps indicated when the conditions are satisfied. Ad-

ditional slots, such as ashort explanation of the steps or

references to literature explaining in more detail the indi-

cation, might be included. Frames can be nested in order

to represent acontext binding implicit in many guidelines.

For example, from the condition “potassium <3.5” the step

“test of aldosterol and renin” is derived only in the context

of the problem “arterial hypertension.” The introduction of

subframes inheriting the conditions of their superframes is

anatural way to represent this context binding.

Formally, conditions and steps consist of akeyword (e.g.

probiem, reszdt, or ezarn) followed by a one or more terms

taken from acontrolled vocabulary. The keyword deter-

mines the interpretation of the following terms, e.g. “prob-

lem x“ means “patient has problem x,” while “esmm x y ...”

means “examination xwith parameters/questions y...is in-

dicated.”

The construction of acontrolled medical vocabulary is

discussed extensively in the literature [1, 2, 3], and sev-

eral important requirements have been identified [4]. The

most important property in our context is “multiple clas-

sification,” allowing aterm to specialize one or more other

terms. Figure 2shows an excerpt of an “ad hoc” term hi-

erarchy which has been sufficient for building the MGM

Cond.: problem art-hyp

Step: ezam lab-exam potassium creatmine

Step: exam ultrasonography . . .

Expl.: basic diagnostic for arterial hypertension

Cond.: result lab-exam potassium <3.5

Step: exam lab-exam aldo renin

Expl.: rule out aldosteronism

II II

Cond.: result lab-exam aldo increased

Cond.: result lab-exam renin decreased

Step: prob/em prim-aldost

Cond.: result lab-exam creatinine >120

Step: e.mrn lab-exam crea-clearance . .

Expl.: renal hypertension?

Figure 1: Guideline frame “arterial hypertension”

(see figure 2for an explanation of terms)

proto~ype. In the long run, however, we

place it by an existing, more sophisticated

intend to re-

approach.

term

root of the

problero

~te.bi erarch~ Parm

exam

medical

,, examination psrameterJ

/\ “

problem

question

art -hyp prim-aldost rad-exam lab-exam lab-param

art erial primary radiological laboratory laboratory

hypertension aldost eronism examination examination mmsrnet er

/\ /- \

Ct cro-exam potassium

computer

/ /

renin

contrast medium

tomography (CT) examination potassiwm renin

crest inine aldo

creatinine aldosterol

cm-ct crea-clearance

CT with creatinine

contrast medium clearance

Figure 2: Term hierarchy (links represent specialization)

416

~ond.: is-ordered cm-exam

itep: exam lab-exam creatinine

IXpl.: prerequisite for CM examination

Cond.: result lab-exam creatinine >120

Step: ezam lab-exam crea-clearance

Expl.: prerequisite for CM examination

Cond.: result lab-exam crea-clearance <50

Step: warnzng limited renal function

Figure 3: Guideline frame “contrast medium examination”

Figure 3shows an example of aguideline frame mak-

ing explicit use of this specialization hierarchy. It describes

preparations for aradiological examination with application

of contrast medium (CM), which may lead to awarning be-

cause of limited renal function. As its condition refers to the

general term cm-exam, it is also satisfied when amore spe-

cialized examination such as cm-ct has been ordered, and

thus need not be reformulated for all these examinations. It

might be called areusable “library” frame.

Patients

Facts about patients might be stored in several different

databases of the medical information system. In order to

apply guidelines to apatient, his facts must be made avail-

able to the MGM in apredefine structure. For that pur-

pose, they are grouped together in acomplex object partially

shown in figure 4. Arrows denote relationships or roles which

are viewed as set-valued functions with names derived from

their domain and range (e. g. patient–>exam). The rela-

tionship patient–>problem is used to store medical prob-

lems, while results of examinations are represented as val-

ues (param– >value) of parameters/questions (exam–>

param) of the patient’s examinations (patient–>exam).

Given that representation, conditions of frames can be in-

terpreted more formally than above, e.g. problem art-hyp

means that the patient object under consideration has a

patient–>problem role filler of type art-hyp, while re-

sult lab-exam potassium <3.5 means that it has a

patient–>exam role filler of type lab-exam having itself

an exam–>param role filler of type potassium with a

param–>value role filler that is lower than 3.5.

The same relationships as well as additional ones such

as patient–>remark will be used by the MGM to store

derived facts about the patient, as described below.

Inferences

In order to apply guidelines to agiven patient, the MGM

must determine all frames with conditions satisfied by this

patient’s facts. The corresponding steps, which may be in-

dicated examinations including parameters/questions, con-

cluded medical problems, or warnings to be issued, must

be added to the patient object using the appropriate rela-

tionships (e. g. patient–>remark for warnings, reminders

etc.). Because this process may lead to further satisfied con-

ditions, it must be repeated until a“fixed point” is reached,

patient

/l\

problem exam remark

param

value

Figure 4: Complex object “patient”

i. e. no further conditions become satisfied. Every time the

patient object is changed, i.e. facts about the patient are

added or removed (the latter might happen when amedical

problem has been solved), the MGM must recompute (or

update accordingly) the derived facts.

Asecond kind of inferences is needed to answer questions

like “Is aparticular examination indicated at the moment ?’s

or “Under which circumstances is it indicated?” Because

the MGM is intended to operate with incomplete knowledge

(guidelines as well as facts about patients may be incom-

plete), the first question is principally undecidable (the ex-

amination might well be indicated without the MGM know-

ing about it). The second question. however, can be an-

swered at least partialiy by determining all frames contain-

ing this examination as astep, and returning their condi-

tions. If apatient satisfies asignificant part of these con-

ditions (defined precisely by the application), ahint might

be issued: “If the patient would additionally satisfy condi-

tion . . . . the examination would be indicated for him.”

3Technical Foundation

Finding all frames with conditions satisfied by apatient’s

facts can be seen as aclassification problem. Each frame

defines the class of patients satisfying its conditions, and

patients have to be classified according to their facts. Be-

cause subframes inherit the conditions of their superframes.

the class of patients defined by asubframe is asubclass (i. e,

asubset) of the classes defined by its superframes. There-

fore, each complex frame (i. e. top-level frame including its

direct and indirect subframes) induces acorresponding class

hierarchy.

Classification-based knowledge representation systems

(CBKRSS) provide alanguage consisting of concept forming

operators as ameans to describe such class hierarchies, and

aspecialized reasoner, the class~jier, which automatically

identifies all classes an object belongs to [5]. Typical concept

forming operators are conjunction, stating that an object be-

longs to class Ciff it belongs to classes Cl, ....Cn, and sev-

eral kinds of number and vaiue restrzcttons, stating that an

object belongs to class C, iff all or at least/at most kfillers

of one of its roles belong to aclass C’. Furthermore, these

systems usually allow some kind of implications or forward-

chaining rules to be associated with aclass, stating that an

object of class Calso belongs to class D. If the definition

of Dprescribes concrete role fillers for its instances (which

417

might be considered aspecial kind of value restriction). these

rules can be used to automatically add additional role fillers

to objects matching class C. These derived role fillers are

truth-maintained, i. e. they are retracted again. if the object

no longer satisfies the conditions of class C. This combi-

nation of classification, forward-chaining rules, and truth

maintenance is exactly what is needed in order to provide

the first kind of inferences described above. (The second

kind will come as aby-product at the end of section 4.)

Atypical CBKRS provides alarge set of functions, oper-

ators, etc. [6, 7], many of which are rarely needed by an ap-

plication. Sometimes there exist several different functions

for similar purposes, leading to alarge and unwieldy inter-

face. Furthermore, different CBKRSS provide quite different

interfaces for the same or similar features, causing serious

portability problems [8]. Therefore it is reasonable to intro-

duce an intermediate layer which abstracts from aparticu-

lar CBKRS, concentrates on the essential features needed,

and provides asmalf and uniform interface for them. In

the remainder of this section, an intermediate layer of this

kind will be developed step by step. After defining adata

model for describing complex objects, prototypical mdividu-

ais and wrzphcattorzs wilf be introduced as ameans to classify

objects and to draw inferences based on this classification.

Afterwards we will briefly sketch the implementation of this

layer called “intelligent object system” (10 S). and describe

in more detail the CBKRS features it requires. In section 4,

the 10S wiIl be used aa a platform to implement the MGM.

Terms, Types, and Relationships

Acontrolled vocabulary constitutes the basis of every

knowledge-based system. In order to build term hierarchies

as the one shown in fimre 2, we postulate afunction term

taking aa arguments aterm to

set of superterms it specializes,

(term exam)

(term rad-exam exam)

(term ct rad-exarrd

(term cm-exam rad-exam)

(term cm-ct ct cm-exam)

b; defined and optionally a

for example:l

On the one hand, aterm is aword, i. e. an element of a

vocabulary, while on the other hand it is atype representing

aclass of real-world objects. In order to build complex ob-

jects like the one shown in figure 4, the function relation

is introduced, taking as arguments domain and range of a

relationship. For example:

(relation

Individuals

patient problem)

patient exam)

exam param)

parem value)

patient remark)

For each type, there exists apredefined individual with the

same name as the type. Furthermore, the name of atype

can be used as afunction (“type function”) to create anew

individual of that type. Initial role fillers may be specified

as asequence of relationship–individual pairs, e. g.:

(patient patient->problem art-hyp)

lS1nce almost every CBKRS 1s based on Lisp, It was anatural

decmon to implement the 10S ]n LMp, too

This creates anew patient individual with thepatient–>

problem relationship filled by the predefine individual

art-hyp. Because initial role fillers can be created in the

same way, acomplex individual can be created with asingle

expression resembling the conceptual graph notation of [9]:

(patient

patient->problem art-hyp

patient->exam

(lab-exam exam->param

(potassium param-%alue 3.2)

)

This creates apatient individual with the problem arter-

ial hypertension and a laboratory finding of potassium with

value 3.2.

The function current, taking as argument atype, re-

turns the “current” instance of that type, i.e. the last indi-

vidual created of that type. The name of arelationship can

be used as afunction (“relationship function”) to establish

that relationship between two individuals. This allows the

same individual to be built incrementally:

(patient)

(patient->problern (current patient.) art-hyp)

(patient->exam (current patient) (lab-exam))

(exam->param (current lab-exam) (potassium))

(param->value (current potassium) 3.2)

Arelationship function can also be used to retract role fillers

and to query the current set of role fillers for agivenindivid-

ual as in the following example, where all medical problems

of the current patient are returned:

(patient->problern (current patient))

Prototypes

On the one hand, the individual created above might de-

scribe asingle patient of the real world having the problem

arterial hypertension and a potaasium value of 3.2. On the

other hand it may be viewed as adescription of the class of

all patients having this problem and this potassium value.

If it is used in the latter way, it is called aprototypica/ in-

dwdualora prototype,and every element of the class being

described by it is said to match that prototype. In order

to allow formore general class descriptions, prototypes may

have symbolic role fillers like (< 3.5) or(> 120) to describe

ranges of values instead of concrete numericaf values.

Formally, matching aprototype is defined as follows:

●Atypeis called asubtypeof another type, ifboth types

are equal, or ifthe formeris defined as aspecialization

of the latter.

●Anumerical value is said to match arange, if it is an

element of that range.

●An individual is said to match aprototype, if the in-

dividual’s type is asubtype of the prototype’s type,

and for each role filfer of the prototype, there exists a

rnatchtng role filler of the individual.

Thelastpart of the definition hasto be recursively applied, if

role fillers arethemselves individuals or prototypes. Roughly

speaking, these definitions say that aprototype describes

the class of all individuals being at least as specialized as

the prototype itself.

418

Because prototypes describe classes of individuals, they

can be used as query expressions. The function all returns

the set of all individuals matching agiven prototype, e.g.

(all (patient patient-jproblem art-hyp) )

This returns all patients with the problem arterial hyper-

tension.

The function copy creates an exact copy of aprototype

(oran arbitrary individual). Thisisuseful forcreating%ub-

prototypes,” because after adding additional role fillers to

the copy, it cau be used as aprototype describing asubset

of the class described by the original prototype.

Implications

In order to build an intelligent object system, reintroduce

implications of the form: “Aslong as an individual matches

prototype A, it is guaranteed to also match prototype B.”

Inorder to satisfy this “guarantee,” an individual matching

prototype Amust automatically receive role fillers match-

ing the role fillers of Bin addition to its original role fillers.

(This is most easily accomplished by receiving exactly the

role fillers of B.) As the term “as long as” indicates, these

additional role fillers must be retracted again, if the individ-

ual does no longer match prototype A.

The function implication taking asarguments two pro-

totypes, is used to define such an implication, e.g.

(inrplication

(patient.patient-jproblem art-hyp)

(patient

patient->exam

(lab-exam

exsm->param potassium

exam->parsm creatinine

)

This guarantees that every patient having problem art-hyp

automatically receives apatient–>exam role filler of type

lab-exam having exam–>param role fillers with types

potassium and creatinine.

Implementationof thelOS

Terms, relationships, and individuals (including prototypes)

are naturally mapped to prirnihue concepts, relations and

instances of aCBKRS, respectively. In order to build term

hierarchies, con~unction of primitive concepts is needed.

The first argument toimplication isconvertedtoa de-

fined concept describing exactly the set of individuals match-

ing this prototype. The concept forming operators needed

here, are conjunction and qualifying existential restriction

(stating that an individual must have atlea..st onerolefdler

of type C’ in order to be a member of class C) as well

as ameans to describe numerical ranges. In the syntax

of Loom [6], which has been used for the prototypical im-

plementation, the patient individual shown above would be

converted to:

(defconcept ... :is

(:and patient

(:sorne patient->problem art-hyp)

(!*.=. pati.nt–~.xam

(:and lab-exam

(:some exam->param

(:and potassium

(= param->value 3.2)))))))

The second argument toimplication is converted to acon-

cept definition prescribing concrete role fillers for its in-

stances, for example:

(defconcept ... :is

(:and patient

(:filled-by patient->pr-oblern prim-aldost)))

The implication itselfis mapped to an zrnpticattonor rule

of the CBKRS with the first concept as antecedent and the

second as consequent.

Aprototype passed to all might be converted to ade-

fined concept in the same way as the first argument to im-

plication, and afterwards the CBKRS can be queried for

all individuals matching that concept. If the CBKRS al-

lows for more complex queries, however, the prototype can

be converted directly to an equivalent query expression, and

no “auxiliary” concept definition is needed.

4The Medical Guideline Module

Transformation of Frames to Prototypes and impli-

cations

A“guideline base” is aset of frame-structured guidelines as

described in section 2. In order to make them applicable to

actual patients, they are transformed to prototypes and im-

plications of the 10S, i.e. eventually to concepts and rules

of the underlying CBKRS. For each frame, two prototypical

patients are created—one to represent the conditions, and

the other to represent the steps of the frame. Because the

“condition prototype” must be matched by aUpatients satis-

fying the conditions of the frame, each condition is converted

to a“prototypical” role filler. For example, the condition

problem art-hyp is transformedto apatient–>problem

role filler of type art-hyp, while result lab-exam potas-

sium <3.5 produces apatient–>exam role filler oftype

lab-exam having itself an exam-> param role filler of type

potassium with aparan->valueof (< 3.5). In the same

way, steps are transformed to role fillers of the “step proto-

type.” This transformation—which depends heavily on the

structure of the complex patient object (figure 4) as well

as the internal structure of conditions and steps—is done

by aseparate “parsing function.” If new keywords shall be

introduced for conditions or steps, this is the only function

needed to be modified.

After these transformations, an implication is declared

between the two prototypes. According to the definition of

an implication in the 10S, this guarantees that each patient

matching the condition prototype, i.e. satisfying the condi-

tions of the frame, also matches the step prototype, i.e. has

the steps of the frame as derived role fillers.

In order to make asubframe inherit the conditions of its

superframes, its condition prototype is created as acopy of

its parent’s condition prototype and augmented with role

fillers corresponding to its own conditions.

Suggesting Indicated Steps

In order to apply aguideline base to agiven patient, apa-

tient individual is created and filled with all facts available

about the patient in the information system. The implica-

tions mentioned above cause all indicated steps to be auto-

matically added to the individual. From the CBKRS’S point

ofview, theclassifier determines all concepts matched by the

individual and applies the associated rules. Whenever the

individual is changed, it is reclassified and its derived role

419

fillers are updated accordingly. Therefore, an application

can obtain the indicated steps at any time by querying the

role fillers of the individual, e.g. patient–>exam to get in-

dicated examinations, patient–>remark to get reminders

and warnings, and so on.

In order to demonstrate this behavior in more detail,

we will briefly sketch an interactive “test session” with the

MGM. After loading the CBKRS, 10S, and MGM code,

as well as asample knowledge base containing the frames

described here, into aLisp system, anew, “empty,” patient

individual is created which is afterwards accessible as the

“current” patient:

J(pat lent)

In order to tell the system that this patient suffers from

arterial hypertension, acorresponding patient–>problem

role filler is added:

>(patient->problem (current patient) art-hyp)

After this “assertion, ”the system recognizes the patient to

satisfy the top-level condition of the frame in figure 1, and

therefore adds the corresponding steps asderived role fillers.

This may be verified by querying the patient–>exam role

fiUers:

>(pat ient-zexam (current patient))

(lab-exam--1 ultrasOnogr._aphy --l)

Querying the exam-> param role fillers of lab-exam--l

yields:

>(exam->param lab-exam--l)

(potassium-- 1creatinine--l)

In order to inspect acomplex object more conveniently, the

function show can be used to show apiece of code which

would exactly reproduce the given individual:

>(show (current patient))

(pat ient

patient->problem (art-hyp)

patient->exam

(lab-exam

exam->parara (potassium)

exam->param (creatinine)

)

patient->exam

(ultrasonography ...)

)

An application-specific function suggest may take thede-

rived patient–>exam role fillers (i.e. the indicated exami-

nations), filter out those which have already been carried

out, and expand the “cryptic” terms into more readable

texts. If we assume that no examinations have been per-

formed yet, it would yield:

(suggest (current patient))

laboratory examination

(basic diagnostic for arterial hypertension)

-potassium

-creatinine

ultrasonography

(basic diagnostic for arterial hypertension)

. . .

After having performed the suggested laboratory tests, their

results are entered by augmenting the patient individual

with acorresponding patient–>exam role filler:

>(patient->exam (current patient)

(lab-exam

exam->param (potassium param->value 3.2)

exam->param (creatinine param->value 110)

According to the guideline in figure 1, potassium is de-

creased (< 3.5) while creatinine has anormal value. There-

fore, the condition of the first inner frame is satisfied, lead-

ing to the suggestion of alaboratory test of aldosterol and

renin. Since the above ultrasonography has not been per-

formed yet, it is suggested again:

(suggest (current patient))

ultrasonography

(basic diagnostic for arterial hypertension)

...

laboratory examination

(rule out aldosteronism)

-aldosterol

-renin

This “dialog” ofentering newresults andasking for the next

indicated steps may be continued that way.

In order to test the system’s behavior in case of retrac-

tions, too, one might remove the problem art-hyp now.

Then, the patient no longer satisfies the top-level condition

offigure 1nor the conditions of any subordinate frames since

they inherit this top-level condition. Therefore, all derived

role fillers will be retracted, causing the output of suggest

to become empty. The only remaining role filler of the cur-

rent patient is the laboratory examination which has been

explicitly asserted:

>(patient->problem (current patient)

:retract art-hyp)

>(show (current patient))

(patient

patient->exam

(lab-exam

exam->param (potassium param->value 3.2)

exam->param (creatinine param-%alue 110)

)

Finding Preconditions ofaStep

Because each prototype matches itself, the implication asso-

ciated with acondition prototype is applied to the prototype

itself as well, i.e. each condition prototype receives the role

fillers of the corresponding step prototype as derived facts.

This can be employed to determine the preconditions of a

particular step by looking for all condition prototypes con-

taining that step, because their original role fillers constitute

exactly these preconditions.

In principal, all can be used to obtain all individual~

containing that step, and afterwards relationship functions

like patient–>problem can be used to obtain their role

fillers. Two problems remain, however: all is unable todis-

tinguish condition prototypes from other individuals, and

the relationship functions cannot distinguish between origi-

nal and derived role fillers. In order to fix these problems, we

augment the 10S with two simple partitioning mechanisms

which might be useful for other purposes as well. First, type

functions such as patient as well as the query function all

accept an optional argument specifying apartztmnin which

individuals are created or searched, respectively. This can

420

be used to create condition prototypes in aseparate par-

tition, thus circumventing the first problem. Second, the

relationship functions accept an optional argument specify-

ing which kind of role fillers to query: original, derived, or

both.

Since aCBKRS internally distinguishes between origi-

nal and derived facts anyway, the second extension comes

almost for free. If multiple partitions of individuals are not

directly supported, an 10S internal relationship represent-

ing the partition an individual belongs to, can be used to

simulate it.

5Discussion

We have built amedical guideline module on top of a

classification-based knowledge representation system. The

combination of classification, forward-chaining rules, and

truth maintenance of derived facts provides apowerful plat-

form for building knowledge-based systems rather quickly.

Several authors describe the advantages of using asemanti-

cally well defined terminology as a“backbone” of an intel-

ligent system, which is usually augmented with production

rules as an inferential component [1 O, 11, 12]. Because we

do not use production rules which cannot be undone once

having “fired,” but truth-maintained implications, the situ-

ation is even better: rules (i. e. frames in our context) can be

formulated in acompletely declarative way, without needing

to have any strategy for execution or conflict resolution in

mind. Indeed, rules are not executed in aprocedural way,

but instead the set of all facts derivable via rules is main-

tained by the CBKRS. It remains to be evaluated, though,

how these powerful mechanisms affect system performance.

In [13], asemantic data model is described which ex-

tends the CBKRS languages FL–, KANDOR, and BACK.

It provides asingle, homogeneous language for defining ob-

jects, queries, and views, instead of different languages for

data definition and manipulation. Similarly, the CLASSIC

system [7] provides identical language constructs for defin-

ing concepts and individuals. We follow this approach in

the design of the intelligent object system. The same func-

tions/language constructs needed to create (complex) indi-

viduals are used to describe queries, classes, and implica-

tions. This principle of “re-using” the same constructs for

several purposes, combined with the careful selection of the

essential CBKRS features needed, has led to an interface

consisting of less than ten simple functions. Furthermore,

since individuals can be constructed incrementally, query

expressions and class descriptions may also be built step by

step, which is sometimes more convenient than generating

one complex description as awhole.

The idea of “blending classes and instances” in order

to simplify language design and usage is also described for

the prototype-baaed object-oriented programming languages

Self [14, 15] and Omega [16].

The definition of matching aprototype, given in sec-

tion 3, is based only on conjunction and qualifying existen-

tial restriction. More general value and number restrictions

have not been necessary so far, but they may be added if an

a.pphcatkm-specific need has been identified. We have ex-

cluded negation and disjunction so far, because they make

things more difficult and thus are omitted from most avail-

able CBKRSS. The authors of [17] tell some simple “tricks

of the trade” to achieve alimited form of negation, how-

ever, which is sufficient in our context: instead of saying

e. g. (not (potassium <3.5)) or (not (ultrasonography

normal) )we say (potassium >= 3.5) or (ultrasonog-

raphy pathological), and so on. In order to deal with

disjunction, we add the following “trick:” if an individual

belongs to claas C, if it belongs to class Aor 1?, this can be

modeled with the implications A+Cand B+C’.

Because CBKRSS as well as the 10S are application-

independent tools providing generic language constructs, it

is not surprising that knowledge representation using solely

these constructs is more like an “encoding” dealing with

“symbols” like concepts, relations, or prototypes, than an

abstract description of knowledge concentrating on the es-

sential content. Usually, afew syntactic templates have to

be repeated again and again (cf. sample knowledge bases

provided with some CBKRSS; one of them is described

in [17]). Therefore, we vote for an application-specific

“knowledge level” representation which is at the same time

“natural” enough to be understood by domain experts and

formal enough to be “understood” by asoftware module

translating it to the symbol level. We have chosen nested

frames for describing medical guidelines for the following

reaaons. First, the extensible slot structure of frames repre-

sents suite naturallv the structure of manv “units of knowl-

edge” including rules. In this respect, our approach is sim-

ilar to the Arden Syntax [18] which has been suggested as

astandard representation for medical knowledge. Its “med-

ical logic modules” (MLMs) are essentially frame-structured

rules, augmented with slots for maintenance, citations, etc.

In order to be easily sharable, MLMs are demanded to be

independent of each other, which means that their condi-

tions must be compiete. While this makes sense for simple,

“single-stage” units of knowledge being semantically inde-

pendent, it leads to unnatural and unwieldy formulations in

the area of “multi-stage” guidelines since many conditions

have to be reueated in order to achieve the context bind-

ing described in section 2. Therefore, we allow frames to

be nested, i.e. conditions to be complete only in their well-

defined context. This does not sacrifice sharability, though,

but changes the granularity of sharable nnits of knowledge

from single rules to complete complex frames.

Due its inherently forward-chaining mode of opera-

tion [5], aCBKRS needs all facts about an individual in

advance in order to find the most specific concepts it be-

longs to. The classifier does not “intelligently” ask for ad-

ditional facts which could “improve” the classification. As

long as the MGM is used as an experimental prototype sub-

ject to changes and improvements, acomplete replication

of patient-specific facts in the CBKRS is acceptable. For

routine use, however, where the MGM must deal with many

patients at the same time, this may lead to memory prob-

lems, since aCBKRS usually keeps all knowledge in main

memory. In addition, consistency and reliability problems

can result. Since not all uatient-sDecific facts available in the

information system are relevant for the application of guide-

lines, amore “intelligent” coupling between the information

system and the MGM is desirable.

Actiue values [10] can be employed to automatically

query relevant facts on demand, but since few CBKRSS sup-

port them, we intend to investigate an alternative approach

which might be called “incremental” classification: Initially,

only afew “essential” facts (e. g. medical problems) are used

to cLassify apatient, and the result is exploited to selec-

tively ask the information system for additional facts. In

the long run, it might even be worthwile to implement the

10S directly on top of adatabase system without using a

421

CBKRS at all, in order to avoid the memory and consistency

problems mentioned above. To remain open for this possi-

bility has been another motivation for defining aCBKRS-

independent intermediate layer which is as small and simple

as possible.

Acknowledgement

We want to thank G. Adler for his support, B. Bohm for pro-

viding the example, and B. Nebel, D. Rosner, and T. Beuter

for their discussions on an earlier version of this paper.

This work is part of the research project “Open Clincial

Database and Information System for the Integration of Au-

tonomous Subsystems” (OKIS), which is supported by the

State of Baden-Wiirttemberg, Germany.

References

[1]

[2]

[3]

[4]

[5]

[6]

[7]

C. A. Goble, A. J. Glowinski, W. A. Nowlan, A. L.

Rector. “A Descriptive Semantic Formalism for Medi-

cine” in Proc. 9th International Conference on Data

Engineering. IEEE Computer Society Press, April 1993,

624–631.

K. E. Campbell, M. A. Musen. “Representation of Clin-

ical Data Using SNOMED III and Conceptual Graphs”

in Proc. 16th Annual Symposium on Computer Applica-

tions in Medical Care. M. E. Frisse (cd.), McGraw-Hill,

November 1992, 354-358.

R. H. Baud, A.-M. Rassinoux, J.-R. Scherrer. “NaturaJ

Language Processing and Semantical Representation of

Medical Texts” Methods of Information in Medtc:ne 31

(2) June 1992, 117-125.

J. J. Cimino, G. Hripcsak, S. B. Johnson, P. D. Clay-

ton. “Designing an Introspective, Multipurpose, Con-

trolled Medical Vocabulary” in Proc. I%h Annual Sym-

posium on Computer Appltcatzons en Medical Care.

L. C. Kingsland (cd.), IEEE Computer Society Press,

November 1989, 513-518.

R. MacGregor. “The Evolving Technology of

Classification-Based Knowledge Representation Sys-

tems” in Prmcaples of Semantic Networks. Explorations

in the Representation of Knowledge. J. F. Sowa (cd.),

Morgan Kaufmann Publishers, 1991, 385-400.

D. Brill. Loom Reference Manual (Version 2.0). Infor-

mation Sciences Institute, University of Southern Cali-

fornia, December 1993.

L. A. Resnick, A. Borgida, R. J. Brachman, D. L.

McGuinness, P. F. Patel-Schneider, K. C, Zalondek.

CLASSIC Descrtptaon and Reference Manual for the

COMMON LISP Implementation (Verston 2.1). AT&T

Bell Laboratories. Murray Hill, NJ, May 1993.

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

J. Heinsohn, D. Kudenko, B. Nebel, H.-J. Profitlich.

.4n Empzr2cal Anal~sas of Termznologzcal Representa-

hors Systems. RR-92-1 6, German Research Center for

Artificial Intelligence (D FKI), Saarbriicken, Germany,

1992.

J. F. Sowa. Conceptual Structures. Information

Processing zn Mind and Machzne. Addison-Wesley,

1984.

R. Fikes, T. Kehler. “The Role of Frame-Based Repre-

sentation in Reasoning” Communtcatzon.s of the ACM

28 (9) September 1985, 904-920.

W. Swartout, R. Neches. “The Shifting Terminological

Space: An Impediment to Evolvability” in Proc. Na-

tzonal Conference on Artificial Intelligence. American

Association for Artificial Intelligence, 1986, 936-941.

J. Yen, R. Neches, R. MacGregor. “CLASP: Integrating

Term Subsumption Systems and Production Systems”

IEEE Transact~ons on Knowledge and Data Engtneer-

nzg 3(1) March 1991, 25–32.

H. W. Beck, S. K. Gala, S. B. Navathe. “Classification

as aQuery Processing Technique in the CANDIDE Se-

mantic Data Model” in Proc. 5th International Corzfer-

ence on Data Engineering. February 1989, 572–581.

D. Ungar, R. B. Smith. “Self The Power of Simplicity”

in 00PSLA ’87 Conference Proceedings, N. Meyrowitz

(cd.), October 1987, 227-242.

C. Chambers, D. Ungar, E. Lee. “An Efficient Im-

plementation of Self, aDynamically-Typed Object-

Oriented Language Based on Prototypes” in 00PSLA

’89 Conference Proceedings, N. Meyrowitz (cd.), Octo-

ber 1989, 49-70.

G. Blaschek. “Type-Safe Object-Oriented Program-

ming with Prototypes. The Concepts of Omega” Struct-

ured Programming 12 (4) 1991, 217–225.

R. J. Brachman, D. L. McGuinness, P. F. Patel-

Schneider, L. A. Resnick. “Living with CLASSIC:

When and How to Use aKL-ONE-Like Language” in

Pranctples of Semantic Networks. Explorations an the

Representation of I(nowledge. J. F. Sowa (cd.), Morgan

Kaufmann Publishers, 1991, 401-456.

G. Hripcsak, P. D. Clayton, T. A. Pryor, P. Haug, O. B.

Wigertz, J. Van der Lei. “The Arden Syntax for Medical

Logic Modules” in Proc. Ilth Annual Sympostum on

Computer Applications zn Medical Care. R. A. Miller

(cd.), IEEE Computer Society Press, November 1990,

200-204.

422