Intelligent Business Process Management through Business ...

flameluxuriantΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 10 μήνες)

303 εμφανίσεις








Design and Implementation of a Business Process Rules Engine


b
y


Wayne Huang and Edward A. Stohr


Stevens Institute of Technology

New

Jersey



January, 2007





Working Paper


Center for Technology Management Research

Howe School of Technology Man
agement

Stevens Institute of Technology

Design and Implementation of a Business Process Rules Engine


Abstract

A business process rules engine (BPRE) enables an organization to increase its agility
and speed to adapt to business process changes.
The major
contribution of this research is the
design, implementation, and evaluation of a novel BPRE that overcomes many of the
implementation, validation, and maintenance problems associated with large monolithic rule
repositories. The design adopts a database app
roach that provides

users with both process
-
oriented and policy
-
oriented views of the rule repository for ease of understanding and
maintenance.
Also presented in this paper is an innovative and efficient database rule matching
algorithm

that provides an a
lternative to the popular Rete algorithm
.

Objective evaluation of this
algorithm by stress testing shows that the BPRE can handle the required production volume in a
real world environment. The design discussed in this paper has been successfully implement
ed in
a large financial services organization. A second research contribution is an evaluation of the
BPRE artifact through user surveys that help uncover the business values and the issues relating
to user acceptance of a business process rules engine.


Introduction

Today’s dynamic business environment presents many new business process
management challenges. First, companies must create new products and services at
unprecedented speed. This is exacerbated by the tendency of clients demanding customized
product and service features. For example, the subject company in this research has more than
10% of its clients requiring specialized service workflows. Second, government regulations such
as ERISA, HIPAA, and
Sarbanes
-
Oxley
are forcing companies to take
a more proactive
approach in handling compliance issues. For the insurance industry in the United States, an
additional challenge is that insurance laws are regulated at the state level. The 50 different sets of
insurance laws increase the complexity of in
surance products and the associated business
processes.

Given these complexities, the number of business rules in a typical information
system can range from several hundreds to several thousands and the number of computer and
process controls for reasons
of data quality control, compliance, and internal audit can similarly
reach into the thousands. Facing t
he complexity of business processes and rules, managers find it
difficult to understand the underlying logic of their business. They are not able to ana
lyze and
make appropriate decisions in a timely fashion when process issues arise. This situation is
worsened by personnel turnover; experience from the subject company shows it takes 4 to 6
months to train a new claim processor to be proficient in process
ing life claims.

As shown in Exhibit 1, the subject company’s life insurance claim processing involves
more than 5,000 rules including over 700 data edit rules, 1,000 special client claim handling
rules, and more than 2,000 state regulatory rules. These r
ules exist in the front
-
end applications
(e.g., in Visual Basic code), in the backend processes (e.g., in database triggers, stored
procedures, Unix scripts), in many decision tables, and in user maintained spreadsheets. Business
administrators have no eas
y means to add or change business rules without going through a
lengthy system change management life cycle in which analysts write a specification; developers
change the code; analysts conduct quality assurance testing; users conduct acceptance testing;
a
nd system administrators promote code from the testing environment to the production
environment. In some cases, the regression testing that is required to make sure other existing
functions still work takes more time than the code change. As a result, sys
tem maintenance

consumes enormous amounts of IT time and companies find it difficult to respond to
environmental changes. To cope with the ever
-
increasing demands on its business and the
constraints of its existing information system, our subject company s
uccessfully implemented a
Business Process Rules Engine (BPRE) in its life insurance claim processing system.


Exhibit 1: Life Insurance Claim Processing Rules



90 plus product types and their associated product rules



700 plus data edit rules



70 plus claim
pending rules



200 plus type of correspondence letters



250 plus claim processing and payment approval authority rules



70 plus claim quality review sampling rules



1,000 plus special client claim handling rules



2,000 plus federal/state regulatory rules



850 pl
us accounting rules



600 plus published claim processing guidelines in Lotus Notes database


This research follows the design science research approach, which involves analyzing
“the use and performance of designed artifacts to understand, explain, and, ve
ry frequently,
improve on the behavioral aspects of Information Systems”
[1]
. The three phases in a design
science research project are:

artifact design, construction, and evaluation. Our approach to the
design
and construction of the BPRE artifact includes defining the
business process rules engine
construct
,

designing a BPRE architecture
model
, proposing a rule matching algorithm
method
,
and implementing the BPRE
instantiation
.

A business requirements survey wa
s conducted in the
design phase to determine existing claim system problems and provide guidelines for the BPRE
system. The construction phase was observed by one of the authors, who was actively involved
as the leader of the BPRE project. The evaluation o
f the BPRE system included stress testing of
the prototype and observation of its implementation in a real
-
world environment. Objective
performance was assessed by measuring efficiency improvements resulting from implementation
of the new system. Subjectiv
e analyses of user acceptance and satisfaction were conducted
through the use of pre
-

and post
-
implementation user surveys that were also administered to both
experimental and control groups.

The remainder of the paper is organized according to the major
phases in design science
research as listed above.


Business Process Rule Engine Construct

Corporations utilize a business process management system (BPMS) to “support the
execution of business process through the automated coordination of activities and
resources
according to the formally defined model of the business process”
[2]
. Where a large number of
business process controls are required to satisfy the needs for mass workflow customization,
regulatory compliance, and interna
l controls, there is a desperate need for a business process
rules engine capability to assist decision automation and process execution. This is especially
true for production workflow management systems that support insurance claim processing
where the b
usiness domain’s task complexity is high and task structure is complicated
[3]
. A
BPRE enhances the ability of a workflow application to transform existing business processes
from human
-
intensive operation to s
ystem
-
oriented operation with increased efficiency and

accuracy. Business rules are a major knowledge asset. Systematic management of business rules
enables a company to retain and deploy knowledge effectively.

To guide the design of the BPRE, a business

requirements survey was sent out to
functional managers to elicit business and system issues related to business rules management in
the company. Analysis of the survey results and additional discussion with current users
generated the following BPRE proj
ect objectives: increase claim manager productivity by
providing relevant and accurate claim processing rules on line; enhance data and business rule
quality to increase client satisfaction and ensure regulatory compliance; increase the visibility of
the r
ules that are relevant to functional managers; and increase the speed of system logic change
by providing a rule authoring facility.

To achieve these objectives, a database approach was adopted. With the rules stored in a
database, business managers can a
dd and test a new business rule directly in the testing
environment using the available rules authoring facility, then implement the new rule in
production immediately. New rules can be added without changing and recompiling the
application code. Furthermo
re, the ability of the database to easily provide different “views” of
the data for different users and to facilitate flexible querying of existing rules promotes
understandability and transparency. Other advantages of the database approach are the ability

