The Asgaard project: a task-specific framework for the application and critiquing of time-oriented clinical guidelines

Artificial Intelligence in Medicine 14 (1998) 29–51

The Asgaard project: a task-specific framework forthe application and critiquing of time-oriented

clinical guidelines

Yuval Shahar a,*, Silvia Miksch b, Peter Johnson c

a Section on Medical Informatics, 251 Campus Dri6e, Medical School Office Building, x215,Stanford Uni6ersity, Stanford, CA 94305-5479, USA

b Vienna Uni6ersity of Technology, Institute of Software Technology, Resselgasse 3/E188,A-10140 Vienna, Austria

c The Sowerby Centre for Primary Care Informatics, Uni6ersity of Newcastle, Newcastle upon Tyne,NE2 4AA, UK

Abstract

Clinical guidelines can be viewed as generic skeletal-plan schemata that represent clinicalprocedural knowledge and that are instantiated and refined dynamically by care providersover significant time periods. In the Asgaard project, we are investigating a set of tasks thatsupport the application of clinical guidelines by a care provider other than the guideline’sdesigner. We are focusing on the application of the guideline, recognition of care providers’intentions from their actions, and critique of care providers’ actions given the guideline andthe patient’s medical record. We are developing methods that perform these tasks in multipleclinical domains, given an instance of a properly represented clinical guideline and anelectronic medical patient record. In this paper, we point out the precise domain-specificknowledge required by each method, such as the explicit intentions of the guideline designer(represented as temporal patterns to be achieved or avoided). We present a machine-readablelanguage, called Asbru, to represent and to annotate guidelines based on the task-specificontology. We also introduce an automated tool for the acquisition of clinical guidelinesbased on the same ontology, developed using the PROTEGE-II framework. © 1998 ElsevierScience B.V. All rights reserved.

* Corresponduing author. Tel.: +1 650 7253393; fax: +1 650 7257944; e-mail:[email protected]

0933-3657/98/$19.00 © 1998 Elsevier Science B.V. All rights reserved.

PII S0933-3657(98)00015-3

Y. Shahar et al. / Artificial Intelligence in Medicine 14 (1998) 29–5130

Keywords: Knowledge representation; Knowledge acquisition; Planning; Temporal reason-ing; Clinical guidelines; Critiquing; Plan recognition

1. Clinical guidelines

Clinical guidelines are a set of schematic plans for the management of patientswho have a particular clinical condition (e.g. insulin-dependent diabetes). Theapplication of clinical guidelines by care providers involves collecting and interpret-ing considerable amounts of data over time, applying standard therapeutic ordiagnostic plans in an episodic fashion, and revising those plans when necessary.Guidelines often involve implicit assumptions about the knowledge of the providerexecuting the plans. Skeletal plans are plan schemata at various levels of detail thatcapture the essence of a procedure, but leave room for execution-time flexibility inthe achievement of particular goals [6]. Thus, they are usually reusable in differentcontexts. Clinical guidelines can be viewed as reusable skeletal plans that need to berefined by a reactive planner over significant time periods when applied to aparticular patient [23].

1.1. Automated support to guideline-based care

During the past 15 years, there have been several efforts to support guideline-based care over time in an automated fashion. Examples of specialized architecturesinclude ONCOCIN [23], T-HELPER [13], DILEMMA [9], EON [14], and theEuropean PRESTIGE project. Other approaches to the task of supporting guide-line-based care encode guidelines as elementary state-transition tables or as situa-tion-action rules dependent on the electronic medical record [21]. However, they donot include an intuitive representation of the guideline’s clinical logic, and have nosemantics for the different types of clinical knowledge represented. Several ap-proaches permit hypertext browsing of guidelines via the World Wide Web [1] butdo not use the patient’s electronic medical record.

None of the current guideline-based-care systems have a sharable representationof guidelines that: (1) has knowledge roles specific to the several guideline-based-care tasks; (2) are machine and human readable, and (3) allow data stored in anelectronic patient record to invoke an application that directly executes the guideli-ne’s logic and related tasks, such as critiquing. A task-specific human- andmachine-readable representation of clinical guidelines, that has an expressive syntaxand semantics, combined with the ability to interpret that representation inautomated fashion, would facilitate guideline dissemination, real-time accessibility,and applicability. Task-specific architectures [5] assign problem-solving roles todomain knowledge and facilitate acquisition and maintenance of that knowledge.Such a representation would also support additional reasoning tasks, such asautomated critiquing, quality assurance [8], and guideline evaluation, and wouldfacilitate authoring and modifying clinical guidelines.

Y. Shahar et al. / Artificial Intelligence in Medicine 14 (1998) 29–51 31

1.2. Support to application of clinical guidelines as an interacti6e process

The application of guidelines involves an interpretation by the care provider ofskeletal plans that have been designed by the guideline’s author. Providing automatedsupport implies an interactive process. Typical tasks include the assessment applicabil-ity of the guideline to the patient, guidance in proper application of a selectedguideline, monitoring of the application process, assessment of the results of theguideline, critiquing the application process and its results, and assistance in themodification of the original guideline. For instance, clinical guidelines often have aninherent ambiguity or incompleteness. To increase flexibility, an automated assistantshould recognize cases in which the care provider’s actions, although different fromthe guideline’s prescribed actions, adhere to the overall intentions of the guideline’sdesigner, and should adjust its critique accordingly. To be useful, the language inwhich clinical guidelines are represented needs to be temporally expressive and shouldenable designers to express complex sequential, parallel, and cyclical procedures ina manner akin to a programming language (although typically on a higher level ofabstraction). The language also requires well-defined semantics for both the pre-scribed actions and the task-specific annotations, such as the guideline designer’sintentions. Thus, the care-provider’s actions can be better supported, leading to amore flexible dialog and to a better acceptance of automated systems for support ofguideline-based care. Having clear semantics for the task-specific knowledge roles alsofacilitates acquisition and maintenance of these roles.

