Integrated Justice Information System Data Warehouse Project

Transcription

1 Nevada Administrative Office of the Courts Requirements Specification Integrated Justice Information System Data Warehouse Project June 30, 2000 Version 1.1 An Employee-Owned Company An Employee-Owned Company Science Applications International Corporation

2 TABLE OF CONTENTS 1.0 INTRODUCTION PURPOSE OF DOCUMENT PROJECT OVERVIEW RELEVANT DOCUMENTS VERSION DESCRIPTION SYSTEM REQUIREMENTS SCOPE AND SIZING REQUIREMENTS Initial Sizing Estimates FUNCTIONAL REQUIREMENTS HARDWARE, SOFTWARE, AND NETWORK REQUIREMENTS SECURITY REQUIREMENTS INTERFACE REQUIREMENTS Participants Systems State Repositories DATA REQUIREMENTS DATA FLOWS CONCEPT OF OPERATIONS...14 APPENDIX A - DETAILED DATA DESCRIPTIONS...17 COURT CALENDAR INFORMATION...17 CONDITIONS OF BAIL SUMMONS AND SUBPOENA WARRANTS DISPOSITION/JUDGEMENT OF CONVICTION DESTRUCTION OF EVIDENCE PROBABLE CAUSE AFFIDAVIT, ARREST REPORT PROOF OF SERVICE BINDOVER/WAIVER PUBLIC DEFENDER ASSIGNMENT COMPLAINT ORDER TO REMAND NOTICE TO APPEAR CRIMINAL INFORMATION NOTICE OF APPEAL ORDERS JAIL RELEASE REPORT CITATION APPENDIX B - DETAILED INFORMATION FLOWS...38 FIRST APPEARANCE FELONY ARRAIGNMENT AND COURT CALENDAR TRIAL AND WARRANT /BENCH WARRANT SUMMONS/SUBPOENA AND BINDOVER/WAIVER ORDERS AND APPEAL COMPLAINT AND CONDITIONS OF BAIL CRIMINAL INFORMATION AND DESTRUCTION OF EVIDENCE JAIL RELEASE REPORT AND ORDER TO REMAND i

3 1.0 Introduction 1.1 Purpose of Document The purpose of this specification is to document the requirements for a Multi-County Integrated Criminal Justice Information System Data Warehouse for the Administrative Office of the Courts (AOC) of the State of Nevada. This requirements specification is the first deliverable for the design project. These requirements will drive the Architecture Options Study the System Design Specifications deliverables to follow. 1.2 Project Overview The following project overview was excerpted from the AOC Multi-County IJIS Data Warehouse RFP: This system seeks to implement an Integrated Justice Information System (IJIS) between various criminal justice agencies in four adjacent counties in northern Nevada. The direction chosen by the executive committee formed to direct this effort is one that involves the use of a data warehouse that individual operational systems will send necessary information to and retrieve information from. It is the desire of the executive committee to have a single data warehouse shared by all participating agencies. The project is to develop specifications for a data warehouse to store criminal justice information that is to be electronically shared with participating criminal justice agencies. Each criminal justice agency will either modify existing software to communicate with the data warehouse or purchase new software with the appropriate communication technology. The data warehouse will also forward the appropriate criminal history information to the state criminal history repository according to published standards. 1.3 Relevant Documents The following documents were utilized during the requirements analysis effort that resulted in this specification: State of NV AOC RFP Development of Specifications for a Multi-County Integrated Criminal Justice Information System Data Warehouse (and appendices). Nevada Trial Courts Technology Assessment, Dec NCJIS: Design Document Final, September 18, 1997 NCJIS: Addendum Document Draft, February 17, 2000 NCJIS: Law Enforcement Message Switch (LEMS) Transaction Standards, Jan.1992 NCJIS: Wants/Warrants Transaction Layouts, Jan NCJIS: Electronic Submission of Wants/Warrants Transactions, Feb

4 Nevada Courts: Electronic Communications with the Nevada Department of Motor Vehicle & Public Safety, Revision 1.0, Aug NCJIS: Court Information Exchange System (Traffic Convictions and Failure to Appear Notices), July 1997 NCJIS: Parking Violation Program, Jan Version Description Version 1.1 of this document is the 2nd formal delivery of this specification, and contains the requirements changes that have taken place since the end of the requirements analysis phase (version 1.0), and the end of the design phase of the project. Versions 1.1 and 1.0 of the document are identical except for the following changes: 1. The interpretation of requirement AC1 has been elaborated on to describe the exact requirement for case by case access. 2. The Jail Release data flow has been changed to correctly name the document Notice of Release. 2.0 System Requirements This section documents all of the requirements for the system to be designed and developed. The following tables contain: - The requirements number (i.e., SC1) that will be used by the technical team for requirements traceability throughout the system design effort. - The actual requirement which was stated in the RFP or derived through project meetings. - The interpretation of the requirement to remove ambiguity and to help insure that everyone interprets the requirement in the same way. 2.1 Scope and Sizing Requirements SC1 The initial system will accommodate Law Enforcement, Prosecutor, and Court agencies from Carson City, Lyon, Churchill, and Storey counties. Interpretation SC2 Interpretation NA It is the intent of the project members that more agencies and more counties be able to contribute and access data in the data warehouse in the future. Other agencies that might participate include Parole and Probation, Juvenile Parole and Probation, Juvenile Detention, and Prisons. Clark county and Washoe Counties will have their own systems and will 2