to
use a well
-
established programming and runtime environment, built
-
in security access control,
and the database audit function. The database approach is well suited for distributed applications
that are the mainstream in today’s corporate IT environment
.

The major disadvantage of the database approach to rule management is that it may be
slow because it requires disk access rather than in
-
memory processing. For this reason, a
specialized
rule processing

algorithm was developed in the design phase of the
project as
explained below. Because a database is designed to safeguard the accuracy and integrity of data
rather than rules, another disadvantage is that the database management system has to be
augmented to ensure rule accuracy and quality. It was theref
ore decided to implement a rule
authoring workflow management system with special rule maintenance, approval, and version
control capabilities.


Buy versus Build Decision

The company decided to build the BPRE in
-
house for both technical and policy reasons.


The technical choices included relying on the rule management facilities of a commercial
Business Process Management Systems (
BPMS), purchasing and integrating a commercial rule
engine into the existing claim workflow, or relying on a decision table app
roach to rule handling.
A study of available
commercial BPMS showed that few provide a comprehensive business rule
management function, instead, many of them rely on an independent business rules management
system (BRMS)
[4]
. A

typical investment in a commercial
BRMS
such as ILOG JRules and Fair
Isaac Blaze Advisor can range from $150,000 for a m
id
-
size project to $500,000 for a large
project plus the typical 15% to 20% annual maintenance fee
[4]
1
. The rule authoring facilities
provided by the examined commercial BRMS were found to be too complicated for regular
business administrators. Nor did they provide the flexibility features inherent in a database
approach as defined above. Anothe
r drawback is that the commercial BRMS rely on workflow
applications to invoke business rules and execute actions, which need to be hard
-
coded in the
workflow application, thus reducing the agility of system change. Many commercial vendors



1

While open source rule engines are available, they mandate that adopting companies make their code available to
the public, which is not desirable for a major company.


also recommend a

separate BRMS server that creates an additional application tier and could
have an measurable impact on the workflow application
[5]
. Finally, existing commercial rule
engines must be implemented o
n a J2EE or .Net platform, which makes it difficult to integrate
the rule engine with existing client/server applications. Although decision table design is a
simple and widely used approach to remove business logic from code
[6, 7]
, it has limitations in
rule maintenance and in rule matching efficiency when there are too many decision tables and a
large number of rules.

From a policy point of view, management favors an incremental approach to improving
existing application capabil
ity. Over the past ten years, millions of dollars have been spent to
migrate its claim processing workflow applications from a mainframe platform to client/server
and Web
-
based platform. In addition, the company did not want to be locked into a single vend
or
solution and lose the flexibility to customize the rules engine features. Finally, the company has
analysts who are familiar with the business processes and rules, a system architect who
understands the existing applications and rules engine technology,

and experienced system
developers. After thorough consideration of these factors, the subject company embarked on the
BPRE project.


Business Process Rules

The GUIDE Business Rules Project
[8]
, created by an industry consortium, defines a
business rule as
“a statement that defines or constrains some aspect of the business.” According
to
[8]
, business rules fall into three categories
: structural assertion, action assertion, and
derivation. “Structural assertion is
a defined conce
pt or a statement of a fact that expresses some
aspect of the structure of an enterprise.
Action assertion is
a statement of a constraint or
condition that limits or controls the actions of the enterprise.
Derivation is
a statement of
knowledge that is der
ived from other knowledge in the business.” Other classification of
business rules include
Ross
[9]
, von Halle
[10]
, and Wilson
[11]
. As discussed in
[11]

inferencing by forward chaining can be achieved in a database environment by writing
intermediate states to the database as shown below. This is the te
chnique adopted in the BPRE
design.


Inference Rule Representation

Database Rule Representation

Rule 1:

IF the nominated driver age is less than
25; THEN he or she is a young driver

Rule 1:

IF the nominated driver age is less than
25; THEN mark the drive
r’s age category in
瑨攠灯汩ty=a猠s=y潵og⁤物癥爠楮⁴桥⁤=瑡ta獥
=
Rule 2:

IF the nominated driver is a young
driver; THEN add 10% to the premium

Rule 2:

IF the driver’s age category is young
摲楶d爻⁔r䕎=a摤‱〥⁴漠瑨攠灲e浩畭⁴漠瑨o猠
灯汩cy
=

In a claim p
rocessing workflow environment, structure
assertion

and derivation are
usually defined in a policy administration application that stores these rules and shapes high
-
level business process model design, while action assertion provides day
-
to
-
day workflow
p
rocess controls that tend to change more frequently. It is more effective to store rules in a
database for ease of maintenance
[12]
.


An informal description of the rule syntax employed by the BPRE is given bel
ow:




ON EVENT

On
-
line Event (e.g., mouse click on a OK button on the payment screen)

[OR Timed Event (e.g., 5:00 AM, (every) Monday; or 2:00 AM, 1
st

date of month)]

[OR Process Event (e.g., process #15 payment process, sub
-
process #1 pre
-
payment)]

IF C
ONDITION

<Data Element/Variable/UDF > (
=, <, <=, >, >=, <>) <Constraint Value>

where, UDF is “user
-
defined function.” (e.g., resident state = “NY”)

[AND
<Data Element/Variable/UDF> (
In, Not In) <List of Constraints>]

(e.g., claim type IN (“Death”, “Accide
ntal Death”, “Dismemberment”))

[AND
<Data Element/Variable/UDF > (
Between) <two Constraints>]



(e.g., age BETWEEN (55, 65))

[AND
<Data Element/Variable> (
=, <, <=, >, >=, <>)
<Data Element/Variable >]

(e.g., claim payment amount > policy maximum a
mount)



[AND
<Old Data Element Value> (
=, <, <=, >, >=, <>) <Constraint Value>]


(e.g. old claim status =
“Pending “)

[AND
<New Data Element Value> (
=, <, <=, >, >=, <>) <Constraint Value>]

(e.g. new claim status =
“Approved “)

[AND
<Data Element
/Variable/UDF > (EXIST, NOT EXIST)]

(e.g., death certificate (record) NOT EXIST)

THEN ACTION


Action 1 (e.g., Update case status)

[AND
action 2 (e.g., Reassign a case)]

[AND
action 3 (e.g., Send an email)…]


The Business Process Rules Engine Design

In a c
laim process workflow, the status of a claim can transit from initial claim form received, to
claim pending with incomplete data, claim pending with complete data, claim approved without
payment, claim approved with payment but under quality review, and th
en finally to claim
payment issued status. Each status transition requires business processes that follow complex
sets of business rules.


