Comparing Models of Decision and Action for ... - Semantic Scholar

1 downloads 11 Views 308KB Size Report
agreed to model the case-study guidelines, validate them as well as possible (using tools where ... tion server, uses formalized clinical guidelines and patient data to generate .... bles and SQL queries to examine model details. IV. ..... from simple if…then…else or switch constructs to complex models such as decision trees.

Page 1 of 37 pages.

Peleg et al., A comparison study of guideline models

Comparing Models of Decision and Action for Guideline-Based Decision Support: a Case-Study Approach (Part 1 of 2) Running head: Comparing guideline decision and action models Mor Peleg, Ph.D.1*, Samson Tu, M.S.1, Jonathan Bury, M.B.Ch.B., M.Sc.2, Paolo Ciccarese, M.Sc.3, John Fox, Ph.D.2, Robert A Greenes, M.D., Ph.D.4, Richard Hall, M.Sc.5, Peter D. Johnson, M.B.B.S.5, Neill Jones, M.B.B.S.5, Anand Kumar, M.B.B.S.3, Silvia Miksch, Ph.D.6, Silvana Quaglini, Ph.D.3, Andreas Seyfang, M.Sc.6, Edward H Shortliffe, M.D., Ph.D.7, and Mario Stefanelli, Ph.D.3

1

Stanford Medical Informatics, Stanford University School of Medicine, Stanford, CA, USA

Advanced Computational Laboratory of Cancer Research, London, UK 3 4

Medical Informatics Laboratory, Department of Computers and Systems Science, University of Pavia, Pavia, Italy Decision Systems Group, Harvard Medical School, Brigham & Women’s Hospital, Boston, MA, USA

5 6 7

Sowerby Centre for Health Informatics at Newcastle, University of Newcastle, Newcastle upon Tyne, UK Institute of Software Technology and Interactive Systems, Vienna University of Technology, Vienna, Austria Department of Medical Informatics, Columbia University, New York, NY, USA

Reprint requests and all communication should be addressed to: Mor Peleg, Stanford Medical Informatics, Medical School Office Building x-208, 251 Campus Drive, Stanford, CA 94305-5479; Phone: (650) 723-7711 Fax: (650) 725-7944; E-Mail: [email protected]

Page 2 of 37 pages.

Peleg et al., A comparison study of guideline models

Abstract We compared six computer-interpretable guideline models to understand their commonalities and differences. We sought to identify issues to be resolved if there were to be a consensus on a set of common components, while allowing research groups to continue their research on unique features. The models compared were Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma. Collaborators from each group that created these models represented, in their own formalism, portions of two guidelines: the American College of Physicians – American Society of Internal Medicine’s guideline for managing chronic cough, and the Sixth Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure. We compared the guideline models according to eight dimensions. This paper describes our study methodology and compares the models according to four dimensions that capture the structure of guideline models: (1) the organization of guideline plans, (2) representation of goals/intentions, (3) representation of guideline actions, and (4) models of decision-making. A second paper compares the models in terms of their underlying data and concept models as well as their expression languages.

Page 3 of 34 pages.

Peleg et al., A comparison study of guideline models

I. INTRODUCTION Expert clinicians have developed evidence-based clinical guidelines to improve quality of patient care, to reduce unjustified variation in care, and to reduce costs. Guideline implementations are most likely to affect clinician behavior if they deliver patient-specific advice during patient encounters1, 2. A key component of guideline-based decision-support tools3 is a machine interpretable guideline model. One model, the Arden Syntax, developed for encoding of medical logic modules (MLMs), has a rule-based formalism, and has been adapted for representation of guidelines by employing interacting MLMs4. Augmented decision tables (ADTs)5 have also been used to model guidelines. ADTs go beyond Arden's rule-based formalism by augmenting decision-table rules with additional information such as probability and utility information. Neither MLMs nor ADTs, however, provide support for conceptualizing a multi-step guideline that unfolds over time. To model such guidelines, many groups have adopted an approach involving hierarchical decomposition of a guideline plan into a network of component tasks6-11. This approach has been described as the “Task-based paradigm”12; we use the term Task-Network Models (TNMs). The plan components provide design primitives that are custom-tailored to clinical guidelines. Relationships among plan components, such as ordering constraints, can be described, and tools for the visual representation of plans and the organization of tasks within them are typically provided. This organization of a guideline model is very different from that of rule-based systems, where the flow of control is not explicitly modeled. TNMs differ in their emphases and in their approaches to addressing particular modeling challenges. These differences reflect the interests and expertise of the groups that have developed them, and the strategies they have adopted in response to specific modeling issues. Previous reviews of the field have relied on published descriptions of individual methodologies3, 13, 14. We seek to compare these approaches by analyzing how two sample guidelines are modeled in each approach. Note that many of the differences we report have resulted from unique purposes or targeted applications that have motivated the various groups in developing their guideline models, briefly reviewed in

Page 4 of 34 pages.

Peleg et al., A comparison study of guideline models

Section III; these should be borne in mind in interpreting the comparisons. This paper focuses on objective features of the various modeling languages relating to their encoding of the sample guidelines. Our purpose has been to understand commonalities and differences, so as to identify issues to be resolved if a consensus on a set of common components is to be developed. We recognize, however, that because of the different goals of various research groups, such a consensus model will be acceptable to the research groups only if it concurrently is to allow them to continue their investigations of unique features.

II. METHODS The Stanford team designed the study. One of us (S.T.) used two criteria to establish dimensions for comparing models. They were (1) functionalities required for these systems (setting goals, interpreting data, making decisions, recommending tasks, and organizing decisions and tasks in a process model3), and (2) the requirement that models encode decision criteria referencing patient data and medical concepts. The dimensions he defined are:

1. Organization of guideline plan components 2. Goals/intentions 3. Model of guideline actions 4. Decision model 5. Expression/criterion language 6. Interpretation of data 7. Medical concept model 8. Patient information model These dimensions capture the essence of modeling the logic of computer-interpretable guidelines. The first four represent core guideline components, which are necessary for structuring narrative guideline recommendations as plans of task networks. They enable modelers to set goals for guideline plans (e.g., maintain blood pressure within normal boundaries), and to specify decision-making and action-taking tasks that fulfill the goals. The last four components link the guideline model with patient data. The eight

Page 5 of 34 pages.

Peleg et al., A comparison study of guideline models

dimensions will be explained in more detail in the Results section. Other dimensions (e.g., complexity management) are also important, but we did not include them in order to limit the complexity of the study. The Stanford team chose segments of two guidelines for our comparisons. These segments were sufficiently small that the effort required to represent them in alternative methodologies and to analyze the results would not be overwhelming. The guidelines were management of cough, (American College of Physicians – American Society of Internal Medicine15), and treatment of hypertension, (Sixth Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure (JNC VI)16). We added comments to guideline recommendations to disambiguate certain sentences. For example, we clarified “Chest radiographs do not have to be routinely obtained before beginning treatment” by adding the comment “Chest radiograph may or may not be obtained before beginning treatment, and both options should be modeled (dimension 1)”. In addition, before the participants started modeling guidelines, we declared which dimensions would be evaluated for each guideline recommendation. The teams agreed to model the case-study guidelines, validate them as well as possible (using tools where available or by manual inspection), and document the models within two months. One or two people in each team encoded the guidelines in their model. We checked each encoded guideline separately for inconsistencies in the model, and ensured that all required recommendations were modeled sufficiently to allow a thorough comparison among the models. We next examined how different models represented specific parts of guideline recommendations. If an encoded guideline did not model an aspect that was encoded by other groups, its modeler was asked to redo that segment. One of us (M.P.) wrote multiple drafts of the comparison analysis that were corrected and amplified by members of the participating teams. The guideline segments, along with the comments that we added to them, are online at http://www.openclinical.org. A fair comparison of guideline-modeling methodologies requires participation of researchers involved in each modeling approach. Consequently, the Stanford team invited research groups that have developed mature TNM modeling methodologies to participate in this study. Six groups agreed to participate.

Page 6 of 34 pages.

Peleg et al., A comparison study of guideline models

III. Guideline-modeling methodologies compared in this study This study compares six guideline-modeling methodologies: PRODIGY-37, EON8, PROforma17, Asbru10, GLIF-36, and GUIDE11. PRODIGY-3 PRODIGY-3 (PRODIGY) was developed at the University of Newcastle upon Tyne. Its purpose is to provide support for chronic disease management in primary care. PRODIGY aims at producing the simplest, most understandable model sufficiently expressive to represent chronic disease management guidelines. Teams of clinicians have used Protégé’s knowledge engineering environment18 to encode three complex chronic-disease-management guidelines and over 150 simple guidelines. Two vendors have integrated identical PRODIGY components into their clinical information systems for general practitioners19. EON EON was developed at Stanford University and is intended to provide a suite of models and software components for creating guideline- and protocol-based applications for different situations. It contains an extensible modeling framework that includes (1) a patient-data information model, (2) a medical concept model, and (3) a guideline model that uses a task-based approach to define decision-support services that can be implemented using alternative techniques20. EON has middleware servers that perform computations necessary to support specific tasks in guideline-based patient care. One server, the guideline execution server, uses formalized clinical guidelines and patient data to generate situation-specific recommendations. A temporal data mediator extends the traditional relational database server to support queries involving temporal abstractions and temporal relationships. A third component provides explanation services for other components21. PROforma PROforma was developed at the Advanced Computational Laboratory of Cancer Research, UK. It combines logic programming and object-oriented modeling, and supports inference in propositional and predicate logics, together with certain non-classical logics for reasoning and control17. Most constructs of

Page 7 of 34 pages.

Peleg et al., A comparison study of guideline models

PROforma are grounded in a well-defined and formally verified logical language called the Red Representation Language (R2L)22. One aim of the PROforma project is to explore the expressiveness of a deliberately minimal set of modeling constructs. It models guidelines as networks of tasks that are encapsulated procedures for achieving particular goals. PROforma supports four tasks: actions, plans (i.e., tasks that are composed of other tasks), decisions and inquiries. Each task has its own distinctive attributes, but all tasks share a number of generic (inherited) attributes describing goals, control flow, preconditions, and post-conditions. The simple task ontology should make it easier to demonstrate the soundness of the underlying model and to teach guideline authors to use the language. Asbru Asbru is a collaboration between groups at Ben Gurion University and the Vienna University of Technology. Asbru is a time-oriented, intention-based, skeletal plan-specification language that is used to represent clinical protocols23. The Asbru language was developed in the Asgaard project10, which outlines taskspecific problem-solving methods to support both design and execution of skeletal plans. Skeletal plans are plan schemata at various levels of detail, which capture the essence of the procedure, but leave enough room for execution-time flexibility in the achievement of particular intentions. Thus, they are usually reusable in various contexts. The developers of Asbru, have enriched skeletal plans by (1) characterizing plan attributes (knowledge roles) such as intentions, conditions, affects, and plan-body, (2) adding a rich set of ordering of actions and plans, and (3) defining temporal dimension of states, actions, and plans. Uncertainty in both temporal scopes and parameters can flexibly be expressed by bounding intervals, which also allows representing multiple time lines. Particular conditions and operators are defined to monitor the plans’ execution. Clinical guidelines can be authored using AsbruView24, a graphical editor and visualization tool, or with a standard XML editor using the Asbru DTD23. GLIF3 The Guideline Interchange Format version 3 (GLIF) has been under development as a collaboration between groups at Columbia, Stanford, and Brigham & Women’s Hospital (Harvard). GLIF is a structured representation format for modeling computer-interpretable clinical guidelines. It stresses the importance

Page 8 of 34 pages.

Peleg et al., A comparison study of guideline models

of sharing guidelines among different medical institutions and software systems. GLIF tries to build on the most useful features of other guideline models, and to incorporate standards that are used in health care. Its expression language was originally based on the Arden Syntax25 (a subsequent object-oriented expression language, GELLO26, is now being refined for consideration as a standard by HL7), and its default medical data model is based on the HL-7 Reference Information Model (RIM). GLIF identifies three levels of abstraction in modeling guidelines. At the conceptual level, guidelines are represented as human readable flowcharts similar to EON’s flowcharts. The second level forms a computable model of the guideline, which formally specifies expressions, clinical actions, the control flow of the guideline, and a medical ontology defining patient data items and medical concepts. The third level, still under development, will support implementation by mapping guideline terms to institutional electronic medical record (EMR) codes and information system procedures. GUIDE GUIDE is part of a guideline modeling and execution framework being developed at the University of Pavia. It supports (1) integrating modeled guidelines into organizational workflows, (2) using decisionanalytical models such as decision trees and influence diagrams, and (3) simulating guideline implementation in terms of Petri nets (formal model used to model concurrent systems, see “organization of guideline plan components”)27. This paper considers the guideline model as presented in the GUIDE tool, which is a graphical authoring tool that a modeler uses to create a guideline flowchart. GUIDE may call external modules representing decisions as decision trees or influence diagrams that can account for patient preferences, organizational preferences, and economic evaluations. Guidelines can be executed in three ways: (1) GUIDE can run a guideline in a simulation environment by populating the EMR with simulated patient data and running its inference engine against this EMR; (2) it can simulate the effects of implementing a guideline at a facility by translating a GUIDE guideline into Petri nets, using the Workflow Process Definition Language, and augmenting the model with a knowledge base of the facility’s organizational structure; and (3) it can drive resource allocation and task management in clinical settings by using the Oracle Workflow tool.

Page 9 of 34 pages.

Peleg et al., A comparison study of guideline models

Whenever possible, we viewed the models by using the same authoring/viewing tools that the modelers used. Thus, we used Protégé for EON, GLIF, and PRODIGY, and the Arezzo tool for PROforma. Asbru uses the AsbruView tool. We examined AsbruView screen shots showing the overall organization of guideline components (plans) and the XML code representing details of component attributes. The GUIDE team created their models using the GUIDE authoring tool. We viewed screen shots of the GUIDE model to see the organization of guideline components and looked at the relational database tables and SQL queries to examine model details.

IV. RESULTS We present the results in terms of the four dimensions that capture the structure of guideline models. 1. Organization of guideline plan components A unifying feature of the modeling schemes is that they represent the guideline recommendations as a guideline plan. The plan’s components represent decisions, actions, or hierarchically decomposed subplans of the guideline and their relationships. Different guideline models refer to plans and their components with different terminology, which can lead to confusion (Table 1). This paper uses the term plan in accordance with the definition in the Merriam-Webster dictionary: “an orderly arrangement of parts of an overall design or objective”. Guideline plans can be decomposed into plan components, which can be arranged in different ways. Plans and plan components Asbru, PROforma, and GUIDE have one type of plan in their model. PRODIGY and EON distinguish between Management Guidelines (decision/management flowcharts or transition networks) and Consultation Templates (context-dependent best-practice recommendations on actions that are always performed, data to collect or display, and patient education). GLIF Guidelines are similar to EON’s Management Guidelines, and contain similar steps. Asbru has one generic Plan class that is used to model all complex and atomic plans, as noted in the Introduction. The plans of the other models include the following plan components:

Page 10 of 34 pages.

Peleg et al., A comparison study of guideline models

Action Steps (called Tasks in GUIDE) model medical actions (e.g., prescribing a medication), or system actions (e.g., sending a message to a user). In GUIDE, tasks can access the terminology server or call an SQL query to access patient data. GLIF, PRODIGY, and EON use subclasses of Action Steps to represent different medical and system actions, including patient data retrieval. PROforma uses the Enquiry class for data retrieval that is distinct from the Action class. Decision Steps are used by all the methodologies except Asbru to model decision-making in guidelines and are discussed in the Decision Models section. PRODIGY uses Scenarios as decision points in guideline plans. A Scenario (EON and PRODIGY) is a patient state characterized by patient conditions and/or their treatment (e.g., a patient is diagnosed with hypertension and is taking low-dose thiazide)3. Scenarios serve as entry points into guidelines and are useful in multi-encounter guidelines, by which patients may enter the guideline at different places in the plan. In EON and PRODIGY, consultation templates are associated with scenarios to describe scenario-specific actions. GLIF3 defines Patient-state steps similarly as entry points and labels, which have associated eligibility criteria, but unlike Scenarios, are not associated with sub-guidelines such as consultation templates. GUIDE allows multiple entry points, associated with different eligibility criteria. Branch Steps (EON, GLIF, PRODIGY, and GUIDE) and Synchronization_Steps (EON, GLIF, and GUIDE) model parallel paths in the guideline plan. PROforma and Asbru can achieve parallel as well as sequential execution without having branch and synchronization steps (see below). A Macro is a special class in GLIF with attributes that define the information required to instantiate a set of underlying GLIF steps. The steps represent a pattern that appears in clinical guidelines. Macro steps provide a means to declaratively specify a procedural pattern in a single construct that is realized by a set of GLIF steps6. Subguideline Step (EON, PRODIGY) and Plan in PROforma and Asbru allow hierarchical decomposition of a guideline plan into subplans. In GUIDE, any task can be decomposed into a subguideline.

Page 11 of 34 pages.

Peleg et al., A comparison study of guideline models

Action Steps and Decision Steps in GLIF can be expanded into (sub)guidelines or Macros, and can thus be used to represent a complex guideline plan. Wait_Step in GUIDE is used to introduce delays. GUIDE’s Monitor task checks for conditions at specified durations. It can be used to monitor goal conditions, as explained in the section on intentions. Aspects of plan organization We examined several aspects of plan organization: (a) supporting computational models, (b) mechanisms for nesting a high-level plan into a network of lower-level plans, (c) sequential execution of plan components, (d) parallel execution of plan components, (e) cyclical and iterative plans, and (f) entry points into guideline plans. Note that sequential-, parallel-, and cyclical-execution define part of the control flow of guideline plans. The other part is modeled by decision models (Dimension 3) that conditionally direct control flow into selected branches of the guideline model.

a. Computational Models of Plan Networks The networks used by modeling methodologies to represent guideline plans have different computational models3. PRODIGY’s management guideline aims to locate a patient in a map of possible scenarios and choose an appropriate care strategy, the application of which moves the patient to a different scenario. It is fundamentally different from a care process that involves sequenced, iterative, and possibly concurrent activities occurring over time. The computational model enabling PRODIGY’s representation is an augmented transition network (ATN), a finite-state transition network that has been extended by supporting nesting (sub-guidelines) as well as by adding conditions and actions to arcs. Note that an ATN allows a single transition to occur only at a certain time point. While PRODIGY allows the selection of a single Action Step only following a Scenario, it may contain several actions (which are considered instantaneous) that affect concurrent activities. Also, the consultation template is not an ATN, as it has branching and concurrent action steps. EON and GLIF order guideline steps in flowcharts that enable concurrency through the use of branch and synchronization steps.

Page 12 of 34 pages.

Peleg et al., A comparison study of guideline models

GUIDE interprets guideline plans according to the task scheduling represented in a flowchart. At the computational level, the GUIDE inference engine accesses a relational database that maps both the parent-child relationships, existing between tasks, and the rules that must be satisfied in order to activate a task. GUIDE flowcharts may be translated into high-level Petri Nets that represent health care processes. Petri Nets are a formal models used to model concurrent systems. They consist of a directed, bipartite graph in which nodes are either places or transitions. Tokens on places define the state of a Petri Net, which can be executed as follows: when all the places with arcs pointing to a transition have a token, the transition is enabled, and may fire, by removing a token from each input place and adding a token to each place pointed to by the transition. GUIDE uses high-level Petri Nets that include extensions for modeling time, data, and hierarchies. PROforma interprets its guideline plans as constraint-satisfaction graphs, where tasks form the nodes of the graph. Tasks are related by their scheduling constraints, preconditions, and post-conditions. A task manager executing a task can assert new facts (i.e., post-conditions) into a global database and affect the activation of other tasks through evaluation of their preconditions. Any number of tasks can be activated concurrently. Asbru organizes plans in a hierarchy of refinement. Clinical protocols are represented as timeoriented, skeletal plans. Skeletal plans are plan schemata at various levels of detail, which capture the essence of the procedure, but leave room for execution-time flexibility in achieving goals. The children of a plan implement their parent by turning a declarative intention into prescriptive actions.

b. Nesting All the methodologies support nesting, which aids in keeping the top-level plans simple and allows reuse of sub-guidelines. GLIF nests action and decision steps into sub-guidelines or macros that show their detail6. EON’s management guidelines may include sub-guideline steps that recursively refine the steps into other management guidelines. In PROforma, a plan is a graph of tasks that can be recursively decomposed using subplans. Asbru plans are hierarchical decomposed, and all subplans have the same plan components (preferences, intentions, conditions, effects, and a plan body). A task in a GUIDE flowchart

Page 13 of 34 pages.

Peleg et al., A comparison study of guideline models

can be nested into a network of other plan components. In PRODIGY, a subguideline of a management guideline is a simple plan that contains only scenarios and action steps; it cannot be further decomposed. It can be specified as part of a subguideline step or as an action in an action step.

c. Sequential execution Sequential execution is supported by all of the methodologies. In GLIF and EON, action/activity, patient state/scenario, and synchronization steps specify a single step that follows preceding steps. Branch steps specify possible concurrent threads of execution by linking to several following steps. Decision steps are linked to several decision alternatives, but just one can be chosen (automatically, or by the user). Sequencing multiple Action Steps is syntactically possible in PRODIGY. In practice, however, all actions associated with one management strategy are grouped into one Action Step. Because an action step is instantaneous, one action step followed by another is equivalent to doing both concurrently. As noted in subsection (a), PRODIGY’s aim is not to describe a process of activities but to provide a map of diseasemanagement scenarios and choices of appropriate management strategies. In Asbru, sequences of plans can be represented by specifying the subplan type to be “sequentially”. PROforma governs the sequence of task execution through scheduling constraints that can be used to introduce task serialization. The example in Figure 1 specifies that the component CXR_and_initial_Rx of the plan Chronic_Cough_Guideline should not be executed until the component Initial_assessment has completed. Authoring tools may represent this relationship as an arrow from task A to B; the superficial similarity between this metaphor and a flowchart is intended to help guideline authors, but it does obscure some important aspects of the approach. First, using declarative scheduling constraints avoids procedural ‘next step’ attributes. More importantly, no additional constructs are needed to represent branching and synchronization of flow control, which are necessary to support parallel execution of tasks. Any task can assume either of these roles, or both roles simultaneously.

Page 14 of 34 pages.

Peleg et al., A comparison study of guideline models

In GUIDE, the Task, Wait, and Monitor components are followed by one or more components. Choice nodes are linked to several decision options. Only one option can be chosen upon guideline execution.

d. Parallel execution All modeling formats support parallel execution of plans and their components, although the syntax and semantics differ. GLIF supports two kinds of parallelism. Guideline steps that follow a branch step can be executed in parallel or singly, in any order. They are then synchronized by logically combining the steps that enter a synchronization step or by indicating that k of n incoming steps should finish execution before synchronization occurs. In EON, the branch step specifies that “all of” the following steps should be executed in any order, while the synchronization step waits for all active incoming steps, or proceeds after one incoming step has arrived and abandons the other incomplete threads. Asbru has three modes of parallel execution: parallel (plans wait for parallel plans to terminate before moving on to the next plan), any-order (only one plan is executed at a time, but the order is non-deterministic), or unordered (plans can be executed in parallel, but there is no synchronization among them). GUIDE supports parallelism by having multiple next steps from a task step. Like EON, GUIDE supports two types of synchronization: ‘||’ waits until one task has been completed before moving on to the next one, while in ‘&’, all the actions must be finished before the next task is executed. Parallel task execution is the default behavior in PROforma, with scheduling constraints being used to enforce serial execution. Usually, when a task has multiple scheduling constraints on its execution, they all must be met before task execution. Arbitrarily complex synchronization behavior can be modeled without synchronizing steps, because any PROforma task can have a synchronizing role as defined through its scheduling constraints. PRODIGY supports parallelism in three ways. First, branches in consultation templates are executed by the system in parallel. Synchronization is unnecessary because all actions are instantaneous and the recommended ones are presented to users, who choose among them. Second, PRODIGY’s management

Page 15 of 34 pages.

Peleg et al., A comparison study of guideline models

guidelines associate sets of concurrent actions with one Action Step. Finally, PRODIGY assumes that parallel activities, such as multiple drug regimens, occur in the background. Guideline actions initiate, change, or terminate these activities.

e. Cyclical and iterative plans All the modeling methods can combine guideline steps in directed cyclical graphs. All except PRODIGY have explicit constructs to support iteration or cycling of plans and/or plan-components: Asbru plans can be iterative or cyclical; GLIF action and decision steps can be iterative; EON actions and sub-guidelines can be iterated; all PROforma tasks can be iterated; and GUIDE’s Monitor component models iterations. Generally, iteration is specified by providing the time or trigger of the first repeat, the duration of each cycle, the repeat frequency, the maximum number of repeats, the completion condition, and the abort condition. Asbru, EON, and GLIF can define a fuzzy iteration frequency (e.g., take medication every 3-4 hours for 24 h).1 Additional details of the syntax of iterative and cyclic plans for some of the methodologies can be found in the bibliography23, 27, 28.

f. Entry points into guideline plans In implementing a multi-encounter guideline, a decision-support system may keep track of a patient’s state between encounters and form expectations about subsequent encounters. However, patient status can improve or worsen. Furthermore, treatment by other health care providers may affect a patient’s medications and conditions. Scenarios in PRODIGY and EON and patient-state steps in GLIF can place entry points into a guideline plan or use them simply for labeling purposes. Any scenario/patient-state step has a precondition that must hold for a patient to be in that scenario/state. The fact that patient states are represented as plan components is important in EON, PRODIGY, and GLIF. PRODIGY and EON scenarios define the context in which actions in a consultation template are appropriate. In these approaches, scenario/patientstate steps help the decision-support system locate a patient in the guideline plan. Furthermore, representing scenarios/patient-state steps as explicit guideline components has utility when creating a guideline model and browsing it. Domain experts find them intuitive, and the diagram of scenarios/action steps

Page 16 of 34 pages.

Peleg et al., A comparison study of guideline models

gives authors and others a rapid overview of guideline content. This is not possible when only criteria are used to infer patient states. Asbru and PROforma do not have specialized constructs representing patient states. Instead, any plan component whose precondition holds can be executed. Therefore, if a guideline encompasses several patient encounters, each encounter can start at a different place in the guideline plan, which corresponds to the state of the patient at that encounter. As mentioned before, GUIDE allows enrolling of patients at different points of a guideline, thus recognizing different initial states. In multi-encounter deployment, guidelines in GUIDE are translated into workflow processes. A workflow manager follows a patient’s location in the guideline plan. Control flow can be directed appropriately with expressions that refer to patient data items describing the patient state. When a user does not follow guideline recommendations, the workflow manager resynchronizes guideline flow to the new situation. Resynchronization is modeled explicitly in the workflow model. 2. Specification of goals/intentions Guideline modeling methods can be partitioned into two groups, based on how they model guideline intentions. Asbru, EON, PROforma, and GUIDE model intentions as formal expressions, while PRODIGY and GLIF specify goals as text strings. Formally specified intentions can be used to control the executionstate of plans.

a. Representing intentions as formal expressions Asbru guideline encoders can represent intentions as context-dependent temporal patterns (e.g., “give three courses of chemotherapy within three months”). Encoders can specify that an intention achieve/maintain/avoid a state/action during the plan’s execution or after it has terminated. Thus, Asbru can specify 3*2*2, or 24 different types of intentions. Complex plans as well as primitive actions can have intentions. Maintain-intentions specify conditions that should hold during plan execution. Encoders can specify an intention that must hold solely at

Page 17 of 34 pages.

Peleg et al., A comparison study of guideline models

the start of a plan by using a maintain-intention and specifying a short time annotation with it, such as “only in the first second of the plan’s execution”. Figure 2 shows an intention expressed in Asbru. Management guidelines in EON may have steps specifying composite goals that decomposes into AND/OR trees of subgoals or single goals specifying criteria to be achieved, maintained, or avoided. In an AND-tree, all subgoals should be satisfied. In an OR-tree, subgoals should be selected if their associated selection conditions are true. A goal criterion can be any Boolean expression. Goal satisfaction and failure are used as decision criteria to select actions. Additionally, plans associated with management guidelines in EON have completion criteria. When the completion criterion of a plan evaluates to true, plan execution terminates. Any task in PROforma can have a goal attribute specifying a formal criterion and defined operational semantics. An active task terminates automatically when its goal becomes satisfied. In addition, if a task’s goal is already satisfied when the scheduler considers it for execution, the task is automatically skipped. When a high-level task is terminated, its actively executed tasks terminate. Goals in GUIDE can be formally represented in a Monitor task (i.e., a loop that terminates only when either a certain threshold for a variable or a deadline is reached). GUIDE measures the monitored variable with a certain frequency, and the modeler can specify actions that should occur. Monitor tasks represent goals for a specific patient. In addition, GUIDE developers use natural language to express populationlevel goals (e.g., “reduce costs while maintaining the care quality”). A developmental version of GUIDE will allow linking population-level goals to appropriate statistical procedures.

b. Representing intentions as text PRODIGY and GLIF specify goals in text. PRODIGY’s Guideline class has an intention slot, whereas in GLIF, both guidelines and action specifications have an intention slot. In both methodologies, the slot is filled with free text. Because of this approach, formally specifying consequences of goal fulfillment or failure is not possible.

Page 18 of 34 pages.

Peleg et al., A comparison study of guideline models

3. Model of guideline actions The methodologies in this study represent guideline plans by creating networks of plan components. Some of the plan components are used mainly for flow of control purposes (e.g., branch and synchronization), while others define tasks that should be carried out (e.g., action, decision, enquiry). Table 2 summarizes the characteristics of guideline actions. Among the characteristics of actions enumerated in the table, nesting and iterative and cyclic actions were discussed in the section on organization of guideline plan components.

a. Structured medical actions While all the guideline models can specify medical actions, not all of them do so with specialized structured classes. In GLIF, guideline encoders specify medical actions by defining the attributes of a Patient Data item according to the data model of the HL7 RIM29. In the HL7 RIM, all clinical data are specified as Act objects, or Acts. Act attributes provide information about clinical concepts and their timing. They are specialized into patient-related procedures, observations, and medications. Different sub-classes contain additional attributes. For example, Observation has a value attribute, whereas Medication has attributes about dosage and route of administration, among other things. Acts use codes representing clinical actions and are taken from a controlled medical vocabulary. Act objects have a mood that distinguishes how they can be conceived: as an event that occurred, a definition, intent, order, etc. Therefore, an encoder can use the Observation class in the “order” mood to order a laboratory test, or use that class in the “event” mood to refer to results of the test. In GUIDE, task names can be specified as SNOMED codes. EON and PRODIGY can represent many specialized medical actions. They include referrals, acute prescriptions, scheduling, asserting conclusions, and modifying drug treatments. Different medical action classes contain slots for mapping their instances into controlled vocabulary terms.

b. Action refinement In EON, guideline encoders use the action-refinement mechanism to specify the drug-prescription actions in increasing levels of detail. The encoder specifies a drug category. For every category, the en-

Page 19 of 37 pages.

Peleg et al., A comparison study of guideline models

coder can specify knowledge about contraindications and indications, interactions with other drug categories, and the preferred formulary drug in the category. This drug is specified separately by giving its generic and trade names and the starting and maximum doses, in addition to specifying contraindications and indications. In PRODIGY, refinement of drug choice is made from drug class to a specific drug, and then to prescription details, accounting for drug interactions, contraindications and patient sensitivities. Preference strategies that account for previous use of the drug, formulary status, and guideline-specific criteria suggest the best product choice. The other guideline models can provide similar functionality of action refinement by defining a subguideline (plan in PROforma and Asbru, task in GUIDE) that expands the details of a drug-order action. The expansion is done in three steps. First, encoders choose the drug category, then the preferred drug, and lastly, prescription details. EON and PRODIGY can also use sub-guidelines for action refinement.

c. Temporal constraints All the guideline models can specify constraints on the start time of guideline plan components. End time constraints can also be defined in Asbru, GUIDE, PRODIGY, and PROforma. In PRODIGY, Action Steps are only relevant in a ‘relevance window’ – an interval of (earliest start time, latest end time). In GLIF, encoders can specify events that trigger the execution of action and decision steps. They can also specify earliest and latest temporal constraints on the start time of these steps, relative to the time of the triggering event. Modelers using Asbru can specify the earliest and latest start and finish times of a plan. In PROforma, scheduling constraints can cause deliberate delays in task execution time. In addition, tasks can be composed alongside a meta-control action that defines start and end times. In GUIDE, Wait steps can delay the execution of subsequent steps, achieving the same effect as specifying start time constraints in GLIF and Asbru.

Page 20 of 37 pages.

Peleg et al., A comparison study of guideline models

Constraints on the end time of GUIDE’s monitor task can be expressed by specifying iterationduration (frequency) and a termination-condition (which could be a temporal condition) of the monitoring task. EON and PRODIGY make a distinction between instantaneous actions (e.g., prescribing a medication) and activities with durations (e.g., administering a medication over time). In GLIF, GUIDE and Asbru, a single class represents actions and activities: Action in GLIF, Task in GUIDE, and Plan in Asbru. They can be either instantaneous or persistent. Actions in EON and PRODIGY do not have a specified duration, while activities are represented as actions with duration. Guideline encoders can specify minimum and maximum temporal constraints on the duration of activities in GLIF, EON, Asbru, and PRODIGY (specific activity classes in PRODIGY). Asbru and GUIDE can define constraints on the valid times of values stored in the EMR that are used by guideline tasks. If a value was stored prior to the valid time, it is not valid any longer, and is not used by the guideline task. In this case, the GUIDE inference engine asks the user to enter the value. In other models, the encoder can specify the time period within which the retrieved value must fall.

d. System actions All methodologies model patient data queries and message sending in roughly the same way. Actions1 in Asbru, GUIDE, PROforma, and GLIF can accept parameters and return results. In Asbru, a plan’s knowledge roles, such as complete and abort conditions, can be inherited from other plans. In other guideline models, action instances cannot inherit information from other action instances. All systems can assign variables with values. Asbru, GUIDE, PROforma, and GLIF have explicit notions of variables to which values can be assigned. EON can evaluate definitions to conclude that certain conditions are present for a particular patient. A PRODIGY guideline author can create abstractions by assigning results of data entry and EMR queries to parameters. An example is calculating Body

1

Actions are termed Action in GLIF, Plan in Asbru, and Task in PROforma and GUIDE

Page 21 of 37 pages.

Peleg et al., A comparison study of guideline models

Mass Index from height and weight, which uses a procedural language. A single value can be returned, which can then be used as a value (e.g., BMI = 23) or converted into a range (e.g., BMI low, normal or high).

e. Representing and reasoning with effects of actions Asbru and PROforma are the only modeling languages that support expression of the effects of a plan and reasoning about plans based on effects. In Asbru, plan effects can be used to select among alternative plans and to express causal relationships (e.g., chronic cough is caused by PNDS with a likelihood of 0.33). PROforma’s post-conditions are similar to Asbru’s effects but they are used as assertions that become true after an action is completed. They affect activation of other subsequent tasks but cannot be used for creating plans (i.e., selecting actions based on their effects). 4. Decision Model The guideline modeling methodologies use a variety of decision models. The decision models range from simple if…then…else or switch constructs to complex models such as decision trees. Many modeling methodologies support multiple decision models.

a. Switch constructs as a decision model A switch construct tests whether an expression matches one of a number of constant values and branches accordingly (does Age > 18 years match {true, false}?). GLIF and EON have a switch construct, called Case Step, which directs control flow to a new destination. In GLIF, one of the possible destinations can be marked as a default that is chosen when the switch’s expression does not evaluate to the constant values to which it is compared. The GUIDE model has a “deterministic one-of” choice among different alternatives, which is similar to a switch construct. Modelers specify a criterion for each decision option. The criteria of the decision options linked to one “deterministic one-of” construct are mutually exclusive, and only one can be chosen. In PROforma, alternative tasks are modeled as tasks that can be executed in parallel, and selection among them is modeled with mutually exclusive preconditions that depend on the result of a decision

Page 22 of 37 pages.

Peleg et al., A comparison study of guideline models

task. In Asbru, as in PROforma, a guideline modeler can represent a decision as unordered plans that have different preconditions and specify that only one (“wait for 1”) of the unordered plans be executed. Switch constructs can be modeled in PRODIGY with mutually exclusive argumentation rules for different decision alternatives, as described in the next subsection. Unlike GLIF and EON, where the switch construct has the added semantics of automatic execution of the selected tasks, all decisions in PRODIGY require user confirmation. See subsection h.

b. Argumentation rules for/against choice alternatives PROforma, PRODIGY, EON, and GLIF use argumentation rules to express preferences for alternative results of a non-deterministic choice. A non-deterministic choice is a decision where more than one alternative may be justifiable for a patient. Each alternative of a non-deterministic choice can have four kinds of rules:

1. Rules that strictly exclude the alternative 2. Rules that argue against the alternative 3. Rules that argue for the alternative 4. Rules that confirm or expresses strong preference the alternative The “result-of” construct of PROforma provides an explicit and flexible way of managing control flow. It captures argumentation rule constructs and the switch construct. In PRODIGY, argumentation rules are written on Action_Step choices that follow a Scenario (Figure 3). GLIF and EON use Choice_Steps that have several decision options. The rules are written on the objects that relate the Choice Step to its alternatives. For example, the following GLIF rule is taken from the hypertension guideline model. The rule excludes a proposed additional drug if it is contraindicated for the patient or is a bad drug partner to another drug being taken by the patient. proposedDrugs is in contraindicatedDrugs or proposedDrugs is in badDrugPartners

Page 23 of 37 pages.

Peleg et al., A comparison study of guideline models

An EON rule that checks for ACE inhibitor contraindications is shown below. The ?condition term represents a note entry specifying a patient’s medical condition, and ?problem represents medical_conditions in the medical concept hierarchy (see companion paper30). (not (exists ?condition (exists ?problem (and (Absolute_Contraindications ACE_Inhibitor ?problem) (subclass-of (domain_term ?condition) ?problem) ))) Medical knowledge representing contraindications, indications, and drug interactions is modeled in PROforma as part of arguments for decision alternatives. In GLIF and EON, modelers can represent this knowledge as relationships between concepts. GUIDE can represent knowledge in relational database tables. Medical knowledge is not represented as part of Asbru’s guideline model, but Asbru can access medical knowledge by using function calls. PRODIGY models this knowledge using the rule-in, rule-out, greyed-in, and greyed-out conditions shown in Figure 3. In addition, it can represent medical knowledge using a drug-ontology, or it can use special queries to refer to outside sources of information. EON has several mechanisms for modeling choices. In addition to the switch construct and choice step, it has an action, the task of which is to evaluate adding, deleting, modifying, or substituting an intervention. The output of such an action is a list of indications and contraindications for a candidate intervention. The EON group is exploring another way to model choices with an evaluation function. This function is modeled as a step that has a list of candidates, and rule-in and rule-out rules that act on all the candidates to evaluate the choice of modifying an activity, substituting it, deleting it, or adding it. For example, the step “Evaluate second anti-hypertension agent to be added to an already active antihypertensive agent” might have a list of candidates including ACE inhibitors, beta-blockers, and thiazide diuretics. Assume that a user considers prescribing a second anti-hypertensive agent. The rule-in could be “find indicated drugs in the list of candidates” and the rule-out could be “find contraindicated drugs in the list of candidates”. The rules are formally expressed in EON’s criteria languages. The in-

Page 24 of 37 pages.

Peleg et al., A comparison study of guideline models

tention is that in the future the evaluation function could be applied to a set of dynamically generated alternatives.

c. Decision Trees and Influence Diagrams GUIDE has a model that uses decision trees or influence diagrams to represent non-deterministic choices27. GUIDE provides a link to Java applets that build and use decision trees or influence diagrams that are specific to a situation addressed in a guideline. When a guideline user makes a decision, within a non-deterministic one-of choice, she may select one of the choices or ask for help. When help is requested, a decision tree or influence diagram, the location of which is specified by a URL, can be invoked. Once a decision tree is requested, it must be instantiated with probabilities and utilities. This process is partially automatic (for information that may be stored into a static database table, such as test characteristics, namely sensitivity, specificity and cost). Other data are provided by the EMR or the user though utility assessment tools. These models can be used, for example, to calculate incremental cost-effectiveness or cost-utility ratios. Different considerations such as cost or life expectancy may influence the utility of a choice alternative. The final recommended alternative is calculated based on the expected utility for each possible alternative.

d. Calling external functions to make a decision In some cases, a guideline encoder may not wish to represent a decision as part of his model. Instead, he may wish to implement the decision by calling external functions. In GUIDE, external functions can be called to compute the expected utility for each possible choice. Asbru can use external functions to make decisions. Arezzo, the commercial version of PROforma, has an API that permits any application to interact with external Prolog functions at any time through actions and enquiries. GLIF’s new expression language, GELLO26, has user-defined classes which can be used for making external function calls.

e. Expressing preferences for alternatives to a choice

Page 25 of 37 pages.

Peleg et al., A comparison study of guideline models

These methodologies use varying methods to express preferences for alternatives. EON, PRODIGY, GLIF, and PROforma can perform symbolic preference ranking of alternatives. PROforma has a method for converting symbolic preferences that are based on argumentation rules into weighted numeric preferences. In Asbru, preferences can be used to select alternative plans based on costs, utility, or resource constraints. In PRODIGY, the default alternative action, when none of the argumentation rules apply, can be marked as “preferred”, (Figure 3). In PRODIGY, alternatives can also be ranked based on cost. In GUIDE’s non-deterministic choice, preferences can be used to compute expected utilities using a decision tree or an influence diagram.

f. Extensibility of the decision model The extensibility of the decision models in the methodologies varies widely. PROforma stresses the importance of formal semantics for its guideline-modeling language. An extensible decision model requires corresponding extensible semantics, which are difficult to develop. Therefore, PROforma is a non-extensible language. Instead, PROforma developers concentrated on making PROforma’s decision model expressive and flexible. Choice options can be generated dynamically using firstorder “generation” rules in Arezzo, PROforma’s toolkit. Multiple candidates can be chosen simultaneously if required. In contrast, GUIDE, EON, PRODIGY, and GLIF provide an extensible decision model. Their philosophy is that extending the modeling language to represent a new kind of decision model is legitimate. These methodologies do not have formal semantics that must be updated. Asbru does not have a decision model. Instead, Asbru plans call external decision-functions to make decisions. Asbru can achieve branching control-flow through plans that have mutually exclusive preconditions (subsection a).

g. The relationship between decision-making and commitment to a decision alternative In all of the methodologies except for PROforma’s, decision-making is explicitly coupled to commitment to a decision alternative. In PROforma, action sequencing is governed by satisfying scheduling constraints and preconditions of individual tasks, rather than through the use of explicit ‘go

Page 26 of 37 pages.

Peleg et al., A comparison study of guideline models

to’ relationships between tasks. If the result of a decision is intended to govern subsequent tasks, the decision’s outcome can be referred to in the preconditions of relevant subsequent tasks.

h. Authorizing decisions All of the groups recognize that user intervention or confirmation may be required during the decision-making process.

EON, GLIF and GUIDE distinguish between deterministic and non-

deterministic decisions in this respect, with non-deterministic decisions always requiring user confirmation. The behavior of deterministic decisions in GUIDE is defined at the authoring stage – it provides an attribute to specify whether an individual decision should be executed with or without confirmation. In contrast, GLIF and EON allow the behavior of deterministic decisions (case steps)

to be defined globally at run time as either automatic or requiring user confirmation. All tasks in PROforma, including decisions, have an attribute called “Automatic” which is set to “Yes” or “No” at the authoring stage. If a task’s “automatic” attribute is set to “No”, or there is insufficient information available to choose between two or more candidates automatically, user intervention is required. Asbru takes a similar approach with each plan having an “activate mode” be manual or automatic. In Asbru, if the user does not answer within an allotted time, the plan is rejected. Decisions in PRODIGY always require confirmation. PRODIGY’s developers believe that a user should always be able to override a system’s recommendation, not only because a decision-support system is always working with less patient information than the user, but also because the professional autonomy of clinicians should be maintained. This functionality is desired as support for a clinical chronic disease encounter. A different application (e.g., a background process monitor) might demand different functionality.

V. DISCUSSION One important aim of this study was to find common components that the computer-interpretable guideline (CIG) community could adopt as standards. If it is possible to map large parts of the different methodologies to a common representation, then sharing parts of encoded guidelines across different

Page 27 of 37 pages.

Peleg et al., A comparison study of guideline models

CIG models might be feasible. Indeed, we found consensus on a number of components. They include: plan organization, expression and query language, a conceptual medical record model (we refer to this as the Virtual Medical Record), a medical concept model, and data abstractions. Our companion paper30 discusses the last four components. All the guideline models support nesting of plans, as well as arranging plan components in sequence, in parallel, and in iterative and cyclic structures. In addition, all the models support expression of temporal constraints on plan components. We propose adoption of a common model for expressing the flow of the guideline process. As part of the Health Level Seven (HL7) Clinical Decision Support Technical Committee (CDSTC), Some of us have been looking at the Worfkflow Management Coalition’s (WfMC) Workflow model as a common process model31. The Workflow model has constructs for expressing nesting, loops, actions (activities), branching, and synchronization, and can express temporal constraints on these components. By specializing specific actions into enquries, scenarios, and decisions, the different guideline models should be able to map to this formalism. The team that develops the GUIDE model actually maps its guideline flowchart to this Workflow model. We see two major benefits to basing our process model on the WfMC’s Workflow model. First, this model is already a tested standard of the WfMC. Second, the Workflow model has a mapping to Petri Nets – a formal mathematical model that enables verification of desired properties of the modeled guideline. These properties include the following: a) Liveness: All actions can be enabled; b) Boundedness: In every place, the number of tokens is always less than n; c) Reachability: Given a certain state of a Petri net, one can determine whether another state is reachable. Agreeing on a standard set of plan components would not be necessary in order to share definitions of process flow. In any case, due to the large variation in plan components, standardizing them does not seem feasible at this time.

