Rules Engine Technologies Across caBIG**^tm^** Workspaces

**Written by members of the Strategic Planning Workspace**

**Joel Saltz, Joyce Niland, Philip Payne, Hemant Shah and Douglas
Stahl**

#  [1. Introduction ]{.underline}

With the emergence of new biological, clinical, and informatics
methodologies targeting translational research, workflow complexity and
the associated need for computer-automated processes has increased
significantly. The Architecture Workspace has responded to this
requirement by incorporating rudimentary workflow capabilities into
caGrid 1.0 and through a continued process of workflow design and
development. The workflow capabilities incorporated in caGrid make use
of the well accepted BPEL standard (described below) and address
computation and data access, but do not yet attempt to address broader
requirements that arise from the need to coordinate the complex
interrelated set of activities required to carry out translational
research studies. We advocate an evolutionary approach in which
caBIG^tm^ would continue to use the workflow language (BPEL) for coarse
grain process orchestration and use one or more rules engines for "deep
analysis", and expose the business rules as services.

The purpose of this white paper is to provide an overview of available
rules engine technologies and to: 1) initiate a process of evaluating
the need for rules engine technologies across caBIG™ workspaces, 2)
begin a process of exploring the match between existing rules engine
technologies and workspace requirements, and 3) begin a process of
investigating how rules engine technology can be layered on the ongoing
BPEL-based workflow effort. The white paper will summarize the current
state of knowledge concerning rules-engine technologies and to introduce
use-case scenarios that illustrate potential application areas for
rules-engine technologies within caBIG™.

This white paper outlines three case studies, contributed by the broader
caBIG community, which can be used to motivate an initial detailed
examination of the need for rules engines and the relationship between
rules engines and a BPEL-based workflow specification. These case
studies involve: 1) adverse event (AE) reporting, 2) the in-vivo imaging
testbed, and 3) radiation treatment planning.

This white paper also outlines a process for systematically evaluating
whether rules engines can provide a useful supplement to BPEL in
describing complex care plan/protocols consisting of both complex
control thread structures, and complex rules for guiding the traversal
of these process threads.

The following sections of the whitepaper specifically expand upon the
preceding themes, providing:

-   **Section 2:** An overview of pertinent definitions used throughout
    the whitepaper

-   **Section 3:** A survey of knowledge representation (KR) schemes for
    rule engine systems

-   **Section 4:** A survey of rule execution engines

-   **Section 5:** A summary of caBIG community generated use cases for
    a rules engine system

-   **Section 6:** A set of recommendations for a caBIG rules engine
    system

-   **Section 7:** Concluding remarks

# [2. Definitions ]{.underline}

In order to provide a common scope of reference for the remainder of
this whitepaper, we will begin by defining:

1)  rules engine,

2)  workflow,

3)  a knowledge representation model, and

4)  an inference or execution engine

We will then go on to provide example instances in which a rules engine,
comprised of a knowledge representation model and inference or execution
engine, could be applied.

[2.1 Rules Engine]{.underline}

We define a rules engine per the conventions introduced by Shortliffe et
al. as a "software component of a rule-based system that assesses
individual rules and determines their applicability in a specific case
or situation." \[1\]. We will go on to then extend this definition in
order to specify that rules engines are most applicable to those
situations where the required logic (e.g., rules) is sufficiently
dynamic to cause the inclusion of such logic in the source code of
software to be impractical, thus necessitating the need for an
externalized rules engine facility \[2\]. At the most basic level, a
rules engine is comprised of two components, a knowledge-base
(consisting of rules represented in a computational format), and an
inference or execution engine which can reason about incoming data based
upon the contents of the knowledge-base in order to generate some form
of output such as an instruction set or alert. An additional critical
component of a rules engine is the knowledge engineering facility, which
provides the capability to curate the contents of the knowledge-base on
an automated, semi-automated, or manual basis. This architecture is
reflected in figure 1.

![](media/image1.jpeg){width="3.997916666666667in"
height="2.5972222222222223in"}

Figure 1: Basic rules engine architecture, including a knowledge-base
and execution or inference engine. In this scenario, incoming data (1)
is reasoned upon by the execution or inference engine using the rules
encoded in the knowledge-base (2), in order to generate some form of
output (3), such as instructions or alerts. An addition critical
component of this architectural model is the knowledge engineering
facility, which allows for the automated, semi-automated, or manual
curation of the contents of the knowledge-base.

[2.2 Workflow]{.underline}

Workflow is concerned with the modeling and coordinated execution of a
set of processes. A workflow process can be defined as a physical
activity or a computational process. Workflow process execution can be
specified in a variety of ways including iterative loops, statements
specifying parallel process execution, and/or conditional branches along
with constructs that specify synchronous or asynchronous interactions.
For a set of process executions to be considered to be a workflow, we
require that the logic describing process execution not be incorporated
into source code of individual processes. Rules engines and workflow are
closely related; we view any system that allows high level specification
of workflow process execution as a rules engine.

[2.3 Knowledge Representation Model]{.underline}

In order for the execution or inference engine described in section 2.1
to reason about incoming data per a set of pre-defined rules, it is
necessary for those rules to be represented in a computationally
tractable format \[3, 4\]. The format for such rules as used by a
specific rules engine implementation can be referred to as the knowledge
representation model. Examples of knowledge representation models
commonly employed in the biomedical and computer science domains include
context-specific Boolean rules such as those found in the Mycin clinical
decision support system \[5, 6\], complex axiomatic statements such as
those employed by the Arden syntax for medical logic modules \[7-9\],
and frames such as those employed in numerous biomedical ontologies and
intelligent agents \[3, 4, 10, 11\]. The process of representing
application-specific rules falls within the broader context of what is
known as knowledge engineering (KE, figure 2).

![](media/image2.jpeg){width="3.436111111111111in"
height="3.4034722222222222in"}

Figure 2: Knowledge engineering (KE) process, consisting of four stages.
The knowledge acquisition stage can be informed by both experts and
existing knowledge collections such as published literature or
databases. The knowledge representation stage generates a knowledge-base
which is later verified/validated, and then used for system
implementation and refinement.

The KE process, as summarized in figure 2, incorporates multiple steps
\[12\]:

1)  Acquisition of knowledge (KA)

2)  Representation of that knowledge (KR) in a computable form

3)  Implementation or refinement of knowledge-based agents or
    applications using the knowledge collection generated in the
    preceding stages

4)  Verification and validation of the output of those knowledge-based
    agents or applications against one or more reference standards.
    These reference standards can include expert performance measures,
    requirements acquired before designing the knowledge-based system,
    or requirements that were realized upon implementation of the
    knowledge-based system. In this context, verification is the process
    of ensuring that the knowledge-based system meets the initial
    requirements of the potential end-user community. In comparison,
    validation is the process of ensuring that the knowledge-based
    system meets the realized requirements of the end-user community
    once a knowledge-based system has been implemented.

When discussing knowledge representation approaches, it is pertinent to
note that two different forms of knowledge representation forms,
declarative and procedural, have gained prevalence. The declarative
knowledge representations contain knowledge about entities, their
relationships and states. Ontologies and UML class diagrams are examples
of declarative approaches. This knowledge is not executable by itself
and depends upon other programs (like reasoners) to derive inferences.
With a declarative knowledge representation, it is possible to reach
conclusions that are quite appropriate even though they were not
conceived of during its creation. This is an emergent benefit of the
network of relationships in such representations.

In contrast, the procedural knowledge representation approaches take the
algorithmic approach. In this form, a representation needs to provide
sufficient information about the states of entities and how to derive
inferences based upon them. In this form, no conclusions other than
those provided by the author are possible. Even though this form of
knowledge requires other tools (e.g., rules engine) to efficiently
execute it, the execution steps that are essential for drawing
inferences are innate to the representation. This is true even if the
syntax of a formalism expresses its axioms in declarative terms.

The initial enthusiasm for expert systems had significantly waned by the
1990s as the realization dawned that, for the expert systems to be
successful beyond narrow areas of concern, they will need to have many
more rules. The portent of burgeoning complexity in dealing with such
gargantuan rulebases significantly discouraged research in the
procedural knowledge representation approach. One of the motivations for
the efforts in declarative approach has been due to this concern. It is
believed that since ontologies are created in the context of wider
domain needs, the assertions made by contributors will be useful for
other users too, consequently ameliorating the need for each developer
to create their own knowledgebase.

This paper focuses on approaches that fall in the procedural knowledge
category. The recommendation section discusses some of these issues
further, specifically in the context of caBIG^tm^.

[2.4 Inference or Execution Engine]{.underline}

The inference or execution engine is the rules engine component that
actually acts upon specific incoming data via the application of rules
embodied in the knowledge-base, in order to generate some type of
output. At the most basic level, the inference or execution engine can
be defined as a software component that takes as its input one or more
elements of data, applies a set of rules to that data, and generates
some form of output \[2\]. For the most part, reports on this type of
rules engine component have described implementations which are specific
to the type of knowledge representation model being employed.

[2.5 Example Applications of Rules Engine Technologies]{.underline}

As has been implied by the preceding definitions and discussion, rules
engine technologies have been demonstrated in numerous biomedical and
computer science domains. Examples of these varied types of applications
include:

1.  Workflow automation for grid services integration \[13\]

2.  Physical and conceptual workflow automation in distributed
    organizations \[14\]

3.  Ontology anchored biological network discovery \[15\]

4.  Critical value alerting in clinical environments \[7, 9\]

5.  Clinical guideline execution and delivery \[16\]

6.  Semi-automated critiquing of clinical trials protocols \[17\].

A common thread throughout all of these example cases is the
externalization of highly dynamic and/or complex business logic from
application-level code, in order to ensure the efficient use and
maintenance of such rules. Such an approach is consistent with
prevailing best practices within contemporary software engineering
\[18\], thus leading to the conclusion that the use of rules engine
technologies in these and many other cases is both warranted and highly
desirable.

# [3. Knowledge Representation ]{.underline}

In the following section, we will introduce a number of models and
formalisms for the representation of rule-based knowledge. These models
will include:

1.  Production rules, with particular emphasis on both computational
    rule representation formalisms and platforms, as well as current
    standards in this domain

2.  Logical or axiomatic rules and platforms, such as those found in
    clinical decision support systems

3.  Hybrid rules and platforms, such as those found in most guideline
    delivery systems.

[3.1 Production Rules]{.underline}

Despite many advances in inferencing technologies and knowledge
representation approaches, the Production Rules, the knowledge that the
Rules Engines execute, remain the most popular. EMYCIN was an expert
system shell that pioneered the approach of separating the logic from
the hard coded parts of the system, giving the flexibility that one now
expects all rules-based systems to provide. Since then, many production
rules systems have developed.

*3.1.1 Rule Representation Formalisms*

The proliferation of rule-based representations and systems over the
last several decades has spawned many different syntaxes for production
rules. However, essentially all rules are composed of two parts. The
first part specifies one or more conditions to be tested and the second
part specifies the action that is performed if the conditions are met. A
rule is executed by the inference engine if the conditions are met by
the current state of the world as available to the system by means of
the facts that are asserted.

In its simplest form, a production rule may be expressed as:

+-----------------------------------------------------------------------+
| > **If**                                                              |
| >                                                                     |
| > **\<condition(s)\>**                                                |
| >                                                                     |
| > **Then**                                                            |
| >                                                                     |
| > **\<action(s)\>**                                                   |
+-----------------------------------------------------------------------+

The condition part of the rule is also commonly referred to as the
premise, antecedent, or Left Hand Side (LHS). The action component of a
rule is also known as the consequent, conclusion or Right Hand Side
(RHS).

In Knowledge Representation terms, rules allow declaratively expressing
first-order logic in an unambiguous human readable form, while retaining
machine interpretability. Thus despite their procedural role in systems,
essentially rules are declarative representations. Since rules are
declarative Knowledge Representation forms, they are not called like
functions in a procedural language. Instead they fire in response to
changes in the facts available to the rules engine. For the same reason,
it may be semantically more appropriate to use "When" in rules syntax
instead of "If", which has a procedural connotation to it.

