This document is no longer current. Please go to the following URL for more information:

http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/default.htm B.4 : CASE MANAGEMENT AND WORKFLOW

This module has been developed with contributions from Cornwell Management Consultants plc and consultation with central and local government representatives. It is not intended to form a part of any future generic functional requirements testing by TNA.

This section lists requirements for an ERMS which handles casework, or case folders. The requirements it contains are relevant only where casework and/or workflow are business needs; in other situations they can be ignored. They include only requirements related to the records management functionality of a case management system; they are unlikely to suffice for the specification of a complete case management application.

Case Management

This section explains the use of the term “case management” and “case folder” in this module. There is no universally-accepted definition of these terms, nor of the distinction between case folders and the other kinds of folders often managed by an ERMS. The following is therefore developed for, and intended to facilitate the understanding of, this module; its applicability in other situations is not guaranteed.

The term “case folder” is here taken to mean the set of records relating to one or more transactions performed in a structured or partly-structured way. The records themselves may be structured (e.g. completed online forms) or unstructured (e.g. e-mail messages or scanned images of paper forms), in any combination; but the key distinguishing characteristic of case folders, compared to the “policy” folders dealt with elsewhere in this specification, is that they result from processes which are at least partly structured.

In the language of the eGovernment Unit’s e-Services Development Framework, case folders are sets of records which pertain to either a specific occurrence of a service interaction, or a series of service interactions that concern a single person, company or other subject entity, where the service interaction(s) is/are the subject of procedural rules.

Examples include case folders containing records pertaining to:

- applications for permits, licences, benefits, passes, funding etc.
- FOI enquiries
- investigation of an incident
- regulatory monitoring
- particular instance papers
- other transactions directly supported by a pre-programmed workflow (i.e. not an ad hoc workflow created for use once).

______________________________________________________________________

1 This and other publications of The National Archives are © Crown Copyright. 2 The term “policy” folders is used in this module only to distinguish a category of records that are not highly structured “case” records – in the sense of instances of a standard process in the meaning of the rest of the module. This definition is not used elsewhere in National Archives guidance and should not necessarily be taken to mean ‘policy’ as in public policy or government policy. 3 Available from the govtalk website, currently at http://www.govtalk.gov.uk/searchresult2.asp?docnum=485&documentname=eSDFprimerV1b&publishdate=06%2F02%2F2002&synopsis=e%2DService+Development+Framework+methodology+for+developing+interoperability+specifications+ 4 The e-Services Development Framework defines Service Interactions in a way which permits unstructured interactions; these would not normally result in case folders for the purposes of this module. See sections B.2.1 and App 1.3 of the Framework. 5 Particular instance papers (“PIPs”) is a term derived from the deliberations of the Grigg Committee of the 1950s and used in archival circles to distinguish records relating to the implementation of public policy (including most government casework). Typically, case folders contain predictable content, albeit with numerous variations. For example, a Benefit Application case folder might always contain a completed application form, then either a request for clarification or an approval record, and so on. They normally rely on business rules (implicit or explicit) which state that specified documents must automatically be considered as records. By contrast, the content of policy folders is unpredictable, and is determined solely by the users who declare the records.

Typically, though not necessarily, other characteristics of case folders are that:

- they are numerous
- they are structured or partly structured
- they are used and managed within a known and predetermined process
- they need to be retained for specific periods, as a result of legislation or regulation
- they can be opened and (in many cases) closed by practitioners, clerical staff or data processing systems without the need for management approval.

Case management frequently involves an application system which is external to the ERMS (a ‘line of business’ system), for example:

- a benefit application processing system
- an FOI enquiry tracking system
- an order processing system.

Many of the additional requirements for case management are related to the need for an ERMS to integrate closely with such systems.

**Workflow**

Case management generally implies following a well-structured process. This in turn often means that it will be beneficial to apply workflow technology. Workflow is defined by the Workflow Management Coalition as *The automation of a business process, in whole or in part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.* In this definition, a “participant” can be a user, a work group (a team), or an application system.

The Workflow requirements as described here relate only to the definition of a standardised business process external to the ERMS. Consequently, processes defined for delivering ERMS functionality will not generally satisfy these requirements.

**Organisation and Use of this Section**

The requirements in the remainder of this section are organised under headings which reflect the headings of the core requirements specification. Where a heading from the body is not shown below, no requirements specific to case management have been identified. Further headings specific to case management and workflow have been added.

