1.1  Introduction
1.2  Project Objectives
1.3  Project Scope
1.4  Project Deliverables
1.5  Recommendations

1.1  Introduction

Vision

The Criminal Justice Information Act (CJIA) Executive Committee has the responsibility to implement the provisions of the Criminal Justice Information Act. This law mandates the development of "a criminal justice information system that supports single entry of data, and multiple use, with focus on accuracy and completeness, ensuring timeliness, access, and appropriate security."

Formation of the Justice Data Architecture Subcommittee

The Executive Committee determined that the best way to implement the sharing of criminal justice data is to create a "data architecture" that identifies the information used by justice agencies and describes its meaning, form, and data values.

The Justice Data Architecture Subcommittee was created as a working committee of the CJIA Executive Committee in May, 1992. Its mission is to produce a set of standards to support the implementation of the Criminal Justice Information Act. This group developed the data architecture in this document.

What is an "Architecture"?

In the field of information management, the term "architecture" has come to mean a framework for identifying information and its relationships to other information technology components. The justice data architecture proposed by this document identifies information shared among state agencies, local law enforcement and courts.

The data architecture provides the following benefits:

• It provides a common language for communication among justice agencies.
• It describes how data is interrelated and provides a foundation for planning and building future information systems.
• Unlike changeable processes and systems, the data architecture is stable; data categorized in a particular way is unlikely to be reclassified.
• It supports the requirement for accuracy and integrity of data by providing a means of determining the impacts of changes made to systems and databases.
• The architecture can be extended to include other aspects of criminal justice not detailed here.

Background

The Subcommittee began its work by investigating judgment and sentence information passed from the Office of the Administrator for the Courts (OAC) to the Washington State Patrol (WSP). This effort focused on system file layouts, on data elements used by OAC and WSP systems and on paper forms. While this approach provided an understanding of the purpose of the systems and their forms, it did not enable the Subcommittee to understand the overall context of the data necessary to recommend valid data-sharing standards.

To define a true "architecture", the Subcommittee broadened its view to include other automated systems and worked with local agencies to better understand criminal justice processes and their data requirements. Local agency representatives and State agency analysts jointly built a high-level view of data usable for long-term planning and for building automated information systems.

The following summarizes the work of the Subcommittee in building the data architecture:

• Review electronic file structures of current state automated systems and identify and categorize unique data elements.
• Identify data elements appearing on forms and reports of justice agencies.
• Use facilitated sessions with representatives of local justice agencies to understand and describe justice processes.
• Synthesize a high-level architecture of justice data.
• Map the data in the architecture to its use in the various processes of the justice system and determine the critical interfaces between them.

The methodology used to identify and record the information in the data architecture was a hybrid of James Martin's "information engineering" and techniques learned by Subcommittee members in developing data and system models for their respective agencies.

The definition of the architecture was facilitated by KnowledgeWare's Application Development Workbench (ADW) software. This software stores information about data, processes, organizations, locations, etc., and the associations that exist between them. It is a tool to manage the complexity of systems by defining components in a gradually more-specific manner.

Summary of what is in the document

The data architecture is composed of two models: a process model and a data model. The models use words and pictures to describe the criminal justice system from the viewpoints of their respective topics. There are detailed descriptions of the deliverables in each model in a later section.

The process model describes the activities and information flow of the justice system. It defines the information content of interfaces between processes and other components of the model.

The data model categorizes justice information and describes the relationships between components of the data model.

The data dictionary part of the data model includes detailed definitions for each data element.

General terms used in this document

Justice Agency: Any organization involved in the justice system, including those which actively participate or those which have repositories of information about people, events, or related data of interest (firearms, vehicles, etc.) to justice.

Model: a representation of one aspect of justice, such as data, process, or organization. A model includes diagrams and definitions.

Interface: a flow of information between justice processes or between a process and another component of the process model. For example, there is an interface between the incident recording process and the identification process; the interface might include name, date of birth, driver's license number, etc.