Page 28 of 37 pages.

Peleg et al., A comparison study of guideline models

Other areas that do not currently lend themselves well to standardization due to large variability among the models are: (a) the model of intentions, (b) decision models – no standard decision model is emerging but most of the models support the notion of an extensible decision model, and (c) the use of Scenarios (Patient State Steps). Our study has two main limitations. The first relates to the dimensions of comparison that were not covered. The studied dimensions capture the logic of guideline modeling, but do not capture the following: •

Documentation attributes such as methods of evidence-collection. GEM32 is a formalism that

focuses on documentation attributes. As part of the HL7 Clinical Decision Support Technical Committee, we are working on standardizing documentation attributes. The models under study would benefit from them considerably. •

The execution semantics of the guideline models. We studied the expressiveness and syntax,

but not how they are used to encode guidelines that are part of real clinical decision-support systems, or the particular classes of intended applications that motivated the choice of features in the various modeling languages. Adding a new feature to a model is easy, but it may not be practically implementable, or it may add such complexity to a model as to make its learning curve too steep. Thus, a feature-rich model may not be the model of choice for many users. Furthermore, a feature may have hidden limitations that are not uncovered until used by clinicians. In this respect, we are limited by the fact that neither GLIF nor Asbru has a currently working execution engine. •

Complexity management for easing human comprehension, visualization, and authoring tools.