Although several popular formalisms for rules and corresponding rule
engines are in use, many of them are closed source and commercial. In
the context of caBIG^tm^, we need to identify systems and approaches
that are suitable for wide deployment without conflicting with the
program\'s open source commitment. We discuss some of these in the
following section.

*3.1.1.1 CLIPS*

CLIPS, or C Language Integrated Production System, is commonly
acknowledged to be the most widely used rules based expert system. The
popularity comes from it being available as a free system since the
mid-eighties combined with its speed, performance and easy integration
with software written in C and C++. CLIPS is still being maintained and
has led to many variants and extensions including Jess, described below.
The license under which CLIPS can be used and distributed is very
liberal, compared to even the most liberal of modern open source
licenses.

The syntax of CLIPS was created to resemble the syntax of the existing
Expert Systems in use in at that time and draws heavily upon Common
LISP.

In the following example, the rule "eligible1" can be used to determine
eligibility of a patient for a clinical trial. The eligibility is
asserted to have value "true" if gender, disease, disease status, and
treatment received have values female, carcinoma breast, chronic and
true respectively.

+-----------------------------------------------------------------------+
| (defrule eligible1                                                    |
|                                                                       |
| (eligibility (name gender) (value female))                            |
|                                                                       |
| (eligibility (name disease) (value carcinoma_breast))                 |
|                                                                       |
| (eligibility (name disease_status) (value chronic))                   |
|                                                                       |
| (eligibility (name treatment_received) (value true))                  |
|                                                                       |
| =\>                                                                   |
|                                                                       |
| (assert (eligibility (name eligible) (value true))                    |
|                                                                       |
| )                                                                     |
+-----------------------------------------------------------------------+

The symbol =\> separates the LHS from the RHS of the rule. The above
rule will be *fired* if the following facts are asserted using the CLIPS
syntax:

+-----------------------------------------------------------------------+
| (deffacts trouble_shooting                                            |
|                                                                       |
| (patient_data (name first_name) (value Jane))                         |
|                                                                       |
| (patient_data (name last_name) (value Doe))                           |
|                                                                       |
| (patient_data (name gender) (value female))                           |
|                                                                       |
| (patient_data (name disease) (value carcinoma_breast))                |
|                                                                       |
| (patient_data (name disease_status) (value chronic))                  |
|                                                                       |
| (patient_data (name treatment_received) (value true))                 |
|                                                                       |
| )                                                                     |
+-----------------------------------------------------------------------+

The syntax, though different from more widely prevalent modern
languages, is not difficult to learn. To access CLIPS from an external
software program, the program should be able to construct such rules and
assert facts as strings and pass them to the CLIPS rules engine.

*3.1.1.2 Jess*

Jess is a rules engine designed to integrate well with Java software
applications, and is itself written in Java. Jess was originally created
to be able to work with rule definitions and fact assertions in CLIPS
syntax, but later acquired many other features that are uniquely its
own.

The following example of a Jess rule stores the string "high" in a java
variable diabetes_suspicion, if the data elements called "Polydipsia",
"Polyuria" and "Unexplained Weight Loss" all have values equal to
"true".

+-----------------------------------------------------------------------+
| (data_element (name \"Polydipsia\") (avalue ?PolydipsiaValue))        |
|                                                                       |
| (test(eq ?PolydipsiaValue \"true\"))                                  |
|                                                                       |
| (data_element (name \"Polyuria\") (avalue ?PolyuriaValue))            |
|                                                                       |
| (test(eq ?PolyuriaValue \"true\"))                                    |
|                                                                       |
| (data_element (name \"Unexplained Weight Loss\") (avalue              |
| ?UnexplainedWeightLossValue))                                         |
|                                                                       |
| (test(eq ?UnexplainedWeightLossValue \"true\"))                       |
|                                                                       |
| =\>                                                                   |
|                                                                       |
| (store diabetes_suspicion \"high\")                                   |
+-----------------------------------------------------------------------+

For anyone familiar with the LISP or CLIPS syntax, the Jess rule should
be easy to comprehend. Jess also provides an XML schema definition,
JessML, for its rules. An extension of the popular IDE framework,
Eclipse is available for writing Jess code, which ensures error free
syntax, testing of the rules, and some debugging facilities.

Jess is available as a Java library for developers to integrate into
their own development efforts, allowing such capabilities as directly
interacting with Java objects, creating new ones on the fly, and
allowing access to its internal variables from Java applications. The
rule definitions and assertion of facts have to be done as strings which
are passed to the Jess engine object in a manner similar to accessing a
database engine via JDBC by SQL string commands.

Despite being a Java based system, use of Jess by developers entails
learning of the Jess syntax, which is quite different from Java. This is
compounded by the fact that there are always several different ways in
which a task may be achieved using Jess. However, a minimal set of
consensus constructs may be standardized by the development team in the
early stage of a project, thereby reducing the need to struggle with the
syntax at each subsequent stage.

Although Jess is available free of cost for academic purposes and at a
low cost for commercial use, it is not provided under an open source
license. There are no runtime licensing fees for deployment of Jess.
Jess comes with rich, easy-to-follow documentation. The source code is
provided to the licensing organizations and the support offered by
creators of Jess is considered exemplary.

*3.1.1.3 JBoss Rules (Drools)*

Another production rules system getting significant attention these days
is the open source JBoss Rules, which is the new name for an earlier
open source project called Drools after it was folded into the larger
JBoss open source effort.

JBoss Rules has a syntax that is much easier to understand than
CLIPS/Jess, in particular for those who are familiar with Java syntax.
It follows a syntax similar to the general pattern for rules described
in the introduction of this section. The following graphic displays a
JBoss Rules template for a rule with annotations explaining different
parts.

![](media/image3.wmf){width="3.745833333333333in"
height="2.158333333333333in"}

Below is an example of a JBoss Rules file with a very simple rule, in
which if a patient is found to be of age 50 or more, the
exampleFunction, which is a Java function within the same file, is
called and the patient object is added to a collection called
eligiblePatients. Thus, one can have Java functions within the same file
as JBoss Rules to be invoked by the RHS.

+-----------------------------------------------------------------------+
| package org.coh.ctms.eligibility                                      |
|                                                                       |
| import java.util.List                                                 |
|                                                                       |
| import org.coh.patient                                                |
|                                                                       |
| global List eligiblePatients                                          |
|                                                                       |
| function void exampleFunction(Patient patient) {                      |
|                                                                       |
| System.out.println( patient.getName() + " is eligible" );             |
|                                                                       |
| }                                                                     |
|                                                                       |
| rule "age eligibility"                                                |
|                                                                       |
| when                                                                  |
|                                                                       |
| patient : Patient( age \>= 50 )                                       |
|                                                                       |
| then                                                                  |
|                                                                       |
| exampleFunction( patient );                                           |
|                                                                       |
| eligiblePatients.add( patient );                                      |
|                                                                       |
| end                                                                   |
+-----------------------------------------------------------------------+

This also demonstrates the ease with which JBoss Rules may be used in
Java environments. Like Jess, JBoss Rules also comes with an Eclipse
Workbench to facilitate editing, debugging, testing and optimization of
rules. Like Jess, JBoss Rules also provides an alternative XML approach
for specifying rules.

A significant benefit of JBoss Rules is the **Domain Specific
Languages** facility that the environment provides. This allows mapping
of Rules elements to domain specific constructs, making the writing of
rules for members of that domain even more intuitive.

JBoss Rules is available under Apache Software Foundation's open source
license which has quite liberal terms for use of code provided under it.

*3.1.1.4 Other Rule Expression Languages*

The above descriptions dealt with those rule representation approaches
that are either open source or are available to academic centers without
any costs. In addition, there are several well known systems which are
commercial products and have their own knowledge representations, but
are not be covered in this paper since they are not available under open
source licenses. These include ILOG JRules, Blaze Advisor, Versata,
MQWorkFlow, BizTalk and Savvion.

*3.1.2 Production Rules Standards*

Despite the popularity that the production rules systems enjoy in the
industry and academia, there have been few efforts aiming to achieve
standardization. Even the few initiatives undertaken by different
consortia and community organizations have found little acceptance. This
may change in the near future as vendors and open source groups that
develop rules-based systems have expressed their commitment to adopt the
standards when they mature.

Standardization for the production rules systems can occur in several
ways. The current efforts are however, oriented towards either (a)
standardization of the syntax and format of the rule-based knowledge
representation or (b) standardization of the way other applications
access the production systems. The former would permit authoring of
rules in a common format or provide a mechanism to translate their
native formats into a shareable format. The latter will allow interface
based access (SOA) to production rules systems.

The two standardization efforts described below fall in category (a),
while those that belong to category (b) are covered in a separate
section, "Interface Based Abstract Representations", below.

*3.1.2.1 The Rule Markup Language -- RuleML*

The RuleML site states its mission as, "The goal of the Rule Markup
Initiative is to develop RuleML as the canonical Web language for rules
using XML markup, formal semantics, and efficient implementations.
RuleML covers the entire rule spectrum, from derivation rules to
transformation rules to reaction rules. RuleML can thus specify queries
and inferences in Web ontologies, mappings between Web ontologies, and
dynamic Web behaviors of workflows, services, and agents".

RuleML aims to facilitate rules interoperability amongst all the
prevailing standards like JSR 94, SQL\'99, OCL, BPMI, WSFL, XLang,
XQuery, RQL, OWL, DAML-S, and popular systems including CLIPS, Jess and
several other commercial ones.

In the following example of RuleML syntax, a rule specifies the
conclusion that a person has the "own" relationship with an object, if
the object has a "buy" relationship with the person in association with
a merchant, and person has a "keep" relationship with the object. Please
note that the \<head\> tag is equivalent to the RHS and the \<body\> tag
is equivalent to LHS of the rule.

+-----------------------------------------------------------------------+
| \<Imp\>                                                               |
|                                                                       |
| \<head\>                                                              |
|                                                                       |
| \<Atom\>                                                              |
|                                                                       |
| \<Rel\>own\</Rel\>                                                    |
|                                                                       |
| \<Var\>person\</Var\>                                                 |
|                                                                       |
| \<Var\>object\</Var\>                                                 |
|                                                                       |
| \</Atom\>                                                             |
|                                                                       |
| \</head\>                                                             |
|                                                                       |
| \<body\>                                                              |
|                                                                       |
| \<And\>                                                               |
|                                                                       |
| \<Atom\>                                                              |
|                                                                       |
| \<Rel\>buy\</Rel\>                                                    |
|                                                                       |
| \<Var\>person\</Var\>                                                 |
|                                                                       |
| \<Var\>merchant\</Var\>                                               |
|                                                                       |
| \<Var\>object\</Var\>                                                 |
|                                                                       |
| \</Atom\>                                                             |
|                                                                       |
| \<Atom\>                                                              |
|                                                                       |
| \<Rel\>keep\</Rel\>                                                   |
|                                                                       |
| \<Var\>person\</Var\>                                                 |
|                                                                       |
| \<Var\>object\</Var\>                                                 |
|                                                                       |
| \</Atom\>                                                             |
|                                                                       |
| \</And\>                                                              |
|                                                                       |
| \</body\>                                                             |
|                                                                       |
| \</Imp\>                                                              |
+-----------------------------------------------------------------------+

*3.1.2.2 The Rule Interchange Format -- RIF*

The Rule Interchange Format (RIF) effort is a relatively new initiative
under the aegis of World Wide Web Consortium (W3C). As the name
indicates, the effort is directed towards creating an interchange format
to avoid vendor lock-in and facilitate knowledge sharing rather than
creating a language that the systems will use for their own knowledge
representation, although use of RIF as a native language for future
systems is also a possibility.

Currently, the effort is in the requirements specification stage and has
acquired a rich set of use-cases that the format will be expected to
fulfill. The use cases described include integration and interaction
with other declarative knowledge representation approaches such as OWL
and RDF, and some use cases pertaining clinical decision support.

Though this effort is in its early stages, it can be expected to gain
significant traction due to the W3C affiliation and participation by an
active Semantic Web community.

*3.1.2.3 Semantic Web Rule Language - SWRL*

Semantic Web Rule Language (SWRL) is an interesting approach that
attempts to bridge the divergent worlds of declarative and procedural
knowledge representation forms. In this approach, the syntax of Web
Ontology Language OWL, a formalism of the declarative knowledge
representation kind, has been extended to allow expressing procedural
rules. SWRL is a proposal under consideration by the W3C.

The proposal extends the set of OWL axioms to include Horn-like rules
enabling combining such rules with an OWL knowledge base. An obvious
advantage of such an approach is to be able to combine declarative
knowledge with the procedural knowledge in one resource, using the same
or similar syntax.

However, as we discuss in our recommendation section, formalisms like
OWL and technologies like production rules address different needs and
it may not be judicious to combine the two.

[3.2 Logical/Axiomatic Models]{.underline}

As introduced earlier in the definitions section of this whitepaper, one
of the commonly used knowledge representation (KR) models for rules
engine technologies is that of logical or axiomatic statements. In these
types of KR models, rules are represented as either simple or complex
(e.g., branching or nested) logical statements, using some type of
extensible logical grammar \[19\]. In the following section, we will
provide examples of several such logical or axiomatic KR models, with
specific emphasis on those that have been applied in the biomedical
domain. It is important to note that some of the examples provided in
this section pertain to what are labeled as guideline systems. However,
they have been included in this section rather than the following
section on guideline-oriented KR models,owing to their primary reliance
on logical axioms rather than more holistic process models such as those
found in GLIF, EON, or SAGE.

*3.2.1 Arden Syntax*

Perhaps one of the most commonly cited or described axiomatic models for
representing clinical decision support rules, the Arden syntax was
developed jointly during the early 1990's by the Columbia University
Department of Biomedical Informatics, LDS Hospital in Salt Lake City,
and the Regenstreif Institute \[7, 8\]. Arden syntax was first
registered and administered as a standard representational scheme in
1992 under the auspices of the American Society for Testing and
Materials, and was later adopted by the HL7 standards-setting body in
1998. Arden syntax is used to write what are called Medical Logic
Modules (MLM's), which are intended to be the basis of clinical alerting
systems (e.g., generating an alert for clinicians or other affected
individuals upon receipt of context-specific data elements which meet
one or more criteria designated as a threshold for triggering such an
alert) \[7\]. Primary examples of MLM-based alerting systems include the
CARE decision support system at the Regenstrief Institute, and the
Clinical Event Monitor deployed as part of Columbia Presbyterian
Hospital's electronic medical record system \[8\]. An MLM, written using
the Arden syntax, will include structured statements organized into
slots that describe a maintenance component (e.g., the author and update
history for the MLM in order to ensure that it is up to date), library
component (e.g., the source or source documents supporting the logic
embodied in the MLM), and a knowledge component (e.g., the data or data
elements and values required to trigger execution of the MLM, and a set
of instructions for what alerts or messages to generate should the MLM
be triggered) \[20\] (figure 3, adapted from Dongwen Wang \[21\]).

Figure 3: Example of the Arden syntax.

+-----------------------------------------------------------------------+
| **MLM for sending an alert when order a CT with contrast for patients |
| with renal failure**                                                  |
+-----------------------------------------------------------------------+
| > **maintenance:**                                                    |
| >                                                                     |
| > **title:**                                                          |
| >                                                                     |
| > CT study with contrast in patient with renal failure;;              |
| >                                                                     |
| > **filename:**                                                       |
| >                                                                     |
| > astm_ct_contrast;;                                                  |
| >                                                                     |
| > **version:**                                                        |
| >                                                                     |
| > 1.00;;                                                              |
| >                                                                     |
| > **institution:**                                                    |
| >                                                                     |
| > ASTM E31.15; SMS;;                                                  |
| >                                                                     |
| > **author:**                                                         |
| >                                                                     |
| > Harm Scherpbier, M.D.;;                                             |
| >                                                                     |
| > **specialist:**                                                     |
| >                                                                     |
| > ;;                                                                  |
| >                                                                     |
| > **date:**                                                           |
| >                                                                     |
| > 1995-09-11;;                                                        |
| >                                                                     |
| > **validation:**                                                     |
| >                                                                     |
| > testing;;                                                           |
| >                                                                     |
| > **library:**                                                        |
| >                                                                     |
| > **purpose:**                                                        |
| >                                                                     |
| > Issue alert when physician orders CT study with contrast in patient |
| > with renal failure;;                                                |
| >                                                                     |
| > **explanation:**                                                    |
| >                                                                     |
| > If physician orders CT scan with contrast, this rule retrieves most |
| > recent serum creatinine.  If the value is less than 1 week old, and |
| > more than 1.5, the system issues an alert to the physician to       |
| > consider the possibility that his patient has renal failure, and to |
| > use other contrast dyes.;;                                          |
| >                                                                     |
| > **keywords:**                                                       |
| >                                                                     |
| > ;;                                                                  |
| >                                                                     |
| > **citations:**                                                      |
| >                                                                     |
| > ;;                                                                  |
| >                                                                     |
| > **links:**                                                          |
| >                                                                     |
| > ;;                                                                  |
| >                                                                     |
| > **knowledge:**                                                      |
| >                                                                     |
| > **type:**                                                           |
| >                                                                     |
| > data_driven;;                                                       |
| >                                                                     |
| > **data:**                                                           |
| >                                                                     |
| > last_creat := read last {\"Creatinine level\"};\                    |
| > last_BUN := read last {\"BUN level\"};\                             |
| > ;;                                                                  |
| >                                                                     |
| > **evoke:**                                                          |
| >                                                                     |
| > ct_contrast_order;;                                                 |
| >                                                                     |
| > **logic:**                                                          |
| >                                                                     |
| > if                                                                  |
| >                                                                     |
| > last_creat is null and last_BUN is null                             |
| >                                                                     |
| > then                                                                |
| >                                                                     |
| > alert_text := \"No recent serum creatinine available.  Consider     |
| > patient\'s kidney function before ordering contrast studies.\";\    |
| > conclude true;                                                      |
| >                                                                     |
| > elseif                                                              |
| >                                                                     |
| > last_creat \> 1.5 or last_BUN \> 30                                 |
| >                                                                     |
| > then                                                                |
| >                                                                     |
| > alert_text := \"Consider impaired kidney function when ordering     |
| > contrast studies for this patient.\";\                              |
| > conclude true;                                                      |
| >                                                                     |
| > else                                                                |
| >                                                                     |
| > conclude false;                                                     |
| >                                                                     |
| > endif;\                                                             |
| > ;;                                                                  |
| >                                                                     |
| > **action:**                                                         |
| >                                                                     |
| > write alert_text \|\| \"\\nLast creatinine: \" \|\| last_creat \|\| |
| > \" on: \" \|\| time of last_creat \|\| \"\\nLast BUN: \" \|\|       |
| > last_BUN \|\| \" on: \" \|\| time of last_BUN;\                     |
| > ;;                                                                  |
| >                                                                     |
| > **urgency:**                                                        |
| >                                                                     |
| > 50;;                                                                |
| >                                                                     |
| > **end:**                                                            |
+-----------------------------------------------------------------------+

*3.2.2 PROforma*

The PROforma KR model has been primarily reported upon in the context of
representing executable clinical processes. The PROForma model is
predicated on a logical decomposition of processes into tasks composed
of data items and rules that may be triggered by those data items. The
PROForma model describes four major types of tasks: 1) plans, 2)
decisions, 3) actions, and 4) inquiries \[22, 23\]. Two significant
software platforms have been developed to aid in the representation of
processes using the PROforma KR model: Arezzo (a commercial software
product) and Talis. Examples of clinical decision support systems that
have been developed using PROforma include: 1) CAPSULE -- a tool for
supporting medication selection in general clinical practice, 2) ERA --
a referral management tool of general practioners in the United Kingdom,
3) RAGs -- a cancer genetics risk assessment tools, 4) LISA -- a
clinical trial-specific medication dosage tool, and 5) an ongoing
project sponsored by the British Medical Journal (BMJ) to support
evidence-based practice based upon published literature \[23\]. The
specific KR scheme used by PROForma is a Backus Naur Form logical
grammar \[24\] in which each expression references a one or more classes
of objects referred to as components, where each component has both a
set of descriptive properties and a state variable (e.g., if the
component describes a critical laboratory value, the state variable
would indicate whether that component had been instantiated as part of
the evaluation of the encapsulating logical statement) \[23\].

*3.2.3 PRODIGY*

The PRODIGY KR model is in many ways very similar to PROforma, in that
it has been primarily reported upon in the context of representing
executable clinical processes. The PRODIGY system has been applied to a
number of aspects of chronic disease management, providing for both
guideline delivery and clinical decision support (e.g., critical value
alerting) functionality. Examples of these targeted chronic disease
states include asthma, hypertension, and angina. The PRODIGY KR model
uses a relatively simple logical grammar that describes scenarios (which
are defined by specific combinations of observed data), management
decisions (instructions on how to proceed given an observed scenario),
and action steps (specific activities required to execute a management
decision) \[25, 26\]. In terms of defining scenarios, PRODIGY uses
logical statements that provide for Boolean rule-in or rule-out
decisions. Given the satisfaction of the appropriate rule-in and out
decisions for a scenario, the PRODIGY model then calls for the execution
of one or more management decisions comprised of action steps (which are
equivalent to the "then" clause of a simplified "if-then" logical model)
\[26\]. One interesting extension provided by the PRODIGY KR model is
the inclusion of a "followed-by" relationship, which allows for the
definition of temporal relationships between rule-in or out decisions as
well as management decisions and more atomic action steps \[26\].

*3.2.4 GUIDE*

Guide is an integrated decision support and guideline delivery platform
initially developed in 1992 that uses a component-based architecture. At
the highest level, GUIDE is comprised of a guideline delivery system,
workflow management system, and electronic medical record. The
underlying KR model used by both the guideline delivery system and
workflow management system of GUIDE is based upon the use of Petri nets,
which are a type of formal grammar for defining concurrent and
temporally dependent processes \[27\]. The reason for the use of a Petri
net approach in GUIDE is the common occurrence of parallel or iterative
workflows in the modern healthcare environment \[28\]. In order to
facilitate the use of this powerful, but potentially complex KR model,
the GUIDE architecture includes a knowledge editor that allows domain
experts and/or knowledge engineers to design Petri nets in an intuitive
and visual manner analogous to conventional flow charts. The GUIDE
knowledge editing tool is then able to convert these flow charts into an
internal, computable representation model predicated on the use of
branching or nested logical axioms \[28\]. Functional prototypes of
GUIDE have been demonstrated in the oncology clinical and research
domains \[28\].

[3.3 Hybrid Models]{.underline}

In contrast to the preceding predominantly logical or axiomatic KR
models, there exist a large number of rules engine technologies that
utilize hybrid KR models which incorporate not only logical rules, but
also higher-level workflow or process abstractions. In the following
section, we will provide examples of both general purpose and biomedical
hybrid KR models, per the preceding definition.

*3.3.1 BPEL (Business Process Execution Language)*

BPEL is a non-deterministic, XML-based, executable process modeling
language. The BPEL language is a derivative of two previous
process-oriented modeling languages, WSFL and XLANG, which were
initially developed by IBM and Microsoft respectively. The BPEL KR model
incorporates two levels of modeling \[29\]. The first level is concerned
with the interaction of collective, abstract processes (e.g., states and
transitions of those processes). The second level is concerned with the
atomic components that make up processes such as transactions and
resources. It is important to note that BPEL is an *orchestration*
language, in that it models the interaction of multiple actors,
resources, and processes as opposed to being a *choreography* language
which would focus upon processes from the perspective of a single actor
or resource. At the most basic level, the BPEL KR model allows for the
definition of workflow related rules that incorporate control flow
(parallel, branching, or looping processes), asynchronous interaction,
and nesting of processes \[29\]. ***BPEL is the language used to specify
caBIG workflow.*** Additional examples of areas where BPEL has been
applied include the modeling of interactions between web services and
business processes (e.g., logistics, supply chain management, customer
relationships management) in numerous domains \[13\]. It is widely
acknowledged that BPEL is the accepted best-practice implementation
language for the computational modeling of processes at the
*orchestration* level.

*3.3.2 WS-CDL (Web Service Choreography Description Language)*

WS-CDL is a *choreography* language used to model the observable
interaction of computational services such as web services. WS-CDL is an
example of a number of other *choreography* languages, including 1)
BPML, 2) BPSS, 3) WSFL, and 4) WSCL, and 5) XLANG. The WS-CDL KR model
is XML-based and, as opposed to most *orchestration* languages (e.g.,
BPEL), does not provide for the definition of process-specific control
points or work units (e.g., units of aggregation for closely related
process-specific activities). Examples of the major classes included in
the XML-based WS-CDL KR scheme include a description, token (e.g., the
state of process for the purpose of transaction tracking), and
choreography (e.g., the constraints on the process in terms of the
execution order of other, related processes) for each process being
modeled. An exemplary fragment of WS-CDL code, representing a process by
which a buyer solicits a quote from a seller is provided in figure 4
\[30\].

Figure 4: Example of WS-CDL KR model

+-----------------------------------------------------------------------+
| **Example WS-CDL representation of a process by which a buyer         |
| solicits a quote from a seller**                                      |
+-----------------------------------------------------------------------+
| \<interaction name=\"QuoteElicitation\" operation=\"getQuote\"        |
| channelVariable=\"tns:Buyer2SellerC\"\>                               |
|                                                                       |
| \<description type=\"documentation\"\>                                |
|                                                                       |
| Quote Elicitation                                                     |
|                                                                       |
| \</description\>                                                      |
|                                                                       |
| \<participate relationshipType=\"tns:Buyer2Seller\"                   |
| fromRoleTypeRef=\"tns:BuyerRole\" toRoleTypeRef=\"tns:SellerRole\"/\> |
|                                                                       |
| \<exchange name=\"QuoteRequest\"                                      |
| informationType=\"tns:QuoteRequestType\" action=\"request\"\>         |
|                                                                       |
| \<description type=\"documentation\"\>                                |
|                                                                       |
| Quote Request Message Exchange                                        |
|                                                                       |
| \</description\>                                                      |
|                                                                       |
| \<send variable=\"cdl:getVariable(\'quoteRequest\',\'\',\'\')\"/\>    |
|                                                                       |
| \<receive variable=\"cdl:getVariable(\'quoteRequest\',\'\',\'\')\"/\> |
|                                                                       |
| \</exchange\>                                                         |
|                                                                       |
| \<exchange name=\"QuoteResponse\"                                     |
| informationType=\"tns:QuoteResponseType\" action=\"respond\"\>        |
|                                                                       |
| \<description type=\"documentation\"\>                                |
|                                                                       |
| Quote Response Message Exchange                                       |
|                                                                       |
| \</description\>                                                      |
|                                                                       |
| \<send variable=\"cdl:getVariable(\'quoteResponse\',\'\',\'\')\"/\>   |
|                                                                       |
| \<receive                                                             |
| variable=\"cdl:getVariable(\'quoteResponse\',\'\',\'\')\"/\>          |
|                                                                       |
| \</exchange\>                                                         |
|                                                                       |
| \<exchange name=\"QuoteResponseFault\"                                |
| informationType=\"tns:QuoteResponseFaultType\" action=\"respond\"     |
| faultName=\"InvalidProductFault\"\>                                   |
|                                                                       |
| \<description type=\"documentation\"\>                                |
|                                                                       |
| Quote Response Fault Exchange                                         |
|                                                                       |
| \</description\>                                                      |
|                                                                       |
| \<send variable=\"cdl:getVariable(\'faultResponse\',\'\',\'\')\"/\>   |
|                                                                       |
| \<receive                                                             |
| variable=\"cdl:getVariable(\'faultResponse\',\'\',\'\')\"/\>          |
|                                                                       |
| \</exchange\>                                                         |
|                                                                       |
| \</interaction\>                                                      |
+-----------------------------------------------------------------------+

*3.3.3 GLIF (Guideline Interchange Format)*

The GLIF KR model focuses upon the representation of clinical
guidelines, and has been developed collaboratively by a consortium of
Columbia University, Harvard University, and Stanford University. GLIF
is object-oriented, and uses a frame-based implementation model. Major
object classes included in each GLIF guideline model are summarized in
figure 5 \[21, 31-33\].

Figure 5: Summary of object classes included in the GLIF KR model
(sub-classes indicated in italics)

+---------------------------+------------------------------------------+
| **Object Class**          | **Major Attributes**                     |
+---------------------------+------------------------------------------+
| Guideline                 | Name, Author, Intention, Eligibility     |
|                           | Criteria, Step, First Step, Didactics    |
+---------------------------+------------------------------------------+
| Guideline Step            | Name, Didactics                          |
+---------------------------+------------------------------------------+
| > *Action Step*           | Action, Sub-Guideline, Next Step         |
+---------------------------+------------------------------------------+
| > *Conditional Step*      | Condition, Destination, Otherwise        |
+---------------------------+------------------------------------------+
| > *Branch Step*           | Branch, Selection Method, Order          |
|                           | Constraint                               |
+---------------------------+------------------------------------------+
| > *Synchronization Step*  | Next Step, Continuation                  |
+---------------------------+------------------------------------------+
| Action Specification      | Name, Patient Data                       |
+---------------------------+------------------------------------------+
| Criterion                 | Type, Didactics                          |
+---------------------------+------------------------------------------+
| > *Boolean Criteria*      | Specification                            |
+---------------------------+------------------------------------------+
| > *K of N Criterion*      | Number To Select, Criteria               |
+---------------------------+------------------------------------------+
| Patient Data              | Name, Type, Possible Values, Temporal    |
|                           | Constraint                               |
+---------------------------+------------------------------------------+
| Supplemental Material     | Label, MIME Type                         |
+---------------------------+------------------------------------------+
| > *Local Material*        | Material                                 |
+---------------------------+------------------------------------------+
| > *WWW Material*          | URL                                      |
+---------------------------+------------------------------------------+

The GLIF2 standard, introduced in 1998, includes a facility (provided
via an extension to the Protégé 2000 knowledge editing environment
\[34\]) to enable the visual editing of guidelines represented in GLIF
as flow-charts, indicating the choreography of guideline objects \[31,
32\]. The current version of GLIF is GLIF3, which is a further
refinement of the GLIF2 standard \[33\]. It is important to note in
terms of the computability of GLIF encoded guidelines that a
corresponding object-oriented query and expression language for use in
executing GLIF guidelines is provided via the GELLO language \[16, 21\].

*3.3.4 Asbru*

Absru, introduced in 1998, is another example of a guideline-centric KR
model for the automation of clinical processes. The Asbru KR model
differs from the preceding GLIF model, in that it focuses on the
definition of tasks and their temporal relationships to one another
(rather than modeling guidelines in an object-oriented manner). These
temporal relationships are in turn constrained by specifications known
as "intentions" \[35, 36\]. The Asbru KR model uses a multi-faceted
application specific language named DeGel (Digital Electronic Guideline
Library) which is part of a broader set of web-based tools for the
storage, authoring, query, and execution of computationally encoded
clinical guidelines. The DeGel language is effectively an XML derivative
which uses Asbru specific tags. One of the primary benefits of the use
of DeGel is the comprehensive suite of editing, visualization, and
quality assurance tools provided within the DeGel suite of tools \[37\].
Current research and development focusing upon Asbru has included the
development of NLP tools to convert free-text clinical guidelines into
Asbru-compliant DeGel representation \[36\].

*3.3.5 EON*

The EON clinical guideline representation and execution engine
development project began in 1996 at Stanford University \[38\]. EON
utilizes the Protégé 2000 knowledge editing environment, enhanced using
a project specific extension, to facilitate the design and
representation of clinical guidelines \[39\]. The EON KR model
decomposes guidelines into conceptual entities known as tasks, which can
include goal setting, decision making, and data interpretation. In
addition, the EON KR model defines specific types of relationships that
may exist between guideline tasks in order to represent the overall
guideline algorithm, which may include decision-based branching linkages
(e.g., depending on the degree of satisfaction of a specific set of
criteria, one or more sets of subsequent tasks that are in turn linked
together by a "followed-by" relationship may be selected for execution)
\[38\]. Guideline-specific rules (such as those that would define the
decision at a particular branching linkage) are represented in the EON
KR model as first-order predicate logic axioms, using the Protégé Axiom
Language (PAL) which is a derivative of the Knowledge Interchange Format
(KIF) \[40\] (figure 6, adapted from Tu \[40\]).

Figure 6: Example EON KR model for axiomatic rules.

+-----------------------------------------------------------------------+
| **PAL statement for checking medication interactions**                |
+-----------------------------------------------------------------------+
| (defrange ?current_med :FRAME Medication)                             |
|                                                                       |
| . . .                                                                 |
|                                                                       |
| (exists ?current_med                                                  |
|                                                                       |
| > (exists ?med_class                                                  |
| >                                                                     |
| > (and (subclass-of                                                   |
| >                                                                     |
| > (drug_name ?current_med) ?med_class)                                |
| >                                                                     |
| > (exists ?contraindication                                           |
| >                                                                     |
| > (and (Absolute_Contraindications                                    |
| >                                                                     |
| > ?med_class ?contraindication)                                       |
| >                                                                     |
| > (exists ?problem                                                    |
| >                                                                     |
| > (subclass-of                                                        |
| >                                                                     |
| > (domain_term ?problem)                                              |
| >                                                                     |
| > ?contraindication)))))))                                            |
+-----------------------------------------------------------------------+

Unlike many other guideline-centric KR and execution engine development
projects, the research products of the EON project have been deployed in
a widely used, production-level advisory system for the management of
hypertensive patients in VA hospitals, named ATHENA \[39\]. Also of
note, EON is the predecessor of the current SAGE project, as summarize
in the following section.

*3.3.6 SAGE*

As described above, SAGE is a descendant of the EON project, and its
development and evaluation involves a collaboratory established in 2002
consisting of Stanford University, Intermountain Health Care, Mayo
Clinic, the University of Nebraska, IDX Systems Inc., and Apelon Inc.
The primary differentiation of SAGE from EON is the tighter coupling of
workflow modeling and clinical decision support mechanisms with the
provision of clinical guidelines. SAGE builds upon the initial EON KR
model by augmenting it with three additional components \[41, 42\]:

1.  **Activity graphs** -- which define high level clinical workflows in
    which a guideline is to be deployed or utilized in terms of
    processes and relationships between processes,

2.  **Decision maps** -- which define represent the temporal
    relationships between workflow and guideline specific decision
    making points, and

3.  **Standard terminologies and interface specifications** -- which
    enable the more rapid integration and deployment of SAGE within
    production environments

Again, as was the case with EON, SAGE uses the Protégé 2000 knowledge
editing environment to enable the creation and ongoing management of the
preceding activity graphs and decision maps, as well as the clinical
guidelines \[41, 42\]. This KR model continues to utilize the PAL
representation format for any associated logical axioms.

# [4. Execution Engines ]{.underline}

In this section, we will introduce and described a number of commonly
utilized execution or inference engine platforms for rule-based systems.
Continuing the structure of the preceding section, we will divide our
discussion of these execution engines into three sections, based upon
the type of rule representation format being used, as listed below:

1.  Production rules

2.  Logical or axiomatic rules

3.  Hybrid rules

[4.1 Production Rules]{.underline}

The most important component of a production rules system is the rule
engine. The rules engines interpret the rules in the light of the facts
that are available to them and select which of the rules to fire and in
which order. Thus for each of the rule representation formalisms
described in the previous sections there is a corresponding Rules
Engine.

Rule engines are needed anywhere it is not desirable for the logic to be
hard coded into the application and has to be amenable for modification
and customization for different needs and situations. Rule engines allow
separation of the business logic from the application code and data,
which reduces the software development and maintenance costs.
Frequently, the rules change by the time the software developers
understand the requirements, codify and develop the application. With
the use of rule engines this premature obsolescence may be avoided. The
use of rule engines facilitates declarative programming approach that
allows separation of concerns while making possible a great flexibility
at runtime. The need for keeping the business logic separate from the
more static parts of the applications has already been identified in
many places in the clinical trials and in-vivo imaging domain spaces of
caBIG, which makes production rules systems a candidate for adoption in
caBIG.

The rules engines primarily have two components, Pattern Matching
Algorithm and Agenda. The pattern matcher identifies if the facts match
the patterns of any of the rules' LHS. Depending upon the facts and the
patterns of the rules, several rules may be considered eligible for
execution. These rules are aggregated by the agenda which after applying
the conflict resolution strategy of the rule engine decides which, if
any, of the rules are to be actually executed. The Rete Algorithm or
some variant of it are the most common pattern matching algorithm
commonly used, although other algorithms have also been described.

The execution of rules engines can occur in one of two ways: forward
chaining and backward chaining. In forward chaining, the execution
proceeds with assertion of facts and propagates until the conclusion is
determined. In backward chaining, the conclusion is provided to the
engine which then tries to identify sets of facts that will fulfill the
conclusion. Thus forward chaining is data driven while backward chaining
is goal driven. Most systems have forward chaining capabilities, while
some systems also provide backward chaining, making them Hybrid
Production Rules Systems. Backward chaining is an infrequently required
feature and in implementations it is possible to create backward
chaining kind of functionality even with a purely forward chaining
engine.

Another characteristic of rule engines to consider is whether they
maintain states or not. As designed, Rete is a stateful algorithm. That
is, it can keep accumulating facts, discarding them or modifying them in
response to the changes in the external world, over the life of an
instance. However, for many situations, e.g., in web applications, it
may be desirable to have a stateless rule engine instance where all the
facts required for an execution of the engine are provided to it in one
go.

A robust system that is capable of supporting needs of enterprises and
network of organizations for production rules will also need rules
servers and rules management systems besides rules engines, rule
languages and editing facilities.

Rules engines of both CLIPS and Jess have forward and backward chaining
capabilities, while the JBoss Rules currently only provides forward
chaining and backward chaining is in development. All the described
production rules systems are capable of handling stateless or stateful
sessions. JBoss Rules team is also developing a Rules Management system
and Rules system in keeping with their goal of developing a suite of
tools for the enterprise.

*4.1.1 Interface Based Abstract Representations*

In contrast with the efforts of standardization that aim at creating
standard formats for expressing rules or other inference capable
knowledge representations, some efforts have targeted creating common
access mechanisms for the diverse inferencing systems. A common standard
programmatic interface that allows accessing functionality of different
types of inferencing mechanism is an appealing goal. However, the
efforts in this area are at an early stage.

The interface based access allows swapping of the tools behind the
interfaces without affecting the clients that access them. Thus the
clients and the inferencing systems can simultaneously evolve without
being concerned with the development of the other. It is also possible
to provide tools with different technologies or from different vendors
via the same interface.

*4.1.2 HSSP -- HL7 DSS*

Healthcare Services Specification Project (HSSP) is a collaborative
effort between two standards development organizations, HL7 and OMG. The
project aims at creating plug and play interoperability between
applications and components developed by different vendors on basis of
standardized interfaces. Decision Support Service (DSS) is one of the
several interesting efforts underway in HSSP.

The decision support service is expected to be accessible in form of
knowledge modules; each knowledge module being a unit capable of
utilizing a set of patient data to arrive at a conclusion. The knowledge
modules are associated with metadata which is information about their
input data requirements, traits, semantic 'signifiers' and profiles.
Traits are attributes that deal with the knowledge management logistics
of the knowledge module, e.g., date last modified, steward organization
etc. The semantic signifiers are a reference to a standard information
model or ontology entities that provide meaning and structure to the
data. For instance, a semantic signifier may refer to an attribute in an
HL7 RIM class. The profiles are constraints on the applicability of a
knowledge module.

Since HL7 and OMG, two organizations that have good understanding of
healthcare related issues, MDA and SOA are leading this effort, the DSS
specification reflects good understanding of the requirements, practical
considerations and several previous initiatives of these organizations,
including Health Data Interpretation Facility (HDIF) of OMG. However, it
may have been better if the DSS specification had taken an iterative
approach to development, with testing of each version of the
specification with real world implementations. This way, the complexity
of the specification could have been added in layers, over several
version, based upon experience from the implementations.

The Service Functional Model (SFM) of the HSSP-DSS specifies three
interfaces:

1.  *Metadata discovery Interface:* The metadata interface provides
    access to functions that allow discovering of published knowledge
    modules by their associated information listed above. This is
    somewhat akin to fulfilling the needs of the UDDI facility of Web
    Services.

2.  *Query Interface:* This interface allows investigating the specifics
    of a knowledge module of interest including the data requirement for
    a knowledge module to perform its evaluation. This is somewhat
    similar to the WSDL capabilities of a web service.

3.  *Evaluation Interface:* This interface allows invoking the knowledge
    module and accessing its conclusions.

It is important to note that the DSS does not specify any specific
inferencing technology, just interfaces that allow accessing such
technologies. Thus it should be possible to have diverse kinds of
technologies to be made available using the DSS interfaces.

*4.1.3 JSR-94 -- Java Rules API*

The Java Rules API is an effort to standardize interface based access of
production systems from within Java environments (J2EE and J2SE). This
API has been specified under the Java Specification Request 94 (JSR-94)
of the Java Community Process (JCP). The API, by design, is generic
enough to accommodate most of the popular production rules systems and
is aimed at facilitating runtime interoperability between different
rules engines and does not specify semantics of a rules engine or a rule
execution cycle. In many ways, JSR-94 is to the Rules Engines what JDBC
is to the database management systems.

The operations in the API are based on the assumption that most clients
need to be able to execute a basic multiple-step rule engine cycle that
consists of parsing rules, adding objects to an engine, firing rules,
and getting resultant objects from the engine.

The interfaces and classes in the API are in two packages, javax.rules
and javax.rules.admin. The rules package provides access to runtime
clients and allows accessing and interaction with a rule session. The
admin package allows loading of rule execution sets from resources
specified as URIs, input streams or documents.

Most widely available java based production rule systems, including Jess
and JBoss Rules described above, claim to provide a JSR-94 compliant
API.

[4.2 Logical/Axiomatic Models]{.underline}

Much as was the case when discussing KR models in the preceding section
of this whitepaper, the domain of currently reported execution or
inference engine components employed by rules engine technologies can be
largely divided into sub-domains based upon the type of rule
representation utilized by their associated KR models. In this section,
we will introduce examples of several commercial and
institution-specific execution or inference engines which are
predominantly employed to execute rules represented using a logical or
axiomatic KR model.

*4.2.1 iLOG*

iLog is a commercial rules engine that executes axiomatic rules
represented in a Java-based KR model known as JRules, where rules are
organized into like-groups called policies. The primary application area
targeted by the iLog rules engine is web services orchestration. From a
deployment standpoint, the iLog rules engine can be implemented as an
Enterprise Java Bean (EJB), thus supporting use in distributed,
standards-based computing environment \[43, 44\].

*4.2.2 Cerebra*

Cerebra is a rules engine that is able to reason about the relationships
between two or more data elements based upon axiomatic ontological
specifications described using the Web Ontology Language (OWL). Cerebra
is usually employed in tandem with or to supplement other logical rules
engines, since the use of axioms derived from ontological specifications
may only represent a portion of the overall rule-base required to
automate processes or workflow. An example of the production use of
Cerebra is the mixed-model clinical decision support engine employed by
Partners Healthcare of Boston, Massachusetts, which combines the GLIF-3
guideline KR model with the iLog execution engine, augmented using
Cerebra to allow for the use of ontology anchored knowledge sources
(such as controlled terminologies or semantic networks) \[45, 46\].

*4.2.3 Columbia University Medical Center Clinical Event Monitor /
Vigilens*

The Columbia University Medical Center (CUMC) Clinical Event Monitor
(CEM) is a rules engine facility that is integrated with CUMC's
web-based electronic medical record system, WebCIS. The CEM receives
patient-related data via HL7 transactions, managed by a central
interface engine, and applies axiomatic rules represented in the Arden
syntax. This reasoning process has the ultimate objective of generating
critical value alerts, which are then delivered via multiple mediums,
including wireless messaging and in-line messages displayed within the
WebCIS interface \[47, 48\]. In the last several years, the CEM has been
supplanted by a more modern, modular clinical decision support system
(including a rules engine) named Vigilens. The primary differentiation
of the CEM and Vigilens systems is the logical partitioning of the
underlying knowledge-base into clinically relevant and administrative
rule sets (e.g., notification modality preferences for end-users,
communication mapping, etc.). This was done to support the more rapid
evolution of the later administrative rule sets, thus necessitating a
mechanism for more graceful and efficient evolution of those rules. In
addition, the Vigilens execution engine reasons upon patient data using
a more XML-like KR model for rules in comparison to the Ardent syntax KR
model used previously in the CEM \[49\].

*4.2.4 University of Utah HELP System*

The University of Utah HELP system is a comprehensive healthcare
information system, which includes as a component a rule-based decisions
support system with an associated rules engine. The HELP decision
support system has been used in numerous domains, including chronic
disease management, medication interaction alerts, antibiotic
prescribing support, and critical value alerting. HELP has evolved to
execute numerous rules formats, including both axiomatic rules
represented in Arden syntax and EON/SAGE guidelines \[50-52\].

[4.3 Hybrid Models]{.underline}

In contrast to the preceding execution or inference engine components
which are used to execute logical or axiomatic rule-bases, the following
section will describe three example execution engine environments that
are used to support the delivery of higher-level rules represented using
hybrid KR models, such as those found in clinical guideline systems.

*4.3.1 BPEL Execution Engines*

Numerous execution engines for workflow models represented using the
BPEL KR model have been developed, including: 1) ActiveBPEL, 2) BPEL-PM
(BPEL Processor Manager), 3) BEXEE (BPEL Execution Engine), and 4) PXE
(Process Execution Engine). Some of these engines have been developed in
the commercial sector by entities such as Active Endpoints
([http://www.active-endpoints.com](http://www.active-endpoints.com/))
and Oracle ([http://www.oracle.com](http://www.oracle.com/))
respectively for ActiveBPEL and BPEL-PM. In addition, open-source BPEL
execution engines have been developed, including BEXEE which is provided
by the BEXEE project but is no longer under active development
(<http://bexee.sourceforge.net/>), and PXE which is provided by Intalio
([http://www.intalio.com](http://www.intalio.com/)). Of particular note
in this context, the ActiveBPEL execution engine is a J2EE compliant
software component that can be integrated with a variety of application
server environments including Tomcat, JBoss, WebLogic, and WebSphere.

*4.3.2 GLEE*

GLEE (GLIF3 Guideline Execution Engine) is an execution or inference
engine for clinical guidelines represented using the current version of
the Guideline Interchange Format (GLIF3). The GLEE architecture is
designed to incorporate interfaces with a clinical data repository and
clinical event monitor to allow for a given guideline to be executed,
using the GELLO language specification describer earlier, in the context
of both patient-specific data and patient-specific critical events (such
as critical laboratory values). GLEE then generates alerts or
instruction sets that can be delivered via appropriate messaging
systems, such as decision support systems (figure 7). Of interest, GLEE
includes a task scheduling facility to enable customizable scheduling of
guideline execution (e.g., real-time, batch, etc.) per end-user
preferences \[16, 33\].

![](media/image4.jpeg){width="3.3833333333333333in"
height="3.6645833333333333in"}

Figure 7: Overview of GLEE architecture.

*4.3.3 SAGE*

The SAGE project, as described earlier, has developed a KR model that
incorporates process-oriented guidelines, higher-level workflow
abstractions, and relationships between temporally related tasks or
activities. As part of the SAGE project, a developmental execution
engine is being evaluated which is capable of executing SAGE derived
axioms (represented in PAL) in conjunction with complex temporal
constraints and workflow parameters \[41, 42\]. While this execution
engine has not been reported upon extensively in the published
literature, the component-based approach being used by its developers,
which allows for rules to be specified and executed at multiple levels
of granularity (e.g., workflow, processes, or temporal constraints)
simultaneously, has the potential to address the drawbacks that may
result from more narrowly defined execution engine modalities.

# [5. caBIG™ Case Studies ]{.underline}

The following three case studies, contributed by members of the caBIG
community, describe initial CTMS-related use cases that motivate the
subsequent recommendations presents in section 6:

[5.1 Use Case #1: Laboratory Data Driven Adverse Event (AE)
Reporting]{.underline}

In this case study, we will provide a usage scenario for a rules-engine
drive application capable of automating the detecting and reporting of
AE's. The high degree of variability in reporting of AEs in Phase II
trials has been reported in the literature.(Sharf and Colevas, JCO,
2006) In particular, it has been observed that one of the areas in which
AEs are reported quite inconsistently is hematologic toxicity. For
example, it was found that two randomized trials in the same year
published in the same journal reported that the Grade 3/4 neutropenia of
the doxorubicin-cyclophosphamide regimen was only 6.3% in one study, yet
reported as 88% in the other.(Extermann, JCO, 2007) Most likely this
extreme difference was due to the emphasis that investigators did or did
not place on the collection of nadir CBCs. However such heterogeneity in
data gathering and reporting defeats the goal of standardizing AE
reporting though the National Cancer Institute's Common Terminology
Criteria for Adverse Events (CTCAE). For potential AEs that are
laboratory-based, it is possible to automate and thereby standardize the
assessment of the presence or absence of AEs, by applying the algorithms
for CTCAE grading to an electronic file of data. Our first Use Case for
a recommended caBIG^TM^ rules engine is based on this premise, to
provide four functions: 1) **Assess** laboratory values for the presence
of an AE; 2) **Qualify** certain lab-based AEs that also involve
clinical conditions; 3) **Route** the AEs to the appropriate parties for
review and electronic signature; and 4) **Report** those AEs that are
deemed Serious Adverse Events (SAEs) to the appropriate regulatory
agencies.

A Cancer Center is participating in enrolling patients into the
Radiation Therapy Oncology Group (RTOG) Study 0418: A Phase II Study of
Intensity Modulated Radiation Therapy (IMRT) to the Pelvis +/-
Chemotherapy for Post-Operative Patients with Either Endometrial or
Cervical Carcinoma. The clinical study coordinator registers the patient
onto the protocol via the local CTMS by entering in the medical record
number. Based on this number, other core initial information, such as
name, demographic information, diagnosis, initial set of laboratory
values, and eligibility criteria are transferred from the local
institution\'s electronic medical record into the CTMS.

The chemotherapy portion of the trial involves the administration of
cisplatin. Incidence rates of AEs associated with cisplatin are provided
in the product package insert, and include major nephrotoxicity.
Dose-related and cumulative renal insufficiency is the major
dose-limiting toxicity of cisplatin. Renal toxicity has been noted in
28-36% of patients treated with a single dose of 50 mg/m^2^. Typically
it is first noted in the second week after a dose and is manifested as
elevated BUN, creatinine, and serum uric acid, or as a decrease in
creatinine clearance. Because renal toxicity becomes more prolonged and
severe with repeated courses of cisplatin, renal function must return to
normal before another dose can be given. Severe renal toxicity can be
avoided by induction of diuresis before, during and after treatment.

In addition, hematologic toxicity consisting of myelosuppression occurs
in 25-30% of patients treated with cisplatin. Nadirs in circulating
platelets and leukocytes occur between Days 18 and 23 with most patients
recovering by Day 39. Thrombocytopenia, anemia, neutropenia, and fever
are also possible adverse events. The Clinical Research Associate (CRA)
assigned to the study needs to track the daily laboratory results for
patients on this Phase II trial on a daily basis, and utilize the
descriptive terminology of the CTCAE V3.0 to assess and report a
severity grading scale for each of a possible \~350 AE terms in this
grading scale.

**1) Assess:** Approximately 300 of the AE terms are fully qualitative
in nature, e.g. dry mouth, pain, nausea, infection, etc. Coded baseline
and per visit data typically are not currently available in the Clinical
Information System (CIS) in a coded form to allow immediate automation
of such assessments. However approximately 50 of the AE terms are
quantitative in nature, based on laboratory values and their normal
ranges, which are available in almost any CIS. It is this set of AE
terms to which automated assessment and decision support can be applied
through a rules engine, e.g. through the measurement of BUN, serum uric
acid and creatinine clearance. By importing a file of laboratory data to
a web-based grading service, the algorithms for CTCAE grading may be
applied to these data.

The Cancer Automated Laboratory Adverse Event Grading Service (CALAEGS)
takes as input any structured laboratory file of results and
accompanying normal ranges, with date and time of the drawn sample for
calculated values such as ANC. The rules engine takes these values as
input, and the output is the automatically assessed and graded AE
whenever present, as in the following screen shot:

![](media/image5.wmf){width="6.410416666666666in"
height="4.807638888888889in"}

**2) Qualify:** Certain AEs that are primarily laboratory-based also
involve a clinical judgement prior to being able to make the final
assessment of the specific grade of the AE. As an example related to
this RTOG protocol, based on the uric acid level an AE of hyperuricemia
may be present as a Grade 1 AE if the quantitative value is elevated to
a certain degree and yet no physiologic consequences are present. Yet
the same elevation of uric acid may be deemed hyperuricemia of Grade3 if
there are physiologic consequences present, clearly a subjective
clinical judgement that must be combined with the quantitative uric acid
assessment.

The caBIG^TM^ rules engine would detect that this is a laboratory-based
AE with a qualitative component, and automatically query the CRA to
answer the query regarding presence or absence of physiologic
consequences. As this is likely to require expert medical judgement,
he/she may need to confer with the medical records or directly with the
treating physician before this additional component of the AE assessment
can be answered.

**3) Route:** For such a combined quantitative/qualitative AE
assessment, the rules engine should identify the treating MD through
data imported for the RTOG protocol from the CTMS. Upon detecting the
need to make a clinical judgment that has been entered by the CRA, the
rules engine should route the preliminary assessment to the MD for
review and signoff via electronic signature. For all AE assessments,
even those that are fully quantitative in nature, once the final
assessment is logged into the grading service, the rules engine should
route the full report to the protocol Principal Investigator for review
and electronic signature.