The requirements for case management and workflow require careful tailoring. Perhaps more than most of the requirements elsewhere, they can vary according to the nature of the transactions and the supporting systems. For this reason, few of the requirements below are considered mandatory in the general case, though many will be mandatory in any specific environment.

______________________________________________________________________

6 See the Workflow Management Coalition Terminology and Glossary, WFMC-TC-1011 Issue 3.0, available at http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf Record Organisation

Classification Scheme and Fileplan

It is a requirement of BS-ISO 15489(^7) that all records are positioned within the Business Classification Scheme of the organisation. Most case records are to an extent self classifying, in the sense that the ‘subject’ of the case identifies it from other instances of the same business process; for example, in a permit application case management system the folders may be identified by “permit application number”, and all the records within the folders will bear that number.

This means that, if case records only are to be stored in the system many of the requirements listed under A.1 Record Organisation may not be strictly essential for case records beyond specifying a fixed location in the organisational scheme for the case records. The case records as a whole will still require a logical positioning within the business classification scheme of the organisation and this will need to be identified according to the ontology of that scheme and the nature of the casework(^8). Additionally, if there are more than one discrete set of case records, they may logically require positioning at different parts of the classification scheme. In practical terms, these may be mostly theoretical positionings, only made explicit once case records are exported into another environment and prefixed accordingly to comply with other referencing systems in place.

If the system is to store both case records and policy records, or if there is any possibility that this will be a future requirement, then all the requirements of section A.1 may apply.