Figure 1: Business Process Rules Engine Architecture


A BRMS consists of a
r
ule authoring facili
ty, a rule repository, and a rule engine.
Figure
1 represents the BPRE architecture implemented within the claim processing workflow

application. The BPRE uses the Event
-
Condition
-
Action (ECA) rule framework
[13]
, stores
busin
ess process rules in a database, and can trigger actions in response to events. The event
monitoring and action execution are controlled in the workflow application. The BPRE provides
the application program interfaces (API), a rule repository, a metadata
map, and a process log to
enable the workflow application to perform selective actions based on the rule match results.


Recognized Event Types

There are three types of BPRE event: on
-
line event, timed event, and process event.
On
-
line events

are used in r
ules with actions that provide immediate user feedback or execute a
database action. Each on
-
line event is distinguished by a set of clearly defined application,
screen, and screen object trigger point. For an on
-
line event, the event monitoring mechanism
resides at certain user interaction points in the on
-
line workflow application where the process
control is needed, e.g., at the OK button on a Payment screen. A call to the rule engine API is
added to major event checkpoints within the workflow applicatio
n to invoke the rule matching
(RM) API. When a claim is in Edit mode and certain user interactions occur, e.g., a mouse click
on the OK button, the RM API first identifies the rule subset that belongs to the event checkpoint
in the rule repository. Then th
e RM API algorithm identifies the rules that match the case data
within the rule subset. The action composition (AC) API creates an individual action request or a
list of action requests that need to be completed based on the matched rule set and sends the

list
to the workflow application. The workflow application executes these actions for the target
workflow participants, e.g., updating data in a table or prompting a warning message to the
workflow application user.

Timed events and process events, typica
lly placed in the backend processes, are used in
rules with actions that do not need the application user’s immediate attention, e.g., sending a
claim received notification email to an external client or create a report for next day’s use.
Timed
events

hav
e three parameters: time of the day, day of the week, and date of the month. A
scheduled job is designed to look up rules at a predetermined time interval, e.g., every ten
minutes. The AC API sends the action requests to the workflow application for execut
ion. A
process event

is similar to a time event. The difference is that a process event is associated with a
particular business process step. For example, a rule with a condition that excludes claims with
pending payments under quality review from check i
ssuance can be placed at the beginning of
the pre
-
payment process step that is within the payment batch process. The parameters used in a
process event are: application name, process ID, and sub
-
process ID. In selected workflow batch
processes, event check
points were added for processes to look up rules that belong to these
process events.


Rule Authoring Facility

Figure 2 shows
the rule authoring facility

with an example of the
DEFRA rule. DEFRA
stands for Deficit Reduction Act of 1984. Certain group lif
e insurance contracts issued by the
subject company are affected by DEFRA. In order to properly allocate life insurance benefit
payments for tax reporting purposes, it is extremely important that claims are paid on the correct
benefit plan. The rule is: if

a claim’s combined claim amount is over $50,000 where the insured
was born before 1/1/29 and retired after 1/1/84, it is DEFRA restricted.
The first $50,000 should
be paid under the Non
-
DEFRA
benefit plan
, and the remaining benefit should be paid under th
e
DEFRA
benefit plan
. In this case, the rule type is statutory. The rule will impact the claim
manager role and the compliance role. The rule will be launched when a claim manager clicks on

the Exit Claim button on the Claim application. The action type is

Warning and the rule creator
has entered a warning message. In the condition section, the first condition record indicates that
the rule only applies to claims whose claim amount is greater than $50,000. The second and third
conditions indicate that the r
ule only applies to claims where the decedent’s date of birth is prior
to 1/1/1929 and the decedent’s last date of active service is after 1/1/1984. The Warning message
will be prompted only when all three conditions are met for a particular claim.


Figure 2: BPRE Rule Authoring Facility


The Rules Authoring screen provides users a means to enter business process rules that consist of
events, actions, and conditions following the event
-
condition
-
action framework that is commonly
used in d
atabase rule
-
based systems
[13, 14]
. The first option on the screen is to
select the rule
type of the rule. The second option is to select the workflow roles impacted by the rule. Then the
user can enter the rule description. The rule status effective dates means the rule can only be
applied within the range of these two dates.
A rule with an open effective end date means the
rule will not expire. When the rule is first created, it is in draft status. Subsequently, it can be
changed to approved or invalid status. The system automatically records the user name and date
-
time of any

rule status changes. In the event section, users can pick either the on
-
line or the
backend option. If the on
-
line option is picked, the user can select the application, the screen, and
the button on the screen, which will tell the application to launch t
he rule when the button is
clicked. If the backend option is selected, the user can select the scheduled time, day, and date
when the rule will be launched. The process event is only available to systems developers who
will specify the application name, pr
ocess, and sub
-
process. In the action options, the user can
pick one or more actions. On each action selection, the rule creator will see an action template
with data fields. Some data fields can be entered with a message that combines standard text and
da
ta element contents that workflow users or action recipients will see. For example, for an email
action, the rule creator needs to enter the recipients’ email addresses, standard subject line, and
main message of the email. The main message can incorporate

a standard message with available
case data elements, e.g., name, case number. In the condition options, users can pick data
elements from a drop down list with more than 50 data elements. Then they can pick the

comparative operator appropriate for that d
ata element, and specify a constraint value or another
data element depending on the need to complete a condition record. The steps can be repeated to
create the next condition record until all the conditions are included.

This design responds to the desi
gn requirement to

provide controlled access for users to
view, create, update, approve, and invalidate rules. The security control design allows only
authorized personnel to create, update, and approve rules. The authority of rule creation and
approval is
segregated to add a control that prevents a single person from being able to
implement a rule in a mission critical application without proper checks and balances. All other
users have permission only to view rules. A rule can be modified only when it is i
n the draft
mode. Once approved, no update is allowed. To change an approved rule, the existing rule must
be terminated with an effective end date and a new rule needs to be created with an effective start
date that does not overlap with the effective end
date in the previous rule. The other option is that
the user can change the status of the original approved rule to invalid status and create a new
replacement rule. This design preserves the rule change and rule processing audit trail.



Figure 3 BPRE Opened Action Items


Figure 3 shows action reminders that came from the action component of the matched
rules that are applicable to a particular claim. Every time a rule is matched, it is recorded in the
BPRE process log as an open item. S
ome BPRE rules are created to remind claim processors of
workflow exceptions such as those in Figure 3. Other BPRE rules are created to capture
workflow deviations. For example, a rule states that every pending claim should have a pending
reason, if not, a