**4) Report:** Once electronic signature by the PI has been obtained,
the rules engine should evaluate the nature of the assessed AEs, and
determine whether a Serious Adverse Event (SAE) has occurred. If an SAE
is detected by the system, the nature of the protocol (treatment,
prevention, etc.), and the governing regulatory groups (CTEP, DCP, etc.)
should be detected by the rules engine. This should trigger the
preparation of an electronic report for all applicable agencies, in the
format and with the content proscribed by each agency.

[5.2 Use Case #2: Clinical Trial Workflow and Data Management
Coordination]{.underline}

In this case study, we will present a modified version of a clinical
trial usage scenario developed by a cross-workspace team led by Ken
Buetow and presented at the caBIG 2007 Annual meeting. This case study
is a useful illustration of the need for close coupling and coordination
between physical processes, database queries or computational tasks and
rule based decision making. The case study is loosely based on a Phase
II efficacy trial of LMB-2 Immunotoxin in chronic lymphocytic leukemia
patients and is presented in Table 1 below. Note that this is only a
sketch presented to raise pertinent points rather than a complete
protocol description, also only the first 16 weeks of this hypothetical
protocol is presented.

Table 1: Phase II efficacy trial of LMB-2 Immunotoxin in chronic
lymphocytic leukemia patients

+-----------------------------------------------------------------------+
| **At Time of Enrollment:** The clinical study coordinator registers   |
| the patient into the protocol. Name demographic information, medical  |
| history number, initial set of laboratory values and clinical         |
| observations (information on which eligibility was determined) are    |
| recorded in the cancer central clinical participant registry (C3PR)   |
|                                                                       |
| The caGrid based system contains a patient study calendar that        |
| manages the ongoing schedule for protocol based tests and treatments. |
| The Patient Study Calendar is initialized using information about     |
| Jane Doe and the LMB protocol. The Patient Study Calendar generates a |
| schedule for Doe. This schedule includes treatment including IV       |
| LMB-2, on days 1, 3, and 5 of an every 4 week schedule, along with    |
| periodic CBC and chemistry panels for toxicity monitoring. The        |
| schedule also includes a pre-treatment repeat bone marrow aspirate    |
| and biopsy during the first week to be used for molecular studies,    |
| and central reviewed Pathology grading along with a 12 week repeat    |
| bone marrow biopsy and followup PET/CT.                               |
+-----------------------------------------------------------------------+
| **Week 1:** Bone marrow biopsy and aspirates are obtained. Quality    |
| control and definitive grading will be carried out by Pathologists    |
| via a grid based central review mechanism. Tissue collection is       |
| carried out as directed by the clinical trial data management system  |
| and study calendar. The tissue collection process involves            |
| coordination between C3PR and the tissue banking software suite. The  |
| process involves generation and use of specimen IDs, barcoded sample  |
| collection vessels and well defined physical storage locations for    |
| tissue. The Pathology lab uses the specimen to produce barcoded       |
| immunostained slides and scans these using a whole slide scanner. The |
| slide images, patient ID and pertinent study information are entered  |
| into the caBIG Pathology Virtual PACS archive.                        |
|                                                                       |
| The study coordinator selects three hematopathologists to review the  |
| Pathology digital images and enters the user IDs of these reviewers   |
| into GridIMAGE. GridIMAGE adds the requested reviews to each          |
| reviewer's worklist. When a reviewer is ready to interpret an image,  |
| he or she runs their GridIMAGE client and is able to browse and       |
| markup the image and choose interpretations from a picklist. Image    |
| interpretation information obtained from each reviewer is stored in a |
| grid accessible markup/annotation database. Once reviewers have       |
| completed their task, the study coordinator is notified. The study    |
| coordinator invokes his or her GridImage client to view each          |
| reviewer's markups and annotations. The study coordinator generates a |
| consensus report from the bone marrow biopsy and aspirate reviews.    |
| ***If the Pathologists have found that the specimen quality is        |
| inadequate, the biopsy is repeated.***                                |
|                                                                       |
| A similar process is used to carry out Radiology central review. The  |
| research coordinator selects three Radiologists and uses Virtual PACS |
| to manage the distributed PET/CT imagery and uses GridIMAGE to        |
| coordinate the review and to collect the results.                     |
|                                                                       |
| ***Final decision on whether to go ahead with the LMB-2 Immunotoxin   |
| regimen is predicated on the results of the Radiologist and           |
| Pathologist review.***                                                |
+-----------------------------------------------------------------------+
| **Week 3: *Ongoing toxicity monitoring tests reveal an adverse event. |
| Each time CBC and chemistry panels are obtained, the information is   |
| sent to a grid based adverse event detection and reporting subsystem. |
| At this time, a dangerous SGOT level is flagged and adverse event     |
| reports are generated. Since this adverse event requires that the     |
| treatment be delayed, until the SGOT is less than or equal to grade   |
| 1.0., we can notify the study calendar that there may be a schedule   |
| change for this patient related to an adverse event. ***              |
+-----------------------------------------------------------------------+
| **Week 5:** Based on the imagery, we've decided to conduct molecular  |
| analysis of the tissue sample. Aliquot are taken from the patient's   |
| tissue and sent to several laboratories for molecular profiling.      |
| caTISSUE is used to track the aliquot as it travels from the          |
| pathology lab to the laboratories where molecular analysis will be    |
| carried out. Gene expression profiling, proteomic analysis and LOH    |
| analyses are carried out by the respective laboratires \-- the data   |
| collected is then loaded onto data repositories such as caARRAY. Grid |
| based Bioinformatics tools (caTRIP, caIntegrator, caBIO, GenePattern) |
| are later used to carry out analyses.                                 |
+-----------------------------------------------------------------------+
| **Week 16:** Followup PET/CT images and bone marrow biopsy are        |
| obtained according to the study calendar. Pathology image review is   |
| carried out as in Week 1. Radiology studies include an evaluation of  |
| change occurring between Week 1 and Week 12. This change detection is |
| carried out by manual comparison of Week 1 and Week 12 PET/CT images  |
| and by invoking an automated change detection algorithm. GridIMAGE is |
| used to coordinate review as well as to send images to a grid based   |
| change detection algorithm. GridPACS is used (as before) to manage    |
| imagery. ***The results of the Pathology review, results from the     |
| human and algorithmic PET/CT change detection evaluation, adverse     |
| event history are used to decide whether to carry out two additional  |
| rounds of LMB-2 Immunotoxin treatment.***                             |
+-----------------------------------------------------------------------+