Given these requirements, we have developed a text-based, machine-readablelanguage, called Asbru. The Asbru language is part of the Asgaard1 project, in whichwe are developing task-specific problem-solving methods that perform execution andcritiquing tasks in medical domains.

In Section 2, we introduce the design-time and execution-time intention-basedmodel, the guideline-application support tasks it comprises and their requiredknowledge roles, and our framework’s overall architecture. Section 3 explains thesyntax and the semantics of the Asbru language. Section 4 demonstrates how anautomatically generated graphic knowledge-acquisition tool is used to acquire Asbruguidelines from physicians. Section 5 discusses the operation of the Asbru interpreter.We will be illustrating our approach throughout by a guideline for controlledobservation and treatment of gestational diabetes mellitus (GDM) Type II.

2. A design-time versus execution-time intention-based model

During the design time of a clinical guideline, an author (or a committee) designsa guideline (Fig. 1). The author prescribes: (1) actions (e.g. administer a certaindrug in the morning and in the evening); (2) an intended plan—the intended

1 In Norse mythology, Asgaard was the home and citadel of the gods, corresponding to MountOlympus in Greek mythology. It was located in the heavens and was accessible only over the rainbowbridge, called Asbru (or Bifrost).


intermediate and overall pattern of actions, which might not be obvious from thedescription of the prescribed actions and is often more flexible than prescription ofspecific actions (e.g. use some drug from a certain class of drugs twice a day); and(3) the intended intermediate and overall pattern of patient states (e.g. morningblood glucose should stay within a certain range). Intentions are temporal patternsof provider actions or patient states, to be achieved, maintained or avoided.

During execution time, a care pro6ider applies the guideline by performingactions, which are recorded, observed, and abstracted over time into an abstractedplan (Fig. 1). The state of the patient is also recorded, observed, and abstractedover time. Finally, the intentions of the care pro6ider might be recordedalso—inferred from her actions or explicitly stated by the provider.

2.1. The guideline-design and -application tasks

Given the intention-based model of clinical guidelines, we can describe a set oftasks relevant to the design and execution of these guidelines and analyze theknowledge requirements of problem-solving methods that perform these tasks(Table 1). The verification and validation tasks are relevant only during designtime; the rest of the tasks are relevant during execution time. Each task can beviewed as answering a specific question (Table 1).

Each task can be performed by a problem-solving method [5] that has anontology, which is a set of entities, relations, and domain-specific knowledgerequirements assumed by the method. Since knowledge requirements (roles) areoften common to several of the problem-solving methods, we combine them into atask-specific knowledge cluster. Examples of knowledge roles include plan inten-tions, several types of preferences, and state-transition conditions.

Fig. 1. The design-time versus execution-time intention-based model of a clinicalguideline. Double-headed arrows denote a potential axis of comparison (e.g. forcritiquing purposes) during runtimeexecution of the clinical guideline. Striped arrowsdenote an abstracted-into relationship.


Tab

le1

Seve

ral

guid

elin

e-su

ppor

tta

sks

and

the

know

ledg

ere

quir

edto

solv

eth

em.

Com

mon

know

ledg

ero

les

can

bevi

ewed

assh

area

ble

byth

em

etho

dsre

quir

ing

them

Tas

kQ

uest

ions

tobe

answ

ered

Req

uire

dkn

owle

dge

Are

the

inte

nded

plan

sac

hiev

able

byfo

llow

ing

the

pres

crib

edV

erifi

cati

onof

agu

idel

ine

Pre

scri

bed

acti

ons;

inte

nded

over

all

acti

onpa

tter

n(i

.e.

acti

ons?

(asy

ntac

tic

chec

k)th

epl

an)

Are

the

inte

nded

stat

esac

hiev

able

byth

epr

escr

ibed

acti

ons

Val

idat

ion

ofa

guid

elin

eP

resc

ribe

dac

tion

s,in

tend

edov

eral

lac

tion

patt

ern;

and

inte

nded

plan

?(a

sem

anti

cch

eck)

inte

nded

stat

es;

acti

on/p

lan

effe

cts

App

licab

ility

ofgu

idel

ines

Wha

tgu

idel

ines

orpr

otoc

ols

are

appl

icab

leat

this

tim

eto

this

Filt

eran

dse

tup

prec

ondi

tion

s;ov

eral

lin

tend

edst

ates

;th

epa

tien

t?pa

tien

t’s

stat

eW

hat

shou

ldbe

done

atth

isti

me

acco

rdin

gto

the

guid

elin

e’s

Exe

cuti

on(a

pplic

atio

n)of

Pre

scri

bed

acti

ons

and

thei

rfil

ter

and

setu

pa

guid

elin

epr

escr

ibed

acti

ons?

prec

ondi

tion

s;su

spen

sion

,re

star

t,co

mpl

etio

n,an

dab

ort

cond

itio

ns;

the

pati

ent’

sst

ate

Rec

ogni

tion

ofin

tent

ions

Why

isth

eca

repr

ovid

erex

ecut

ing

apa

rtic

ular

set

ofac

tion

s,E

xecu

ted

acti

ons

and

thei

rab

stra

ctio

nto

exec

uted

plan

s;es

peci

ally

ifth

ose

devi

ate

from

the

guid

elin

e’s

pres

crib

edac

tion

and

stat

ein

tent

ions

;th

epa

tien

t’s

stat

e;ac

tion

/pla

nac

tion

s?ef

fect

s;re

visi

onst

rate

gies

;pr

efer

ence

sE

xecu

ted

acti

ons

and

thei

rab

stra

ctio

nto

plan

s;ac

tion

Isth

eca

repr

ovid

erde

viat

ing

from

the

pres

crib

edac

tion

sor

Cri

tiqu

eof

the

prov

ider

’sac

tion

sin

tend

edpl

an?

Are

the

devi

atin

gac

tion

sco

mpa

tibl

ew

ith

the

and

stat

ein

tent

ions

ofth

eor

igin

alpl

an;

the