5 not participate in this system. The system should be scalable to allow for all other counties in the state to participate. The population of all potential counties that could participate in the system is approximately 500, Initial Sizing Estimates The following analysis gives more insight as to the volume the system, network, and database will need to handle. At this point in the project the numbers are high level estimates to be used for planning the system architecture. Estimates will be further refined later in the project once the network and database designs have been completed. Summary of assumptions used in the estimates: 1. The caseload numbers are based on the caseload summaries provided in the "Nevada Trial Courts Technology Assessment, December 1997". The following estimates include a 20% escalation to allow for growth that may have occurred since On average 7 documents per traffic case, and 55 documents per criminal case will be submitted to the data warehouse % of the data submitted to the warehouse will be in batch mode, and 50% will be submitted via the direct connect method using online transaction processing (OLTP). 4. The average size of a single document data transaction submitted to the warehouse is 350 bytes. 5. The formula used to derive the database size estimates is: Size of total raw data submitted * 4. The multiplier is needed to account for the manner in which the DBMS will store the data, the storage of indexes to increase query performance, and the denormalization of data that typically occurs in a data warehouse to facilitate reporting and query capabilities. 6. It is estimated that for each submittal of document information into the system, on average, four reports will be run. Document Submission (Transaction) Estimates The initial system for the four specified counties will need to accommodate approximately 800,000 "documents" submitted to the warehouse per year. A document is analogous to a single information type as defined in the Data Requirements section of this document. This data warehouse will not store actual document images, but the important data from the documents that are submitted by the participating agencies. The system must be scalable to accommodate up to approximately 3,000,000 documents a year if all NV counties other than Clark and Washoe eventually participate. Network and System Performance Impact Assuming that 50% of the data will be submitted to the data warehouse in batch mode, the network and servers must be initially able to accommodate approximately 400,000 data update transactions a year in batch, and 400,000 via OLTP. This is an average of 1600 documents per day for batch and OLTP. 3

6 Database Size Estimates The estimated database size for the initial 4 counties is 1.1 GIG a year. The database must be scalable to 4.5 GIG a year if all potential counties in the state participate. A more detailed database sizing estimation will be completed in the design phase of this project once the database design has been completed. 4

7 Summary of Sizing Data Traffic Cases Criminal Cases Total Initial 4 Counties Initial County Total 1997 Cases 14,449 10,103 24,552 20% Escalation 17,339 12,124 29,462 Estimated Yearly DW Docs Submitted 121, , ,170 Estimated Daily Docs Submitted 485 2,667 3,031 Estimated Daily Inquiries 9,094 ROM Raw Data Size 275,859,360 ROM DB Size Estimate 1,103,437,440 Other Potential Counties Other Counties Total 1997 Cases 123,348 19, ,241 20% Escalation 148,018 23, ,889 Estimated Yearly DW Documents 1,036,123 1,312,938 2,349,061 Total Potential System Volume Total 1997 Cases 137,797 29, ,793 20% Escalation 165,356 35, ,352 Estimated Yearly DW Docs Submitted 1,157,495 1,979,736 3,137,231 Estimated Daily Docs Submitted 4,452 7,919 12,066 Estimated Daily Inquiries 36,199 ROM Raw Data Size 1,098,030,780 ROM DB Size Estimate 4,392,123, Functional Requirements FC1 A push-pull approach has been chosen. Interpretation FC2 Interpretation All transactions will be initiated by the participating systems. The data warehouse is passive, i.e., it doesn t initiate any transactions. The participating systems will push and pull data when they want to. The data warehouse will never access or interrogate agency systems. Query and view only reporting interfaces must be provided. The system will provide participants read-only and reporting screens to the data warehouse. Data entry screens will not be provided. The actual reports that will be available on the initial system will be described in the design specifications. There is no requirement to provide an ad-hoc reporting tool, however, the use of a relational database will allow ad-hoc reporting as a future add on if necessary. 5

8 FC3 Interpretation FC4 Interpretation FC5 Interpretation FC6 Interpretation The system will not support data entry screens. All data will be sent to the DW electronically through the API's. However, there will be data entry screens designed to set up users and agency profiles on the system. This will be a system administration function, and will not be readily available to all users. The Data Warehouse will be available seven days a week, 24 hours a day (7x24). It is acceptable for the system to allow for periodic scheduled maintenance, however the architecture and associated hardware and software must accommodate on-line backups. Transactions will be sent to the data warehouse immediately upon completion of underlying activity in the operational system. Since the DW is "passive", it will not be capable of controlling when transactions occur. However the design will allow for participants to configure their system " to send transactions to the data warehouse immediately upon completion of underlying activity in the operational system" via the direct connect mechanism. The system will provide mechanisms for the participating agencies to see what new data is available for them in the warehouse. Two mechanisms will be designed: 1. The participants will be able to run a report to see what new data has been submitted to the warehouse. 2. The system will have the ability to provide notifications to participants when certain data is submitted to the warehouse. The data that the participants want to be notified about will be configurable in the agency profile. 2.3 Hardware, Software, and Network Requirements HW1 A single data warehouse will be shared by all participants Interpretation HW2 Interpretation There will be one database server, and all participating agencies will access this single server for warehouse transactions. A database must be developed to act as the storage medium. NA 6

