Gail Harris (Deloitte & Touche Consulting Group/DRT Systems)
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.
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.
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).
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:
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 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).
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.
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.
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.
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.