pati

ent’

sst

ate;

acti

on/p

lan

effe

cts;

revi

sion

stra

tegi

es;

pref

eren

ces

auth

or’s

plan

and

stat

ein

tent

ions

?E

valu

atio

nof

agu

idel

ine

Isth

egu

idel

ine

wor

king

?In

term

edia

te/o

vera

llst

ate

inte

ntio

ns;

the

pati

ent’

sst

ate;

inte

rmed

iate

/ove

rall

acti

onin

tent

ions

;ex

ecut

edac

tion

san

dpl

ans

Mod

ifica

tion

ofan

Inte

rmed

iate

/ove

rall

stat

ein

tent

ions

;ac

tion

/pla

nef

fect

s;W

hat

alte

rnat

ive

plan

sar

ere

leva

ntat

this

tim

efo

rac

hiev

ing

afil

ter

and

setu

ppr

econ

diti

ons;

revi

sion

stra

tegi

es;

exec

utin

ggu

idel

ine

give

nst

ate

inte

ntio

n?pr

efer

ence

s;th

epa

tien

t’s

stat

e


The semantics of the specific knowledge roles used in the Asbru language arediscussed in Section 3. Given these knowledge roles, we can define what knowl-edge is required to solve each task (Table 1).

In this paper, we focus on the dynamic (runtime) execution, plan-recognition,and critiquing tasks. However, we are also looking at the static verification andvalidation tasks. Static verification of a guideline plan involves the examinationof an uninstantiated plan for logical consistency. An Asbru plan is logicallyconsistent, if none of its explicit or implicit logical constraints are violated; inparticular, the plan intentions are compatible with the prescribed actions. Such averification is essentially syntactic in nature (e.g. is visiting a dietician eachTuesday consistent with the intention of visiting a dietician at least four times amonth?). Validation involves a semantic check that the intended patient statesare compatible with the prescribed actions and intended plans. Of course, it isoften difficult or impossible to ascertain that any particular patient state willresult from the performance of certain actions. However, gross inconsistenciescan be detected, given sufficient domain-specific knowledge, such as expectedeffects of drugs and guidelines.

A subtask implicit in several of the tasks in Table 1 is the abstraction ofhigher-level concepts from time-stamped data during the execution of the skeletalplan. Possible candidates for solving this subtask include the RESUME systemand the temporal data-abstraction component in the VIE-VENT system. TheRESUME system [19] is an implementation of a formal, domain-independentproblem-solving method, the knowledge-based temporal-abstraction method [20]and has been evaluated in several clinical domains [19]. VIE-VENT is an open-loop knowledge-based monitoring and therapy planning system for artificiallyventilated newborn infants, which includes context-sensitive and expectation-guided temporal data-abstraction methods [11].

2.2. Plan recognition and critiquing in the application of clinical guidelines

The following example demonstrates the tasks of plan-recognition and cri-tiquing in the domain of monitoring and therapy of patients who have insulin-dependent diabetes.

During the therapy of a diabetes patient, hyperglycemia (a higher than normallevel of blood glucose) is detected for the second time in the same week aroundbedtime. The diabetes-guideline’s prescribed action might be to increase the doseof the insulin the patient typically injects before dinner. However, the providerrecommends reduction of the patient’s carbohydrate intake during dinner. Thisaction seems to contradict the prescribed action. Nevertheless, the automatedassistant notes that increasing the dose of insulin decreases the value of theblood-glucose level directly, while the provider’s recommendation decrease thevalue of the same clinical parameter by reducing the magnitude of an action (i.e.ingestion of carbohydrates) that increases its value. The assistant also notes thatthe state intention of the guideline was to ‘avoid more than two episodes of


hyperglycemia per week.’ Therefore, the provider is still following the intentionof the guideline. By recognizing this high-level intention and its achievement bya different plan, the automated assistant can accept the provider’s alternate setof actions, and even provide further support for these actions.

We consider a plan-recognition ability, such as demonstrated in the example,an indispensable prerequisite to the performance of plan critiquing. Such anability might increase the usefulness of guideline-based decision-support systemsto clinical practitioners, who often follow what they consider as the author’sintentions rather than the prescribed actions. Note that we assume knowledgeabout the effects of inter6entions on clinical parameters, and knowledge of legiti-mate domain-independent and domain-specific guideline-re6ision strategies. Bothintervention effects and revision strategies can be represented formally [18].

Intentions have been examined in philosophy [2] and in artificial intelligence[16]. As we explain in more detail in Section 3.2, we are viewing intentionsformally as temporally extended goals, comprising action or state patterns, atvarious abstraction levels.

The example also demonstrates a specific execution-critiquing model. In thismodel, five comparison axes exist: the guideline’s prescribed actions versus theprovider’s actual actions; the guideline’s intended plan versus the provider’s (ab-stracted) plan; the guideline’s intended patient state versus the provider’s stateintention; the guideline’s intended state versus the patient’s (abstracted) actualstate; and the provider’s intended state versus the patient’s (abstracted) actualstate. Combinations of the comparison results imply a set of different beha6iorsof the guideline application by the provider. Thus, a care provider might notfollow the precise actions, but still follow the intended plan and achieve thedesired states. A provider might not even follow the overall plan, but still adhereto a higher-level intention. Alternatively, the provider might be executing theguideline correctly, but the patient’s state might differ from the intended, per-haps indicating a complication that needs attention or a failure of the guideline.In theory, there might be up to 32 different behaviors, assuming binary compari-sons along five axes. However, the use of consistency constraints prunes thisnumber to approximately 10 major behaviors. (We are also investigating the useof continuous, rather than binary, measures of matching).

2.3. The conceptual architecture

In the Asgaard project, we are developing different task-specific reasoningmodules that perform the guideline-support tasks shown in Table 1. Fig. 2presents the overall architecture.