9 HW3 Interpretation HW4 Interpretation Network Redundancy is required. The design must include network redundancy. This requirement is in place because the Sheriff s offices will consider this a mission critical system because of the interfaces to the state repositories The data warehouse system design will utilize industry-accepted standards and protocols for open systems. NA 2.4 Security Requirements SC1 Access security and business rule (translation) tables and programming logic will need to be implemented to allow easy administration of security. Interpretation The following capabilities and rules will apply: The security design needs to include the ability to configure access on a case by case basis, since public defenders can only see their own cases. (Note: Per the design review meeting between SAIC and Teamworks on May 25, the access configuration on a case by case basis is not a high priority and will not be implemented in the initial design.) Each agency (ORI) should be configurable so they can only see certain types of information from certain counties. Security profiles will be configured at the ORI level. Users within an ORI will all have the same access. Individual users and password logins must be maintained on the system. Different permissions will be available for updating and reading information. ORI's will never be able to modify information submitted by another ORI. The reference to translation tables means that the data warehouse system will be responsible for handling references to previously submitted data. Participants systems will not be required to store identifiers from the data warehouse. 7

10 2.5 Interface Requirements Participants Systems IN1 Interpretation The system must provide a seamless transfer of data between agencies without the need for agencies to maintain case numbers or other unique identifiers for all agencies involved in a case. All data transfers will go through the data warehouse. Agencies will not actually transfer data directly to another agency. The participating systems will not be required to store any identifiers to support the data warehouse. The data warehouse will be responsible for maintaining all necessary identifiers. The "translation" tables will map participating system identifiers so that the participating systems will not be required to. IN2 The API's will support direct writing to and reading from the data warehouse, as well as text file transmission. Interpretation The design will allow the participants to interface with the data warehouse in 2 ways: 1. "Batch" - By submitting files which will be loaded into the database in batch. 2. "Direct Connect" - By connecting directly to the system and interacting with the database on a transaction by transaction basis. ISSUE: Having the Direct Connect option which will perform online transaction processing is unusual for a data warehouse and will be a key issue in the design of the system. Data warehouses are typically designed (i.e. denormalized) to facilitate query and reporting capabilities, which is not a good design for OLTP systems. IN3 Interpretation The API specifications will insure that no information being sent to or from the data warehouse will be lost due to system downtime or communications failure. The DW system will insure that all API methods occur as a transaction. The participating system will be confirmed when a successful transaction is completed, and when a transaction was unsuccessful. This means that partial data will never be stored. If system downtime or communications failure occur in the middle of a transaction, no data will be stored. 8

11 Many data warehouses pull data directly from legacy (participant) systems in order to load the warehouse with data on a regular basis. For these types of projects, detailed analysis of all participating systems is required because code needs to be written to actually perform the data pulls. This system will not provide data loading applications, rather API s will be utilized by agency systems to send data to the data warehouse. The design phase of this system will specify the protocols that agency systems will have available to them to interface with the data warehouse through the API s. Since this system will not directly access participant systems, it is not necessary to list in detail every participant s system hardware, software, and operating systems. However, it is necessary to insure that the data warehouse design will accommodate all participating systems. The following information sources were used to provide a summary of participant technologies. - A survey of the existing technology for the participating counties was published in the Nevada Trial Courts Technology Assessment, December Surveys designed to capture updated systems information from the participants were distributed. The response to the surveys was limited. - Interviews were held with Bill Naylor, head of Carson City IS department, and Mark Carter of ADS, the company that provides and supports systems in several of the participating counties. The following list describes the types of technologies that are currently in place and those that are expected to be in place in the near future. - IBM AS400 DB2 - IBM AS IBM System 36 - IBM ES IBM RS6000 UNIX - NT Server - Novell New client/server systems are being planned for. Specific platforms and technologies have not been chosen yet. 9

12 2.5.2 State Repositories ST1 Interpretation Transmit the necessary criminal history information to the Nevada Criminal History Repository within a 24 hour time period of the completion of each event required by the repository. The specifications used for the requirement and design are found in section 1.3 Relevant Documents. All of these documents address the types of data and formats of data to be submitted to the warehouse. To date, no specifications have been received regarding the communication protocols and methods required to connect to and interface with the repositories. We have been told that there are 3 potential ways that this could happen: 1. Using DCOM protocols. This is the currently supported method. 2. There is a possibility that an AAI system will be developed that will provide a communications server, and utilize data dictionary mapping to facilitate the data transfers. 3. The XML protocol will be available in the future. ST2 Interpretation ST3 Interpretation Due to the status of the CIES interfaces and specifications, this design phase will concentrate on providing the required data to the repositories with the specified formatting. The details of the communication methods and protocols that will be used to interface with the repository will not be completed in this design. The system will provide a mechanism for participating agencies to provide data to, and possibly from, two state repositories - the criminal history repository (NCJIS) and the Nevada Department of Motor Vehicle repository (DMV). Applications developed will provide data to the repositories from the data warehouse system. Applications will not be developed to provide data from the state repositories to the participant systems. However, the network design should allow for participating agencies to connect directly to the State repositories, utilizing CIES interfaces so that queries may be performed through CIES provided applications. The data warehouse must store PCN s, Sequence Numbers, NINs, PONs, BINs, NOC codes, condition codes, and ORIs. All of these items are identifiers and codes that the state repositories utilize, and the data warehouse must store them. The data warehouse will not be responsible for generating any of these items. The data warehouse will store them as they submitted by the operational systems, and pass them to the repositories as required. 10