1.2  Project Objectives

Identify the structure of justice data

Identify data standards for sharing data among justice agencies

Resolve issues pertaining to the matching of criminal arrest data to judgment and sentence data via the "Process Control Number" (PCN).

1.3  Project Scope

The scope of the data standards project includes the analysis of the following:

• Justice processes and interfaces beginning with the recording of an incident through disposition and sentencing in judicial cases
• Criminal history and associated data managed by state agencies
• Data shared among justice processes ("interfaces")

The following items were not within the scope of the current project:

• Management of correctional facilities
• Data internal to local sheriffs' departments or police departments, counties, municipal governments, or other organizations

1.4  Project Deliverables

Process Model

The process model includes the following diagrams and documents:

Justice System Overview

This section shows the context of the justice system processes and their relationships to organizations outside of criminal justice. The diagram shows a high-level view of the justice system and its information flow. Following the diagram, there are definitions of each process and identification of major interfaces.

Interface Descriptions

This section names the data elements that are shared by the justice processes. An interface consists of data in the form of computer transmissions, magnetic tapes, paper, or other media. Regardless of the medium, an interface contains specific data elements, such as SID number, case number, name, address, etc.

Each justice process is linked to other processes by a flow of data. Data created by one process may be used by another. For example, the Sentencing process uses conviction data created in the Disposition process.

Process Data Flow Diagrams

A data flow diagram shows how information moves between processes and organizations, systems, person, etc. This type of diagram is developed to identify interfaces between justice processes. However, it does not show the sequence of events within the process.

There is one data flow diagram for each justice process. Three kinds of data flows appear on each diagram:

• between justice processes
• between processes and automated systems or databases
• between processes and people or organizations outside the processes.

There is a description of how to read a data flow diagram in the appendix.

Data Model

The diagrams and documents of the data model make up the justice data architecture.

Subject Areas Decomposition Diagram

The subject area decomposition diagram shows a high-level breakdown of data of interest to the justice community. Each subject area consists of different types of data unique to that subject. For example, the "Property" subject identifies types of property such as vehicles and firearms. The data contained in each subject area is described in an "entity-relationship diagram."

Entity-Relationship Diagrams

Entity-relationship diagrams show the information of interest to the justice community and describe the associations that exist between different types of information. Each subject area has an entity-relationship diagram.

The pieces of information shown on the diagrams are called "entities." An entity represents a person, place, concept, or event of interest. An entity is described by attributes, or data elements. For example, an entity called "person" might have attributes for name, height and weight; "weapon" might have attributes like caliber, finish, etc. Lines drawn between entities (relationships) show rules that govern the data; an example of a relationship might be "a person must always be associated with at least one incident."

There is a description of how to read an entity-relationship diagram in the appendix.

Data Definitions

This section defines each data element used by justice processes. The details of each data element consist of a number of characteristics, including a formal definition, data type, length, and allowable values.

1.5  Recommendations

• To address the objective of standardizing data sharing among justice agencies, the data architecture provides a common language for agencies which use justice information. It is recommended that the format, length and values for each data element named in the final Data Dictionary Section be accepted as standard. The standard data element format will be the means to share information. This recommendation generally conforms to the goal for data sharing recommended by DIS.
• Translation to and from standard format and values for data elements will be the responsibility of the transmitting and receiving organizations. The organization transmitting data will send data in standard form; if necessary, the receiving organization will translate it to the required form.
• Determine organizational responsibility for maintaining data codes, such as the various crime identifiers. Make this information available to the various justice agencies and provide a means for keeping it up to date. These codes provide a foundation for much of the data shared by justice agencies; unless they are up-to-date and accurate, there is a greater possibility for error.
• Assign the responsibility and provide the means to periodically review and revise the data architecture in this document. If the architecture is to be useful, it must keep up with changing information needs and remain current and complete.
• Provide the means to expand the data architecture to include corrections information. Without data for the administration of sentences and other corrections activities, the architecture is not complete.