All the modeling methods that we compared use authoring-tools to create a graphical layout of guideline-plans to ease human comprehension. In addition, the guideline modeling methods use other methods to control the complexity of guideline knowledge to facilitate its comprehension. Some of these methods were discussed in this paper. They include: (1) nesting in all of the methodologies, (2) separation of guideline knowledge into management guidelines and consultation tem-

Page 29 of 37 pages.

Peleg et al., A comparison study of guideline models

plates in EON and PRODIGY (in the section on organization of guideline plan components), and (3) action refinement (in the section on model of guideline actions).

The second limitation concerns the case study examples. We compared only portions of guidelines. Moreover, we used only two guidelines for the comparison. Although we believe that these guidelines represent a variety of situations that often arise in narrative guidelines, we cannot be sure that we covered all of them. Several studies have addressed classification of guidelines33, 34. However, their classification is based on clinical distinctions (e.g., clinical area, and clinical setting). Most of these classification schemes do not classify guidelines in terms of an engineering-perspective relating to the types of modeling problems. The classification of Bernstam et al.33 does address some engineering-oriented issues, including a ranking of computability, but the ranks are not defined by formal criteria. When choosing the guidelines for our case study, we looked for those that addressed the eight dimensions we evaluated. Collectively, the two guidelines that we chose cover all of these dimensions.

