Motivation Scenario Transport of a Very Low Birth Weight Infant

This scenario involves the transport of a very low birth weight infant, weight under 750 grams, at 25-26 weeks gestation, from a rural hospital located approximately 100 miles from the Medical College of Georgia (MCG) to the MCG Neonatal Intensive Care Unit (NICU). The transport takes 2.5 hours. In the ambulance there are several healthcare professionals who perform different roles. During the transport, the ambulance personnel will perform the standard procedures to obtain medical data for the infant. If there are any deviations (exceptions) identified during the transport, corrective actions must take place. The decision of the corrective procedures involves collaboration and coordination between the ambulance personnel and the consultants at MCGís NICU.

It is usually not possible to enumerate or detail all solutions to those exceptions in a workflow. This is where defeasible workflow can be used. The basic principle of defeasible workflow is that common sense rules can be applied by default, unless there are specific reasons to the contrary. Each specific situation may express conflicting interests and values. The coordination of conflicting profiles is often accomplished by establishing preference relations that one prevails over the others, generally or under specific circumstances. This approach also recognizes that there are many problems that cannot be completely covered by a theoretical model but can only be solved with the help of experience.

Workflow Building Blocks

We have defined several building blocks such as AND-split/join, OR-split/join and Loop in our METEOR system (see figure 2.1) to form a representational framework to express the operational semantics of organization processes with necessary preference constraints and an initial set of preference and indifference expressions. A group of input transitions, by default, is an OR-join. It is called an AND-join if all of the participating transitions must be activated for the task to be enabled for realization. A group of common source transitions is called an AND-split if each of the transitions in the group has the condition set to true. It means that all of the transitions in the group are enabled, once the task completes. A group of common source transitions called an OR-split is an ordered list of transitions where all but the last transition may have arbitrary conditions. The last transition on the list has the condition set to true. A loop is a special case of an OR-split, where the list is composed of exactly two transitions. Structural constraint of a loop requires that all of the paths beginning with one of the transitions and none of the paths beginning with the other transition cycle back to the source task.

Figure 2.1 METEOR Architecture

Justified Event-Condition-Action (JECA) rules are used to specify these blocks. ECA rules allow for an event-driven realization of context and time dependent behavior that constitutes a major property of coordination policies [Kappel et al. 1998]. Justification provides a reasoning context for the evaluations of ECA rules. By encapsulating coordination policies within JECA rules, general knowledge can be represented in association with necessary context. Each JECA rule consists of four parts as follows:

• Justification: Justification forms the reasoning context in which selection of the specific JECA rule can be decided.
• Event: when event occurs, related JECA rules will be evaluated.
• Condition: logic constraints to be satisfied so the action in the rule can be taken.
• Action: necessary actions to be taken when this rule is not denied, events occur, conditions are met.

Workflow computation

In our approach, a workflow system is considered as a reactive system that maintains an ongoing interaction with its environment. It is assumed the all variables that describe the properties of workflows are taken from a set of variables, called workflow variable set or vocabulary. Instances of those variables form the workflow environment. Situation of the activities in workflows at a certain point of time is called a workflow state. A workflow state may contain one or more sub-workflow states. An initial state is a state at which the computation of a workflow can start. A final state is a state at which the computation of a workflow can stop. Inter-activity dependence constraints are enforced through workflow transitions that are specified through a mapping function,

d : S ® S ,

which maps a state s Î S into another state d (s) Î S . State d (s) is called a d -successor of s. A workflow transition d is enabled on the state s if d (s) ¹ Æ . Otherwise, we say d is disabled on s. A workflow transition may contain many sub-transitions.

Workflow States and transitions are specified in defaults that have three parts, prerequisite, justification and consequence specified in logic expressions constructed through JECA rules with mappings from J to justifications, C to prerequisite, and A to consequence. In order to apply the defaults, the prerequisite of the defaults should be proved. It is required that the defaults should be justified. This means the justifications should not deny the applicability of the default. Consequence, the third part in a default, forms a belief set. The defeasible reasoning process should resolve inconsistencies existing in the belief set.

