Modeling case management processes For discussion

Motivation Case management processes are rather different from production workflow processes. It is not clear how BPMN can adequately support semi-structured processes in general, and case management processes in particular. It could make sense to seek consensus within OMG/BM&I task force regarding a modeling paradigm for case management, and to extend business modeling standards accordingly.

Case management processes are rather different from production workflow processes.

It is not clear how BPMN can adequately support semi-structured processes in general, and case management processes in particular.

It could make sense to seek consensus within OMG/BM&I task force regarding a modeling paradigm for case management, and to extend business modeling standards accordingly.

Disclaimer Cordys did not yet decide to adopt modeling paradigms as suggested in this presentation … These suggestions are just meant to trigger discussion within OMG’s BM&I task force. In this presentation formal BPMN notation is not followed, since that would not add specific value to the discussion at hand.

Cordys did not yet decide to adopt modeling paradigms as suggested in this presentation …

These suggestions are just meant to trigger discussion within OMG’s BM&I task force.

In this presentation formal BPMN notation is not followed, since that would not add specific value to the discussion at hand.

Definition “ Case”, according to Webster ( http://www.m-w.com/dictionary/case ) : (1) A situation requiring investigation or action (as by the police) (2) The object of investigation or consideration Case Management Society of America (CMSA): “ Case management” is a collaborative process of assessment, planning, facilitation, and advocacy for options and services to meet an individual's < health > needs through communication and available resources to promote quality cost-effective outcomes. Probably more clear ( http://www.emc.com/analyst/pdf/20854_IDC_Citizen_Service.pdf ) : “ Case management” is a set of processes and technologies that, in response to internal or external event triggers , enable <government> employees to set up workflows to assess, plan, perform, monitor, and evaluate the options and services required to reach the optimum value and desirable outcomes for all constituents (citizens).

“ Case”, according to Webster ( http://www.m-w.com/dictionary/case ) :

(1) A situation requiring investigation or action (as by the police)

(2) The object of investigation or consideration

Case Management Society of America (CMSA):

“ Case management” is a collaborative process of assessment, planning, facilitation, and advocacy for options and services to meet an individual's < health > needs through communication and available resources to promote quality cost-effective outcomes.

Probably more clear ( http://www.emc.com/analyst/pdf/20854_IDC_Citizen_Service.pdf ) :

“ Case management” is a set of processes and technologies that, in response to internal or external event triggers , enable <government> employees to set up workflows to assess, plan, perform, monitor, and evaluate the options and services required to reach the optimum value and desirable outcomes for all constituents (citizens).

Case management examples http://www.gov.bc.ca/ajo/down/case_management_best_practices.ppt#5 Complaints tracking Issues tracking Appeals resolution Licensing & permitting Inspection tracking Call center Claims Medical diagnosis Mortgage application Insurance application Citizen service

http://www.gov.bc.ca/ajo/down/case_management_best_practices.ppt#5

Complaints tracking

Issues tracking

Appeals resolution

Licensing & permitting

Inspection tracking

Call center

Claims

Medical diagnosis

Mortgage application

Insurance application

Citizen service

Case management in BPM In BPM nobody has given a clear definition yet, but there seems to be consensus on the following characteristics of case management processes: The “case” and its data serves as sole and shared context for any activity that executes on the case. Case workers are professionals dealing with knowledge-intensive work. Such professionals cannot be limited by a-priori specified process models, and they should have access to all relevant case data at all times. Case management processes are state-based (event-driven) and/or rule-based (data-driven), probably more than flow-based (sequence-driven).

In BPM nobody has given a clear definition yet, but there seems to be consensus on the following characteristics of case management processes:

The “case” and its data serves as sole and shared context for any activity that executes on the case.

Case workers are professionals dealing with knowledge-intensive work. Such professionals cannot be limited by a-priori specified process models, and they should have access to all relevant case data at all times.

Case management processes are state-based (event-driven) and/or rule-based (data-driven), probably more than flow-based (sequence-driven).

Typical case management process (top-level) http://www.gov.bc.ca/ajo/down/case_management_best_practices.ppt#5 Case work is normally subdivided into a number of phases (state-based flow) The typical flexible and knowledge-intensive case work takes place within the phases We will discuss both levels of processing, as well as the combination of both

Diagram: Case life cycle states (example states) Situation Assessment event x event z Establish Plan Service Delivery event y Preparation : Regular (“external”) state transition Probably we would not need the complete UML 2.1 state machine semantics. We adjust its notation to our “business modeling” needs.

Meta-model: Case and case life cycle definitions States can be composite In some case management environments, “top level states” are called “states” and lower level states are called “milestones”

Meta-model: Case definition

Diagram: Case activities executed during case life cycle Situation Assessment event x event z Establish Plan Service Delivery event y Preparation How to control case activities ? And how to model case activity control ? => See next pages … Let’s first have a closer look at case events We will refine the diagram in a step-wise way, during the remainder of the presentation a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Meta-model: Case events (like UML events) Note: A change is represented by a condition (context: case definition). Certain changes would be useful as case events (case information change events).

Case events: milestone events and follow-up events We can differentiate events according to another dimension also: Follow-up events : Important case events, which serve as trigger to add more case activities to the case instance (define more case-work), automatically by the system, or manually by a case worker . Milestone events : Important case events, which serve as trigger to transit to a next case state. Note: Some case events might be used for both purposes

We can differentiate events according to another dimension also:

Follow-up events : Important case events, which serve as trigger to add more case activities to the case instance (define more case-work), automatically by the system, or manually by a case worker .

Milestone events : Important case events, which serve as trigger to transit to a next case state.

Note: Some case events might be used for both purposes

Case events: milestone events and follow-up events case creation signal like “approval” activity completion case info change case info creation usefulness as milestone event usefulness as follow-up event Milestone event: To trigger transition to other case state Modeled by regular transition Follow-up event: To trigger selection of “follow-up” activities Modeled by follow-up on activity or follow-up on “local” transition (see next pages)

Defining follow-up activities (just imagine like this) Automatic Manual Any that applies Spot Verification Medical Test Verify Claim History Approve Claim For auto-selection by system For manual selection by case worker (optionally) Example: Follow-up activities which can be selected based on completion of case activity “Verify Claim”.

Defining follow-up activities (just imagine like this) Automatic Manual Approve Claim For auto-selection by system For manual selection by case worker (optionally) Any that applies Same example

Defining follow-up activities It would also be logical to define activities as “follow-up” activities on creation of the following: Case (instance) or sub-case (… case creation event …) Instance of case information definition (… case info creation event…) Especially: documents, such as reports, telephone notices, etc.; could be structured information as well. These activities would normally be selected automatically by the system. It could make sense to allow case workers to select activities manually in certain situations (e.g. upon creation of a telephone notice).

It would also be logical to define activities as “follow-up” activities on creation of the following:

Case (instance) or sub-case (… case creation event …)

Instance of case information definition (… case info creation event…)

Especially: documents, such as reports, telephone notices, etc.; could be structured information as well.

These activities would normally be selected automatically by the system.

It could make sense to allow case workers to select activities manually in certain situations (e.g. upon creation of a telephone notice).

Meta-model: Follow-up activities (on follow-up events)

Meta-model: Case life cycle definition refined: Local transition From UML: local transition is event with effect, but without any state exit or entry; transition without transition connector notation

Follow-up event: link follow-up list to case event Case event Act. compl. Link to regular (“external”) state transition Link to activity Follow-up list Follow-up relationships ( ) can be created in the case management diagram, based on these design-time linkages => See next page … Link to local state transition This linkage makes the case event a follow-up event This linkage makes the case event a milestone event Automatic Manual Any Spot Verification Medical Test Verify Claim History Approve Claim

Diagram: Transitions and follow-up relationships Situation Assessment event x event z Establish Plan Service Delivery event y Preparation : Automatic selection by system : Follow-up : Regular (“external”) state transition local trans. : Local state transition (event icon, without transition connector) a a a a a a Follow-up does not imply execution sequence ! a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Applicability of case activities Applicability can be constrained further by “applicability rules”, which can serve as a more refined filter (more refined than just the case definition type), and also as a dynamic filter, based on ongoing case data changes. Such rules would typically be defined via decision tables. Next to applicability rules, we can also consider release rules (“guards”), which can further constrain the actual release of activity instances (further than just the transition to a certain case state) Let’s first analyze case activity control in more detail on the next page …

Applicability can be constrained further by “applicability rules”, which can serve as a more refined filter (more refined than just the case definition type), and also as a dynamic filter, based on ongoing case data changes.

Such rules would typically be defined via decision tables.

Next to applicability rules, we can also consider release rules (“guards”), which can further constrain the actual release of activity instances (further than just the transition to a certain case state)

Let’s first analyze case activity control in more detail on the next page …

Case activity control Any Applicable Planned (activity instance created) Released (activity instance in work-list of case team) … case processing … Filter by case definition (type) and applicability rules (if defined) Filter by “follow-up” list Filter by state dependency and release rules or “guards” (if defined) Milestone event Follow-up event *) Not necessarily (and often not) defined as case event ! Change *) trigger

Case activity control Case activities are executed in a flexible way: Activities in work-list can be executed in any sequence They can also be skipped, or re-done (based on authorizations) It is also possible to start other (“next”) applicable activities, before completing “current” ones. The case worker should be able to look-up activities that are not released due to broken guard conditions.

Case activities are executed in a flexible way:

Activities in work-list can be executed in any sequence

They can also be skipped, or re-done (based on authorizations)

It is also possible to start other (“next”) applicable activities, before completing “current” ones.

The case worker should be able to look-up activities that are not released due to broken guard conditions.

Meta-model: Rulesets for applicability and release rules (filters)

States and rule sets (combination of UML and PRR meta-models) The case might reach a certain state. While residing in that state there is ongoing evaluation of decision table (based on corresponding “case” data changes), which stops when the case transits to another state. From PRR (Production Rules Representation) From UML

Diagram: Rule-based filters in states Situation Assessment event x event z Establish Plan Service Delivery event y Preparation table 1 table 2 : Automatic selection by system : Follow-up : Regular (“external”) state transition local trans. : Local state transition (event icon, without transition connector) Layout of table2: See next page … Note: Filter that would apply during entire case life cycle could be modeled via “top state” (being the most outer state container) a a a a a a a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Decision table: table2 (applicability rules) X X a6 X a5 X X a4 X X a3 X X X a1 Action stubs !=z =z !=z =z !=z =z !=z =z attr3 <y <y >=y >=y <y <y >=y >=y attr2 >=x >=x >=x >=x <x <x <x <x attr1 Condition stubs 8 7 6 5 4 3 2 1 Rules

Decision table for “Applicability” as well as “Release” Next to “applicability filter”, a decision table can also be used as filter for “Release”. A “release rule” is basically a guard. E.g. to check feasibility (to release) by checking whether a piece of information is available (document available or certain fields properly and consistently filled). Separate tables could be used as “release filter”. It would also be possible to use the same table as both “applicability filter” and “release filter” (hybrid). See an example on next page.

Next to “applicability filter”, a decision table can also be used as filter for “Release”.

A “release rule” is basically a guard. E.g. to check feasibility (to release) by checking whether a piece of information is available (document available or certain fields properly and consistently filled).

Separate tables could be used as “release filter”. It would also be possible to use the same table as both “applicability filter” and “release filter” (hybrid). See an example on next page.

Decision table for “applicability” and “release” filter X = Applicable O = Release OX = Both Conditions X O O X act_w X X act_v X OX X act_u Action stubs Attr_z Attr_y Attr_x Condition stubs 4 3 2 1 Rules

Further refinement: Case activity control So-far we assumed discrete “follow-up” events, based on which additional case activities can be selected from a “follow-up” list. The concept would also allow for selection of additional case activities (by a case worker) at any moment, based on the set of all activities that are “applicable” at that moment. A “follow-up” list would not be applicable then. “Applicability rules” could still constrain activity selection.

So-far we assumed discrete “follow-up” events, based on which additional case activities can be selected from a “follow-up” list.

The concept would also allow for selection of additional case activities (by a case worker) at any moment, based on the set of all activities that are “applicable” at that moment. A “follow-up” list would not be applicable then. “Applicability rules” could still constrain activity selection.

Diagram: Dynamic selection of additional activities Situation Assessment event x event z Establish Plan Service Delivery event y Preparation table 1 table 2 a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Further refinement: state transition handling So-far we discussed event-triggered transitions. It would also be possible that the case transits to a next state once all activities (in the work-list), that relate to the current state, have been completed (“completion transition”). When the case transits back to an earlier state (e.g. for rework purpose), it could be logical to re-consider case activities that have been executed in that state. Executed activities should still be visible, and it should be possible to re-do them, based on case worker judgment. When a case event triggers the case to transit to another state, any case activity (that relates to the current state) that is in the work-list, but not yet in progress, should be removed from the work-list, and any case activity (that relates to the current state) that is planned-but-not-yet-released, should be removed from the “planning”. If could sometimes be wanted to also terminate case activities that are in progress (the case team should be notified on termination).

So-far we discussed event-triggered transitions.

It would also be possible that the case transits to a next state once all activities (in the work-list), that relate to the current state, have been completed (“completion transition”).

When the case transits back to an earlier state (e.g. for rework purpose), it could be logical to re-consider case activities that have been executed in that state. Executed activities should still be visible, and it should be possible to re-do them, based on case worker judgment.

When a case event triggers the case to transit to another state, any case activity (that relates to the current state) that is in the work-list, but not yet in progress, should be removed from the work-list, and any case activity (that relates to the current state) that is planned-but-not-yet-released, should be removed from the “planning”. If could sometimes be wanted to also terminate case activities that are in progress (the case team should be notified on termination).

Meta-model: Further refinement: Case tasks, with follow-up and sub tasks All follow-up activities of a sub-task are sub-task of the main task as well A case activity (case task) might be a composite of sub-case activities (sub-tasks), which also might have their follow-up activities (( Here is some similarity with “sub-process” as known from BPMN …))

Evaluation: State- and rule-based, rather than flow-based Cases have a life-cycle with explicit milestones (states). BPMN proposes intermediate event as notion of milestone. But most of the state and state-transition related constructs, as discussed in this presentation, cannot be addressed by that. Case management is event-driven, whereby events are often independent from each other, and can be received at any moment, in any sequence. This would complicate flow-based modeling. Due to the data-driven nature of case management, and the flexibility in executing activities, which is typical for case workers, it will often be difficult to locate rule-based decisions in flow-based (sequence-driven) processes. Ongoing rule evaluation e.g. while the case resides in a certain state allows for more appropriate modeling of rule-based behavior. Flexible case activity control is much easier to model, when a state-based (or state-and-rule-based) modeling paradigm is adopted. A flow-based (sequence-driven) model is less suited for that purpose.

Cases have a life-cycle with explicit milestones (states). BPMN proposes intermediate event as notion of milestone. But most of the state and state-transition related constructs, as discussed in this presentation, cannot be addressed by that.

Case management is event-driven, whereby events are often independent from each other, and can be received at any moment, in any sequence. This would complicate flow-based modeling.

Due to the data-driven nature of case management, and the flexibility in executing activities, which is typical for case workers, it will often be difficult to locate rule-based decisions in flow-based (sequence-driven) processes. Ongoing rule evaluation e.g. while the case resides in a certain state allows for more appropriate modeling of rule-based behavior.

Flexible case activity control is much easier to model, when a state-based (or state-and-rule-based) modeling paradigm is adopted. A flow-based (sequence-driven) model is less suited for that purpose.

Evaluation: More than just “ad-hoc” A diagram that expresses case activity control, as being discussed in this presentation, would be considered “semi-structured” from a BPMN-perspective. However, BPMN ad-hoc sub-process, meant as “semi-structured” modeling construct, does not cover case management requirements. It just offers a process that is not indicating any control at all… A “train of ad-hoc sub-processes” would not offer value from the perspective of “what you model is what you execute”.

A diagram that expresses case activity control, as being discussed in this presentation, would be considered “semi-structured” from a BPMN-perspective.

However, BPMN ad-hoc sub-process, meant as “semi-structured” modeling construct, does not cover case management requirements. It just offers a process that is not indicating any control at all…

A “train of ad-hoc sub-processes” would not offer value from the perspective of “what you model is what you execute”.

Backup slides Some backup slides follow

Some backup slides follow

All that BPMN 1.1 says on states (milestones) “ There may be situations within a Process where the flow is affected by or dependent on the activity that occurs in another Process. These events or conditions can be referred to as milestones .” “ The enabling of an activity depends on the case being in a specified state , i.e. the activity is only enabled if a certain milestone has been reached which did not expire yet.” BPMN seems to re-use (misuse ?) intermediate event icons for this purpose:

Diagram: Case management (refinement) Situation Assessment event x event z Establish Plan Service Delivery event y Preparation table 1 table 2 local trans. a a Activities could be applicable in more than one state. This could be modeled by linking such activities to a parent state. Possibly, a diagram option would be useful to toggle between showing parent state activities only, or child state activities only, or both. a a a a1 a3 a6 a4 a5 a8 a9 a10 a11 a12 a7

Diagram: Case management (refinement) Situation Assessment event x event z Establish Plan Service Delivery event y Preparation table 1 table 2 local trans. : “Before” constraint a a It would also be possible to implement “before” constraints. Meaning: e.g. activity a12 can only be executed after a11 has been executed. Note that this does not imply strict sequence; other activities might be executed in between, or after executing a11, a12 is never executed. a a a a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Diagram: Case management (refinement) Situation Assessment event x event z Establish Plan Service Delivery event y Preparation table 1 table 2 local trans. : Just to indicate the possibility that completion of an activity could trigger a transition ( … probably not a formal diagram element … ) a a a a a a1 a3 a6 a4 a5 a8 a9 a10 a11 a12

Case milestones http://www.dsca.osd.mil/samm/policy_memos/2003/DSCA%2003-16.pdf Lease cases in Defense 30 milestones defined

Case states and milestones http://www.disam.dsca.mil/pubs/Archives/Journal24-1.pdf 23 milestones Cases in Defense 2 levels of states, called “states” and “milestones” here

Case milestones http://www.ferc.gov/legal/admin-lit/Act-Cases-Milestones.Asp?Lead=ER05-343-000&RSL=N

Case milestones http://www.igt.gov.au/content/work_program/Review_into_Tax_Office_audit_timeframes.pdf The Tax Office states that is in the process of implementing a new case management system that incorporates an automated case milestone-setting and review control .

http://www.igt.gov.au/content/work_program/Review_into_Tax_Office_audit_timeframes.pdf

The Tax Office states that is in the process of implementing a new case management system that incorporates an automated case milestone-setting and review control .

Central rule evaluation better than sequence-based decisions in case management Case data changes, based on which applicability rules should fire, can be triggered from multiple activities, dependent on scope of task UI, and authorization of case workers Multiple activities can act on the same case, independently from each other. Case data changes might not be controlled by case workers directly, but might be the result of calculations or automatic processing of incoming information. Case workers (especially authorized ones) don’t follow strict sequence, because of which flow-based decisions aren’t evaluated “as planned” Hence: It is often not possible to determine applicability of activities based on flow-based decision points (gateways, tables) Central applicability rule evaluation (on the case data) would be best.

Case data changes, based on which applicability rules should fire, can be triggered from multiple activities, dependent on scope of task UI, and authorization of case workers

Multiple activities can act on the same case, independently from each other.

Case data changes might not be controlled by case workers directly, but might be the result of calculations or automatic processing of incoming information.

Case workers (especially authorized ones) don’t follow strict sequence, because of which flow-based decisions aren’t evaluated “as planned”

Hence:

It is often not possible to determine applicability of activities based on flow-based decision points (gateways, tables)

Central applicability rule evaluation (on the case data) would be best.

Motivating rule-based (data-driven) modeling in case management (examples) Circumstances (“attribute values”) of cases (case-related subjects) can change “autonomously” at any moment during case processing. E.g.: Patient conditions in healthcare New and unexpected facts might emerge at any moment during case processing in advocacy Financial position (bank remainder, salary, etc.) of clients at any moment during mortgage or insurance case processing Activities that can cause case data changes may be selected at any moment during case processing. E.g.: Request for recommendation of medical service Request for medical test Request for antecedents research Request for risk analysis It can be too restrictive to include certain case data to the scope of a single task. E.g.: Help desk cases: new insights can emerge during execution of any task Medical diagnosis: similar

Circumstances (“attribute values”) of cases (case-related subjects) can change “autonomously” at any moment during case processing. E.g.:

Patient conditions in healthcare

New and unexpected facts might emerge at any moment during case processing in advocacy

Financial position (bank remainder, salary, etc.) of clients at any moment during mortgage or insurance case processing

Activities that can cause case data changes may be selected at any moment during case processing. E.g.:

Request for recommendation of medical service

Request for medical test

Request for antecedents research

Request for risk analysis

It can be too restrictive to include certain case data to the scope of a single task. E.g.:

Help desk cases: new insights can emerge during execution of any task

Medical diagnosis: similar

Motivating rule-based (data-driven) modeling in case management (examples) Probably we could learn also from “industrial cases”, like: Trouble shouting by service engineer Non-conformance analysis by quality engineer A common pattern for handling such cases: First suggestion of “required” tasks, based on type of case After entering first inspection results, the system suggests more tasks, some of which are required, others are available to assist the expert Maybe there are some main stages, which sub-divide the “catalogue” of available tasks into subsets Etc.

Probably we could learn also from “industrial cases”, like:

Trouble shouting by service engineer

Non-conformance analysis by quality engineer

A common pattern for handling such cases:

First suggestion of “required” tasks, based on type of case

After entering first inspection results, the system suggests more tasks, some of which are required, others are available to assist the expert

Maybe there are some main stages, which sub-divide the “catalogue” of available tasks into subsets

Etc.

Motivating some diagram choices Although data-based applicability rules are typically defined via decision tables, events (milestone events as well as follow-up events) are preferably depicted more explicitly. Although follow-up relationships and state transitions could have been defined via separate diagrams, it has advantages to combine them in one: The same event can sometimes serve as both milestone event and follow-up event. When defining follow-up relationships, it raises understanding of case-work, when the case activities are projected against the case life cycle.

Although data-based applicability rules are typically defined via decision tables, events (milestone events as well as follow-up events) are preferably depicted more explicitly.

Although follow-up relationships and state transitions could have been defined via separate diagrams, it has advantages to combine them in one:

The same event can sometimes serve as both milestone event and follow-up event.

When defining follow-up relationships, it raises understanding of case-work, when the case activities are projected against the case life cycle.

Cordys customers Ertan HydroPower PingDingsHan Coal Co.Ltd Larsen & Toubro Ltd. ABN AMRO Verzekeringen, een samenwerkingsverband tussen Delta Lloyd Groep en ABN AMRO