The task-specific reasoning modules require different types of knowledge, oftenoutside of the scope of the guideline-tasks ontology. For instance, the knowledgebased temporal-abstraction method implemented by the RESUME module re-quires knowledge about temporal-abstraction properties of measurable clinicalparameters, such as persistence of their values over time when these values arenot recorded [20]. These properties exist in the domain’s temporal-abstraction


Fig. 2. The guideline-support architecture. Arrows denote data or knowledge flow.

ontology [19]. The RESUME temporal-abstraction module is part of a temporal-query and temporal-abstraction module that is used to query the time-oriented patientrecord for both raw data and higher-level temporal abstractions and patterns.Currently, we are using the Tzolkin temporal mediator [15] as the temporal-queryand temporal-abstraction module. The Tzolkin module includes, besides the RE-´SUME temporal-abstraction module, the Chronus [3] temporal-query module anda controller that parses temporal queries and coordinates the two modules.

Similarly, the plan-recognition and critiquing methods require generic and domain-specific plan-revision knowledge [18]; much of that knowledge might not be part ofthe guideline specification, but can be represented in a separate knowledge baseaccessible to the appropriate problem-solving methods (reasoning modules). Effectsof specific interventions, such as insulin administration (and, in general, of guidelines)can be represented as part of the guideline, but can also be viewed as a separateknowledge base (Fig. 2). The specifications of clinical guidelines and of theirindependent components (we refer to either of these entities as plans in this paper)are all represented uniformly and organized in a guideline-specification library. Thelibrary is a set of execution plans expressed in our task-specific language. During theguideline-execution phase, an applicable guideline plan is instantiated with runtimearguments.

3. Asbru: a global ontology for guideline-application tasks

We have developed a language specific to the set of guideline-support tasks andthe problem-solving methods performing these tasks, which we call Asbru. Asbruenables a designer to represent a clinical guideline, including all of the knowledgeroles useful to one or more of the problem-solving methods performing the various


tasks supporting the application of clinical guidelines. The major features of Asbruare that prescribed actions can be continuous; plans might be executed in parallel,in sequence, in a particular order, or every time measure; temporal scopes andparameters of guideline plans can be flexible, and explicit intentions and preferencescan underlie the plan. These features are in contrast to most traditional plan-executionrepresentations, which have significant limitations and are not applicable to dynamicenvironments such as clinical domains. Medical domains have certain characteristicfeatures: (1) actions and effects are not necessarily instantaneous: actions are oftencontinuous (have duration) and might have delayed effects; (2) goals often havetemporal extensions; (3) there is uncertainty regarding the effect of available actions;(4) unobservable, underlying processes determine the observable state of the world;(5) a goal may not be achievable; (6) parallel and periodic execution of plans iscommon. The requirements of plan specifications in clinical domains [23] are asuperset of the requirements of typical toy domains used in planning research. Wehave defined a formal syntax for the Asbru language in Backus-Naur form [12]. TheAsbru language combines the flexibility and expressivity of procedural languages (e.g.the Arden syntax [10]) with the semantic clarity of declaratively expressed knowledgeroles. These roles (e.g. preferences and intentions) are specific to the ontology of themethods performing the guideline-support tasks.

3.1. Time annotation

The time annotation used allows a representation of uncertainty in startingtime, ending time, and duration of a time interval [4], [17]. The time annotationsupports multiple time lines by providing different reference annotations. Thereference annotation can be an absolute reference point, a reference point withuncertainty (defined by an uncertainty region), a function (e.g. completion time)of a previously executed plan instance, or a domain-dependent time point vari-able (e.g. CONCEPTION). Temporal shifts from the reference annotation repre-sent uncertainty in the starting time, the ending time, and the overall duration(Fig. 3). Thus, the temporal annotation represents for each interval the earlieststarting shift (ESS), the latest starting shift (LSS), the earliest finishing shift(EFS), the latest finishing shift (LFS), the minimal duration (MinDu) and themaximal duration (MaxDu). Temporal shifts are measured in time units. Thus, atemporal annotation is written as ([ESS, LSS], [EFS, LFS], [MinDu, MaxDu],REFERENCE). All temporal-shift constraints can be unknown (unbound, de-noted by an underscore,‘–’) to allow incomplete time annotations.

To allow temporal repetitions, we define sets of cyclical time points (e.g.MIDNIGHTS, which represents the set of midnights, where each midnight occursat exactly 0:00 a.m., every 24 h) and cyclical time annotations (e.g. MORNINGS,which represents a set of mornings, where each morning starts at the earliest 8:00a.m., ends at the latest 11:00 a.m., and lasts at least 30 min.). In addition, we allowcertain short-cuts, i.e. for the current time, whatever that time is (using the symbol*NOW*), or the duration of the plan (using the symbol *). Thus, the Asbru


notation enables the expression of interval-based intentions, states, and pre-scribed actions with uncertainty regarding starting, finishing, duration, and theuse of absolute, relative, and even cyclical (with a predetermined granularity)reference annotations.

3.2. The semantics of the Asbru task-specific knowledge roles

A (guideline) plan in the guideline-specification library is composed of a set ofplans with arguments and time annotations. A decomposition of a plan into itssubplans is attempted by the execution interpreter unless the plan is not found inthe guideline library, thus representing a nondecomposable plan. This can beviewed as a ‘semantic’ halting condition, which increases runtime flexibility, sincethe same plan might imply an atomic action for one clinical site, but might bedecomposable into more primitive actions at another clinical site. A nondecom-posable plan is executed by the user or by an external call to a computerprogram. The library includes a set of primiti6e plans to perform interaction withthe user or to retrieve information from the medical patient record (e.g. OB-SERVE, GET-PARAMETER, ASK-PARAMETER, DISPLAY, WAIT). Allplans have return values.

Generic library plans that are mentioned as part of an executing guideline havestates (considered, possible, rejected, and ready), that determine whether theplan is applicable and whether a plan instance can be created (Fig. 4).

At execution time, a ready plan is instantiated. A set of mutually exclusive planstates describe the actual status of the plan instance during execution. Particularstate-transition criteria (conditions) specify transition between neighboring plan-in-stance states. Thus, if a plan is activated, in can only be completed, suspended,