ACKNOWLEDGEMENTS: The authors from Stanford, Columbia, and Harvard universities are supported in part by Grant LM06594 with support from the Department of the Army, Agency for Healthcare Research and Quality, and the National Library of Medicine. The Asgaard Project is supported by Fonds zur Foerderung der wissenschaftlichen Forschung (Austrian Science Fund), grant P12797-INF. The work done by the GUIDE team has been partially funded by the European Commission through the project PatMan (Health Care Telematics Applications Programme).

Page 30 of 37 pages.

Peleg et al., A comparison study of guideline models

REFERENCES 1. Overhage JM, Tierney WM, Zhou XH, McDonald CJ. A Randomized Trial of "Corollary Orders to Prevent Errors of Omission." JAMIA 1997;4(5):364-375. 2. Shea S, DuMouchel W, Bahamonde L. A Meta-analysis of 16 Randomized Controlled Trials to Evaluate Computer-based Clinical Reminder Systems for Preventative Care in the Ambulatory Setting. JAMIA 1996;3(6):399-409. 3. Tu S, Musen M. Representation Formalisms and Computational Methods for Modeling Guideline-Based Patient Care. First European Workshop on Computer-based Support for Clinical Guidelines and Protocols; Leipzig, Germany; 2000:125-142. 4. Starren J, Hripcsak G, Jordan D, Allen B, Weissman C, Clayton PD. Encoding a post-operative coronary artery bypass surgery care plan in the Arden Syntax. Comput. Biol. Med. 1994;24(5):411 - 417. 5. Shiffman RN. Representation of Clinical Practice Guidelines in Conventional and Augmented Decision Tables. JAMIA 1997;4(5):382-393. 6. Peleg M, Boxwala A, Ogunyemi O, Zeng Q, Tu S, Lacson R, et al. GLIF3: The Evolution of a Guideline Representation Format. Proc AMIA Symp 2000:645-649. 7. Johnson PD, Tu SW, Booth N, Sugden B, Purves IN. Using Scenarios in Chronic Disease Management Guidelines for Primary Care. Proc AMIA Symp 2000:389-393. 8. Tu SW, Musen MA. A Flexible Approach to Guideline Modeling. Proc AMIA Symp 1999:420-424. 9. Fox J, Rahmanzadeh A. Disseminating medical knowledge: the PROforma approach. Artificial Intelligence in Medicine 1998;14:157-181. 10. Shahar Y, Miksch S, Johnson P. The Asgaard Project: A Task-Specific Framework for the Application and Critiquing of Time-Oriented Clinical Guidelines. Artificial Intelligence in Medicine 1998;14:29-51. 11. Quaglini S, Stefanelli M, Lanzola G, Caporusso V, Panzarasa S. Flexible Guideline-based Patient Careflow Systems. Artificial Intelligence in Medicine 2001;22:65-80. 12. Bury J, Fox J, Sutton D. The PROforma guideline specification language: progress and prospects. Proc First European Workshop, Computer-based Support for Clinical Guidelines and Protocols, Leipzig; 2000. 13.Elkin P, Peleg M, Lacson R, Bernstam E, Tu S, Boxwala A, et al. Toward Standardization of Electronic Guideline Representation. MD Computing 2000;17(6):39-44. 14. Wang D, Peleg M, Tu SW, Shortliffe EH, Greenes RA. Representation of Clinical Practice Guidelines For Computer-Based Implementations. Proc MedInfo 2001:285-289.