warning message should be fired before exiting the claim. If a pending claim
happened to have no pending reason assigned, thus meeting the exception condition, a record
with opened status would be added to the BPRE process log. After the claim processor h
as fixed
the deviation, e.g., by adding a pending reason, the rule would no longer apply. The previous
created process log record will be closed and will not appear on the Claim Advisor screen. All
system processed actions such as data update and email del
ivery are logged and automatically
closed for audit trail purposes. They do not appear on this screen, but the actions are recorded
and viewable in another table such as the claim event log or correspondence log.




User Views and Search

Figure 4 shows th
e rule search screen where rule administrator or users can find any
existing rules in the rule repository by various rule attributes such as rule type, role type,
effective date, rule creator, rule approver, event type, action type, condition element, and
global
text search. By selecting the desired rule, the user can see the detailed content of the rule as in
Figure 2.


Figure 4: BPRE Rules Search Facility



Figure 5: BPRE Rule Repository ER Diagram


Design of the Rule

Database

To achieve scalability, transparency, ease of maintenance, and quick business rule change
we store the rules in database tables.
As illustrated in Figure 5, t
he rule repository stores the
complete definition of the business rules, which includes
rule structure with ECA components,
rule types, workflow roles that own the rule, rule status, and rule effective date.

The repository
contains four basic tables: a rule main table (RMain) that stores description of rules, a rule event
table (REvent), a ru
le condition table (RCondition), and a rule action table (RAction). Three
other tables are needed for reference purpose: a rule type table (RType), a role type table
(RRole), and a metadata table (RMetaData) that
maps data element business names to their d
ata

source
. Finally, the rule process log table (RLog) stores the rule execution history for audit and
performance evaluation purposes.


BPRE Rule Matching Algorithm

To address the concern of rules processing speed and efficiency, we implemented a new
alg
orithm that is different to the Rete
[15]

algorithm commonly used in popular commercial rule
engines such as Fair Isaac Blaze Advisor and ILOG JRules. T
here are two types of
rule engine
:
database/transactional based rule engines and inferencing based rule engines.
Rete is a forwar
d
-
chaining inference rule matching algorithm; our BPRE uses a constraint
-
based rule matching
algorithm
without using the database trigger facility that brings limitations in implementation
[16]
. The BP
RE has limited inference capabilities via forward chaining.

Assume that an event, E, occurs that is associated with specific case data. The objective is
to discover all the rules that apply to the case


the applicable rules will depend on the attribute
va
lues stored in the case record. The BPRE algorithm consists of a four
-
step process. Suppose
the rule repository has N rules RR = {Rule 1
, ...,
Rule N}. Assume only i of the rules {Rule 1
, ...,
Rule i} in RR
belong to
event E; these constitute the rule subs
et RS.


Step 1:




Store the rule IDs {1, …, i} of the rule subset RS in memory A.



Obtain all the unique data elements in RS and store the data values corresponding
to these data elements {v1, …, vj} from the case record in memory B.



Store the
condition list

(unique data element, operator, and rule ID
combinations
in RS
)
{C
11
, …, C
1k
, …, C
m1
, …, C
mk
}
RS in memory C. Here,

m represents the
number of unique data element
-
operator combinations and k indexes the rule(s)
associated with each particular data element
-
operator combination. The condition
list is sorted in descending order of the occurrence frequency of the data element
-
operator combination.


Step 2:

Start with the first data element
-
operator combination, C
1,

in memory C. Query
the rule set RS to obtai
n the list of
unmatched rules

where the rule event equals
event E, and the data element
-
operator combination exists, and the data element
value in memory B does not match the condition constraint value.



Step 3:

Remove the unmatched rule IDs from memory

A



Step 4:

Remove [
C
11
, …, C
1k
] and any other items that belong to unmatched rules in
memory C


Repeat Step 2 thru Step 4 until all items in condition list memory C are removed. The
items left in memory A are the IDs of matched rules.
We use Figure 6

to illustrate how the
BPRE algorithm works with an example.





Figure 6: Algorithm Example


Step 1:



Store
the IDs of the rules in subset RS in memory A = {1,2,3,4,i} by querying the
REvent Table (Figure 5) where the event equals even
t E.



Obtain the unique data elements in RS (Age, Status, State, Amount), find the
corresponding case data values {60, Pending, NY, $40,000}, and store them in
memory B. This is accomplished by querying the unique data elements in the
RCondition table (Figu
re 5) where the rules belong to event E and then getting
their data values from the case that is being worked on at that instance.



Compile unique data element, operator, and rule ID combinations and store them
in condition list memory C. See Figure 6 fo
r the list. The list is sorted by the data
element and operator occurrence frequency from the highest (C1: Status,=) to the
lowest (C6: Age,<). This is done by querying the unique combinations in the
RCondition table where the rules belong to event E, an
d sorting the results by the
counts of combination occurrence.

Step 2:



Start with the first item in the condition list C1 (Status,=) and get the case data
value of Status from memory B; this is “Pending”. Run a query against the rule
set RS; and the “St
atus” data element and the “=” operator exist; and the
“Pending” value does not match (equal) the condition constraint value. The
unmatched rules are R3 and R4.

Step 3:



Remove rule IDs 3 and 4 from memory A.

Step 4:



Remove all C1 items (C11 to C14) and any

other condition list items that belong
to Rule 3 and Rule 4, i.e. C23 and C51, in memory C.


Then we move on to C2 and repeat Step 2 through Step 4. It takes only 4 iterations to
match all conditions in rule subset RS because C23, C51, C32, and C61 are re
moved by the
respective C1, C2, and C4 Step 4 processes. The final matched rule set contains Rule 1 only.

Several factors contribute to the efficiency of the BPRE data model and algorithm. First,
because the event component is integrated as an independent
rule element, the design effectively
reduces the number of rules that need to be matched at a given process point and time. For

example, in a rule repository with 5,000 rules, maybe only 250 of the rules are associated with
the payment activity. During pay
ment processing, when the event is triggered, the rule matching
(RM) API can focus on only 250 rules instead of all 5,000 rules.

Second, we approach the rule matching process by focusing on the limited number of
data elements in the rule subset. The rule

repository data model design makes the data element
matching approach possible. Through the algorithm example above, we show that the RM API
can easily identify the matched rules through matching the case data element value against the
condition constrain
ts in the RCondition table. Using the previous example, suppose there are 50
data elements in the 5,000 rules and that only 30 data elements are in the 250 payment
processing rules. It is more efficient to run 30 or fewer simple queries against the 250 rul
e
condition records than to run 250 individual rule queries against the case record in the database
to get the matching rules. Building 250 dynamic individual queries also presents a major
challenge considering the complexity of the entity relation design
in a database application.

