DesignFest Home

Case Management

A Framework


[ Home | Problem Collection ]

Prepared by

Gail Harris (Deloitte & Touche Consulting Group/DRT Systems)


Background

Domain

Miscellaneous Requirements

Use Cases

Change Cases


Background

Case Management is a business function common to government health benefit programs, and insurance and financial organisations. The problem you are here to solve today is to develop an object oriented framework for use in developing specific case management systems to support case workers in these industries. These systems must provide access to all necessary information for case workers to process work or respond to customer service needs. They may also provide workflow and business rules processing to support case workers. As the main incoming channel for cases is frequently the telephone, the system must have sub-second response times and be intuitive to use.

Problem Description

Domain

Many organisations use Cases as their basic unit of business. Consider, for example, government benefit programs, insurance companies and lending institutions. A government agency, in administering a benefit program, controls and tracks the issuing of cheques and benefits to particular clients according to legislation, policy, rules and regulations, making decisions on a case by case basis. Insurance companies must manage claims against policies, making decisions for each case. Lending institutions grant or refuse loans for a case based on specific criteria and regulations. The common element in each of these is the Case.

A case is a specific instance of applying procedures to render a decision. It involves a client, a specific set of rules in force at the time when the case started, and follows a lifecycle. Case Management involves managing client tombstone data, supporting the workflow specified by the case lifecycle, managing events and case status, and generating bring-forward actions. These are described in more detail below. In addition, each specific case management application will have analysis, display, and processing requirements unique to the company, which, in the interests of simplicity, are not part of this problem.

Common functions for case management include:

The design problem for DesignFest® is to create an Object Oriented framework for use in developing Case Management applications quickly, and customisable to the particular work practices of the company purchasing the framework.

Four areas, correspondence management, contact tracking, prioritising cases based on rules, and scheduling work and resources, have been excluded from the scope of the framework to simplify the problem.

Client/Tombstone data management

Client data and case tombstone data management refers to the capture and tracking of basic client data such as name, addresses, and phone numbers. It also includes capturing and tracking similar data for clients representatives, and the nature of the relationship.

This process also includes capturing data unique to the case management application under development. The framework must provide facilities for defining data that needs to be captured. There is no requirement for this to be configurable at run time (but it wouldn hurt if that was an option).

Workflow Support

Workflow support refers to the part of the system that allows multiple workers to work on multiple cases in a wide variety of organisational arrangements.

The framework must support workflow functions that are managed either by assigning cases to individual case workers or to a pool of case workers of the same subtype. The use-case descriptions below will specify when this applies. In the former situation, the cases are assigned centrally by a line manager. In the latter situation, the organisation using the framework for developing their case management system has essentially chosen to empower their case workers to partially manage their workload. These case workers will pick a case from the pool to work on next. The manager is depending on their professionalism to ensure that cases do not stay in the pool too long.