Page 31 of 37 pages.

Peleg et al., A comparison study of guideline models

15. Irwin RS, Boulet LS, Cloutier MM, Gold PM, Ing AJ, O'byrne P, et al. Managing Cough as a Defense Mechanism and as a Symptom, A Consensus Panel Report of the American College of Chest Physicians. Chest 1998;114(2):133S-181S. 16. National Institute of Health. The Sixth Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure: National Institute of Health; 1997 Report No.: 98-4080. 17. Fox J, Johns N, Rahmanzadeh A, Thomson R. PROforma: A method and language for specifying clinical guidelines and protocols. Proc. Medical Informatics Europe; Amsterdam; 1996. 18. Grosso WE, Eriksson H, Fergerson R, Gennari JH, Tu SW, Musen MA. Knowledge Modeling at the Millennium (The Design and Evolution of Protege-2000). Gains BR, Kremer R, Musen M, editors. The 12th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop. 1999: 7-4-1 to 7-4-36. 19. Johnson P, Tu S, Jones N. Achieving Reuse of Computable Guideline Systems. Proc Medinfo 2001:99-103. 20. Tu SW, Musen MA. From Guideline Modeling to Guideline Execution: Defining Guideline-Based Decision-Support Services. Proc AMIA Symp 2000:863-867. 21. Tu SW, Musen MA. Modeling Data and Knowledge in the EON Guideline Architecture. Proc Medinfo 200: 280-284. 22. Fox J, Das S. Safe and Sound. AAAI Press; 2000. 23. Seyfang A, Kosara R, Miksch S. Asbru's Reference Manual, Version 7.3: Vienna University of Technology, Institute of SoftwareTechnology, Vienna; 2002. Report No.: Asgaard-TR-2002-1. 24. Kosara R, Miksch S. Metaphors of movement: a visualization and user inter-face for time-oriented, skeletal plans. Artificial Intelligence in Medicine 2001;22(2):111-131. 25. Hripcsak G, Ludemann P, Pryor TA, Wigertz OB, Clayton PD. Rationale for the Arden Syntax. Comput Biomed Res 1994;27(4):291-324. 26. Ogunyemi O, Zeng Q, Boxwala A, Greenes RA. Object-oriented guideline expression language (GELLO) Specification: Brigham and Women's Hospital, Harvard Medical School, Boston; 2002. Decision Systems Group Report No.: DSG-TR-2002-001. 27. Quaglini S, Dazzi L, Gatti L, Stefanelli M, Fassino C, Tondini C. Supporting tools for guideline development and dissemination. Artif Intell Med 1998;14(1-2):119-37. 28. Peleg M, Boxwala A, Ogunyemi O, Zeng Q, Tu S, Lacson R, et al. GLIF3 Technical Documentation. In: http://smi-web.stanford.edu/projects/intermed-web/guidelines/GLIF1.htm. 2000. 29. Schadow G, Russler DC, Mead CN, McDonald CJ. Integrating Medical Information and Knowledge in the HL7 RIM. Proc AMIA Symp 2000:764-768.