Fig. 3. A schematic illustration of the Asbru time annotations. The upper part of the figure presents thegeneric annotation. The lower part shows a particular example representing the time annotation [[24WEEKS, 26 WEEKS], [32 WEEKS, 34 WEEKS], [7 WEEKS, 9 WEEKS], CONCEPTION]), whichmeans ‘starts 24 to 26 weeks after conception, ends 32 to 34 weeks after the conception, and lasts 7 to9 weeks.’ REFERENCE=reference annotation, ESS=earliest starting shift, LSS= latest starting shift,EFS=earliest finishing shift, LFS= latest finishing shift, MinDu=minimal duration, MaxDu=maxi-mal duration. The annotation is thus ([ESS, LSS], [EFS, LFS], [MinDu, MaxDu], REFERENCE).


Fig. 4. Plan-selection states and their state-transition conditions in Asbru. These states are relevant tolibrary plans that are considered for execution.

or aborted depending on the corresponding criteria; the suspended state isoptional and available for complex plans (Fig. 5).

State-transition conditions are explained below. A plan consists of a name, a setof arguments, including a time annotation (representing the temporal scope of theplan), and five (optional) components: preferences, intentions, conditions, effects,and a plan body which describes the actions to be executed. All components areoptional. Every subplan has the same structure. Thus, a sequential plan can includeseveral potentially decomposable concurrent or cyclical plans.

We now examine each of the knowledge roles represented in Asbru in moredetail.

Preferences: Preferences bias or constrain the selection of a plan to achieve agiven goal. Examples include:1. Strategy : a general strategy for dealing with the problem (e.g. aggressive,

normal);2. Utility : a set of utility measures (e.g. minimize the cost or the patient

inconvenience);3. Select-method : a matching heuristic for the applicability of the whole plan (e.g.

exact-fit);4. Resources : a specification of prohibited or obligatory resources (e.g. in certain

cases of treatment of a pulmonary infection, surgery is prohibited and antibi-otics must be used);

5. Start-conditions : an indication whether transition from a ready state of thegeneric plan to an activated state of the plan instance is automatic or requiresapproval of the user.

Intentions: Intentions are high-level goals at various levels of the plan, an annota-


tion specified by the designer that supports special tasks such as critiquing andmodification. Intentions are temporal patterns of provider actions and patientstates, at different levels of abstraction, that should be maintained, achieved, oravoided. We define four categories of intentions:1. Intermediate state : the patient state(s) that should be maintained, achieved, or

avoided during the applicability of the plan (e.g. weight gain levels are slightlylow to slightly high);

2. Intermediate action : the provider action(s) that should take place during theexecution of the plan (e.g. monitor blood glucose once a day);

3. O6erall state pattern : the overall pattern of patient states that should hold afterfinishing the plan (e.g. patient had less than one high glucose value per week);

4. O6erall action pattern : the overall pattern of provider actions that should holdafter finishing the plan (e.g. patient had visited dietitian regularly for at leastthree months).

Conditions: Conditions are temporal patterns, sampled at a specified frequency, thatneed to hold at particular plan steps to induce a particular state transition of theplan instance. They are used for actual execution (application) of the plan. We donot directly determine conditions that should hold during execution; we specifycon-ditions that activate the change of a particular plan state (Fig. 5). A plan instanceis completed when the complete conditions become true, otherwise the planinstance’s execution suspends or aborts (often due to failure). Conditions areoptional. We distinguish between six types of conditions:1. filter-preconditions, which need to hold initially if a generic plan is applicable;

these conditions are not goals to be achieved (e.g. patient is a pregnant female),and must be true to achieve a possible state (Fig. 4);

Fig. 5. Plan-execution states and their state-transition conditions in Asbru. These states are relevant toinstances of library plans that are being executed.


2. setup-preconditions, which need to be achieved (usually, within a given timedelay relative to the initial time of consideration of the plan) to enable a planto start (e.g. patent had a glucose-tolerance test) and allow a transition froma possible plan to a ready plan (Fig. 4);

3. suspend-conditions, which determine when an active plan instance has to besuspended (e.g. blood glucose has been high for four days); these are infor-mally the inverse of protection conditions in the planning literature, whichhave to hold during certain time periods (Fig. 5);

4. abort-conditions, which determine when an active or suspended plan has to beaborted (e.g. there is an insulin-indicator condition: the patient cannot becontrolled by diet) (Fig. 5);

5. complete-conditions, which determine when an active plan is completed, typi-cally, but not necessarily, successfully (e.g. delivery has been performed) (Fig.5);

6. reacti6ate-conditions, which determine when a suspended plan has to be reac-tivated (e.g. blood glucose level is back to normal or is only slightly high)(Fig. 5).

Effects: Effects describe the functional relationship between either: (1) each ofthe relevant plan arguments and measurable parameters it affects in certaincontexts (e.g. the dose of insulin is inversely related in some fashion to the levelof blood glucose); or (2) the overall plan and the clinical parameters it is ex-pected to affect (e.g. the insulin-administration plan decreases the blood-glucoselevel). Effects can have a likelihood annotation—a probability of occurrence.Effects can be part of the guideline library (when they annotate plans) and canalso be stored in a domain-specific knowledge base (especially for commonplans, such as administration of drugs).

Plan-Body: The plan body is a set of plans to be executed in parallel, insequence, in any order, or in some frequency. We distinguish among three typesof plans: sequential, concurrent, and cyclical. Only one type of plan is allowed ina single plan body. A sequential plan specifies a set of plans that are executed insequence; for continuation, all plans included have to be completed successfully.Concurrent plans can be executed either together, in parallel, or in any order.We distinguish between two dimensions for the classification of sequential or(potentially) concurrent plans: the number of plans that should be completed toenable continuation and the order of plan execution. Table 2 summarizes thedimensions of the two plan types. Using the two dimensions, we define the plansubtypes DO-ALL-TOGETHER, DO-SOME-TOGETHER, DO-ALL-ANY-OR-DER, DO-SOME-ANY-ORDER, DO-ALL-SEQUENTIALLY. The continua-tion condition specifies the names of the plans that must be completed toproceed with the next steps in the plan.