At a minimum, the framework should support:

  • A case worker is assigned cases which are managed from start to finish.
  • A case worker is assigned a case by a manager to perform a specific function for that case, and then informs the manager the task is complete. The manager then determines the next appropriate step (close, assign to another case worker for the next processing step, put aside until a bring-forward is activated, etc.).
  • A case worker selects cases from a pool which are managed from start to finish.
  • A case worker selects cases from a pool to perform a specific function, and then moves that case to the next appropriate step (close, put in another pool, put aside until a bring-forward is activated, etc.).
  • Workflow support for case workers and managers requires an in-basket metaphor for selecting one of the cases assigned or selecting a case from a pool. A manager should be able to view, control and organise the work among the case workers.

    Workflow support also includes integration with e-mail and other means of communication in an office environment.

    Finally, workflow support also means providing the ability to Approve or Reject a particular request regarding a case. A case may involve a single or multiple requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.

    Event & Status management

    Event and status management forms the core of the case management framework. The sequence of events trace the processing of the case by the organisation. These are referred to frequently, and may ultimately be used to resolve disputes, respond to queries, and predict trends in the business. The current status of a case situates the case within the lifecycle model described by the organisation procedures, and may be used to determine the next step in processing.

    Event management refers to the creation, editing and reporting of events significant to the business. The framework must provide facilities to configure, at run time, the types of events and the information to capture for each event. An event may trigger a status change, or close a bring-forward.

    Status management refers to maintaining a status field for the case. The status values may control other aspects of the framework, depending on the configuration. For example, the framework must support restricting the next status or the types of events that may occur based on the current status value. Changing to a particular status may cause an event to be created automatically, such as creating a bring-forward entry due at some future date. Changing to a particular status may also automatically close a bring-forward (whether it is due or not).

    Bring-Forwards

    Bring-Forward entries are reminders to a case worker that it is time to perform a certain action. The framework must provide a means to manually and automatically create, review, and close bring-forwards.

    Miscellaneous Requirements<

    The framework must be scalable for several hundred case workers and tens of thousands of cases and clients. Case workers may be centrally located, or geographically dispersed. If case worker are geographically dispersed, then you may assume that the cases are managed by geographic regions.

    Response times for case workers must be less than two seconds on saving and retrieving case information, and sub-second on moving between views of different data for the current case.

    Line Management requires daily and weekly reporting. Senior Management requires the ability to regularly coalesce case data from disperse locations for data warehousing and data mining in support of Decision Support Systems. Usually this will be weekly, monthly and quarterly.

    Security is needed to control which users can do certain actions, such as assigning cases, approving a request, or editing particular fields.

    The system must support multi-lingual deployment using multi-byte character encoding.

    The system must include an audit trail for each case.

    The system must include archiving of old or inactive data.

    Use Cases

    Actors

    Case Worker use cases:

    CW1: Create a new case, and enter tombstone data for it. The case may be for an existing client or for a new client. Also, a case may involve more than one client. This use case uses the use case for adding/editing client contact data. Report an error if mandatory information is missing.

    CW2: Search for a case using key data particular to this application of the framework. The user should be presented with a list of matching entries, with a variety of specific details to help choose the desired case.

    CW3: Add or edit a client contact information. When entering a name the system must search for all matches and allow the case worker to choose one from those found, or create a new entry.

    CW4: Edit or view tombstone data for an existing case. Note that the tombstone data will vary for different applications developed using the framework.

    CW5: Create an event about a case, capturing the type of event, the date, and automatically applying any status changes to the case caused by the event. Report an error if mandatory information is missing.

    CW6: Edit the status of a case, automatically creating any events, or bring-forwards caused by the status change.

    CW7: Enter or edit business specific information about the case. For example, for a house insurance case management system, this might be the location of the dwelling, a description of the building, type of heating, building materials, number of occupants, and other similar fields. For a government disability benefits program, the case data might be the nature of the disability, how long the client can remain standing, degree of mobility and other similar fields describing their functional level.

    CW8: Create and edit a Bring-Forward entry, capturing the type of entry, the date created, the case worker or case worker subtype assigned the BF, the due date, and the BF status. The system should be able to automatically create or edit a BF based on an event or a status change. To close a BF, the user or the system changes the status of the BF to "closed".

    CW9: Perform a particular analysis function, unique to the industry. Depending on the result, the case may remain with the worker, or be forwarded along various paths according to the configuration for this application of the framework.

    CW10: Approve or reject a request for a case. The system should be configurable to support multiple approval/rejection points for the lifecycle of a case. A case may be rejected at one point and this could trigger a variant of a request, or a case lifecycle might consist of a single approval/rejection. This action may cause an event entry or a status change.

    CW11: Search and retrieve the event entries for the currently selected case. If no case is current, then report an error.

    CW12: Search the bring-forward entries using any combination of the following criteria: case, case worker, status, or date range. If any criterion is not specified then retrieve all matches. If no matches are found then report this. This use-case can be used by a case worker to display the on-going case-work for which they are responsible, or by a manager to manage the workload of a group of case workers.

    Manager Use Cases

    A manager can do any of the use-cases for Case Workers.

    M1: Assign a case to a specific case worker or to a pool of case workers of the same subtype.

    M2: View the workload of case workers reporting to them.

    M3: View the inventory of cases, noting status and age of the case. The framework should have a way of ensuring certain events follow other ones within a specified time limit, and highlighting when something is overdue.

    Change Cases

    The system should be configurable as to whether history is maintained or not for client/tombstone data management.

    The framework should not preclude changes by the company as to the lifecycle of a case. Existing cases must continue to use the lifecycle in force when the case began (i.e. apply "grandfathering").

    Similar to the above, the framework should not preclude changes to the workflow. Existing cases may continue using the old one or be transferred into the new workflow. However, cases must not be left in limbo.


    Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.