Page 32 of 37 pages.

Peleg et al., A comparison study of guideline models

30. Peleg M, Tu SW, Bury J, et al. Comparing models of data and knowledge for guideline-based decision support: a case-study approach. Submitted to JAMIA 2002. 31. Layna Fischer (Ed). Workflow Handbook. Future Strategies Inc., Lighthouse Point, FL, USA.; 2002. 32. Shiffman RN, Karras BT, Agrawal A, Chen R, Marenco L, Nath S. GEM: a proposal for a More Comprehensive Guideline Document Model Using XML. JAMIA 2000;7(5):488-498. 33. Bernstam E, Ash N, Peleg M, Tu S, Boxwala AA, Mork P, et al. Guideline classification to assist modeling, authoring, implementation and retrieval. Proc AMIA Symp 2000:66-70. 34. Field MJ, Lohr KN. Guidelines for Clinical Practice: From development to use. Washington DC: Institute of Medicine, National Academy Press; 1992.

Page 33 of 37 pages.

Peleg et al., A comparison study of guideline models

Table 1. Terms used by guideline modeling methodologies to refer to plans and actions. Asbru PROforma PRODIGY

EON

GLIF

GUIDE

Plan Plan Plan Decision/ Management map Subguideline Consultation Template Management Guideline Consultation Guideline SubguidelineStep Guideline, Macro)