13 ST4 Interpretation The data warehouse must receive and store transmittal status from CIES when transmitting data to the repositories. In the initial design, this is the only data that the warehouse will receive from the repositories. The warehouse design will not handle the acceptance of operational data from the repository for the purposes of updating operational systems. 2.6 Data Requirements This section lists the information types that will be stored in the data warehouse. Court Calendar Information Conditions of Bail Summons and Subpoena Warrants Disposition/Judgement of Conviction Destruction of Evidence Probable Cause Affidavit, Arrest Report Proof of Service Bindover/Waiver Public Defender Assignment Complaint Order to Remand Notice of Arraignment Criminal Information Appeals Orders Jail Release Report See Appendix A for the detailed data descriptions for each information type. 3.0 Data Flows This section documents the anticipated information flows through the data warehouse system. Although the system can be configured to allow any agency to access any type of data, the following diagrams show the expected usage of the system. Figures 1 and 2 show the high level view of the information flow, i.e., what types of information will be provided to the data warehouse, and what agencies will be accessing that data. Appendix B documents the detailed information flows that are anticipated to occur within system. 11

14 Notice of Arraignment, Criminal Information id Court Court Calendar Information, Disposition, Warrant, Orders Appeal Decision Summons, Court Calendar Information, Bail Conditions, Disposition, Warrant, Orders Proof of Service, Jail Release Report Appeal (Misdemeanor) id Law Enforcement Subpoena, Disposition (not filed), Notice of Destruction of Evidence Court Calendar Information, Bail Conditions, Summons, Warrant, Disposition Booking Sheet/PC Affidavit, Notice of Appearance, Proof of Service Booking Sheet/ PC Affidavit, Notice of Appearance, Proof of Service Booking Sheet/ PC Aff/Citation/ Case-Arrest Rpt, Court Calendar Information, Proof of Service Appeal Decision id Municipal Court Complaint/Citation Bindover/ Waiver, Appeal (Misdemeanor) Court Calendar Information, Bail Conditions, Disposition id Justice Court Court Calendar Information, Disposition, Warrant Court Calendar Information, Bail Conditions, Bindover/ Waiver, Disposition, Warrant, Orders Complaint id Attorney, City Attorney Appeal (Misdemeanor) Public Defender Assignment, Court Calender Information Appeal Decision id Public Defender Figure 1 - Misdemeanor (With Arrest)/Gross Misdemeanor/Felony Data Flow 12

15 id Court Appeal id Law Enforcement Citation, Proof of Service Appeal Decision Court Calendar Information, Summons, Warrant, Disposition Citation, Proof of Service Appeal Decision Citation, Proof of Service id Appeal Decision Municipal Court Complaint, Complaint Amendment Subpoena Appeal Decision Appeal Court Calendar Information, Disposition id Attorney, City Attorney Court Calendar Information, Disposition, Warrant, Notice of Appeal, Authorization to Represent Complaint, Complaint Amendment id Justice Court Court Calendar Information, Summons, Warrant, Disposition id Public Defender Public Defender Assignment Notification, Court Calendar Information Figure 2 - Traffic/Misdemeanor (No Arrest) Data Flow 13

16 4.0 Concept of Operations The Concept of Operations (CONOP) is provided to give a user perspective of how the system will work based on the requirements in this document. The system architecture and design have not been developed yet, so this CONOP does not imply any specific type of hardware, software, or technology. The word agency is used to refer to any organization that participates in the system to include courts, law enforcement agencies, public defenders, and district attorneys. Submitting Data to the Warehouse Data can only be submitted to the warehouse through electronic interfaces that are not visible to the users. Agency systems that are already in place, or new systems that will be developed or procured down in the future will be modified to submit data to the warehouse. Data submissions can occur on a transaction by transaction basis throughout the day, or can be submitted as a nightly batch job. Agencies can update data previously sent to the warehouse, however, the warehouse will maintain a history of all data submitted. Viewing Information The system will be configured to specify what types of information all the participating agencies would like to view, as well as the restrictions on data access (See Access Security immediately below for details). There will be 2 ways for an agency to determine what information is available to them in the warehouse: 1. For heavy users of the system, a summary report can be run at any time to view a list of the following types of information: - Available information that has not yet been viewed. - Information that has been recently submitted within a certain timeframe. - Lists of specific information types available, i.e., a list of all the court calendar information that pertains to my agency for the current week. Once the item on the list has been identified as being interesting, it can be selected in order to view the details about the information on the screen. Of course, all reports can also be printed. The process of running reports to view new important information that has been submitted in the past 24 hours could happen each morning, or at any time throughout the day. 2. Some agencies will not have the need to view the shared information on a daily basis. These agencies will not want to run daily reports if it is likely that nothing will be available for them at that time. For these "low usage" agencies, a notification feature will be implemented that will notify the participants by when data that they are interested in has been submitted to the warehouse. Each participating agency can 14