If only case records are to be stored, then it may be good practice to allow for the requirements in A.1, but they are generally not essential below this level \[on export of any the records from the system, it may be necessary to prefix the classification of the case records to the case identifier[s] according to this logical position.

In particular, under these circumstances case folders generally do not need to be further classified within a hierarchic arrangement of classes containing folders – a “flat” structure of folders is often all that is needed to exert good controls over the records; so the requirements in the following sections may be disregarded:

- Classification scheme and fileplan
- Class metadata.

Additionally, much of the concept of Class becomes unnecessary owing to the absence of the descendent levels, and requirements throughout the specification have to be interpreted accordingly. In particular, inheritance may not apply from this point and should be removed throughout the remainder of the specification(^9).

'Zero' folder

B.4.1 (HD) The ERMS must support the capture of a standard case process, including its graphical representation (as described in the Workflow requirements below), in a case folder (hereafter called the “Zero” folder).

B.4.2 (D) The ERMS may permit the validation of the numbering of the “Zero folder” as having number Zero as its case identifier in the folder metadata and, if so, must prevent its assignment to any other case folder.

______________________________________________________________________

(^7) BS-ISO 15489 Information and documentation: Records management

(^8) this may well require a clear ‘breaking out’ of a prevailing principle of the classification, particularly if it is a functional scheme, to accommodate the case material

(^9) The evidential quality of the inherited metadata being supplied by other controls over the content and its metadata Folders

B.4.3 (M) The ERMS must provide facilities for the opening of case folders including appropriate validation checking (see following requirements).

B.4.4 (HD) When case folders are opened as a result of direct user action within the ERMS, the ERMS should provide an interface to allow the folder identifier entered manually to be validated against an external system.

B.4.5 (HD) The ERMS should allow case folders to be created and opened automatically on receipt of a valid request from an external application.

B.4.6 (M cond.) Where the ERMS is configured to support automated folder opening (B.4.5), it must provide error processing for the event of receipt of an invalid request to create or open a folder (for any reason, such as a request to open an existing folder). The nature of the error processing is not specified here; its essential characteristics are that:

- receipt of an invalid request does not create a new folder
- receipt of an invalid request must not result in a software failure in either the ERMS or the external application
- it must provide a mechanism to alert an appropriate user so that corrective action can be initiated.

B.4.7 (HD) When creating a new electronic folder, the ERMS should allow the folder reference to be supplied by an external application (this requirement is related to A.1.26 & A.1.27).

B.4.8 (HD) The ERMS should allow case folders to be closed automatically on receipt of a request from an external application.

B.4.9 (HD) The ERMS should be capable of configuration so that the ability to create new folders can be controlled according to both user role and the class in which the folder is to be created (this requirement is related to A.1.40, and is needed typically when the ERMS is to hold both policy and case folders – for which different approval may be needed).

Folder Metadata

B.4.10 (M) The ERMS must support the capture of folder metadata consistent with these requirements.

B.4.11 (M) When the ERMS is to store both policy and case folders, it must allow for different metadata for each.

B.4.12 (M) When the ERMS is to store both policy and case folders, it must include a metadata element which differentiates between them10.

B.4.13 (M) When the ERMS is to store both policy and case folders, it must allow for different referencing mechanisms for each (i.e. a structured numerical or alphanumerical reference as described in A.1 for policy folders, and a case identifier, often generated by an application external to the ERMS, for case folders. The requirement is usually that users can, within one classification scheme, refer to policy folders and carry out all operations on them, by using the structured reference; and

______________________________________________________________________

10 A suitable sub-element would be TYPE:FolderType. can refer to and carry out all operations on case folders using only the case identifier or using the structured reference. Note that this is similar to, but more flexible and more general than, requirement A.1.26).

B.4.14 (M) When two naming mechanisms are simultaneously in use (as in B.4.13) the ERMS must allow users all features with both schemes (e.g. users must be able to search for, declare to etc. folders using only the naming mechanism applicable to the folder(s) in question).

B.4.15 (M cond.) When the ERMS allows case folders to be created on the receipt of a request from an external application (B.4.5), it must populate the relevant folder metadata using data provided by the external application.

B.4.16 (D) The ERMS may support a folder metadata element which records the case status, allowing authorised users (including an application system) external to the ERMS to change the status using a controlled list such as a drop-down list (examples of values might be “application received”, “Form B2 sent”, “Awaiting Clearance” etc).

Record Capture, Declaration and Management

Capture

B.4.17 (M) The ERMS must be capable of configuration so that it can capture and declare records from external applications (‘line of business systems’) either with or without direct user action within the ERMS (this requirement is related to A.2.3).

Declaration and Record Metadata

B.4.18 (M) When the ERMS is configured to capture records from external applications without direct user action within the ERMS, it must be capable of configuration to extract and/or derive from the records (or from transactions provided by the external application) sufficient metadata to classify the records automatically, and to meet the metadata standard; and it must then classify the records automatically, associating the metadata with the records.

B.4.19 (HD) When the ERMS is configured to capture records from external applications without manual intervention, it should provide error processing for the event of receipt of a record which cannot be captured and declared properly (for any reason, such as incomplete mandatory metadata, internal inconsistency, specification of a folder which is closed or non-existent). The nature of the error processing is not specified here; its essential characteristics are that:

- an invalid record is not created in the ERMS;
- receipt of a record which cannot be captured and declared should not result in a software failure in either the ERMS or the external application;
- it should provide a mechanism to alert an appropriate user so that corrective action can be initiated.

B.4.20 (M) The ERMS must record the date and time of declaration (to the level of accuracy appropriate for the specific application(^{11})) as a metadata element attached to the record; this data should in addition be recorded in the audit trail (this replaces A.2.44 for case processing applications in which the time of receipt is relevant at this level of accuracy; in all other applications, A.2.44 stands unchanged).

(^{11}) ISO 8601 is a requirement of the Government Data Standards Catalogue [GDSC] available from http://www.govtalk.gov.uk Permissions, Search, Display and Presentation

B.4.21 (D) The ERMS may allow users who have opened an ERMS case folder to switch to the external application and open the corresponding case in the external application, within one keystroke or mouse click.

B.4.22 (HD) The external application should be able to provide an interface with the ERMS which allows users who have opened a case in the external application to open the corresponding case folder in the ERMS, with one keystroke or mouse click.

B.4.23 (D) When the ERMS is able to interact with some external application(s), it may be possible to grant access permissions to the application(s) as if the application(s) were a user (so as to allow good control, e.g. when some records bear privacy markings).

Retention, disposal

This requirements module the scenario where structured case records are passed from a line-of-business case management solution to an ERMS solution [that should itself be compliant with the core requirements specification]; and explicitly not where the records are retained and managed within the line-of-business system which already contains reliable and acceptable retention and disposal logic.

This approach nonetheless may transfer reliance for retention and disposal scheduling away from the ERMS and to the external application system, although the case records are being passed to the ERMS. It can therefore only be used when the external application system’s processing is considered correct and reliable(^\\text{12}). The approach has the benefit that it prevents inconsistencies arising between the two systems.

In these circumstances, it is likely that aspects of section A.4 (Retention and Disposal) may be disregarded insofar as they relate to specific casework requirements of the ERMS itself (along with other requirements which refer explicitly to disposal schedules(^\\text{13})), but the following mandatory requirements should be considered the absolute minimum:

Retention and disposal(^\\text{14})

B.4.24 (M) The ERMS must retain case folders and their contents intact until a valid request for destruction is received.

B.4.25 (M) The ERMS must allow the external application system to mark for deletion one or more case folders scheduled for destruction (but not any other folders).

B.4.26 (M) When the ERMS is configured to support marking folders for destruction (B.4.24), it must provide error processing for the event of receipt of an invalid request to destroy a folder (for any reason, such as a non-existent folder). The nature of the error processing is not specified here; its essential characteristics are that:

- receipt of an invalid destruction request must not result in any destruction;
- receipt of an invalid destruction request must not result in a software failure in either the ERMS or the external application;

(^{12}) “correct and reliable” in this context must mean to the same degree of robustness and auditability as in the disposal requirements of the main core requirements specification

(^{13}) the rationale being that the flatter structure of the records means that they will probably have the same retention rule

(^{14}) Export will, logically, be carried out using the regular functionality of the ERMS and destruction processes for exported records entered following confirmation of successful export in the manner of the core requirements it must provide a mechanism to alert an appropriate user so that corrective action can be initiated.

B.4.27 (M) The ERMS must require the confirmation of the destruction of case folders by an administrator before executing the destruction.

B.4.28 (HD) When any folder is destroyed at the initiation of the external system, the ERMS should retain a metadata stub to record its former existence.

B.4.29 (D) The ERMS may provide tools for the subsequent deletion of metadata stubs recording the former existence of destroyed folders by an administrator.

Audit

B.4.30 (M) When the ERMS is configured to capture records from external applications without direct user action within the ERMS, it must record such capture, and the related classification, in the audit trail automatically.

B.4.31 (M) When any folder is opened, closed or marked for destruction at the initiation of the external system, the ERMS must record such actions in the audit trail automatically.

Reporting

B.4.32 (M) When the ERMS is configured to capture records from external applications without manual intervention, it must provide tools for the reporting of capture statistics (this requirement is related to A.7.7).

B.4.33 (M) When the ERMS is configured to delete folders automatically on instruction from an external application system, it must provide tools for the reporting of deletion statistics.

B.4.34 (HD) When the following three conditions are met:

- the ERMS is integrated to an external application system
- the external system produces reports which can be regarded as records (e.g. some MIS reports)
- the ERMS stores ‘policy’ records as well as case records

then the ERMS should be able to capture these reports automatically in a policy folder defined by a suitably authorised user (note that the metadata to be captured is not defined here in detail; however, it will be necessary to specify the rules for the metadata of such records).

Workflow

The following requirements are based on workflow requirements set out in the MoReq Specification, with additions and changes.

As noted in the introductory section to this module, these generic workflow requirements are especially relevant in defining standard processes for case management environments and

______________________________________________________________________

15 MoReq, Model Requirements for Electronic Records Management Systems, European Commission 2001. Available from http://www.cornwell.co.uk and also available in paper form from the Office for Official Publications of the European Communities as INSAR Supplement VI, ISBN 92-894-1290-9 should be read in conjunction with the preceding case management requirements. Potentially, they can also be useful in other circumstances.

**Workflow rôles**

B.4.35 (M) The ERMS must allow the authorisation of users as workflow process “participants” by an administrator.

B.4.36 (M) The ERMS must support the definition of distinct workflow roles to different users. Examples, of “distinct workflow roles” include:

- a workflow administrator (having permissions to reassign tasks or actions to another user or group but not necessarily wider administrator powers within the ERMS);
- a local administrator or manager (having permissions to designate a workflow for exceptional handling); or
- ordinary workflow users (or “participants”).

B.4.37 (M) The ERMS must recognise as workflow “participants” both individual users and work groups.

B.4.38 (HD) Where the participant is a work group, the ERMS should include a facility to distribute incoming items to group members in rotation, or on a member’s completion of the current task, to balance team members’ workloads.

**Workflow definition**

B.4.39 (M) The ERMS must provide workflows which consist of a number of steps, each step being (for example) movement of a record or folder from one participant to another for action.

B.4.40 (M) The ERMS must not impose any practical limit on the number of steps in each workflow.

B.4.41 (HD) The ERMS should support the setting of a practical limit to the maximum number of steps permitted in a workflow process as a configuration option.

B.4.42 (M) The ERMS must allow pre-programmed workflows to be defined and maintained by an Administrator.

B.4.43 (HD) The workflow definition and maintenance tools should include support for graphical representation and/or editing of the flows.

B.4.44 (M) The ERMS workflow feature must not allow pre-programmed workflows to be changed by users other than an Administrator, or by approved users authorised by an Administrator.

B.4.45 (HD) The ERMS should support the export of a standard workflow process or any of its constituent parts according to any relevant finalised XML schema[s] published on [http://www.govtalk.gov.uk](http://www.govtalk.gov.uk).

______________________________________________________________________

16 *Workflow rôles may be integrated into the rôle management of the main ERMS, but this aspect of the functionality is neither assumed nor covered in this specification* Workflow alerts

B.4.46 (M) The ERMS must provide a function to alert a user participant that a folder or record(s) have been sent to them for attention, specifying the action required.

B.4.47 (HD) The ERMS should integrate with an e-mail client to notify on behalf of a user (or the workflow) to notify other users of records requiring their attention.

Workflow administration

B.4.48 (HD) An authorised user should be able to designate that individual users are able to reassign tasks/actions in a workflow to a different user or group (for example, a user may wish to send a file or record to another user because it requires exception processing, or because the assigned user is unavailable).

B.4.49 (M) The ERMS workflow feature must record all changes to pre-programmed workflows in the audit trail.

B.4.50 (HD) The ERMS should support the capture of a defined workflow process as a record in its own right (case management requirement B.4.1 refers).

B.4.51 (M) The ERMS workflow feature must record the progress of a record or folder through a workflow so that users can determine the status of a record or file in the process by a simple enquiry.

B.4.52 (M) The ERMS must not practically limit the number of workflows which can be defined.

B.4.53 (HD) The ERMS should manage the folders and records in queues (or some similar construct) which can be examined and controlled by an authorised user.

B.4.54 (HD) The ERMS should be capable of letting workflow participants view queues of work addressed to them and select items to be worked on.

B.4.55 (M) The ERMS workflow feature must provide conditional flows which depend on user input or system data (for example, a flow may take a record to either a credit control participant or an order consolidation section, depending on input from a sales supervisor; or the flow may depend on the value of an order, as computed by the system).

B.4.56 (HD) The ERMS workflow feature should provide a reminder, or bring-forward, facility for folders and records.

B.4.57 (D) The ERMS workflow feature should allow users to interrupt a flow (i.e. to suspend it) temporarily in order to be able to attend to other work.

B.4.58 (HD) The ERMS workflow feature should include the ability to prioritise items in queues.

B.4.59 (M) The ERMS workflow feature must include “rendezvous” processing (this requires the workflow to be paused to await a specified event, such as the receipt of a related electronic document, or the completion of another workflow action; when the awaited event occurs, the flow resumes automatically).

B.4.60 (D) The ERMS workflow feature may be able to associate time limits with individual steps and/or process in each flow, and report items which are overdue according to these limits.

B.4.61 (HD) The ERMS workflow feature should allow the trigger events (such as receipt of an electronic document) to initiate workflows and trigger actions automatically.

B.4.62 (M) The ERMS must provide comprehensive reporting facilities to allow management to monitor workflow volumes, performance and exceptions.

B.4.63 (HD) The ERMS should be compatible with the Workflow Management Coalition Reference Model.(^{17})

**Other**

B.4.64 (HD) The ERMS should support automated recognition of electronic and scanned forms (using barcodes, form recognition or any other appropriate technique).(^{18})

B.4.65 (HD) The ERMS should support the automated extraction of case identifiers from form fields.

B.4.66 (HD) The ERMS should support the automated extraction of other metadata (e.g. data, names) from form fields.

B.4.67 (HD) The ERMS should automatically declare forms from which the form identifier and case identifier have been extracted into the correct case folder, without user intervention, using the extracted metadata.

______________________________________________________________________

(^{17}) Workflow Management Coalition Workflow Reference Model, TC00-1003 Issue 1.1, available at http://www.wfmc.org/standards/docs/TC-003v11.pdf

(^{18}) This requirement, for forms recognition, and subsequent requirements (up to B.4.67) for forms processing, are not essential features of case management. However, in practice, forms are frequently used in case management systems, and so this functionality is included here. It may be promoted in importance (to Highly Desirable or Mandatory) if appropriate to a specific application. It will be acceptable for this functionality to be provided by a closely-integrated scanning application rather than by the ERMS itself.