A cyclical plan (a DO-EVERY type) includes a plan that can be repeated, andoptional temporal and continuation arguments that can specify its behavior. Startand end specify a starting and ending time point. Time base determines the timeinterval over which the plan is repeated and the start time, end time, and durationof the particular plan instance in each cycle (e.g. starting with the first Monday’smorning, until next Tuesday’s morning, perform plan A every morning for 10 min).


Table 2Categorization of plan types by continuation conditions and ordering constraints

Continuation conditionOderingconstraints

Some plans should be completed inAll plans should be completed in orderto continue order to continue

DO-ALL-TOGETHER (no continua- DO-SOME-TOGETHER (continuation-Start togethertion-condition; all plans must complete) conditions specified as subset of plans)

DO-SOME-ANY-ORDER (continua-DO-ALL-ANY-ORDER (no continua-Execute in anyorder tion-condition; all plans must complete) tion-conditions specified as subset of

plans)—DO-ALL-SEQUENTIALLY (no con-Execute in total

tinuation-condition; all plans mustordercomplete)

The times-completed argument specifies how many times the plan has to becompleted to succeed and the times-attempted argument specifies how many at-tempts are allowed. Obviously, the number of attempts must be greater or equalto the number of successful plans. A temporal pattern can be used as a stopcondition of the cyclic plan. Finally, the plan itself is associated with its ownparticular arguments (e.g. dose). The start time, the time base, and the planname are mandatory to the specification of a cyclic plan; the other argumentsare optional.

3.3. Example: a gestational diabetes mellitus guideline

We represented a Stanford University guideline for controlled observation andtreatment of gestational diabetes mellitus (GDM) type II (non insulin dependent)in Asbru. The guideline prescribes several concurrent monitoring and manage-ment plans following a glucose tolerance test (GTT) between 140 and 200 mg/dl(Fig. 6). The plan body consists of three plans that are executed in parallel(glucose monitoring, nutritional management, and monitoring for insulin indication),exist in the guideline-specification library, and are decomposable into other li-brary plans.

4. Acquisition and maintenance of guideline plans

Expert physicians need not have familiarity with the syntax of the Asbrulanguage to author clinical guidelines. Graphical knowledge-acquisition (KA)tools can be generated automatically by systems such as PROTEGE-II [22]. TheKA tools can internally use the Asbru representation or its equivalent, however,that representation need not necessarily be known to the user. In addition tocreation of an internal (e.g. object-oriented) version of the plan, the KA tool


Fig. 6. A small portion of the representation of the guideline for management of non-insulin-dependentgestational diabetes mellitus (GDM) type II. Double colons are followed by comments.


should be able to generate a text-based Asbru version. The Asbru version canthen be used as a sharable machine-readable version that does not depend onany particular platform and will also be useful for reading and editing by moreknowledgeable designers. We have explored the option of generating an auto-mated graphic KA tool for acquiring the set of shared knowledge roles, usingthe PROTEGE-II suite of tools, with encouraging results.

4.1. Modeling a clinical-guideline ontology using the PROTEGE-II methodology

PROTEGE-II is a set of tools and a methodology to develop knowledge basedsystems. We used PROTEGE/Win (the Windows version of PROTEGE-II) todevelop the ontology and to generate a graphical KA tool automatically fromthe ontology. This ontology is shared by the task-specific cluster of problem-solving methods relevant to the support of skeletal-plan execution. InPROTEGE-II terms, we have developed a method ontology, global to all ourproblem-solving methods. By this we mean that the ontology is in theory local(specific) to some hypothetical, all-encompassing method that performs the taskcluster, but is in practice global to (shared by) all the methods that performsubtasks in that cluster. This is sensible in this case, as there is a great deal ofoverlap in the concepts needed for the different tasks, and the roles undertakenby these concepts are the same in all their uses by this set of tasks. The domainontology in the case of clinical guidelines is also required, but not shown here.The domain ontology specifies concepts, such as drugs, diseases, patient findings,tests, and clinic visit types.

Ontologies in PROTEGE-II are represented as a hierarchy of classes. Eachclass is represented as a frame with slots. Slots may be constrained to basic datatypes, or to be instances of another class defined in the ontology, thus allowingthe expression of relationships in the ontology. The PROTEGE/Win Ontolo-gyEditor tool was used to capture the ontology of the cluster of methods sup-porting skeletal-plan execution. Fig. 7 shows a portion of that ontology.

Once the ontology is defined, the PROTEGE/Win LayoutEditor tool automat-ically generates a specification of a graphical KA tool for this ontology. Thespecification of the KA tool is interpreted by the PROTEGE/Win LayoutInter-preter. It is possible to change the layout of the user interface to some degree inthe LayoutEditor. The resultant KA tool can then be used to acquire instancesof the ontology, which in this case would be guidelines in the Asbru language.

The knowledge roles in the Asbru syntax can be viewed as a set of slots in aframe-based ontology of skeletal plans. The ontology that we have developedmirrors the BNF Syntax of the Asbru language. As this language is not objectoriented, the ontology is fairly flat, in that inheritance is not used significantly.The concepts of inheritance and polymorphism can be usefully applied to thisdomain, indeed it seems more natural to express the ontology in this form. Asan example, all plans in the current ontology share the same state transitioncriteria, which has been chosen as one which applies to most actions. However,in a hierarchical ontology it is easy to create special subclasses of the plan class


Fig

.7.

Par

tof

the

exec

utio

n-su

ppor

tm

etho

dson

tolo

gy,

repr

esen

ted

byth

eP

RO

TE

GE

/Win

Ont

olog

yE

dito

r