17 determine what data, if any, they want to be notified about. If a notification looks interesting, the agency can easily access the detailed information from the warehouse. Reports will be available to display the details of all the information types stored in the data warehouse (See Appendix A for details). Reports will also be available to see all transactions that have been submitted to the warehouse for a certain individual. Access Security A set of screens comprising the Access Security module will be made available to system administrators and/or superusers who have been designated to implement the access control rules that have been agreed upon within the participant community. These screens will set up the agency profiles that will determine what data they have access to, and when notifications will be sent. Some agency profiles will include only access to certain data on a case by case basis, i.e., public defenders will only be able to view information about their own cases. Some agencies will be configured so that they only access certain information from certain counties. Agencies will never be able to submit or modify another agency data. All users on the system will be assigned a username and password; however, all users within an agency will share the same agency profile. Updating Participant Systems The data warehouse will provide electronic interfaces that will feed data to your agency systems so that the data previously entered by another agency doesn t have to be keyed. Scenarios of System Usage This section describes two potential operational scenarios in which the data warehouse might be utilized. Scenario 1: Arrest by Law Enforcement, Agency-First Appearance An arrest is made by a local Law Enforcement Agency, which creates the Probable Cause Affidavit. The Agency enters the data through the software system that is currently in place. This data will then be forwarded to the data warehouse for use by all agencies that have the proper security profile to access it. This action starts the flow of available data for the other agencies that will use this information for the First Appearance hearing. The Attorney s Office will query the data warehouse to obtain the information they will need for First Appearance for the defendants scheduled to appear, according to the Custody List provided by the Jail. The Courts now have the same capability to query the data warehouse to get the pertinent information they need for the First Appearance hearing. 15

18 The Public Defender also will have access to this information for the purpose of representing clients that may be assigned by the Judge. At First Appearance a number of things can take place. The Defendant may be released, bond out, or be returned to jail. A Notice of Arraignment can result from this action, a Public Defender can be assigned to the defendant, or Conditions of Bond can be set. Once this information is entered into the systems in place and transferred to the data warehouse, it will be available for immediate use. The Attorney, Law Enforcement, Courts, and Public Defender now have current information for all to share on a timely basis. Scenario 2: Warrant/Bench Warrant The sharing of data for Warrants through the data warehouse will provide timely information to agencies involved in the warrant process. When a warrant request is issued, the data will be transferred to the data warehouse. This will give the Attorney and Law Enforcement immediate access to the information. When the warrant has been served a Proof of Service will be generated and this information will be transferred to the warehouse. This will give timely information to better track warrant data for arrest purposes, and for query on warrants if a suspect is being arrested to verify if any outstanding warrants exist. If certain agencies are particularly interested in warrants, they may set up their profiles to receive immediate notifications when Warrant information is submitted to the data warehouse. 16

19 Appendix A - Detailed Data Descriptions Court Calendar Information COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 15 Y Court Case Number Alpha 15 Y Plaintiff Alpha 50 Y, 1st app. only Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Hearing DateTime Datetime Y Place Alpha 100 Y Type Hearing Alpha 50 Y Judge Alpha 40 Y Bail Amount Number 6 Y Notes Alpha Y Multiple Records Charge Process Control Number Alpha 15 Count Number 3 Nevada Offense Code Number 5 Charge Condition Code Alpha 6 Sequence Number Number 3 Plea Code Alpha 2 Plea Date Date Attorneys Alpha 50 17

20 Conditions of Bail COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 15 Y Court Case Number Alpha 15 Y Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 No law violation flag Alpha 1 Y No arrests for violence flag Alpha 1 Y No arrests for theft acts flag Alpha 1 Y No driving of motor vehicles flag Alpha 1 Y No alcohol in possessin flag Alpha 1 Y No drinking of alcohol flag Alpha 1 Y Must not refuse chemical test flag Alpha 1 Y No illegal drugs flag Alpha 1 Y No loitering in gaming areas flag Alpha 1 Y Must no leave county flag Alpha 1 Y Must not leave state flag Alpha 1 Y Electronic monitoring required flag Alpha 1 Y Residential confinement at flag Alpha 1 Y Must be supervised by flag Alpha 1 Y Curfew hours flag Alpha 1 Y Contact under age 18 flag Alpha 1 Y No contact with flag Alpha 1 Y 100 yards from location flag Alpha 1 Y Comments flag unlimited Y 18

21 Summons and Subpoena COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 15 Y Subpoena ID Alpha 15 Y Summons ID Alpha 15 Y Court Case Number Alpha 15 Y Plaintiff Alpha 30 Y Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 DateTime of Summons Date Y Place Alpha 100 Y DA Case No Alpha 15 Y Number attempts to serve Number 3 Y Date of Birth Date Y Validate Served Alpha 1 Y 19

