Case Management Processes

Slide 1: Modeling case management processes For discussion

Slide 2: 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. 2

Slide 3: 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. 3

Slide 4: 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). 4

Slide 5: 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 5

Slide 6: 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). 6

Slide 7: Typical case management process (top-level) 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 http://www.gov.bc.ca/ajo/down/case_management_best_practices.ppt#5 7

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

Slide 9: 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” 9

Slide 10: Meta-model: Case definition 10

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

Slide 12: 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). 12

Slide 13: 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 13

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

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

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

Slide 17: 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). 17

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

Slide 19: 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 19

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

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

Slide 22: 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 … 22

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

Slide 24: 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. 24

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

Slide 26: 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 From UML changes), which stops when the case transits to another state. From PRR (Production Rules Representation) 26

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

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

Slide 29: 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. 29

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

Slide 31: 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. 31

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

Slide 33: 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). 33

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

Slide 35: 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. 35

Slide 36: 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”. 36

Slide 37: Backup slides  Some backup slides follow 37

Slide 38: All that BPMN 1.1 says on states (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: “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.” 38

Slide 39: Diagram: Case management (refinement) table 1 Preparation table 2 local trans. Situation Assessment Establish Plan Service Delivery a1 a6 a8 a11 event x event y a3 a12 a4 a5 a9 a10 a7 event z 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. 39

Slide 40: Diagram: Case management (refinement) table 1 Preparation table 2 local trans. Situation Assessment Establish Plan Service Delivery a1 a6 a8 a11 event x event y a3 a12 a4 a5 a9 a10 event z It would also be possible to implement “before” constraints. Meaning: e.g. activity a12 can only : “Before” constraint 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. 40

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

Slide 42: Case milestones Lease cases in Defense 30 milestones defined http://www.dsca.osd.mil/samm/policy_memos/2003/DS 42

Slide 43: Case states and milestones Cases in Defense 23 milestones 2 levels of states, called “states” and “milestones” here http://www.disam.dsca.mil/pubs/Archives/Journa 43

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

Slide 45: Case milestones  http://www.igt.gov.au/content/work_program/Review_into_Tax_Office_audit_t  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. 45

Slide 46: 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. 46

Slide 47: 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 47

Slide 48: 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. 48

Slide 49: 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. 49

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