which have variants of the state transition criteria. Such an ontology maps wellas an object-oriented language.

4.2. A knowledge-acquisition tool for support of clinical-guideline execution

We have generated an automated graphical KA tool for the object-orientedversion of the Asbru language, using the PROTEGE-II suite of tools, withencouraging results. Fig. 8 shows an example of a domain expert using the KAtool to acquire a part of the GDM type II guideline. The expert has defined thebody of the guideline as being composed of three parallel plans, all three to bestarted together; one of the plans is being highlighted and examined, as well asthe overall state intention of the top-level (GDM type II) plan.

If the user is conversant with the syntax of the Asbru language, it may bequicker to design guidelines by writing them in the language, using ‘copy andpaste’ functions or editor macros. If the user, in particular a domain expert, isunfamiliar with the syntax, then it is easier to use the KA tool. The complexityof the ontology enforces the automatic generator of the KA tool to produce auser interface with many cascading, small dialogs. Thus, for providing an opti-mal dialog, more control of the layout of the automatically generated userinterface was needed than was possible in early versions of PROTEGE/Win.Once this additional feature became available, we managed to generate andcustomize significantly better KA tools, although more improvements can takeplace.

Another significant benefit of the KA tool approach is that it detects incorrectsyntax while authoring a guideline. Thus, implicit syntactic support is providedat no cost.

One of the interesting areas for acquisition of knowledge is the temporalannotations. We are examining several alternatives to our ontology-based graphicinterface, including a specialized string editor that accepts as input the BNFsyntax of temporal annotations, and automatically creates a graphical KA toolthat acquires legal strings from the user (Fig. 9). The string editor is part of thePROTEGE/Win framework. We are also exploring other representations to facil-itate acquisition from domain experts, such as assuming that complex temporalpatterns are composed of a small number of temporal intervals, amongst whichthe user only needs to specify temporal and value relations, while each is ac-quired as a separate instance.

5. The Asbru interpreter

We have implemented an interpreter for the Asbru language (i.e. a computationalmodule that performs the execution task). The Asbru interpreter is implemented inthe CLIPS language [7] and assumes as input a library of generic guideline plansrepresented as CLIPS objects, and a top-level plan (with appropriate arguments, ifrelevant) to be considered for execution. Guideline plans are acquired through the


Fig

.8.

The

Asb

rukn

owle

dge-

acqu

isit

ion

tool

.T

hesc

reen

shot

dem

onst

rate

sac

quis

itio

nof

part

ofth

ege

stat

iona

ldi

abet

esm

ellit

us(G

DM

)ty

peII

guid

elin

efr

oma

dom

ain

expe

rt.

The

mai

nw

indo

wsh

ows

the

guid

elin

e’s

com

pone

nts

and

isge

nera

ted

auto

mat

ical

lyby

the

Pro

tege

/Win

tool

sfr

oman

Asb

ruon

tolo

gy.

Tw

oof

the

thre

esu

bwin

dow

ssh

owac

quis

itio

nof

one

ofth

ree

para

llel

(do-

all-

toge

ther

)pl

ans

that

the

GD

Mgu

idel

ine

isco

mpo

sed

of;

the

thir

dsh

ows

ade

finit

ion

ofth

eG

DM

guid

elin

e’s

over

all

stat

ein

tent

ion.


Fig

.9.

The

stri

nged

itor

.T

hesc

reen

shot

issh

owin

gac

quis

itio

nof

part

ofa

trea

tmen

tgui

delin

efo

rne

wbo

rnin

fant

sw

hoar

ebe

ing

mec

hani

cally

vent

ilate

dfr

oma

dom

ain

expe

rt.

Inth

est

ring

edit

or,

the

acqu

isit

ion

proc

ess

isgu

ided

dire

ctly

byth

eA

sbru

lang

auge

’sB

NF

synt

ax.


graphic KA tool generated through the PROTEGE/Win system, and can also becreated directly from an Asbru pure-text version by a simple 1:1 mapping. Thus, theAsbru interpreter assumes a generic, objected-oriented intermediate representationfor plans that can be acquired directly from an expert physician using the graphicKA tool or that can be created by a preprocessor (a parser) from an existing(text-based) Asbru guideline written by a domain expert who knows the language.The Asbru interpreter creates as output plan objects that refer to generic orinstantiated plans, and communicates with the user by sending messages involvingplan objects (e.g. regarding execution of atomic plan instances that cannot bedecomposed further, or regarding the need to make certain set-up conditions trueto make a possible generic plan ready to be instantiated).

The Asbru interpreter goes through several distinct phases. In each phase, all planobjects (i.e. both those that refer to generic plan types and those that refer to planinstances) that refer to (generic or instantiated) plans in a particular state areprocessed. Therefore, the phases correspond roughly to potential states of bothgeneric plans and plan instances, and include consider, check-possible, check-ready,and execute phases. The execute phase includes several subphases in which theabort, suspend, and complete conditions of all plan-objects are being checked. Ineach phase, an appropriate list of plan objects is processed. Thus, for instance, inthe consider phase, the interpreter examines the filter condition for all consideredplans, changing their states to possible or rejected until the list of considered plansis empty.

The Asbru interpreter implements several aspects of the pragmatic semanticsunderlying the Asbru syntax. For instance, aborting any type of plan instance (e.g.an instance of a parallel plan) aborts all its component plans (e.g. the plan instancesexecuting in parallel as part of a DO-ALL-TOGETHER plan type). The inverse isnot necessarily true, and the effect of aborting a component plan on the parent plandepends on the type of the plan.

We are implementing the plan-recognition and critiquing task by building on thismodel of interpretation with respect to the execution model, and on our temporal-abstraction model [20] and the Asbru temporal annotations with respect to therepresentation and querying of patient data.

6. Summary and discussion