Third, we increase the matching process efficiency by considering the rule condition
occurrence statistics. The order of selection of each element
-
operator combination in each
matching cycle is based on its occurrence frequency

in the subset of rules to be matched. The
data element
-
operator combination with the highest occurrence is picked first; the one with the
lowest occurrence is picked last. Because we delete from the condition list not only the used data
element combinatio
n records, but also the unused combination records that belong to unmatched
rules, we can effectively reduce the number of data element matching cycles needed. This is
particularly effective in a rule repository that has similar rule conditions or reused r
ule conditions
among rules.

The same algorithm is used for backend events. First, a lookup job finds a subset of rules
that match the particular timed event, the RM API then unions all the case data records that
match the composite conditions in the rule

subset. Finally, the above algorithm is applied
successively to each resulting case record.

This algorithm can be easily programmed into a stored procedure in a database. See
[12]

for a complete listing of the

required SQL code. The algorithm can also be programmed as a
component in a client/server application, e.g., a class or a dynamic link library (DLL), or as a
web service using .Net or Java.


Objective Evaluation: BPRE Rule Engine Stress Testing Results

W
e stress tested the BPRE algorithm using a prototype program that included four tasks
in the rule engine process: make database connection, query the case data, find matching rules,
and log the matching results. We designed the stress test to show the perf
ormance of the rules
engine by increasing the number of rules in both single user and five concurrent user scenarios.
The performance was measured by the average database server connection time and average
query execution time for the latter three tasks. T
he test rule base was constructed by the system
architect. About 50 unique data elements were included in the rule conditions. We started the test
at 250 rules, then increased the number of rules to 500, 1,000, 2,000, 3,000, 4,000, and 5,000.
Before each t
est, we deleted records in the process log to eliminate the impact of possible longer
record insertion time due to the process log table having more records. Each test was conducted
for 5 to 6 minutes. The test environment consisted of a Sun V890 Solaris 9

Unix server, a Sybase
ASE 15.0 database server with production quality data, and the Mercury Load Runner testing
tool.

Table 1 shows the average database server connection time and the average query

execution time in seconds of the BPRE prototype progr
am when we increased the number of
rules from 250 to 5,000 under the single user and five concurrent user scenarios. The results
show that the average database server connection time is insignificant for both the single user
and five concurrent user scenar
ios. For the average query execution time (includes query the
case data, find matching rules, and log the matching results) the results indicate that the
execution time increased by only 52.8% under the single user and 66.9% under the five
concurrent user

scenarios while the number of rules increased 200 times.


Table 1: BPRE Rule Engine Average Response Time


Number of Rules

250

500

1,000

2,000

3,000

4,000

5,000

Single User

Server Connection Time

0.14

0.18

0.13

0.14

0.12

0.15

0.13


Query Execution Tim
e

3.41

3.29

3.27

3.53

3.99

4.56

5.21

Five Concurrent

Server Connection Time

0.38

0.47

0.29

0.31

0.33

0.38

0.25

Users

Query Execution Time

7.32

7.22

7.40

8.12

10.01

9.98

11.78


The results in Table 1 indicate that the BPRE is feasible in a production en
vironment.
Our observation from the existing 200
-
user claim application production environment is that
most of the time, there are fewer than three users sending queries to the database server at the
same time. We tested the five concurrent user scenario j
ust to obtain the rules engine
performance data in an extreme, but rare, situation. The test performance of the BPRE, 5.21
seconds response time under one user and 5,000 rules, is quite acceptable in a real
-
world
application.

Independent evidence of the
acceptability of the performance of the BPRE has
subsequently been obtained through observation in the initial production environment with 250
rules; the production response time has been found to be less than two seconds.


Quantitative Benefits

In a six
-
month period, 268 rules that include special client claim handling rules and
regulatory rules have been created by business users and 33,472 unique claims requiring that at
least one of the new rules be fired were recorded in the BPRE process log. Each ru
le created and
processed in the BPRE reflects savings from claim processing expense and process rule
publishing and communication expense. The empirical data collected from the requirement
survey showed that claim processors spent at least 10 minutes per c
laim to investigate special
claim processing rules and that the average time it takes to publish a new rule was approximately
two days. Based on a hypothetic claim processor annual salary of $50,000, the total savings from
reduced claim processing time and

reduced time to publish and communicate rules is about
$272,000 in the six months since the BPE was implemented.

Additional quantifiable benefits could be found in the following areas once we collect
enough empirical data over a longer period of time.



Sa
ving in system development and testing time for enhancements that can be avoided
by adding new rules to the BPRE



Saving from new claim processor special claim handling rule training time that
averages two weeks after most of the rules are captured in BPRE



Reduced numbers of claim rework identified by the Quality Review Team and the
Financial Control Team



Reduced client complaints related to claim processing




Reduced cycle time in new business rule creation, communication, and enforcement



Reduction in lines

of code needed to implement a new business functionality


Subjective Evaluation: Pre
-

and Post
-
Implementation User Surveys

Based on the results of the prior requirements survey, the relevant business rules
literature, and our own judgment, the efficacy of

the rule engine implementation was measured
by testing the following seven hypotheses. After the implementation of the BPRE, application
users will perceive:

H1: The usefulness of the application to be higher.

H2: The ease
-
of
-
use of the application to b
e higher.

H3: Rule maintenance to be easier.

H4: The business rules to be more transparent.

H5: The data quality of their work to be higher.

H6: Workforce flexibility to be higher.

and

H7: Overall satisfaction with the application rule handling capab
ilities will be higher


In these hypotheses, we employed six constructs: usefulness, ease
-
of
-
use, rule
maintainability, rule transparency, data quality, and workforce flexibility. The related research
domains reviewed include the technology acceptance mode
l
[17
-
19]
, u
ser information
satisfaction
[20
-
22]
, software quality
[23
-
25]
, business rules (engine) design
[5, 9, 10, 26]
, data
quality
[27]
, and BPMS or BRMS evaluation articles
[4, 28, 29]
.



Under the
usefulness

construct, we examine items such as the
relevancy

and
consistency

of the
rules, the
speed

of the BPRE, and workflow task
productivity

improvement.



In the
ease
-
of
-
use

construct, we focus on variables such as whether the application is
easy
to

learn
; whether users can leverage
existing

(application)
knowledge

to use the BPRE;
w
hether the presented business rules are

easy to understand
.



In the
rule maintainability

construct, we measure how
easy

and how
quick

the business
rules can be created; we also look at how
flexible

the rules components can be selected.



In the
rule tran
sparency