22 Warrants COMMON NAME TYPE Sub NCJIS Mandatory Document Date Date Y Submitting ORI Alpha 9 Y M Submitting ORI Internal Doc Number Alpha 15 Y Court Case Number Alpha 15 Y C Plaintiff Alpha 30 Y Defendant Name Name, Last Alpha 30 O Name, First Alpha 20 O Name, Middle Alpha 15 O Name, Suffix Alpha 5 O SID Alpha 10 Bail Amount Number 6 Y M Date of Warrant Date Y M Time DateTime Y Citation Number Alpha 15 Y O DA Case No Alpha 15 Y Date of Birth Date Y M Social Security Number Number 9 Y O Height Number 3 Y Weight Number 3 Y Extradition Limits Y Validate Served Alpha 1 Y Multiple Records Charge Process Control Number Y Count Number 3 Y Nevada Offense Code Number 5 Y Charge Condition Code Alpha 6 Sequence Number Number 3 Alias Alias Last Name Alpha 30 Alias First Name Alpha 20 Alias Middle Name Alpha 15 Alias Suffix Alpha 5 20

23 Disposition/Judgement of Conviction COMMON NAME TYPE Sub NCJIS Mandatory DA ORI Alpha 9 Y Submitting ORI Alpha 9 Y Y Submitting ORI Internal Doc Number Alpha 15 Y Plaintiff Alpha 30 Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Date of Birth Date Y M Social Security Number Number 9 Y DNA Flag Alpha 1 Y Finding Y Finding Type Y Multiple Records Charge Process Control Number Number 8 Y Y Count Number 3 Y Y Nevada Offense Code Number 5 Y Y Charge Condition Code Alpha 6 Y Sequence Number Number 3 Y Plea Code Alpha 2 Y Y Plea Date Date Y Sentence Information Date of Sentence Date 8 Y Y Death/Life Indicator Alpha 3 Y Fine Amount Number 10 Y Fine Excused Amount Number 10 Y Credit Time Days Number 3 Y Credit Time Hours Number 3 Y Credit Time Months Number 3 Y Credit Time Years Number 2 Y Restitution Alpha 1 Y Restitution Amount Number 10 Y Probation Days Number 3 Y Probation Hours Number 3 Y Probation Months Number 3 Y Probation Years Number 2 Y Community Service Days Number 3 Y Community Service Hours Number 3 Y School Alpha 1 Y Counseling Alpha 1 Y Term Minimum Days Number 3 Y 21

24 Term Minimum Hours Number 3 Y Term Minimum Months Number 3 Y Term Minimum Years Number 2 Y Term Maximum Days Number 3 Y Term Maximum Hours Number 3 Y Term Maximum Months Number 3 Y Term Maximum Years Number 2 Y Attorneys Alpha 30 22

25 Destruction of Evidence COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 9 Y Plaintiff Alpha 30 Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Multiple Records List to Dispose Alpha Long Y 23

26 Probable Cause Affidavit, Arrest Report COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Citation Number Number 10 Y DA ORI Alpha 9 Y CA ORI Alpha 9 Y Court Case Number Alpha 15 Y DA no. Alpha 15 Y Agency Code Alpha 5 Y Booking no. Alpha 15 Y Process Control Number Alpha 15 Y Defendant Name Y Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Y Name, Suffix Alpha 5 Y SID Alpha 10 BIN Alpha 10 SSN Alpha 9 FBI Num Alpha 10 Street Number and Address Alpha 50 Y Residence City Alpha 20 Y Residence State Alpha 2 Y Residence Zip Alpha 9 Y Race Alpha 1 Y Sex Alpha 1 Y Date of Birth Date Y Social Security Number Number 9 Y Height Number 3 Y Weight Number 3 Y Hair Alpha 3 Y Eyes Alpha 3 Y Ethnic Alpha 1 Y Resident Status Alpha 1 Y Operator's License Number Alpha 20 Y Operator's License State Alpha 2 Y Occupation Alpha 30 Y Employer Name Alpha 30 Y Employer Address Alpha 50 Y Employer City Alpha 20 Y Employer State Alpha 2 Y Employer Zip Alpha 10 Y Residence Phone Number Alpha 10 Y Employer Phone Number Alpha 10 Y 24

27 Armed with Alpha 15 Y Type of Arrest Alpha 15 Y Disp of Juvenile Alpha 15 Y Vehicle Alpha 15 Y Vehicle Make Alpha 4 Y Vehicle Model Alpha 3 Y Vehicle Year Alpha 2 Y Style Alpha 15 Y License Plate Alpha 10 Y License Plate State Alpha 2 Y Vehicle Identification Number Alpha 21 Y Place of Arrest Alpha 30 Y Place of Offense Alpha 30 Y Date Date Y Bail Type Y Bail Amount Number 6 Y Custody Status Y Warrant no. Alpha 15 Y Citation Date Date Y From Arrest and Property Record Y Inmate No Alpha 15 Y Name, Last Alpha 30 Y Date of Arrest (Booking Date) Date Y Time Datetime Y Age Number 3 Y Marital Alpha 1 Y Religious Pref Alpha 30 Y Citizenship Alpha 1 Y Warrant No Number 10 Y Officer ID Number 10 Y Agency Code Alpha 5 Y Fingerprint Flag Alpha 1 Y Photo Available Alpha 1 Y Warrant Check Alpha 1 Y Own Recognizance Alpha 1 Y Date of Disposition (Court Date) Date Y Time Datetime Y Sentence Number 10 Y Start date Date Y Multiple Records Y Charge Alpha 50 Y Process Control Number Alpha 15 Y Count Number 3 Y Nevada Offense Code Number 5 Y Charge Condition Code Alpha 6 Y Sequence Number Number 3 Y Alias Y Alias Last Name Alpha 30 Y 25