Definition Workflow Computation
s is a sequence of workflow states s₀, s₁, Ö, s_n. Transition d is enabled at position k of s if d is enabled on s_k. Transition d is justified at position k of s if s_k+1 is a d -successor of s_k. The sequence of s is to be a workflow computation if it satisfies the following requirements:

• Initial: s₀ is initial.
• Consecutive: For each j = 0, 1, 2, Ö, n the state s_j+1 is a d -successor of the state s_j. d is a workflow transition.
• Terminal: s_n is a final.
• Fair: The workflow policy on which the selection of enabled transition(s) is based should be fair.

Evaluation Architecture

Workflow computation involves defaults evaluation. The approach for defaults evaluation is to look for preferred defaults, i.e., defaults leading to justified consequences. A clustered and layered reasoning architecture is developed. The defaults are clustered into several domains. Each default is associated with a local reasoning unit. If the local reasoning unit cannot make an acceptable decision, another reasoning unit at the domain layer that can get access to domain context will be consulted. A global reasoning unit is responsible for decision making in the global context. The local reasoning unit can also make a decision according to the partially available information without consulting another local unit or a unit at a higher level. This layered reasoning architecture is well suited in workflow management because organizational processes modeled by workflows are clustered and/or hierarchical in nature in which local decisions can often be reached. The criteria used in clustering can be either one or a combination of the following:

• Security: For security reasons, defaults must be clustered so sensitive information can be transmitted in a controlled manner.
• Organization: It is natural to cluster defaults into several domains to model the organizational structure in that organization.
• Performance: To provide better performance, it is necessary to cluster the defaults into several domains in which defaults can be more effectively managed.

Conflicts resolution

Inconsistent information in workflows can lead to conflicts during workflow execution. Conflicts in workflow execution can be either one or more of the following:

• Temporal conflict: Defaults formed in subsequent times result in conflicts.
• Role conflict: Defaults evaluated by different roles result in conflicts.
• Semantic conflict: Alternative interpretation of the consequence of defaults occurs.

To resolve those conflicts, the defaults of workflow systems are assigned priorities, or more generally, are ordered by partial ordering relations regulated in workflow policies. That is, some defaults may be preferable to others, and assuming they are applicable, they should be used first. To resolve any inconsistencies, workflow polices taken are based on:

• Special: Preference will be given to exceptions over existing JECA rules. For example, whenever a local decision cannot be made, an exception is always raised.
• Hierarchical: Consequences derived at higher positions in the hierarchy will be favored over those at lower positions. In the example scenario, if the medical situation of the infant becomes serious, the decision made by the personnel at a higher position who can be responsible for the action taken will be preferred.
• Temporal: Consequences from the latest defaults will be favored over earlier ones. In the example scenario, the personnel on board may consult the experts in the MCGís care unit. During the decision making process, the experts might give one suggestion at one time, and later they might come up with another suggestion. The later one might be given a higher priority during the decision making.
• Semantic: Interpretations that are more plausible will be preferred to less plausible ones. In the example scenario, if a symptom is discovered and if it might be caused by several different reasons, the personnel on board may derive one he believes is the most reasonable.

Exception handling

With the intention towards running in heterogeneous and often distributed environments, robustness and interoperability of workflow systems have become much more important. The exception-handling construct, as well as the underlying mechanism, is meant to be sufficiently general to cover various aspects of exception handling in a uniform way. So it can help separate the modules to handle unusual situations from the modules for the normal cases. [Strong and Miller 1995] point out that designing an integrated human-computer process may provide better performance than eliminating exceptions and moving toward an entirely automated process. We believe the defeasible reasoning [Marek and Truszynski 1993] and case-based reasoning [Aamodt 1994] can help the processes of the identification of exceptions and the derivation of acceptable exception handlers.