In this protocol description, we follow patient Jane Doe. Assume that
the patient is eligible for this protocol (which we will call the LMB
Protocol), and has been appropriately consented. A bone marrow biospsy
and aspirate has been collected and interpreted by a Pathologist and
PET/CT images have been obtained to assess lymph node status. In the
interests of space, this usage scenario will be presented in an informal
manner. In Table 1, we present snapshots that take place 1) at
enrollment, 2) during the first week, 3) at weeks 3, 5 and 16 of the
protocol.

The patient study calendar is used to provide a coarse grained plan that
specifies a temporal sequence of clinical study tasks to be carried out.
The items in bold italics are some of the examples of scenarios where
rules engines could play a useful role. Rules engine coordination
includes specifying what to do if problems arise. For instance, if
central reviewer Pathologists judge bone marrow specimens to be of
inadequate quality, a repeat biopsy will need to be obtained (Week 1).
Decision whether to initiate treatment (Week 1) and decision on whether
to extend treatment (Week 16) can also be supported by a Rules Engine.
The interplay between human tasks and data query and management
permeates the entire scenario. The Week 16 scenario depicts the
interplay between computational tasks and protocol activities. In this
week, human Radiologists, Pathologists and image analysis algorithms
analyze image data. The results of these analyses are used in the
decision making process involved in evaluating whether the patient
should be given additional rounds of treatment. As in use case #1, (week
3) rules engine based coordination can play a key role in coordinating
tests used to screen for adverse events and in determining how adverse
events need to be handled (e.g. delaying treatment and generation of
report forms).