Action_Step, Decision_Step Guideline

Plan component (sub)Plan, primitive plan Tasks (Action, Decision, Enquiry, Plan) Scenario, Action_Step, Subguideline_Step Consultation_Action_Step Consultation_Branch_Step Action_Step, Subguideline_Step, Decision, Scenario, Synchronization_Step, Branch_Step, End Consultation_Action_Step Consultation_Branch_Step Management_Guideline Guideline_Step (Branch_Step, Synchronization_Step, Action_Step, Decision_Step, Patient_State_step) Guideline or Macro task, wait, monitor, deterministic decision, nondeterministic decision, synchronization &, synchronization || (OR)

Page 34 of 37 pages.

Peleg et al., A comparison study of guideline models

Table 2. Characteristics of actions that are modeled by different guideline modeling methodologies. Structured medical actions Action refinement

System actions Nesting Temporal constraints on actions/activities Actions accept arguments Actions return values

Variables assignment actions Iterative and cyclical actions Representing and reasoning with effects of actions

Asbru + +

GLIF +

EON + (Struc-

(Structured)

tured)

+

+ + See (1) +

+ + See (1) +

+ +

+ + See (1) +

PRODIGY +

PROforma +

(Structured)

+

+

(Using concept model)

(Using concept model)

+ + See (1) +