construct, we look at whether the rules relevant to a claim are
easy to identify; and whether the rules can be viewed by

workflow activity

and by

workflow role
.



In the
data quality

construct, we evaluate the BPRE’s ability to ensure claim
data
a
ccuracy
, rule accuracy with regard to
client requirement

and
regulatory compliance
, and
the
processing quality

judged by operational quality metrics.



In the
workforce flexibility

construct, we assess organization agility in terms of
ease of
case assignm
ent

to less experienced claim processors,
speed to adapt
to new rules,
required
training time
for new claim processors.


The pre
-
implementation survey was conducted two months before the BPRE module was
added to the claim processing workflow application. T
he post
-
implementation survey was
conducted five months after the BPRE software installation. The experimental group consisted of
claim processors in the life claim division in the subject company. We chose a control group that
consisted of claim processor
s in the disability claim division within the same company. The
disability claim division uses a similar claim application but did not have a rule engine in place
during this experimental period. The disability claim application has built
-
in decision table
s that

are used to guide claim processors client specific claim handling rules and some regulatory
rules
2
.

The survey instrument in the Appendix was administered under the pre
-
and post
-
test
conditions to both the experimental and control groups. We asked a
pplication users to rate their
satisfaction with the existing application’s ability to handle the business process rules in terms of
the usefulness, ease
-
of
-
use, rule maintainability, rule transparency, data quality, and workforce
flexibility constructs by

choosing from a five
-
point Likert scale ranging from 1 (Strongly
Disagree) to 5 (Strongly Agree). In addition to questions related to each of the above constructs,
the survey contained one Likert
-
type scale related to overall satisfaction of users with th
e system
and two open
-
ended questions. The “LCMS” mentioned in the questions refers to the Life Claim
Management System. In the control group survey, the application name is changed to “Disability
Claim Management System.”

Since most of the questions had b
een pre
-
tested in the previous design requirements
survey, we only pre
-
tested the survey on 3 senior claim managers to evaluate the questionnaire
adequacy and to avoid any confusion the respondents might have. A Lotus Notes application was
developed to pre
sent the questions and collect responses for both the surveys. In the pre
-

and
post
-
implementation surveys, our population size is around 150 people in both experimental
group and control groups. The surveys were distributed by email through division heads
. We
received 42 responses from the experimental group in the pre
-
implementation survey and 33 of
them responded in the post
-
implementation survey. For the control group, we received 34
responses from the pre
-
implementation survey and 29 of them responded
in the post
-
implementation survey.


Survey Results


The Reliability of the six constructs in the survey instrument was tested using
Chronbach’s alpha and found in all cases to be above the minimum recommended value of 0.70.

We ran t
-
tests for both the expe
rimental group data and control group data to compare the mean
difference between the pre
-

and post
-
implementation survey data, and to determine if the results
were significant. Table 2 provides a summary of the t
-
test results from the experimental group’s

pre
-

and post
-
implementation survey data. We paired the average rating of questions within each
construct in the pre
-
implementation survey with the average rating in the same construct from
the post
-
implementation survey for each respondent. Table 3 shows

the t
-
test results from the
control group.


Table 2 Experimental Group Pre
-

and Post
-
implementation Survey Summary

Experimental
Group

Construct

Usefulness

Ease of Use

Rule Main
-
tainability

Rule Trans
-
parency

Data
Quality

Workforce
Flexibility

Overall
Sat
isfaction

Paired Sample

N

32

33

27

28

32

32

33

Pre
-
implementation

Mean

3.27

3.85

2.64

2.60

3.16

2.71

2.91

Std. Dev.

1.02

0.72

1.32

1.28

1.04

1.22

1.01

Post
-
implementation

Mean

3.95

4.08

3.79

3.62

3.74

3.51

3.70

Std. Dev.

0.59

0.41

0.51

0.64

0.66

0.6
9

0.68

t
-
Test

Mean Diff.

0.68

0.23

1.15

1.02

0.58

0.80

0.79

t Value

4.156

2.174

5.653

4.437

3.772

4.544

4.561

Sig. (2
-
tailed)

0.000

0.037

0.000

0.000

0.001

0.000

0.000




2

Based on the success of the BPRE implementation described in this paper, th
e Disability Claim Division is now
implementing their own BPRE system.



Table 3: Control Group Pre
-

and Post
-
implementation Survey Summary

Control Group

Construct

Usefulness

Ease of Use

Rule Main
-
tainability

Rule Trans
-
parency

Data
Quality

Workforce
Flexibility

Overall
Satisfaction

Paired Sample

N

29

29

28

29

29

28

29

Pre
-
implementation

Mean

4.01

4.26

3.16

3.25

3.90

3.11

3.38

Std. Dev.

0.64

0.58

0.99

0.90

0.72

0.95

0.78

Post
-
implementation

Mean

4.05

4.03

3.05

3.31

3.97

3.18

3.45

Std. Dev.

0.54

0.62

0.90

0.69

0.60

0.83

0.83

t
-
Test

Mean Diff.

0.04

-
0.23

-
0.11

0.06

0.08

0.07

0.07

t Value

0.74

-
2.35

-
1.15

0.70

1.22

0.70

0.53

Sig. (2
-
tailed)

0.466

0
.026

0.260

0.491

0.231

0.491

0.602


The results of t
-
tests of the hypotheses are shown in the tables. All seven hypotheses were
supported. The level of significance of the difference of pre
-

and post
-
test means was below
0.001 for six of the hypotheses an
d below 0.05 for the ease
-
of
-
use hypothesis. There were no
significant differences in the pre
-
test and post
-
test means for the control group.

In the pre
-
implementation survey, the experimental group’s overall satisfaction with the
application‘s rule handli
ng capability was at 2.91, slightly below neutral. In the post
-
implementation, the satisfaction level rose to 3.70 that is close to the satisfied level. We also
observe that the experimental group’s satisfaction level was lower than that of the control gro
up
at the time of the pre
-
implementation survey, but exceeds that of the control group after the
BPRE implementation. The control group’s higher initial satisfaction level could suggest the
advantage gained through utilizing rule decision tables by the con
trol group over the
experimental group. Once BPRE is implemented in the experimental group, the situation is
reversed. The results from the control group show no significant changes in any of the six
constructs or in overall satisfaction, which could indic
ate that there is no major environment
factor during this pre
-

and post
-
implementation period that would influence the users’ survey
responses. These results validate the efficacy of the BPRE implementation by demonstrating the
subjective improvements in u
ser satisfaction in terms of usefulness, ease
-
of
-
use, rule
maintenance, rule transparency, data quality, and organization flexibility.