[5.3 Use Case #3: Radiation Treatment Planning]{.underline}

Medical accelerator manufacturers have employed advanced computer
technology to produce treatment planning/delivery systems that use
computer-controlled multileaf collimators (MLC) to precisely shape
incident radiation beams to deliver the desired dose prescription. This
mode of therapy is referred to as Intensity Modulated Radiation Therapy
(IMRT), and is capable of generating extremely conformal dose
distributions including concave isodose volumes that provide conformal
target volume coverage and avoidance of specific sensitive normal
structures. Image-guided radiation therapy (IGRT) extends IMRT to make
use of improved tumor and normal organ definition made possible through
the use of anatomical and functional imaging. The ATC cooperative group
now requires the use of volumetric imaging studies to characterize
volume of known tumor (GTV), suspected microscopic spread (CTV) and
marginal volumes needed to account for variations in setup and patient
motion. The testbed Special Interest Group in the in vivo imaging
workspace is recommending the development of data management
infrastructure and remote review tools to 1) support efficient and
effective review of IMRT and IGRT studies, 2) to permit experts to carry
out assessments of ongoing treatment processes and 3) to provide tools
that support IGRT protocols that involve algorithmic criteria to specify
how changes in conformal dose distributions should be driven by ongoing
assessments of treatment response, as assessed by anatomic and
functional imaging.

