U.S. Department of Justice Office of Community Oriented Policing Services Case Studies Information Systems Technology Enhancement Project ISTEP II CASE STUDIES ISTEP Phase II Case Studies Final Report Prepared for Office of Community Oriented Policing Services (COPS) Program/Policy Support and Evaluation Division 1100 Vermont Avenue, NW Washington, D.C. 20530 Prepared by Abt Associates, Inc. 55 Wheeler Street, Cambridge, MA 02138 ISBN: 1-932582-23-1 SUGGESTED CITATION Abt Associates Inc. Police Department Information Systems Technology Enhancement Project (ISTEP): Phase II Case Studies. Washington, D.C.: U.S. Department of Justice, Office of Community Oriented Policing Services, 2003. Acknowledgments This project was supported by cooperative agreement # 97-CK-WXK-005 awarded by the Office of Community Oriented Policing Services, U.S. Department of Justice. Terence Dunworth directed this project at Abt Associates. Points of view or opinions in this document are those of the authors and do not necessarily represent the official position or policies of the U.S. Department of Justice. Abt Associates wishes to thank Veh Bezdikian, Michael Seelman, and Nancy Leach from the COPS Office for overseeing this project. Veh, in particular, provided critical suggestions, feedback, and encouragement. We also thank the Arlington County (VA) Police Department, Phoenix (AZ) Police Department, Reno (NV) Police Department, and the Montgomery County (MD) School District for their support and willingness to participate in the project. We should note that their participation in the project does not necessarily imply that they endorse all of the findings in this report. Tom Rich Abt Associates Inc. Cambridge, Massachusetts Contents Chapter 1:COMPSTAT Information System . . . . . . . . . . . . . . . . . . . . . . . 1 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. System Description and Illustrative Applications . . . . . . . . . . . . . . . .13 3. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 4. Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Chapter 2: School Safety and Information Technology at the Montgomery County (MD)Public Schools . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 2. School Safety and Information Technology: The Current Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 3. Initiatives Under Consideration . . . . . . . . . . . . . . . . . . . . . . . . 73 4. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Chapter 3: Prostitution Problem Solving . . . . . . . . . . . . . . . . . . . . . .91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 2. Problem Solving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Chapter 4: Auto Theft Problem Solving . . . . . . . . . . . . . . . . . . . . . . 119 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 2. Problem Solving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Chapter 1 ISTEP Phase II Case Studies Final Report COMPSTAT Information System January 2003 Prepared for Office of Community Oriented Policing Services (COPS) Program/Policy Support and Evaluation Division 1100 Vermont Avenue, NW, Washington, D.C. 20530 Prepared By John Lavin Tom Rich Abt Associates Inc. 55 Wheeler Street Cambridge, MA 02138 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.ISTEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1.2.COMPSTAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.ISTEP–COMPSTAT Linkage . . . . . . . . . . . . . . . . . . . . . . . . . .9 1.4.Test Site Background . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. System Description and Illustrative Applications . . . . . . . . . . . . .13 2.1.User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 3.1.Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.Police Data Requirements and Preparation . . . . . . . . . . . . . . . . 20 Transferability Considerations . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.Map Data Requirements and Preparation . . . . . . . . . . . . . . . . . .23 Transferability Considerations . . . . . . . . . . . . . . . . . . . . . . . 24 4. Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix–User Guide & Administrator Manual . . . . . . . . . . . . . . . . . 29 1. Introduction This report is one of several produced for the Information Systems Technology Enhancement Project (ISTEP), a project funded by the Office of Community Oriented Policing Services (COPS Office). The overall goal of the ISTEP project is to develop written documentation, software systems, and procedures that will increase the utilization of information and information technology in police departments, particularly regarding the implementation of community- and problem- oriented policing. The report describes a software application designed to support a popular police management technique known as COMPSTAT. The COMPSTAT process evolves around periodic meetings in which senior police officials and area commanders discuss crime trends and what police strategies and tactics are being used to address crime and other quality of life problems in particular localities. Computerized crime maps and other data analyses are used extensively during the meetings as a way to highlight and discuss specific areas and problems. The software application developed and discussed in this report was designed to be used during COMPSTAT meetings to produce maps that help answer questions that arise during such meetings. In the larger context of police department use of information technology, the COMPSTAT system represents one method of making effective use of existing computerized data. All medium- and large-sized police departments routinely collect the type of information that the COMPSTAT system is designed to displayed, such as reported crime information. The vast majority of agencies, however, have very limited ways of retrieving and analyzing that vast store of information. Typically, agencies can either run one of a series of 'canned' reports or utilize the services of a specially-trained analyst who can respond to ad- hoc requests for information by extracting data sets from the main computer system and downloading the data into a PC-based analysis package. The COMPSTAT system discussed in this report is intended to provide non-technical law enforcement personnel–especially command staff who are either attending a COMPSTAT meetings or perhaps simply what to access information from their own desks–with sophisticated query and analysis tools, thus permitting more flexible and spontaneous manipulation of the data. The COMPSTAT system was initially designed for use in the Arlington County (Virginia) Police Department. As of this writing, police staff are still evaluating the system. As such, this report provides an overview of the system and its potential uses in COMPSTAT meetings, rather than an assessment of how the system has impacted the COMPSTAT process in Arlington County. It should be noted that, while the system was developed for testing in Arlington County, the system can be customized for use in other police departments. The system's installation kit is available on CD from the COPS Office or Abt Associates. This report is organized as follows: • The remainder of Section 1 provides background information on the ISTEP Project (Section 1.1) and COMPSTAT (Section 1.2), discusses how COMPSTAT relates to ISTEP principles (Section 1.3), and provides summary information on Arlington County (Section 1.4). . • Section 2 discusses the COMPSTAT system from a non-technical perspective. It shows how police staff can formulate data queries and create their own maps, and provides some examples of the types of maps that could be displayed during the COMPSTAT meetings. • Section 3 provides technical information for persons with responsibility for setting up and administering the COMPSTAT system. Topics include an overall "wiring diagram" of the system, a summary of the data and map preparation processes, and ways in which other jurisdictions can customize the system for use in their law enforcement agencies. • Section 4 discusses ways in which the system could be enhanced to provide additional analytic capabilities, increased access to COMPSTAT data, and streamlined data preparation. 1.1. ISTEP Overview With the goal of increasing the utilization of information and information technology in police departments implementing community policing, the ISTEP project team initially developed a conceptual framework document that describes how community policing imposes different information needs on law enforcement.1 In particular, the framework identifies seven key information domains that should be developed if police departments want to implement community policing effectively. The seven domains are: . community interface . inter-organizational linkages . work-group facilitation . environmental scanning . problem orientation . area accountability . strategic management 1 All ISTEP reports are available through COPS Online at www.cops.usdoj.gov. Subsequent project work proceeded in two phases. The goal of the Phase I was to learn about police department accomplishments in community policing, technology development, and the seven information domains. Phase I was also designed to gain an understanding of the internal and external processes involved in implementing information technology in support of community policing. Five police departments–Tempe, Arizona; San Diego, California; Hartford, Connecticut; Reno, Nevada; and Charlotte-Mecklenberg, North Carolina–were selected to participate in Phase I of the project. These departments were selected because of their successes and experience relating to information technology and community policing implementation. The Phase I departments provided the ISTEP team with open access to their operations and made command and line level staff fully available for interviews, observations, and questions. Several site visits were made to each city to gather information on community policing practices, technology planning, and technology implementation. Members of the ISTEP team attended numerous meetings, participated in technology training, conducted ridealongs, and examined specific hardware and software at each site. Individual case study reports were prepared for each of the participating departments and submitted to the COPS Office. A Phase I cross-site report synthesizes the findings of the individual case studies. It does so by addressing nine specific questions, as a means of helping other departments involved in community policing learn and understand the processes necessary for IT development. The nine questions are: . Is technology driving community policing or is community policing driving technology? . Is there integration of technology with strategic planning? . Is the process of designing and acquiring technology "bottom up" or "top down"? . What is the level of external support for these processes, and what linkages with other information and intervention systems are present? . What is the mix of "in-house" versus "out-of-house" expertise shaping technology planning and acquisition? . Who is responsible for IT integration? . How do these new systems and/or processes actually affect the quality and impact of police work, and how do we know that such changes have occurred? . Is there a process for on-going assessment of IT implementation and use, and how is it sustained? . How is such change financially supported? In Phase II of the project, the ISTEP team worked with three departments –Phoenix, Arizona; Reno, Nevada; and Arlington, Virginia–that have demonstrated a strong commitment to community policing but are in the early stages of IT planning. In Phase II, the ISTEP team worked closely with these departments to develop an information technology design that will support community- and problem-oriented policing. The Phoenix and Reno case studies focus on specific problems–prostitution and auto theft, respectively–while the Arlington case study describes the design and development of a COMPSTAT information tool that can support community policing in a wide range of environments. 1.2. COMPSTAT Overview COMPSTAT (Computerized Statistics) is a relatively new police management technique that relies heavily on the presentation and analysis of reported crime data and other quantitative police performance indicators. The process originated in New York City in the mid-1990s, when the New York Police Department (NYPD) began holding regularly scheduled command staff meetings in which area commanders would discuss crime trends, interventions underway, and plans for reducing crime in their assigned areas. Computerized crime maps (e.g., maps showing the location of reported robberies in the past 30 days) and other crime indicators (e.g., a graph showing the number of robberies by month over the past 3 years) are displayed on large screens so that all attendees can see and comment on the data. The COMPSTAT meetings also provide a forum for creating short- and long-term objectives and for holding area commanders accountable for crime levels, case clearance rates, and other crime and quality of life indicators. When New York City began to experience significant reductions in crime in the mid and late 1990s, many high-level city officials pointed to the COMPSTAT process as a key–or perhaps even the key–factor. The perceived success of COMPSTAT in New York City led many other cities to implement similar programs in their police departments. For example, COMPSTAT-like programs have been implemented in Seattle (where it is referred to as SeattleWatch), Baltimore (Crimestac), Minneapolis (Codefor), Boston (CAM Meetings), and Los Angeles (Fastrac). COMPSTAT has been further popularized by the CBS television show "The District," in which the police chief frequently directs his department's COMPSTAT process, complete with computerized crime maps and other data displays, during the show. Law enforcement agencies using COMPSTAT typically have their crime analysis units prepare maps and other data analyses prior to the meetings and then assemble the data in a slide show format using presentation software such as PowerPoint. The underlying data are not typically available for query and analysis during the meetings. Thus, while standard COMPSTAT procedures enable crime analysts to provide sophisticated and professional-looking maps and graphs for the meeting, new data displays cannot be created "on-the-fly" that allow further data manipulation and address unanticipated questions that arise during the meetings. The system described herein was designed to be used during, rather than prior to the meetings, with the goal of creating a more spontaneous–and, hopefully, more relevant–discussion of crime and quality of life problems during the meetings. Despite COMPSTAT's apparent popularity, the process has its critics. In part, this criticism is directed at those who present COMPSTAT as a panacea for crime. More substantively, some police practitioners and researchers charge that COMPSTAT is "anti-community policing" because it promotes "top down" rather than "bottom up" decision making in a police department, arguing that community police officers should focus on what they (and the community) perceive as the top priority problems in their area, regardless of how department-driven problem solving activities contribute to COMPSTAT crime reduction and police performance goals. A comparison of the New York City and Chicago Police Departments is often used when discussing the pros and cons of COMPSTAT, with the Chicago PD emphasizing a "bottom up" approach to community policing that focuses on empowering the beat officer. Interestingly, both departments have developed map-based information systems, with the NYPD's supporting the COMPSTAT process and the Chicago PD's (i.e., the ICAM system) providing more information support to individual beat officers. COMPSTAT critics thus argue that information technology resources should be directed at community police officers, rather than senior management. The extent to which COMPSTAT actually contributes to crime reduction and improvements in quality of life is unclear. The Police Foundation is currently conducting a national evaluation of COMPSTAT processes, with funding from the National Institute of Justice, that may address some of these performance issues. 1.3. ISTEP – COMPSTAT Linkage Despite claims by critics described above, the COMPSTAT process can directly contribute to community policing by helping to satisfy community policing's information needs. In particular, the basic function of COMPSTAT–discussing crime and other police performance data at police command staff meetings–potentially helps satisfy the ISTEP information domain requirements that were formulated in the project's conceptual framework document. For example: . Community Interface. COMPSTAT can facilitate a two-way exchange of information between the police and the community by incorporating (in addition to crime and other computerized police data) various kinds of community data in the police COMPSTAT meetings (e.g., community satisfaction or quality of life surveys), or by providing the community with access to non-sensitive COMPSTAT information via the police department website. The Chicago Police Department has done this with "Citizen ICAM."2 2 Citizen ICAM is available at http://12.17.79.6/ctznicam/ctznicam.asp . Environmental Scanning. This information domain emphasizes the need to incorporate a wide array of data, including social and community data, into the police decision making process. The COMPSTAT process, in theory, provides a forum for display and discussion of these other data sets, as they could be incorporated into the process in much the same manner than police crime data are. . Interorganizational Linkages. Community policing requires that the police work closely with other governmental agencies, non-profit organizations, and the private sector to address crime and disorder problems. The COMPSTAT process can fulfill this requirement either by including other agency data in the COMPSTAT data analyses (e.g., social service agency data that depict possible contributing factors to crime problems) or by including representatives from these other organizations in the meetings. . Workgroup Facilitation. COMPSTAT meets the workgroup facilitation requirement by enabling key stakeholders within a geographic area–both within and outside the police department - to participate in COMPSTAT meetings. . Problem Orientation. The problem orientation requirement stresses the need to focus on problems rather than incidents. COMPSTAT meetings focus on community problems and examine their nature and extent via crime and other trends. In addition, while COMPSTAT processes generally display incident-level crime data, they could also potentially display other data that show potential contributing factors to community problems. . Area Accountability. COMPSTAT is perhaps best aligned with the area accountability requirement that commanders be responsible for specific geographic areas and, therefore, have access to information that provides them with required information about their assigned geographic area. COMPSTAT crime maps are of course inherently area-specific; other analyses, presented as either tabular data or graphs, can be presented in an area-specific manner as well. . Strategic Management. As noted earlier, COMPSTAT is, at its most basic level, a police management tool for enforcing accountability among area commanders. As such, it becomes an overall strategic management tool for the police chief and other senior police managers. 1.4. Test Site Background The test site for the COMPSTAT Information System is Arlington County (VA), a 26 square mile jurisdiction located across the Potomac River from Washington, DC. The County has approximately 190,000 residents, although its daytime population increases to over 260,000 persons. The Arlington County Police Department (ACPD) has 452 employees, of whom 350 are sworn officers. Organizationally, the ACPD is divided into three divisions–operations, systems management, and criminal investigation. Like many urban areas in the country, Arlington County experienced a significant reduction in serious crime during the 1990s, with the number of reported Part I crimes dropping from nearly 12,000 in 1990 to under 8,000 in 1998. The ACPD began to embrace community policing in the early 1990s with the implementation of a community-based problem-oriented policing (CB-POP) unit. Officers in this unit do not have routine call for service responsibility, and thus were freed to focus on problem solving and community policing. By the mid-1990s, there were five CB-POP teams with a total of 24 officers across the teams, many of whom were funded through the COPS Office Universal Hiring Program. The CB-POP program stresses four elements: . Targeted law enforcement on "hot spots" and repeat offenders; . Community problem solving through establishment and use of collaborative relationships with community and business leaders; . Geographic accountability, rather than time-of-day accountability; and . Systemic prevention, by focusing on root causes of problems and coordinating police services with services from other agencies. More recently, the ACPD Police Chief has initiated a process to integrate community policing throughout the department, rather than have it isolated in specialized units. CB-POP officers still exist, but they work alongside regular patrol officers. In addition, the ACPD has also embraced the school resource officer concept, and currently deploys 16 police officers in Arlington County public schools. In terms of information technology, the ACPD's records management system (RMS) is one component of a county-wide system called the Arlington County Criminal Information System (ACCIS). The system encompasses the county-wide 911 computer aided dispatch (CAD) system, the County Sheriff's jail management system, and the Commonwealth Attorney's case tracking system, in addition to the ACPD's RMS. Querying and producing reports using the department's RMS can be done on two levels. Canned reports and queries are available to any officer in the department; these enable staff to run common reports and query the system by name or location. In addition, department programmers can, in response to requests for ACPD management or officers, create custom reports using a report generation tool. For example, a common request is a listing of calls for service in a particular census tract or beat. A current focus of the department is integrating information technology with community policing by examining the ways in which information is shared and accessed. Specific technologies under consideration include voice mail for all officers, mobile data computers for police cars, cellular telephones in all police cars, personal digital assistants (PDAs) for officers and investigators, electronic reporting, digital dispatch operations, crime mapping, and electronic roll call. In addition, the ACPD decided to implement a COMPSTAT process in which senior management would meet on a regular basis to discuss crime trends in specific areas of the county. Senior ACPD managers not only recognized that they needed to have an information system in place for evaluating crime trends, officer performance, and different police strategies and tactics, but also realized that this system had to be usable during the meetings to address ad-hoc questions. That is, the ACPD wanted to go beyond standard COMPSTAT procedures (see Section 1.2) that involved preparing a set of maps and other data displays prior to the meetings. As a result, the ACPD was very receptive to Abt Associates' invitation to participate in the ISTEP project and test a COMPSTAT information system that could bring the seven ISTEP information domains into the COMPSTAT meetings themselves. Following extensive discussions with ACPD senior management and IT professionals, Abt Associates' project staff developed the particular COMPSTAT system that is discussed in this document. As noted earlier in Section 1, as of this writing the system is currently under evaluation by the ACPD. 2. System Description and Illustrative Applications This section describes, from a non-technical perspective, the COMPSTAT system developed for the ISTEP project and for testing at the Arlington County Police Department. Section 2.1 discusses the system's "user interface"–that is, what the system looks like to the user and how the user interacts with the system. Some examples of the types of maps the system can produce are presented in Section 2.2. In general, the examples highlight how the COMPSTAT application may be used in a variety of situations to: . facilitate access to police data through a set of tools provided on a graphic user interface; . investigate the various elements involved in any incident and the dynamics between those elements; and, . aid the formulation of strategies to prevent/address community problems. 2.1. User Interface The key feature of the system is a map display, shown below, that displays the location of specified police data (e.g., calls for service, field interviews, and arrests) that occurred in specified areas and during specified times. These data are displayed in a spatial context with streets, addresses, beat boundaries and building outlines. The user controls all the data to be displayed, the area that will be visible on the map, and the time period in which the events occurred. The top-left panel of the interface ("Build a Map") includes the controls used to build a map. As shown in the diagram, the map creation process involves three steps: . Selection of the desired police data. The user can select one, two, or three sets (or subsets) of pre-prepared police data files. For example, the user can produce a single-layer map showing arrests or a multilayer map showing arrests, calls for service, and field interviews. Depending on how the data are prepared, subsets of police files–only Part I crimes, only drug arrests, etc.–can also be displayed. . Selection of the date and time range. The user picks the desired date and time range by selecting values from the date and time drop- down lists. . Selection of the area of interest. The user selects the desired geographic area, which is either the entire county or a specific police beat, police district, landmark, or address. If a landmark or address is selected, the user also enters a distance to specify a circular area around the landmark or address. Image of Computer Screen Showing CompStat Query and Display After these three items are selected, the user simply clicks the "Click Here to Update Map" button to produce the map. The system then finds the police data records that match the specified criteria and then displays that data on the section of the map corresponding to the area of interest. Below the 'Build a Map' panel is the legend, which lists the map layers available for display. The name that appears is the layer's file name. The user can select which layers to display by clicking on the check box beside the desired layers. To the right of the legend are buttons providing tools for interaction with the map. These buttons allow the user to zoom in, zoom out, and pan across the map. Additional functions are provided through the four buttons located just below the map widow. These buttons allow the user to query the police data associated with each point displayed on the map, toggle the width of the map window to display more of the map's surface, print the map, and exit the application. Additional information on the user interface can be found in pages 2 through 7 of the COMPSTAT User's Manual, located in the Appendix to this document. 2.2. Examples The following examples illustrate the types of maps that the system can produce for COMPSTAT meetings. (Data are fictitious and presented for illustrative purposes only.) Example 1 The first example addresses a series of reports of indecent exposure near the Henry Elementary School. As shown in the map display below, three types of data are displayed: . Arrests for indecent exposure, drawn with a red square, highlights the scope of the problem; . Sex offender addresses, drawn with a green circle, shows the home addresses of any persons previously arrested for sex offenses; and, . Field interview locations, drawn with a blue triangle, shows proactive responses from the police department. The entire month of October 2000 and a 1 mile radius around the Henry Elementary School are also selected as query parameters. Map of Sex Offenders Near Schools The map shows that three arrests for indecent exposure (red squares) have been made near the school, and that two of those arrests occurred within a small park one block away from the school. The map above also shows the "Incident Data" window that appeared when the "Identify Police Data" button was clicked. This window shows specific information about the selected incident record. The map window also shows that, as a follow-up to these incidents, four field interviews (blue triangles) were conducted in the vicinity of the school. The search also shows the residences of two potential suspects (green circles) within one mile of the school who should be contacted for questioning. Example 2 In this example, the COMPSTAT system is used to investigate the potential relationship between drug arrests, citizen complaints, and the locations of drug houses around the Henry Elementary School. The map below shows drug arrests (red squares), narcotics complaints (green circles), and drug houses (blue triangles) reported during October 2000 within 1 mile of the Henry Elementary School. Map of Drug Dealing Near Schools The map shows incidents and complaints clustered around a drug house (blue triangle) and certain streets and parks. From the information displayed on this map, options could be considered during the COMPSTAT meetings to address the complaints and the criminal activity emanating from the drug house, including possibly focusing more resources on the area around the school. Example 3 In this example, the COMPSTAT system is being used to plan a strategy to reduce the occurrence of auto accidents involving pedestrians in the vicinity of a subway station. Mapped data include the location of vehicle (non-pedestrian) accidents, citation locations, and pedestrian-car accident locations occurring from 8 AM to 4 PM in October 2000 within 1,000 feet of the Virginia Square Metro station. Map of Auto/Pedestrian Accidents Near Metro Station 3. Technical Overview This section provides a brief technical overview of the COMPSTAT system; additional details can be found in the Appendix. This discussion is intended for System Administrators at law enforcement agencies charged with installing the system or preparing data for the COMPSTAT meetings. Section 3 begins with an overall look at the system's architecture. Next, Sections 3.2 and 3.3 discuss the system's police data and map requirements, respectively, including instructions for jurisdictions that wish to customize the application for their particular needs. 3.1. Overall Architecture The COMPSTAT System prepared for the Arlington County Police Department (ACPD) is a Microsoft Visual Basic software application to be used with existing departmental data to provide a simplified interface for data viewing and query during command staff meetings. When the application is started, a set of map layers is loaded that serves as a map background to all other data presented by the application. The user may then, by interacting with controls present on the application interface, select up to three different types, or categories, of police data to display over the base map. For example, the user may choose to display the locations of arrests, calls for service, or field interviews occurring in a certain police district of the County during the past two weeks. The diagram on the following page summarizes the data preparation process for the COMPSTAT system. Data preparation occurs along two lines and is supervised by the analyst within the agency who has been designated the COMPSTAT System Administrator. This person's tasks include preparing the latest police data for use in the application and periodically editing the base map layers with the Department's geographic information system (GIS) software to incorporate any recent changes necessary to keep the base map layers up to date. The application displays two types of information–police data and map layers. As depicted in the diagram, each requires pre-processing in order to be incorporated into the system: . Police data files are extracted from the department's records management system (RMS) according to the desired parameters for types of events (arrests, calls for service etc.) and date range. These records are then geocoded to produce a new map layer with points– one point for each event record containing a valid address field value. . Base map layers are acquired from various departments that have digitized paper maps or have built maps from scratch using a GIS system. Further details on preparing police and map data for COMPSTAT follow in Sections 3.2 and 3.3. COMPSTAT Architecture and Data Flow Diagram Image of COMPSTAT Architecture and Data Flow Diagram It should be noted that the COMPSTAT system requires that all police data and map files be in ESRI shapefile format. The shapefile format is the native format for ArcView, the GIS program used by the ACPD. The Environmental Systems Research Institute (ESRI, www.esri.com) has made the specifications for this data format open and has published a technical description so that data vendors may make their products available in this format (www.esri.com/library/whitepapers/pdfs/ shapefile.pdf). Departmental personnel accomplish the conversion of police data to shapefiles through the use of ArcView software. The User's Manual, located in the Appendix to this document, provides complete instructions for the System Administrator on how new shapefiles of police data may be added to the files displayed by the application (see pp.8–25 of the User's Manual in the Appendix). 3.2. Police Data Requirements and Preparation In anticipation of an upcoming COMPSTAT meeting, Department commanders communicate to the COMPSTAT System Administrator the types of events and time period desired for the data to be displayed at the meeting. The System Administrator then queries the computer aided dispatch (CAD) and/or RMS databases to select and extract the appropriate records. Three types of events will usually be displayed and discussed at the meetings–arrests, calls for service, and field interviews (although the System Administrator can extract and use other data or configure the system to display only one or two tables). Within the Department's RMS, these three types of events are maintained as separate tables. Each arrest, call for service, or field interview event is stored as a unique record in the appropriate table and, at a minimum, each record in these tables must have the following fields: 1. A text field containing a complete valid address that will be used when geocoding the event. 2. A numeric field labeled "NAT" that identifies the nature of the crime. The ACPD uses a four-character UCR code such as "5499". 3. A text field labeled "DATE" with MM/DD/YYYY format (e.g., 10/10/2000). The table(s) of extracted data are then imported into ArcView and geocoded. Geocoding is the process by which the location of each event represented by each record in the extracted data is determined based on the value stored in the field that contains that address of where the event occurred. To be geocoded, each record must have a valid address, and it must be geocoded against a street centerline shapefile that has in its attribute table (for each street segment) the range of addresses on that street and the name of the street. After completing the geocoding, the results are saved as a new shapefile of points. The System Administrator then copies the new point shapefile to a specific directory on the computer where the COMPSTAT application is installed, so that it will be available to users during the next command staff meeting. The User's Manual provides complete instructions for the System Administrator on how new shapefiles of police data may be added to the files displayed by the application (see pp.8-25 of the COMPSTAT User's Manual in the Appendix). Transferability Considerations While the COMPSTAT system was designed for use with data currently available at the ACPD, the application may be used in other jurisdictions by considering the points discussed below. When the System Administrator installs the COMPSTAT system, the installation process creates a new directory within the "c:\program files" directory where the application's executable files and data files are to be stored. At the time of installation, unless the Administrator chooses to install the application to another hard disk on the local machine, the path to the application will be "c:\program files\COMPSTAT." After the application has been installed, and the COMPSTAT directory has been automatically created within the "\program files" directory, the System Administrator must manually copy the Data and the Admin directories from the installation CD into the new "c:\program files\COMPSTAT" directory. This will ensure that the system will have the correct directory structure to store the required data and administration files used by COMPSTAT and that the application will be able to locate and access these files. Whereas the GIS layers that make up the base map are expected to remain stable, the application is designed to facilitate frequent changes in the sets of police data displayed by the application. To make police data available for use by the COMPSTAT system follow these steps: 1. Use ArcView to geocode the new police data, such as arrests, calls for service or fields interviews, and save the results of each geocoding operation as a new shapefile. 2. Use ArcView to add a new text field to the attribute table of each new police data shapefile, give it the label "DATE" and populate the field with the date value for that event, using the format MM/DD/YYYY. 3. Review the file name given to each shapefile. Consider if the layer's contents are clearly communicated through its file name. Remember from Section 2.1, above, that when the program is running, each of the shapefiles available to the COMPSTAT application are listed in the bottom-right of the interface by their file name. Avoid using a file name that only the System Administrator will understand. For example, when the shapefile was created it may have been given a file name like "a401." But for the user, it would be much clearer if the file were renamed as "Arrests_April_01." 4. Open each layer's attribute table and consider if the meaning of the field names and record values will be clear to the users of the COMPSTAT application, because those field names will appear in the Incident Data popup window (see Section 2.2 for an example of field values displayed in the Incident Data window). If not, the values should be replaced with something clearer. 5. Place the new shapefiles in the "c:\program files\COMPSTAT\ Data\Map_Layers" directory. 6. Remove from this same directory the shapefiles of police data that were used previously by the COMPSTAT system, and save them to an archive directory. 7. Update the PolLayrs.dbf table, which is located in the "c:\program files\COMPSTAT\Admin\Tables" directory, with the names of the new shapefiles (see pages 11 and 12 of the User's Manual in Appendix). When the COMPSTAT application starts, it reads this table to find the names of the police data shapefiles to load. 8. Use ArcView to open the PolLayrs.dbf dBase table, and edit the values in the SHPNAME column to replace the names of the previous shapefiles with the names of the new shapefiles of police data that you just placed into the "c:\program files\COMPSTAT\Data\ Map_Layers" directory. Replace each name with the name of the new shapefile that is to replace it. Double-check the spelling of the shapefile name and the use of capital letters in the name to avoid errors in loading the shapefiles when the application starts. It may be necessary to rename the shapefile(s) so as not to have empty spaces in the filenames. 9. With the PolLayrs.dbf table still open in ArcView, change the display color for each new police layer, if desired, in the COLOR column. Refer to the list of MapObjects color variables (see User's Manual p. 13) to set the color in which the entire layer will be drawn when it is checked in the Legend located in the lower-left of the COMPSTAT display screen. This does not affect the colors used to draw the layer selected for display through any of the drop down boxes on the COMPSTAT screen. The color that each layer will be drawn with, when selected with a drop down box, is indicated by the color of the symbol located to the right of that drop down box. 10. Update the PolData.dbf table. Use ArcView to change the names of the police data categories, if desired, and then edit the definition of each category to correspond to the values in the new file. The path to the files is "c:\program files\COMPSTAT\Admin\Tables\ PolData.dbf." When operating COMPSTAT, users interact with the interface to select the parameters to use in querying the police data shapefiles. Each time the application is started, the program reads three tables and uses the values that it finds in each table's records to populate the drop-down lists on the interface. These three tables (PolData.dbf, time.dbf, and distance.dbf) are located in the "c:\program files\COMPSTAT\Admin\Tables" directory: • PolData.dbf table is used to specify the categories of police data that should appear in the three Police Data dropdown lists located on the top-left of the interface. Examples of categories include "All Arrests," "Robbery Arrests," "All Field Interviews," etc. • Time.dbf table is used to specify the time range used in queries, such as "All Day" or "8 AM–4 PM." • Distance.dbf table is used to specify the distance to be used when selecting events within a certain distance from landmarks or addresses. Each of these tables may be edited by the System Administrator using ArcView to customize the query parameters available to the user when the application is running. See pages 14-16, 17&18, and 20-21 in the User's Manual for a complete description of the purpose and content of each table and instructions on managing the query parameters stored within these tables. 3.3. Map Data Requirements and Preparation The ACPD currently uses ESRI ArcView GIS 3.2 and all GIS layers used in this project were available in shapefile format. Therefore, it was recognized during the application design phase that the mapping components employed to provide GIS functionality to the application would be required to use shapefiles as a native format. As noted earlier, ESRI's MapObjects product were selected and the program code was written to load, display, and query data in shapefile format. The application code is written to expect a specific set of named shapefiles to display as the basemap (see User's Manual pp. 9 & 10). The file names used by the ACPD for these layers are specified in the application program code, as these layers form the permanent base map over which the frequently changing police data will be displayed. Therefore, the COMPSTAT system requires the layers specified in the table below in order to open and execute properly. Required COMPSTAT Shapefiles Base Map File Names Layer Type Contents address_points Point Parcel centroids Buildings Polygon Building footprints Landmarks Point Location of landmarks police_beats Polygon Beat boundaries street_names_lines Line Street center lines street_outlines Line Street curbs Parks Polygon Park boundaries county Polygon County boundary The application further requires some specific fields in the attribute tables of various layers–for example a text field with dates in the police data layers that are utilized in date range queries. All data requirements are documented in the User's Manual (pp.11 & 13) in the Appendix. Required Fields in the Required Shapefiles Shapefile Name REQUIRED Field in Attribute Table Address_points ADDRESS Landmarks SM_NAME Police_beats BEAT Street_names_lines STCODE Transferability Considerations While all eight shapefiles–with the names and layer types specified in the first table above–must be present on the computer's hard drive in order for this application to start and run successfully, the application can be used in other jurisdictions where eight shapefiles of local data would be substituted for the shapefiles from Arlington County. To do this, make sure that the eight shapefiles are of the same layer type and are given the same names as indicated in the first table above. Specifically, do the following: . Install the application on a local hard drive, as indicated in the previous section; . Open the new COMPSTAT application directory that was created on the hard drive during the installation process; . Copy the entire Data and the Admin directories from the CD into the new application directory. This will ensure that your system will have the correct directory structure and that the application will be able to find the required files; . Open the "c:\program files\COMPSTAT\Data\Map_Layers" directory and replace the eight shapefiles there with your local data, ensuring that you rename your layers to match the names of the layers that are being replaced. If a jurisdiction does not have one or more of the shapefiles called for in the Contents column in the table above, up to eight shapefiles containing only one token feature could be saved into this directory. In other words, the application need only be able to access eight valid shapefiles with these specific names located in the "c:\program files\COMPSTAT\ Data\Map_Layers" directory. 4. Possible Enhancements While the COMPSTAT application developed for the ISTEP project can be used as is, the development of enhancements would expand access, functionality, and facilitate the implementation of the system within other jurisdictions. Specific possible enhancement include the following: . Browser/Web Based System. Under this enhancement, jurisdictions could take advantage of distributed GIS capabilities available from the new generation of Internet map server technology to create a Browser-based version of the COMPSTAT application. The application could then be made available to any number of users over the jurisdiction's Intranet through a server running an Internet Map Server (IMS) program like ESRI's ArcIMS connected to the network. By connecting the server to the Web, the same data could also be made publicly accessible over the Internet, and–through a TCP/IP connection such as a wireless local area network, cellular phone, or a wireless modem–maps of the data could be made available to officers in the field. ESRI's ArcIMS Internet map server technology is fully compatible with the current GIS program and data format used in the Arlington County Police Department, and in most other jurisdictions. Internet map server software is by design created to serve GIS-based applications on an Intranet or the Internet. ArcIMS provides an environment for the creation of custom applications and the development of Web pages to present those applications to clients, as well as tools to control the operation of the application on the server computer. The cost to purchase licenses for ArcIMS is solely based on the number of server computers which have ArcIMS installed on them, and not the number of users. Therefore, with one license (one server), a department can legally accommodate many users, and can add new users by simply having them open the browser program on their computer and use it to connect to the COMPSTAT application on the server computer. . Automate the Data Preparation Process. This enhancement involves creating standardized queries within a police department's RMS so that each time that new data is extracted for use by the application at the next command staff meeting, it meets a consistent set of parameters. If the RMS is ODBC (Open Database Connectivity, a standard application programming interface for accessing a database) compliant, the Department's ArcView software would be able to use the ODBC database protocol standards to directly access the RMS, run the desired query from within the RMS, and begin the geocoding process on the records returned by the query to ArcView. . Direct layer selection. Functions could be added to the graphic interface to allow users to browse and select any number of base map layers and police data layers to be displayed. In addition, developers could add the ability to save that configuration to a file that can then be opened at some future time, thus enabling the application to display the same set of previously selected layers. Through this capability users could compose their own preferred set of local shapefiles to serve as the base map, and then save that configuration to their hard disk. Then, at any future time the configuration file could be opened and the latest police data could be selected and added to the map window for display over the previously selected set of base layers. . Add additional analysis capabilities. Users could be provided with a tool to query the attribute tables of the police data, so as to highlight on the map all geocoded points matching the user's query parameters. For example, selection criteria could include a certain range of incident numbers. This capability, and that of feature selection through buffers generated by the user, are available with ArcIMS. In addition, graphing capabilities, tabular reporting, and statistical algorithms could be incorporated in the system. Appendix COMPSTAT Information System User’s Guide and Administrator’s Manual Image of COMPSTAT Information System Manual Table of Contents 1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 2 COMPSTAT System Users Manual . . . . . . . . . . . . . . . . . . . . 32 2.1 Starting the System . . . . . . . . . . . . . . . . . . . . . . . .32 2.2 Building a Map . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 What Appears on the Screen When a Map is Produced . . . . . . . . .33 2.4 Display Other Data. . . . . . . . . . . . . . . . . . . . . . . . .34 2.5 Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.5.1 Map Manipulation. . . . . . . . . . . . . . . . . . . . . . . . .35 2.5.2 Interaction with the Map Display and Form. . . . . . . . . . . . 36 3 System Administration. . . . . . . . . . . . . . . . . . . . . . . . 37 3.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . .37 3.1.1 Overview of the operation of the COMPSTAT system. . . . . . . . .37 3.2 Base Map Layers . . . . . . . . . . . . . . . . . . . . . . . . . .38 3.3 Police Data Map Layers. . . . . . . . . . . . . . . . . . . . . . .39 3.3.1 How Police Data Layer are Loaded by the COMPSTAT System. . . . . 39 3.1.2 Replacing Police Data Layers . . . . . . . . . . . . . . . . . . 40 3.1.3 Updating the PolLayrs.dbf Table. . . . . . . . . . . . . . . . . 41 3.4 Managing the Query Parameters. . . . . . . . . . . . . . . . . . . 42 3.4.1 Police data query parameters. . . . . . . . . . . . . . . . . . .42 3.4.2 Date Range . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4.3 Time Range. . . . . . . . . . . . . . . . . . . . . . . . . . . .44 3.4.4 Landmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.5 Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5 Administration Resources: Reference Tables and Files . . . . . . . 48 3.6 Preparation of the COMPSTAT System for Meetings . . . . . . . . . .49 3.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.6.1.1 Prepare and load new shapefiles. . . . . . . . . . . . . . . . 49 3.6.1.2 Update PolLayrs.dbf . . . . . . . . . . . . . . . . . . . . . .50 3.6.1.3 Test system . . . . . . . . . . . . . . . . . . . . . . . . . .50 Overview The key feature of the system is a map display showing the location of calls for service, field interviews and arrests that occurred in specified areas of Arlington county and at specified times. This data is displayed in context with current streets, addresses, beat boundaries and building outlines. The user controls all the data to be displayed, the area of Arlington County that appears on the map and the time period in which the events occurred. This system was created using Microsoft Visual Basic and ESRI MapObjects. Section 2 contains a brief guide to using the system. Section 3 contains instructions for modifying the system and the steps necessary for the Administrator of the system to periodically take in order to prepare the system for meetings in which it will be used. The system Administrator will need to be sufficiently competent with ESRI ArcView to be able geocode address files, create and edit shapefiles and edit the contents of the system menus and drop-down lists stored in ESRI ArcView tables. 2 COMPSTAT System Users Manual 2.1 Starting the System To start the COMPSTAT system, click on the Windows Start button and then select the COMPSTAT menu item. Alternatively, click on the Start button, select the Programs menu item, followed by the COMPSTAT menu item, followed by the COMPSTAT Mapping System menu Item. COMPSTAT Interface 2.2 Building a Map Image of COMPSTAT screen The upper left side of the COMPSTAT screen highlights the four-step process that is used to build a map: 1. Pick police data. Click on any of the three police data drop down lists to select the desired police data. Zero, one, two, or three different police data sets, or layers, can be included in the display. The icon that will be used for the particular layer is shown alongside the drop down list. If is displayed in any of the dropdown lists, then no data has been selected for the particular layer. To remove a layer, click the drop down list and select the choice. 2. Pick data and time range. Use the date and time range drop down lists to specify the desired date and time range you want for the map display. • In the two date range drop down lists you can either (i) select one of the choices in the drop down list, or (ii) enter any date you want by clicking in the very top part of the drop down list. If you do enter a date, use this format: MM/DD/YYYY. When the system is started the "From" date range and the "To" date range both display, by default, the current date. For convenient operation, the drop down lists for both also offer dates for you to select that are 7, 14, 21, 30 and 60 days prior to the current date. With the "From" date range drop down, select or enter the date for the earliest incidents that you wish to appear on the map. With the "To" date range drop down, select or enter the date for the most recent incidents. 3. Pick Area. For this step, choose the area you want for the map display. Select either a police beat, landmark, or address. . If the Beat option button is selected, pick one police beat ID number from the Beat drop down list. . If the landmark option button is selected, pick a search distance from the Distance drop down and a landmark name from the Landmark drop down list. . If the Address option button is selected, pick a search distance from the Distance drop down and enter an address into the Address text box. The components of the address, such as the street number, name, prefix or suffix, must be entered in the order of, and in accordance with, the address matching system currently used by the Arlington County Police GIS department, as they have created and will be responsible for maintaining the address point file used by this system. This is an example of the current address format: 1106 N UTAH ST. 4. Click here to Produce Map. You must click on this button to produce the map and to update the map if you change any of your selections. 2.3 What Appears on the Screen When a Map is Produced When the "Click Here to Produce Map" button is clicked, the following appears on the screen. . Map Display. The area within Arlington County that is visible on the map will be re-positioned so that it is limited to only the area specified in the "Pick Area" selection (Step 3 above) and any police data records meeting all the specified criteria are shown in the map display. The icons used to represent the police data layers are shown next to the police data drop down in the upper left-hand corner of the screen. For example, a red square is used for all the data points in the first police data layer. . Records Counts. The number underneath the "N" column, (next to the police data layer drop downs) show the number of records meeting all the user specified criteria for each police layer, and thus have been drawn on the map display with that layer's symbol. ! Note: Icons representing police data events which all occurred at the same address will be stacked directly on top of one another and, thus, all but the top one will be hidden from view. System Map Display. The Buildings layer has been clicked by the user for display. Image of map 2.4 Display Other Data Within the legend located in the lower left-hand corner of the COMPSTAT screen, are listed all of the layers of data that are available for use with the system. Most of these layers (such as Police Beats, Parks, Streets, and the County outline) serve as the base map, or background on which the police data is displayed. As can be seen in the illustration, above, one layer, "Buildings" is included as an optional visual reference that may be clicked on or off in the legend. The legend also contains the three police data layers that the system administrator has currently prepared for use by the system. Clicking in the check box for any layer in the legend will turn on all of the features in that data layer. This is a quick way, for example to view all events in the particular police data layer. ! Note: Before clicking on the button labeled "Click Here to Build Map", be sure that all three police data layers in the legend are turned off. This will avoid confusion between the datasets. 2.5 Other Commands 2.5.1 Map Manipulation These tools are located between the Legend and the Map display. Image of Zoom In Button Zoom In Click once on this button. The mouse pointer changes to a magnifying glass with a plus sign inside. Click on the map in the center of the area that you want to zoom to. In response, the map centers on the point where the map was clicked and zooms in. If necessary, click again on the map to zoom in again on that spot. Image of Zoom Out Button Zoom Out Click once on this button. The mouse pointer changes to a magnifying glass with a negative sign inside. Click on the map in the center of the area that you want to zoom out from. In response, the map centers on the point where the map was clicked and zooms out. If necessary, click again on the map to zoom out again on that spot. Image of Pan Button Pan When you click on this button, the mouse pointer changes to an open hand. This tool lets you move the map by dragging the display in any direction with the mouse. To pan, move the cursor anywhere over the map, hold down the mouse button, and drag in any direction. Release the mouse button to leave the display in your desired position. The program will update the display to fill in any blank areas in the map caused by the pan. Image of Zooms To Full Extent Button Zooms to Full Extent Click once on this button and the map zooms out to the full extent of Arlington County. 2.5.2 Interaction with the Map Display and Form Located below the map display are the following buttons: Image of Buttons Located Below the Map Display Identify Base Layers This tool allows you to view the attribute data for features in the map layers that appear in the legend. These layers form the base over which you display police data. Click this button and then click anywhere on the map display and all features within 3 pixels of the location where you clicked on the map will be selected from all map layers currently visible in the display. The feature nearest the point where you clicked will flash four times to confirm that it has been selected, then a new form will open listing all the attributes for one of the selected features. To view the attributes of features on another layer, click on the listbox labeled "Current Feature." It will open a dropdown that lists the feature selected from each layer. Click on one of the items in this list and the selected feature from that layer will flash and its attributes will then be listed on the form. On the map display, if you click on another location on the map, a new set of features will be selected from the visible layers and the attributes listed in the form will change to display those of the newly selected feature. Identify Police Data This tool allows you view the attribute data for any point in the Police Data layers drawn on the map display. Click this button and then click on any Police Data point symbol currently drawn on the map display. The point that was selected will flash four times to allow you to confirm if it is the desired point, then a new form will open listing all the attributes for the event represented by that point. With this new form, you may print the attributes of the selected point. Click on a new point on the map display and the attributes listed in the form will change to display those of the newly selected point. Enlarge Map Window Click on this button to widen the map display window to the full width of the Query & Display form. Print Access a printer dialog form through this button. With the dialog you may select a printer, page orientation and number of copies to be printed. Note: Some less advanced printers are not able to process the information that makes up Legend display. On these printers the Legend area appears on the print out as parallel black lines (similar to a bar code). On these printers, only the Legend area is effected. Exit Close and exit the COMPSTAT application. 3 System Administration 3.1 Introduction The COMPSTAT system was designed so that a person with a working knowledge of ESRI ArcView could update and modify the data displayed and the query parameters available to the user. The instructions that follow assume the reader has a working knowledge of ESRI ArcView. . ESRI Environmental Systems Research Institute www.esri.com . ArcView GIS www.esri.com/software/arcview/index.html ! Be sure to thoroughly test any changes that you make before using the system during a COMPSTAT meeting. 3.1.1 Overview of the operation of the COMPSTAT system When a user starts the COMPSTAT system, the first action executed by the program is to load the map window with layers of shapefiles. The shapefiles are loaded as two groups, through two different methods. The first group of shapefile layers to be loaded composes the base map, or background, on which the second group of layers will be displayed. This second group of shapefile layers is composed of discrete sets of police data such as Arrests, Calls for Service and Field Interviews. The base map layers are loaded first into the map, and then the application begins the process of loading the police data layers. The names of the police data layers are not hard coded in the application program because these layers will be periodically replaced by the Administrator to maintain the COMPSTAT application with current police data. Since the names of the police data layers are not hard coded, the application must first identify which shapefiles to load as the current police data layers. To identify the current data, the application looks for the dBase format table named "PolData.dbf," located in the "…\Admin\Tables" directory, and reads the "SHPNAME" field in that table to obtain the names of the police data shapefiles to be loaded. The application then loads these last three shapefiles. The execution of the application continues, and next the values are read from other tables to populate the boxes and dropdowns that the user will employ to specify the parameters for queries. Base map Layers Image of Map With Bottom Left Corner Highlighted 3.2 Base Map layers The number of layers that form the base map and their file names are specified by name in the application programming code. These layers are shapefiles located in the directory labeled "Map Layers," under the path: "...Data\Map_Layers" There are eight shapefiles that form layers of the base map: layersources.dbf lists the Required Shapefiles Name Now Original Name Source address_points Addpnt Arlington Police Dept buildings Blrgnb Arlington Police Dept landmarks Strmap (nodes) Arlington Police Dept police_beats Pbeats Arlington Police Dept street_names_lines Strnet Arlington Police Dept street_outlines Smarc Arlington Police Dept parks Parks Arlington Police Dept county Cntyusgs Arlington Police Dept The application depends on these eight shapefiles being in the Tables directory, therefore they must not be deleted or renamed, yet, these shapefiles can and should be replaced when they become out of date. As new features are built in Arlington County, (such as buildings and streets), or modified, (such as beat boundaries), or new address points are created, they need to be included in this database in order to keep the data used by the application current. To do this, first save a backup copy of the current shapefile, and then copy the new shapefile into the "...Data\Map_Layers" directory. Be sure to rename (if necessary) the new file so that its name matches exactly the name of the shapefile it is to replace. Be sure that the name of the updated shapefile matches the one it is to replace. The application uses the following fields in the above shapefiles to perform searches for queries. Therefore these fields must be present in the attribute tables of the indicated shapefiles, and must contain relevant data. Required Fields in the Required Shapefiles Shapefile Name REQUIRED Field in Attribute Table address_points ADDRESS landmarks SM_NAME police_beats BEAT street_names_lines STCODE 3.3 Police data map layers 3.3.1 How Police Data Layer are Loaded by the COMPSTAT System The police data layers are not hard coded into the application program, as their file names will periodically change when the system administrator replaces these files with new files containing more recent police data. Therefore these shapefiles are loaded using a different method. To identify the police data shapefiles to load, the application refers to a table to obtain the names of the current shapefiles to load. The application cycles through the "PolLayrs.dbf" table located in "…\Admin\Tables" directory, reading the "SHPNAME" field for the current record, and then searches the "...Data\Map_Layers" directory for a shapefile with the same name. When that shapefile is found it is loaded into the map Legend and is available for use in the COMPSTAT system. The reading of the PolLayers.dbf table then continues and the next record is read to identify the next police data shapefile to load. The police data layers are added to the map and the legend, one by one, as they are read from the table and located in the Map_layers directory. The color that each police data shapefile is displayed with in the legend is determined by the color code stored in the "COLOR" field in the "PolLayrs.dbf" table. PolLayrs.dbf dBase Table SHPNAME COLOR NOTES test_fi MoBlue Use only MapObjects Color Codes test_cfs MoGreen Use only MapObjects Color Codes aprmay14 MoRed Use only MapObjects Color Codes The order in which the police data layers are displayed in the Legend is controlled by the order of the records in the table. The shapefile identified in the first (top) record will be loaded first, then the next one down (second record) will be loaded in the Legend above the shapefile that was read first, then the next record down (third record) will be read from the table and this last police data layer will be added to the Legend on top of all other layers in the legend. 3.1.2 Replacing Police Data Layers To replace the current Police data layers with more recent police data, create new point shapefile(s) of geocoded events (such as arrests, or calls for service or field interviews) and place the file(s) in the "…\Data\Map_Layers" directory. Then use ArcView to update the PolLayers.dbf dBase table with the name(s) of the new shapefiles(s). ! Note: Each and every Police Data shapefile must have a text field labeled "DATE" present in its attribute table with date values in the standard Y2K required format of "MM/DD/YYYY." (See " AV Date Formula .doc" located in the "..\Admin" directory for step by step instruction on how to do this with ArcView.) To make police data available for use by the COMPSTAT system: 1 Use ArcView to geocode the desired police data, such as arrests, calls for service or field interviews, and save the results of each geocoding operation as a new shapefile. 2 Review the attribute table of each shapefile. Consider if the meaning of the field names or record values will be clear to the users of the COMPSTAT system during meetings, or if any of the values should be replaces with something clearer. 3 Use ArcView to add a new text field to the attribute table of each new police data shapefile, give it the label "DATE" and populate the field with the date value for that event. Refer to the Word document titled "AV Date Formula.doc" located in the "… \Admin" directory for instructions on how to extract the date value from the "INC" field. DATE field values must be in "MM/DD/YYYY" format. 4 Place the new shapefiles in the "…\Data\Map_Layers" directory. 5 Remove from this same directory the shapefiles of police data that were used previously by the COMPSTAT system, and save them to an archive directory. 6 Update the PolLayrs.dbf table with the names of the new shapfiles. 3.1.3 Updating the PolLayrs.dbf Table General steps to update a COMPSTAT system table using ArcView: 1 Open an ArcView project, 2 Make the Project window active. 3 From the Project menu, choose Add Table 4 From the File Type list, choose dBase (.dbf) 5 Navigate to the directory that contains the file you want to add. 6 Double-click the file you want to add or choose the file and press OK ArcView adds the table to your project. 7 Make the necessary modifications to cell values. 8 Save the table modifications. A sample ArcView project that has had all the COMPSTAT tables added to it is labeled, Administrate_tables.apr, and is located in the "…\Admin" Directory. Use ArcView to open the PolLayrs.dbf dBase table, and edit the values in the SHPNAME column to replace the names of the previous shapefiles with the names of the new shapefiles of police data that you just placed into the "…\Data\Map_Layers" directory. Replace each name with the name of the new shapefile that is to replace it. Double check your spelling of the shapefile name and the use of capital letters in the name to avoid errors in loading the shapefiles when the application starts. It may be necessary to rename your shapefile(s) so as not to have empty spaces in the filenames. Change the display color for each new police layer, if desired, in the COLOR column. Refer to the list of MapObjects color variables, below -- and remember that the color that is set in this table only determines what color the entire layer will be drawn in when it is checked in the Legend located in the lower-left of the COMPSTAT display screen. This does not affect the colors used to draw the layer selected for display through any of the drop down boxes on the COMPSTAT screen. The color that each layer will be drawn with, when selected with a drop down box, is indicated by the color of the symbol located to the right of that drop down box. Colors to Use in Color field of the PolLayers.dbf table FIELD_VALUE MAP_COLOR MoBlack Black MoLtYellow Light Yellow MoRed Red MoYellow Yellow MoGreen Green MoLimeGreen Lime Green MoBlue Blue MoTeal Teal MoMagenta Magenta MoDarkGreen Dark Green MoCyan Cyan MoMaroon Maroon MoWhite White MoPurple Purple MoLightGray LightGray MoOrange Orange MoDarkGray DarkGray MoKhaki Khaki MoGray Gray MoOlive Olive MoPaleYellow Pale Yellow MoBrown Brown MoNavy Navy 41 ! Tables in dBase format that have been modified by programs OTHER than ArcView (such as Microsoft Excel) are, as a result, frequently incompatible with ArcView itself and MapObjects. This application employs ESRI MapObjects components and therefore it is necessary when editing any table used by this system to use ArcView to perform all editing! Use of another program has been found to result in incompatible dBase files–resulting in the crash of the system. 3.4 Managing the Query Parameters As the application is starting, immediately after the map window loads with shapefiles, the program reads various tables and populates selection boxes on the interface with which the user will interact to make selections to specify the parameters to use in querying the police data shapefiles. These tables are located in the "..Admin\Tables directory." . PolLayers.dbf . PolData.dbf . time.dbf . distance.dbf 3.4.1 Police data query parameters The queries that the user can make against the layers of police data are completely customizable. When the application is running, categories of data to be selected can be chosen from the "Pick Police Data" comboboxes on the form. The COMPSTAT Administer can customize–and has complete control over–the categories of police data that are available for selection. The Administrator will establish the categories listed in the Police Data comboboxes, and create and modify the Structured Query Language (SQL) code necessary to perform the query of the attribute files associated with each police data shape file. The table that allows the Administrator to do this is the "PolData.dbf" file located in the "…\Admin\Tables" directory. Image of COMPSTAT Administrator As the application is starting, after the base map and police shapefile layers have all been loaded, the application reads the query categories from the "LIST_TEXT" field of the "PolData.dbf" table and populates the drop down list for each police data combobox. The user may then click on any combobox and select the desired category of data to be displayed in the map window, on top of the base map layers. The application then refers to the SQL code in the "WHERE" field of the table, and the layer name in the "SHPNAME" field to identify the name of the shapefile with the corresponding data to be queried. Then the query is executed on the shapefile whose name matches that obtained from the table, to select those records that satisfy the Where statement also stored in the "PolData.dbf" table. Example of the contents of the PolData.dbf Table Table Displaying List Text, Where, and Shpname With the "PolData.dbf" table the COMPSTAT Administrator will: . Control the number of categories in the list that appears from the Pick Police Data comboboxes (Add or delete records in the table with ArcView). . Store the labels for each category that will appear in the dropdown list on the form. . Store the SQL Where phrase. . Store the name of shapefile that contains the data to be queried. These are the steps to add a new category: 1. Open ArcView. Add the "PolData.dbf" table to the current project. 2. Open the table by clicking on its name in the Project window. 3. With the PolData table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 4. Click on Edit from the main menu, and select Add new record. 5. Type a descriptive phrase for the new query category in the LIST_TEXT field. 6. Type in the SQL code necessary to select the desired subset of records into the WHERE field. Note: Do not use quotation marks around the UCR codes, as these are stored in the Police Data shapefiles as Numbers, not text. Note: For a query to not filter out any records, you must leave the WHERE field empty. 7. Type the name of the shapefile that contains the data to be queried, in the SHPNAME field. 8. Save the table. To modify the WHERE clause of a query, refer to steps 3 - 6 & 8 above. To delete a category: 1. With the PolData table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 2. Click on the row (record) in the table that you want to delete. It should automatically be highlighted in yellow to confirm that it has been selected. 3. Click on Edit from the main menu, and select Delete record. ! Tables in dBase format that have been modified by programs OTHER than ArcView (such as Microsoft Excel) are, as a result, frequently incompatible with ArcView itself and MapObjects. This application employs ESRI MapObjects components and therefore it is necessary when editing any table used by this system to use ArcView to perform all editing! Use of another program has been found to result in incompatible dBase files–resulting in the crash of the system. 3.4.2 Date Range The Date Range parameters for the query are read by the application from the Date Range comboboxes. Both the Start Date and the End Date boxes are by default filled with the current date as obtained from the PC's operating system. The user may change these dates by typing any desired date into the Start and/or End Date boxes. By clicking on the arrow to open the drop down list, the user may select a date from the list. The dates that appear in the list are always 7, 14, 21,30 and 60 days prior to the current date. These dates are hard coded in to the program and are not open to modification by the Administrator. Each and every Police Data shapefile must have a text field labeled "DATE" present in its attribute table, and date values in that field must be in standard Y2K required format of "MM/DD/YYYY." Image of Date Range Boxes 3.4.3 Time Range The COMPSTAT application populates the "Pick Time Range" listbox with time range values that are used in the query to select those police data records that occurred within a specific time period. Image of Time Range Boxes Table Displaying List Text and Where The COMPSTAT Administer can customize–and has complete control over–the time ranges that are available for selection to the user. The Administrator may use ESRI ArcView add or delete records in the time.dbf table and modify the Structured Query Language (SQL) code used in the query of the attribute files associated with each police data shape file. The time.dbf file located in the "…\Admin\Tables" directory. In the time.dbf table, Single quotes around all 'hour values' are necessary. With the "time.dbf" table the COMPSTAT Administrator will: . Control the number of categories in the list that appears from the Time Range listbox. . Store the labels for each Time Range that will appear in the dropdown list on the form. . Store the SQL Where phrase. These are the steps to add a new category: 1 Open ArcView. Add the time.dbf table to the current project. 2 Open the table by clicking on its name in the Project window. 3 With the table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 4 Click on Edit from the main menu, and select Add new record. 5 Type a clear descriptive phrase for the query category is stored in the LIST_TEXT field. 6 Type in the SQL code necessary to select the desired subset of records into the WHERE field. Note: In the Time.dbf table, Single quotes around all 'hour values' are necessary. Note: For a query not to filter out any records, you must leave the WHERE field empty. 7 Save the table. Refer to steps 3 - 7 when modifying a query. To delete a category: 1. With the time.dbf table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 2. Click on the row (record) in the table that you want to delete. It should automatically be highlighted in yellow to confirm that it has been selected. Click on Edit from the main menu, and select Delete record. ! Remember: It is necessary when editing any table used by this system to use ArcView to perform all editing! 3.4.4 Landmark The Landmark list box is populated from the "SM_NAME" field in the attribute table of the "Landmarks" shapefile. Any changes to this shapefile by the Administrator to add or remove records or edit the name of the landmark in the "SM_NAME" field will be immediately displayed the next time the application is started. Example values in landmarks.dbf, the attribute table of the Landmarks shapefile Table Displaying STRMAP_ID and SM_NAME Image of Landmark List Box To edit the Landmark shapefile itself, use ArcView or ArcInfo to . Add points . Delete points . Move points . Edit attribute table values 3.4.5 Distance The "Distance" listbox is populated with distance values that are used in the query to select those police data records that occurred within a specific radius distance of the user selected landmark or address point. The COMPSTAT application reads the Distance label from the "LIST_TEXT" field of the "distance.dbf" table and populates the drop down list of the Distance combobox. The user may then click on the combobox and select the desired distance within which police data is to be selected and displayed in the map window. The application then refers to the number in the "DIST_FEET" field of the table to obtain the number of feet to use as the radius in a spatial search that will select all police data events whose location falls within the circle. Then the query is executed on the police data shapefiles to select all events, as selected by the user, which occurred within the selected radius from the specified landmark or address. distance.dbf Image of Distance List Box LIST_TEXT DIST_FEET 500ft 500 1,000ft 1000 1500ft 1500 1 mile 5260 The COMPSTAT Administer can customize–and has complete control over–the distances that are available for selection to the user. The Administrator may use ESRI ArcView to add or delete records in the time.dbf table and modify the distance-in-feet value used in the query of the attribute files associated with each police data shape file. The distance.dbf file located in the "…\Admin\Tables" directory. As the values in the DIST_FEET field are numeric, no quotes are necessary. With the "distance.dbf" table the COMPSTAT Administrator will: . Control the number of distance categories in the list that appears from the Distance listbox. . Store the labels for each radius distance value that will appear in the dropdown list on the form. . Store the number representing the number of feet for the search radius. These are the steps to add a new category: 1. Open ArcView. Add the distance.dbf table to the current project. 2. Open the table by clicking on its name in the Project window. 3. With the table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 4. Click on Edit form the main menu, and select Add new record. 5. Make sure a clear descriptive number or phrase for the distance value is stored in the LIST_TEXT field. 6. Type in the search radius distance into the DIST_FEET field. This is the radius that will be used in the spatial search to select the desired subset of records. Note the distance value must be in feet, as feet are the map units of the GIS files used by the Arlington Police Department. Note: As the values in the DIST_FEET field are numeric, no quotes are necessary. Note: For a query to not filter out any records, you must leave the DIST_FEET field empty. 7. Save the table. Refer to steps 3 - 7 to modifying the distance to be use in a query. To delete a category: 3. With the distance.dbf table open, click on "Table" from the main menu, and click on "Start Editing" from the Table menu. 4. Click on the row (record) in the table that you want to delete. It should automatically be highlighted in yellow to confirm that it has been selected. Click on Edit from the main menu, and select Delete record. ! Remember: It is necessary when editing any table used by this system to use ArcView to perform all editing! 3.5 Administration resources: Reference tables and files Various files have been created and placed in the "…\Admin" directory to aid in the administration of the tables and shapefiles. Please become familiar with them. They are: . CompStat Administration.doc This Document . AV Date Formula .doc The COMPSTAT application requires that the police data shapefiles contain a text field labeled "DATE" and that its date value be in "MM/DD/YYYY" format. This Word document contains step-by-step Instructions for using ArcView to extract the incident date from the "INC" field in the Arrest police data shapefile and write it to a new field, labeled "DATE," in the standard "MM/DD/YYYY" Y2K required format. This operation must be performed by the Administrator - on every police data shapefile - before trying to use it with the COMPSTAT application. This process creates a field and populates it with date values that can be queried by this program. . Administrate_tables.apr An ArcView apr file has been prepared to aid in managing and modifying the tables COMPSTAT application program to ensure that they remain compatible with the ESRI MapObjects components embedded in the application. The tables used by the COMPSTAT application are all in dBase format. While various programs, such as Microsoft Excel are able to import, modify and save tables in the dBase format, in our experience .dbf files saved out from Excel are sometimes unreadable by ESRI ArcView GIS. Therefore, since the MapObjects components embedded within the COMPSTAT application are also a product of ESRI, and since the ArcView GIS program is available to–and commonly used by–the COMPSTAT Administrator, we recommend that ArcView always be used to modify or replace any dBase table to be used by the COMPSTAT application. The ArcView project file that we have prepared has had each of the COMPSTAT tables already added to the project. The first time that the Administrate_tables.apr is opened it will be necessary to indicate where the dBase tables are currently located on your computer or network. Save the project and the next time this ArcView project is opened the tables will load from their new locations automatically. The tables that should be modified or replaced only with ArcView are located in the "..Admin\Tables directory." . distance.dbf . PolData.dbf . PolLayers.dbf . time.dbf . layersources.dbf This table documents the source entity for the base map shapefile layers used in the COMPSTAT application. When the application is running, the name of the shapefile is displayed in the legend on the form. To make the content of each layer easier to understand for the user, the file name of almost every shapefile has been changed. This table also records the original name and new name for each layer that appears in the base map. . Colors to Use in Tables.dbf The COMPSTAT Administrator has control over the color used to display each of the police data layers. This is done through the PolLayrs.dbf table, as described above in the "Police data map layers" section of this document. The file, "Colors to Use in Tables.dbf" contains the list of color codes used by the COMPSTAT application. 3.6 Preparation of the COMPSTAT system for meetings 3.6.1 Overview When preparing the COMPSTAT system for use in meetings, the system Administrator should ensure that the desired set of police data layers is available for display when the system is operating. The police data to be displayed will normally be the latest information available - but it should be noted that the system could be prepared to display point shapefiles of police data from any desired time-period. Query parameters should also be reviewed, and the values in the appropriate dBase table(s) modified if desired. 3.6.1.1 Prepare and load new shapefiles To make police data available for use by the COMPSTAT system: 1. Use ArcView to geocode the desired police data, such as arrests, calls for service or field interviews, and save the results of each geocoding operation as a new shapefile. 2. Review the attribute table of each shapefile. Consider if the meaning of the field names or record values will be clear to the users of the COMPSTAT system during meetings, or if any of the values should be replaces with something clearer. 3. Use ArcView to add a new text field to the attribute table of each new police data shapefile, give it the label "DATE" and populate the field with the date value for that event. Refer to the Word document titled "AV Date Formula.doc" located in the "… \Admin" directory for instructions on how to extract the date value from the "INC" field. DATE field value format must be "MM/DD/YYYY" 4. Place the new shapefiles in the "…\Data\Map_Layers" directory. 5. Remove from this same directory the shapefiles of police data that were used previously by the COMPSTAT system, and save them to an archive directory. 3.6.1.2 Update PolLayrs.dbf 6. Use ArcView to open the PolLayrs.dbf dBase table, and edit the values in the SHPNAME column to replace the names of the previous shapefiles with the names of the shapefiles of police data that you just placed into the "…\Data\Map_Layers" directory. Replace each name with the name of the new shapefile that is to replace it. Double check your spelling of the shapefile name and the use of capital letters in the name to avoid errors in loading the shapefiles when the application starts. It may be necessary to rename your shapefile(s) so as not to have empty spaces in the filenames. Change the display color for each new police layer, if desired, in the COLOR column. Refer to the list of MapObjects color variables, above—and remember that the color that is set in this table only determines what color the entire layer will be drawn in when it is checked in the Legend located in the lower-left of the COMPSTAT display screen. This does not affect the colors used to draw the layer selected for display through any of the drop down boxes on the COMPSTAT screen. The color that each layer will be drawn with, when selected with a drop down box, is indicated by the color of the symbol located to the right of that drop down box. 7. Review query parameters available in the distance.dbf, PolData.dbf, and time.dbf tables, and if desired, edit the values in the appropriate field(s). 3.6.1.3 Test system 8. Run the COMPSTAT application and test the new layers and the various query combinations. Chapter 2 ISTEP Phase II Case Studies Final Report School Safety and Information Technology at the Montgomery County (MD) Public Schools January 2003 Prepared for Office of Community Oriented Policing Services (COPS) Program/Policy Support and Evaluation Division 1100 Vermont Avenue, NW, Washington, D.C. 20530 Prepared by Tom Rich Anne-Marie Bruen Abt Associates Inc. 55 Wheeler Street Cambridge, MA 02138 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 1.1. ISTEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 1.2. ISTEP Applied to School Safety . . . . . . . . . . . . . . . . . . . . . .57 1.3. Site Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2. School Safety and Information Technology: The Current Situation . . . . . . 61 2.1. Primary School Safety Information Consumers . . . . . . . . . . . . . . . 61 2.1.1. School Administrators. . . . . . . . . . . . . . . . . . . . . . . . . .61 2.1.2. School Security Personnel . . . . . . . . . . . . . . . . . . . . . . . 63 2.1.3. Law Enforcement Officers . . . . . . . . . . . . . . . . . . . . . . . .64 2.2. Data Systems and Utilization. . . . . . . . . . . . . . . . . . . . . . . 66 2.2.1. School Incident Data. . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.2.2. Law Enforcement Data. . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.2.3. Attitudinal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 3. Initiatives Under Consideration. . . . . . . . . . . . . . . . . . . . . . .73 3.1. School Incident Data . . . . . . . . . . . . . . . . . . . . . . . . . . .74 3.1.1. Interim Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.1.2. Comprehensive Solution. . . . . . . . . . . . . . . . . . . . . . . . . 77 3.2. Law Enforcement Data . . . . . . . . . . . . . . . . . . . . . . . . . . .81 3.3. Attitudinal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Differences Between Incident-Based and Student-Based Systems . . . . . . . . . 85 Illustrative School Safety Survey . . . . . . . . . . . . . . . . . . . . . . .88 1. Introduction This report is one of several produced for the Information Systems Technology Enhancement Project (ISTEP), a project funded by the U.S. Department of Justice's Office of Community Oriented Policing Services (COPS Office). The overall goal of ISTEP is to develop written documentation, software systems, and procedures that will increase the utilization of information and information technology (IT) in police departments, particularly regarding the implementation of community- and problem-oriented policing. This report expands the scope of ISTEP from information technology utilization in police departments exclusively to public safety organizations in general. The report focuses in particular on the role that information technology can play in enhancing safety at elementary and secondary schools. As with prior ISTEP reports, this report focuses on a single site–the Montgomery County (Maryland) Public School system. In conducting this research, Abt Associates project staff interviewed a total of five principals and safety officers from four different schools; seven persons from various Montgomery County school district offices; and three representatives from the Montgomery County Police Department. As this methodology suggests, this project and the resulting report are limited in scope. In particular, the report does not discuss everything Montgomery County is doing, or is considering doing, relative to school safety. Such a report would need to address a wide variety of topics, including safety policies and procedures, programmatic interventions, video surveillance and metal detectors, staffing, training needs, and critical incident response plans. Instead, the report documents and organizes some major initiatives being considered in Montgomery County. Thus, for Montgomery County, the purpose of this report is to assist strategic decision making relative to information technology and to highlight how information technology can support the implementation of safe school strategies and tactics. This report is organized as follows: . The remainder of Section 1 provides background information on the ISTEP Project and discusses how ISTEP relates to school safety. . Section 2 examines the current situation regarding information technology and its role in school safety, both nationally and in Montgomery County. Specific topics include which persons need to have access to school safety-related information, what type of information is available to provide to these persons, and how school safety data are currently used. . Section 3 discusses specific information technology initiatives under consideration in Montgomery County. While the initiatives are specific to Montgomery County, they should also apply to most school districts across the country. . An appendix contains additional materials related to the initiatives discussed in Section 3. 1.1. ISTEP Overview With the goal of increasing the utilization of information and information technology in police departments implementing community policing, the ISTEP project team initially developed a conceptual framework document that describes how community policing imposes different information needs on law enforcement. In particular, the framework identifies seven key information domains that should be developed if police departments are to implement community policing effectively. The seven domains are: . Community interface . Inter-organizational linkages . Work-group facilitation . Environmental scanning . Problem orientation . Area accountability . Strategic management Subsequent project work proceeded in two phases. The goal of Phase I was to learn about police department accomplishments in community policing, technology development, and the seven information domains. Phase I was also designed to gain an understanding of the internal and external processes involved in implementing information technology in support of community policing. Five police departments–Tempe, Arizona; San Diego, California; Hartford, Connecticut; Reno, Nevada; and Charlotte-Mecklenburg, North Carolina–were selected to participate in Phase I of the project. These departments were selected because of their successes and experience relating to information technology and community policing implementation. The Phase I departments provided the ISTEP team with open access to their operations and made command and line level staff fully available for interviews, observations, and questions. Several site visits were made to each city to gather information on community policing practices, technology planning, and technology implementation. Members of the ISTEP team attended numerous meetings, participated in technology training, conducted ride-alongs, and examined specific hardware and software at each site. Individual case study reports were prepared for each of the participating departments and submitted to the COPS Office. A Phase I cross-site report synthesizes the findings of the individual case studies. It does so by addressing nine specific questions, as a means of helping other departments involved in community policing learn and understand the processes necessary for IT development. The nine questions are: . Is technology driving community policing or is community policing driving technology? . Is there integration of technology with strategic planning? . Is the process of designing and acquiring technology "bottom up" or "top down"? . What is the level of external support for these processes, and what linkages with other information and intervention systems are present? . What is the mix of "in-house" versus "out-of-house" expertise shaping technology planning and acquisition? . Who is responsible for IT integration? . How do these new systems and/or processes actually affect the quality and impact of police work, and how do we know that such changes have occurred? . Is there a process for on-going assessment of IT implementation and use, and how is it sustained? . How is such change financially supported? All Phase I reports are available on the COPS Office website. In Phase II of the project, the ISTEP team worked with three police departments (Phoenix, Arizona; Reno, Nevada; and Arlington County, Virginia) and one school district (Montgomery County [MD] Public Schools). The ISTEP team worked closely with these departments to document information technology initiatives that are supporting community- and problem-oriented policing. The Phoenix and Reno case studies focus on specific problems–prostitution and auto theft, respectively–while the Arlington case study describes the design and development of a decision support system for police commanders that can support community policing in a wide range of environments. The Montgomery County Public Schools case study discusses options under consideration for improving the collection, exchange, and utilization of school safety-related information within the school district. 1.2. ISTEP Applied to School Safety The national movement to standards-based education has created a sense of urgency for improving the quality of education. At the same time, educators have long realized that students cannot learn in unsafe schools. The events of September 11th, as well as high profile shootings at schools in recent years, have heightened concerns about school safety to the point where school mission statements typically speak of 'ensuring a safe and effective learning environment.' Yet the information and IT requirements necessary to bring community policing strategies to K-12 schools has been relatively undeveloped. This presents an opportunity for ISTEP. Interestingly, at the national level, there is no comprehensive source of information on the nature and extent of school safety problems. Quantitative measures on school safety are based on infrequent surveys of students, teachers, and administrators, rather than counts of actual incidents. Some of the indicators from these surveys suggest that school safety has improved in recent years. For example, in the 2001 edition of the "Indicators of School Crime and Safety" report from the U.S. Department of Education, the percentage of high school-aged students who reported carrying a weapon to school declined from 12 percent in 1993 to 7 percent in 1999, while the percentage of male high school seniors who reported carrying a weapon to school on at least one day within the previous four weeks also declined over this same general period–from 14 percent in 1993 to nine percent in 1996. At the same time, it is interesting to note that relatively few students–fewer than 4,000 during the 1997-98 school year, according to the U.S. Department of Education–are expelled for carrying weapons to schools. Whether or not quantitative measures of school safety have shown an improvement or a worsening in recent years, many parents, students, school administrators, teachers, police, and other members of the community have a perception that the problem is serious and growing. This perception can create an environment of fear and distraction that inhibits learning by students and teaching by instructors. It can also encourage students to come to school with weapons, provoke parents to keep their children out of school or send them to private school, and create stress among teachers that leads them to take "mental health days" or even switch careers. This perception is a reality that school administrators and law enforcement representatives must take seriously and address. For the COPS Office, a recent top priority has been to bring community- and problem-oriented policing to K-12 schools. The COPS Office has accomplished this, in part, through two major grant programs. One, the School-Based Partnership Program, has provided approximately 275 police agencies with an opportunity to work with schools and community-based organizations to address persistent school-related crime problems, such as drug dealing, assaults, or bullying. The second program, the COPS In Schools hiring program, provides funding to local jurisdictions to deploy sworn law enforcement officers in K-12 schools to engage in community policing activities. Officers are deployed as School Resource Officers (SROs) and play multiple roles in the school, including problem solver and liaison to the community, educator, and law enforcement/safety specialist. Over 2,000 jurisdictions are participating in the COPS In Schools program. A reason to involve school safety in ISTEP is that the seven ISTEP information domains, although developed for police departments, are also applicable to school communities. For example, the community interface domain is critical because persons directly responsible for ensuring school safety, including school administrators, SROs, and school security staff, must engage the community in school-based problem solving efforts, since parents, business leaders, and other residents have a vested interest in fostering school safety. Having a problem-, rather than incident-, orientation is also critical. In addition, problem-solving efforts must incorporate a broad array of data sources, rather than simply discipline or incident data. Finally, the work-group facilitation requirement is also important, as problem solving efforts should include several stakeholders within the school community, including students, faculty, and support staff. In the vast majority of schools, however, the only automated information widely available are data on students' attendance, grades, schedules, and other information that are stored in systems generally called "student information systems." These systems were not designed to capture detailed information on the nature or extent of school safety problems; they generally only contain records of when students were suspended or expelled for violating school rules. These systems lack critical information on incidents not resulting in an administrative sanction against a student (e.g., 'unsolved' incidents), as well as any information on victims. Information sharing with other agencies, including police, probation, and other criminal justice agencies, is, typically, ad-hoc and based on personal relationships. To effectively implement community policing in schools, a wide array of data sources must be available, including school incident and discipline data, student and staff survey information on safety and crime, and police data (especially regarding problems in the area surrounding the school). These data should be widely accessible in a convenient format and there must be a variety of easy-to-use tools for viewing and analyzing these data. In particular, schools should be able to view the nature and extent of their own safety problems within the context of problems at other similar schools, thus enabling schools to establish a basis for self-evaluation and continuous quality improvement. Finally, policies, procedures, and training programs must be implemented to ensure that collected data are complete, accurate, and timely, and that a variety of easy-to-use software applications are available to allow authorized users to analyze these data. 1.3. Site Background Montgomery County is located immediately northwest of Washington, DC (see map). Approximately 900,000 people live in the 500 square-mile county. Map of Montgomery County, Maryland and Surrounding Area 1 All statistics presented in this section were taken from the MCPS website. With approximately 140,000 students, the Montgomery County Public School system (MCPS) is the largest school district in Maryland and the 19th largest in the Nation.1 It is also the 12th fastest growing in the Nation. MCPS employs 10,700 teachers and has an overall operating budget of $1.3 billion. MCPS has 190 schools–125 elementary schools, 35 middle schools, 23 high schools, and 7 specialized schools. Each school is part of a 'cluster', which includes one or more high schools and all their middle and elementary feeder schools. A Community Superintendent oversees groupings of three or more clusters. Community Superintendents report to the Deputy Superintendent of Schools, who reports directly to the Superintendent of Schools. Montgomery County is economically and racially diverse. Although the County is the most affluent in Maryland and includes some of the wealthiest Washington D.C. suburbs, 22 percent of MCPS students receive free or reduced priced meals. Whites constitute 49 percent of the student population, followed by African Americans (21 percent), Hispanics (16 percent), and Asian Americans (13 percent). MCPS is perhaps best known as a high-performing public school system. Fifty-six percent of MCPS students enroll in honors or advance placement classes, 98 percent of students graduate, and 82 percent plan to attend college. During the project, no formal attempt was made to measure school safety, either by conducting surveys or analyses of discipline and crime data, or to render an overall judgment as to whether MCPS schools are "safe." It should be noted, however, that there have been no shootings in MCPS schools and that parents are overwhelmingly satisfied with the quality of MCPS schools. For example, in a 1998 survey of parents, 93 percent felt that their children were getting a good education. 2. School Safety and Information Technology: The Current Situation This section provides background information on school safety and issues related to information technology, both from a national and Montgomery County Public Schools (MCPS) perspective. Section 2.1 examines what kinds of persons need access to school safety-related information; Section 2.2 looks at what type of information is currently collected that these persons might find useful; and Section 2.3 examines some of the ways in which this information is currently used. 2.1. Primary School Safety Information Consumers Any plan to improve the use of information technology to enhance school safety needs to consider all the persons who are directly responsible for ensuring safe schools and then consider the type of information they might want access to. In the discussion below, persons with direct responsibility for school safety are grouped into three categories: school administrators, security personnel, and law enforcement officers. 2.1.1. School Administrators School safety is but one of the many issues that school administrators face, although, increasingly, in many schools it is the most important issue. The specific discipline, safety, and crime issues administrators confront–and, as a result, their related information needs–vary according to whether they work at the school- or district-level: School Level Administrators Principals (and, to varying degrees, assistant principals) have primary responsibility for safety in their schools. Their duties range from dealing with minor violations of school policy to contending with acts and perpetrators of violence that can threaten the lives of students and staff. Further, not only must they deal with threats posed by persons from within the school, but they must also confront threats posed by outsiders and the surrounding community. In order to meet these challenges, school-level administrators require access to detailed student and incident data that enable them to identify and address problems–ideally, before they become crises. Management of school safety in the MCPS system is largely decentralized, with principals having primary responsibility (with assistance from the MCPS Department of School Safety and Security) for developing and overseeing school safety-related activities at their individual schools. Principals hire their own security officers, establish their own procedures for responding to and handling incidents, and have developed their own database systems for tracking referrals ("students sent to the principal's office"). MCPS principals generally have ready access to the type of information they need with respect to school safety, although MCPS is considering at least two improvements in this area. One involves having online access to police statistics on crime in their school's surrounding community. This would provide principals with a better understanding of external threats posed to their school, as well as a more detailed understanding of the issues their students face during non-school hours. The other concerns access to information on incidents occurring at other schools. Some principals thought there would be value in being able to see what safety- related issues other schools in Montgomery County (particularly those with similar characteristics) were confronting, both as a measure of "selfevaluation" and as a way of identifying schools that are or are not experiencing similar problems. District-Level Administrators The information requirements for district-level consumers (e.g., staff in the superintendent's office and the district-level security office) are driven largely by their responsibilities for formulating district-wide discipline rules, obtaining and allocating school safety resources across district schools, and ensuring that principals are maintaining safe school environments. To meet these responsibilities, district-level consumers require access to comprehensive, but not as detailed, school safety data. The level of detail required will vary, but generally, the higher up in the organizational structure an individual is, the fewer details will be required. Typically, access to monthly or quarterly data on indicators of school safety threat levels and performance of individual schools will suffice for these purposes. District-level consumers are also usually the primary point of contact for the School Board and community and parent groups. As such, in addition to general trend data, district-level consumers also need to be made aware of more serious incidents, especially those involving suspensions, expulsions and/or law enforcement action. The primary district-level administrative consumers in MCPS include the Community Superintendents, the Deputy Superintendent of Schools, the Chief Operating Officer, and the Superintendent of Schools. (The Department of School Safety and Security is also a district-level consumer, but this office's needs are considered later in this section.) Community Superintendents have direct line authority over the schools and, as such, require access to essentially the same data to which their schools have access. This is necessary primarily for accountability, oversight, and resource management purposes. Community Superintendents are also often approached by parents and/or community members regarding specific cases (whether they be incidents or students). Ready access to detailed student and incident information would greatly enhance the Community Superintendent's ability to make these meetings informed and productive. The Deputy Superintendent of Schools oversees the Community Superintendents and is responsible for making district-wide decisions regarding school safety policies and resource allocation. The information needs at this level tend to be more general and include trends in incidents and performance. The exception to this is the need for this office to be informed of any major incidents that occur in the schools. Although it varies depending upon the nature and severity of the incident, generally, this office is responsible for coordinating with other agencies to ensure a timely and appropriate response to a serious incident, and facilitating the flow of information to the Superintendent and community. A peer of the Deputy Superintendent, the Chief Operating Officer (COO) is responsible for, among other things, developing MCPS' annual budget proposal. In this capacity, this office reviews and provides input for final budgetary decisions. The information needs at this level are largely trends in performance and an understanding of how performance is linked to resource levels. Typically, this type of information is provided to the COO office by the program offices seeking to increase or maintain funding levels. In the case of school security, this is the Community Superintendents and the Department of School Safety and Security under the Deputy Superintendent of Schools. Representatives from the office of the COO, however, noted some benefits to providing that office direct access to school incident data as well. Specifically, they could assist program offices in formulating justifications for their budget requests and they could also identify the extent to which safety issues may be impacting MCPS' academic achievement goals. In summary, school administrators, including those at the school district and state-levels, need "the big picture" regarding the nature and extent of school safety problems in order to effectively manage resources and respond to their constituents with accurate information. In addition, school-based administrators need the assistance that information technology can offer to manage day-to-day individual disciplinary cases and issues. 2.1.2. School Security Personnel Many school districts–including MCPS–directly hire and use security personnel to help ensure safe schools. These staff, who are typically either retired police officers or civilians with special training, conduct safety audits, patrol hallways and other "hot spots," respond to incidents, conduct follow-up investigations of incidents, and recommend strategies for improving school safety. There are two primary models for school security staffing–centralized and decentralized. With the centralized model, a district-based security office hires, trains, and deploys security officers at schools throughout the district. Other school districts, including MCPS, employ a decentralized approach, in which each school principal hires their own security teams (subject to an overall staffing level set by the district) and develops their own procedures (with input from the district-level security office) for handling incidents and disciplinary issues. For example, the primary mission of the MCPS's Department of School Safety and Security is to provide support to individual schools (in the way of policies and procedures, emergency planning, and training) and additional assistance for major incidents. A current focus of the Department is implementing standards throughout the district related to staffing (including hiring and training) and emergency policies and procedures. Although there is no direct line of authority over security resources in the schools, MCPS is considering providing the Department of School Safety and Security (and other authorized district-level staff) with ready access to comprehensive, detailed safety-related incident data, which would improve this office's ability to support schools and establish district-wide standards. Both models have advantages; in particular, the decentralized approach allows schools to develop customized plans, subject to district-wide standards, that serve their unique safety needs. In addition, other districts use a hybrid centralized-decentralized approach, with some school-based security staff under the control of the district security office and other staff under the control of an individual principal. As is the case with school-based administrators, school security staff (especially supervisors) need both "the big picture" regarding school safety, as well as information technology support for day-to-day incident case management. In all of the Montgomery County schools visited during the project, the school security staff had access to all data regarding school safety incidents at their school. Currently, reports of incidents that are medical emergencies or that potentially involve criminal acts are routinely reported to the district level. 2.1.3. Law Enforcement Officers Law enforcement officers also play a key role in ensuring safe schools. Traditionally, law enforcement agencies provide security services to schools on either an as-needed (e.g., the school administration or school security office requests assistance for a particular incident) or routine basis (e.g., police commanders direct their officers to patrol areas around certain schools at the end of the school day). In Montgomery County, the school system and local police departments 2 have established a very good working relationship at all levels. Many District Commanders have forged close relationships with the principals and community superintendents in their district. For example, one police District Commander ISTEP project staff interviewed had established a school liaison program where officers, on a voluntary basis, 'adopt' a school. Liaison officers become a primary point of contact for schools within the police department and often become actively engaged in school activities. One liaison officer, for example, is the lacrosse coach at his high school. There is also a police district gang coordinator who works closely with the schools to exchange information in furtherance of anti- gang activities and student safety. Similarly, some schools assign students to serve as liaisons with the police district. Student liaisons keep the police department informed of school-related activities in which the police may have an interest. This can range from fund-raising events that the police department would like to support (like bringing the patrol cars to car washes) to information about planned illegal and/or dangerous activities. Student liaisons also collaborate with the police district in efforts to improve school-community-police relations. This type of cooperation and communication extends through the ranks of both organizations, with representatives from the Police Department maintaining close lines of communication with the MCPS Director of School Safety and Security and the Community Superintendents. Two other models for involving law enforcement agencies in school safety should be noted: . School Resource Officers (SROs). An increasingly popular approach to using law enforcement officers to help ensure safe schools is having officers assigned to one or more schools as full-time SROs. SROs provide a range of services, including mentoring, counseling, teaching, problem solving, and law enforcement. Nationally, the number of SROs is increasing rapidly. A 1997 survey by the U.S. Department of Justice (the Bureau of Justice Statistics Law Enforcement Management and Administrative Statistics survey) found that, nationwide, there were over 12,000 SROs deployed in schools. That number has increased significantly since 1997, in part because of the COPS Office hiring program "COPS In Schools" mentioned in Section 1.3 MCPS applied for COPS In Schools funding in May 2002 to establish an Educational Facilities Officer (EFO) program in the high schools. 2 In Montgomery County, the Montgomery County Police Department (MCPD) is responsible for the vast majority of the county. Three local communities have their own police departments. 3 As of early 2003, approximately 5,900 SROs have been funded through the COPS In Schools program. . School Police Department. Some communities have school police departments that are separate and distinct from the local law enforcement agency, much like some cities have a separate police department for their public housing developments. This situation generally arises from the public's demand, perhaps based on the perception that schools are unsafe, for a specialized sworn agency that can focus exclusively on schools. Both law enforcement authorities and schools can benefit through the exchange of information, as they share a common interest in creating and maintaining a safe school environment. There are, however, a number of issues that confound the ability of these organizations to freely exchange information. On one hand, schools have an obligation (both legal and ethical) to protect students' privacy rights. So, schools are limited in their ability to provide law enforcement agencies with certain types of information that could assist law enforcement in carrying out their duties. Similarly, law enforcement has an interest in preserving the integrity of investigations that are underway, limiting, to some degree, their ability to share information with the schools. Regardless, student safety is a paramount concern, and there are ways to work within these constraints towards that end. 2.2. Data Systems and Utilization The type of information that school administrators, security personnel, law enforcement officers, and other stakeholders need, both to understand the "big picture" and to handle day-to-day safety and disciplinary issues, can be grouped into three categories: . Information concerning incidents that occur on school campuses or in other areas where schools have safety responsibility; . Information concerning incidents that occur off school campuses but that are still relevant to school safety (e.g., because they involve students or occur near school property); and . The perceptions and attitudes of students and staff regarding school safety. Each of these three categories is discussed below. 2.2.1. School Incident Data A school incident is any event that violates a school's set of established rules of conduct. They range in seriousness from victimless minor infractions to violent felonious acts. From the perspective of ensuring safe schools, persons with responsibility for ensuring safe schools ideally should have access to comprehensive information on all incidents that are reported to school-level administrators and security staff. Comprehensive incident information includes: . Incident information–basic facts about the incident (e.g., when it occurred, where it occurred, who reported it, what happened). . Persons involved–who was involved in the incident, including perpetrators, victims, and witnesses. . Actions taken–actions that were taken against the perpetrators. Actions taken can include both administrative sanctions, which could range from a parent-administrator conference to expulsion, and criminal justice sanctions. In fact, at schools across the country school personnel rarely have access to this breadth of information. The extent to which school incident data are available (in either manual or automated databases) to the stakeholders identified in Section 2.1 varies widely by school district and depends on the district's reporting requirements and procedures, the automated systems in place to capture information, and who has access to these automated systems. Schools and school districts typically maintain incident-related information in as many as four different types of information systems: school-level student-based referral systems, school-level incident-based systems, district-level incident systems, and district-level student information systems. Each is discussed below. School-level student-based referral systems Nationally, many schools document information about student referrals (i.e., instances in which a student is sent to the school administration office because of a school rule violation or more serious incident). The documentation process can be all manual, partially automated, or all automated. All MCPS schools use a paper "Student Referral" form, which captures the student's name, a few facts about the incident (e.g., date and time), the reason(s) for referral (e.g., profanity, open defiance), action taken against the offender, and miscellaneous remarks. The form is student-based–if six students are involved in a fight, six forms will be filled out. Each of the four schools visited as part of the ISTEP project had automated systems in place to house data from the Student Referral form. Each of these automated systems was "home grown"–that is, independently developed by staff at the school (as opposed to being purchased from a vendor). In addition, each school developed its own policies and procedures regarding the use of these systems. At the schools visited during the project, the referral systems served a number of different purposes: . Assist administrators in handling new referrals. When a student is referred, the administrator immediately needs to know if and when the student was previously referred, what the circumstances were, and what action was taken. A simple query to the system can bring up this information. . Referral summaries for parent conferences. For parent-administrator conferences, a computer-generated report of prior referrals demonstrates solid evidence of past behavior problems. . Identify teachers with unusually high numbers of referrals. Conferences can be held with these teachers to identify and solve specific problems and to ensure that consistent discipline standards are being applied. . Identify at-risk students. One school that project staff visited has a systematic method for identifying students at-risk for dropping out of school, so that additional services can be provided to these students. One factor in this methodology is the number of referrals. . Keep parents informed. More than one principal at the schools visited during the project mentioned the importance of ensuring that accurate information is provided to parents, in part to dispel rumors and other sources of inaccurate information. In one instance, data from the school's referral system was used to counter claims that minority students were being unfairly targeted for referrals. . Justify requests for additional resources. A common use of incident tracking systems used in schools and other settings is to justify requests for additional resources–utilizing detailed records that document the extent of disciplinary or criminal incidents is more persuasive than making arguments based purely on perceptions of problems. School-level Incident-based Systems In contrast to the student-based systems discussed above, some schools across the country use incident-based systems to collect and analyze information on school incidents. Whereas student-based systems relate all information to a particular student, incident-based systems relate all information–including persons involved in the incident and actions taken against perpetrators–to an incident. (See also the appendix "Differences Between a Student-Based and an Incident-Based System.") Some MCPS schools use incident-based systems, while others use student-based systems. Both types of systems have advantages. Key advantages of incident-based systems include: . Incident-based systems can capture information about incidents in which no perpetrator was identified. . Incident-based systems can capture information on persons other than perpetrators who were involved in the incident. Knowledge about who was victimized, in particular, is essential for effective problem solving. . Incident-based systems can answer a much broader range of questions than student-based systems–for example, how many fights were there last year, in addition to how many students were involved in fights. At the same time, incident-based systems, at least initially, appear unnecessarily complex to educators who, naturally, have a "studentfocus"– educators think in terms of students, rather than incidents. This is generally not the case with security staff, many of whom are former police officers, who typically have an incident orientation. District-level incident systems In many school districts, including MCPS, certain incidents–as dictated by school district procedures–are reported to the district offices, typically the security office, where they are maintained in manual or automated files. In MCPS, "serious" incidents–generally defined as criminal offenses and incidents requiring immediate medical attention–are immediately reported to the central administrative office and, as appropriate, other agencies (e.g., law enforcement, emergency medical agencies). Serious incidents are reported via telephone to the central MCPS office, where facts about the incident are entered into an internally-developed FoxPro database system. The primary purpose of this system is to ensure that the appropriate agencies and persons within MCPS are notified and respond to the incident. A printout of entered data is immediately sent to the appropriate Community Superintendent, the Associate Superintendent, and the Department of School Safety and Security. In addition, MCPS personnel funnel all requests for information from the database to an analyst in the Office of School Performance. Staff at the Department of School Safety and Security, for example, periodically request reports that show trends for different types of incidents. In addition, annual incident totals by school are one factor, along with the number of students and the size of the buildings, which determine the allocation of security personnel across the schools. District-level student information systems A school district's main administrative system, generally referred to as a student information system, records and maintains a variety of information on students, including their schedules, attendance, and grades. These systems also include a "discipline module" that typically captures information on actions taken against students. In MCPS, an action taken that results in keeping a student out of class (i.e., suspensions and expulsions) will be documented in the discipline module. The MCPS discipline module also captures some incident information, including the date the incident that led to the suspension occurred and the reason for the suspension (i.e., the "incident type"); information about the student suspended; and information about the action taken (e.g., length of suspension). In MCPS, staff at the individual schools enter suspension data into the student information system. The central office prepares a data extract two to three times a year for each school that contains all data on their students; if desired, schools can import these databases into desktop software applications for further analysis. 2.2.2. Law Enforcement Data Many events and incidents that impact school safety do not occur on school property: students could be arrested in the evening or on weekends; criminal activity can occur near campuses or near student hangouts; and, in general, community crime and disorder problems can be "brought" into the schools. For schools, the issue is to what extent are they kept informed of events and conditions that may affect school safety. There are a variety of mechanisms for sharing information between a school district and the local law enforcement agency, ranging from online access to law enforcement databases, to daily faxes of pertinent information, to informal information sharing via telephone. In MCPS, information regarding specific criminal incidents involving or threatening MCPS students is provided to MCPS staff in two different ways. If a student is arrested for a Part I crime4 (excluding drug-related crimes), state law requires that the police department notify the school district by faxing a Student Arrestee Notification Fax Memorandum to the Director of School Safety and Security. Information regarding other types of incidents involving or affecting students is provided via established lines of communication between the police department and MCPS. 4 Part I crimes include homicide, rape, robbery, aggravated assault, burglary, larceny, and auto theft. 2.2.3. Attitudinal Data While school and law enforcement incident data can help identify new trends and provide a means to track progress in meeting safe school goals, perceptions of safety issues of students, teachers, and staff can serve other purposes and complement incident data. A variety of survey instruments are in use in school districts across the country. The instrument included with the COPS Office "COPS In Schools" training manual (and shown in the appendix to this report), for example, includes 44 questions on such topics as: . Extent to which the respondent feels safe or unsafe at schools, in general. . Extent to which the respondent feels safe or unsafe at specific locations (e.g., locker rooms, stairwells, restrooms). . Whether the respondent has been victimized via thefts, physical attacks, or verbal attacks. . Whether the respondent has carried different types of weapons in school. . Extent to which specific issues (e.g., drug use, fights, gangs) are a problem in school. . The respondent's comfort level in reporting incidents to administrators and security officials. It is also possible to supplement surveys with focus groups and individual interviews with students and staff. The MCPS's Office of Shared Accountability has an active research and evaluation unit that conducts a wide variety of surveys of students, parents, and staff. This unit currently conducts a survey that focuses on the overall "climate" at schools and includes about a half dozen questions on school safety. 3. Initiatives Under Consideration MCPS recognizes the important role that information technology can play in enhancing school safety and is actively considering new initiatives in this area. This section discusses some of the key initiatives under consideration. While the initiatives focus on MCPS, they are, in general, applicable to most school districts around the country. Key features, benefits, and design considerations are presented, but equipment, personnel, and other cost calculations are, for the sake of brevity, not discussed. In addition, no attempt has been made to discuss these initiatives within the context of other possible ways of improving school safety, nor to address such questions as "is it more cost effective to invest resources in training, security cameras, or programmatic initiatives instead of information technology?" The initiatives concern the collection and analysis of school incident data (Section 3.1), law enforcement information (Section 3.2), and attitudinal information on school safety (Section 3.3). Together, the initiatives are intended to improve MCPS's ability to: . meet the diverse information needs of principals, assistant principals, and school-based security teams, and . meet the diverse information needs of persons who work at the district-level and have safety responsibilities that span many, or all, schools. More specifically, by enhancing the information available to school- and district-level administrators and safety personnel, MCPS will improve their ability to: . manage day-to-day student referrals, incident investigations, and case management . implement formal problem solving initiatives . respond to ad-hoc concerns raised by the school board, parent groups and other constituents, and provide them with accurate information . build community support for safety initiatives . identify new and emerging trends . ensure that adequate resources are available to address school safety problems . establish measures with which to track school safety . identify schools that may are experiencing similar safety problems . identify schools that have developed effective strategies for dealing with particular problems . identify district-wide needs and priorities 3.1. School Incident Data In order to meet the information needs identified above, MCPS is considering implementing systems and procedures that will improve the collection and utilization of school incident data. MCPS recognizes that there is no comprehensive source of school incident information in MCPS. This is also the case in the vast majority of school districts in the country. Specifically, MCPS is considering a two-phase approach to improving the collection and analysis of school incident data: . Phase I involves an Interim Solution that could be implemented quickly (since it does not involve changes to school-level policies and procedures) and would offer significant benefits to district-level administrators and school safety staff. . Phase II involves a longer term approach–the Comprehensive Solution–that would create a comprehensive source of school incident data that could be made available to authorized users at the school- and district-levels. Figure 1 summarizes the differences between the current approach, the Interim Solution, and the Comprehensive Solution. This will allow MCPS to realize some immediate benefits to their incident reporting and analysis capabilities, while they consider the design and implementation of the Comprehensive Solution. Figure 1 Collection and Analysis of School Incident Data: The Current Situation, the Interim Solution, and the Comprehensive Solution Data Entry Procedure Current Situation: School-level staff telephone district staff, who enter data in the serious incident database Interim Solution: Same as Current Situation Comprehensive Solution: School-level staff enter incident information directly in the new system What Data are Entered: • Which incidents Current Situation: Serious incidents only Interim Solution: Same as Current Situation Comprehensive Solution: All incidents • Information for Each Incident Current Situation: Basic incident facts (what, when, and where) Interim Solution: Same as Current Situation Comprehensive Solution: Basic incident facts + Persons involved + Actions taken Data Access Procedure Current Situation: Indirect (requests are telephoned to an analyst) Interim Solution: Direct (desktop access by authorized district-level staff to data analysis tools) Comprehensive Solution: Direct (desktop access by authorized school- and district-level staff to data analysis tools) The Interim Solution is discussed below in Section 3.1.1; the Comprehensive Solution is discussed in Section 3.1.2. 3.1.1. Interim Solution The Interim Solution involves making improvements to the serious incident database. The improvements relate to how the data are accessed, rather than how they are reported. In fact, the Interim Solution does not involve any procedural changes to how serious incidents are reported to the district level–that is, school-level staff would continue to report these incidents via telephone to the central district office. As such, the Interim Solution could be implemented quickly, while design work proceeds on the Comprehensive Solution (see Section 3.1.2). Specially, the Interim Solution would involve: . Reviewing and, if necessary, revising policies and procedures to ensure that consistent, accurate, and updated serious incident data are collected from schools. Reporting standards relative to serious incidents (e.g., definitions of what constitutes a serious incident) must be addressed to ensure that the serious incident database is accurate and complete. . Making the serious incident database directly accessible to authorized district-level staff. All authorized users, in particular staff in the Department of School Safety and Security and the Community Superintendents, would have access to the database from their desktops. . Developing a wide array of reporting and analysis tools. Primary emphasis of the Interim Solution system development efforts would be focused on how the data will be analyzed and used, rather than on how data will be entered. As such, easy-to-use software needs to be available that enables authorized users to produce a wide variety of tabular reports and charts. Since incident information reported under this scenario would not be linked to data on persons involved or actions taken, this scenario offers lower potential benefits for district-level personnel compared to the Comprehensive Solution discussed in the next section. Still, assuming the data quality and accessibility improvements are instituted, the serious incident database could become a much-improved tool for measuring district-wide safety, identifying needs, and improving resource allocation. In addition to improvements to the serious incident database, a component of the Interim Solution could be to standardize data collection and analysis at the school-level. For example, a standard incident-based or student-based package–either a commercial package purchased from a vendor, a package developed in-house by MCPS staff, or a public domain package–could be offered to any school in the district. 3.1.2. Comprehensive Solution For the long term, MCPS is considering a Comprehensive Solution to meet the diverse safety information needs of school- and district-level personnel. This would involve a centralized, district-wide incident collection, analysis, and reporting system. It would replace the existing district-level serious incident database and ad-hoc school-level student referral databases. Specifically, the system would reside on the school system's network and: . Enable schools to directly enter, into a centralized database, comprehensive school incident information, including information about: . The location, day, time and nature of the incident, . Persons involved in the incident (victims, offenders and witnesses), and . Actions taken against perpetrator; . Provide authorized school-level, district-level, and other stakeholders with flexible on-line analysis and reporting tools that can meet their diverse information needs; and, . Automatically transfer information to other systems (or, alternatively, automatically accept information from other systems), as necessary, to minimize data entry burdens. Under the Comprehensive Solution, school-level personnel would enter basic facts about an incident shortly after learning of and/or responding to the incident. For many incidents, this would occur when a student (who, for example, has been involved in a fight) is referred to the principal's office, just as many schools currently log student referrals in referral databases. Other incidents, such as vandalism to school property or bullying reported by a victim, would be entered in the system prior to the identification of an alleged perpetrator. As additional information about the incident is discovered (e.g., additional persons involved) and administrative sanctions are determined, school-level personnel would update the on-line record with that information. Depending on how the system was configured, authorized personnel at the school- and district-levels would have immediate access to this information at either the incident-level (e.g., specific details about individual incidents could be perused) and/or at the aggregate-level (e.g., the incident would be included in summary reports). For school-based personnel, all of the current functionality of school- based referral databases would be included in the new system. Indeed, facilitating day-to-day management of incidents and referrals is a key objective of the system. Since the new system would be incident-based, rather than student-based, more incidents (i.e., those that do not result in a student referral) and different types of information (e.g., victim information) would be available compared to the existing student-based referral systems. (See the appendix, "Differences Between Incident- Based and Student-Based Systems") Using these data, school-based personnel could produce a wide variety of reports and visual graphics that depict safety at their school. In addition, depending on how the system is configured, this system could provide school-based personnel with some level of access to incident information at other schools (either incident- level data or aggregate reports), thus enabling school-level personnel to quickly determine which schools are (and are not) experiencing similar problems. For district-based personnel, this new system offers substantial benefits compared to the current system, both in terms of the number of incidents available for analysis (all vs. only serious incidents), the depth of information (information on persons involved and actions taken vs. only basic incident facts), and accessibility of the information (available as a desktop application with a broad array of reporting and analysis tools vs. making requests for information via telephone). Key Design Issues and Options Implementation of a district-wide incident collection and analysis system requires decisions on a number of major design issues: . Which schools. Although certainly feasible, the system need not involve all MCPS schools. For example, an initial goal might be to include only high schools in the system, but then later expand to include middle schools. . Reports and applications. Providing useful information to authorized system users is the key to the success of any system. Systems perceived as simply data collection tools will ultimately fail because the persons responsible for entering the data have no stake in ensuring the quality of the data. To that end, adequate resources need to be devoted to specifying and then developing (1) reporting tools for retrieving and analyzing incident data (e.g., charts, graphs, maps (of the schools and county), tabular reports) and (2) applications (e.g., resource allocation models, forecasting) that use statistical modeling and other sophisticated analytic techniques that can improve decision-making processes. . Accessibility. The extent to which various users have access to incident data can vary, ranging from the most restrictive (the ability to only view aggregate data for a single school) to the most flexible (the ability to view incident-level data across all schools). Since the needs and access rights of different users will vary, the system should allow for access levels to be customized at the user level. Of course, accessibility of the information must be balanced against student privacy rights expressed in state and Federal (e.g., FERPA) law. . Technology approach. MCPS is considering two overall Intranetbased technology and system integration options: . Integrate with student information system. Ideally, an incident reporting and analysis system should be one module of a district's student information system. Not only does the student information system already serve many of a district's operational needs, but also "specialized" independent systems increase maintenance and support costs and are at-risk of falling into disuse if key system users transfer positions or leave the school district. Since MCPS's existing student information system is planned to be replaced, MCPS is considering including the Comprehensive Solution in the design requirements of a new student information system. . Use a separate, independent incident reporting and analysis system. Alternatives to integrating incident reporting and analysis into the student information system are to develop inhouse, purchase from a vendor, or use a public domain incident reporting and analysis system. This approach may represent at least a good short-term solution for MCPS, until a new student information system, with integrated incident reporting and analysis, can be developed. If this option were pursued, MCPS would select or design a system that captures and defines data in a format consistent with their long-term student information system design intentions. In other words, if it is important for MCPS to be able to categorize incidents as either safety- or medical-related, they will want the interim system to be able to make such a distinction. Otherwise, data captured in the interim will not be transferable to the student information system that is ultimately developed. Related Implementation Issues The design and technological issues outlined above are relatively easy to resolve compared to the challenge of collecting consistent data across the schools. Given this, and the fact that the proposed system represents substantial changes to current MCPS procedures–most notably maintaining linked incident- and student-level data at the district level– MCPS recognizes that a carefully developed implementation plan is required. The key elements of the implementation plan, aside from the design considerations discussed above, include the following: . Conduct informational meetings. The required changes, the expected benefits, and the anticipated costs of this option need to be carefully explained to all stakeholders. In particular, school-level benefits need to be articulated to ensure that all parties understand that this system, unlike statewide incident reporting systems in other states, is not simply for the benefit of higher level policymakers and researchers. Also, principals need assurances that this system will not become just a tool for measuring their performance, but rather a method for identifying areas for improvement and schools in need of additional resources. MCPS leadership also recognizes the need to address concerns that some principals may have that their school will be inappropriately compared to schools with entirely different characteristics (e.g., different crime rates in the surrounding neighborhood). . Secure formal buy-in. Following the informational meetings, stakeholders should agree to support the new system. This is particularly true for school-based administrators and security staff, inasmuch as their support and cooperation is essential to the success of the project. If support from a majority of school-based staff cannot be secured, their objections should be identified and options for addressing these obstacles should be explored in a collaborative manner. . Establish definitional and reporting standards. Any attempt to combine data across multiple schools requires that each school adhere to certain reporting standards. The standards must be very detailed and specific and be consistent with state and Federal reporting requirements. For example, the standards need to distinguish battery (which is generally a criminal offense reportable to the police) and fighting (which is generally not reportable to the police), and establish what is and is not a reportable theft. In general, there needs to be a consistent definition of an "incident"; otherwise, cross-school comparisons will be meaningless. Once standards are developed and tested, they need to be thoroughly explained, via meetings and workshops, to MCPS personnel involved in the system. . Establish incentives for accurate reporting. MCPS recognizes the need to address this difficult, yet critical, issue. The lack of incentives for accurate reporting–or, conversely, sanctions for underreporting–is perhaps the most important design flaw in statewide school incident reporting systems and other systems that require school-based personnel to report incidents to a central office. In the end, how district-level managers use information from the centralized incident reporting system will be the driving influence. Generally, the best way to ensure accurate reporting is to view the data as a tool that managers and principals can use to collaboratively identify and develop solutions to problems in the schools. Using the data as a basis for punitive actions–or imposing arbitrarily derived performance goals for a school–will almost certainly result in a "gaming" of the system. A sensible approach would be for the Community Superintendents and the Director of School Safety and Security to meet with individual principals to establish mutually agreed upon performance goals that take into account characteristics (e.g., community crime rates and demographic characteristics) that would be expected to affect a school's rate of incidents. A number of persons interviewed from MCPS (both at the school- and district-levels) indicated that they were very open with community stakeholders about incidents occurring in their schools–even when the data showed there was a problem. They considered this, though, an opportunity to not only inform the community about what they are trying to do to remedy the problem, but also as a means of eliciting the community's support. Although implementing this type of a system presents challenges, they are far from insurmountable. Costs, too, can be minimized by using public domain incident reporting and analysis software packages that can be acquired free of charge. 3.2. Law Enforcement Data Staff interviewed from both the police department and school district seemed pleased with the support they received from the other agency. Although having formal, automated, routine reporting of police data would be ideal, given MCPD's workload and current limitations of their records management system (RMS), this would place an undue burden on the police department for what would amount to minimal benefit for the school district. Also, the MCPD website5 already contains monthly and quarterly crime statistics by police district and type of crime. Although a smaller level of geographic detail (e.g., to the patrol service area or school boundary) would be more beneficial to school principals, district-wide crime statistics still provide at least a general picture of what may be occurring in the school's surrounding community. Therefore, in the short-term, MCPS is working to ensure that all principals and community superintendents are enjoying the same type of cooperative relationships with their police district commanders as those ISTEP project staff interviewed. In cases where relationships have not been established, the Director of School Safety and Security is leveraging his experience and relationships with both the police department and school system to help forge such ties. 5 www.co.mo.md.us/services/police /media/crimestats1.html A long-term goal is to provide school officials (both at the school and district levels) automated access to crime statistics, with an ability to aggregate according to school boundaries. From their desktop PC, school officials should be able both to quickly view information on crimes committed near their school and examine crime trends in the areas around their school. In fact, many police departments throughout the country have websites where anyone can access crime information. While the current MCPD website provides only aggregate crime and arrest information at the county level and for each of their police districts, other police departments have websites that provide query and analysis tools, so that, for example, a citizen can view information about crimes occurring within 1000 feet of a school.6 The MCPD is in the process of overhauling their police information systems. As such, MCPS views this as an ideal time to discuss the specific information needs of the school system so these needs can be considered in the development of the MCPD's new system. 6 For examples of police departments with websites offering crime analysis or mapping tools, go to www.ojp.usdoj.gov/cmrc/weblinks/welco me.html 3.3. Attitudinal Data Perceptions of students, teachers, and other school staff can also contribute to an increased understanding of the nature and extent of school safety issues, and MCPS is considering instituting, on a regular basis, school safety surveys. Surveys can answer questions that analysis of school incident data cannot: . Safety concerns. Surveys can directly answer questions regarding what safety issues concern students and staff the most and the seriousness of specific safety issues. Just because an incident occurs frequently (which would be noted in an analysis of incident data) does not mean that it causes great concern among students and staff. Similarly, infrequently occurring incidents can still be the cause of significant concern. Whatever the case may be, there is great value in understanding the perceptions that exist. . Unreported incidents. Surveys can also be used to develop estimates of victimization levels and account for unreported incidents. Two options for conducting these surveys are: . School-based surveys, the primary objective of which is to provide information on school safety at a particular school. In this case, district staff could design and test a survey instrument and then make it available to schools, where implementation of the survey would be at the discretion of each principal. . District-wide surveys, in contrast, could provide information on school safety across the entire district. In either case, sampling procedures could be used so that it would not be necessary to survey all students and staff. For example, in order to draw conclusions about overall safety levels at a high school with 2,000 students, a sample size of roughly 200 to 300 would probably be sufficient. Key implementation steps, which are familiar to MCPS research and evaluation staff that conduct other surveys, would be those associated with most survey projects: . Survey design. MCPS administrators would identify what exactly they wanted to learn from the surveys and then formulate and pilot test questions that meet those objectives. As indicated in Section 2, a number of different school safety surveys are in use across the country, which can be used as a starting point in the design process. The appendix contains an illustrative school safety survey. . Develop sampling plan. The sampling plan will depend, in part, on the questions being asked and whether they address issues that span all students and staff or deal with a specific subpopulation (e.g., high school girls). Once the target audience has been identified, those selected to receive the survey should be representative of the target universe based on important characteristics, such as age/grade, gender, academic achievement level, residential neighborhood, and race. If not, statistical controls can be used to adjust for differences in the sample and target populations. . Implementation. The decision here, as noted above, is whether the school district implements the surveys or whether implementation is left to the discretion of each principal. Appendix Differences Between Incident-Based and Student-Based Systems The primary initiative under consideration at MCPS discussed in Section 3 is a comprehensive district-wide incident-based system. There are important, but perhaps subtle, differences between incident-based systems and student-based systems. Three key differences involve: . When does the incident get documented? With incident-based systems, the incident is documented when it is reported to school administrators; with student-based systems, the incident is documented when (if ever) the alleged perpetrator is identified and taken to administrator's office. . What type of information is documented? Incident-based systems record (1) basic facts about the incident (e.g., what happened, where did it happen, and when did it happen), (2) information about who was involved in the incident, including perpetrators, victims, witnesses, and suspects, and (3) information about what actions were taken against perpetrators. Student-based systems record information pertaining to a particular student (e.g., when and why was s/he referred and what action was taken against the student). Importantly, in student-based systems, there is no direct link to other students involved in the incident. Another way to think about this is in terms of what corresponding paper forms would look like: . A paper incident form is divided into two sections. The top section captures basic facts about the incident–what happened, where did it happen, and when did it happen. The bottom section captures information about all the different persons involved in the incident (i.e., there is one subsection for each person involved in the incident). . A paper student referral form has only one section, which captures information about a specific person involved in the incident. . What follow-up questions can be asked to understand the scope of the problem? Incident-based systems can answer questions about both incidents and students involved in the incidents, whereas student-based referral systems, because there is no direct link between students involved in the same incident, can only answer questions about students. In other words, incident-based systems allow school administrators to identify problem areas (e.g., a specific hallway, specific times of the day) as well as problem students. The following scenarios illustrate these differences: Scenario 1 A security team member breaks up a fight involving two students and the students are sent immediately to the principal's office. What gets recorded Incident-Based System: Information about the incident (e.g., where and when it happened) - Information about the two students involved in the incident. Both are linked to the incident information. Student-Based System: Information about the first student and, separately, information about the second student. The two records are not linked. General types of related questions that can be answered at the end of the year Incident-Based System: . The number of fights . Characteristics about students involved in fights . Characteristics about where and when fights occurred Student-Based System: . Characteristics about students involved in fights Scenario 2 A teacher enters her classroom and discovers three windows have been broken. A suspect is never identified. Incident-Based System Student-Based System What gets recorded Incident-Based System: . Information about the incident (e.g., where and when it happened) Student-Based System: . Nothing General types of related questions that can be answered at the end of the year Incident-Based System: . The number of vandalism incidents . Characteristics about where and when acts of vandalism occurred Student-Based System: . Nothing Scenario 3 A student tells a school administrator that she was sexually harassed but is afraid to identify the students who harassed her. What gets recorded Incident-Based System: . Information about the incident (e.g., where and when it happened) . Information about the student who was victimized Student-Based System . Nothing until the alleged perpetrators are identified General types of related questions that can be answered at the end of the year Incident-Based System: . The number of sexual harassment incidents . Characteristics of students who engage in sexual harassment . Characteristics of students who sexually harassed Student-Based System: . Characteristics about students involved in fights Finally, another method of distinguishing incident-based and student- based systems is to examine a few of the specific data elements that could be captured in these systems: Incident-Based System Student-Based System Incident number (unique identifier) Referral number (unique identifier) Reported by Referred by Incident type Incident type (referral reason) Incident date and time Incident date and time Incident location Incident location General description of incident General description of incident Investigator Investigator For each person involved in the incident: .Person's Name .Student's Name .Identifying Information .Identifying Information (e.g., student ID#) (e.g., student ID#) .How involved (e.g., perpetrator, victim) .Action taken (e.g., suspension) .Action taken (e.g., suspension) Illustrative School Safety Survey The survey displayed in this appendix is included in the "COPS In Schools: Keeping Our Kids Safe" training manual that is distributed at COPS In Schools conferences sponsored by the Office of Community Oriented Policing Services (COPS Office). Chapter 3 ISTEP Prostitution Problem Solving Phase II Case Studies Final Report January 2003 Prepared for Office of Community Oriented Policing Services (COPS) Program/Policy Support and Evaluation Division 1100 Vermont Avenue, NW, Washington, D.C. 20530 Prepared by Vincent Webb Scott Decker Abt Associates Inc. 55 Wheeler Street Cambridge, MA 02138 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 1.1. ISTEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 96 1.2. Site Background . . . . . . . . . . . . . . . . . . . . . . . . . .98 1.3. Community Oriented Policing in the Phoenix Police Department. . . .99 1.4. Information Technology in Support of Community Oriented Policing .100 2. Problem Solving Process . . . . . . . . . . . . . . . . . . . . . . 101 2.1. Prostitution as Problem for Central City and For PPD . . . . . . .101 2.2. The Problem Solving Response in Central City Precinct . . . . . . 103 2.3. The Use of Information Technology in the Central City Prostitution Reduction Program . . . . . . . . . . . . . . . . . .105 2.4. The Central City Precinct Prostitution Problem Analysis Revisited. . . . . . . . . . . . . . . . . . . . . . . . . . .107 3. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 3.1. The Central City Prostitution Reduction Program in the Context of ISTEP Principles. . . . . . . . . . . . . . . . . . .111 3.2. Lessons Learned and Recommendations for Others.. . . . . . . . . .116 1. Introduction This report is one of several produced for the Information Systems Technology Enhancement Project (ISTEP), a project funded by the Office of Community Oriented Policing Services (COPS Office). The overall goal of the ISTEP project is to develop written documentation, software systems, and procedures that will increase the utilization of information and information technology in police departments, particularly regarding the implementation of community- and problem-oriented policing. This particular report describes the use of information systems technology in police problem solving to address street prostitution. This crime is a persistent problem in many of America's communities and one that has been fairly resilient to traditional police approaches aimed at its reduction. Although street prostitution is only one type of prostitution and probably represents less than one-fourth of all prostitution, it is a significant problem that requires police attention for several reasons. Street prostitution is a public health problem due to its role in spreading sexually transmitted diseases. Street prostitution is at odds with community values and moral standards and can be offensive to residents and workers in or near areas in which street prostitution takes place. Street prostitution poses a threat to the commercial and economic viability of neighborhoods by making neighborhoods undesirable places to live, work, transact legitimate business, or invest. According to some police practitioners and scholars, street prostitution operates much like street drug sales as part of the "Broken Windows" dynamic of disorder that leads to more serious forms of crime. Clients of prostitutes are especially vulnerable to assault and robbery given their participation in an illicit cashed-based transaction, and prostitutes are vulnerable to assault and abuse from their clients. Additionally, the street-level sale and consumption of drugs is often associated with street prostitution. Although the problem of street prostitution poses a major challenge to police agencies, relatively little has been written about police problem solving aimed at its reduction. The case study presented here examines the prostitution problem-solving efforts of a high crime police precinct in Phoenix, Arizona. The Phoenix Police Department (PPD) was selected for participation as a Phase II ISTEP project site due to its commitment to community-oriented policing, its recent efforts to expand and experiment with problem solving, and its increased investment in and use of information technology in support of strategic community-oriented policing (COP) initiatives. This investment is especially evident in the development of PPD's crime analysis capacity. Prostitution was selected for this case study after a series of preliminary conversations were held with PPD research and planning staff and with Precinct Commanders and Area Managers tasked with designing and implementing strategies for achieving PDD crime reduction goals. 1 All ISTEP reports are available on the COPS Office website at www.cops.usdoj.gov Through these interviews, one high crime precinct (Central City Precinct) was selected for study due to its emphasis on problem-solving and the use of technology as part of problem solving to reduce street prostitution along a major traffic corridor within the precinct. Precinct personnel had designed a multi-stage program targeting prostitution along a 30-block stretch of Van Buren Road, a stretch that produced nearly 1200 arrests for prostitution in 1999 and 900 in 2000. The case study presented here is based on information from a variety of sources. Three site visits conducted in late 2000 and during the first quarter of 2001 were used to identify the problem-solving application for study and to identify data sources, uses, and problems. Interviews were conducted with a variety of PPD personnel, including staff from Research and Planning, Crime Analysis, and Records Bureau, as well as Precinct Commanders and Area Managers. Once the Central City Precinct was selected for more in-depth study, much of the site visit activity involved interviewing Central City problem solvers to codify their problem solving approach as well as to identify the information technology (IT) used in problem solving. Problem solving is well-documented in Central City Precinct and that documentation was readily available to the study team. The site visits also involved working with the supervisor of the Crime Analysis Unit to determine data availability and analytic capacity in support of problem solving in Central City and other precincts. This remainder of this report is organized as follows: . The remainder of Section 1 provides background information on the ISTEP Project (Section 1.1) and Phoenix (Section 1.2), including its use of community policing (Section 1.3) and information technology (Section 1.4). . Section 2 describes the problem solving approach used in Phoenix to combat street prostitution and how this approach utilized information technology. . Section 3 presents some conclusions and lessons learned for other jurisdictions. 1.1. ISTEP Overview With the goal of increasing the utilization of information and information technology in police departments implementing community policing, the ISTEP project team initially developed a conceptual framework document that describes how community policing imposes different information needs on law enforcement.1 In particular, the framework identifies seven key information domains that should be developed if police departments want to implement community policing effectively. The seven domains are: . community interface . inter-organizational linkages . work-group facilitation . environmental scanning . problem orientation . area accountability . strategic management Subsequent project work proceeded in two phases. The goal of the Phase I was to learn about police department accomplishments in community policing, technology development, and the seven information domains. Phase I was also designed to gain an understanding of the internal and external processes involved in implementing information technology in support of community policing. Five police departments–Tempe, Arizona; San Diego, California; Hartford, Connecticut; Reno, Nevada; and Charlotte-Mecklenberg, North Carolina–were selected to participate in Phase I of the project. These departments were selected because of their successes and experience relating to information technology and community policing implementation. The Phase I departments provided the ISTEP team with open access to their operations and made command and line level staff fully available for interviews, observations, and questions. Several site visits were made to each city to gather information on community policing practices, technology planning, and technology implementation. Members of the ISTEP team attended numerous meetings, participated in technology training, conducted ridealongs, and examined specific hardware and software at each site. Individual case study reports were prepared for each of the participating departments and submitted to the COPS Office. A Phase I cross-site report synthesizes the findings of the individual case studies. It does so by addressing nine specific questions, as a means of helping other departments involved in community policing to learn and understand the processes necessary for IT development. The nine questions are: . Is technology driving community policing or is community policing driving technology? . Is there integration with strategic planning? . Is the process of designing and acquiring technology "bottom up" or "top down"? . What is the level of external support for these processes, and what linkages with other information and intervention systems are present? . What is the mix of "in-house" versus "out-of-house" expertise shaping technology planning and acquisition? . Who is responsible for integration? . How do these new systems and/or processes actually affect the quality and impact of police work, and how do we know that such changes have occurred? . How does the process of assessment continue? . How is such change financially supported? In Phase II of the project, the ISTEP team worked with three departments –Phoenix, Arizona; Reno, Nevada; and Arlington, Virginia–that have demonstrated a strong commitment to community policing but are in the early stages of IT planning. In Phase II, the ISTEP team worked closely with the departments to develop an information technology design that will support community- and problem-oriented policing. The Phoenix and Reno case studies focus on specific problems–prostitution and auto theft, respectively–while the Arlington case study describes the design and development of a COMPSTAT information tool that can support community policing. 1.2. Site Background Rapid social and demographic change has made Phoenix, Arizona, one of the country's largest cities situated in one of the largest metropolitan areas. The population of Phoenix grew by approximately 34 percent in one decade, from 943,403 in 1990 to 1,321,045 in 2000, while Maricopa County, which encompasses Phoenix and the bulk of the metropolitan area, grew by nearly 45 percent, from 2,122,101 in 1990 to 3,072,149 in 2000. Phoenix experienced considerable growth in its Latino population over the past decade, as did the State of Arizona where the Latino population increased by 88 percent between 1990 and 2000. About one in four Phoenix residents is Hispanic. In general, Phoenix experienced the same crime trends as the rest of the nation with the end of the 1990s seeing lower Part I crime rates compared to the decade's beginning. Violent crime peaked in the mid-1990s, and Phoenix has experienced a dramatic reduction in property crime in the past few years. In 2000, the Part I crime index rate for Phoenix was 7,514.3 per 100,000, down from 9,805.2 in 1996. The Part I violent crime rate was 749.9 in 2000, down from 947.3 in 1996, and the Part I property crime rate in 2000 was 7,514.3 per 100,000, down from 8,857.9 per 100,000 in 1996. The Phoenix Police Department employs 2,607 officers, or about two officers per every 1000 citizens. The department received 863,489 calls for service in 2000. Geographically, Phoenix is a large city–the Phoenix Police Department is responsible for an area of 472.63 square miles. Patrol services are provided through seven precincts that are organized primarily, but not entirely, on the basis of crime levels. This means that geographically the precincts range from being fairly compact to very large. In addition to precincts, the PPD has patrol services organized into two large delivery areas referred to as the North and South Patrol Divisions. PPD Headquarters remains in the downtown area and is the hub for administrative services, investigations, research and planning, records, the bureau responsible for information technology, and upper- echelon management. In recent years the Phoenix Police Department has engaged in a continuous strategic planning process that results in a two-year "Phoenix Policing Plan." The elaborate planning process used involves a major community survey, including surveys of PPD employees as well as other information sources, to identify problems and to set a small number of goals. One goal is crime suppression, which translates into reducing Part I crimes. 1.3. Community Oriented Policing in the Phoenix Police Department Community oriented policing (COP) has been part of the Phoenix Police Department's operating philosophy for several years; however, the past few years have witnessed the development of numerous strategies for enhancing COP. COP is visible in several operational features, with the core of COP activities located in the PPD precincts. Precincts have Community Action Officers (CAOs) with specific responsibilities for serving as liaisons between the local community and the precinct. CAOs are active participants in community meetings and work to bring precinct resources to bear on local problems. Precincts also have Neighborhood Enforcement Teams (NET), which are squads of four officers each supervised by a sergeant, who take on special tasks within the precinct assigned by an Area Manager. The Area Manager concept is relatively new in PPD, and reflects an increased emphasis on area accountability. In 1997 PPD sub-divided each precinct into four smaller geographic areas and designated a Lieutenant as Area Manager for each. The Area Manager is responsible for patrol operations within the area and has CAO's and NET officers available for special projects. Area Managers report to the precinct Commander. Neighborhood problem identification and problem solving are largely the responsibility of Area Managers, although Commanders play an important role in setting priorities and allocating resources to support these efforts. The Central City Precinct, which is the principal site of this case study, is the smallest PPD precinct geographically, but is one of the two PPD precincts with very high crime rates. This relatively compact precinct encompasses a good part of the downtown core as well as some of the city's gentrified historic residential districts. Central City has a staff of approximately 275 personnel, of which 220 are sworn. Although not unique to Central City, the area is one of the principal locations of street prostitution in Phoenix. The area is also known for its street drug markets and high levels of aggravated assault. Central City Precinct is often thought of as the precinct where new developments within PPD are piloted. The precinct places a great deal of emphasis on formal problem solving using the SARA (Scanning, Analysis, Response, and Assessment) model. Recently, Central City began to experiment with the permanent assignment of officers to a beat to increase community interface. 1.4. Information Technology in Support of Community Oriented Policing Information Technology in the Phoenix Police Department has been in the process of continuous development over the past several years, although the pace has increased considerably in the past few years. The department's Computer Aided Dispatch and Records Management System, known as the Police Automated Computer Entry system (PACE), is a fairly robust information system that contains an extensive list of information elements. Although the system serves the department well, data quality is a significant problem that the PPD is currently addressing. Much of the problem is attributed to incident reports with data fields (e.g. checkboxes, codes) that are not completed. Currently PPD has a Quality Control Committee hard at work to remedy this problem. One IT area that has seen rapid development in PPD during the past few years has been in the department's crime analysis capacity. The Crime Analysis Unit is within the Research and Planning Bureau and is responsible for a variety of duties related to Administrative, Strategic, and Tactical Crime Analysis. Crime Analysis has been bolstered through increased investment in both human resources and in technology. On the human resource side, the number of analysts has been increased and the department has started to employ research aides. The unit has also become increasingly civilianized. Several IT developments have strengthened the unit's functionality. For example, in 1998 PPD was largely without capacity to do GIS crime mapping and was unable to readily produce basic pin maps. The 1999-2001 Policing Plan called for a number of enhancements related to its technology goal, including improving the CAD/RMS or PACE system. The department acquired the CrimeView crime analysis software package with the goal being to empower the precincts to directly access and map crime data. All precincts now have that capacity, and Crime Analysis provides them with support and training to do mapping and analysis. 2. Problem Solving Process 2.1. Prostitution as Problem for Central City and For PPD The recent focus on prostitution in the Central City Precinct stems from several forces. First, East Van Buren Road, especially the area running from 7thStreet to 64thStreet has a lengthy history as Phoenix's "Red Light District." The persistent problem and relatively ineffectual reactionary enforcement programs such as "reverse sting" operations, along with complaints from neighborhood and business associations, led Central City to begin to focus on "core issues" that staff believed to be responsible for the problem. Street prostitution is a difficult crime to measure since, unlike many other crimes, it is unlikely to result in a call for police service that leads to an incident report. The known level of prostitution is largely a function of proactive enforcement efforts that result in arrests, which depends on the level of enforcement activities. Central City officers made 920 prostitution arrests in 1998, 835 arrests in 1999, and 1065 in 2000. Central City estimated that the average daily number of prostitutes working the East Van Buren Road corridor was about 45. Central City personnel attribute the following characteristics to the Van Buren prostitution problem, often referred to as the "301 Problem," since 301 is the radio code for prostitution: . Many of the prostitutes work a circuit moving from one town to the next, based on enforcement and market opportunities. . Many johns are Mexican nationals, who may be more vulnerable to other forms of victimization. . The cash transaction nature of prostitution provides a ripe setting for armed robbery. . Prostitutes are frequently assault victims. . Prostitution is linked to other crimes such as assault, drug dealing, and to disorder such as public drinking. . Prostitution is linked to the location where it occurs including such factors as type of business, lighting, and traffic flow . The location of prostitution is specialized by sex act with specific acts being marketed in specific locations. In January 2000, one Central City Area Manager who had been heavily involved in prostitution enforcement efforts proposed adopting a major problem-solving approach addressing the area's prostitution using a SARA model. That effort began with a scanning phase that, in addition to those characteristics of the problem noted above, led to the following conclusions: . Local prostitutes, as well as out of city and out of state professionals, traveled in groups along with their pimps. . Phoenix was a favored stop for prostitutes because it has a relatively small enforcement unit. . The Van Buren problem area had a number of low rent motels/hotels. . Low rent motels/hotels had hourly rates. . Prosecutors turned down about 40 percent of the arrests. . The bonds on prostitutes set by the court were too low and did not serve as deterrent since the earnings of prostitutes could easily offset the cost of the bonds. . Patrol officers were apathetic and gave enforcement low priority. As was previously noted, the Phoenix Police Department's strategic plan includes a crime reduction goal. The goal in the 1999-2001 plan was to reduce violent and property crimes and violent crime by 10-20 percent. Prostitution, not being a Part I offense, was not singled out for action in that plan. Different precincts focus on different crimes depending on their level. Some precincts are focusing on auto theft and others on burglary. Violent crime is a major problem in Central City Precinct, so in June of 2000, the department targeted Aggravated Assault for suppression in Central City. The Crime Analysis Unit did an extensive aggregate analysis of the problem looking at such things as time of day, day of week, weapons used, premise type, age and race of victims and suspects. Crime analysis also identified aggravated assault hotspots in Central City, mapped several features of the problem, and created several maps relating aggravated assaults, prostitution, and drug offenses. Instead of directly addressing the problem of aggravated assault, Central City continued and expanded its emphasis on the prostitution problem as well as drug offenses. Precinct officials indicated they believed that a reduction in prostitution and drug offenses would produce a concomitant reduction in aggravated assault and other forms of violent crime. They articulated a "Broken Windows' view of the problem, indicating the prostitution and drug offenses were closely associated with neighborhood deterioration and criminogenic structures and businesses, such as cheap hotels and exotic dance clubs, with the larger effect being serious violent crime. The analysis phase of the SARA problem-solving process used by Central City was unable to take full advantage of the growing capacity of the Crime Analysis Unit to analyze and map CAD/RMS and other data relevant to the prostitution. That capacity was not yet fully developed when Central City began the prostitution problem solving process. Instead, Central City problem solvers relied on experience with past enforcement plans, reviews of general crime statistics and prostitution arrest statistics, general data on calls for service, and surveys of local businesses. Few data were directly available that would have enabled them to test some of their assumptions about prostitution or about its connection with serious crime. As a result, the response to the problem was developed without extensive data sources or analysis. 2.2. The Problem Solving Response in Central City Precinct As noted above, in January 2000 a Central City Area Manager implemented a major problem-solving initiative that led to what is referred to as the Van Buren Prostitution Action Plan. That plan was premised on several largely untested assumptions about the nature of the prostitution problem and its connection with other types of crime and disorder. The resulting plan has several components, some of which were aimed at enhancing traditional enforcement practices, but several that constituted new ways of addressing the problem. The plan focused on the following six dimensions of the Van Buren prostitution problem: . An abatement program to end prostitution and other criminal activity on hotel and motel properties. . Development of and passage of an ordinance to prohibit hourly or partial day rentals of hotel and motel rooms. . Development of an ordinance to prohibit customer cruising on Van Buren and adjacent streets. . Development of an ordinance to prohibit open loitering by prostitutes and pimps. . Strengthening relationships with the City Prosecutor's Office to try to improve consistency in filing charges, plea-bargaining, and punishment in prostitution cases. . Strengthening a relationship with the City of Phoenix Municipal Court to improve handling cases involving travel restrictions of arrested prostitutes. As was previously noted, Central City prostitution plan was largely developed with limited benefit of data-driven analysis. The analysis that was done by Central City problem solvers included a review of past enforcement efforts, a review of overall crime statistics and calls for service in the precinct, and a survey of businesses in the area to gauge the extent of prostitution and related activity on or near the premises. In regard to calls for service analysis, Central City problem solvers identified the "Top 25 Locations" and characterized these locations by type (motel, apartment, etc.) and precinct beat. In several cases this information was used to target businesses such as motels for participation in the abatement program. In addition, the Crime Analysis Unit provided simple pin maps of the location of "301" (prostitution) arrests. An analysis of the outcomes of arrests was also conducted to develop a clearer picture of the legal processing of prostitutes. The analysis phase also examined officer apathy, the use of travel restrictions on prostitution as an enforcement tool, and an analysis of the pricing structure of prostitution in the area. Much of the analysis underlying the action plan that was eventually developed consisted of in-depth examination of existing ordinances in order to seek modifications that would result in more effective enforcement. For example, in an effort to address the problem of cheap hotels and motels with hourly and partial daily rates, Central City problem solvers carefully examined existing ordinances that regulated Sexually Oriented Businesses (SOBs) to see if enforcement actions could be taken against such hotels and motels for violating SOB ordinances. Problem solvers also reviewed zoning codes to see if they afforded an opportunity to take enforcement actions against such properties. The overall response developed at Central City had included several components, including a Prostitution Customer Apprehension Program, which is a periodic intensive enforcement effort that focuses on johns, and expanded use of the abatement program that notifies business owners that they are responsible for criminal activity taking place on their property and points out their responsibility to take corrective action. One of the more creative components of the overall response in Central City that makes use of Information Technology is the On-Site Prostitution Identification Systems (OSPIS) described in detail in the next section. That system was developed to facilitate enforcement of ordinances prohibiting prostitutes at certain locations. The system was also designed to make manifesting ordinances easier to enforce, since it helps officers make positive identification of prostitutes. 2.3. The Use of Information Technology in the Central City Prostitution Reduction Program Part of the problem with prostitution enforcement identified by Central City problem solvers was a need for patrol officers to make immediate on- the-street positive identification of individuals who appeared to be manifesting for prostitution. Such immediate identification should result in better arrests, in more consistent court actions, and should facilitate the enforcement of court-ordered travel and other restrictions. A system that resulted in quality arrests with reasonable certainty of successful prosecution and meaningful penalties could help to overcome the problem of officer apathy identified as part of the analysis of the Van Buren prostitution problem. To achieve the goal of positive identification, Central City developed a database and user system known as the On Site Prostitution Identification System or OSPIS. The origin of OSPIS can be traced back to the efforts of a Central City patrol officer who became a crusader against prostitution on Van Buren. The officer, who has been described as having an exceptional prostitution arrest record, put together a "301 Book" that documented his contacts with prostitutes using reports and Polaroid photographs. Three other Central City patrol squads that focused on prostitution enforcement when not responding to radio calls also put together prostitution photo books. OSPIS was proposed as a prostitution identification system that could be shared by officers, thus avoiding the problem of duplication of effort. Patterned after the Phoenix Police Department gang tracking system, OSPIS is a stand-alone information system that uses digital cameras, laptop computers, a dedicated desktop PC with re-writeable CD-ROM Drives, scanners, color printers, and most importantly, an Access database developed and maintained by Central City personnel. Two principal information sources are used to populate the OSPIS database: a data form completed by patrol officers once they contact someone suspected of prostituting, and a digital photograph of the suspects. The data form is known as a Prostitution Identification Program (PIP) Worksheet. This worksheet is not a substitute for a Field Identification (FI) report that is eventually entered in the PPD PACE System. Completing the PIP Worksheet requires recording information on several variables related to the incident, such as identifying characteristics of the suspect or arrestees, and providing information on johns, vehicles involved, and noting other observations made by the officer. The worksheet also has space for narrative and checkboxes indicating that a digital photo was taken, that information from the form was entered in the OSPIS database (sometimes referred to as the 301 database), and whether or not an FI was entered into the PACE System. The information recorded on the worksheet is summarized below. . About the Incident: Date, Time of Day, Nature of Incident, Location. . About the Suspect/Arrestee: Name, Date of Birth, Address, Drivers License Number and State of Issuance, Race, Gender, Weight, Height, Eyes, Hair, Social Security Number, Description of Clothing, Scars and Tattoos, Nicknames and Aliases. Body Build, Hair Length, Hair Style, Facial Hair Characteristics, Complexion, Jewelry, Weapons Carried, Admitted 301, Rates, Name of Pimp, Court Restrictions, Associates, Location for Tricks, Supporting (Drug habit, children, or pimp), Travel Area (circuit, local, transient). . About the "Date:" John's Name, Date of Birth, Social Security Number, Address, Race, Height Weight, Hair Color, Eye Color. . About the Vehicles Involved: Plate Number, State, Year, Vehicle Year, Style, Make, Model, Color, Vehicle Identification Number, Special Features/Characteristics. . About Observed Characteristics (Checkboxes): Dressed to Draw Attention, Loitering in an area know for prostitution, Dress not consistent with others in area, Gave false name, Hotel keys, Carrying empty or near empty purse, Priors for 301, Exposing body parts, Admitted to working/dating, Caught in carnal act, No identification, Frequent use of taxi cabs, Frequent visits to convenience stores, Traveling pattern inconsistent with destination, Condoms/lubricants, Using verbiage common to prostitutes, verbally yelling/whistling to vehicles, Contact with males only. OSPIS involves officers completing the PIPs form once they have made a field stop of someone they suspect is a "301," prostitute. Officers complete the worksheet and take a digital photo of the suspect. The worksheet and photo are turned into the officer tasked with inputting the data and digital photo as well as maintaining and updating the OSPIS or 301 database. The database, including digital photos, is written onto CD's that are placed in laptops and issued to officers on the squads working the Van Buren area. The laptops enable officers to make queries based on the information fields in the Access database, as well as visual comparison of suspects on the street with digital photos in the database. For example, an officer might observe someone who appears to be manifesting, and after making field contact, notes the tattoo "Rosie" on the suspect. The database could be searched for all women with the tattoo "Rosie," and a list of names and photos and could be generated making it possible to make identification. The officer would immediately be aware of any court imposed travel restrictions placed on the suspect, and would be able to determine if those restrictions had been violated. The database would also track the number and location of officer contacts, which could be useful in seeking stiffer penalties. This information could also be useful in examining travel pattern and displacement effect due to arrests or special operations. Once Central City problem solvers conceptualized OSPIS, they needed to find a way to fund its development. They applied for and successfully received funding through the Court Award Funds program, although the initial award was substantially less than what was originally requested. Interestingly, the funding request for OSPIS was premised on prostitution affecting UCR Part I crime statistics including homicide, aggravated assault, sexual assault, and robbery. Part of the justification for the system was its potential for helping the PPD achieve citywide crime suppression goals. OSPIS started with the equipment and software necessary to maintain the database, but the funding was only sufficient to acquire two laptops. Officers patrolling the Van Buren area check out these laptops. Officers without laptops can call the unit that has the laptop should one be needed. The OSPIS system was fully implemented in the first quarter of 2001. One of the first challenges faced in implementing and updating the system was to get officers to complete the PIPs so that the database could be populated. A variety of strategies have been used, including public commendations for officers who complete and turn in PIPs. Information for approximately 400 field-contacted "301s" had been entered into the system during the first few months of its operation. A Central City officer works overtime to maintain OSPIS. The goal of Central City problem solvers is to expand the system to include other precincts and provide training in its use. Ideally, they would like to be able to access OSPIS information on "301s" working other precincts. This would help with early identification of unknown "301s" moving into the Central City area. It would help facilitate achieving the goals of better arrests and more consistent sentencing by providing officers and court officials with more complete information on the history and nature of police contacts with an arrestee. 2.4. The Central City Precinct Prostitution Problem Analysis Revisited As a problem-solving response, the OSPIS system and other components of Central City's Van Buren Prostitution Action Plan are creative strategies for addressing a persistent problem impacting the quality of life of citizens who live and work in the neighborhoods along the East Van Buren corridor as well as those who travel through the area. The effectiveness of the program has yet to be thoroughly assessed, although a pre-OSPIS assessment conducted by Central City staff indicated a fairly dramatic decrease in the number of prostitutes working the streets. Observation by officers indicated a drop from a daily average of 35-50 prostitutes on the streets in 1998 to an average of 5-15 daily during the first quarter of 2000. Data availability and the information technology available for problem analysis limited the original analysis phase of the SARA model used in Central City. However, this situation has improved tremendously and Central City and the Phoenix Police Department are in a much better position to do in-depth analysis of the prostitution problem, and the nature of its connection with Part I crimes. Future prostitution problem-solving iterations should consider incorporating into or expanding the following items in the analysis phase in order to more thoroughly test working assumptions about the problem and to identify additional opportunities for developing effective responses. To examine these issues, we identify several assumptions regarding the prostitution problem and the data that can be brought to bear in understanding it and responding in ways that support community and problem oriented policing. . Trends in numbers over time. One working assumption impacting prostitution enforcement is that it is related to special events, such as professional sporting events and trade shows that attract large numbers of visitors to Phoenix and the Van Buren area. This assumption could be examined by reviewing time series of prostitution arrests and field contacts over time to detect increases and decreases that coincide with the scheduling of such events. This analysis would also help verify assumptions about seasonal patterns in street prostitution activity. . Patterns in time of day or day of week. A thorough analysis of "301" arrest records and FIs to validate assumptions about peak times and days of week for prostitution would be useful information for verifying existing beliefs about such patterns. This information could also help guide resource allocation decisions . Data from the OSPIS database on day and time of contact should also be used in such an analysis. . Relationship between victim and offender. One analysis goal of the prostitution problem is to systematically document the pattern of interaction that leads to the transaction. How do prostitutes get to the location of the interaction? How do johns get there? Linking and mapping last known addresses of prostitutes and their customers would help to answer these questions. Additionally, this analysis could help to determine the connection between tourist-attracting events and the level of prostitution activity. . Circumstances of prostitution. A thorough analysis of the relationship between prostitution and other crimes such as assault, drug dealing, public disorder (e.g., public drinking), and robbery should be conducted to assess the validity of the working assumption about their interconnection. Is there evidence of temporal ordering of these crimes that suggests causal ordering, or is any temporal or areal correlation spurious with the connection being the result of a relationship with non-crime factors. The Crime Analysis Unit has already done extensive mapping of data for a six- month period that shows considerable overlap in the location of prostitution and assault hotspots. This analysis should be extended to examine the relationship of prostitution with other crimes. Analysis of incident data should be conducted to determine if increasing prostitution enforcement produces decreases in UCR Part I offenses. This analysis would help determine if prostitution enforcement is an avenue for meeting PPD Part I crime suppression goals, such as the reduction of aggravated assault. . Characteristics of location. Systematically documenting criminogenic features of the environment where prostitution takes place is another analysis that would be useful. Here the experience of officers working in the area is particularly useful, but such information is seldom collected and organized systematically. Central City has already targeted cheap hotels through an abatement program which gets at an important part of the problem, but an analysis of a broader set of potential CPTED issues could help to inform the development of new responses to the problem. Land use data could be used to more thoroughly describe the environmental context of the Van Buren prostitution problem by characterizing critical residential, commercial, and public-use features of area neighborhoods. Surveillability issues in the areas where prostitution takes place related to lighting and barriers obstructing the view of patrol officers and residents could also be inventoried. Licensing data is another source of information to analyze the relation of the event of prostitution to the places where prostitution takes place. . Characteristics of clients. Analysis of the characteristics of prostitution clients could help verify existing beliefs about them, and such information could serve as foundation for new responses to the problem. PACE incident and FI data as well as data from OSPIS could be used to capture the repeat participation of customers. How pervasive are repeat customers? Can effective responses be developed that target repeat customers? Are the customers involved in other forms of criminal behavior as offenders or as victims? This analysis would help validate some of the current working assumptions about customers. For example, many assume that a disproportionate number are Mexican nationals because Mexican nationals tend to operate in a cash economy, and that they are both attractive customers and at the same time vulnerable to robbery. . Characteristics of prostitutes. Systematic analysis of the characteristics of prostitutes using incident, FI records data, criminal history data (NCIC), and OSPIS could be used to assess a number of working assumptions about the nature of prostitution in the Van Buren area, as well as the connections between prostitution and Part I crimes. One analysis goal would be to examine the nature of any network of relationships among prostitutes by looking at known associates and linking them to common addresses. An analysis of addresses and arrest warrant histories over time could also be used to gauge the existence of intra and interstate prostitution circuits. Analysis of the characteristics of prostitutes could also help develop a better understanding of the nature of its link with other crimes. Criminal history records could be used to determine if prostitutes are specialists or if they are cafeteria style offenders involved in a variety of offenses. If prostitution and assault are linked, then analysis should show a decline in assaults after prostitution sweeps, since prostitutes should have involvement in assault as victims and offenders. This should also be true of drug cases if prostitution and drug activity are linked. Finally, analysis should examine the linkage of prostitution with other crimes by looking for patterns of multiple charges including drugs, prostitution, and assault. Conducting the analyses described above requires using data from a variety of sources including the traditional sources of crime data such as incident and FI data extracted from the PPD PACE system, and also other sources of police and non-police data as well. For example, although OSPIS was developed largely as an enforcement tool, it contains a great deal of information that can support analysis. It is another source of information on critical analysis variables such as suspect address, associates, and incident location. Licensing and land use databases are important sources of information for analysis that PPD has direct access to, and that Central City can access directly or through the Crime Analysis Unit. A recent innovation under development at PPD is a shared database that links police and Maricopa County Probation data. That database contains extensive information on probationer characteristics and includes updated addresses for residence and for place of employment plus information on probation restrictions. Central City recently became one of two pilot precincts provided with direct access to that database through CrimeView. There are still other data sources that could enrich the analysis of the prostitution problem in Phoenix. Phoenix\Maricopa County is a site for the National Institute of Justice's Arrestee Drug Abuse Monitoring (ADAM) program, and each calendar quarter approximately 150 recently booked adult female arrestees are interviewed about drug use and drug markets and are asked to provide urine samples that are tested for common street drugs. Most of these are PPD arrestees and a substantial number of the bookings are for prostitution. Not only are ADAM data useful for examining the connection between prostitution, drugs, and crime, ADAM also provides a research platform where arrestees charged with prostitution could be queried about any of a number of topics related to understanding the problem or assessing the effectiveness of PPD\Central City responses. 3. Conclusions 3.1. The Central City Prostitution Reduction Program in the Context of ISTEP Principles As noted in Section 1.1, Phase I of the ISTEP project identified seven critical information domains that police departments must address for full implementation of community oriented policing (COP). The review of Central City Precinct efforts to address the East Van Buren prostitution problem provides an opportunity to examine the extent to which one police precinct, the PPD Central City Precinct, has been able to address these domains as it more fully engages in COP. . Community Interface. COP requires close working relationships between the police and community, with the community playing a larger role in public safety. Close working relationships require information sharing, from police to community and from community to police. Community interface is given high priority in Central City Precinct, and problem-solving efforts and special operations nearly always involve community groups. Commonly, preliminary problem identification takes place at community meetings. In the case of the prostitution problem, much of the impetus for an expanded focus on the problem was concern voiced by local business associations and the Garfield Neighborhood Association. Furthermore, that association worked hand-in-hand with Central City problem solvers to take advantage of a policy giving neighborhood associations standing as crime victims. They developed a program where volunteers wrote letters to presiding judges and attended court to offer input on cases involving prostitutes arrested or working in their neighborhood. Central City officials are careful to inform residents, via neighborhood associations, about pending sweeps such as Customer Apprehension Days, and to give them follow-up information and de-brief them after special operations. Most community interface in Central City involves face to face communication between citizens and police, however the PPD has made important strides in using their website to provide all residents with information on crime in their neighborhood. Furthermore, the strategic planning process used by the PPD involves the use of extensive community surveys and citizen advisory groups to help set and prioritize department goals. . Inter-organizational Linkages. Police partnerships with governmental, neighborhood groups, non-profit and private organizations are essential for successful community oriented policing. From an information systems perspective, police must have access to a variety of non-police information systems, and other organizations must have access to police information systems. Central City problem solvers are closely aligned with a variety of other governmental agencies and the approach used by Central City to address prostitution reflects genuine partnerships with the courts, probation, and private organizations. Typically, representatives from these entities are involved in all phases of the problem solving process. Central City problem solvers can access an array of non- police databases through the Crime Analysis Unit, which has direct access to a number of non-police databases that make up a data warehouse maintained by the City of Phoenix. Limited data is directly available on-site at the precinct such as information on streets and freeways, neighborhood associations, some census data, liquor and grocery stores, and schools and school districts. The use of these data sources was limited in the case of Central City prostitution problem solving efforts. . Workgroup Facilitation. An important feature of COP is its emphasis on shared responsibility and joint action for geographic areas and problems. Temporal boundaries across shifts are de- emphasized and the coordination of information across shifts and work groups is emphasized. Information systems that facilitate this coordination are highly desirable. Problem solving in Central City has placed increased emphasis on shared responsibility and joint action. Some problem solving is the responsibility of patrol supervisors and squads, but major problem-solving efforts involve teams comprised of patrol officers, Neighborhood Enforcement Team or NET officers, Community Action Officers, Area Managers, and the precinct Commander. Historically, information systems have not been designed with workgroup facilitation in mind, however recent IS developments have good potential to serve that need. The implementation of CrimeView provides all precinct shifts and personnel with beat-level and address- level crime information for the last 90 days of reported crimes, for the same 90 day period during the previous year, and for the most recent 90 days of field interrogations. The police-probation database also provides all Central City shifts and personnel with a variety of probationer data via CrimeView. In other words, a growing amount of information is available across shifts in Central City (and other PPD precincts), although cross-shift uses of that data are not necessarily well developed. At least one other PPD precinct (Maryvale) has designed an electronic bulletin board to support work-group facilitation, and other precincts are exploring the use of Web pages to do the same. The On-Site Prostitution Identification System was created explicitly with work-group facilitation in mind. That system provides common information across shifts by providing shared laptops containing the OSPIS database. . Environmental Scanning. COP requires a capacity for broad environmental scanning in order to identify problems and crime trends and changes in the larger environment including land-use patterns and community demographics. The capacity for environmental scanning has increased greatly in the PPD in recent years. Development in the department's Research and Planning Bureau, which hosts the Crime Analysis Unit, has greatly increased the department's ability to access data and to interpret it. These developments include the employment of highly skilled crime analysts, the acquisition of GIS crime mapping (ArcView\CrimeView), statistical analysis software (SPSS), and database\report software (Crystal Reports). Crime mapping and analysis capacity exists at each precinct and commanders and other precinct staff are in a much stronger position to use IS technology to support scanning efforts. Central City problem solvers had limited access to databases for scanning when they started to focus on the Van Buren prostitution problem. They relied heavily on the experiential-based knowledge of officers and supervisors working in the area. The selection of prostitution over other crimes was done in response to a growing concern about the problem voiced by the community and to the belief on the part of PPD and Central City problem solvers that a reduction in prostitution would produce a concomitant reduction in UCR Part I violent crimes. In other words, the identification of prostitution as a problem was based on limited use of relevant data, at least initially. For example, estimates of the level of prostitution activity relied on officer generated "nightly counts" of the number of prostitutes working the streets. The identification of officer apathy toward prostitution enforcement as a problem was based on conventional wisdom and experience, and not systematic survey data of officers' beliefs and practices. As was noted, Central City now has increased capacity through CrimeView and through dedicated research personnel (Research Aide) to use a variety of data sources in the environmental scanning process. . Problem Orientation. COP requires that information and analysis of information be oriented toward supporting officers and other police personnel in identifying and analyzing problems as well as aiding them in assessing the effectiveness of the responses that they implement. Much of the recent development of information systems in the PPD has been to re-orient existing information systems and to develop new information systems, to support the department's growing problem orientation. Problem solving has been a COP feature in PPD for several years, however the level of its development and use varies from one precinct to another. Central City Precinct is one of the precincts where the problem orientation is most well developed. A premium is placed on problem solving, and problem-solving efforts are well documented and shared with precinct personnel and various stakeholders using presentation software. It is evident that Central City problem solvers take advantage of best practices when developing responses. For example, the Van Buren Prostitution Plan was modeled in part after a program developed by the San Bernardino Police Department. Precinct personnel are active consumers (and producers as well) of information disseminated at the Police Executive Research Forum's annual Problem Oriented Policing Conference and similar forums. In addition, Internet access provides them the opportunity to explore a variety of best practices web sites. Unlike some police departments, PPD or Central City has not developed an IS capacity for tracking problem solving efforts that make it possible to share institutional knowledge across officers. . Area Accountability. A central feature of COP is area accountability, which requires that management structures and processes be connected to well-defined geographic areas. As a result, area commander and managers have a need for a broad range of information items pertaining to their geographic area of responsibility and on the resources available to them to achieve command area goals. The bottom line is accountability for what goes on in the command area, and commanders and their staffs need information that helps them meet the goals of their area command. Area accountability has been a major, if not the major force driving much of the crime analysis related IS development in PPD. A key feature of the overall management strategy in the department has been to make area commanders responsible for achieving crime suppression goals and objectives developed as part of the department's strategic plan. Phoenix Policing Plan goal achievement is linked to annual individual performance goals (PAP), which are the basis for performance review and the allocation of performance based salary increases. As a result, there is a strong demand for access to data, especially crime data, and this demand resulted in the acquisition of CrimeView and the development of its use at the precinct level. The Area Manager concept described earlier was another step in developing area accountability in PPD, and Areas managers now have access to CrimeView and are in a much stronger position to monitor crime trends. Central City has taken area accountability one step further and is the first precinct to experiment with the permanent assignment of individual patrol officers to a beat. The goal is much broader than area accountability: Central City is trying to maximize community interface by increasing officer knowledge of smaller areas and enhancing officer-citizen information exchange. Of course the ultimate goal of this approach is to achieve beat-level crime reductions that add up to meeting command area crime reduction goals. Central City has full CrimeView access to crime data for the last 90 days and for the same 90 days for the previous year as well as FI's for the most recent 90 days. This enables the precinct managers to monitor trends and develop a sense of how well various responses to precinct problems are working. A variety of information related to prostitution is developed by the Area Manager responsible for the Van Buren Prostitution Plan, including arrest trends and average daily counts of prostitutes on the street. Specialized reports on arrests stemming from special operations such as Customer Apprehension Day are also prepared and made available to the area commander and other stakeholders. . Strategic Management. ISTEP asserts that one of the critical information domains for COP is in the area of Strategic Management. It is difficult to distinguish the information demands placed on police executives under COP from those associated with traditional policing. However two things are clear: the role of police executives is more complex under COP, and the need for police executives to have more information related to measuring the demand for services and to the delivery of services has greatly increased. Under COP the traditional formula for gauging demand for service such as calls for service are insufficient. Under COP, "calls by the community" made through surveys and community meetings become important sources for monitoring the demand for service. Police executives need systematic information on the demand for service generated by these sources. Perhaps it might be useful to think of such demands as demands for problem solving services. In recent years PPD has increased its focus on strategic management issues as is evidenced by its systematic and thorough approach to strategic planning. As noted elsewhere, much of the movement to expand and improve information flows from the development of PPD's strategic initiatives for crime reduction. Area commands such as Central City Precinct have many of the same strategic management information needs as top PPD executives. Area commanders are responsible for prioritizing and allocating resources to support major problem solving opportunities and need to have information about constituent service demands so that they can manage precinct resources wisely. They need information that helps them to balance meeting the new service demands generated by COP against those posed by traditional calls for service. Under COP, area commanders are accountable for Part I crime reductions and at the same time they must respond to the "problem solving" requests for services voiced by a variety of empowered community groups. The planning of the Central City Van Buren project reflects considerable sensitivity to a community calling for problem solving services. Strategically, in Central City the reduction of Part I violent crime, especially assault, is premised on a reduction in prostitution and drug activity. Information bearing on the link between those crimes and the levels of service or resources invested in responses, and on the impact of those responses is essential for strategic decision making in that command. At the present time there is no single information system that meets the strategic management needs of the area command. However, the enhanced crime trend data now available to them through CrimeView, along with more traditional management information systems, represents an important step in meeting their strategic management information needs. 3.2. Lessons Learned and Recommendations for Others. The Phoenix Police Department has applied existing technology and integrated new technologies to the understanding of the problem of prostitution. The department has done so in an effort to support its Crime Reduction Strategy. The application of technology has been done in a manner consistent with principles of community oriented policing, and demonstrated considerable success. The successes in the number of arrests and reductions in visible prostitution in the target area are clear. In addition, a good deal of new information has been learned about prostitution and prostitutes. There are a number of key components that intersect to make this possible. First, there is administrative support for the innovative application of technology within the PPD. While such support is not a sufficient condition for such innovation to occur, it is a necessary condition. Put more directly, without the support (in word and in deed) of key command staff including the Chief, such innovations rarely will be successfully implemented. A second key to the success in Phoenix was the availability of technology within the department. The laptop, email, CAD, RMS and digital camera system were all integrated and user- friendly. Absent these two conditions, the application of technology to specific problem solving activities will be difficult for officers to complete. A third factor we cite in the ability of Phoenix to apply technology to working on prostitution is the availability of a strong crime analysis unit. Staff members in this unit were able to produce, on relatively short notice, the appropriate maps, data and analyses to support problem definition, description, and intervention. Finally, there is a strong commitment to problem solving and the integration of principles of community oriented policing within the PPD. This commitment is communicated from top command ranks to Precinct commanders to line level officers. But these four characteristics (administrative level support for the use of technology, the availability of high quality technology, a strong crime analysis unit, and commitment to COP) do not guarantee success by themselves. Officer initiative and support for innovation were also key elements to the response in the Central City Precinct to the problem of prostitution. Officers were clearly motivated to go beyond routine patrol as a strategy to address a longstanding problem of prostitution. Some of this motivation came from actively engaged community partners who helped to define problems and expected accountability from the Precinct. Some of it came from the quality of leadership within the District. The key technological lesson to emerge from the project in Phoenix was the integration of digital photographs into reporting procedures. As this technology becomes more reasonable in cost, and its successes become documented, it will find broader application within law enforcement. While the PPD created a separate database with such photos and the "301" data, a key for future innovations is to integrate such technological innovations into existing CAD and RMS data systems. This integration should include both the ability to view these specialized databases and to make entries into them. Such integration will facilitate their use by patrol officers and detectives who see suspects in the prostitution database who are engaged in a variety of other illegal activities not involving prostitution at the time. As most offenders engage in cafeteria style offending and rarely specialize in a single offense, maintaining the broadest access to information about offenders must remain a high priority. When a specific problem solving effort originates in a specialized unit or is directed against a specialized offense, the tendency may be to create a new data system that is independent from existing data sources or fails to fully capture the capabilities of such data systems. Such an effort may have the unintended consequence of limiting access or use by officers outside that unit because they may not be available to those officers or such officers may not know of their existence. Such limits would have the unfortunate consequence of reducing the utility of the new information. There are significant costs, both in personnel time and dollars, to the creation of new data systems within police departments. Such systems should have the broadest use and application possible, as the systems themselves should necessarily lead to new innovations. Chapter4 Phase II Case Studies Final Report ISTEP Auto Theft Problem-Solving January 2003 Prepared for Office of Community Oriented Policing Services (COPS) Program/Policy Support and Evaluation Division 1100 Vermont Avenue, NW, Washington, D.C. 20530 Prepared by Scott Decker Tim Bynum Abt Associates Inc. 55 Wheeler Street Cambridge, MA 02138 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 1.1. ISTEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 1.2. Site Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 2. Problem Solving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 2.1. The Auto Theft Problem and Response in Reno. . . . . . . . . . . . . . . . . 127 2.2. Description of Site Visits and Project Methodology . . . . . . . . . . . . . 132 2.3. Process of Defining Problem, Identifiying Data Elements, and Links to the Outcomes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 2.4. Role of Technology.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 2.5. Data Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 3. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.1. ISTEP Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.2. Lessons Learned and Suggestions for Other Locations. . . . . . . . . . . . . 141 Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 1. Introduction This report is one of several produced for the Information Systems Technology Enhancement Project (ISTEP), a project funded by the Office of Community Oriented Policing Services (COPS Office). The overall goal of the ISTEP project is to develop written documentation, software systems, and procedures that will increase the utilization of information and information technology in police departments, particularly regarding the implementation of community- and problem-oriented policing. This particular report describes the use of information systems technology in police problem solving to reduce auto theft. This crime is not well understood. Indeed, the research literature on auto theft is relatively limited, and little has been written specifically about problem solving in the area of auto theft. Leading texts on Community Policing (Thurman, Zhao, Giacomazzi, 2001; Glensor, Correia and Peak, 2000; Gaines and Cordner, 1999; Durham and Alpert, 2001) make little mention of the application of community oriented policing (COP) and problem oriented policing (POP) philosophies to the crime of auto theft. Indeed, when specific crimes are treated in the framework of COP, they are couched in general terms of investigations. Forst (1998) examines the use of COP principles in investigations of specific offenses. He notes the significance of an emphasis on offenders and locations rather than offense characteristics in the application of COP to investigations. Such a shift demands real time data, fully enumerated data systems, and efficient means for providing output to detectives, patrol officers and police managers. He calls for an analysis of patterns of crimes–an analysis that requires enhanced information systems capability and applications. This case study describes the application of Information Systems technology to problem solving for the crime of auto theft in Reno, Nevada. Reno was selected for participation in this project owing to the Reno Police Department's longstanding commitment to problem solving. This commitment is demonstrated in the patterns of recruitment, promotion, and training used by the department, as well as the emphasis on problem solving that infuses the organization. In addition, Reno participated in Phase I of the ISTEP Project (Dunworth et al, 2000). The problem of auto theft became the focus of this case study after a series of conversations with the Deputy Chief of the Reno Police Department and members of the Crime Analysis Unit. In particular, auto theft was selected because of its relatively high prevalence and low clearance rate. In addition, it was generally accepted in the department that little was known about the patterns and characteristics of auto theft. This is typical of other agencies as well, because there is little work examining the nature of the offense or responses to it. In the year 2000, the city of Reno recorded 770 reported auto thefts, with a clearance rate of 5.2 percent. The clearance rate is well below the US rate for 1999 (14.9 percent) and the rate for cities with population ranging from 100,000 to 250,000 (12.5 percent). This is a rate of 455 per 100,000 and compares to auto theft rates for the US of 421 per 100,000. The remainder of this report is organized as follows: . The remainder of Section 1 provides background information on the ISTEP Project (Section 1.1) and Reno (Section 1.2). . Section 2 describes the problem solving approach used in Reno to combat auto theft and how this approach utilized information 1 All ISTEP reports are available on the technology. COPS Office website at www.cops.usdoj.gov . Section 3 presents some conclusions and lessons learned for other jurisdictions. 1.1. ISTEP Overview With the goal of increasing the utilization of information and information technology in police departments implementing community policing, the ISTEP project team initially developed a conceptual framework document that describes how community policing imposes different information needs on law enforcement.1 In particular, the framework identifies seven key information domains that should be developed if police departments want to implement community policing effectively. The seven domains are: . community interface . inter-organizational linkages . work-group facilitation . environmental scanning . problem orientation . area accountability . strategic management Subsequent project work proceeded in two phases. The goal of the Phase I was to learn about police department accomplishments in community policing, technology development, and the seven information domains. Phase I was also designed to gain an understanding of the internal and external processes involved in implementing information technology in support of community policing. Five police departments–Tempe, Arizona; San Diego, California; Hartford, Connecticut; Reno, Nevada; and Charlotte-Mecklenberg, North Carolina–were selected to participate in Phase I of the project. These departments were selected because of their successes and experience relating to information technology and community policing implementation. The Phase I departments provided the ISTEP team with open access to their operations and made command and line level staff fully available for interviews, observations, and questions. Several site visits were made to each city to gather information on community policing practices, technology planning, and technology implementation. Members of the ISTEP team attended numerous meetings, participated in technology training, conducted ridealongs, and examined specific hardware and software at each site. Individual case study reports were prepared for each of the participating departments and submitted to the COPS Office. A Phase I cross-site report synthesizes the findings of the individual case studies. It does so by addressing nine specific questions, as a means of helping other departments involved in community policing to learn and understand the processes necessary for IT development. The nine questions are: . Is technology driving community policing or is community policing driving technology? . Is there integration with strategic planning? . Is the process of designing and acquiring technology "bottom up" or "top down"? . What is the level of external support for these processes, and what linkages with other information and intervention systems are present? . What is the mix of "in-house" versus "out-of-house" expertise shaping technology planning and acquisition? . Who is responsible for integration? . How do these new systems and/or processes actually affect the quality and impact of police work, and how do we know that such changes have occurred? . How does the process of assessment continue? . How is such change financially supported? In Phase II of the project, the ISTEP team worked with three departments –Phoenix, Arizona; Reno, Nevada; and Arlington, Virginia–that have demonstrated a strong commitment to community policing but are in the early stages of IT planning. In Phase II, the ISTEP team worked closely with the departments to develop an information technology design that will support community- and problem-oriented policing. The Phoenix and Reno case studies focus on specific problems–prostitution and auto theft, respectively–while the Arlington case study describes the design and development of a COMPSTAT information tool that can support community policing. 1.2. Site Background Reno, located in Washoe County, is a rapidly growing city with approximately 170,000 residents. Gaming is a primary industry in the area and attracts nearly 60,000 participants on a daily basis. The city has experienced substantial growth over the past decade, and the population has become increasingly diverse. The police department has 330 sworn officers, and roughly 170 civilians. One hundred thirty officers are assigned to the patrol division, which is organized into three districts, North, South and Central. The North and South districts include mixed use properties, including residential, industrial and commercial land use patterns. The Central district, however, primarily includes the downtown areas of the city where the gaming and hotel industries are concentrated. Each district is commanded by a Lieutenant. Area management and beat integrity are given high priority within the Reno Police Department. Consistent with these principles, each district has a sergeant responsible for each shift. The department operates out of a single facility located in the Central District. A special tax levy created a downtown policing district that is staffed by fourteen officers who are assigned to a bike team. This group operates within a well-defined ten to fifteen block area that coincides with the primary hotel and gaming industry locations. Part I crimes have declined substantially from their levels at the beginning of the 1990s, in total a drop of 13.7 percent. For example, double digit declines were observed for homicide, rape, assault and larceny. Burglaries declined by just over four percent, and auto theft and robbery were the only crimes for which increases were recorded. The increase in auto theft from 1990 to 2000 was 6.4 percent, an increase of 46 vehicle thefts over that period of time. During this same period felony arrests increased substantially, nearly 25 percent. In 1999, the city of Reno reported a total of 736 motor vehicle motor vehicle thefts and 770 in 2000. With the exception of 1995 (810) the 2000 auto theft total was the highest number recorded in the decade. 2. Problem Solving Process 2.1. The Auto Theft Problem and Responses in Reno Auto Theft Investigative Activities There are two detectives and one clerk assigned to auto theft in the Reno Police Department. An investigative sergeant has oversight responsibility for this unit as well as other investigative units. The senior auto theft detective has been in the auto theft detective bureau since 1999, and has been in the detective unit on several other occasions during his time with the PD. (Detectives can serve a maximum of four years in the unit and then must transfer out for a year. Detective is an assignment, not a rank, in the Reno PD.) The other auto theft detective joined early in 2000. Assignment to the Auto Theft unit is regarded as an entry level detective position. Regarding case processing and information flow, when a call is received by dispatch it is entered into the computer and the dispatcher immediately checks to see if the vehicle is on the towed or repossessed list. If it is not on this list, normally a Community Service Officer (CSO) is sent to take a report. In some cases, a police officer may be dispatched if there is a potential for confrontation or other unusual circumstance, or if there is an officer immediately available. In some cases however, there is no one available so the complainant is asked to come to a substation to file a report. When the report is completed it goes to the records division and is entered into FBI's National Crime Information Center (NCIC). The auto theft detectives then selectively examine these cases to determine which ones merit their time and attention. This process is also followed for recovered vehicles.2 In one instance, the auto theft detective indicated that he found a Pre-Sentence Investigation form from the probation office for an offender on the front seat of a recovered auto that the officer who recovered the car had not seen. The offender was subsequently arrested. The failure of responding officers to capture such information can have substantial negative results in ultimately linking perpetrators to the cars that they stole. The auto theft detective also indicated that patrol officers rarely if ever conduct fingerprinting within the cars that were reported recovered. These observations inform the basis for recommendations at the end of this report. 2 There are no fixed criteria by which this is done. After the auto theft report is completed and processed, the auto is then listed on a "hot sheet" that is distributed to officers at the next shift. This is a Be on the Look Out for (BOLO) list that includes all stolen vehicles and plates. The entry stays on the sheet for the balance of the current month and for the next entire month. Each officer gets a hot sheet at the beginning of every shift. They are also e-mailed to the Washoe County Sheriff and to Sparks PD. The senior auto theft detective noted that the department recovers about three-four stolen cars a week from the hot sheet list. He felt that officers like to use the hot sheet and have come to define such use as a normal part of their jobs. However, there is no formal mechanism available to capture the number and nature of successful hot sheet "hits", recoveries and arrests. After records have been entered into the system, hard copies are made and sent to crime analysis, auto theft detectives, and the repeat offender program (ROP). Crime analysis or the detective unit (whichever gets to the report first) then enters the information into a FoxPro database. The review of FI cards for auto thefts is not an established practice at this time. An auto theft detective reads every case and makes a determination on whether the case should be assigned for follow up investigation. The assignment of a case to a detective is based on the solvability factors of a case. These factors are not formally specified, nor are they captured in a database as such, but rather are based on the knowledge and experience of the detective. Using information technology to determine the validity of such factors is an important part of the analysis phase of this project. Indeed, in a following section we assess the empirical validity of typologies that are used to help define solvability. The validity of solvability factors is a key to having something "that you can work on," such as possible witnesses. About 25 percent of the cases get assigned to a detective, and in a lot of cases there is not much to investigate. In many incidents, the car is gone and that is all that is known. Every case in which there is an arrest is assigned to a detective. This involves a recovered vehicle that is occupied. If there is a recovery by the police there is only a short report that typically contains no information. This underscores the importance of having data available to detectives for problem solving, and as Forst (1998) noted, establishing patterns of offenders and locations. Detectives estimated that a recovery is made in about 85 percent of the cases. This is more common in certain types of cases, generally those involving unauthorized taking or embezzlement cases. Documenting the precise recovery rate, and other characteristics of recoveries, such as time to recovery, characteristics of recovery areas, and the relationship between these and other variables form key tasks for the analysis. Typology of Auto Thefts Interviews with auto theft detectives revealed six types of auto theft. In general, the auto theft detectives believe that there is little organization or structure to auto theft in Reno. Three of these types fall into the general category of embezzlement: 1) lending a vehicle to a friend or acquaintance and it not being returned in the agreed period, 2) cases involving drugs in which an individual will "rent" his car to a drug user who does not return the car within a specified time (it is believed that in many of these cases, the car is taken to California and used in other dope deals and perhaps abandoned there), and 3) rental cars not returned. Another type of auto theft involves individuals who need 4) temporary transportation and will steal a car to get where he is going and will then abandon it. This happens frequently, and an individual active in this type of auto theft can account for a large number of stolen vehicles. There is the stealing involving the 5) permanent taking of a vehicle for a chop shop operation, stripping of parts, or other use. There were very few "chop shop" type of cases in Reno, only three in the year 2000. A final category consists of 6) insurance fraud in which there is of course no car actually stolen. An important task for the analysis of auto thefts is to examine these six types, refine them conceptually, and determine their relationship to the data. A complete analysis that had all available data would document the number of each type, changes over time, recovery rates within type, locations of types, and other relevant characteristics of each type during the analysis phase. In Reno there has been increasing awareness from detectives about patterns involved in auto theft. When they see a "rash" of auto thefts particularly involving a certain type of vehicle or location of theft or recovery they will try to determine what is going on. However, they haven't used offender locations as a factor in investigations, owing in part to the lack of willingness on the part of other units to share or collect data. The Crime Analysis Unit performs the analyses for the auto theft detectives. Until recently there was a state auto theft task force in the region lead by the NV Division of Investigations. RPD was going to join this group, but it was disbanded by the state at the end of June 2000. Auto theft detectives believe that one of the most important aspects of auto theft investigation is knowing who is in town that likes to steal cars. By this it is meant that certain individuals who frequent a tourist town such as Reno can be expected to steal cars while in town. Identifying their presence is important for understanding and preventing auto theft. The Auto Theft detectives receive a list of auto theft offenders from Repeat Offender Program (ROP) but it does not contain addresses. Clearly working more closely with the ROP needs to be a high priority for the auto theft division. It would be useful to know the number of perpetrators in ROP with prior auto theft convictions, as well as their residences, MO's and areas of prior offending. To date, these data have not been available to the Auto Theft unit. The auto theft detectives also believe that it is not unusual to have drugs as well as residential burglaries involved with auto theft cases. In some cases guys who are drug-involved will give up their dealer or a meth lab location to avoid the auto theft case. Auto theft can be reduced to a gross misdemeanor of unlawful taking for which no one goes to prison. This circumstance underscores the importance of sharing data across units, a process that will be facilitated by automation of case records and investigative files. The Nevada Department of Corrections provides to the Reno Police Department a monthly list of individuals released from prison that contains the sentencing offense and the living address. Auto theft detectives make increasing use of such a list by identifying potential suspects and locations. There is often a problem with incomplete investigations being conducted at recovery locations. Often prints can be collected, but officers are reluctant to attempt to collect such potential evidence. This may be because recovery of a stolen auto without a suspect is not seen as a high priority. Once the car is recovered and the arrest of a suspect is not imminent, there is little follow up. This leads to a situation where little evidence is collected, further reducing the probability of an arrest. Detectives indicated that having patrol officers generate a list of potential suspects is very important, as is collecting as much information as possible in the initial report. This points to the need to validate information, a key to the successful use of data. For example, if the VIN is wrong on a report it leads detectives to pursue leads that don't lead anywhere, underscoring data quality control as a high priority in any IT- based intervention. There is often incomplete information in the report. In addition, it is helpful to know the specific location (e.g., where in parking lot), the way it was stolen, accurate information on time of theft, in addition to obtaining prints from recoveries. These cases decay quickly, and unless information is obtained early it is often lost. This is important when the car is found as well, because there is a limited time the police can hold the vehicle before it is returned to the owner. This adds to the shortcomings of available data regarding auto theft, particularly regarding auto theft offenders. Further there is a need to communicate with rental car agencies about fake ID and stolen credit cards. The department has encouraged rental car agencies to copy the licenses of renters, but only some comply. The auto theft detectives use mapping on a bi-weekly basis to indicate the locations of thefts and recoveries. This exercise would likely prove to be more valuable if analysis could include other characteristics that may be helpful in identifying relationships between these events, such as incidents with no forced entry, common stolen items, suspects identified, etc. However, as noted above, in many cases such data are not included in the reports. Although auto theft receives considerable attention in Reno it has not been the subject of a formal POP project. This is likely due to the lack of information contained in the RMS that could be used for analysis. There is a need to improve reports to get officers to enter environmental conditions, such as lighting etc., that could be helpful in designing prevention and target hardening activities. Given the historic commitment to CPTED in RPD it is expected that integrating such principles into the use of data should not be problematic, and the analysis phase should be able to shed light on the presence or absence of such information. However, in the analysis conducted for this project, only four cases noted any CPTED principles in an auto theft case file. Process Mapping of Auto Theft Process The specific steps in handling and processing auto theft complaints are summarized in the diagram below: . car disappears . victim notices . call to dispatch . PO or CSO responds to scene, to victim (if known suspect, potential for confrontation, PO responds) . report taken . dispatch checks for towed vehicles . officer dispatched to scenereport written (copy to CA, ROP, Auto Theft, RMS) . AT enters report into FoxPro . Entry to Hot Sheet (stays on for month of entry and nesxt full month), NCIC Entry, Broadcast to be on lookout . access to case by all officers . AT detectives review for solvability factors . assigned, not assigned 2.2. Description Of Site Visits And Project Methodology To collect data and better understand the local context of the auto theft problem, four site visits were conducted to the Reno Police Department. The first was conducted on March 20-21, 2000, the second was conducted on June 7-8, 2000, the third on December 18-19, 2000, and the final site visit occurred on April 25-26, 2001. The first site visit was primarily dedicated to updating our knowledge of the status of the technology integration in the department. Technology acquisition has been an area of emphasis for the department over the past two years. The CAD/RMS contracts had been signed at the time of the first site visit, and the CAD was to be the first of these systems to be installed. These systems were developed through the process of establishing "platform leaders," groups of individuals from the police department responsible for working with the vendor on implementation issues. There is a specific component in the RMS that will capture problem solving efforts, and that is viewed as a hallmark of the new system. ArcView has become the platform for departmental GIS, and mapping has a central role in crime analysis conducted by the department. In addition, three Community Service Officers have been assigned to the crime analysis division. There is ongoing discussion of the appropriate role and location of these individuals (centralized vs. district based). POPTRACK has been used to document the SARA process with regard to a number of areas, specifically the successful efforts against drug selling in downtown Reno. Four specific activities were conducted on this first site visit. First, information was obtained regarding the data that are to be contained in the new RMS that may be useful for addressing these questions. Second, information on the current RMS (albeit limited) was reviewed. Third, several focus group meetings were held with detectives and supervisors involved with auto theft investigations to explore what is done now, what is currently known about this problem, and what information is most important. This would deal with both issues for crime solving (tactical) as well as more strategic problem solving concerns. Fourth, interviews were conducted with various administrators including detectives, crime analysts, and the Deputy Chief to ascertain their perspective on how this problem is approached currently and how it could be better handled. The specific information needs for various domains were examined in more detail during these interviews. Past practices regarding specific task forces were also discussed, and particular attention was devoted to detective functions. The second site visit was conducted on June 7-8, 2000. During this site visit, considerably more attention was paid to issues of the application of information. Meetings were held with a variety of units and individuals, including the Deputy Chief, the Police Services Manager, a sergeant from Planning, Training and Research, the head of Crime Analysis, and a member of the Downtown Bike Unit. As was anticipated, there were delays in the implementation of the CAD/RMS systems. There is an emerging emphasis on the mapping of crime events, and they are being integrated into patrol efforts. There is an increasing "bottom up" demand for information that appears to be linked to the departmental emphasis on problem solving. It is important to observe that Reno places a high emphasis on Crime Prevention Through Environmental Design (CPTED) in addition to the POP emphasis. Extensive training and modification of the organizational structure and performance measurement has taken place to support the transition to problem solving. While this transition is not complete, there is a substantial need for improved information for problem solving. The new RMS is intended to fill this gap. A process map including the flow of auto theft information and cases was developed from information obtained in the first site visit (see Section 1.3). Process maps are useful tools for documenting the flow of cases through various steps in the information process. In addition, the model describes various analysis questions and the potential data sources that can be used to fill such information needs. During the second site visit, this process map was reviewed with administrators, detectives, and officers, and the feasibility of the approach envisioned for the Reno Auto Theft Project was discussed. Interviews were also conducted with each of these groups and individuals to determine how this model will resonate with the practice of problem solving and its relevance to auto theft. After the second site visit, revisions were made in the process model and the information models to incorporate the findings from the second site visit. The third site visit, conducted during December 2000, focussed on identifying and reviewing the available data with the Crime Analyst. During this site visit a coding form was designed and a plan for data collection developed. A feasibility plan was developed by working iteratively with the available data sources. A plan for data coding was developed and the Deputy Chief made arrangements to hire a student to enter data. By the time the fourth site visit was scheduled (March 2001) data from three quarters of calendar year 2000 had been entered in Excel. At the time of the fourth site visit project staff reviewed the preliminary analysis of data on auto theft from three quarters of calendar year 2000. Although full implementation of the RMS had not occurred by the time of this visit (the RMS is expected to be implemented in early summer 2001) an assessment can be made regarding the "fit" between the model that was developed and the capabilities of the RMS and how they can be integrated. A considerable portion of the fourth site visit was spent examining data collected for the analysis phase of the Reno Auto Theft project and identifying new data elements to be collected. These new data elements are offender specific and include: Prior Record (Reno and NCIC) Number of Arrests Number of Auto Theft Arrests Most recent Auto Theft Arrest Data Offense type (3 most recent) Fel/Mis Date Conviction Sentence Residence Length of residence in Reno Known Associates Were charges filed by the prosecutor Date of Conviction Conviction Offense Sentence Relationship to the CJS at time of arrest 2.3. Process of Defining Problem, Identifying Data Elements, and Links To Outcomes A primary reason that auto theft was selected as a key problem by the department was the lack of knowledge regarding the nature of auto theft, the characteristics of offenders, and the typology of offenders. This was amply demonstrated in our discussions with command staff, detectives, and patrol. But data also serve to underscore the dilemmas that surround understanding auto theft in Reno at the time of this study. Aside from these official reports of auto theft, the Reno police department had other reasons to be interested in learning more about auto theft. Their clearance rate for auto theft was 5.2 percent in 2000, well below the U.S. rate of 14.9 percent. Interestingly, the clearance rate for 2000 is the lowest since 1990. Despite this low clearance rate, the department reported recoveries of 81 percent of stolen cars. The recovery rate is important for a variety of reasons. It suggests a number of things about the nature of auto theft in Reno. First, it suggests that most auto thefts have a local and highly instrumental origin. That is, autos that are recovered are unlikely to be stolen by highly organized groups involved in organized crime, interstate transport or chop shop organizations. In addition, the low clearance rate suggests that strangers may be involved in these thefts. Finally, the nature of auto theft in Reno–low clearance but high recovery –suggests several things about the investigative process. It would appear that it is difficult to engage victims once their car has been recovered, and in addition, it seems that it would be difficult to generate much interest among individuals who are not auto theft detectives following a recovery. This was supported by interviews with command and patrol staff. Two major information gaps were identified in this process. The first gap was an understanding of the investigative steps in addressing auto theft. The second was an understanding of the nature of individuals who participated in auto theft. 2.4. Role of Technology There are a variety of roles that technology could play in the understanding of and response to auto theft. Unfortunately, the department is not fully automated at this point and the RMS and CAD systems are not fully operational. As noted in the Phase I ISTEP report, Reno engaged in an extensive redesign of their RMS system. This redesign involved a process of determining what information needs were for problem solving and department operations rather than simply more efficiently computerizing what was currently being done. This system will be fully operational in the coming months and will serve to fill a number of information and analysis gaps in the department. 2.5. Data Analysis The following analysis was conducted on auto theft reports for three quarters during 2000. The total number of auto thefts involved 626 separate offenses. In addition, data were collected regarding the offender in cases in which an arrest was made and data were available. There was only very limited data of this sort available and much of it was incomplete. Characteristics of Auto Thefts Two charges dominated auto theft. Grand Larceny accounted for 403 (64 percent) and Grand Theft Auto for 190 (30 percent) of all auto theft cases. The balance of cases were spread over such charges as residential burglary, burglary and stolen vehicle. In addition, all but three of the offenses were felony charges. The modal offense (93 percent) included no second charge, indicating that auto theft in Reno is an offense in which correlative illegal activity is not present. Cars accounted for just over half of the stolen vehicles (54 percent), followed by other vehicles (24 percent), trucks (20 percent) and motorcycles. Auto thefts in Reno were primarily reported by the victims themselves; this category accounted for 87 percent of all reports of auto thefts, with employees (largely of rental car agencies) accounting for eight percent and other people representing five percent of those who reported a stolen car. The location of stolen cars also provides insights into potential application of IT to problem solving. Sixty percent of stolen cars in Reno were taken from a parking lot, 26 percent from the street, 11 percent from a driveway or garage and three percent from another site. Increasing parking lot surveillance, decreasing the number of entrance and exit locations, and other means of slowing ingress and egress to and from parking lots should pay dividends in reducing the number of stolen cars. Registering a car with a driver on the way into a parking lot is one such recommendation. There was little that could be learned from analyzing the specific location of the theft in terms of establishing patterns of theft. No specific address location accounted for more than a handful of auto thefts. This suggests that "hot spots" identification for auto theft may not be an appropriate analysis tool.3 In addition, repeat victimization analyses by address may also not yield fruitful information. However, triangulating specific theft address with offender and victim characteristics or pools of victim and offender characteristics (from ROP data for example) may lead to useful outcomes. 3 Of course, "residence" accounted for 41 percent of all locations, but there was tremendous variation across residence addresses as well. Locals are the primary victims of auto theft in Reno. Ninety percent of all classifications of victim state were Nevada, and the cities of Reno and Sparks combined accounted for 85 percent of the home residences of all victims. Nine percent of all victims of auto theft resided in California. There was also tremendous diversity in the make and model of cars stolen, with over 100 different makes and models represented in the stolen car inventory. In most instances, the method of entry to the car was not known (67 percent). However, in those instances where this could be determined, access to the keys (either through keys left in the ignition, car running or keys visible) was the modal category, accounting for 82 percent of the method of entry into the car when that data was known. Project staff examined the relationship between the state the victim resided in (Nevada, California or Other) and whether a suspect had been identified. There was concern that auto thefts committed against individuals from out of state were somehow different and may produce fewer suspects. Interestingly, this hypothesis was not supported as suspects were identified in equal percentages for victims from Nevada and California (23 percent) and a higher percentage of victims were identified from other states (38 percent), though the number of theses individuals was very small (n=16). The identification of suspects in such a small number of cases (22 percent) prevented much analysis. Further, identification of a suspect was often in the form of a general nomination of an individual by general description (someone from the neighborhood) rather than a specific individual. We were unable to observe differences in the identification of suspects based on who had reported the offense (victims versus employees). Recovery of Stolen Vehicles One of the key features of the auto theft problem in Reno is the extent to which stolen cars are recovered. In fully 81 percent of all cases, the stolen car was recovered. There was little pattern to the source of recovery of cars that were recovered, however, with police accounting for the largest proportion (72 percent), and a variety of miscellaneous groups or individuals accounting for the balance. None of these miscellaneous groups or individuals by themselves accounted for more than five percent of recovered cars. This suggests that the police (primarily through the direct observation of patrol officers) continue to play the dominant role in the extraordinary high rate of recovered cars. It is important to note that the recovery locations of cars mirror the locations from which they were stolen, with streets accounting for over 60 percent of recovery locations and parking lots or garages accounted for just over ten percent of recovery locations. Importantly for future considerations, in 91 percent of recoveries no specific location of recovery (business, location, etc.) was noted in the reports. If recovery locations are useful pieces of data for tracking suspects (the missing data in the analysis) capturing this data in reports is critical. The lack of data once a car is recovered speaks to the police culture and reward system for this offense that emphasizes the recovery of vehicles rather than the much more difficult task of capturing suspects. Vehicles that are recovered typically have suffered some form of damage, with only 6 percent of vehicles reported as having no damage. Interestingly very few cars had their ignition tampered with or damaged in some fashion. Again, the presence of keys in so many cases of theft makes the need to tamper with ignition greatly reduced. In 88 percent of vehicle thefts no items were stolen from the car. We examined the relationship between state of vehicle origin and recovery of the car. 82 percent of thefts of cars from Nevada residents were recovered, while only 68 percent of those from California residents were recovered, a statistically significant difference. This suggests that out-of-state cars may be more likely to be targeted for theft by individuals interested in using them for longer-term purposes than those stolen from locals. Police Investigative Tactics The way in which the department responds to or investigates auto thefts is also important. We were struck by how rare Crime Prevention Through Environmental Design (CPTED) principles were noted in the data. Of the 626 stolen vehicles reported, only four instances recorded the presence of CPTED principles or practices in the police report. This suggests that either the application of CPTED principles is not so widespread, that the police recording of such details is limited in auto theft reports, or both. Suspects were not identified in a large number of cases; 23 percent of auto thefts resulted in the identification of a suspect. This is an interesting finding given the large number of recovered cars, suggesting that recovery seldom occurs through arrest, and that once recovery does occur, the ability to or commitment to capturing a suspect declines significantly. Not surprisingly, the largest category of individuals interviewed during the investigation were victims, accounting for well over 90 percent of all subjects interviewed. Auto Theft Typologies We also examined empirical indicators for each of the six typologies identified earlier in this report. 1. Lending a vehicle to a friend or acquaintance and it not being returned in the agreed period. There were a considerable number of stolen vehicles that could fall into this category, based on the high recovery numbers, presence of keys as the method of entry, and location of thefts. 2. Cases involving drugs in which an individual will "rent" his car to a drug user who does not return the car within a specified time (it was noted that in many of these cases, the car is taken to California and used in other dope deals and perhaps abandoned there). There was less support for this typology in the data, given the high recovery rates especially for Nevada registered vehicles. However, the lack of substantial offender data prevents us from knowing much about this category. 3. Rental cars not returned. We found that a small but important number of cases of auto theft in Reno could be accounted for by rental car companies as the victims. The reporting of this offense by employees was a key empirical indicator of this typology. 4. Temporary transportation–stealing a car to get where a suspect is going and then abandoning the car. This happens frequently and an individual active in this can account for a large number of thefts. The lack of offender data prevents us from knowing the prevalence of such offending behavior. However, the high recovery numbers support this as a primary category of auto thefts. 5. Permanent taking of a vehicle for a chop shop operation, stripping of parts, or other use. There were very few "chop shop" type cases, only 3 reported for 1999. 6. Insurance fraud in which there is no car actually stolen. We were unable to document this type in the data. 3. Conclusions 3.1. ISTEP Principles Reno represents a specific and unique application component for ISTEP II. A key objective for this site is to demonstrate how automated information can address problem solving for auto theft. This represents a unique application of ISTEP, being the first instance in which a specific crime and specific detective unit will be addressed. Many police departments struggle in their application of information for specialized units that focus on specific crimes. This approach is supplemented by the use of information from non-automated sources to fill gaps in knowledge about auto theft. Like many departments, information systems are in a dynamic state, as a new RMS is being integrated into departmental information systems. Because of the transition from the previous computer system to a state of the art records management system, there are many problems for which automated data are not available. There are implications in this example for many of the information domains developed in Phase I, and these will also be explored. Specifically, we address six of the seven ISTEP information domains outlined in Section 1.1. Information Domain Being Done Needs to be Done Environmental Scanning CPTED Training Describe scene of recovery Workgroup Facilitation Detectives work together, CSO participation Interaction with ROP, Interaction w. Detectives Interorganizational Linkages Washoe County Sheriff, Nevada Highway Patrol Probation and Parole, Dept. of Corrections Strategic Management Manage AT Unit Prioritize Auto Theft Community Interface AT brochures Provide hot sheets, Work on prevention Problem Orientation Link to other offenses, Examine other Conditions Of the seven domains, we believe that the following are relevant to the application of ISTEP principles to auto theft: . Environmental scanning–the extent to which the environment surrounding auto thefts is scanned and examined by detectives. This will include both the use of information and the sources of environmental information. CPTED principles applied, learning about the immediate environment, characteristics of cars, locations and persons. Micro-environmental characteristics of the crime. More in this area needs to be done and integrated into routine data collection by patrol officers and detectives alike. . Workgroup facilitation–the extent to which auto theft detectives are drawn together as a group and use information to produce strategies and tactics to address auto theft. Training of officers on patrol to collect useful information including data and field evidence such as prints. Working across detective units, such as narcotics, burglary and particularly in Reno the downtown bike team. Facilitation between Crime Analysis and the AT unit. BOLO for cars across units. Working with CSO's as well as others outside law enforcement, including Probation and Parole. . Inter-organizational linkages. This domain will be examined by interviews with police personnel to determine the extent to which information from sources external to the police department are used to provide information for the solving of auto theft crimes. For example, the parking enforcement division or the city zoning division could provide information regarding car use patterns that would be useful in understanding the manner in which autos are used and are accessible to offenders. California Highway Patrol, Nevada Highway Patrol, Airport Police, Apartment managers, business owners, insurance companies and car rental agencies. . Strategic management. In this instance, we anticipate tracking the flow of information throughout the organization. For example, we will examine the tracking of information from patrol to detectives, from CAD to detectives, and from other specialized units to auto theft detectives. In addition, command rank staff could prioritize auto theft. . Community interface. The community has an important role to play in addressing most offenses. Auto theft is probably no different from the majority of offenses in this regard. There is little evidence about how the police learn from the community regarding auto theft. These data sources include investigations as well as community meetings. Listing of the hot sheet on the website. CPTED principles come into play here as well, particularly with parking lot owners. . Problem orientation. Many specialized units pay less attention to information than would be desirable, detracting from their problem orientation. In addition, specialized units often act in ways that treat crime as a discrete problem, independent from other community characteristics. Auto theft detectives may wish to broaden their focus and respond to problem definition more than individual cases. The need for a problem orientation is driven by the ability to access and use data. The tendency is to approach many crimes as independent self-contained units. This is particularly true for auto thefts. Nevertheless, it is also overwhelmingly likely that auto thieves seldom steal a single car in their criminal careers. Each successful event has the probability of leading to another. Thus, linking events to each other through the use of IT is an important part of the problem orientation. 3.2. Lessons Learned and Suggestions for Other Locations The auto theft problem solving analysis conducted in Reno was intended to not only lead to improved processing of these cases in Reno but also demonstrate the potential for the use of analysis and technology in addressing auto theft problems in other jurisdictions. This section will reflect on what has been learned from the Reno experience that may be useful in this regard. As noted previously, auto thefts can be placed into a typology of offenses based largely on the motivation of the offender. If auto thefts could be classified early in the investigative process, then perhaps greater investigative effort could be placed into those cases in which the vehicles are being stolen by chronic car thieves or those crimes that are economically motivated. However, the nature of auto thefts dictates that at the time of the initiation of the investigation typically little is known that could aid in this classification. What is known is that the car has been reported missing by its owner. Typically there is little information that can be obtained from the crime scene that would aid in the investigation. For example, in almost all cases it is impossible to take fingerprints at the crime scene since the vehicle is not present. Further, in most cases the victim will not have observed the offense and thus may not be able to provide useful information regarding suspects. Thus, the challenge in addressing auto theft problems for Reno and other cities is obtaining a greater amount of information on auto thefts and using technology to improve the information generation and flow process. Through the efforts of the Reno project several potentially fruitful areas emerged. There appear to be several ways in which auto thefts may be reduced, through prevention activities and through apprehension of active, particularly high rate, offenders. In both cases increased information is needed to design prevention strategies and solve cases. One area through which information can be improved is the increase in required elements of investigation that the responding officer should collect at the time of crime reporting. Reno is doing this through the implementation of a redesigned record management system (RMS). In addition to standard items of incident reporting including the date and time (often estimated) of the offense, and characteristics of the vehicle, it may also be helpful to note the nature of the area in which the car was parked (e.g., lighting, location in the parking lot). Such items may not only be helpful regarding the MO of specific offenders but also important for the design of prevention efforts. It was noted in Reno that many individuals leave their car idling to warm up prior to their going to work in the morning. It was believed that this results in many auto thefts. Systematically collecting such information would allow for an estimation of how large this problem actually is, where it is concentrated and lead to the creation of a prevention campaign based on this information. In Reno as in many other cities, there is a very high recovery rate of stolen autos (81 percent in 2000). While this is comforting, it is also disturbing. In many cases where these vehicles are recovered, there are no suspects and there is little further investigation. Although victims are pleased to have their vehicles returned (assuming there is minimal damage), the question remains whether this offense could have been prevented in some manner or the arrest of a suspect could prevent future auto thefts. In addition to enhancing the information that is collected at the time of the offense report, it is important to collect expanded information at the time of recovery. Recovery information typically includes the date and time of recovery and limited information about the condition of the vehicle. The collection of fingerprints from the vehicle is a potentially productive method of identifying possible suspects, yet this is often not done. This is likely due to the responding officer's workload and perception of the lack of payoff from this activity. In addition, valuable information regarding the method of entry and taking of the vehicle could be helpful in determining the MO of the offender and potential identification of suspects. Further, information regarding items taken from the vehicle can also be of benefit in identifying those vehicles taken for economic reasons. Although there is nothing unusual in these specific investigative items, the key to their being useful is a structure that would require their collection and entry into an automated data system. This structure can be provided through a record management system that specifies that such information is to be included in preliminary and investigative reports for stolen and recovered vehicles. Thus one principal use of technology in the area of auto thefts is to provide a structure for the acquisition of information that is required for successful problem solving and investigation through revised reporting requirements in the record management system. Other data that can be helpful in addressing auto theft is information from probation and parole agencies. As was observed by Reno auto theft detectives, one of the key pieces of information is knowing what known and potentially active offenders are in town and their typical locations of routine activity such as visiting girlfriends, residence and the locations of known associates. Reno has recently set up a process through which data are obtained on recently released parolees and is establishing a similar link with the local probation office. However having such information is not sufficient, it must be placed in an analytical framework to be useful. Key structures for the use of this information would include a data file that would include the characteristics of known auto thieves including MO, types of vehicles stolen, and recovery locations. Reno has made extensive use of mapping technology in the analysis of the addresses of auto theft offenders and the recovery locations. In several instances it was observed through mapping that offenders were stealing cars and abandoning them within a short distance of their residence. Since these individuals were stealing cars as a principal method of transportation, their arrest led to the clearing of a substantial number of vehicle thefts. This has been a particularly beneficial use of mapping, one that needs to be expanded. One of the most effective strategies that Reno has used to address auto theft is the hot sheet. Stolen vehicles are immediately put on this BOLO list that is distributed at roll call for each shift. It was reported that this practice has been quite productive in vehicle recoveries. There are several ways in which technology may be used to even further increase the effectiveness of this practice. In addition to having patrol officers looking for stolen cars, community residents can also play an active role in this activity. Reno is in the process of implementing a "reverse 911" system, in which residents of a specific area will be called with a recorded message indicating that a car has been stolen from their neighborhood and they should be on the lookout for this car. They will be instructed to call the police if they have information that could be useful in identifying suspects or in the recovery of the vehicle. In addition, the Internet can be used to distribute "hot sheets" for citizens to watch for stolen vehicles. The use of these techniques can lead to earlier recoveries with potentially more intact evidence. A common issue in all of the above lessons is the current lack of information about auto thefts. Another strategy to improve our knowledge of this criminal behavior is to create a more systematic method of obtaining information directly from auto thieves. This strategy would involve developing questions to be asked of offenders in order to learn more about the "whys" of auto theft. These questions would explore issues such as the motivation, planning, opportunity, learning, and techniques of this offense. Detectives can build such questions into their routine interviews. In addition, such information can also be collected on a one-time basis through interviews conducted, perhaps by non-sworn personnel, with convicted auto theft offenders. This information would be very useful for developing an understanding of how auto thieves learn and conduct their business. In turn these data can be helpful in designing auto theft prevention strategies and interventions for these offenders. The glue that holds together all of these strategies for increasing the collection and utilization of information on auto thefts is crime analysis. Crime analysis in Reno currently produces a bi-weekly map of the location of recent vehicle thefts. Such maps may also include recovery locations and addresses of known active auto thieves. However, as information regarding auto thefts is increased the role of crime analysis will also be enhanced. In addition to producing maps, crime analysis can serve an important role in maintaining a database on known auto thieves and their characteristics (e.g., MO, types of vehicles, criminal justice status, method of entry, motivation for stealing vehicles). Further, crime analysis can coordinate patterns and trends of auto theft on a regular basis for distribution throughout the department and community. The principal key to the production and management of this increased information is the efficient use of technology. Through the creation of required data fields in an enhanced RMS, the use of the Internet and reverse 911 systems to communicate information to the community, the integration of probation and parole data, and computer mapping technology, a more comprehensive and potentially more effective approach to auto theft problems and offenses can be created. Sharing data across units is a key to this. Recommendations The application of information technology to specialized units is an important next step in expanding the implementation of community policing and problem solving. Successful applications of COP principles in routine patrol indicate that this may be the next frontier. We offer the following suggestions based on our observations, interviews, and data analysis for integrating technology and problem solving to address auto theft problems. . States may wish to consider bar-coding license plates as a means for easier identification of vehicle ownership and registry. Parking enforcement could then simply "swipe" the bar code with a hand held device that could provide a variety of information, including whether the vehicle had been reported as stolen. . Dealing with the self fulfilling prophecy of recovered cars and no suspects. When a vehicle is recovered, many officers disengage from the investigative process, believing that the most important objective has been achieved. However, we believe that vehicle theft recoveries ought to make departments more interested in the crime rather than less concerned. A problem orientation would shift the focus from recovering one car after another to dealing with the circumstances of those thefts and therefore solving the problem of auto theft. . Use reverse 911 capability to do call outs to citizens in neighborhoods when cars are reported stolen. This could be called upon when more than one car is reported stolen from a neighborhood in a short period of time. . Ticket writers should call all ticketed cars in for a check of tags. This must be a priority equal to writing tickets. . The involvement of the bike unit and work in parking garages downtown need to be expanded to address vehicle theft. Given the volume of cars stolen from downtown locations, and the impact of such thefts on business, this is a natural priority. . Limit ingress and egress to parking lots, considering a system in which vehicle owners show identification at the time of entry to and exit from parking lots. Such "secure" lots might be advertised to the public and tried on an experimental basis to determine public demand. Perhaps private companies would consider implementing such a concept. . The value of the hot sheet for recovering vehicles is clear, as is its value for apprehending suspects. However, we believe that there may be a broader deterrent value if the public is aware that the list of stolen vehicles will be made available on the Internet (and perhaps other media sources such as community newspaper). Fraud also may be deterred if potential perpetrators are aware of the publication and widespread dissemination of stolen autos. . A large number of auto thefts occur when individuals leave their running cars unattended. Increasing public education efforts to continue to address this problem is important. References Durham, Roger and Geoffrey Alpert (2001). Critical Issues in Policing: Contemporary Readings. Prospect Heights, IL.: Waveland Press. Dunworth, Terrence, Gary Cordner, Jack Greene, Timothy Bynum, Scott Decker, Thomas Rich, Shawn Ward and Vince Webb (2000). Information Systems Technology Enhancement Project. Washington, D.C.: Office of Community Oriented Policing Services. Forst, Brian (1998). "Problem-Oriented Criminal Investigation." Pp. 399-412, in Tara O'Connor Shelley and Anne C. Grant (Editors). Problem Oriented Policing. Washington, D.C.: Police Executive Research Forum. Gaines, Larry and Gary Cordner (1999) Policing Perspectives: An Anthology. Los Angeles: Roxbury. Glensor, Ronald, Mark Correia and Kenneth Peak (2000). Policing Communities: Understanding Crime and Solving Problems. Los Angeles: Roxbury. Thurman, Quint, Jihong Zhao and Andrew Giacomazzi (2001) Community Policing in a Community Era. Los Angeles: Roxbury. FOR MORE INFORMATION: U.S. Department of Justice Office of Community Oriented Policing Services 1100 Vermont Avenue, NW Washington, D.C. 20530 To obtain details on COPS programs, call the U.S. Department of Justice Response Center at 800.421.6770 Visit COPS Online at the address listed below. e07032016 Updated Date: November 13, 2003 ISBN: 1-932582-23-1 DOJ Seal