+ + See (1) +

GUIDE + (Structured)

+

+ (Using concept model)

+ + See (1) +

+ + See (1) +

+

+

+

+ from subguideline to higher-level decision +

+ (decision)

+

+

+

+

+ See (1)

+ See (1) +

+ See (1)

+ See (1)

Page 35 of 37 pages.

Peleg et al., A comparison study of guideline models

plan:: Chronic_Cough_Guideline; component:: Initial_assessment; component:: CXR_and_initial_Rx; schedule_constraint:: completed(Initial_assessment); Figure 1. A scheduling constraint in PROforma.

Page 36 of 37 pages.













Figure 2. Expressing intentions in Asbru. The “hypertension-treatment” plan has an intention of achieving an overall state of normal systolic blood pressure within one month of the plan’s execution.

Page 37 of 37 pages.

Peleg et al., A comparison study of guideline models

Figure 3. The PRODIGY choice model. Note therules for and against giving diuretics to a patient who is already on an ACE Inhibitor. The “Rule-in condition” expresses strong preference for an alternative. The “greyed-in condition” is a possible argument for the alternative. The “greyed-out condition” is an argument against the alternative”. The “rule-out condition” is a rule excluding the alternative. These rule-in and ruleout conditions are objects that include formal criteria that can be evaluated against patient data and natural language descriptions of the criteria. The figure shows only the natural language form. In case none of the rule-in, rule-out, greyed-in and greyed-out conditions apply, one of the alternatives of a choice can be marked as “preferred” by default.

Suggest Documents