The Implementation Experience


The project followed the waterfall model of system development life cycle that includ
es
business requirement gathering, system specification development, coding, quality assurance
testing, user acceptance testing, user training, and production installation. Three hundred person
-
days were invested in the project over a six
-
month period. The

project team included one project
manager, one business analyst, one system analyst, one system architect, two developers, and
several business testers.

During the initial implementation, business rule administrators were able to add more
than two hundr
ed new special client claim handling rules and statutory rules without the need for
any system changes. An additional 1,500 new regulatory rules will be added in coming months.


The following challenges were encountered during the project:



Many business r
ules are hard
-
coded in different parts of the existing claim application
making them hard to identify and extract into the BPRE without fully understanding the
code. Although not a preferred option, the decision was made to leave the code as is

without mig
rating all the existing application logic to the BPRE. Thus, only new business
rules or existing rules that need to be changed are added in the BPRE.



During the business requirement stage, we found many business process rules,
particularly special clien
t claim handling rules, with inconsistent format between claim
processing teams and among divisions. Excel spreadsheets were the most popular means
to record rules, but there was no version control. Sticky notes were commonly used.
Although it is time cons
uming for the business analyst to collect the latest rules and
organize them in a consistent format, many of these rules were included in the BPRE
implementation.



After BPRE implementation, in some rare cases when customer demand was particularly
urgent
and the action template design was complex with the possibility of only one time
usage, programmers chose to hard code the logic in order to save time.


Discussion

In contrast to the prior relational active database (ADBMS) research prototype systems,
e.g
., POSTGRES
[30]
, HiPAC
[31]
, Starburst
[
32]
, and Ariel
[33]
, that integrated the Rete or
TREAT

algorithm into their production rules engines, we implemented the new BPRE algorithm.

Unlike BPRE, these ADBMS prototype rules engines employ database
triggers

to implement the
“On Event, If Condition, Then Action” ECA language
[34]
. Other researchers also provide code
-
based extensions to the ECA languages
[35, 36]
. Our design stores ECA rules in database tables,
which eliminates the concern in an ADBMS system that “uses a centralized active database
management system, which ren
ders distribution, openness, and scalability hard to achieve”
[37]
.
The database approach also simplifies rule maintenance and eliminates black
-
box issues that are
inherited from the traditional code
-
based design approach
[5]
. Compared to other systems that
implement some version of the Rete approach, our BPRE design avoids the large computational
and memory overhead associated with building and maintaining a Rete network.
In our design,
co
mplexity is controlled and usability is enhanced by providing different views for users in
different contexts. T
o satisfy the design requirement for quality and accuracy of the rules, a
special rule maintenance workflow was built into the rule authoring fa
cility to ensure version
control, enforcement of approval processes, and audit capabilities.


To date, business rule administrators were able to add more than two hundred new
special client claim handling rules and statutory rules without the need for any

system changes.
With the on
-
line claim processing advice provided during claim adjudication, claim managers no
longer need to search paper
-
based special claim processing rules, less experienced claim
managers are assigned to more complicated claims. With
the on
-
line claim processing advice
provided during claim adjudication, claim managers no longer need to search paper
-
based
special claim processing rules and less experienced claim managers can be assigned more
complicated claims. Actions executed by the
BPRE are logged and are viewable by all workflow
participants, which increases both auditability and learning by participants.


Conclusion

At the outset of this project, we had two major concerns: Would the database
-
oriented
BPRE perform efficiently in a p
roduction environment? and Would business administrators and
claim processors find the new approach both easier to use and more transparent? The evidence to
date is positive regarding both these concerns. First, the database
-
oriented BPRE has been found
to

run efficiently in a production environment and to scale very efficiently as new rules are added

to the rule base. Second, the BPRE design has been found to be easy to use and understand. The
BPRE helps the claim application users in both understanding th
e business rule logic and
executing the intended tasks.
This design can be easily implemented in a database workflow
application. Future issues to be studied include
developing a rule validation process to prevent
rule conflicts

and investigating rule mana
gement issues at the enterprise level
.



References

1.

Hevner, A., et al.,
Design Science in Information Systems Research.

MIS Quarterly, 2004.
28
(1): p. 75
-
105.

2.

zur Muehlen, M.,
Work
-
flow Based Process Controlling
. 2004, Berlin: Lo
gos Verlag.

3.

Georgakopoulos, D. and M. Hornick,
An Overview of Workflow Management: From Process
Modeling to Workflow Automation Infrastructure.

Distributed and Parallel Databases,
1995(3): p. 119
-
153.

4.

Hall, C. and P. Harmon,
The 2006 BPTrends Report
on Business Rules Products
. 2006,
Business Process Trends.

5.

Morgan, T.,
Business Rules and Information Systems
. 2003: Addison Wesley.

6.

CODASYL,
A Modern Appraisal of Decision Tables
. 1982, Decision Table Task Group,
ACM.

7.

Moreno, G.A., M. Verhelle, a
nd J. Vanthienen,
An Overview of decision table literature
1982
-
2000
. 2000, K.U.Leuven.

8.

Hay, D., K.A. Healy, and A. Kolber,
GUIDE Business Rules Project Final Report
. 2000.

9.

Ross, R.G.,
Principle of the Business Rule Approach
. 2003: Addison
-
Wesley.

10
.

von Halle, B.,
Business Rules Applied
. 2001: John Wiley & Sons.

11.

Wilson, K.D.,
IMPLEMENTING BUSINESS RULES WITH INFERENCING.

Business Rules
Journal, 1999(7).

12.

Huang, W.,
Business Process Rules Management: Challenges and Solutions
, Dissertation
Prop
osal, Howe School of Technology Management, Stevens Institute of Technology, 2007.

13.

ACT
-
NET_Consortium,
The Active Database Management System Manifesto: A Rulebase of
ADBMS Features.

1996.

14.

Paton, N.W. and O. Diaz,
Active Database Systems.

ACM Comput
ing Surveys, 1999.
31
(1).

15.

Forgy, C.L.,
Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match
Problem.

Artificial Intelligence, 1982.
19
(1): p. 17
-
37.

16.

Rankins, R., et al.,
Sybase SQL Server 11
.
1999: Sams Publishing.

17.

Davis, F.D.,

R.P. Bagozzi, and P.R. Warshaw,
User Acceptance of Computer Technology: A
Comparison of Two Theoretical Models.

Management Science, 1989(August): p. 982
-
1003.

18.

Venkatesh, V. and F.D. Davis,
A Theoretical Extension of the Technology Acceptance
Model: Fo
ur Longitudinal Field Studies.

Management Science, 2000.
46
(2): p. 186
-
204.

