2025_CAD-RMS_RFP-_8.11.25.pdf

REQUEST FOR PROPOSAL

FOR A COMPUTER-AIDED DISPATCH AND RECORDS MANAGEMENT SYSTEM AND

RELATED MODULES

Invitation to Bid

CITY OF TUSTIN REQUEST OF PROPOSALS

Computer-Aided Dispatch And Records Management System And Related Modules

Notice is hereby given that the City of Tustin will receive sealed proposals from qualified and experienced contractors to provide a fully integrated Computer-Aided Dispatch (CAD) and Records Management System (RMS) along with related modules, including mobile and field-based reporting, smartphone access, mapping, and booking management. Proposals must be submitted to the Office of the City Clerk no later than 05:00 p.m. on September 4, 2025.

The primary intent of this Request for Proposal (hereinafter “RFP”) is to enter into an agreement with a contractor capable of providing and installing a complete public safety software system that will modernize and replace the existing CAD and RMS platforms used by the Tustin Police Department. This includes all required software, installation, training, data conversion, and first-year maintenance and support services.

Specifications are available online at the City of Tustin website (http://www.tustinca.org) or at the City Clerk’s Office located at City Hall, 300 Centennial Way, Tustin, CA.

The City of Tustin reserves the right to accept or reject any or all proposals, to waive any informality, and to accept the proposal deemed to be in the best interest of the City of Tustin.

City of Tustin, Tustin, California Sean Thuilliez, Chief of Police Dated this 11th day of August, 2025

Attention Bidders – It is the City of Tustin’s intent to enter into an agreement with a contractor on a suitable value approach. We will treat suitable value as a combination of availability, fit, short-term costs and long-term costs that, in totality, are deemed to best meet the City of Tustin’s needs.

Table Of Contents

1. INTRODUCTION -------------------------------------------------------------------------------------------------------------------- 1

1.1. Submission Of RFP ---------------------------------------------------------------------------------------------------------- 1

1.2. BID PROCESS ----------------------------------------------------------------------------------------------------------------- 2

1.3. SCHEDULE OF EVENTS ----------------------------------------------------------------------------------------------------- 2

1.4. BACKGROUND --------------------------------------------------------------------------------------------------------------- 3

2. PROPOSAL FORMAT -------------------------------------------------------------------------------------------------------------- 4

3. SYSTEM REQUIREMENTS -------------------------------------------------------------------------------------------------------- 8

4. COMPUTER HARDWARE ------------------------------------------------------------------------------------------------------- 36

5. INSTALLATION AND TRAINING ----------------------------------------------------------------------------------------------- 36

6. SUPPORT SERVICES ------------------------------------------------------------------------------------------------------------- 37

7. PRICING FORMS ----------------------------------------------------------------------------------------------------------------- 40

8. EXCEPTIONS ---------------------------------------------------------------------------------------------------------------------- 41

9. TERMS AND CONDITIONS ----------------------------------------------------------------------------------------------------- 41

10. ADMINISTRATION SPECIFICATIONS -------------------------------------------------------------------------------------- 42

11. PUBLIC RECORDS ACT ------------------------------------------------------------------------------------------------------- 45

1. INTRODUCTION

The City of Tustin is soliciting proposals from qualified vendors for a Microsoft Windows-based public safety software system to replace its existing Computer-Aided Dispatch (CAD) and Records Management System (RMS). A key objective of this procurement is to obtain a fully integrated solution from a single vendor.

Through this Request for Proposals (RFP), the City expects to receive comprehensive responses detailing how proposed solutions meet the City’s specified requirements. Following the evaluation of submitted proposals, a limited number of selected vendors may be invited to participate in the Presentations and Demonstrations phase. These in-person presentations, held in Tustin, California, will be scheduled at mutually agreed-upon dates and times. The City will provide a facility and limited presentation equipment. This phase is critical for evaluating the functionality, usability, and overall suitability of each proposed solution.

This RFP is issued on behalf of the City of Tustin, with the Tustin Police Department serving as the issuing office and sole point of contact. All questions and correspondence regarding this procurement shall be directed to:

Lieutenant Robert Nelson Community Oriented Policing & Problem-Solving Bureau Tustin Police Department

1.1. Submission Of RFP

To allow for a fair analysis of vendor responses to this RFP, all vendors are REQUIRED to adhere to the format identified within the sections of this RFP. Responses to the RFP MUST be signed by an official authorized to enter into a contract between the vendor and the City. Any vendor who deviates from the submission instructions may be disqualified by the City.

Bidders are to submit their proposals via email on or before 1700 hours (5:00 PM PDT) on September 4, 2025, to Lieutenant Robert Nelson at RNelson@tustinca.org.

Additionally, vendors are requested to provide the following hard copies:

• One (1) original

• Four (4) additional copies

• One (1) digital copy on a USB drive

All hard copies and the USB drive must be delivered in a sealed, clearly marked envelope and received no later than the deadline stated above. All materials are to be sent to:

City of Tustin City Clerk’s Office Attn: Lieutenant Robert Nelson 300 Centennial Way Tustin, CA 92780

No other persons within the City of Tustin are to be contacted. Doing so may disqualify the vendor from further participation in the bid process.

The City of Tustin reserves the right to accept or reject any or all bids, to waive any informality, to negotiate separately with competing bidders and to accept the proposal deemed to be in the best interest of the City of Tustin.

Contractors with local government and public safety technology experience are preferred but not required. Local Contractors or Contractors with a local presence are also preferred but not required.

1.2. BID PROCESS

The City of Tustin will conduct the selection and contract award process in the following manner:

1. This document will be distributed to all bidders who request it.

2. Bidders will prepare responses to the RFP. Bidders may submit questions about the RFP to the contact person listed above.

3. The proposals will be received and evaluated as described in this RFP. If deemed necessary, the City of

Tustin will ask one or more selected bidders questions about their proposals, either in writing or by oral presentation. Demonstrations of the system at the City of Tustin may be requested.

4. A selected bidder will be chosen for contract negotiations.

It will be the sole responsibility of the bidders to have their bids delivered to the City of Tustin before the closing hour and date. Late bids will not be accepted.

All bids must be valid for a period of 90 days after bid opening. Bids must address all RFP requirements. This RFP is for a complete turnkey system including software, installation, training, plus software maintenance, support and updates for the first year. Partial or incomplete proposals will be rejected.

1.3. SCHEDULE OF EVENTS

The following is the schedule of events listed in the order of occurrence, showing the major milestones from issuance of the RFP to the contract award and the targeted completion dates. No late bids will be accepted.

RFP Issuance August 11, 2025

Questions about RFP Due August 25, 2025

Proposal Due Date September 4, 2025, by 1700

Proposal Evaluation Complete September 12, 2025

Presentations and Demonstrations (invite only) Week of September 15, 2025

Final Selection and Meetings September 26, 2025

Negotiations September 29 – October 10, 2025

Recommendation to Council October 22, 2025

Award Contract** October 31, 2025

Contract Signed November 5, 2025

Target Completion Date August 30, 2026

**Tentative City Council contract award date, subject to change at City’s discretion

The City of Tustin reserves the right to modify these dates if extenuating circumstances necessitate.

1.4. BACKGROUND

City of Tustin – General Information

Incorporated in 1927, the City of Tustin is a General Law City under the laws of the State of California. As such, Tustin exercises only those powers granted by state legislation. Unlike Charter Cities, which operate under a voter-approved charter, General Law Cities are governed by the California Government Code. Tustin has elected to retain this status since its incorporation.

Located in central Orange County, Tustin spans approximately 11.08 square miles and had a population of 80,276 as of the 2020 U.S. Census. The City is bordered to the south by the cities of Irvine and Santa Ana; to the north by unincorporated Orange County and the City of Orange; and to the east by additional unincorporated areas and the City of Irvine. Tustin is situated approximately two miles north of John Wayne Airport and is accessible via two major freeways: the I-5 (Santa Ana Freeway), which bisects the City north to south, and the SR-55 (Costa Mesa Freeway), which cuts through the western portion of the City.

Operating Environment

The City of Tustin’s information technology infrastructure includes a citywide Ethernet LAN/WAN, secure Wi-Fi networks, mobile data computers in police vehicles, and a combination of physical, virtual (VMware), and cloud-based server environments. The City currently utilizes a VMWare virtual server platform and maintains both on-premise and government (non-public) cloud systems. The City of Tustin uses Azure Active Directory and is requiring bidders to utilizing this access management system.

The City is seeking proposals for a comprehensive public safety solution which may include:

• Computer-Aided Dispatch (CAD)

• Records Management System (RMS)

• Automated Field Reporting (AFR)

• Evidence Management Control (EMC)

• Jail Management System (JMS)

Solutions may be hosted on physical servers (with full redundancy), virtual servers on the City’s VMware platform, government cloud infrastructure, or a hybrid combination. The selected system must comply with all applicable federal and state regulations, including Criminal Justice Information Services (CJIS) requirements. Redundancy, proven reliability, and adherence to all relevant compliance standards are mandatory.

Tustin Police Department Overview

The Tustin Police Department operates out of three facilities:

• Main Police Headquarters: 300 Centennial Way

• Emergency Operations Center: 1472 Service Road

• Police Annex: 15445 Lansdowne Road

The department is staffed by approximately:

• 110 Sworn Police Officers

• 55 Civilian Personnel, including:

o 12 Records Personnel o 15 Communications Officers (Dispatchers) o 5 Detention Officers (Jailers) o 15 Police Services Officers (PSOs)

• The City’s IT Department supports all technology needs and includes five full-time staff members.

Current System

Since 2020, the City of Tustin has utilized the Mark43 Computer-Aided Dispatch and Records Management System. At this time, the city does not anticipate migrating historical data from the current system to a future replacement platform.

Over the past five years, the Tustin Police Department has averaged 9,077 calls for service annually and has taken an average of 5,120 police reports per year.

2. PROPOSAL FORMAT

It is the intent of the City of Tustin to solicit proposals that are complete yet concise, descriptive yet brief.

To enable the evaluation committee to fairly evaluate each bid, proposers shall utilize the following proposal format:

• Introduction

The bidder shall provide a brief background of the company, its approach to installation of systems of this kind, company references, and identify any unique or distinctive features of their system that the bidder wishes to be given particular attention by the evaluation committee.

• Bidder Qualifications This section shall respond in detail to RFP Section 2.2.

• Hardware Requirements The bidder shall include the completed hardware specifications forms provided in Section 4 of this RFP.

Additionally, an itemized list and description of the computer hardware required, especially all proprietary hardware, shall be included in this section.

• Installation and Training Plan The bidder shall present a proposed tentative schedule for the installation of the system. The schedule duration shall not exceed 90 days. See RFP Section 5.

• Support Services The bidder shall describe the support services available to the City of Tustin after system installation and identify those included as part of the proposal. See RFP Section 6.

• System Requirements The bidder shall include the completed software specification forms provided in Section 3 of this RFP. Additional information or clarification of responses to the bid specifications shall be included in this section in the notes column or in the Exceptions, Section 7.

• Price Proposal The bidder shall utilize the forms provided in RFP Section 7 for this purpose.

• Exceptions The bidder shall clearly state its objections, exceptions, or alternatives to the general (non-technical) requirements stated in this RFP. Exceptions to the RFP technical system requirements should be listed in Section 5 unless the explanation is lengthy in which case it may be referenced to this section.

2.1. EVALUATION CRITERIA

It is the intent of the City of Tustin to acquire the best system available within its budgetary means. Thus, while preference might be given to the lowest compliant bidder, the City of Tustin reserves the right to select the bidder of its choice.

The City of Tustin also reserves the right to waive any irregularities and technicalities and to request rebids should it be deemed in its best interest to do so.

The City will form an Evaluation Committee to review all submittals received by the deadline. Any submittal failing to meet any of the qualifications documented in this RFP may be rejected. The purpose for the Evaluation Committee is to recommend which vendor is best able to provide, install, maintain and support the SYSTEM, to the City’s requirements, and within the City’s budget. A submission in response to this RFP indicates your acceptance of the City’s evaluation criteria.

• Organization Background - 30%

Company’s demonstrated capabilities and staffing levels to meet the project’s needs, service requirements and the company’s customer satisfaction

• Recommended Solution – 30%

Understanding of requirements Project management methodologies Proposed approach Quality assurance plan

• Technical Competence and Experience – 10%

Project Manager and key personnel’s demonstrated experience and expertise Meets technical system requirements as outlined in the Request for Proposal

• References – 10%

Vendor has completed three projects similar in scope, scale, and budget Relevant experience in providing similar software and services to that stated in the RFP

• Cost – 20% The cost proposal is comprehensive and realistic to complete the project

2.2. BIDDER QUALIFICATIONS

The City of Tustin will satisfy itself that potential contractors are reputable firms with a proven track record and a proven product.

1. Bidders shall provide at least five (5) references of installations of similar size and functionality to the system being bid. References shall include a contact name, phone number, email address, date the system went online and a brief description of the system.

2. Bidders shall provide a complete list of California agencies that are currently installed and have successfully obtained final acceptance. (Count customers that include one law enforcement agency and one or more fire/EMS agencies as a single installation).

3. Bidders shall state how many failed installations they have had, that is, installations that never went “live” or went live and the operational use was discontinued within one year.

4. Bidders shall provide the average time to final acceptance from contract signing.

5. Bidders shall provide the number of projects in the last 10 years have exceeded two years from contract signing to final acceptance.

6. Bidders shall provide the number of current active projects that are more than 18 months old without the agency (or agencies) going live. If any, explain why.

7. How many of your law enforcement installations have replaced your system with another vendor in the past 10 years? (Do not count agencies that had to switch vendors because their CAD/RMS merged with a different agency --- a police department whose dispatching was switched to the sheriff's office, for example.)

8. Bidder shall state if their company is currently, or ever has been, involved in any court action, lawsuit, or any other legal investigation/action related to the performance of a contract.

2.3. SYSTEM SUITABILITY

Bidders will be evaluated on the suitability of their systems with respect to the following factors:

1. Does the system meet all the functional needs of the City of Tustin?

2. Does it provide a system that will be easy to use?

3. Does it provide a system that will be easy to learn?

4. Is the proposed computer platform already familiar to City of Tustin IT personnel and will it be maintainable by them?

5. Will the computer platform be expandable as needed?

6. Does the proposed computer hardware fit in with the City of Tustin ’s long term computer technology plans.

2.4. PRICE EVALUATION

Price evaluation will be based upon bidder's base price as given in the price schedule plus the criteria described below.

Bidders are encouraged to offer system options that they believe will enhance the usability of the system. These options are to be described and priced separately. The City of Tustin reserves the right to consider or ignore these options in evaluating the overall fitness of a proposal. The price will be specifically evaluated on the following points:

1. What is the initial cost of the system?

2. What is the projected cost of the system over a projected 10-year life span (“total cost of ownership”).

3. What, if any, additional computer equipment will the City of Tustin need to purchase?

4. What is the annual cost for support, maintenance, and updates?

5. What is the vendor’s commitment to support pricing after the first year?

6. Are all updates to the software included in the support program or will some be at additional cost?

7. Is the software sold as a site license or will the City of Tustin need to purchase additional user licenses every time a user or user workstation is added to the system?

8. Will any additional training of City of Tustin IT personnel be required?

9. What is the expected extent of City of Tustin IT resources required for ongoing support of the system?

10. What will be the internal cost of ongoing training of new personnel?

11. What is the vendor’s reputation among its customer base with respect to long term costs?

2.5. SYSTEM INSTALLATION

The successful bidder will be responsible for installation of the proposed software. The City of Tustin will be responsible for procuring and installing all required computer equipment and related network infrastructure. The bidder shall describe in the proposal any special electrical and environmental requirements of required equipment.

2.6. PAYMENT TERMS

Payment to the vendor will be made as progress payments at the conclusion of the following milestones:

Contract Signing 15% of contract value System Installation Completed 35% of contract value

Training Completed 25% of contract value System Accepted 25% of contract value

3. SYSTEM REQUIREMENTS

This section describes in detail the specific functions required of the system requested. It does not describe how a proposed system is to implement these functions as each bidder's system will be unique in that respect.

Bidders shall also list all exceptions to the functions specified in this section. Failure to do so may be cause for disqualification or the City of Tustin may direct the bidder, if selected, to implement the missing features at no cost to the City of Tustin.

Place the appropriate reference letter in the RESPONSE column of the table.

I - Included. Requirement is met by vendor’s base product. Feature or functions must be available for demonstration and operational at user sites now. If not present now but planned, Use the “C” response. Use also for YES where the requirement needs a Yes/No response.

M - Modification required. Base product has this feature or function, but some modification will be required to meet the specific requirement. Cost, if any, must be itemized in the Pricing Section.

C - Custom enhancement. The vendor’s base product does not contain this function or feature but it will be added to meet the requirement. Cost, if any, must be itemized in the Pricing Section.

N - Not provided nor proposed. Use also for NO where the requirement needs a Yes/No response.

Use the NOTE column for:

o Explanations of your Response where you deem it needed o Reference sections in the proposal that provide, at your discretion, detailed response information o Response information requested in the Requirement

3.1. GENERAL REQUIREMENTS

REQUIREMENT RESPONSE NOTE

Foundational

The system proposed is Microsoft Windows™ based and runs on Windows 11 or later at user workstations.

The system runs on a Windows 2016 or later Server

All applications running on a server must run in a Windows environment.

The system can run within a virtualized infrastructure.

The proposed system is based on a Microsoft SQL Server database.

All information entered into the system is solely owned and controlled by the City of Tustin.

Data stored on the system is readily accessible to City of Tustin IT personnel using common utility tools such as Microsoft SQL Server Management Studio and Crystal

Reports at no additional cost to City of Tustin (beyond cost of third party tools)

Vendor has at least 5 operational CAD/RMS sites in California. Provide the number of such sites in the Note column.

Report in the Note column how many of the Vendor’s California sites have been operational for at least 5 years.

Report in the Note column how many years Vendor’s current oldest California site has been operational.

Calls to Agencies using the Vendor’s products (not just the recommended references) will reveal at least a 90% satisfaction rate.

Contacted users of Vendor’s product will rate customer support as good or excellent.

CAD and Records Management are two interlocking halves of one system, not two systems interfaced to each other.

All RMS functionality shall be transparently available to dispatchers without a second sign on, subject to the dispatcher’s security profile.

All CAD functionality shall be transparently available to authorized records personnel without a second sign on, subject to the user’s security profile.

All proposed application software is from one vendor. If not, identify the software and names of other vendors in the Note column.

The CAD/RMS software is updated frequently to correct reported user issues.

Implementing software updates must be a simple, one minute task that does not require vendor nor local IT involvement.

A new version with more than 50 product enhancements (not bug fixes) is issued at least annually. A list of the previous year’s enhancements is available upon request by City of Tustin.

Implementation of a new version shall be straightforward, not require Vendor participation and take no more than 30 minutes.

The CAD/RMS system is highly configurable by City of Tustin personnel beyond installation configuration by vendor. In the Note column enter the approximate number of configuration parameters.

Vendor shall convert RMS data from City of Tustin’s existing system

In the Note column state the number of times Vendor has converted data from that system

Data conversion is performed by Vendor in house, not by a third party.

User Features

The system recognizes and provides for simultaneous handling of multiple transactions.

The system utilizes function keys for frequently used CAD transactions, e.g., incident initiation.

The system automatically checks reference data files in real time.

The system utilizes well organized, easy to read screen formats.

On line help is available via keystroke or menu item.

The system automatically validates entered data with automatic presentation of valid values when an invalid value is entered.

Commands, Menus, Function Keys, and the Mouse

The system utilizes four (4) methods of initiating actions:

▪ Command Entry

▪ Menu Selection

▪ Function Key

▪ Mouse selection to accommodate user preferences

The command entries consist of a command identifier and data parameters in conjunction with a function key (if necessary).

Command entries are available for all commonly used dispatch functions where the number of data items to be entered makes this method of entry desirable (as opposed to displaying and filling in a form).

Menu selections extend to one or more sub-menus, where appropriate.

Menu selection is available for all functions that are performed by occasional, casual users of the system.

Function keys are used to implement commonly used dispatch functions.

Function keys are used for single key retrieval of blank incident forms.

Most functions can be initiated using the mouse.

Keyboard commands are available to duplicate mouse functions for CAD.

System minimizes duplicate entry to the maximum extent possible, specifically including transfer of data from a CAD incident to an RMS officer report

Multiple Screen Functionality

The system supports execution and maintenance of simultaneous events.

Multiple simultaneously open application windows are supported. For example, a user can have incident, person, and vehicle records all displayed simultaneously.

Security Considerations

All system users are required to sign onto the system before being given access to any system function.

System shall support Active Directory for logging into applications.

ID and password requirements meet FBI security standards

The sign on form includes fields for user ID and password.

The password is not displayed when entered.

After the password is verified, the system automatically attaches the user to a security group that determines what system functions he or she may access.

Security granularity extends to individual control of access to view, modify, add and delete functions for each application screen.

The passwords and security group assignments are changeable by authorized personnel only at the highest security level.

The security groups are configurable.

The System Manager is able to create and modify security groups, defining system access down to the function level.

A new security group can be created by copying it from an existing one.

Besides users, each terminal shall have a security group setting

Single Point Data Entry

Data entered into the system either directly or indirectly is propagated to all relevant databases.

Data entered into the system either directly or indirectly is available to all relevant system functions.

Once entered, there is no requirement for re-entry of data to satisfy the needs of a different sub-system.

Records are automatically created and available data filled in when possible, e,g. a citation record from an arrest if needed

All modules of the system are completely integrated.

Auditing

Auditing of system activity shall be present throughout the CAD/RMS system.

Auditing shall be completely transparent to the user.

For any given record, a person for example, the audit trail for that person shall be accessible by a single user action.

Auditing shall include auditing the creation of each record

For changes to a record, the audit record shall include the previous and new values.

Each time a record is view a “viewed” audit record shall be written.

Audit records shall include the date, time, user and physical position identifier of the user.

It shall not be possible to change an audit record.

There shall be a report available by user to provide a profile of user activity for a period using the audit trail.

3.2. CAD (COMPUTER AIDED DISPATCHING) REQUIREMENTS

Call Taker/Dispatcher Functionality

The system supports a call taker taking the call, filling in the incident form, and routing the call to the appropriate dispatcher.

The dispatcher receives an audible or visual indication that a new incident has arrived for dispatch.

The system shall be flexible enough to allow any position to be used for any system function, dispatching, call taking, records within City of Tustin defined security parameters.

Changing a workstation’s functions shall not require reconfiguration of the system.

Incident Entry

Two incident screen formats shall be provided for the entry of incident information, one for calls for service from the public and the other for officer initiated activity such as traffic stops.

The call for service screen shall allow entry of the following information:

▪ Incident location with apartment number/suite number

▪ Incident type

▪ Response priority

▪ Caller name, address, telephone number, location of the caller

▪ Incident details

▪ Vehicle information

Does the system support full incident creation, update, and unit management through a command line interface.

Does the system support two primary incident entry methods: one for call takers entering public calls for service, and one for officer-initiated activity entered via a command line.

The incident location information shall be automatically validated against a geographical database immediately after location entry.

The incident type shall be validated when entered.

Validation shall take one second or less.

The response priority shall be a function of the incident type but enterable by the call taker as well.

The incident details shall allow unlimited characters

Does the system allow dispatchers to designate the origin of each incident using predefined source types, including but not limited to:

• 9-1-1

• Walk-In

• Phone

• Officer-Initiated

Vehicle information shall be recorded as data items, not just text.

The “Officer Initiated” form shall function similarly to

The officer form shall allow the easy entry of unit, location, plate, make, model, colors

Upon entry of a vehicle license plate, the CAD system shall immediately search its database and if found retrieve make, model, year, and color information directly into the form.

immediately display a history of recent contacts with the vehicle.

look up the person associated with the vehicle and display pertinent information about the person including but not limited to recent contact history, officer safety notations, and arrest, warrants, and suspect information.

The geographical database shall be capable of verifying locations entered as street addresses, street names, hundred blocks, place names, and intersections without relying on exact matching of entered location.

Partial street place names and soundex-type matching shall be supported.

Multiple matches of the entered location shall result in a matches list from which the user can select the correct location.

The Geofile shall return the nearest cross street and the standard spelling of the location to facilitate historical retrieval.

The system shall automatically search its database for previous incident history and shall retrieve and display summaries of the 10 most recent incidents at the location.

The system shall automatically search its databases for reporting party information and shall retrieve and display summaries of the 10 most recent contacts with the reporting party.

premise information unique to the location and shall, when available, display a button or icon the user can select to display the information. This record may contain hazardous material information, firefighting information, the names of emergency contacts (for businesses) or special handling information for residents who may be handicapped or elderly.

There shall be a visual feature to easily mark a comment as urgent or important

There shall be a visual to let the call taker know that the caller’s phone number has been linked to other incidents and should take a mouse click or similar to retrieve the information.

The system shall search its databases for vehicle history and shall retrieve and display (for traffic stops) summaries of the most recent five contacts with a vehicle whenever one is entered as part of an incident.

street information and shall retrieve any available information about the street location from the geographical databases, including street hazards.

The most important available information shall be automatically displayed for dispatchers with indicators to alert the dispatcher to the availability of other pieces of

The dispatcher shall be able to display the retrieved information via a short key sequence, a function key, or mouse.

The system shall interface with an E911 controller to automatically receive caller location and telephone number information when an E911 call is received.

Receipt of the E911 information shall cause the CAD system to automatically present the information in an incident entry form at the answering call taker position.

The system shall automatically check for and display a list of previous incidents at the E911 supplied location.

E911 Phase II caller location is supported with the caller’s location or probability circle automatically drawn on the CAD map for the call taker.

When the user commits the transaction, the system shall assign a system generated incident number to the incident and record the date, time and dispatcher handling the call.

That number shall be a unique number not used anywhere else in the system.

CAD shall support entry of RIPA stop data and electronic submission to the State.

Stop data entry and submission shall be part of CAD, not a third party product

CAD shall support What3Words.

CAD shall support Rapid SOS.

Incident Handling

The dispatcher shall be able to update the existing incident information once the incident has been created.

The dispatcher shall be able to add an unlimited number of additional comments once the incident has been created via command line or mouse.

There shall be a feature to add comments in rapid fire and enter them using a hotkey or the enter key, should the need arise during a pursuit or similar.

Each additional comment added to an incident record shall be time and date stamped.

The dispatcher shall be able to assign an unlimited number of additional units to an incident.

The dispatcher shall be able to record all status changes from assigned units once the incident has been created.

The dispatcher shall be able to clear units and close the incident once the incident has been created.

The incident history shall always be shown as part of the incident detail display.

The incident display must include all times for the incident:

call received, entered, dispatched, enroute, on scene, closed.

The incident display must include all times for each unit assigned to the incident: dispatched, enroute, on scene, clear, dispatched-to-on scene, on scene-to-clear, dispatched-to-clear.

Multiple incidents can be simultaneously displayed and updated.

There must be a way to enter and schedule incidents to appear at a later date and time, either once or periodically.

Such incidents should automatically appear in the incident queue at the specified time. It should also be possible to pre-assign a specific unit to the incident when it is scheduled.

Unit Recommendation and Dispatch

Response algorithms shall be based on incident location, incident type, unit availability and GPS location.

For police responses, the recommendation shall show the beat unit, if available, or an unavailable unit from an adjoining beat if the beat unit is not available.

The dispatcher shall be able to accept the recommended dispatch with a single key or edit the recommendation as needed.

For officer-initiated incidents, the unit will be the unit calling; the unit will be entered on the initial incident and will automatically be on scene, unless another option is choses.

There shall be a customizable screen for dispatchers and call takers.

The system must support multiple command lines.

Dispatcher must be able to free and hold an unit in 1 simple command

The system must support CLETS and NCIC queries via the command line.

The system shall allow multiple case numbers per incident in one command.

The system shall be able to create a case number from an incident without reopening the incident.

There shall be a log of a units prior incidents.

There shall be a log of a units prior status changes.

The system must compile and print a Shift Bulletin.

The system must compile and print a Media Bulletin.

The system shall have ad hoc searching ability to search for incidents by time of day, day of week, unit, officer, location, type, etc.

The system will be able to print a full incident.

The system will be able to print a full sanitized version of an incident suitable for the public.

The system will have many built in reports that only require a date range; time response charts, time spent at locations, officer and dispatcher activity, false alarm reports, etc.

Unit Handling Functions

The system must have the “Free a Unit” command to return a unit to a clear status but not close the incident the unit has been assigned to.

The system must have the command “Reassign a Unit” to reassign a unit from one incident to another, returning the first incident to a pending status rather than closing it if there are no other units assigned to the first incident.

The system must have the command “Exchange Units” to dispatch a unit to an incident while simultaneously clearing a unit it is replacing.

The dispatcher must be able to hold one or more pending incidents for a particular unit with an indication in the incident status display.

Users are able to drag and drop Units to Incidents and vice versa.

Dispatchers must be able to clear units from calls and close incidents directly from the status monitor or command line. The system shall record the final disposition or outcome of the call in a searchable and reportable format.

Status Monitor Functionality

Does system provide a persistent, text-based status monitor within the CAD interface that displays each active unit’s call sign, officer name or ID, current status (e.g., available, en route, on scene), assigned vehicle, and real-time location in plain text (if assigned). This display must be visible at all dispatcher workstations, update automatically in real time, and support both mouse interaction and command line input. All information shown must be consistent across users, regardless of individual screen customizations.

Rotation Towing

The system shall be capable of recommending a vehicle tow company upon request.

The tow company recommended shall be the next company on a rotating list.

The dispatcher shall also be able to choose a tow company of their choice.

The tow screen shall include a list of tows already made for the incident

The frequency of rotation shall be configurable, i.e., each call, daily, weekly, etc.

The selected tow company shall be recorded in the incident record.

A dispatcher shall also be able to manually rotate the tow list to the next to the next tow company

The system shall handle tow requests for big rigs, hazmat and drivers’ choice.

City of Tustin shall be able to have multiple tow lists if desired, based on location or type of vehicle to be towed.

The dispatcher shall be able to switch to a different tow list for a particular tow via selection from a drop down list.

Tows shall be logged in the incident history.

A tow log of all tows shall be readily available.

3.3. RMS (RECORDS MANAGEMENT SYSTEM) REQUIREMENTS

Master Name File

The Master Name file maintains the database of persons encountered by the City of Tustin.

Master Name information is entered as part of other data entry, i.e., incident, officer reports, citations, but can also be entered directly into the database.

The system matches new information to the Master Name file with existing persons in the database when appropriate.

The Master Name file has two principal parts for each person: personal information (name, address, height, weight, etc.) and the history of contacts with the person.

When a Master Name record is displayed, both parts of the record are displayed.

The system shall be capable of displaying at least 10 master name records (screens) simultaneously.

The history display shall always initially display the most recent encounters with the person.

The Master Name function shall include the ability to page through the Master Name file.

The Master Name function shall include the ability to page through the Master Name history for a given person.

The Master Name function shall include the ability to add, update, or delete a Master Name record.

The Master Name function shall include the ability to add, update, or delete a history entry.

The Master Name function shall include the ability to print a Master Name record with or without criminal history log

The process used to look up a person in the Master Name file must be flexible enough to aid in locating the person when only a partial name or misspelled name is available.

The logic of the Master Name look-up shall include:

▪ Searching on the name as entered

▪ Matching on any aliases used by the person

▪ Searching on the last name only

▪ Searching for sound-alikes of the entered name.

▪ Match beginning of last name only

▪ Allow the use of wildcards

▪ Match on first name or any other field in the master name.

The prompt screen for looking up a person shall include a list of most recently viewed persons. Persons in that list shall be accessible via a single user action.

When multiple matches are found, the user shall be given the opportunity to page back and forth through the list of matching names, looking at individual records to find the correct match, if any.

When the person record is displayed it shall include warning flags based on previous contacts with the person --

- officer safety, warrant, etc. If provided, enter the number of such flags in the Explanation column

The system shall automatically relate the Master Name to other persons associated with them via their joint presence in officer reports, citations, FIs, incidents, etc. and provide a list of these associations.

The system shall collect Scars, Marks, Tattoos that correspond to the NCIC standards.

The system shall support electronic file attachment.

The system shall collect photographs/mugshots.

The system must be able to create a photo line up.

The system shall support an electronic mug book.

Officer Reports

The system shall support direct entry of officer reports from information collected in the field by officers.

The system shall maintain a reports log.

Provide an interface with Crossroads and support soundex-type matching

The reports log shall be easily viewed and browsed.

The reports log shall contain the officer report number, date, offense, officer, and status, at a minimum.

A command shall be provided to permit easy generation of an officer report number.

Pertinent incident information shall be automatically transferred to the officer report record from a CAD incident record when it is created.

Officer reports shall include a cover sheet - who, what, where, when.

Officer reports shall contain information about an unlimited number of persons involved - personal information, connection to incident, and information specific to their connection (for victims, suspects, etc.)

Information from officer reports shall be automatically propagated to the Master Name file.

Agencies shall optionally be able to keep report-specific person information as part of the case without overwriting existing information in the Master Name File.

The officer reports shall contain vehicles involved information. Detailed vehicle information shall be recorded.

The officer reports shall contain method of entry and other specific information required for the CIBRS reports.

The officer reports shall contain narrative and unlimited subsequent supplements.

Supplements can be added at any time and can include additional persons, vehicles, etc.

Supplements are tightly associated with the original report and do no have separate report numbers

Integral spell checking for narratives and supplements shall be provided.

The system shall allow the user to “cut and paste” text from a word processing program to a narrative/supplement.

The officer reports shall contain officer/reviewer signoff and report routing.

The report screen shall include the ability to add an unlimited number of photos and other images to the report.

The report screen shall include access to a log of all state queries associated with the report

It shall be possible to associate an unlimited number of other files with the report (pdf, spreadsheets, etc.)

A notes section (besides that associated with the case investigation) shall be included

Explicit tracking of assaults on officers must be included for each case.

An approval log must be available to list all reports not yet approved by a supervisor.

A method must be provided for supervisors to approve cases that includes electronic routing of reports from supervisor to officer and back, from supervisor to records, from records to officer and back.

The approval process must allow supervisors and records clerks to attach lists of report problems to the report for the officer to correct.

The officer must be able to individually check off problems as corrected and the supervisor must be able to individually check-off corrected items as verified.

Once approved, a case must be “locked,” i.e., not subject to change (except for supplementary narratives) except by personnel with sufficient security level.

Supplements must be separately reviewable if written after the initial report is reviewed.

The system must collect and tally solvability factors.

The system must support an agency creating their own fillable forms that auto-attach to the case.

The system must support routing internally and externally for the case.

The system must have a subsystem to support prosecuting attorney access.

The report must allow attachments of any supported Windows file, photographs, video, etc.

The report must be able to be marked confidential, confidential to a specific division, confidential to a specific agency if multi-agency.

The officer report must have a visual notification if the case isn’t to be released.

Printing an Officer Report

There must be options for printing the report to meet the variety of printing requirements:

- Entire report

- Entire report plus arrests

- Entire report for accident

- Entire report plus pictures/images

- Face sheet plus narrative only

- Face sheet

- Public version

- Court version

- Property only

- Audit trail

- Picture gallery

- All pictures, one per page

- Accident only

- Accident face sheet

- Accident plus photos

Other required printing options:

- Reason for printing

- Print preview

- Print as PDF and attach to officer report

- Include unapproved supplements

- Include the controlled document stamp

- Include CAD incident in printout

- Print confidential persons

- Select an alternate controlled document stamp

An officer report must be able to be redacted and saved electronically, as well as watermarked within the case itself.

Case Investigation Management

The system shall provide a case investigation log by detective, officer, or all cases under investigation with features similar to the officer log report.

The system shall provide a case investigation status detail display.

The system shall provide appropriate status and progress reports.

The system shall have a feature for assigning follow ups to both investigators and officers that will track the follow up due dates and work complete.

Information kept for each case in the investigation file shall include detective, date assigned, follow up date, victims, suspects, investigation, court dispositions and date closed.

There shall be a mechanism in place to allow the property officer to send inquiries to investigators and officers to request information regarding a piece of property.

Use of Force

Can create a CA DOJ compliant use of force record for any officer report

Approval of the Use of Force entry is included in the officer report approval sequence.

Probable Cause Arrests

Can create a probable cause document for an arrest

Includes person information and arrest information

Includes Determination statement of officer

Includes appropriate submission language

Submission language can be customized by City of Tustin

CIBRS Reporting

Must comply with all California NIBRS (CIBRS), California Domestic Violence, and California RIPA standards

For officer report entry, when entering a crime, burglary for example, the officer must have the option to easily display a selection list of all the CIBRS offenses with that category code (Burglary=NIBRS code 220)

Officer/reviewer/records clerk must be able to run a one button check that reports all CIBRS errors currently present in the officer report.

For a report error, user must be able to jump to the location of the error in one step

Ability to prevent submission to CA DOJ before all errors have been corrected

Ability to submit to CA DOJ multiple times if needed

Vendor shall provide software to support updating of City of Tustin’s Offense Codes file in one step when CA DOJ issues updates.

Citations

The system shall provide means to track traffic and parking citations and associate persons (both the driver and the vehicle owner) and vehicles with them.

Up to six violations shall be supported.

System shall support attaching images associated with the citation.

A separate ability to attach other documents as…