Computable clinical guidelines and rules languages can be used in
protocols to specify relationships between conformal dose distributions
and results of imaging studies. Rules can specify required radiation
dose in known tumor volumes, in areas of suspected microscopic spread
and can also be used to specify what tolerances need to be made for
patient motion. Rules can also be used to specify maximum radiation
doses that can be applied to non target structures. The rules can be
formulated to critique conformal dose distributions generated by
radiation treatment planners or can be formulated in ways that assist in
the generation of radiation treatment plans. Finally rules regarding
recommended conformal dose distributions during the course of treatment
can incorporate changes in GTV and CTV over time along with observed
radiation toxicity effects.

**6. Recommendations for a caBIG Rules Engine System**

[6.1 Overview]{.underline}

The need for business rules functionality within caBIG is ubiquitous, as
had been demonstrated in the preceding use cases. However, each need
comes with a different set of concerns and priorities. In such a
setting, a universally useful solution will have to be described in
fairly fundamental terms.

Any solution recommended for caBIG should effectively leverage the
existing caBIG knowledge based infrastructure that is expressed in terms
of CDEs, UML models, Interfaces and immutable concepts. In particular,
the recommendation has to consider caDSR's utility and how to maximally
exploit it. Fortunately, caDSR lies at the intersection of information
models, applications and ontologies. The use of caDSR-derived,
ontology-anchored knowledge structures (e.g., the NCI Thesaurus) when
designing caBIG applications provides a means for semantic
interoperability between such an application and others within the
caGRID framework, as well as a mechanism for graceful evolution to, or
adoption of, other alternative knowledge bases.