28 Alias First Name Alpha 20 Y Alias Middle Name Alpha 15 Y Alias Suffix Alpha 5 Y Scars, Marks, Tattoos Alpha 80 Y Witness Y Witness Name Alpha 30 Y Witness Home Address Alpha 30 Y Witness Home Phone Alpha 10 Y Witness Work Address Alpha 30 Y Witness Work Phone Alpha 10 Y Victim Alpha 15 Y Victim Name Alpha 30 Y Victim Address(all multiple) Alpha 100 Y Written notes Alpha Y 26

29 Proof of Service COMMON NAME TYPE Sub Document Date Date Y DA/CA ORI Alpha 9 Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 15 Y Summons ID Alpha 15 Y Subpoena ID Alpha 15 Y Warrant ID Alpha 15 Y Court Case Number Alpha 15 Y File No Alpha 15 Y Initiator Alpha 30 Y Court Alpha 30 Y Service Date Date Y Time Time Y Location of Service Alpha Y Fee Number 9,2 Y Name Served Y Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Y Name, Suffix Alpha 5 Y SID Alpha 10 Y Person Serving Alpha 30? Type of Service Y Person over 18 Flag Alpha 15 Y Remarks Alpha Y 27

30 Bindover/Waiver COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Court ORI Alpha 9 Y Court Case Number Alpha 15 Y Process Control Number Alpha 15 Y Case No Alpha 15 Y Custody Status Y Plaintiff Alpha 30 Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Height Number 3 Y Weight Number 3 Y Hair Alpha 3 Y Eyes Alpha 3 Y Date Date Y Multiple Records Charge Process Control Number Alpha 15 Count Number 3 Nevada Offense Code Number 5 Charge Condition Code Alpha 9 Sequence Number Number 3 Plea Code Alpha 2 Plea Date Date Attorneys 28

31 Public Defender Assignment COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Public Defender Alpha 30 Y Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Assigment Date Date Y Plaintiff Alpha 30 29

32 Complaint COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Originating LE PCA_Complaint Y Court Case Number Alpha 15 Y Plaintiff Alpha 30 Y Defendant Name Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Y Name, Suffix Alpha 5 Y SID Alpha 10 Y DA Name Alpha 30 Y Complaint Date Date Y Complaintant Name Alpha 30 Y Multiple Records Charge Process Control Number Alpha 15 Count Number 3 Nevada Offense Code Number 5 Charge Condition Code Alpha 6 Sequence Number Number 3 30

33 Order to Remand COMMON NAME TYPE Sub Document Date Date Y Court ORI Alpha 9 Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Remand Reason Y Order Date Date Y 31

34 Notice to Appear COMMON NAME TYPE Sub Document Date Date Y Court Case Number Alpha 15 Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Defendant Name Name, Last Alpha 30 Name, First Alpha 20 Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 BIN Alpha 10 SSN Alpha 9 FBI Num Alpha 10 Appearance Date Date Y Time Datetime Y Place Alpha 100 Y Appearance Type Y 32

35 Criminal Information COMMON NAME TYPE Sub NCJIS Mandatory Document Date Date Y Court ORI Alpha 9 Y Submitting ORI Alpha 9 Y M Submitting ORI Internal Doc Number Y Indictment Flag Alpha 1 Y Incident Type (PCA, Criminal Information, Complaint, Citation, Bindover/Waiver) Incident Number Reference Internal Document Number Court Case Number Alpha 15 Y Dept No Alpha 3 Y Plaintiff Alpha 30 Y DA Name Alpha 30 Y Defendant Name Y Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Y Name, Suffix Alpha 5 Y SID Alpha 10 Y BIN Alpha 10 SSN Alpha 9 FBI Num Alpha 10 Multiple Records Charge Y Process Control Number Alpha 9 Y Y Count Number 3 Y Y Nevada Offense Code Number 5 Y Y Charge Condition Code Alpha 6 Y Sequence Number Number 3 Y Attorneys Y 33

36 Notice of Appeal COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Alpha 15 Y Appellate Court ORI Alpha 9 Y Court Case Number Alpha 15 Y Defendant Name Name, Last (Appellant) Alpha 30 Name, First (Appellant) Alpha 20 Name, Middle (Appellant) Alpha 15 Name, Suffix (Appellant) Alpha 5 SID Alpha 10 Respondent Alpha 30 Y Date Filed Date Y 34