Representing clinical guidelines and the intentions underlying them in a standard,machine-readable, and machine-interpretable form is a prerequisite for sharingclinical guidelines and for useful, flexible automated assistance in the execution ofthese guidelines. The task-specific representation we suggest supports several differ-ent knowledge roles that can be used by multiple reasoning modules, for directexecution of a guideline and for related tasks such as recognition of care providers’intentions and critiquing their actions. In addition, the Asbru language places aparticular emphasis on an expressive representation for time-oriented provideractions and patient states. Temporal reasoning is important for many clinicaldomains and needs to be supported.


Expert physicians need not have familiarity with the Asbru syntax to authorclinical guidelines. We used the PROTEGE-II framework to develop an Asbru-likeobject-oriented guideline ontology and to generate a graphical knowledge-acquisi-tion tool automatically from the ontology. The tool acquires instances of guidelinesmodeled in an object-oriented Asbru version.

We are continuing to develop the computational modules, focusing on theexecution, plan recognition, and critiquing modules.

Acknowledgements

Yuval Shahar has been supported by grants LM05708 and LM06245 from theNational Library of Medicine, and IRI-9528444 from the National Science Foun-dation. We thank Kinkoi Lo for implementation of the prototype of the Asbruinterpreter.

References

[1] Barnes M and Barnett GO. An Architecture for a Distributed Guideline Server. In: Gardner RM,editors. Proc. Annual Symposium on Computer Applications in Medical Care (SCAMC-95). NewOrleans, LA: Hanley and Belfus, 1995:233–237.

[2] Bratman ME. Intention, Plans and Practical Reason. Cambridge: Harvard University Press, 1987.[3] Das AK, Musen MA. A temporal query system for protocol-directed decision support. Methods

Inf. Med. 1994;33:358–70.[4] Dechter R, Meiri L, Pearl J. Temporal constraint networks, artificial intelligence. Spec. Vol. Knowl.

Represent. 1991;49(1-3):61–95.[5] Eriksson H, Shahar Y, Tu SW, Puerta AR, Musen MA. Task modeling with reusable problem-solv-

ing methods. Artif. Intell. 1995;79(2):293–326.[6] Friedland P, Iwasaki Y. The concept and implementation of skeletal plans. J. Automated Reason.

1985;1(2):161–208.[7] Giarratano J, Riley G. Expert Systems: Principles and Programming. Boston: PWS Publishing

Company, 1994.[8] Grimshaw JM, Russel IT. Effects of clinical guidelines an medical practice: a systematic review of

rigorous evaluation. Lancet 1993;342:1317–22.[9] Herbert SI, Gordon CJ, Jackson-Smale A, Renaud Salis JL. Protocols for clinical care. Comput.

Methods Programs Biomed. 1995;48:21–6.[10] Hripcsak G, Ludemann P, Pryor TA, Wigertz OB, Clayton PD. Rationale for the Arden Syntax.

Comput. Biomed. Res. 1994;27:291–324.[11] Miksch S, Horn W, Popow C, Paky F. Utilizing temporal data abstraction for data validation and

therapy planning for artificially ventilated newborn infants. Artif. Intell. Med. 1996;8(6):543–76.[12] Miksch S, Shahar Y, Johnson P. Asbru: A task-specific, intention-based, and time-oriented

language for representing skeletal plans. In: Proc. 7th Workshop on Knowledge EngineeringMethods and Languages (KEML-97). Milton Keynes, UK, 1997:9-1–9-20.

[13] Musen MA, Carlson CW, Fagan LM, Deresinski SC, Shortliffe EH. T-HELPER: AutomatedSupport for Community-Based Clinical Research. In: Frisse ME, editor. Proc. 16th AnnualSymposium on Computer Applications in Medical Care (SCAMC-92). New York: McGraw Hill,1992:719–723.

[14] Musen MA, Tu SW, Das AK, Shahar Y. EON: A component-based approach to automation ofprotocol-directed therapy. J. Am. Med. Inf. Assoc. 1996;3(6):367–88.


[15] Nguyen J, Shahar Y, Tu SW, Das AK, Musen MA. A temporal database mediator for protocol-based decision support. Proc. 1997 AMIA Annual Fall Symposium (formerly the Symposium onComputer Applications in Medical Care). Nashville, TN: Hanley and Belfus, 1997:298–302.

[16] Pollack M. The use of plans. Artif. Intell. 1992;57(1):43–68.[17] Rit JF. Propagating Temporal Constraints for Scheduling. In: Proc. 5th National Conference on

Artificial Intelligence (AAAI-86). Los Altos, CA: Morgan Kaufmann, 1986:383–388.[18] Shahar Y, Musen MA. Plan Recognition and Revision in Support of Guideline-Based Care. Notes

of the AAAI Spring Symposium on Representation Mental States and Mechanisms. Stanford, CA,1995:118–126.

[19] Shahar Y, Musen MA. Knowledge-based temporal abstraction in clinical domains. Artif. Intell.Med. 1996;8(3):267–98.

[20] Shahar Y. A framework for knowledge-based temporal abstraction. Artif. Intell. 1997;90(1):79–133.[21] Sherman EH, Hripcsak G, Starren J, Jender A, Clayton P. Using Intermediate States to Improve

the Ability of the Arden Syntax to Implement Care Plans and Reuse Knowledge. In: Gardner RM,editor. Proc. Annual Symposium on Computer Applications in Medical Care (SCAMC-95). NewOrleans, LA: Hanley and Belfus, 1995:238–242.

[22] Tu SW, Eriksson H, Gennari JH, Shahar Y, Musen MA. Ontology-Based Configuration ofProblem-Solving Methods and Generation of Knowledge-Acquisition Tools: Application ofPROTEGE-II to Protocol-Based Decision Support. Artif. Intell. Med. 1995;7(3):257–89.

[23] Tu SW, Kahn MG, Musen MA, Ferguson JC, Shortliffe EH, Fagan LM. Episodic Skeletal-PlanRefinement on Temporal Data. Communications of ACM 32, 1989:1439–1455.

.

Documents

The Asgaard project: a task-specific framework for the application and critiquing of time-oriented clinical guidelines