We also need to consider how declarative knowledge resources (e.g.,
ontologies like NCIt) can be exploited to allow deriving inferences.
Some ontologies are a rich source of knowledge but their content is, in
general, implementation independent, and for domain wide application.
Using such a resource one may be able to infer, for example, that
"diabetes mellitus has sequelae diabetic retinopathy" but it may not be
possible to infer higher order relationships between concepts such as:
"if a study participant develops diarrhea grade 3 or higher, start IV 5%
dextrose drip and inform gastroenterologist". Furthermore, given the
still emergent nature of many biomedical knowledge collections (e.g.,
ontologies, taxonomies, or their equivalents), no single collection can
be expected to have sufficient information to deal with all the values
of the attributes of the entities involved. Thus it can be concluded
that while declarative knowledge collections can be of value for drawing
lower-order inferences concerning relationships between concepts, they
are not necessarily of utility in inferring higher order relationships,
such as those associated with protocol derived linkages between
conceptual entities (e.g., procedural knowledge), such as was provided
in the preceding example. We believe that both approaches, specifically
the use of a declarative and procedural knowledge collections to define
rule bases, are complimentary, and therefore there is need to pursue the
use of both within caBIG applications and infrastructure, such as the
rule engine platform being described in this particular instance.

***The following recommendations are for a caBIG Rules system or
platform that will consist of several components, of which Rules Engine
is only one***. The recommendations are based around what we perceive as
a need for a common syntax and a structure for rules which utilize caDSR
CDEs as their facts and conclusions. Besides a rule expression language
the recommendations include adopting common interfaces for rules engines
and a rules repository. Finally, we recommend development of a
user-friendly rule editing environment, which will encourage quick
adoption of the proposed rules system by the domain experts. It is
important to note in the context of these recommendation that also have
determined that the current BPEL orchestration language used by many
caBIG application, while appropriate for such process orchestration,
cannot serve all of the roles or provide the functionality required of a
true rules engine facility or system.

## 

## [6.2 Common Syntax & Structure]{.underline}

Adoption of a shared syntax and structure by all members of the caBIG
community will facilitate exchange of executable knowledge and diminish
the need for extensive or resource intensive learning efforts on the
part of adopters of such a system.

The rule expression language adopted by caBIG should allow representing
the conditions in the LHS as a tree as depicted in the following
graphic. In the rule, each node of a LHS or RHS (light green) is an
operator. The dark brown leaves are CDEs and the light brown leaves are
their corresponding values, associated with them via an operator node.
The nodes could also be more complex functions in the case of conditions
in the LHS. This structure allows nesting of conditions/criteria
modularly to provide extensibility and make them available for reuse
within other rules. Furthermore, each node and reference to its contents
can be stored in a database as a record. The structure also permits use
of caDSR CDEs and permissible values as essential part of the conditions
and conclusions for the rules.

![](media/image6.wmf){width="5.997222222222222in"
height="2.7354166666666666in"}

In a programming language the same rule can be expressed as:

> If
>
> (Age \>= 45) AND ((Polydipsia = true) OR (FBS \> 120) OR (Race =
> Indian))
>
> Then
>
> Diabetes Suspicion = true
>
> Endif

The proposed structure can be used to represent rules from existing
sources, e.g. CTCAE 3.0. For example, CTCAE 3.0 states that an adverse
event is determined to be Diarrhea Grade 2 based on the following
criteria :

-   Increase of 4 - 6 stools per day over baseline

-   IV fluids indicated \<24hrs

-   moderate increase in ostomy output compared to baseline

-   not interfering with ADL

The structure for rules described above can be used to express this
rule, shown below in a table, along with some of the CDEs from caDSR
that may be reused in the LHS of the rule. Please note the rule has been
modified to ensure completeness.

![](media/image7.wmf){width="4.876388888888889in"
height="4.549305555555556in"}

Besides allowing use of CDEs, a rule definition language that allows
accessing instances of classes and their attributes will be more useful
for developers. Thus Java objects expressed as Beans could be made
available to rule engines, which could then access the beans' attributes
exposed as properties.

It is important that the adopted rule expression syntax/schema allows
for the translation or extension of rules into higher-level logical,
workflow oriented, or hybrid rule representation and execution mediums
such as those associated with previously introduced Arden Syntax, BPEL,
and GLIF/GELLO models. In addition, it will also be necessary for rules
in the recommended syntax/schema to be translatable to
production-oriented models such as Jess and JBoss Rules. However, unlike
other components of our recommendations, the ability to perform such
translation is still an area of active and open research -- we will
introduce a potential mechanism to allow for the adoption of such
translation and alternative knowledge representation schemas in our
later recommendations concerning a ***Rule Editing and Management
Environment***.

We recommend exploring if a common syntax can be based upon RuleML, as
it is designed to facilitate interoperability between several popular
production rule languages and for working with semantic web ontology
languages. Furthermore, RuleML is easy to learn. Some extensions in the
language will have to be considered to allow the syntax of the language
to work natively with caDSR CDEs and Java Beans. Below is an example of
how modified RuleML may allow use of CDEs as facts within its conditions
and inferences:

+-----------------------------------------------------------------------+
| \<if\>                                                                |
|                                                                       |
| > \<atom\>                                                            |
| >                                                                     |
| > \<objectClass\> eligibility \</objectClass \>                       |
| >                                                                     |
| > \<property\> status \</property\>                                   |
| >                                                                     |
| > \<value\> true \</value\>                                           |
| >                                                                     |
| > \</atom\>                                                           |
| >                                                                     |
| > \<and\>                                                             |
| >                                                                     |
| > \<atom\>                                                            |
| >                                                                     |
| > \<objectClass\> person \</objectClass \>                            |
| >                                                                     |
| > \<property\> race \</property\>                                     |
| >                                                                     |
| > \<value\> African \</value\>                                        |
| >                                                                     |
| > \</atom\>                                                           |
| >                                                                     |
| > \<atom\>                                                            |
| >                                                                     |
| > \<objectClass\> person \</objectClass \>                            |
| >                                                                     |
| > \<property\> gender \</property\>                                   |
| >                                                                     |
| > \<value\> female \</value\>                                         |
| >                                                                     |
| > \</atom\>                                                           |
| >                                                                     |
| > \</and\>                                                            |
|                                                                       |
| \</if\>                                                               |
+-----------------------------------------------------------------------+

Another variant schema could be provided to access properties of a Java
Beans by accessor methods and store inferences by calling mutator
methods.

In brief, we propose adopting a syntax and structure for rules
expression language for caBIG that is

-   Based on RuleML or translatable into RuleML

-   Allows using caDSR CDEs + Permissible value(s) as conditions

-   Allows using sets of caDSR CDEs + Value as outcomes

-   Allows use of instances of objects as conditions and conclusions

-   Hierarchical, allowing nested conditions

-   Translatable into

    -   Arden Syntax

    -   GELLO

    -   Jess

    -   JBoss Rules

-   Storable in database

Use of caDSR CDEs in rules, in the proposed approach, allows
interoperability at the knowledge representation level. In the case of
CDEs derived from UML models in the caBIG environments, the rules
represented in this manner allow linking the dynamic part of declarative
knowledge with the static part as represented in UML class diagrams.

Despite our recommendation for RuleML, if it proves too difficult to
accommodate the requirements as stated above, a new language should be
considered which should then be translatable into RuleML too.

### 

### [6.3 Common Model for Rule Structure]{.underline}

The proposed structure for rules can additionally be represented as a
UML model which will allow the rules to be treated as objects. This has
significance in caBIG as it will allow the rules to be accessed via an
interface and this will also allow the different components of rules to
be treated as CDEs.