In the example scenario, when an exceptional symptom is discovered, the personnel on board should make decisions, assisted by the process automation mechanism, as to which procedures (sub-workflows) should be taken. To coordinate such closely integrated human-computer processes, case-based mechanism is considered as a good integration technique. When the case-based reasoning component is notified about the exceptional situation of the infant, cases stored in the case repository will be analyzed. The result from the analysis is used to facilitate the decision making process.

Abnormal events, exceptions and handlers

An exception is an occurrence of some abnormal event that the underlying workflow management system can detect and react to. An exception signal may be sent manually, by an external program, or by a workflow administrator. All exceptions form a hierarchy rooted at class Exception (see Figure 2.2). Two basic groups of exceptions include system exceptions and application-defined exceptions. A variety of system exceptions identify a number of possible system-related errors such as response, time and omission errors in the services provided by the workflow system. Response error occurs when the results from a service are not correct. The request of services that is served in an untimely manner results in a time error. When the service provider omits a service request, an omission error occurs. User-defined exceptions are specified by the workflow designer and identify possible application-dependent errors in task realizations. Specific user-defined exceptions depend on the specific workflow application. An exception handler is a description of action(s) that workflow runtime component(s), or possibly a workflow application, is going to perform in order to respond to the exception. Exceptional situations, such as the location of control and exception type, should be identified.

Figure 2.2 Exception Hierarchy

>

Case based exception handling

The case based approach models how reuse of stored experiences contributes to expertise. In this approach, new problems are solved by retrieving stored information about previous problem solving steps and adapting it to suggest solutions to the new problems. The results are then added to the case repository for future use. The procedure of selection of similar previous cases is based on the similarity measure that takes into account both semantic and structural resemblance and differences between the cases. A simple similarity measure can be achieved by computing the nearest neighborhood function of the quantified degrees of those semantic and structural similarities. A case usually consists of three parts: problem, solution and effect. The status of cases in the workflow execution is illustrated in Figure 2.3.

Figure 2.3 Case Resolution Cycle

During the workflow execution, when an exception is raised, defeasible reasoning and case-based reasoning are used to derive an acceptable exception handler. We adopt a view of competence-driven exception handling. A component that has a handler specified for a given exception is said to be competent to handle the exception. The component hierarchy induces a competence hierarchy. Exceptions are handled according to the competence hierarchy in the following way. In case an exception occurs, it is first made available to the workflow component in which the flow of control resides. If the component is competent to handle the exception, that is it has at least one handler for the given exception type, it handles the exception. On the other hand, if the component does not have the competence for the exception, the exception is passed on to the next higher level in the competence hierarchy. Human involvement is needed when acceptable exception handlers can not be automatically obtained. Solutions given by a person will also be incorporated into the case repository. Effects of the exception handler candidates on the workflow system and applications will be evaluated. Thus, when the exception is handled, necessary modifications to the workflow system can be made. There are four steps in the exception handling by exception handler that involve case-based reasoning [Aamodt 1994]:

• Retrieval of the most similar cases to the identified exception situation
• Validation of the solution from most similar cases
• Adaptation of the most similar cases
• Updating of the system by adding the verified solution to the case database.

Figure 3.1 METEOR components

Implementation

Our implementation in progress is based on component technology. Components are the smallest self-managing, independent, and useful parts of a system that work in multiple environments [Lewandowski 1998]. As shown in Figure 3.1, we currently have two runtime workflow engines: WebWork [Miller et al. 1998] and ORBWork [Sheth and Kochut 1997]. A workflow application is designed by using workflow designer. The designed workflow is either saved as a wil (a workflow specification language) file or stored into the workflow repository. Workflow engines enforce the inter-activity dependence. The workflows are monitored and administrated by the workflow runtime administrator. The capabilities of handling uncertainties and exceptions are enhanced by the defeasible reasoning component and case-based reasoning component. The workflow bus provides an uniformed message channel that connects all the workflow components including the authentication component as a working system.

Conclusion and Future Directions