History of Technology Standards

An Introduction to Functional Standards

Background

The Conference of State Court Administrators and National Association for Court Management have joined with the Consortium for National Case Management Automation Functional Standards and National Center State Courts in a three-year effort to assist state courts in automating their case processing systems. Together, these groups formed the National Consortium for Court Functional Standards (the "Consortium"), which has been tasked with developing guidelines that will help state courts more effectively use their financial and staffing resources to obtain a state-of-the-art computer system - either through in-house development or procurement from a software developer. The Consortium has focused on ways in which the state courts can:

  • Reduce the time needed to obtain a new computer system,
  • Improve work processes, and
  • Reduce staffing requirements.

As part of its study, the Consortium looked at the lack of computer system standards in state courts throughout the country. Unlike a private sector company, which can exercise greater control over its various branches, state court systems are controlled by public funding and the unique needs of the individual courts to create internal systems that work for them. Because of this, state court jurisdictions often must develop entirely new computer applications or have software vendors tailor standard products to meet their requirements. With the rapid rate of change in computer technology, systems can become obsolete even before they are fully implemented, and the procurement cycle must begin again.

Recognizing the state court's need for functional standards in computer systems and the staffing limitations that exist in most state courts, the Consortium has developed a set of functional standards for developing new computer systems. The scope and uses of these functional standards are discussed more fully in the following sections.

Scope

Each volume in this study describes the functional standards for a specific type of case processing system and tracks how these cases move through the court system, along with their accompanying documents and reports. The currently available volumes are:

  • Volume 1 - Civil Case Processing System Functional Standards
  • Volume 2 - Criminal Case Processing System Functional Standards
  • Volume 3 - Domestic Relations Case Processing System Functional Standards

For a more complete explanation of the types of cases encompassed by each case processing system, consult the About This Volume section in the individual volumes. Future volumes will cover other case processing systems, including probate, juvenile delinquency and dependency, traffic cases and those ordinance violations that are processed like traffic cases, mental health, child support and other family, juvenile and adult probation, and jury management. Other case processing systems will not beincluded; however, all appeals other than de novo appeals are included with each case type.

Each of the volumes is devoted to a specific case type to: (1) permit the standards to be evaluated according to case type so that, for example, the civil system or subsystem can be addressed by one work group and the criminal system or subsystem can be addressed by another work group (each work group can be given a copy of the introduction and the appropriate standards volume and work independently on their respective systems); and (2) because of the dynamic nature of computer technology, give the Consortium the ability to update the functional standards in the various volumes independently of each other.

Using Functional Standards

Courts nationwide can use these standards to define functional requirements for in-house systems development and requests for proposals (RFPs) for vendor-supplied computer systems. The standards should be used in the system definition stage to help managers, analysts, and designers identify the functions of new or enhanced systems. While the standards identify what the system should perform, they leave the question of how the system should accomplish those functions to the designer because such questions are design issues. Because these functional standards are intended for national use, some of the standards are expressed in general terms. The reason for this is to give state courts latitude to customize the standards and add details and specificity based on local and state procedures, policies, and customs. Therefore, the functional standards contained in these volumes are sufficiently detailed to render them meaningful, but they are not so detailed that they eliminate design options or are irrelevant to certain courts.

The standards for each case processing system have been broken down into the following functional groups. The functional groups listed below chronologically track how a case moves through the court system:

  • Case initiation and indexing,
  • Docketing and related recordkeeping,
  • Scheduling,
  • Document generation and processing,
  • Calendaring,
  • Hearings,
  • Disposition,
  • Execution,
  • Case close,
  • Accounting (including front counter, cashier, back office and general ledger functions),
  • Security, and
  • Management and statistical reports.

The functions of each of the above groups is further divided into subfunctions, which in turn are broken down into descriptions of the step-by-step tasks that are performed on a daily basis by court personnel during case processing. The subfunctions are described both in textual summaries and in tables that itemize the individual processing steps.

The tables themselves are useful tools that can be adapted by system designers to create maps of their own state court’s individualized functional standards. A table exists for each subfunction of the major functions (such as the Case Initiation Function, the Scheduling Function, etc.). For example, the Scheduling Function has subfunction tables for Schedule Creation, Person and Resource Assignment, Ticklers and Other User Alerts and Prompts, and Schedule and Case Management. As shown in Figure 1 below, the tables structure the day-to-day activities of court personnel sequentially by numbering tasks in the order in which they occur.

The Consortium has written the tables in a broad fashion. Most of the functions listed in these volumes are performed by all state courts, varying only in the details of how the tasks are performed. For this reason, the Consortium has used certain terms that indicate places where each court must customize the standards to accommodate their own methods of operation. Examples of such expressions include "various criteria," "locally defined," and "all transactions." The About This Volume section at the beginning of each volume gives a more extensive list of terminology that must be redefined before developing system documentation and RFPs.

In addition, some redundancy exists between the volumes because of the modular nature of these functional standards. Each volume contains material that is applicable to all case types, as well as material that is unique to the specific case type. Each volume is designed to act as a stand-alone volume for use by individual work groups during the system definition and design phase to create their own customized functional standards.

The functional standards summarize data standards in terms of data groups, as opposed to individual data elements (see the Data Groups section in each volume). The basic data groups contain information about each case and the people involved in those cases. Other data groups contain information about events, financial activities, documents and reports produced by the system, and systems and utility functions. For each data group, enough data elements are given to illustrate its purpose and content. The data elements given in this document are not intended to be a complete list; therefore, detailed data standards and a data dictionary should be developed locally for each court application during the system definition and design phases.

The data groups (e.g., files in the database) relate closely to code translation tables, which have been provided for each case type (see the List of Code Translation Tables section in each volume), because the tables provide the interface between the translations, which are meaningful to users, and the codes, which are stored in the database and used internally within the system.

While the functional capabilities of case processing systems are of paramount importance, each court should be aware of numerous other technological capabilities and understand that many of these capabilities are sophisticated and potentially difficult and costly to implement and maintain. The Related Technical Considerations section in Appendix A contains lists of these technologies that, even though they are not case processing standards, should be reviewed and incorporated into the court’s plans depending on its functional needs, technical expertise, and available funds.

Other Considerations

The primary purpose of these functional standards is to assist with system development and procurement, with particular emphasis on vendor-supplied software. Although not related directly to the functional aspect of the standards, other topics to consider are:

  • With respect to vendor-supplied software, there is the issue of the many computing platforms used in courts nationwide. A cooperative relationship should exist between courts and software vendors with the acknowledgment that vendors cannot build systems for a multitude of platforms and, conversely, courts’ limited budgets permit only infrequent changes in computing platforms. Clearly, open systems architectures should be an objective.
  • Preparations for in-house system development or system procurement should include provisions for user training, system documentation, interfaces with other systems, and on-going system and database maintenance and upgrades.
  • RFPs should have a provision for in-house training or training that encompasses all system users, including those who are external to the court such as attorneys, self-represented litigants, the public, and handicapped persons. Training could be accomplished using manuals; in-house or vendor trainers; train-the-trainer procedures; training tutorials on video, CD-ROM, or on-line (e.g., using the Internet or an intranet); and training help desks.
  • System and user documentation is often overlooked - particularly when systems are developed in-house - but is essential, and documented system and database maintenance and back-up procedures must exist. This documentation must be maintained to reflect the most recent system and database modifications and upgrades.
  • In-house and vendor system developers should allow for interfaces with other systems and databases through such features as application program interfaces, data tagging, and open systems.