37 Orders COMMON NAME TYPE Sub NCJIS Mandatory Document Date Date Y Submitting ORI Alpha 9 Y Y Submitting ORI Internal Doc Number Y Order Type Y Defendant Name Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Name, Suffix Alpha 5 SID Alpha 10 Multiple Records Charge Process Control Number Alpha 9 Y Count Number 3 Y Nevada Offense Code Number 5 Y Charge Condition Code Alpha 6 Sequence Number Number 3 Plea Code Alpha 2 Y Plea Date Date Free form Content of order Alpha Y 35

38 Jail Release Report COMMON NAME TYPE Sub Document Date Date Y Submitting ORI Alpha 9 Y Submitting ORI Internal Doc Number Y Court Case Number Alpha 15 Y Process Control Number Alpha 15 Y Bail Conditions Y Name Y Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Y Name, Suffix Alpha 5 Y SID Alpha 10 Y 36

39 Citation COMMON NAME TYPE Sub NCJIS Mandatory Document Date Date Y Submitting ORI Alpha 9 Y Y Submitting ORI Internal Doc Number Y Submitting ORI Alpha 9 Y Y Submitting ORI Internal Doc Number Y Alcohol Treatment Indicator Blood Alcohol Concen / Speed Breakdown Court Ordered Begin Date Court Ordered End Date Commercial Motor Vehicle Flag Court Ordered Suspension Flag Citation Time Defendant Name Name, Last Alpha 30 Y Name, First Alpha 20 Y Name, Middle Alpha 15 Name, Suffix Alpha 5 Def DOB Def Height Def Weight Def Address Def Zip Def SSN DUI Flag Eye Color Fine Amount Hair Color Hazardous Materials Flag Jail Time License Confiscated Indicator License Plate Number License Plate State Message Key NRS (Why not ORI) Violation Code Violateion Description Plea Code Plea Date Registered Owner name Resident State Sex 37

40 Appendix B - Detailed Information Flows The following pages depict the anticipated process/information flows through the system. It shows what process initiates the information flow, which agency submits the data, and which agencies will access the data. First Appearance First Appearance Process Diagram Legend Law Enfocement Arrest/ Booking PC Affidavit Next Morning Next Morning or City Attorney Justice, Municipal, or Court Agency Process Document Process Flow Notice to Appear (a.k.a. Notice of Arraignment) Law Enforcement or City Attorney 1 Day after Arrest First Appearance/ Plea Public Defender Assignment Public Defender Back to Jail Released or City Attorney Bond Out 38

41 Felony Arraignment and Court Calendar Arraignment - Felony Process Diagram Legend Guilty/Not Guilty (Plea) Next Day or City Attorney Agency Justice or Municipal Court Plea Next Day Law Enforcement Process Next Day Document Back to Jail Bond Out Released Public Defender Public Defender Assignment Process Flow Plea: Not Guilty or City Attorney Set Trial Date/ Preliminary Hearing Court Calendar Information Next Day Next Day Law Enforcement or City Attorney Public Defender Law Enforcement Next Day Public Defender Court Calendar Next Day or City Attorney Court Calendar Justice, Municipal, or Court Trial Date Memo, Law & Motion Setting Notice Next Day Law Enforcement Next Day Public Defender 39

42 Trial and Warrant/Bench Warrant Trial Process Diagram Legend Justice, Municipal, or Court In Session Judgment of Conviction/ Disposition Same Day Same Day or City Attorney Law Enforcement Agency Process Document Process Flow Same Day Justice/ Municipal/ Court Warrant/Bench Warrant Immediate or City Attorney 1-2 Days Warrant/Bench Warrant Proof of Service Justice or Court Immediate Law Enforcement Serve Warrant/ Bench Warrant 1-2 Days 40

43 Summons/Subpoena and Bindover/Waiver Summons/Subpoena Process Diagram Legend or City Attorney Agency Process Summons Subpoena Document OR Law Enforcement Serve Summons/ Subpoena Process Flow Justice Court Summons Proof of Service 1-2 Days Bindover/Waiver Bindover/Waiver or City Attorney Justice Court Public Defender Trial Next Day Court 41

44 Orders and Appeal Legend Justice or Court Orders or City Attorney Agency Process Law Enforcement Document Process Flow Notice of Appeal Appeal Appeal Justice or Municipal Court Next Day Court Next Day Appeal Court Next Day Next Day or City Attorney or City Attorney Next Day Appeal Decision Next Day Appeal Decision 42

45 Complaint and Conditions of Bail Complaint/Citation Process Diagram Legend Complaint/ Citation Agency or City Attorney Justice or Municipal Court Process Document Process Flow Conditions of Bail or City Attorney Bail Conditions Justice, Municipal, or Court Law Enforcement Public Defender 43

46 Criminal Information and Destruction of Evidence Criminal Information Criminal Information or City Attorney Court or City Attorney Notice of Destruction of Evidence Law Enforceme nt Destruction of Evidence Municipal Court Justice, Municipal, or Court Court 44

47 Jail Release Report and Order to Remand Jail Release Report Notice of Release Law Enforcement Justice Court Order to Remand Court Order to Remand or City Attorney Justice Court Public Defender 45