## 

## [6.4 Common Interface]{.underline}

Like a common syntax and structure for rules permits interoperability at
knowledge representation level, common interfaces can facilitate
interoperability between different types of rule engines and client
systems that will have different uses for such systems.

Interface-based access to a rule system will increase flexibility and
reduce costs of development and maintenance of applications as it will
encourage 'externalizing' business logic instead of hard coding it into
the systems.

At least two interfaces will be needed to be exposed, one for accessing
and managing the entire rulebase for an organization, and another for
interacting with the rule engine. If the rules are based upon caDSR
CDEs, the rule engines and rule repository will need to access the
caDSR. If a rule editing environment (like IDE) is developed it can also
be made to access the rule repository and engine via the interfaces.

![](media/image8.png){width="6.0in" height="4.5in"}

### *6.4.1 Extension of JSR-94*

Since JSR-94 was designed to allow interoperability between different
kinds of rule systems it is a very generic API. It should be possible
extend the API to meet caBIG specific requirements. With extensions, it
should allow interacting with the caDSR. In future, the interfaces may
be extended to provide ability to interact with the GME facility of
caGRID so that the semantics of UML models can be accessed directly.

A future consideration for the common interface for rules engine should
be the HSSP-DSS specified interface model once it has evolved to a
sufficient level of maturity.

## 6.4.2 Rules Engine Interface

The Rules Engine Interface should be capable of supporting the
capabilities that most leading commercial and open source rules engines
provide. The functionalities available should include capability of
acquiring sessions (stateless or stateful), loading of rules,
interacting with sessions, access to runtime and other metadata of
sessions and engines etc. Interaction with sessions will allow client
systems to provide facts and retrieve conclusions both as CDEs with
values.

### 

### *6.4.3 Translator as Middleware*

Another component that will be closely associated with the Rules Engine,
though not a part of it will be the Translator. This component will
allow translating the common universal format into formats that actual
rules engines can use. This could be a facility that has the capability
of translating the caBIG rules format to any desired format once a
mapping/translation specification for that format has been produced.
This capability will also allow this facility to be used as a mechanism
to translate between different rules format if they are compatible with
the caBIG format.

## 

## [6.5 Rules Repository Interface]{.underline}

In contrast to the requirements that a Rules Engine Interface can
fulfill, there are fewer descriptions of common requirements for Rules
Repositories. However, in the context of caBIG, it is possible to
conceive several features that a Rules Repository should be able to
provide. Some of these are listed here.

### *6.5.1 Unique Identifiers and Versioning*

The repository system will ensure that the rules are unique and assign
them unique IDs. The system will also allow maintaining versions of the
rules as they evolve.

### 

### *6.5.2 Concept/CDE based search for rules*

Since the rules are based upon CDEs which are linked with concepts in
EVS vocabularies/ontologies it should be possible to search for rules
using different concept or CDE based criteria. Examples of such a search
for rules are, "all rules that determine patient eligibility = true",
"all rules that utilize 'disease = papillary serous adenocarcinoma of
ovary' and 'duration of disease' as facts"

### 

### *6.5.3 Organization based on CDEs/concepts.*

It should also be possible to provide pre-created indices that organize
the rules based on certain semantic categories. For example rules may be
organized according to disciplines like oncology, endocrinology and
gynecology. In another example, the rules may be organized by
institutions that create them. The rules may even be organized based on
semantic similarity between them.

### *6.5.4 Rule Components*

The repository should not just allow accessing rules but also rule parts
as components to be used in other rules if required. This will be
facilitated by the rule syntax proposed above.

### 

### *6.5.5 Batch Operations*

The repository should allow accessing rules as a group to allow
simultaneous operations upon them including batch runtime access,
download, and modification

## 

## [6.6 Rule Editing and Management Environment]{.underline}

We propose a two-tiered approach to rule editing and management,
consisting of knowledge management and rules management components, as
described below.

*6.6.1 Knowledge Management*

In order to model rules for a caBIG rules engine system, it will first
be necessary to adopt a common tool for editing and managing the
underlying knowledge structures used in the definition of rules, which
is easily accessible and usable by domain experts. As described earlier,
the use of an ontology-anchored approach to the definition of rules
provides for maximal extensibility to and the graceful evolution of the
proposed systems. Such extensibility and evolution is critical, given
the earlier survey of available rules engine platforms, technologies,
and representation schemes provided in this whitepaper, which indicates
that there are numerous evolving models that may be of utility to the
caBIG community in the future, but which might not be explicitly
included in the current recommendations. Therefore, we recommend that
the preceding rules editing and management facility utilize as its basis
an ontology anchored knowledge editing tool for the purpose of defining
the key conceptual knowledge entities used in any such rules.
Specifically, we recommend the use of the broadly applied Protégé
([http://www.protege.com](http://www.protege.com/)) knowledge editing
environment. Initially, per our preceding recommendation, Protégé would
be used to model CDE's used when defining rules, and then subsequently
provide RuleML generation functionality via currently available plug-ins
(<http://www.ruleml.org/txruleml/protege/index.html>). A generic example
of this type of plug-in, allowing for an interface between a conceptual
knowledge collection modeled in Protégé and correlating rules
represented using the RuleML editing/markup environment is provided
below.

![](media/image9.jpeg){width="5.123611111111111in"
height="4.038194444444445in"}

Example of linkage between conceptual knowledge structures modeled in
Protege and the RuleML representation format, using current plug-in
technologies.

The rules resulting from this modeling process would then be aggregated
and managed using more advance rule editing facilities such as that
described in the following section. We believe that given the
wide-spread use of and familiarity with Protégé within the Biomedical
Informatics community and the availability of a plug-in architecture
that extends Protégé to incorporate evolving knowledge representation
and inferencing schemas, this tool is ideal in terms of supporting a
caBIG rules engine system. More specifically, should it be necessary for
a caBIG rules engine system to incorporate alternate rule representation
formats (e.g., using OWL, SWRL, etc.) or underlying knowledge structures
(e.g., ontological or taxonomic constructs other than those in the
caDSR), such evolution should be made possible through the use of
appropriate plug-ins and mappings between knowledge structures, executed
within the Protégé environment.

*6.6.2 Rules Management*

To make the rules system useful to the domain experts, it should be
possible for them understand, author modify, test and deploy the rules
themselves. An application that provides an environment that enables
direct interaction by the users with the rules system will greatly
facilitate its use.

Although it is not possible to recommend a tool as a standard or for
mandatory usage, we believe that development of a user-friendly tool
within caBIG will significantly enhance the likelihood of success of use
of rules system by the community.

Ideally, such a tool should have graphical user interface and a
graphical notation system that makes it intuitive to understand rules
and interact with them.

An example of such an environment is the Greed (**Gr**aphical **R**ule
**E**lements **Ed**itor), a tool in development at City of Hope, shown
in the figures below.

  -----------------------------------------------------------------------
  ![](media/image10.png){width="5.997916666666667in"
  height="5.071527777777778in"}

  The figure shows Greed running; its main panel shows a rule displayed
  in the Greed graphical notation. The rule displayed is to determine,
  based on the CDEs and their possible/permissible values (on the left
  side of the panel), which of the grades (displayed on the right side of
  the panel) a diarrhea adverse event is. The large beige triangle in the
  center represents an AND, and the light green square elements represent
  mathematical or boolean operators. The displayed rule can then be read
  as, if the difference between values of 'Stool Number, current' and
  'Stool Number, baseline' is more than 7, and 'Life threatening
  consequences?' is true, then the value of 'CTCAE 3.0 Diarrhea Grade' is
  'grade 4'. The bottom right panel displays the same rule in Java format
  or in pseudocode that users can comprehend. Extensions allow
  translations into other formats (e.g.,Arden Syntax, RuleML etc.)
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  ![](media/image11.wmf){width="5.999305555555556in"
  height="3.651388888888889in"}

  This rule says if 'Symptomatic?' is true or 'Intervention indicated?'
  is true, the AE is grade 2. This rule is for CTCAE 3.0 Adrenal
  Insufficiency Grade determination.
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  ![](media/image12.wmf){width="5.997916666666667in"
  height="2.4555555555555557in"}

  This rule for CTCAE 3.0 Creatinine AE says that if 'Creatinine' is more
  than 1.5 times 'Creatinine ULN' and 'Creatinine' is less than or equal
  to 6 times 'Creatinine ULN', the AE is Grade 3.
  -----------------------------------------------------------------------

All editing in Greed occurs by dragging and dropping, and the rules
created can be displayed in several different formats simultaneously,
including as a tree or in a user readable pseudocode format. The
different rule elements are reusable and can be used in other rules.
More operators and functions (shown on the toolbar at top) can be added
easily.

## [6.7 Production Rule System Clients]{.underline}

The clients that require business rules functionality should be
accessing the rules engine and repository via their respective
interfaces.

Examples of tools or their components that would require such
functionality are:

-   Workflow and Guidelines based systems

-   Data validation for CRFs

-   AE grade determination

-   Eligibility determination for clinical studies

-   Drug response determination

# [7. Conclusions ]{.underline}

There exist compelling use cases within the caBIG community that could
greatly benefit from support by Rules Engine technology, as described in
Section 5. The existence of multiple, and often overlapping rules engine
platforms and technologies necessitates the selection of a sufficiently
extensible and evolvable rules engine system (consisting of a knowledge
representation scheme, execution engine, and supporting
standards/components) that is both able to meet currently perceived
need, and that will also be able to adapt to future need and
technologies. The recommendations provided in section 6, which include
the adoption of well validated, open-source production rule components
in conjunction with an ontology-anchored approach to the definition and
representation of rules for use in such a system should provide such
benefits to the caBIG community.

# [8. References ]{.underline}

# [9. Additional Useful References and Resources]{.underline}

+--------------------+-------------------------------------------------+
| **Relevant         | **Reference or Resource**                       |
| Standard or        |                                                 |
| Technology**       |                                                 |
+--------------------+-------------------------------------------------+
| Definitions of     | <http://ai.eecs.umich                           |
| Knowledge Types    | .edu/cogarch2/prop/declarative-procedural.html> |
|                    |                                                 |
|                    | <http://dx.doi.org/10.1016/j.jbi.2007.03.005>   |
+--------------------+-------------------------------------------------+
| HSSP- HL7 DSS      | <http://hssp-dss.wikispaces.com/                |
|                    | space/showimage/DSS+OMG+RFP%2C+v2007-02-20.doc> |
+--------------------+-------------------------------------------------+
| HSSP-DSS SFM       | [http://hssp-dss.wikispa                        |
| (Service           | ces.com/space/showimage/HL7+Decision+Support+Se |
| Functional Model)  | rvice+%28DSS%29+Service+Functional+Model+%28SFM |
|                    | %29%2C+v1.0+%28final+DSTU+version%29.doc](http: |
|                    | //hssp-dss.wikispaces.com/space/showimage/HL7+D |
|                    | ecision+Support+Service+(DSS)+Service+Functiona |
|                    | l+Model+(SFM)%2C+v1.0+(final+DSTU+version).doc) |
+--------------------+-------------------------------------------------+
| JSR 94 Java Rule   | <http://jcp                                     |
| Engine API         | .org/aboutJava/communityprocess/review/jsr094/> |
+--------------------+-------------------------------------------------+
| JBoss Rules        | <http://labs.jboss.com/portal/jbossrules>       |
|                    |                                                 |
|                    | <                                               |
|                    | http://labs.jboss.com/file-access/default/membe |
|                    | rs/jbossrules/freezone/docs/3.0/html/ch06.html> |
+--------------------+-------------------------------------------------+
| Jess               | <http://www.javawo                              |
|                    | rld.com/javaworld/jw-11-2006/jw-1107-brms.html> |
+--------------------+-------------------------------------------------+
| RuleML             | <http://www.ruleml.org/>                        |
+--------------------+-------------------------------------------------+
| SWRL               | <http://www.w3.org/Submission/SWRL/>            |
+--------------------+-------------------------------------------------+
| Protégé            | <http://protege.stanford.edu/>                  |
+--------------------+-------------------------------------------------+