19.

Venkatesh, V., et al.,
User Acceptance of Information Technology: Toward a Unified View.

MIS Quarterly, 2003.
27
(3): p. 425
-
478.

20.

Baroudi, J.J. and W.J. Orlikowski,
A Short
-
Form Measure of User Information Satisfaction:
A Psychometric Evaluation and Notes on Use.

Journal of Management Information Systems,
1988(Spring): p. 44
-
59.

21.

Doll, W.J., W. Xia, and G. Torkzedeh,
A Confirmatory Factor Analysis of the End
-
user
Computing

Satisfaction.

MIS Quarterly, 1994(December): p. 453
-
461.

22.

Melone, N.P.,
A Theoretical Assessment of the User
-
Satisfaction Construct in Information
Systems Research.

Management Science, 1990.
36
(1): p. 76
-
91.


23.

Boehm, B.W., J.R. Brown, and L. M.
Quant
itative Evaluation of Software Quantity
. in
2nd
International Conference on Software Engineering
. 1968: 1976.

24.

Sunazuka, T., M. Azuma, and N. Yamagishi.
Software Quality Assessment Technology
. in
8th international conference on Software engineering
. 198
5. London, England.

25.

Boehm, B., et al.
Applying WinWin to Quality Requirements: A Case Study
. in
Proceedings
of the 23rd International Conference on Software Engineering
. 2001. Toronto, Ontario,
Canada.

26.

Chisholm, M.,
How to Build a Business Rules En
gine
. 2004: Morgan Kaufmann.

27.

Strong, D.M., Y.W. Lee, and R.Y. Wang,
Data Quality in Context.

Communications of
ACM, 1997.
40
(5): p. 103
-
110.

28.

Miers, D., P. Harmon, and C. Hall,
The 2006 BPM Suites Report
. 2006, Business Process
Trends.

29.

Lienhard,

H. and U.
-
M. Kunzi,
Workflow and Business Rules
-

A Common Approach
, in
Workflow Handbook
. 2005, Future Strategies, Inc. p. 129
-
139.

30.

Stonebraker, M., E.N. Hanson, and C.
-
H. Hong.
The Design of the POSTGRES Rules System
.
in
International Conference on
Data Engineering
. 1987.

31.

Dayal, U., et al.,
The HiPAC Project: Combining Active Databases and Timing Constraints.

ACM SIGMOD Record, 1988.
17
(1).

32.

Haas, L.M., et al.,
Starburst Mid
-
Flight: As the Dust Clears.

IEEE Transactions on
Knowledge and Data E
ngineering, 1990.

33.

Hanson, E.N.,
The Design and Implementation of the Ariel Active Database Rule System.

IEEE Transactions on Knowledge and Data Engineering, 1996.
8
(1).

34.

Dayal, U., E.N. Hanson, and J. Widom,
Active Database Systems
, in
Modern Databa
se
Systems: The Object Model, The Interoperability, and Beyond
, W. Kim, Editor. 1994.

35.

Casati, F., et al.,
Specification and Implementation of Exceptions in Workflow Management
Systems.

ACM Transactions on Database Systems, 1999.
24
(September): p. 405
-
4
51.

36.

Kumar, A. and J.L. Zhao,
Dynamic Routing and Operational Controls in Workflow
Management Systems.

Management Science, 1999.
45
(2).

37.

Geppert, A. and D. Tombros,
Event
-
based Distributed Workflow Execution with EVE
, in
SWORDIES Report
. 1998.



APP
ENDIX

Pre
-

and Post
-
Implementation Survey Sample Questionnaire

Section A. Please choose your answer for each of the following questions. If the function described is not currently
available in the LCMS, please select “Strongly Disagree”

Questions

Strongl
y

Disagree


Disagree

Neutral

Agree

Strongly
Agree

NA

USEFULNESS







1.1 The LCMS is consistently able to provide
me relevant and accurate business rules relating
to a claim

1

2

3

4

5


1.2 The LCMS is able to provide claim
processing rules to me quick
ly

1

2

3

4

5


1.3 Using the LCMS enable me to accomplish
my work faster

1

2

3

4

5


1.4 The LCMS is useful to my job

1

2

3

4

5


EASE OF USE







2.1 Learning to use the LCMS is easy for me

1

2

3

4

5



2.2 I have the knowledge necessary to use the
LCMS

1

2

3

4

5


2.3 The LCMS provides me easy to understand
fatal edits and warnings

1

2

3

4

5


2.4 I find the LCMS easy to use

1

2

3

4

5


RULE MAINTAINABILITY







3.1 The LCMS makes it easy to create or
update claim processing rules

1

2

3

4

5


3.2 The L
CMS makes it easy to select rule
components from a list of available events,
conditions, and systems services

1

2

3

4

5


3.3 The LCMS helps reduce the time required
to publish, communicate, and enforce new
claim process rules

1

2

3

4

5


RULE TRANSPARENCY







4.1 The LCMS allows me to view claim
processing rules relevant to a claim

1

2

3

4

5


4.2 The LCMS allows me to view all the
business rules by claim processing activity

1

2

3

4

5


4.3 The LCMS allows me to view all the
business rules by job funct
ion

1

2

3

4

5


DATA QUALITY







5.1 The LCMS helps ensure claim data
accuracy

1

2

3

4

5


5.2 The LCMS helps ensure claims are
processed correctly according to the clients’
requirements

1

2

3

4

5


5.3 The LCMS helps ensure claims are
processed correc
tly to meet regulatory
requirements

1

2

3

4

5


5.4 The LCMS helps enhance overall claim
processing quality to improve quality metric
results

1

2

3

4

5


WORKFORCE FLEXIBILITY







6.1 I feel comfortable in giving sensitive case
claims to less experience
d claim managers by
relying on the LCMS to provide all the business
rules

1

2

3

4

5


6.2 With the LCMS, I can react quickly to
changes in the claims process due to new client
or regulatory requirements

1

2

3

4

5


6.3 With the LCMS, new claim managers can

quickly learn how to process claims
independently

1

2

3

4

5



Section B.

Overall, how satisfied are you with the current LCMS’ ability to help you meet special client requirements,
statutory regulations, and/or other claim processing rules?

Very

Dissat
isfied


Dissatisfied

Neutral


Satisfied

Very

Satisfied

NA

1

2

3

4

5


Section C. Please provide your comments on the current LCMS’ ability that helps you meet the claim processing rules.

___________________________________________________________________
_______________________

Section D. Please provide your comments on limitations of the current LCMS that make it difficult for you to perform
your role in the claims process.

__________________________________________________________________________________
________