ADDENDUM #4 (DTD. 08/30/11) Administrative notice only-no changes to solicitation
ADDENDUM #3 (DTD. 08/23/11) Upload Interface Requirements to Bidsync
ADDENDUM #2 (DTD. 08/17/11) Upload Attachment D to Bidsync
ADDENDUM #1 (DTD. 08/17/11) SEE CHANGES TO BID OPENING DATE, SECTIONS: 1.16.1, 2.0, 4.16, AND ATTACHMENT C
NOTE: Vendor response tool (Attachment D) will be available soon
NOTICE OF SOLICITATION
SERIAL 11086- RFP
REQUEST FOR PROPOSAL:
CAD/RMS/CIVIL PROCESS and MOBILE SYSTEMS
Notice is hereby given sealed proposals will be received by the Materials Management Department, Materials Management
Center, 320 West Lincoln Street, Phoenix, Arizona 85003-2494, until 2:00 P.M. Arizona time on SEPTEMBER 9 2, 2011 for the
furnishing of the following goods or services for Maricopa County. Proposals will be opened by the Materials Management
Director (or designated representative) at an open, public meeting at the above time and place.
To participate in this solicitation process, vendors shall register through BidSync.com. To register with BidSync, please go to
www.BidSync.com and click on the orange ‘Register’ link. Registration has no cost, and will allow you to access all of the
proposal information, proposal documents, and receive proposal notifications.
For assistance with registration, please contact BidSync Vendor Support Department via phone or email, during regular business
hours: 1-800-990-9339 or agencysupport@BidSync.com
All Proposals must be signed, sealed and addressed to the Materials Management Department, Materials Management Center, 320
West Lincoln Street, Phoenix, Arizona 85003-2494, and marked “SERIAL 11086- RFP REQUEST FOR PROPOSAL:
CAD/RMS/CIVIL PROCESS and MOBILE SYSTEMS.
The Maricopa County Procurement Code (“The Code”) governs this procurement and is incorporated by this reference. Any
protest concerning this Request for Proposal must be filed with the Procurement Officer in accordance with Section MC1-905 of
the Code.
ALL ADMINISTRATIVE INFORMATION CONCERNING THIS REQUEST FOR PROPOSAL CAN BE LOCATED AT
www.maricopa.gov/materials/
ANY ADDENDA TO THIS REQUEST FOR PROPOSAL WILL BE POSTED THROUGH MARICOPA COUNTY
MATERIALS MANAGEMENT WEB SITE UNDER THE SOLICITATION SERIAL NUMBER AS WELL AS ONLINE
AT www.BidSync.com
PROPOSAL ENVELOPES WITH INSUFFICIENT POSTAGE WILL NOT BE ACCEPTED BY THE MARICOPA COUNTY
MATERIALS MANAGEMENT CENTER
DIRECT ALL INQUIRIES TO:
BRIAN WALSH
PROCUREMENT OFFICER
TELEPHONE: (602) 506-3243
EMAIL: WALSHB@MAIL.MARICOPA.GOV
THERE WILL BE A MANDATORY PRE-PROPOSAL CONFERENCE ON AUGUST 15th, 2011 AT 9AM ARIZONA
TIME, AT THE MARICOPA COUNTY FACILITIES MANAGEMENT DEPARTMENT 401 W. JEFFERSON,
FREEDOM CONFERENCE ROOM, PHOENIX, ARIZONA 85003. VISITOR PARKING IS AVAILABLE ON
MADISON BETWEEN 5TH AND 6TH AVE. NOTE: DUE TO LIMITED SEATING PLEASE NO MORE THAN TWO
REPRESENTATIVES FROM EACH VENDOR MAY ATTEND.
NOTE: MARICOPA COUNTY PUBLISHES ITS SOLICITATIONS ONLINE AND THEY ARE AVAILABLE FOR
VIEWING AND/OR DOWNLOADING AT THE FOLLOWING INTERNET ADDRESS:
http://www.maricopa.gov/materials/solicitation.aspx
VENDORS MUST ACKNOWLEDGE RECEIPT OF THIS ADDENDUM WITH THEIR BID
Signature:
Date:
SERIAL 11086- RFP
TABLE OF CONTENTS
NOTICE
TABLE OF CONTENTS
SECTIONS:
1.0
BACKGROUND, OVERVIEW AND INTENT
2.0
SCOPE OF WORK
3.0
VENDOR RESPONSE REQUIREMENTS
4.0
SPECIAL TERMS & CONDITIONS
ATTACHMENTS:
ATTACHMENT A
PRICING
ATTACHMENT B
AGREEMENT/SIGNATURE PAGE
ATTACHMENT C
REFERENCES
ATTACHMENT D
VENDOR RESPONSE TOOL (CAD AND RMS REQUIREMENTS)
EXHIBITS:
EXHIBIT 1
VENDOR REGISTRATION PROCEDURES
EXHIBIT 2
LETTER OF TRANSMITTAL SAMPLE
EXHIBIT 3
MATERIALS MANAGEMENT CONTRACTOR TRAVEL AND PER DIEM POLICY
EXHIBIT 4
DRAFT CONTRACT
EXHIBIT 5
SECURITY GUIDELINES
EXHIBIT 6
VENDOR RESPONSE TOOL USER GUIDE
EXHIBIT 7
INTERFACE DETAILS AND CONTACTS
II
SERIAL 11086- RFP
REQUEST FOR PROPOSAL:
1.0
CAD/RMS/CIVIL PROCESS and MOBILE SYSTEMS
BACKGROUND, OVERVIEW AND INTENT:
1.1
GENERAL BACKGROUND INFORMATION:
The Maricopa County Sheriff’s Office (MCSO) is the fourth largest county law enforcement
agency by population and land mass in the United States, with responsibility for an area that
covers 9,226 square miles. MCSO is responsible for all unincorporated areas within Maricopa
County. In addition, MCSO services eight contract cities – Fountain Hills, Carefree, Cave Creek,
Guadalupe, Litchfield Park, Gila Bend, and Sun Lakes. MCSO provides dispatch and 911
services for the town of Youngtown. MCSO also serves numerous large recreation areas that
attract hundreds of thousands of people each year.
In addition to covering MCSO’s areas of responsibility, MCSO’s Emergency Operations Center
has control of the warning sirens for the Palo Verde Nuclear Facility and dispatches units to
respond. Furthermore, MCSO’s Emergency Operations Center is the designated 911 default
center in Maricopa County for all cell phone emergency calls that do not identify the callers’
locations.
1.2
SHERIFF’S OFFICE BACKGROUND INFORMATION:
The Sheriff’s Office has an annual budget of $280,000,000. There are 1982 detention officers of
which 198 are Sergeants, 64 are Lieutenants, and 8 are Captains. There are 708 sworn officers
working in Patrol and various specialty assignments of which 567 are Deputies, 87 are Sergeants,
64 are Lieutenants, and 8 are Captains. There are 1,982 detention personnel, and 614 civilian
personnel. Of the 614 there are 514 line-level employees, 68 supervisors, 24 managers, and 8
Deputy Directors.
1.2.1
The Organization:
The Sheriff’s Office operates under the authority of the Maricopa County Sheriff and
Interim Chief Deputy.
The Sheriff’s Office is organized into four major commands that report to a Chief or a
Director.

Enforcement
o
Patrol Bureau

Districts 1, 2, 3, 4, 6, 7, Lake Division and Mountain Patrol
o
Patrol Resource Bureau

Enforcement Support Division

SWAT/High Risk Response, K9

Special Investigations Division

General Investigations Division

Training Division

Special Operations
o
Support Services Bureau

Property Division

Records Division

ID Division

Civil Division including Extradition
o
Intelligence Bureau

Criminal Intelligence Div. / Counter-Terrorism Div.

Communications Division

Facial Recognition Unit
SERIAL 11086- RFP

o



Legislative Liaison
Compliance Bureau

Compliance & Policy Division

Aviation Services

Occupational Safety Division
Custody
o
Custody Region 1

Central Intake

Madison Street Jail

Transportation

Court Security Division

4th Avenue Jail

Durango Jail
o
Custody Region 2

Lower Buckeye Jail

Detention Standards and Compliance, Medical Services

Institutional Services

Ancillary Services

Custodial Support Services
o
Custody Region 3

Estrella Jail

Tents Jail

Towers Jail

Special Response Team

Sheriff’s Information Management

Inmate Classification
Business Operations
o
Budget and Finance Bureau

Business Services Division

Budget Development and Management Division

Financial Reporting Division

Financial Services Division

Fleet Management Division

Construction and Maintenance, Warehouse and Surplus,
Procurement Services
o
Human Resources Bureau

Personal Services Division

Pre-employment Services Division
o
Technology Management Bureau

Business Systems Development

Desktop and Client Support

Mainframe Operations and Tech Support

Telecommunications Technology
Districts
The County is currently divided into six geographical areas, referred to as
Districts, and consists of District 1, District 2, District 3, District 4, District 6
and District 7. Districts are generally staffed by a District Commander
(Captain), Deputy Commander (Lieutenant), uniformed sergeants and patrol
deputies, detectives, and administrative staff.
SERIAL 11086- RFP

Lake Patrol
The Lake Patrol Division (also known as District 5 for GIS and other reporting)
has the responsibility for law enforcement services in the recreational areas of
Tonto National Forest and Lake Pleasant Regional Park. This area includes, but
is not limited to: Saguaro, Canyon, Apache, Bartlett and Horseshoe Lakes as
well as the Lower Salt and Verde River recreational areas, Four Peaks,
Superstition, Mazatzals, Camp Creek and Seven Springs recreational and
wilderness areas. The total area of responsibility is over 1,000 square miles,
which are visited by over 1.5 million people annually.

Trails Division
The Trails Division (also known as District 8 for GIS and other reporting) has
the responsibility for law enforcement services in the recreational and
wilderness areas of the Maricopa County Parks. These areas include, but are not
limited to:
o
o
o
o
o
o
o
o
o
o
Buckeye Hills Recreation area
Cave Creek Regional Park
Estrella Mountain Regional Park
Lake Pleasant Regional Park
McDowell Mountain Regional Park
San Tan Mountain Regional Park
Spur Cross Ranch Conservation Area
The Desert Outdoor Center at Lake Pleasant
Usery Mountain Regional Park
White Tank Mountain Regional Park
The total areas of responsibility are over 120,000 acres and are visited by over
1.8 million persons annually. The Maricopa County parks system is the largest
regional parks system in the nation.
1.3
CURRENT TECHNOLOGY ENVIRONMENT:

The Maricopa County Sheriff Office’s PRC Safety Suite includes:
o
Computer Aided Dispatch (CAD) (COBOL) which is a PRC System installed in
1990 (PRC Inc. was acquired by Northrop Grumman in 2000).
o
State interface (AJIS)
o
ALI/ANI 911 Interface
o
PRC Mobile CAD Application on Mobile Data Computers

The Maricopa County Sheriff’s Office Records Management Suite includes:
o
o
o
o
1.4
New World RMS was installed in October 2003.
Field Reporting – Officers currently prepare reports on paper with narratives
entered offline using an MSWord enhanced applications. Some officers are
using the systems as designed, but they are a minority.
Crime Analysis -. Detectives use an ACCESS database for case tracking. Crime
analysis functions are utilized on an ad-hoc basis.
Case Management – Not being used.
MARICOPA SHERIFF’S
INFORMATION:

OFFICE
WORKLOAD
&
COUNTY
POPULATION
In CY 2010 Communications handled 737,366 calls for service, officers responded to 91,
243 calls for service and generated 30,408 incident reports. Total CAD entries numbered
507,205 which include MCSO Adult Probation and Youngtown PD’s workload.
SERIAL 11086- RFP
Thursdays, Fridays and Saturdays are traditionally MCSO’s busiest days of the week
with Sundays being the slowest.
HISTORICAL WORKLOAD
CY 2008
CY 2009
CY 2010
Population:
3,954,598
4,023,132
4,083,159
Total CAD incidents entered (1)
607,570
563,698
507,209
911 Emergency Calls (2)
8,270
6,053
5,547
Administrative Calls from General Public
(3)
95,899
92,385
89,012
Administrative Calls from other MSCO or
County or both/ Agencies (4)
Unknown
Unknown
Unknown
Total Calls for Service (5)
104,169
98,438
94,559
Total On View/Self-Initiated Calls (6)
503,401
465,260
412,650
Total Accidents (7)
7,406
6,272
6,370
Total False Alarms (8)
13,667
13,434
12,558
Total Reports Generated (No Accidents unless DUI) (9)
35,064
30,553
27,273
Total Accidents (10)
4,375
3,731
3,861
Total Detective Cases Assigned
Not Available
5,943
4,085
Total Citations (11)
20,444
19,779
18,958
Warrants
54,157
46,888
43,088
Total Property Impounded
Not Available
25,208
27,392
Total Arrests Total arrested and booked by
MCSO
Not all arrests require a report.
20.073
19,319
18,902
Total Arrests recorded by UCRIncludes
DUI but no other criminal traffic
An unknown portion of these totals are not
included in the totals above (cite and
release)
10,654
Vehicles Towed (12
COMPUTER AIDED DISPATCH CALLS
10,003
8,882
N/A
1485
2905
IR’s (DR’s) Entered by Jail Personnel
3780
3740
3893
3511 Hearings/Releases (12)
N/A
958
3133
Notes for above table:
1. The total number of incidents entered into CAD is all inclusive and include Maricopa County Adult
Probation, Youngtown Police Department, MCSO, and other entities that are dispatched from the
Emergency Communications Operations Center (911).
2. The figures are calculated on the number of incidents entered in CAD where the source of the call is
“9” which indicates a 911 call. The totals include MCSO and Youngtown Police Department and
potentially other agencies that might have transferred a 911 call to MCSO, but does not include
Adult Probation.
3. Figures calculated based on any incident where the source was from a non-emergency line (Code =
T for telephone) other than a 911 call. This Includes Youngtown PD and MCSO and any calls from
other agencies.
SERIAL 11086- RFP
4. This figure is unknown. Calls from other agencies are grouped by utilizing the “T” code as
mentioned above. Thus, these figures are included in the Administrative Calls from General Public
category.
5. Total Calls for Service calculated by combining 911 calls and non-emergency calls from the public.
6. Officer initiated calls includes MCSO, Youngtown PD and Adult Probation activity.
7. These accident figures include all motor vehicle accidents and boating accidents regardless if the
incident did not require a report, or was turned over to another agency, or cancelled due to various
circumstances. It includes figures for Youngtown and MCSO.
8. Includes all forms of Alarms that did not require a report and were concluded as false alarms
regardless if they were cancelled or not.
9. Includes all reports taken by Youngtown and MCSO and any DUI/Alcohol related traffic accidents
where a report was taken.
10. Figures include all traffic accident reports taken except for those that are DUI/Alcohol related.
11. Figures include all citations/warnings per CAD data for MCSO and Youngtown PD.
12. This information is from August 9, 2009 thru March 16, 2011.
2010
4,083,159
2011
4,205,653
Population Projections
2012
2013
4,331,823
4,461,777
2014
4,595,631
2015
4,733,500
It is estimated that growth will not exceed 3% through 2015 and no estimates are available for further
years.
1.5
MARICOPA COUNTY CURRENT TECHNOLOGY ENVIRONMENT OVERVIEW:

County Networking Environment: The County of Maricopa operates three Countywide networks; The Enterprise Network, the Supervisory Control and Data Acquisition
(SCADA) Utility network, and the Justice Network. The justice network supports
Computer Aided Dispatch (CAD) and Records Management System (RMS) operations,
along with other public safety related systems. The networks are connected through
firewalls to allow CAD and RMS to access other applications for public safety use
without putting any additional burden on the public safety network and to ensure system
and data security, as described below:
o
Enterprise Data Communications Network: The Enterprise Network is the
primary network for Maricopa County. The network is operated by the Office
of Enterprise Technology and over is comprised of over 1000 networking
devices in more than 85 locations. The county network is a three tiered
environment with Gigabit uplinks between the Core and Distribution tiers.
Desktop bandwidth varies between locations from 10Mb to 1000Mb Ethernet
connections. Remote sites are connected with varying levels of service
depending on requirements
o
Justice Network: In addition to being on a separate network with dedicated
hardware from the Enterprise Network, each public safety location accessing the
CAD/RMS system and other public safety sensitive systems is further isolated
using network segmentation technologies. Firewalls separate the justice
network from the enterprise network. Buildings within the same campus are
connected via fiber. Remote site connectivity varies between 1.5Mbps and
1Gbps. Depending on the criticality of the site, a lower-bandwidth backup link
may also be in place. Desktop connectivity is comprised of 10Mb and 100Mb
connections.
o
Sheriff’s Office Administration Buildings Network Environment: A high speed,
redundant IP-based network utilizing Cisco equipment is installed to support the
various user groups. 100 MBPS Ethernet will be available at all desktops via
copper infrastructure serviced by a fiber optic based Gigabit Ethernet backbone
SERIAL 11086- RFP
within the PSAB. The Intranet and the PSAB network are capable of carrying
voice, data and video simultaneously.

Mobile Computing: The County utilizes Verizon Wireless as its primary wireless data
solution to support the operations of the Sheriff’s Office. Connectivity to the Mobile
Data Computers (MDCs) is via CDMA EV-DO cellular communications utilizing
TCP/IP protocol. This system links the response vehicles of the Sheriff’s Office to the
County’s CAD/RMS system. CAD also forwards mobile-initiated ACJIS requests via a
dedicated T1 connection to the Arizona Criminal Justice Information System (ACJIS)
operated by the Arizona Department of Public Safety (DPS) to conduct federated queries
against state and federal databases.

Mobile Hardware: The MDCs consists of 200 Panasonic Toughbooks. Transmitting
speed of this CDMA wireless data system is consistent with EV-DO standards in the
center of the County, and a minimum of 1xRTT speed in the outlying areas. The
County’s Panasonic Toughbook CF-30K standards are as follows:
o
o
o
o
o
o
o
o
Intel Core 2 Duo SL7300 1.6GLV (Centrino2)
13.3" Touch XGA 1024x768 Monitor
3 GB memory
160 GB hard drive
Internal Intel WiFi a/b/g/n with pass through to external antenna
Windows XP Professional with SP2
Bluetooth capable / No Optical Drive
DVD (r/w) in CF30’s
MCSO has various models of the Panasonic ruggedized laptops in service (CF-29’s, CF30’s, and CF31’s). The MDC’s communicate via Bluetree 5600 series CDMA modems
throughout the Verizon wireless network. These modems have 2 signal antenna ports and
1 GPS antenna port. The GPS information is currently only utilized locally for a Streets
and Trips application. The Franson GPSgate server has the capacity to utilize the GPS
data for CAD related AVL, but is not currently utilized. All of the data from the modems
goes through the laptops to ensure that it is encrypted through Netmotion. The MDC’s
are running MS Windows OS (currently XP or Windows 7). The CF29’s will not run
Windows 7 OS. Future MDC’s must be laptop computers with the capability to run
standalone applications. They cannot be simply terminals that attach to a remote
application.
The MDC’s are mounted in the vehicles using LEDCO single pass through docking
stations with WIFI antenna and external USB ports. The docking stations have their own
power supplies and charge guards which protect the vehicles batteries.

Mobile Applications:
o
o
o
Mobile CAD Applications: Are provided by the PRC Public Safety Suite, a
COTS product. The application allows officers to receive calls for service and
send text messages to dispatchers and other cars. This interface also allows
ACJIS federated queries for vehicle, person and warrant information.
Field Reporting (FR): FR is a New World Public Safety Suite. FR allows
officers to enter all incident data directly into an automated reporting system in
the field. FR is based on a store-and-forward model utilizing CDMA wireless
infrastructure. The MDC’s have MS-Streets and Trips or MS-MapPoint
installed. The Justice Web Interface (JWI team is currently working on
mapping functionality within JWI..
Application Updates: The ability to update the current suite is provided by
Kaseya, a COTS product. This utility wirelessly transmits differential updates
to not only the CAD applications, but for any other Windows application.
SERIAL 11086- RFP
o
o
o
o
1.6
System Imaging – Desktop or mobile system refreshes are accomplished using
Altiris Deployment, an imaging system that holds master images for each
system model and make.
Mobile Encryption Security - NetMotion Mobility XE – FIPS-compliant
encryption software providing 128-bit end-to-end security and session
persistence, is our standard for all mobile computers that run ACJIS queries.
Antivirus / Network Access Control - Symantec EndPoint Protection ver. 11.0 is
deployed to all desktops and mobile computers.
Major Application Updates – Operating system updates are managed using
Microsoft Windows Server Update Services (WSUS) version 3.0.
MARICOPA COUNTY APPLICATION/HARDWARE STANDARDS:

Security Standards: The County of Maricopa complies with (and requires Vendors who
provide applicable solutions to help uphold and adhere to) the Payment Card Industry
(PCI)
Data
Security
Standard
(DSS)
(https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml), the Health
Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security
Rules.
(http://www.hhs.gov/ocr/privacy/hipaa/administrative/index.html), and the
Arizona Department of Public Safety Data and Network Security standards. Vendors
dealing with public safety ACJIS systems also must comply with the Federal Bureau of
Investigation’s Criminal Justice Information System’s Vendor agreement. Additionally,
the County of Maricopa embraces Microsoft’s Best Practices recommendations, as
included in their published documents, for the configuration of servers, applications, and
databases and for security updates and patches.

Network Infrastructure: Cisco Switched 10/100 network utilizing TCP/IP is the only
network protocol. Municipal facilities are connected through GB fiber connections with
remote locations primarily running on T1 connections. The network consists of
converged voice and data running Cisco VoIP with QOS.

Servers: HP Proliant servers running Microsoft Windows 2008 R2 64-bit operating
systems (latest Service Pack and Critical Updates applied), Windows 2008 R2 64-bit
Active Directory, Trend Antivirus, Symantec Backup Exec 2010 R2 License, Agent &
Option Library Expansion, HP System Insight Manager agents, and QLogic SanSurfer
agents for blade server connectivity and management of SAN.

Supported Virtual Environments: VMware vSphere 4.1

Storage Area Network: HP EVA4400 attached to Brocade 24/4 SAN switches within
the HP c7000 blade enclosure.

Databases: Microsoft SQL Server 2005 / 2008 R2 Standard Edition in place, Enterprise
Edition purchased when required, with latest service packs and critical updates.
Microsoft enterprise per seat licensing in place, per processor purchased as needed.

Web Application Servers: Currently using but not limited to: Microsoft IIS, Cold
Fusion MX7.0, and Apache-Jakarta-Tomcat Servlet.

Web Servers: Windows 2003 R2 32-bit & 64-bit / 2008 R2 64-bit.

Web Applications: Currently using but not limited to ASP/JSP/ASP.Net.

Email: Currently maintained on Maricopa County OET network, running Exchange
2007 w/no encryption in place and Outlook 2003/2010 Client on local MCSO / CHS
systems.

Application Systems: Client-server or browser-based clients.
SERIAL 11086- RFP
1.7

Reporting Tool: Access and Excel, Rigel Analyst, and ATAC applications that can
produce reports as well).

GIS:
Arc View with Extensions (3D Analyst and Spatial Analyst) Single User
o
o
o
o
o
o
o
o
o
o
o
o
o
Arc View Single Use Primary – MCSO EOC
ArcInfo Concurrent Use Primary
ArcInfo Concurrent Use Secondary
ArcGIS Spatial Analyst Concurrent Use
ArcGIS Spatial Analyst Concurrent Use Secondary
ArcGIS 3D Analyst Concurrent Use Primary
ArcGIS 3D Analyst Concurrent Use Secondary
ArcGIS Publisher Concurrent Use
ArcGIS Tracking Analyst Concurrent Use
ArcGIS Server Advanced Enterprise - Up to Four Cores Maintenance
2 - Arc Pad
ArcGIS Explorer & ArcReader (accessible free downloads)
The Sheriff’s Office is currently running version 9.3.1 but have the ability to
upgrade to version 10.
SHERIFF’S OFFICE DESKTOPS:

Dell hardware standard, OptiPlex 780 Mini-tower or SFF depending on desk space,
Microsoft Office 2010 Suite, Trend Anti-Virus, LANDesk Client Management Suite
license & LANDesk Patch Manager Subscription. Desktop standards are:
o
o
o
o
o
o
o
o
o
1.8
Processor: Intel® Core™ 2 Duo E8400 with VT (3.0GHz, 6M, 1333MHz FSB)
Memory: 4GB DDR3 Non-ECC SDRAM,1333MHz, (2 DIMM)
HDD: 160GB 10,000 RPM 3.5" SATA, 3.0Gb/s Hard Drive with 16MB Cache
Video: 256MB ATI RADEON HD 3450 (2 DVI /1 TV-out), Full Height
DVD: 16X DVD+/-RW and 16X DVD,SATA,Data Only
Monitor: Dell Professional P190S 19in HAS Monitor, VGA/ DVI
Speakers: Dell AX510 Sound Bar for all Ultra Sharp Flat Panel Displays (Black)
Warranty: 3 Year ProSupport and 3 Year NBD Onsite Service
Windows 7 w/SP1
PRINTERS:
Samsung Blk & Wht Laser ML-4551DN(Network Printer)

Samsung Color Laser CLP-770ND (Network Printer)

Samsung Color Laser CLP-315 (USB Only)

Samsung Blk & Wht SCX-4826FN (All In One Printer)

Samsung Color CLX-3185FW (All In One Printer)

Samsung Blk & Wht Laser ML-2525 (USB Only)

LEXMARX 2581 DOT MATRIX

HP JET DIRECT 300x (A Network Card)

HP470B (Portable printer)

Printing & Scanning Devices: Model recommendations depend on low, medium & high
volume needs. Those presented above are the most common purchases based on our user
needs. There are various models to choose from with multiple options to consider
(Duplex printing, network capable, additional trays, etc.)
1.9
REMOTE ACCESS:

Cisco VPN, Citrix Application Server.
SERIAL 11086- RFP
1.10
1.11
PUBLIC SAFETY RADIO SYSTEM:

The County currently operates on a Motorola P-16 800 MHz 15 site trunked radio
system. The current portable radios are Motorola XTS3000, XTS5000, MTS2000, and
XTS2500 and are capable of GPS location with the addition of a GPS Microphone. The
current mobile radios are Motorola ASTRO Spectra, XTL5000, MCS2000, and XTL2500
and were not purchased with a GPS location receiver. Additional bandwidth is needed to
meet channel capacity for the system to meet the needs of the Sheriff’s Office for the next
10 years. Currently Maricopa County has approximately 7000 radios on the system with
about 4000 of them used by the Sheriff’s Office. The other radios are deployed to the
other Maricopa County Departments and City agencies contracted to be on the radio
system. Interoperations with neighboring jurisdictions are with approved talkgroups on
those agencies radio systems, Console patches and Interagency channels.

Maricopa County is in the 1st stage of implementation of a Motorola P-25 radio system.
From time of approval to completion is estimated to be 5 years.

The new radio system will add 700MHz frequencies and be a mixed hi-low site
configuration. The County will be adding approximately 40 towers for approximately
95% portable radio street level coverage.
PUBLIC SAFETY PHONE SYSTEM:

The 9-1-1 dispatch center phone system is provided by Maricopa Regional 9-1-1, which
was implemented in 1985 through a partnership between the county, municipalities and
the Mountain Bell telephone system (precursor to Qwest). E-911:
o
o
o
o
o
o
o
o
o
1.12
Viper 2.0.0.8
Positron Power911 5.2 SP1 (5.2.1.40)
Power MIS 4.2 SP1 (4.2.1.109)
PowerMAP 3.2 (to be upgraded to 4.0 within 12 months)
Logging and Recording:
NICE AIS Administrator 1.16.3.0
IP Logger Digital 9.10.05.33 SP5
Analog Gigital 9.6.03.24
Master Time Clock: Spectracom 91890 (NTP Protocol) / Net Clock GPS
COMPUTER TELEPHONY INTEGRATION (CTI) POSITRON POWER VIPER:





Call information display (caller's number (ANI), number dialed (DNIS), and Screen
population on answer, with or without using calling line data - Together VIPER 2.0 and
Power911 displays ANI and ALI information and is capable of providing traditional
caller-id and inbound trunk identification. The system can be upgraded to handle
QSIG/PRI interfaces from a telco or legacy PBX and is SIP capable. Positron has
partnered with Cisco and can integrate (through IP firewalls) with Cisco Call Manager
based telephony systems.
Automatic dialing and computer controlled dialing (fast dial, preview, and predictive
dial.) - Power911 provides redial capability along with extensive customizable "phone
book"/rolodex functionality. It is not a predictive dialer.
Phone control (answer, hang up, hold, conference, etc.) - Together VIPER 2.0 and
Power911 provide answer, transfer (supervised and unsupervised), hold, park, conference
and barge/monitor functions.
Coordinated phone and data transfers between two parties (i.e. pass on the Screen pop
with the call) - Together VIPER 2.0 and Power911 provide 911 transfers (intrasite and
between regional 911 centers).
Call center phone control (logging on; after-call work notification) - Together VIPER 2.0
and Power911 can require a user to login with individualized credentials. The system can
support ACD functionality, but it is currently not employed for Maricopa.
SERIAL 11086- RFP



1.13
Advanced functions such as call routing, reporting functions, automation of desktop
activities, and multi-channel blending of phone, e-mail, and web requests - PowerMIS
provides for call center and telephony activity monitoring. The current version of
VIPER/Power911 does not support "nontraditional" contact implements (email, web chat,
SMS). It is expected that as industry standards evolve in these areas that support will
become available on the VIPER/Power911 platform.
Agent state control (i.e., after-call work for a set duration, then automatic change to ready
state) - The system can support ACD functionality, but it is currently not employed for
Maricopa.
Call control for Quality Monitoring/call recording software. - Barge/monitoring
functionality is supported along with short and medium term call recording (ICC-instant
call check and ITRR-integrated telephony and radio recording). These do not take the
place of traditional long term logging/recording and have relatively limited capability for
supervisor/user sharing of recordings.
GEOGRAPHIC INFORMATION SYSTEMS (GIS):
The Maricopa County Sheriff’s Office has invested significant resources to develop in-house GIS
services.

Hardware: The MCSO GIS maintains one production server:
o
o
o
o
o
o
o
BL460c Blade Servers (Half-Height Blade - High End, 2Proc, 12GB)
HP BL460c Intel Xeon 2P QuadCore E5450 3.0Ghz Blade Svr
HP 12GB Reg PC2-5300 6x2GB Low Power Memory
2 x HP 146GB 2.5 SAS 10K Hard drive (RAID 1)
HP 64MB BBWC upgrade for E200i Smart Array Controller
Qlogic QMH2462 4Gb FC HBA for c-Class
HP 4y 4h 24x7 c-Class Svr Blade HW Supp (w/ Disk Media Retention)
The blade will connect to the drives via fiber channel and all of the data will be backed
up on a centralized tape library.

Software: Environmental Systems Research Institute (ESRI) based application platform
for server and client side access. Inventory includes Arc View with Extensions (3D
Analyst and Spatial Analyst) Single Use Primary.
o
o
o
o
o
o
o
o
o
o
o
o

Arc View Single Use Primary – MCSO EOC
ArcInfo Concurrent Use Primary ArcInfo Concurrent Use Secondary
ArcGIS Spatial Analyst Concurrent Use Primary
ArcGIS Spatial Analyst Concurrent Use Secondary
ArcGIS 3D Analyst Concurrent Use Primary
ArcGIS 3D Analyst Concurrent Use Secondary
ArcGIS Publisher Concurrent Use
ArcGIS Tracking Analyst Concurrent Use
ArcGIS Server Advanced Enterprise - Up to Four Cores Maintenance
2 - Arc Pad
ArcGIS Explorer & ArcReader are accessible downloads for free
Currently running version 9.3.1 but have the ability to upgrade to version 10.
Data: MCSO GIS maintains five main layers of data.
o
Street Centerline (approximately 300,000 records)
o
District (40 Polygon Records)Beat (103 Polygon Records)
o
Beat (103) Polygon Records
o
Reporting Areas (3247 Polygon Records)
o
City Boundaries (535 Polygon Records
SERIAL 11086- RFP

Most interaction has been as a result of map product requests and specific Sheriff’s
Office GIS Framework data theme updates (districts, beats, reporting areas, etc.). The
current situation for various aspects of enterprise GIS (IT GIS responsibilities) are as
follows:
o
o
1.14
MDC Mapping Tool: MS-Streets and Trips (or Map Point) and JWI
Maricopa 9-1-1 Addressing: (Phoenix Fire) Provide extracts of both point
addressing and transportation (centerline) feature classes for use in the
Maricopa911 PowerMAP. This is done quarterly (or upon request) – there may
be a need to formalize this process in the future, especially with respect to
address changes. The Maricopa911 Power map is utilized by 9-1-1 Staff for
response mapping (currently).
MARICOPA COUNTY ENTERPRISE GIS:
The current Maricopa County GIS structure is a modified decentralized model, governed by a GIS
steering Committee while maintaining GIS autonomy within the departments. Data sets generated
by the different departments are available in a centralized area for all county departments to use.

Hardware:
Hardware varies by department, but they follow the attached schema for serving and
using GIS data.
o
o
o

GIS Power Users use a high end workstation – Dell Precision T7500
GIS users that do not develop applications and use GIS for mostly viewing
purposed use a low end workstation – Dell Optiplex GX780
Internal and External Servers:
- 16 Core Xeon Class, 48GB RAM, 3TB Storage
Software:
Maricopa County has a negotiated enterprise license agreement with Environmental
Systems Research Institute (ESRI) that allows unlimited deployment for the most current
release of the following modules:
o
Desktop Software:
ArcInfo, ArcEditor, ArcView
o
Desktop Extension Software:
Spatial Analyst, 3D Analyst, Geostatistical Analyst, Network Analyst,
Publisher, Schematics, ArcScan, Maplex, Workflow manager & ArcPress.
o
Server Software:
ArcGISServer (Basic Workgroup, Standard, Advanced or Enterprise)
ArcGIS Server Extensions – 3D, Network, Spatial, Geostatistical,
Schematics, Workflow and Image Extension.
o
ArcGIS Engine Runtime Extensions:
3D, Spatial, Geo-database Update, Newtwork, Schematics & Maplex.
Assessor’s office uses Oracle Spatial, while Public Works, RDSA and Recorders
office use SQL Server for database management. Autodesk Mapguide is used for web
applications by PW and the Assessor’s office.

Data: The table below shows the data sets available to all Maricopa County employees.
Some of the data sets are generated internally within the County, while others are
acquired from external providers. Examples of external data sets not maintained by the
county include soils information, Census data, schools, hospitals, etc. Aerial photography
is acquired on an annual basis since 1998. The oldest data set dates January 1930. Since
then, multiple years have been acquired and the extents of the coverage of the images as
SERIAL 11086- RFP
well as the resolutions are available via the
http://www.maricopa.gov/assessor/gisPortal/gis_portal.asp)
Maricopa
GIS
portal.
Not all data sets contain comprehensive coverage information. For example not all
construction As Builts have been scanned and attached to the GIS data set.
[This space left intentionally blank]
SERIAL 11086- RFP
Category
Administrative and
Political
Aerial
Photography
Atmospheric
Climatic
Cadastral Land
Planning
Cultural
Demographic
Emergency
Management
Environmental /
Conservation
Facility /
Structures
Data Set
Departments Updating
Data Sets
Type
Congressional , School, Supervisory &
Fire Districts
Voting Precincts
No Fence Districts
Zip Codes
jurisdictional Limits
All Geographic Features Depicted in
USGS Quads
Traffic and Regional Analysis Zones
Project's Extents
Public Works / Recorder's
Office / Assessor's Office
Vector
Annual Aerial Photography
Flood Control
Rain/Temperature/wind velocity Gauges
Desert Spaces
Subdivisions
Employer
Landfills
Land Ownership ( BLM / Private / State
Land)
Land Use
Parcels
Residential Completions
Sand & Gravel Operations
Flood Control
U. S. Census Data
Palo Verde Nuclear Power Plant
evacuation zones
Palo Verde Nuclear Power Plant
Barricades
Palo Verde Sirens / Wind Vectors /
Sectors/ Field Teams
Dam Break Evacuation Zones
Spillway inundation areas
Hazmat Sites
Vegetation / Wilderness areas
Biotic Communities
Landscape Characteristics
Noise Contours
Riparian Vegetation
Air Quality
Building Footprints
As Builts
Dams
Industrial Sites
County Owned facilities
Landmarks: Museums, shopping centers,
airports, colleges, justice courts, post
offices, libraries, Golf courses, cemeteries,
rest areas, sport venues
Raster
Public Works /RDSA/
Recorder's Office / Assessor's
Office
Vector
External - US Census Bureau
Vector
Emergency Management/
Public Works /RDSA/
Recorder's Office / Assessor's
Office
Vector
PW/RDSA/External
Vector
Public Works /Assessor's
Office/ External
Vector
SERIAL 11086- RFP
Floodplain Delineations
Cross sections, Base Floor elevations,
Elevation Certificates and Flood Events
Faults, Geology, land forms,
Physiography, sols, erosion, Land
subsidence and Fissures
Flood
Geophysical
Vector
External
Vector
PW/ Assessor's/
External/Recorder's Office
Vector
Flood Control / External
Vector
Section Corners, Miscellaneous Control,
GDACS, Section Lines, Township and
Range grid.
Transportation / Assessor's
Office
Vector
Emergency Care, Hospitals, Fire Stations,
PM10 Monitors
PW / Public Health/ External
Vector
County Parks, Neighborhood parks, Golf
Courses, Trails
Parks & Recreation
Vector
Topographic Data, NAVD88 & NGVD29
PW
Vector
Transportation/ Recorder's
Office / Assessor's Office
Vector
SRP
Vector
Stage lines, historical voting precincts,
towns, forts
Canals, Drainage Basins, Lakes, Rivers,
Springs, Watersheds, wells, Wet
Crossings, Ground Water
Historical Data
Hydrology
Land Survey
Public Health
Recreation
Terrain
Transportation
Streets, Bridges, Railroads, Signs, Road
Closures, Valley Metro, Accidents
Transmission Lines, Substations, Gas
Companies, Waste Water Plants
Utility
1.15
Flood Control
COPLINK
Maricopa currently utilizes the COPLINK investigation tool and host their own database. The
intent is to automatically export new RMS data into COPLINK daily.
1.16
SHERIFF’S OFFICE SOFTWARE LICENSE REQUIREMENTS:
1.16.1
Initial Implementation Software License Requirements (Refer to Attachment A to
provide detailed pricing).
TYPE
LOCATION/USER
COUNT
COMMENTS
Please provide a per seat price for CAD Full
Function licenses along with any other options
that could lower the overall cost.
CAD Full
Function
Communications
28
CAD Full
Function
CAD Full
Function
Total:
Probation
15
Systems
Administrators
2
CAD
Enterprise
Network
Viewer
Total:
45 42
Unlimited
Unlimited
Allows users to view patrol activities without
the ability to dispatch units. If the vendor can
offer an enterprise viewer with more than
query capabilities, please explain the
additional functionality provided and price
separately from any query only offering.
SERIAL 11086- RFP
RMS
Enterprise
Consider the need to be no less than 400
concurrent and propose the best option.
Field
Reporting
Enterprise
Mobile Data
Enterprise
The goal is to have field reporting in all patrol
vehicles and on laptops used by
Detectives and specialty units. Over several
budget cycles the license count may
grow to 700 or more. Vendors should
assume that MCSO will initially
equip/license 250
vehicles/laptops with plans to increase this
number as quickly as funding will allow.
Vendors are asked to propose a licensing
plan that will meet the initial 250 license
requirement, and the best licensing option
for the County’s plans to increase this count
to 700 or more.
Apply above comments.
1.16.2 Additional Software Licenses Subject to Availability of Funding:
TYPE
LOCATION/USER
COUNT
COMMENTS
It is unknown at this time the nature of the
Civil Process Modules that are going to be
bid. Will they be bundled under RMS or
priced as separate options. If they are bid
as separate options, provide a seat price for
each option. An option in this definition
would be Service of Legal Documents,
Foreclosures, Extradition etc.
Please provide seat pricing for this option
and the interfaces that support it. If volume
discounts are available, please provide
them.
Any modules being bid that are not bundled
in with CAD or RMS must be clearly
identified and seat pricing must be
provided. This description covers modules
like Personnel, Field Training, Citizen
Reporting, etc. when offered as options as
opposed to being bundled.
CAD Full Function Licenses in this row
and below will not be utilized on a regular
basis. If costs can be reduced by obtaining
an agreement for 50 concurrent licenses,
vendors are asked to offer this option or
other alternatives to lower costs.
Civil Process
Civil Process Division
TBD
e-Citation
Patrol/Field Ops.
TBD
Other
Modules
Sheriff’s Office
TBD
CAD Full
Function
Emergency Ops./
Counter Terrorism
9
CAD Full
Function
CAD Full
Function
CAD Full
Function
Total:
Ball Park
1
EOC
5
Spares
2
16
SERIAL 11086- RFP
RMS
Enterprise
Network
Viewer
2.0
TBD
If a vendor can offer a reduced function
RMS license that will meet the needs of the
County Attorney’s Office, the Sheriff’s
Office would prefer this approach,
assuming it will lower overall licensing
cost. Please provide seat costs and a
description of the capabilities provided.
SCOPE OF WORK:
2.1
Sheriff’s Office Project Goals and Objectives:

The Maricopa County Sheriff’s Office wants to complete a technology refresh that will
include new CAD, RMS, Mobile, Field Reporting, Civil Process and other systems.
Vendors are being asked to include all supporting hardware necessary to meet
performance requirements,

As a result of the requirements development process, management and organizational
commitment to an integrated solution over a best of breed solution was re-affirmed. The
intent is to purchase a Consumer Off the Shelf (COTS) product that can be configured,
and minimally customized, to meet the needs of the Sheriff’s Office. As there is a high
degree of business process change inherent in the implementation of a COTS solution,
over the next few months, Focus Groups will be developed to assist in the change
process. The success of the new system will be tied to buy-in from end users and it is
expected the CAD/RMS/MOBILE/CIVIL PROCESS Vendor partner will play an
important change management role during the implementation of the new system.

MCSO wants to implement an up to date technology solution that allow for future
integration and data sharing with the Arizona Department of Public Safety, Maricopa
County, regional law enforcement hubs and state and National Information Sharing
Systems.

Planning and full implementation of the CAD/RMS/MOBILE/CIVIL PROCESS system
will be a challenging project which will be broken into phases with identified outcomes
based on the Vendor recommendation for project phasing and organization

In response to the vendors request for extension of the submission date, the County
has reviewed the procurement schedule and the impact on the County's
construction project and determined that submission opening date would be
extended to September 9, 2011. This procurement and the implementation of the
selected solution are closely linked to the MSCO Headquarters construction
schedule which requires hardware installation in the new facility no later than April
2013. No extensions to the construction schedule will be authorized.

The Maricopa Sheriff’s Office strives to be goal oriented, problem solving, and data
driven. Decisions must be based on quality data, and solutions must reduce redundancy
and increase efficiency. Business and Technology solutions provided in the new
CAD/RMS/MOBILE/CIVIL PROCESS systems must work together to improve
productivity by:
o
Reduce redundancy and repetitive action across the organization;
o
Enhance the ability to measure the effectiveness of strategies and tactics in a
timely manner;
o
Improve the ability to analyze the deployment of personnel and resources;
o
Improve the quality of products and services;
SERIAL 11086- RFP
2.2

The Sheriff’s Office expects that the new CAD/RMS/MOBILE/CIVIL PROCESS system
will provide public safety first responders with ready access to the tools that allow them
to share tactical information, often in real time and on-site, and with potentially a number
of different entities such as emergency management agencies; neighboring PSAPs and
Sheriffs; as well as State of Arizona and federal authorities including Department of
Defense components. Within the County of Maricopa, the CAD/RMS/MOBILE/CIVIL
PROCESS system will provide the foundation for a number of important ancillary public
safety systems that support various management and analytical processes. In addition,
future improvements to this environment may include expanding the system into an
integrated criminal justice system by connecting to systems in the courts, probation and
other relevant entities.

The CAD/RMS/MOBILE/CIVIL PROCESS system will serve as the core of this
integrated, comprehensive public safety information management system. As a result, the
technical architecture of the CAD/RMS/MOBILE/CIVIL PROCESS system is critically
important. The technical architecture proposed by the Vendor must address the
requirements listed in this RFP and also provide the foundation through an open
architecture that enables the County of Maricopa to meet future needs with greater ease
and agility. Since many of the components of this future environment will be outside the
realm and/or control of the Sheriff’s Office, it is imperative that the
CAD/RMS/MOBILE/CIVIL PROCESS system be based upon widely-adopted technical
standards that facilitate integration and interoperability with external entities seamlessly.
Firm’s Experience/Product History:
















Number of years in business selling CAD/RMS/Mobile products and services
Number of years performing CAD software development
Number of years performing RMS software development
Number of years performing Mobile application development
Number of years performing Field Reporting (i.e., Incident and Traffic Crash reports)
software development
Number of years performing Civil Process application development.
Number of employees dedicated to CAD (support, development, implementation, etc.)
Number of employees dedicated to RMS (support, development, implementation, etc.)
Number of employees dedicated to Mobile (support, development, implementation, etc.)
Number of employees dedicated to Civil Process (support, development, implementation,
etc.)
Date of original release of the version of the CAD/RMS/Mobile and Civil Process
applications proposed for Maricopa County
Date of three most previous major version updates to the CAD/RMS/Mobile and Civil
Process software suites proposed for Maricopa County
Number of CAD/RMS/Mobile clients in the United States
Number and location of CAD/RMS/Mobile client sites in the State of Arizona
Number of installations of the proposed version of software (CAD/RMS/Mobile and
Civil Process) that is on a scale comparable to the Maricopa County Sheriff’s Office and
serviced population
For each comparable implementation, please identify the name of the public safety
agency and (Note: Include No more than 10 of the most recent projects, if applicable):
o
o
o
o
o

Number of CAD licenses
Number of RMS licenses installed
Number of Mobile Data Computer Licenses
Number of Field Reporting licenses
Number of calls of service or population size
List all CAD/RMS/Mobile system contracts completed in the last three years similar to
Maricopa County Sheriff’s Office proposed project
SERIAL 11086- RFP


2.3
Firm’s Project Management Plan:

2.4
List the names of public safety agencies, if any, that have defaulted or are in the process
of defaulting an existing CAD/RMS/Mobile and Civil Process contract with your
company in the past five years
Are all product lines proposed for Maricopa County developed internally by the Vendor?
Yes/No
This major Sheriff’s Office information technology projects that include the
CAD/RMS/CIVIL PROCESS and MOBILE applications will be managed by County’s
Project Managers with operational oversight provided by the Sheriff’s Office Information
Technology staff who report to the Chief of the Technology Management Bureau.
Project sponsorship is through County resources for the project are staffed and managed
through a matrix management project structure. A project steering committee will
oversee the CAD/RMS/CIVIL PROCESS and MOBILE project. Vendors shall describe
below how their Project Management Plans will complement the County’s Project
Management structure.
Project Management Approach:

The Vendor shall describe the management, technical and organizational approach;
resources, and controls to be employed to successfully accomplish project planning, and
schedule requirements.

After contract award the Vendor will prepare and submit to the Maricopa County
Sheriff’s Project Manager for approval a Statement of Work to include:
o



2.5
Project Schedule:

2.6
Detailed steps on how the vendor will accomplish each of the major proposed
phases of the project, to include:
o
Project Planning and Initiation
o
System Design
o
System Configuration
o
System Testing (to include Whole System Testing)
o
System Administration, other Technical including GIS) and End User Training
o
System Cutover
o
Transition to Maintenance and Support
All features of Vendors base system that are available in the base system price, but not
included in the County’s functional and tech specs
o
Final Implementation Plan
Payment schedule should be based on major project milestones and deliverables (note
that it is the policy of the County not to tie any payments to the signing of the contract)
County expects the Vendor to include a retainage in its price proposal.
Vendor must provide draft project schedule in MS Project 2007 or earlier format utilizing
a Work Breakdown Structure (WBS) format including resources and milestones. The
intent of Maricopa County is to develop and maintain a shared project schedule that
includes all Vendor and County tasks and activities. Implementation schedule should
incorporate the major subproject implementation phases such as CAD, RMS, Mobile, FR,
etc.
Vendor Project Staffing Plan:

Given the high profile nature of this project, the County’s Facilities Project Manager and
the Sheriff’s Office expect best in class project management services from the Vendor.
The County expects the Vendor will work closely in conjunction with County’s Facilities
Project Manager, the Sheriff’s Office and Winbourne Consulting Inc (WCI) who have
SERIAL 11086- RFP














2.7
been designated by the County as the Integration Oversight Consultants. The County
will only accept Vendor personnel who have significant and relevant experience with the
Vendor’s CAD/RMS/CIVIL PROCESS and MOBILE system and can show a successful
track record at locations of similar size and complexity as the Maricopa County Sheriff’s
Office.
Vendor must identity proposed staffing resources and Level of effort for each major task.
Also include an organization chart for proposed project personnel, including proposed
sub-contractors.
Expectation of Maricopa County Sheriff’s Office staffing resources and Level of Effort
for each major phase, including expected skill set needed to successfully complete each
task.
List key personnel that will be assigned to the project.
Resumes of all key staff that provides sufficient information to allow the County’s
Facilities Project Manager, the Sheriff’s Office and Winbourne Consulting Inc (WCI) to
evaluate their capability and qualifications to perform proposed tasks.
Describe roles and tasks for all key personnel.
Identify whether this is their major assignments, and a projection of other assignments
they may be working on during the implementation period.
Describe for all key personnel what percentage of time will be on project.
Provide information regarding who will be on site for each major phase of the project,
and who will be remote.
Provide an organizational chart of all personnel proposed for the project.
Describe the Vendors Communications Plan that will be used for this project.
The Maricopa County Sheriff’s Office is concerned there will be a significant increase in
long-distance telephone calls during the life of this project. Please provide any possible
solutions to this potential cost increase.
Describe the Vendor’s escalation process of issues.
Describe the facilities and equipment that the Sheriff’s Office is required to provide onsite staff.
Identify Vendor tasks to be performed on-site.
Additional Vendor Requirements:

All Vendor personnel assigned to work on-site on the CAD/RMS/CIVIL PROCESS and
MOBILE project shall be required to undergo a criminal history check. Off-site
personnel may also be subject to a criminal history check. Please note that arrangements
for required criminal history checks should be made in advance with appropriate County
personnel. The County reserves the right to reject any personnel proposed by the Vendor
for any reason. All key personnel will be required to sign a confidentiality agreement for
access to sensitive data. (Refer to Exhibit 5 for Security Guidelines).

The Vendor’s Project Manager is expected to coordinate and participate in all activities
related to Vendor demonstrations, if shortlisted. County’s Facilities Project Manager, the
Sheriff’s Office and Winbourne Consulting Inc (WCI) prefer the following:
o
o
A Prime/Subcontractor relationship
The Vendor’s Project Manager to be PMP certified

Key personnel will not be removed without prior permission from Maricopa County’s
Facility Project Manager. The County’s Facilities Project Manager, the Sheriff’s Office
and Winbourne Consulting Inc (WCI) also reserves the right to review the background
and resume of any proposed replacement vendor PM, and unilaterally reject any
replacement proposed vendor Project Manager.

The prime contractor shall be a Tier 1 vendor in the specific business of providing
CAD/RMS systems for a minimum of twenty-five (25) years and support more than 500
public safety clients’ organizations. The company's history must depict a strong heritage
in the public safety software business with progressive growth of more than 200
SERIAL 11086- RFP
employees directly supporting their public safety. The vendor must be an active member
of the National Emergency Number Association (NENA) and the Association of PublicSafety Communications Officials (APCO). Products offered by the bidding vendor must
be open source and interoperable with the Next Generation 9-1-1 initiatives for public
safety technology. (Refer to Attachment C)
2.8
Project Reporting:

2.9
Project Status Reports:

2.10
The Vendor’s Project Manager will provide weekly project status reports detailing
relevant information to the County’s Project Manager.
Implementation Management Plan:

2.11
The Vendor shall participate in a weekly Project Meeting to report progress toward
contract deliverables, update status from the previous reporting period, and advise current
objectives, problems or delay issues, proposed corrections and other relevant
information.
Please describe how your implementation planning activities incorporate all of the major
phases (Initiation, Planning Execution, Monitoring & Control, and Closing).
Implementation Approach:

Responses should also detail the vendors’ approach to the following:
o
o
o
o
o
2.12
Change Management:



2.13
Describe the Vendor’s process to complete each major implementation phase
within each subtask (i.e. CAD, RMS, Mobile, AFR, Civil Process etc.).
Describe the Vendor’s methodology to prepare servers (i.e., completed on-site
or at the Vendor’s location).
Describe the Vendor’s Deployment plan of all phases and why this methodology
is being proposed.
Describe the Vendor’s Risk Management plan that will be used to ensure
successful implementation of all phases.
Describe the Vendor’s Quality Management plan that will be used to ensure
successful implementation of all phases.
The County’s Facilities Project Manager, the Sheriff’s Office and Winbourne Consulting
Inc (WCI) understands the implementation of a new CAD/RMS/MOBILE/CIVIL
PROCESS and Field Reporting systems will require new business processes and a change
in policies, procedures and training protocols.
Please describe any Change Management solutions provided by the Vendor that are a
component of the proposal
If no Change Management solutions are provided in the proposed solution, does the
Vendor offer Change Management consulting services? If yes, describe the options for
Change Management consulting services and provide all relevant costs in the Cost
Proposal Worksheet.
Data Migration Plan:

The offeror shall include a detailed Data Conversion Plan that describes all vendor and
Maricopa County Sheriff’s Office processes and activities required to successfully
migrate relevant Maricopa County Sheriff’s Office legacy data from their PRC CAD,
their RMS, and from other internal systems identified herein, into the offeror’s proposed
CAD/RMS systems. If Civil Process modules are bid and/or Personnel modules data
SERIAL 11086- RFP
from an Access program will also need to be migrated. Vendors shall submit a migration
plan that includes the following:
o
o
o
o
o
o
o
o
o
o
The vendor’s proposed data conversion process.
Specific roles and responsibilities for proposed MCSO resources, as well as
recommended skills of personnel required to perform MCSO tasks.
Specific roles and responsibilities for proposed vendor resources, as well as
recommended skills of personnel required to perform MCSO tasks.
Qualification, experience and resume of a vendor resource capable of
performing an extract of the MCSO’s systems.
The vendor’s proposed automated data conversion tools.
Recommended methodologies for end-users to access non-migrated legacy data
via integrated system or separate queries.
Recommended storage location for non-migrated legacy data.
Any prior data conversion experience with the MCSO’s legacy CAD and RMS
systems. Please list the relevant projects, the versions involved, and provide
contact information for the clients.
The offeror shall include a cost for implementing the Data Conversion Plan in
Attachment A (Pricing).
Cost Proposal. The vendor must provide separate cost proposals based on the
following assumptions:
-



Vendor must provide cost to have vendor extract PRC legacy data for
conversion.
Vendor must provide cost to have vendor extract PRC legacy data for
creation of storage for non-migrated legacy data solution
Vendor must provide cost if MCSO provides PRC extract to convert
legacy data to new system
Vendor must provide cost if MCSO provides PRC extract for storage of
non-migrated legacy data solution.
Vendor must provide cost to have vendor extract New World legacy data
for conversion.
Vendor must provide cost to have vendor extract New World legacy data
for creation of storage for non-migrated legacy data solution
Vendor must provide cost if MCSO provides New World extract to
convert legacy data to new system
Vendor must provide cost if MCSO provides New World extract for
storage of non-migrated legacy data solution.
RMS data may be supplemented with detective data that resides in an ACCESS
application. It is assumed that MCSO will create a flat file of this information in the
vendor’s specified format, for the vendor to validate and load into their RMS or into a
non-legacy data solution if one is proposed. Vendor must provide cost for both options.
The Maricopa County Sheriff’s Office has utilized the current PRC CAD system for over
20 years, and its RMS system for over 8 years.. It is imperative that the last 10 years of
CAD historical data is archived and maintained in a manner that allows querying of the
data. The Maricopa County Sheriff’s Office expects that the last two years of call history
be migrated to the new CAD system along with some tabular data (i.e. code tables,
telephone lists etc.). The Maricopa County Sheriff’s Office also expects case reports for
the past two years be migrated to the new RMS, along with transportation of inmate
reports that have been entered. Vendors are encouraged to use their expertise in this area
to provide the Sheriff’s Office applicable options. The Sheriff’s Office understands there
may be many methodologies available to manage legacy data in a cost effective and user
friendly manner.
The following list of proposed legacy data candidates is to provide Vendors with
background information concerning the Sheriff’s Office’s objectives regarding legacy
data:
SERIAL 11086- RFP
2.14
Data Name
Property & Evidence Data
Time Frame/Records
All data.
Comments
It is unlikely that the Sheriff’s
Office will discontinue using its
relatively new Quetel system.
Master Entity Files (i.e.
name, address, vehicle, etc.)
All master name records and
all vehicle records.
Incident Report information
(Report narrative
information)
Two years
CAD Data, including:
a. Incident information
b. Location information
c. Hazards
Past ten years of data.
Incident Information Location, Hazards–
There are concerns regarding the
quality of some of the data. For
example, no names have ever been
merged in the Master Name File.
Many of the incident records are in
the form of a face sheet with
narratives included or contained in
attached word documents, The SO
wants to migrate as much of this
information as possible.
County has already converted
incident data back to year 2000 and
through 2010 to a SQL 2005 DB.
Data for 2011 is currently in MSAccess, but can be ported to SQL
server if needed. The plan is to
have the last two years of incident
data migrated to the new system,
and past years data available
through Access.
Operational Cut-Over Plan:

The cut-over from one CAD/RMS/MOBILE/CIVIL PROCESS systems to a new one can
present significant threats to the health and safety of the public and first responders if
problems arise. The Sheriff’s Office CAD cutover will take place in a new building
(Public Safety Answering Point) and will require an extraordinary level of coordination
and staging to avoid impacting existing operations. Cut-over activities shall be approved
in advance by the Sheriff’s Office. A cut-over working group composed of Sheriff’s
Office, CAD/RMS/MOBILE/CIVIL PROCESS, Vendor and other relevant personnel
will be formed to develop a detailed migration plan and conduct the actual cut-overs.
o
o
o
o
o

Describe the Vendor’s ability to meet the above described requirements.
Describe the process for migration from one environment to another (i.e., test
environment to production).
Describe the Vendor’s Risk Management processes to ensure a successful ATP
processes.
Contingency Plan – Please describe what contingency plan and problem
resolution measures the Vendor will have during the cut over period.
Please provide a list of previous clients who have cut-over using a plan similar
to the one being proposed for the Sheriff’s Office.
The current RMS is not being fully utilized by the majority of the patrol officers. It is a
common practice to enter only face sheet information into Field Reporting and
supplement the face sheet with narrative word document attachments. The detectives are
also using MS Word to prepare narrative attachments and maintaining case management
logs in an Access application. The RMS cut-over will be more of an initial
implementation than a cut-over from one RMS to another. With the understanding that
the RMS cut-over will involve implementing a new Field Reporting system, and a very
different approach to preparing/supplementing case reports by detectives, and a new
NIBRS reporting process, vendors are being asked to propose how this can best be
accomplished.
Should RMS be implemented following a successful CAD
implementation, or should both systems be implemented together?
SERIAL 11086- RFP

2.15
The Civil Process systems will be new implementations with little to no transitioning for
current automated systems. Vendors who are proposing any Civil Process applications
are being asked to recommend how they can best be successfully implemented.
System Test Plans:
This section outlines the Sheriff’s Office’s Testing expectations. Vendors are being asked to agree
and to commit to these expectations, or offer alternatives for consideration.
2.16
The Vendor shall be responsible for assisting Sheriff’s Office personnel with the following testing
activities:










2.16.1
The Vendor shall provide the Sheriff’s Office with draft test plans. The Sheriff’s Office
shall be responsible for developing a final unit, subsystem and system acceptance test
plan that will include but is not necessarily limited to the following:













2.16.2
Drafting a realistic test plan
Product performance testing
Interfaces testing
Parallel testing (if parallel processing is appropriate)
Security testing
Data conversion testing
Hardware and network testing
Integration testing
Load testing
Fail-over testing
Testing all software components in accordance with published functions and
features
Testing all software components
Testing all system software based on business scenarios
Testing all system software based on user friendliness
Testing of all contracted interfaces based on design and business scenario
Parallel testing prior to cutover (if parallel processing is appropriate)
Security testing
Data Conversion testing
Testing based on business scenarios
Hardware and network testing
Integration testing
Load testing
Fail-over testing
The Vendor shall review the Sheriff’s Office’s additions to the test plans for accuracy and
completeness. If the vendor wishes to perform any initial off-site testing prior to software
delivery, the Sheriff’s Office will not consider any of the off-site testing results as being
in any way a substitute for testing the software on-site using the Sheriff’s Office’s
production run-time environment and test plans. If vendor pre-delivery testing is
performed, the Sheriff’s Office may ask to see the results, but only for comparison to the
on-site results. The Sheriff’s Office reserves the right to revise the test plans provided
that reasonable notice is given to the Vendor. The Sheriff’s Office maintains sole
authority to certify the successful completion of any and all tests performed by the
Vendor on the proposed system.
SERIAL 11086- RFP
2.17
Acceptance Test Process:
The acceptance test process shall include three phases: the acceptance testing period, the reliability
test period, and the final acceptance. If at any time during the acceptance-testing period, the
system reveals any major defects or several minor defects, the process shall be terminated and the
Vendor shall resolve the outstanding issues. Once all of the issues have been addressed, the
Vendor will recommence the acceptance test period from the very beginning.
2.17.1
Acceptance Test Plan: The Vendor’s software will be delivered to the Sheriff’s Office
accompanied with written documentation of a test plan for the Sheriff’s Office to use in
their acceptance testing. The Sheriff’s Office will review the written draft of the testing
plan and schedule the installation of the software within the Sheriff’s Office test
environment. The acceptance test period will begin when the Sheriff’s Office, along with
the assistance of the Vendor, first performs all tests in accordance with the written test
plan and successfully completes the tests defined within that plan. If major defects or
numerous minor defects are found during the acceptance testing, the tests shall be
terminated and the Vendor shall resolve outstanding issues. Once all issues have been
addressed, the Vendor will recommence the acceptance test process from the very
beginning.
2.17.2
Reliability Test Period: After the successful completion of the cutover period, there shall
be a minimum of thirty (30) day reliability test period during which the newly installed
system will be in production and its performance monitored. During this period, the
system must perform fully without degradation of any kind in order for the acceptance
test to be satisfied. If any major defects or numerous minor defects are discovered, the
reliability test period shall be terminated and the Vendor shall resolve any and all issues.
Once all issues have been addressed, the Vendor will recommence the acceptance test
process from the beginning.
2.17.3
Final Acceptance: At the successful completion of the reliability test period, the Sheriff’s
Office shall issue the conditional acceptance certificate. At the end of the successful
completion of both the reliability test period and the data conversion, the Sheriff’s Office
shall issue the final acceptance certificate.
The Vendor should demonstrate through an acceptance process performance (stress) test
that the system performs as required in the Sheriff’s Office’s technical environment and
that the system meets or exceeds the Sheriff’s Office’s functional requirements. The
stress test should include all LAN connected applications (i.e., CAD, RMS, etc.). The
final Acceptance Test Plan (ATP) should have use of Sheriff’s Office’s approved data
and include report generation.




2.18
The final acceptance test should exercise all functionality and components
successfully.
MCSO should test back-up features successfully
MCSO should test and recovery features successfully.
The failure of any specific portion of a test may require that the entire test be
rerun, not just the failed portion of the test.
Training Plan:
Ensuring that all personnel are trained to an appropriate level of proficiency as the various
applications are implemented is a primary factor to the success of this project. The Sheriff’s Office
will focus considerable attention on the proposed training plan. The Sheriff’s Office shall provide
sufficient space for conducting the training and housing and securing the training equipment.
The Sheriff’s Office prefers the Vendor to utilize the Train the Trainer (TTT) approach for all
applications unless designated otherwise.
SERIAL 11086- RFP
2.18.1
Technical Support Team Training:
This group will consist of what is commonly referred to as super-users within each
functional area and will be called upon to perform any unique support functions within
their areas. Unique support functions would include maintaining area specific code
tables, and user profiles if security profile maintenance activities are distributed as
opposed to centralized. For example, if only a Detective Supervisor can forward a case
to the County Prosecutor after conducting a quality review, a Support Team member in
Investigations would determine the participants in Investigations having this capability.
Technical Support Team members are commonly selected to be Trainers within their
functional areas.


2.18.2
Please list all coursework required to fully train project team members to
facilitate participation in configuration workshops and their backup person.
For each course, please state the prerequisite requirements, size of class,
duration, and location of the class.
System Administrator Training:
The Maricopa County Sheriff’s Office has its own dedicated Technology Management
Bureau that is staffed with information technology professionals having numerous years
of public safety technology experience. The System Administrator will be one of the
Senior Analysts within this bureau and will be the Vendor’s primary contact on all
implementation and on-going support issues. The Database Administrators (primary and
backup) and the Applications Administrators will also be staffed with Technology
Management Bureau personnel.

Please list all coursework required to fully train a System Administrator and
their backup person. For each course, please state the prerequisite requirements,
size of class, duration, and location of the class. Note that the Sheriff’s Office is
interested in having the Vendor provide a phase training approach that ensures
that the System Administrator is provided the appropriate training throughout
the length of the implementation.

In addition please list all coursework required to fully train personnel that will
create security profiles for groups of end users in the system as per Arizona CJIS
requirements.


2.18.3
Database Administrator Training:


2.18.4
For each course, please state the prerequisite requirements, size of class, and
duration.
Please list all coursework required to fully train a Database Administrator and
their backup person.
For each course, please state the prerequisite requirements, size of class,
duration, and location of the class.
Applications Administrator Training:
It is the Technology Management Bureaus intent to assign personnel to support (both
technical and user) each the more complex modules within the total system. For example,
an Administrator will be assigned to support CAD and someone else will likely be asked
to support Field Reporting. Modules that are heavily used 7/24 and modules that are
mission critical will have both primary and backup support.

Please list all coursework required to fully train an Applications Administrator
and their backup person.
SERIAL 11086- RFP

2.18.5
End User Training:


2.18.6

2.18.9
Please list all coursework required to fully train the trainers that will, in turn,
train the end users of the system (i.e., Sheriff’s Office sworn and civilian
personnel).
For each course, please state the prerequisite requirements, size of class, and
duration.
Training Documentation:

2.18.8
Please list all on-site coursework required to conduct end user training for CAD,
RMS, FBR, Mobile and Civil Process separately. If additional systems are
being proposed (i.e. Personnel, Training, Property Management) include their
coursework.
For each course, please state the prerequisite requirements, size of class, and
duration.
Trainer Training:

2.18.7
For each course, please state the prerequisite requirements, size of class,
duration, and location of the class.
To meet the needs of the Sheriff’s Office, some training documentation may
require updates and/or MCSO specific customization. If the need for the update
is the result of a vendor fix or upgrade, or the result of a Federal or Arizona
State mandate, the obsolete training documentation shall be updated by the
vendor. Customization made necessary by events that are unique to the
Sheriff’s Office would be a customer responsibility. Please confirm your
willingness to support this requirement.
Training Manuals and Materials:

The Vendor shall be responsible for providing sufficient training materials and
take-away documents such as:
o
Instructor Manual(s)
o
Student Training Manual(s)
o
All manuals in Microsoft Word format
o
All manuals in other media format (HTML and Adobe Acrobat .PDF)
o
Master videos or DVDs of pre-recorded training
o
Keyboard templates
o
On-Line and Computer Based Training

All training materials must be edited to reflect the Sheriff’s Office’s specific
environment, technology, post-configured screen shots. The Sheriff’s Office
will work with the Vendor to document and edit the training materials to match
the Sheriff’s Office’s implementation state and business processes. The
Sheriff’s Office expects to receive final versions of training materials in
hardcopy and electronic formats, using the Microsoft Office suite of
applications.
Training Schedule:

Given the shift assignments of public safety personnel training courses will
often need to be scheduled outside of normal working hours, including
weekends. In order to keep the training relevant to the ultimate system lookand-feel as well as fresh as possible and still accommodate the necessary
number of sessions it is expected that training will not begin until after
SERIAL 11086- RFP
preliminary system acceptance and before cut-over, but in no case will begin
longer than 60 days prior to the scheduled “go live” date.
2.18.10 Extended Training Cycle:

The Vendor should describe their ability to ensure personnel have the requisite
skills at the time of migration if the training period was extended period of time
to get all personnel trained (i.e., Computer based training and/or refresher
training).
2.18.11 Training Plan Production Mode:

The Vendor should describe its ability to train personnel using the proposed
CAD/RMS/MOBILE/CIVILPROCESS/ system while it is in production mode.
For example, applications have a training module that allows personnel to use
the CAD/RMS/MOBILE/CIVIL PROCESS/Civil Process systems while it is in
production operation.
o
o
o
2.19
Describe the responding company’s ability to meet this requirement.
Provide a detailed training plan.
Provide all facility and logistical requirements of the Sheriff’s Office
regarding the Training Plan.
Hardware Specifications and Installation Plan:
The Sheriff’s Office reserves the option to purchase all hardware and Operating System (OS)
software separate from the Vendor’s proposal.



The Vendor shall submit detailed specifications of all hardware and OS required to meet
the performance and operational specifications described in their response.
The Vendor will install and perform initial configuration of software with County
personnel to allow County personnel to document installation and configuration process.
Provide a hardware and software installation plan.
Describe all logistics required by the Vendor and the Sheriff’s Office to complete:
o
Shipping and receiving of equipment.
o
Storage of equipment.
o
Installation, configuration and testing of equipment.
2.19.1
On-Site Prep:


2.19.2
As an option, The Sheriff’s Office may request to have the Vendor prepare
servers on-site. Describe all implications and costs (i.e., Cost Proposal
Worksheet – Options Section) if this request was made.
Vendor Product Support:
The Sheriff’s Office requires product support for the
CAD/RMS/MOBILE/CIVIL PROCESS and Civil Process systems.
includes some or all of the following:




implemented
Such support
Telephone Help Desk Support – 24/7/365 via a toll free number.
Remote Help Desk Support for the system 24/7/365. Note that remote network
connectivity will be provided for system support as required. Access must be
initiated by Sheriff’s Office personnel.
Describe your ability to meet this requirement.
List all technical support options.
SERIAL 11086- RFP

2.20
Software Updates, Warranty, Maintenance and Roadmap/ Enhancements:



The Vendor shall make available to the Maricopa County Sheriff’s Office at no
additional charge all updates to the software as they are released so long as the County is
currently under the Vendor’s software maintenance agreement, if the County decides to
take advantage of the updated version and support it under the on-site maintenance
agreement.
To ensure that documentation is consistent with the operating environment, updated
documentation shall be delivered concurrently with the software update.
Software warranty will commence at “go-live” system acceptance and will last for oneyear.
o
o
o
o
o
o
o
o
o
2.21
List the costs associated with each Technical Support option on the separate
Cost Proposal Worksheet.
Describe the Vendor’s ability to meet the above requirements.
Describe the proposed Software Warranty plan.
Describe all Vendor warranties for all applications and hardware.
Describe all Maintenance Services included in each major level of maintenance
support tiers provided i.e. software patches to major enhancements.
Describe the roadmap for each application and how the roadmap is developed.
Describe the software enhancement process for each application.
Describe the role and processes of user groups, to include the use of user groups
in the design of product roadmaps.
Describe the upgrade process, including the process and optional cost for
moving upgrades from the Test to Production environment.
Describe any other support services the Vendor may offer. Provide any
applicable costs to these services in the separate Cost Proposal Worksheet.
Interface Plan:
The Sheriff’s Office prefers that the new CAD/RMS/Mobile system be able to query, add, or
modify information stored in various third party systems. This includes federal and State of
Arizona systems (i.e., missing persons, wanted persons, stolen vehicles, stolen property, and sex
offender registries). Additionally, the new CAD/RMS/Mobile system should be able to interface
with COPLINK and other multi-jurisdictional systems through national standards such as
GJXDM, NIEM, and NCIC.
2.21.1
Vendors shall provide their proposed solution for each mandatory and optional interface
described below, including:






Methodology that will be employed.
Functionality and features.
Technical specifications.
Experience with this type of interface.
Performance specifications.
Whether the interface is COTS or will have to be developed.
2.21.2
Interface Costs - The cost for each interface shall be listed separately on the Cost
Proposal Worksheet (Attachment A). Vendors should indicate on the Cost Proposal
Worksheet the costs for all proposed options.
2.21.3
Mandatory Interfaces:

Arizona Criminal Justice Information System (ACJIS): A bidirectional, lifecritical interface between the Arizona Department of Public Safety (DPS) and
SERIAL 11086- RFP
all modules (CAD, RMS, MDC and Field Reporting). The requirement for an
interface using IBM WebSphere MQ to DPS provides Arizona access to MVD,
ACIC, NCIC, NLETS, and numerous other systems.

Arizona Criminal Justice Information System (ACJIS) Masks: The State of
Arizona ACJIS has over 250 screens for entry, queries and modifications.
Vendors should indicate the number and type (if applicable) of masks included
in their proposal. If the proposal does not include all ACJIS masks, Vendors
shall include all options to develop ACJIS masks, used for entry, modifications,
clears and removals.

Arizona Automated Disposition Reporting System (ADRS): An interface,
tying together the system’s RMS, the Sagem Morpho Automated Fingerprint
Identification System (AFIS) Livescan, ImageWare Mug Photo Interface
systems and Maricopa County Sheriff Pre-booking Portal. The initial version of
ADRS provides a web interface to justice agencies for entering disposition and
sentence data. ADRS interfaces with the Arizona Automated Fingerprint
Identification System (AZAFIS) and the Arizona Computerized Criminal
History system (ACCH). AZAFIS populates all of the fingerprint based arrests
in the State into ADRS and ADRS has a 2-way interface with ACCH.
Dispositions added, updated or deleted through ADRS are updated into ACCH
on a real-time basis. If updates occur directly into ACCH related to Arrest /
Charge information, transactions are then sent to ADRS to keep the two systems
synchronized.
http://www.azdps.gov/services/ADRS/
and
http://www.azafis.gov/. See ADRS Specifications.

Maricopa County Pre-Booking Portal: The Sheriff’s Office books prisoners
into the Maricopa County Jail. Officers need to be able to submit pre-booking
information from the RMS to the Maricopa Jail Management System. The
Sheriff’s Office would like to eliminate duplicate data entry and maintain an
arrest record for the booked prisoners in its RMS. See Pre-Booking
Specifications.

LiveScan: When the MCSO Arrest/Booking number is entered the LiveScan
system will pull arrest/subject information from the RMS arrest module
eliminating the need for duplicate data entry. See LiveScan Specifications.

COPLINK: An export, pushing incident report information from the RMS
system to the Sheriff’s Office’s COPLINK system. COPLINK’s vendor (i2) has
a contract established with AZLink agencies, of which MCSO is a member, to
implement this interface. This information includes:
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Name master file
Location master file
Accident Master File
Vehicle Master information
Accident Supplement Property
Adult arrest
Body marks
Case management assignment
Charge / Offense
Citation
Citation disposition
Drug
Field Interrogation
Incident
Young offender
Narrative
SERIAL 11086- RFP
o
o
o
Identifiers / Fingerprints
Property
Warrant

9-1-1 System Phase II Compliant: A mission-critical, user-initiated
pull interface between the Positron Power911 system and the CAD module,
delivering ANI/ALI to the CAD system.

9-1-1 System Master Clock: A mission-critical, user-initiated pull interface
between the Positron NetClock 9183 and all of the Vendor modules. The RMS,
CAD, MDC, and Report Writing applications shall all be synchronized to one
Master Network Clock such that all time stamping is synchronized. Vendor may
connect to the SNTP server provided the Sheriff’s Office.

Maricopa County Attorney: When a case is ready to submit for prosecution
the case agent needs to initiate a process that will send the CASE Report (DR)
and all textual based supplements to the case report to the Maricopa County
Attorney's Case Management System. The data transferred will be in a XML
format. Prosecutors will require the capability to further the Case Report back to
the submitting agent with instructions on what additional data needs to be
provided. This transfer back and forth will continue until the case is suitable for
prosecution, or a determination not to prosecute is reached. When the County
Attorney's Office has completed work on a case to the point that associated
evidence in the property room can be released, their system will send a status
message to the assigned case agent and the MCSO Property Room. Once such a
notice is received, the RMS should continue to remind the case agent every 30
days or until the case agent sends a property release notification to the Property
Room. The County Attorney's Office will need a TBD number of limited
function RMS seat licenses to view/hear all other records (photos, recordings,
attachments etc.) that are associated with cases that have been submitted for
possible prosecution. They will also require the capability to download any of
these records to their system. Members of the County Attorney's IS Staff will
perform the necessary programming of their system and assist the RMS vendor
with testing and acceptance. See MCSOtoCAIS for additional details.

Justice Web Interface (JWI): JWI is a software product created by a local
vendor (Pragmatica L.L.C.). Pragmatica has been working on the County’s
ICJIS project and has considerable experience in building interfaces with
various County, State and National Systems. Currently, County Warrants are
being entered into JWI by the County. JWI geocodes the warrant service
addresses for its own map display and passes the Warrants on to the State’s
ACJIS for posting. Quash transactions are handled in the same manner. The
new CAD/RMS will need to receive the geocoded Warrant and Warrant Quash
transactions in order to maintain Warrant Service Information in one of its own
map layers. Pragmatica has agreed to format the transactions accordingly. JWI is
also used by the Sheriff’s Office to query ACJIS and retrieve County Mug-shots
and MVD Driver’s License photos. This functionality will become redundant
with a new CAD/Mobile system, but the vendors may find that it is less
complicated to interface with JWI for the photos. See JWI Specifications for
further details.. See County Prosecutor Data Feed.

Maricopa County Pawn: A timed, one-way push interface between the RMS
system and Maricopa County’s Pawn System for the exchange of pawned and
stolen property information. This may not be required if the vendor proposes a
replacement Pawn system that is integrated with their RMS. For new system
requirements see Pawn Shop Specifications.
SERIAL 11086- RFP
Optional Interfaces:

Accident Reporting: Maricopa County currently uses the Arizona Dept. of
Transportation TraCS system to push or pull data with the State of Arizona
Department of Transportation, interfacing accident information between the
RMS module and the AZDoT TraCS system. The Sheriff’s Office is interested
in information regarding the Vendor’s accident reporting modules, and would
like an interface included an option in the cost proposal. See AZCR - TraCS.

eCitation Traffic Citations: A timed pull import from eCitation to the RMS
module and the County Court capturing citation information. The Court feed
needs to contain citation images as well as data.
Not all of the requested interfaces have fully developed specifications, the vendor
finalists will be provided an opportunity to meet and discuss the interfaces during the
week of vendor presentations, and, County IS Staff will do its best to further clarify
interface requirements in response to vendor inquiries. See Exhibit 7 for additional
details and contact information.
3.0
TECHNICAL REQUIREMENTS:
3.1
Standards Compliance:
The federal government has taken the lead recently in developing standards for facilitating
information sharing among local, state and federal first responders and emergency operations
managers. The proposed CAD/RMS/MOBILE/CIVIL PROCESS solution should adhere to these
standards.

National Information Exchange Model (NIEM) http://www.niem.gov/
o
o
o
o
o

Law Enforcement Information Technology
o

Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability
to meet LEITS standards.
FBI CJIS Security Policy
o

Describe compliancy with NIEM standards. List all specifications, functionality
and features related to proposed CAD/RMS version.
Describe any completed and existing projects implementing NIEM standards
relevant to proposed CAD/RMS version. Provide public safety customers point
of contact information (if applicable).
Describe current plans, processes and functionality related to N-DEX standards.
Describe any completed and existing projects implementing N-DEX standards
relevant to proposed CAD/RMS system. Provide public safety customers point
of contact information (if applicable).
Identify criminal justice entities that the company is a participant related to the
development and implementation of NIEM and N-DEX standards.
http://www.fbi.gov/
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability
to meet CJIS standards.
Arizona Criminal Justice Information System (ACJIS) and Arizona Disposition
Reporting System (ADRS)
o
All arrest data stored in ADRS is considered criminal history information and
therefore all security requirements defined in Arizona Revised Statute 41-1750
apply.
SERIAL 11086- RFP
o

National Emergency Number Association (NENA) ALI/GIS Standards
http://www.nena.org/
o
o

o
o
Describe how the company will update existing CAD systems as new NG-911
standards, functionalities and features are developed.
http://www.hhs.gov/
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability
to meet HIPAA standards.
Deviations from Standards:
o
o
3.2
Describe the company’s involvement with the development of NG-911
standards and how NG-911 will impact the proposed CAD system’s
functionality and features.
Describe any NG-911 capabilities, functionality and features of the proposed
CAD system.
HIIPA Compliance
o

The Sheriff’s Office is adopting the “NENA Recommended Formats and
Protocols for ALI Data Exchange, ALI Response and GIS Mapping”, NENA
02-010 of January 2002 as a minimal standard. All GIS/Mapping solutions
should comply with the NENA formats and standards.
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability
to meet NENA standards.
Next Generation 9-1-1 (NG-911) http://www.its.dot.gov/ng911/
o

Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability
to meet both the ADRS and ACJIS standards.
Deviations from the architecture and standards may represent a barrier to the
implementation of the County’s public safety integration and interoperability
goals and may be reviewed with prejudice.
All bidders should specifically disclose all aspects of the proposed solution
which deviate from the documented standards and desired architectures, and
provide approaches for consideration about the manner in which non-standard
components may be integrated.
Maintenance of Standards:
The Federal government and other parties such as APCO occasionally update and improve the
above referenced standards or develop new ones. In that the Sheriff’s Office may desire to adopt
such future standards, it is mandatory that the CAD/RMS/MOBILE/CIVIL PROCESS Vendor
will monitor these developments and upgrade their offerings as necessary to comply. As the time
between purchase of a CAD/RMS/MOBILE/CIVIL PROCESS system and their implementation
may be significant, it is possible that updated standards would have been released in the interim.
The Sheriff’s Office will not accept products that will be outdated by the time they are installed.
o
3.3
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS solution’s ability to meet
this standard.
Technical Environment:
3.3.1
Hardware Specifications

All hardware should be new equipment delivered in the manufacturers’ original
packaging and carrying the manufacturers’ full warranty. The warranty period
SERIAL 11086- RFP
begins after system acceptance and certification by MCSO that the equipment is
in production use.
All equipment should be installed according to
manufacturers’ requirements. All hardware components should be sized
appropriately to ensure that the performance requirements of the Contractor’s
application will be met. MCSO prefers that all servers be HP branded and that
all server systems be implemented in virtualized environments using VMWARE
server virtualization tools.
o
Describe the Vendor’s ability to meet this requirement.
3.3.2
Redundancy and Failover

3.3.3
Backup and Recovery

3.3.4
The CAD/RMS/MOBILE/CIVIL PROCESS system servers should have an
appropriate automated backup capability for system and application backup and
recovery. Backup media shall be in a format suitable for convenient off-site
storage. The system should provide differential backup schedules for various
system components configurable by the system administrator. Incremental and
full backup capabilities should be provided. All backup and recovery processes
should be subject to auditing and reporting. System backups should be
accomplished without taking the application out of service and without
degradation of performance or disruption to operations.
o
Describe the Vendor’s ability to meet this requirement.
Test/Training Environment


3.3.5
Two separate computing environments, with the ability to run concurrently,
should be provided. Automated failover to the secondary system is preferred.
Ensure that each environment is technically equivalent, duplicate servers and
workstations. Once the issue that prompted the failover to the secondary system
is resolved the systems should resynchronize and renew their prior failover roles
without any noticeable impact on performance. The Maricopa County Sheriff’s
Office will work with the Vendor to duplicate or approximate other relevant
environmental considerations such as the network and systems loading to ensure
realistic testing scenarios are facilitated.
o
Describe the Vendor’s ability to meet this requirement.
In addition to production, a separate test/training environment is required for this
application to assist with minor development, such as mask creation, and testing
service patches both for the application, as well as the server operating system.
The Maricopa County Sheriff’s Office expects to work with the Vendor to
utilize virtualization software to create a test/training environment.
The County’s preference would be to utilize the production environment during
the implementation phase to perform development, configuration and testing
activities. As part of the cut-over activities, the Vendor will migrate the final
production configuration to the Test/Training environment.
o
Describe the Vendor’s ability to meet these requirements.
o
Describe the proposed environments and the company’s migration
methodology as part of your overall proposed Detailed System
Architecture diagram and System Development Life Cycle plan
(SDLC)
Mobile Data Computers

The Sheriff’s Office will be retaining their current mobile data computer (MDC)
hardware. The MDC units are Panasonic Toughbook’s (CF-29’s, CF-30’s, and
CF31 models) equipped with GOBI embedded CDMA modems. The network
protocol is TCP/IP and UDP/IP based.
SERIAL 11086- RFP
o
3.3.6
Performance Standards



3.3.7




What kinds of licenses are needed for all hardware?
Are workstation/MDCs licensing concurrent? If concurrent, are there separate
modules that have different licensing ability at the same time? If concurrent,
how will the application control the concurrent sign-ons
Do you require separate licensing for a test environment or training
environment?
System Costs

3.4
What kind of connectivity does the application use, i.e. ODBC connections with
specific drivers or server IP addresses.
Licensing


3.3.11
What operating systems are supported on the servers and workstations?
Does any piece of the software require the Vendor or a certified business partner
to install?
Connectivity

3.3.10
What are the database platforms that will be employed for the entire proposed
solution?
What are the initial sizes of the databases?
What are the yearly expected growth rates of each database?
Initial storage capacity should be sufficient to store 10 years of historical data.
Software – Server and Workstations


3.3.9
Provide relevant performance standards for all proposed hardware systems and
applications.
Describe how the Vendor completes load testing?
Describe the Acceptance Test Process (ATP) to prove completion of
performance standards. Note: This response may be completed in the ATP
section.
Database

3.3.8
Please confirm that the Sheriff’s Office MDCs and wireless network
will meet the Vendor’s minimum specifications to operate the proposed
applications.
Please provide full implementation, optional, and post implementation 5 year
costs plus 5 additional option years for the proposed system. Include: annual
maintenance, typical/proposed consulting, providing/applying patches and
updates, upgrade services, and other services.
Other Technical Requirements:
3.4.1
Archive Process

Describe the proposed system’s ability to archive data.
SERIAL 11086- RFP
3.4.2
CAD Data Purging

The CAD system should have a purge facility that will off-load incident and
incident-related data from the CAD servers for archival storage and access.
Purging should be administrator configurable by multiple parameters, e.g., date,
file, field value, unit ID and location. All purges should be subject to strict audit
tracking and reporting and should occur while the system is fully operational
without degradation of performance.
o
o
3.4.3
CAD Standalone Mode

The CAD workstations should have the ability to operate in a standalone, offline mode in the event of the CAD servers becoming unavailable. The system
should have the ability to append event data from the workstations in a storeand-forward capacity when the servers are back on line. At a minimum, the
system should provide the ability to track basic unit availability and status
information in a standalone mode.
o
3.4.4
All Vendor software installation and updates to both desktop workstations and
mobile data computers should be accomplished through an automated network
facility and not require a technician to perform a manual procedure on each
workstation/MDC. This update utility should be configurable by multiple
parameters, e.g. workstation type, and able to support the scheduling of update
activities in batch and non-batch modes. A summary report is required
documenting the results of the update activity.
o
o
o
Describe the proposed system’s capability to meet this requirement.
The MCSO uses a LanDesk solution for workstation management. Will
LanDesk work with the proposed system?
The MCSO uses Kaseya to manage its MDC environment. Will
Kaseya work with the proposed system?
Update and Patches applied to Server Systems

3.4.6
Describe the proposed CAD system’s capability to meet this
requirement.
Automatic Update of Workstations/Mobile Data Computers

3.4.5
Describe the proposed CAD system’s capability to meet this
requirement.
Describe the proposed system’s ability to purge CAD data.
All Vendor software installation and updates to CAD/RMS system servers must
be coordinated with MCSO Technical personnel. This includes both the server
operating system and the proposed CAD/RMS software.
o
Describe the proposed system’s capability to meet this requirement.
o
Does the Vendor apply server patches and updates or will MCSO?
Data Integrity

The CAD/RMS/MOBILE/CIVIL PROCESS system should ensure the integrity
of the data in which it is maintained. Interruptions in processing due to
incidents such as aborted transactions, hardware failures, or network
unavailability should not result in inaccurate or inconsistent data residing in the
system. If data transfers occur, the system should provide a method of audit
validation to ensure that all data sent was received in the target application.
SERIAL 11086- RFP
o
3.4.7
Scalability

It is clear that future requirements for regional cooperation and interoperability
will only increase. Since this may result in the CAD/RMS/MOBILE/CIVIL
PROCESS being subjected to a greater than normal amount of traffic, the
system should be able to scale up to handle the additional load without any
performance impact on the CAD operations. Increased loads of up to 50 percent
may be the result of temporary surges based on a major event. Also, the need
may arise to permanently increase the standard capabilities of the system. The
former will be handled by building in excess over historical trends, the latter by
seamlessly adding hardware and software components to adapt to the new
workload. Adding or upgrading hardware components should be accomplished
without bringing the system down or negatively affecting its performance.
o
3.4.8
Describe the proposed system’s capability to meet this requirement.
Describe the proposed system’s capability to meet this requirement.
Peak Workload
During FY 2010, patrol officers assigned to the Patrol Services Bureau responded to
nearly 100,000 calls for service. The new system is expected to be able to handle two
times the current peak load. This is estimated to be 300 calls (all types) for service per
hour and 1,300,000 total calls annually with the 2+ factor applied.
Total CAD incidents
entered (1)
2008
2009
2010
607,570
563,698
507,209
(1) The total number of incidents entered into CAD is all inclusive and include Maricopa
County Adult Probation, Youngtown Police Department, MCSO, and other entities that
are dispatched from the Emergency Communications Operations Center (911).

Describe the proposed system’s capability to meet this requirement.
3.4.9
CAD System Reliability/Availability and Access

The public safety mission requires consistent operations. The CAD is expected
to maintain a system availability of 99.999 percent “up time” annually. Routine
maintenance or administrative procedures should not require system “downtime” or a re-start to take effect. These procedures specifically include all
system/database/security administrator actions as defined below.
o
o
3.4.10
Describe the proposed CAD system’s capability to meet this
requirement.
Describe the up-time availably of all other proposed systems (i.e.,
RMS, Mobile, etc.).
GIS AND ADDRESSING
The CAD/RMS system should have the ability to utilize existing master addressing
features coming from the enterprise GIS (ESRI GEODATABASE 10.x Environment).
The master address features contain the following representative information (high level
definition):
SERIAL 11086- RFP
3.4.10.1
Address Points (Parcel Addresses): Information is stored in native
components with associated easting and northing available for capture. Points
are located as follows:




3.4.11
Single Family Residential Addresses: address point located in the
center of each parcel/lot as identified by the cadastral framework.
Multifamily Residential: Addresses identified with a single master
address point (located central to the development). No points
currently exist for each apartment/unit number. The County is
working towards replacing the single point with points for each unit.
Updated data set with complete locations will be available within a 3
year period.
Mobile Home Parks/Courts (non-parceled): Addresses identified with
a single master address point (located central to the development. No
points currently exist for each mobile home. The County is working
towards replacing the single point with points for each mobile home.
An updated data set with complete locations will be available within
a 3 year period.
Commercial Addresses: Addresses identified with a single master
address point (located central to the development). No points exist
for individual stores within a commercial center.
3.4.10.2
Transportation/Roadway Linear Features - Linear features containing
appropriate street naming conventions (native components; directional, street
name, type), right and left address ranges, right and left
annexation/jurisdiction components and right and left zip codes.(At this point
the County has no plans to add impedances to street segments).
3.4.10.3
Mile Posts for Maricopa County maintained roads - Mile posts along roads
where there are no address ranges associated with them.
GIS Requirements
The CAD/RMS should have the ability to integrate/leverage the above mentioned GIS
feature classes to establish an appropriate process within the CAD/RMS to address match
the existing GIS addressing data. Each address point record contained within the
CAD/RMS database should have the ability to store geographic values (easting’s and
northing’s) representing the spatial location for the address being reviewed. The
CAD/RMS must have the ability to export all pertinent addressing information as well as
the geographic values (easting and northing’s) to any report requiring geographic
information at the address level. The CAD/RMS will store this information against a
variety of datasets: calls for service (site locations), persons of interest, records (as
appropriate to site location), etc.
Where the CAD/RMS utilizes the Transportation/Roadway/mile post feature class to
identify geography
for any call for service, the geographic values (easting and
northing) representing the location of interest shall be stored internal to the CAD/RMS
data model and provide opportunity for easy extraction to be utilized in reporting from
any record requiring geographic location rendering.



Please describe the Vendor’s ability to integrate/interface with the County’s
existing ESRI GEODATABASE (10.x) data environments to include various
level of vector representation (point, line, and polygon) with respect to the
creation of CAD/RMS tables.
Please describe the Vendor’s geofile Model.
The integration of updated geofiles to the CAD/RMS environment should be
accomplished with no impact on systems operations or performance. The
CAD/RMS system should have the ability to support scheduling of automated
SERIAL 11086- RFP

tasks driven by changes (additions or edits) to the GIS Master Addressing files
(Point and linear feature classes).. The CAD/RMS should possess the ability to
synchronize back with the GIS Master Address table any errors, changes, or
additions to addressing records found during the course of daily operations and
provide the ability to catalog these issues via an automated reporting process or
tool. This will provide an opportunity for the GIS to repair any addressing
issues discovered through the course of day to day operation of the CAD/RMS.
Please describe Vendors application ability to update geofile from County’s GIS
master address tables, and its ability to recognize change (additions, edits,
removals) from either the GIS Master Address tables or necessary changes
identified via the CAD/RMS users.
3.4.11.1
Alias Data - The CAD/RMS should have the ability to accept address alias
information from the enterprise GIS and also provide to the GIS any alias or
common name reference files to be used in mapping through either system
(CAD/RMS or GIS).
o
Please describe the Vendor’s application ability to utilize alias
information for rapid address recognition.
3.4.11.2
Composite Locator Process - The current enterprise GIS (ESRI ArcMAP
10.x and ArcSDE 10.x) utilizes a composite locator process to match and store
locations of interest derived from address flat files (e.g. Calls for Service
information containing address data). The location of points follows a
hierarchical structure starting with an exact match, followed by ranked match
and finally by an interpolated methodology based on address ranges along
street segments. Each of these levels is explained in detail under the following
bullet points. The CAD/RMS is expected to have similar capabilities
depending on the accuracy of input addresses (Note: it is understood that free
form addresses are a necessity within the CAD/RMS environment – the ability
of the product to adequately match these addresses is the intent of this
requirement):
o
o
o
o
3.4.12
Exact Match (single field locator) – the address string must match
exactly with the address string provided within the GIS. This locator
runs against all available point addresses in inventory.
One Address Locator – The address string is broken into native
components (street number, directional, street name, street type, post
directional) and linked to the highest ranked (within specified criteria)
address point of the collection.
Address Range Locator – Lowest priority address locator, if no point
address is located, this locator will attempt to identify via the existing
centerline and associated address ranges, an approximate location for
addresses that fall outside of the criteria referenced in the Exact Match
or One Address locator – this locator holds the least confidence to
actual geography.
Please describe the Vendor’s solution for utilizing multiple address
source information (specific point locations and address range (linear)
features) to adequately geocode CAD/RMS information (to include
mile posting as appropriate).
Reference Point - The CAD/RMS system should have the ability to reference the
appropriate call/location type (point based or range (linear) based systems) based on the
call for service need. For example:
o
Traffic Accidents or Traffic Stops should have the ability to address match to
the approximate location of the accident (geocode to the centerline as opposed to
an address associated with a property owner (residential or commercial site)) via
the linear reference data. No offsets will be used when placing this type of point.
SERIAL 11086- RFP
o
3.4.13
Jurisdiction - In addition, the CAD/RMS should have the ability to identify via the call
type a potential for jurisdiction conflict. For example, a particular right of way (street)
may reside within Jurisdiction A, however, all the residences/business located on the east
boundary actually correspond to Jurisdiction B – when a call for service is entered that
(through call type and identified location value) indicates a response to the street (traffic
stop or accident, etc.), Jurisdiction A would be primary with Jurisdiction B available in a
support role. If a call for service indicates a response to a property location (serving
warrant, interview, burglary, etc.) then Jurisdiction B would have primary response, with
Jurisdiction A playing the support role.
o
3.4.14
Please identify the applications ability to track and return jurisdictional
information to assist in call taker dispatching.
Dynamic Impediment Mapping - The CAD/RMS system should have the ability for an
authorized user or resource to dynamically insert impediments to any existing street
segment, intersection, bridge, tunnel, interstate highway (or access ramp), low water
crossings in support of vehicle routing. The system should have the capability to identify
permanent impediments, such as, access gates (gated community access), bollards as well
as differentiate between public and private street systems. The system should have the
ability to reference the GIS database or other known and acceptable services that may
provide this type of information and integrate to system. The CAD/RMS should have
opportunity to override specific impediments (coming from other disparate sources) if the
impediment is not seen (in the field) as an issue to routing. Also any impediment that is
referenced through the CAD/RMS should have the capability to be submitted to Mobile
Data Computers located in Officers vehicles.
o
3.4.15
Property Crime should be recognized and addressed matched to the appropriate
property location as provided. Note: if the address provided is not in inventory
for exact match or one address location, then a range location would be
acceptable (and noted). Points should be offset from the center line depending
on the address to be located within a parcel and not the street centerline.

Please describe the Vendor’s application ability to geocode (address
match) each activity based on appropriate address type (Property vs.
Right of way issues) within the GIS Map environment.
Please describe the applications ability to handle dynamic impediment mapping
(inventory) to assist in routing and mapping.
Graphical User Interface:


Graphical User Interface (GUI) - The system should use a standard Graphical
User Interface which utilizes menus, keyboard shortcuts, point and click and
touch-screen (i.e., MDC) and function keys to operate and navigate. All
standard windows functionality regarding the sizing and placement of windows
and the ability to sort columnar data by pointing and clicking and other
capabilities should be supported. The ability of a user to return to a default
windows configuration shall be available. A consistent user interface design
between the CAD terminal and MDC is required (e.g. use of controls, function
keys, navigational procedures, etc.) to reduce user training and application
administration.
All windows on desktop workstations should be designed to continuously
display updated information, for example, windows displaying status or active
events shall continually be updated even while being manipulated. All inactive,
or non-focused, windows should be continuously updated as if they were active.
o
Describe the responding company’s ability to meet this requirement.
SERIAL 11086- RFP
3.4.16
Configuration / Transaction Utility


3.4.17
Browser Support - The CAD/RMS/MOBILE/CIVIL PROCESS client application
should be accessible via MS Internet Explorer using SSL security. All CAD and RMS
functionality, within the parameters set by the system or security administrator, should
also be available to users in real time outside of the PSAP via browser.

3.4.18
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS system’s system
administration capability.
Database Administration - The full suite of database administration tools and
capabilities
native
to
the
proposed
database
environment
for
the
CAD/RMS/MOBILE/CIVIL PROCESS system should be available to the Maricopa
County Sheriff’s Office.

3.4.20
Describe the responding company’s ability to meet this requirement.
CAD/RMS/Mobile/CIVIL PROCESS System Administration - The proposed
CAD/RMS/MOBILE/CIVIL PROCESS solutions should provide a suite of system
administration tools to support the effective ongoing operation of the systems. The full
suite of system administration tools native to the operating system and database utilized
shall be available to appropriate Maricopa County Sheriff’s Office personnel.

3.4.19
Describe the configuration utility of all CAD/RMS/MOBILE/CIVIL PROCESS
systems.
Describe any utility that will allow Maricopa County Sheriff’s Office staff to
build ACJIS state query transaction masks.
Describe the proposed system’s database administration capability.
Security
Security Overview: As mission-critical applications affecting the safety of the public as
well as the County’s first responders the CAD/RMS/MOBILE/CIVIL PROCESS system
should be supported by robust security controls. Security considerations to be addressed
minimally include hardware and networks; application security; user identification and
authentication; and multi-jurisdictional considerations.
Multiple firewalls, encryption, anti-virus software, intrusion detection, for remote users
and LDAP authentication are all utilized within the County’s systems.




The Vendor should install a secure remote management capability to permit
Vendor access to the servers for troubleshooting in cases where on-site
personnel require assistance, and stand ready to be activated when needed. The
Maricopa County Sheriff’s Office will authorize remote access as needed.
All hardware and software introduced to the County’s networks should be in
compliance with County standards.
The system/security administrator should have at a minimum the ability to
assign different user profiles based on individual and group classifications and
sub-classifications and assign differential access privileges. To protect restricted
data, the system administrator should have the ability to define security profiles
down to the individual data field level. Profiles should support read-only access
and selective read/write privileges. Security profiles should also be able to be
assigned to individual devices such as workstations and printers.
A detailed activity auditing and reporting module with the capability to log,
query and report all user actions, including keystrokes, at specified positions,
throughout the entire CAD/RMS/MOBILE/CIVIL PROCESS environment
including all workstations, MDCs and other devices should be available.
Logging shall be configurable by the security administrator. Log entries shall be
SERIAL 11086- RFP



customizable by the security administrator to handle the different requirements
of the user agencies but shall minimally contain a user and workstation ID, date
and time. Audit trails related to events should be appended to the event history.
As many users will also require simultaneous access to applications on the
enterprise
network,
the
CAD/RMS/MOBILE/CIVIL
PROCESS
security/authentication process should support single log-on and integrate with
Active Directory that is currently in use on the enterprise network.
The Maricopa County Sheriff’s Office and other public safety agencies in the
region will also be participating in federal information sharing initiatives with
the Department of Homeland Security, the FBI, and potentially others through
various local, state and federal initiatives. In that this and other initiatives with
security impacts are active projects with changing requirements, it is mandatory
that the County’s CAD/RMS/MOBILE/CIVIL PROCESS Vendor maintain
awareness of these national and regional programs, and is prepared to support
any emerging security and identity authentication standards which may impact
CAD/RMS/MOBILE/CIVIL PROCESS operations.
All security administration procedures should be supported by a detailed
logging, auditing and reporting capability.
o
o
o
3.4.21
Describe the proposed CAD/RMS/MOBILE/CIVIL PROCESS
system’s ability to meet these security requirements.
If the proposed system has a SQL backend, do all users have individual
SQL logins or do they all share one. Please describe.
Does your solution provide user group security and access control? If
so, please describe.
Data Analysis and Report Generation
The ability for all users to complete ad-hoc queries, data mining, analytics and statistical
reports is a primary goal for the Sheriff’s Office. The Maricopa County Sheriff’s Office
expects all public safety personnel to utilize the query and data mining tools on a constant
basis and does not want queries to negatively impact the performance of the production
system.










Describe the proposed system’s capability to meet this requirement.
Does the proposed system architecture have a separate reporting database
optimized for reporting (e.g. Does your solution have an integrated data
warehouse/data mart solution or does it integrate with a 3rd party solution?)
Please describe.
If the proposed system does have an integrated data warehouse/data mart
solution, what kind of Data Warehouse tools is used? Please describe.
Describe the Vendor supported Extract, Transform and Load (ETL) tool or
metadata integrations.
Describe how the proposed data analysis tool provides for online analytical
processing (OLAP) style analysis, i.e. slicing and dicing.
Does the proposed solution have the ability to create and edit reports from a
business view, i.e., a semantic layer?
Does your solution provide central administration and monitoring for reporting?
If so, describe.
Describe how the proposed solution provides report/query audit logs and usage
information.
Describe the proposed solution’s ability to provide flexibility and scalability to
adapt to future growth.
Is the proposed reporting and analysis tool developed internally or is it part of an
OEM agreement with a third-party Vendor? If third-party Vendor then please
list the Vendor.
SERIAL 11086- RFP


3.4.22
Report Output










3.4.23
Does the proposed solution provide generic interfaces (via web services or API)
providing integration points for pulling data?
Please describe the Vendor supported generic interfaces.
Does the proposed solution have the ability to publish standard reports in a
variety of formats, i.e., Microsoft Office, PDF, email, etc.? Please describe.
Does the proposed solution integrate with Microsoft Office and MS
SharePoint? If so, describe.
Does the proposed solution provide an integrated Management Information
System (i.e., Dashboard solution)? How can these dashboards be rendered (e.g.
portal, email, etc.)? Are these static dashboards or can they be connected for
real-time data access?
Does your solution provide Score carding capabilities for CAD and RMS?
Please describe and provide examples.
Does the proposed solution provide a print-friendly report format? Please
provide examples.
Does the proposed solution provide the ability to schedule standard and userdefined reports? If so, describe.
What kind of canned reports does the proposed solution provide? Please
provide examples.
Does the proposed solution allow canned reports to be modified and saved
separately?
Does the proposed solution’s query and reporting tool(s) allow ease of use for
end-users? If so, describe.
Does the proposed solution provide the ability to export data or integrate with
statistical programs? If so, describe.
System Documentation

The Vendor will supply documentation in printed and electronic format (MS
Word Format). The proposed solution should include complete documentation
including, at a minimum:
o
System and Technical Documentation will be a deliverable. The
Vendor should describe the technical architecture of the product as
installed and configured. The technical documentation should include
information regarding the relational database design (data dictionary),
record or table layouts, file schemas and use of application programs
interfaces (API’s), program description, and report manual. The
Vendor should compile and provide to the Sheriff’s Office complete
documentation for all COTS and customized components of the
CAD/RMS/MOBILE/CIVIL PROCESS environment minimally
including:









Data dictionary, table layouts and relationships
Interface specifications
Data conversion processes
Programs
XML schema
Stored queries and procedures
Report layouts
Configuration
Describe the Vendor’s ability to meet this requirement.
SERIAL 11086- RFP
3.4.24
System Administration Documentation:

The Vendor should describe the steps and procedures needed to operate the
product as installed, configured and customized, on a day-to-day basis. It
should include information relating to procedures for system start-up and shut
down, batch job submission procedures, security procedures, table maintenance
procedures, etc.
o
3.4.25
User Documentation:



The Vendor should describe the operation of the products, as installed,
configured and customized from the perspective of the end user. The
documentation should cover sign-on and sign-off sequences, menu operation,
screen descriptions, means of invoking online help facilities, report generation,
etc., and should be targeted to specific user groups.
The Vendor shall, at no additional charge to the Maricopa County Sheriff’s
Office, provide updated technical, System Administrator, and user
documentation when major system changes or updates occur such as Versions or
Releases. Documentation will be provided in electronic format with permission
for the Maricopa County Sheriff’s Office to distribute internally as needed. All
new versions and releases should be accompanied by a document clearly
explaining the new functionality, features, corrections, etc., addressed by the
release or version.
The Vendor shall, at no additional charge to the Maricopa County Sheriff’s
Office, provide documentation for any system configurations and integrations.
System documentation should be provided in a MS Word format. Any content
within the documentation which is considered proprietary in nature shall be so
marked.
o
3.4.26
Describe the Vendor’s ability to meet this requirement.
Source Code:

The Vendor shall either provide their proposed systems’ source code to the
Maricopa County Sheriff’s Office, or establish an escrow account with the exact
version of the source code being implemented at the Maricopa County Sheriff’s
Office. The Vendor should provide to the Maricopa County Sheriff’s Office, or
escrow, the original, unaltered code, which should be replaced with the as-built
code subsequent to completing the 1) testing, 2) acceptance and 3)
implementation phases of this project. The Vendor should notify the Maricopa
County Sheriff’s Office every time code versions are sent to escrow. This is
required to ensure that the Maricopa County Sheriff’s Office has unrestricted
access to and use of the source code in the event the company ceases to exist,
ceases to support the application, or otherwise terminates its relationship with
the product.
o
o
3.4.27
Describe the Vendor’s ability to meet this requirement.
Describe the Vendor’s ability to meet this requirement.
Describe the technical environment used to develop proposed system.
Include a list of all technical tools required to support development of
proposed system.
Ownership of and Access to Data and Associated Products:

CAD/RMS/MOBILE/CIVIL PROCESS data shall remain the sole property of
the Sheriff’s Office. Therefore, all tools and capabilities native to the
SERIAL 11086- RFP

database/OS environment, either Oracle/SQL Server, Unix/Windows, as
proposed, should be available to the Maricopa County Sheriff’s Office to allow
for full access to that data. All tables, layouts, queries, stored procedures, XML
schema and other content developed to support the operation of the database and
the CAD/RMS/MOBILE/CIVIL PROCESS applications in the Sheriff’s Office
environment become the property of the Maricopa County Sheriff’s Office, and
shall be available to the appropriate Maricopa County Sheriff’s Office personnel
as needed and upon request. Database query, extract and download capabilities
into external formats such as MS Excel and Access should be completely
operational and available for appropriate Maricopa County Sheriff’s Office
personnel to access.
The above is not meant to include proprietary programs or other intellectual
property unique to the Vendor’s solution. However, such claim to proprietary
content cannot intrude on the County’s right to access its data without undue
interference or additional cost. Data owned by Sheriff’s Office may not be used
by the Vendor for any purposes without the express written consent of the
appropriate Maricopa County Sheriff’s Office representative.
o
4.0
Describe the Vendor’s ability to meet this requirement.
SPECIAL TERMS & CONDITIONS:
4.1
LOCATIONS AND TERM OF PERFORMANCE:
Shall perform tasks at various locations for meetings and implementation activities, all other
administrative tasks can be performed at the vendor’s own facilities and/or any office location that
may be provided by the County.
4.2
FACILITIES:
During the course of this Contract, the County may provide the Contractor’s personnel with
adequate workspace for consultants and such other related facilities as may be required by
Contractor to carry out its obligation enumerated herein.
4.3
INVOICES AND PAYMENTS:
4.3.1
The Respondent shall submit two (2) legible copies of their detailed invoice before
payment(s) can be made. At a minimum, the invoice must provide the following
information:











Company name, address and contact
County bill-to name and contact information
Contract Number
County purchase order number
Invoice number and date
Payment terms
Contract Item number(s)
Description of Purchase (services)
Pricing per unit of service
Extended price
Total Amount Due
4.3.1.1 Problems regarding billing or invoicing shall be directed to the using agency as
listed on the Purchase Order
4.3.1.2 Payment shall be made to the Contractor by Accounts Payable through the
Maricopa County Vendor Express Payment Program. This is an Electronic
Funds Transfer (EFT) process. After Award the Contractor shall fill out an EFT
SERIAL 11086- RFP
Enrollment form located on the County Department of Finance Website as a
fillable PDF document (www.maricopa.gov/finance/).
4.3.2
4.4
EFT payments to the routing and account numbers designated by the Contractor shall
include the details on the specific invoices that the payment covers. The Contractor is
required to discuss remittance delivery capabilities with their designated financial
institution for access to those details.
TAX: (SERVICES):
No tax shall be levied against labor. It is the responsibility of the Contractor to determine any and
all taxes and include the same in proposal price.
4.5
TAX: (COMMODITIES):
Tax shall not be levied against labor. Sales/use tax will be determined by County. Tax will not be
used in determine low price.
4.6
STRATEGIC ALLIANCE for VOLUME EXPENDITURES ($AVE):
The County is a member of the $AVE cooperative purchasing group. $AVE includes the State of
Arizona, many Phoenix metropolitan area municipalities, and many K-12 unified school districts.
Under the $AVE Cooperative Purchasing Agreement, and with the concurrence of the successful
Respondent under this solicitation, a member of $AVE may access a contract resulting from a
solicitation issued by the County. If you do not want to grant such access to a member of $AVE,
please so state in your proposal. In the absence of a statement to the contrary, the County will
assume that you do wish to grant access to any contract that may result from this Request for
Proposal.
4.7
CONTRACT TERM:
This Request for Proposal is for awarding a firm, fixed-price purchasing contract to cover a five
(5) year term.
4.8
OPTION TO RENEW CONTRACT:
The County may, at its option and with the approval of the Contractor, renew the term of this
Contract up to a maximum of five (5) additional years, or other specified length options, (or at the
County’s sole discretion, extend the contract on a month to month basis for a maximum of six (6)
months after expiration). Five option years shall be provided. The Contractor shall be notified in
writing by the Materials Management Department of the County’s intention to extend the contract
term at least thirty (30) calendar days prior to the expiration of the original contract term.
4.9
PRICE ADJUSTMENTS:
Any requests for reasonable price adjustments must be submitted sixty (60) days prior to the
Contract expiration date. Requests for adjustment in cost of labor and/or materials must be
supported by appropriate documentation. If County agrees to the adjusted price terms, County
shall issue written approval of the change. The reasonableness of the request will be determined
by comparing the request with the (Consumer Price Index), and/or by performing a market survey.
4.10
INDEMNIFICATION:
4.10.1
To the fullest extent permitted by law, Contractor shall defend, indemnify, and hold
harmless County, its agents, representatives, officers, directors, officials, and employees
from and against all claims, damages, losses and expenses, including, but not limited to,
attorney fees, court costs, expert witness fees, and the cost of appellate proceedings,
relating to, arising out of, or alleged to have resulted from the acts, errors, omissions,
mistakes or malfeasance relating to the performance of this Contract. Contractor’s duty
SERIAL 11086- RFP
to defend, indemnify and hold harmless County, its agents, representatives, officers,
directors, officials, and employees shall arise in connection with any claim, damage, loss
or expense that is caused by any acts, errors, omissions or mistakes in the performance of
this Contract by the Contractor, as well as any person or entity for whose acts, errors,
omissions, mistakes or malfeasance Contractor may be legally liable including
Contractor’s subcontractors.
4.11
4.10.2
The amount and type of insurance coverage requirements set forth herein shall in no way
be construed as limiting the scope of the indemnity in this paragraph.
4.10.3
The scope of this indemnification does not extend to the sole negligence of County.
INSURANCE REQUIREMENTS:
4.11.1
Contractor, at Contactor’s own expense, shall purchase and maintain the herein stipulated
minimum insurance from a company or companies duly licensed by the State of Arizona
and possessing a current A.M. Best, Inc. rating of A-, VII or higher. In lieu of State of
Arizona licensing, the stipulated insurance may be purchased from a company or
companies, which are authorized to do business in the State of Arizona, provided that
said insurance companies meet the approval of County. The form of any insurance
policies and forms must be acceptable to County.
4.11.2
All insurance required herein shall be maintained in full force and effect until all work or
service required to be performed under the terms of the Contract is satisfactorily
completed and formally accepted. Failure to do so may, at the sole discretion of County,
constitute a material breach of this Contract.
4.11.3
Contractor’s insurance shall be primary insurance as respects County, and any insurance
or self-insurance maintained by County shall not contribute to it.
4.11.4
Any failure to comply with the claim reporting provisions of the insurance policies or any
breach of an insurance policy warranty shall not affect the County’s right to coverage
afforded under the insurance policies.
4.11.5
The insurance policies may provide coverage that contains deductibles or self-insured
retentions. Such deductible and/or self-insured retentions shall not be applicable with
respect to the coverage provided to County under such policies. Contactor shall be solely
responsible for the deductible and/or self-insured retention and County, at its option, may
require Contractor to secure payment of such deductibles or self-insured retentions by a
surety bond or an irrevocable and unconditional letter of credit.
4.11.6
County reserves the right to request and to receive, within 10 working days, certified
copies of any or all of the herein required insurance certificates. County shall not be
obligated to review policies and/or endorsements or to advise Contractor of any
deficiencies in such policies and endorsements, and such receipt shall not relieve
Contractor from, or be deemed a waiver of County’s right to insist on strict fulfillment of
Contractor’s obligations under this Contract.
4.11.7
The insurance policies required by this Contract, except Workers’ Compensation, and
Errors and Omissions, shall name County, its agents, representatives, officers, directors,
officials and employees as Additional Insureds.
4.11.8
The policies required hereunder, shall contain a waiver of transfer of rights of recovery
(subrogation) against County, its agents, representatives, officers, directors, officials and
employees for any claims arising out of Contractor’s work or service.
SERIAL 11086- RFP
4.11.9
Commercial General Liability.
Commercial General Liability insurance and, if necessary, Commercial Umbrella
insurance with a limit of not less than $2,000,000 for each occurrence, $4,000,000
Products/Completed Operations Aggregate, and $4,000,000 General Aggregate Limit.
The policy shall include coverage for bodily injury, broad form property damage,
personal injury, products and completed operations and blanket contractual coverage, and
shall not contain any provision which would serve to limit third party action over claims.
4.11.10 Automobile Liability.
Commercial/Business Automobile Liability insurance and, if necessary, Commercial
Umbrella insurance with a combined single limit for bodily injury and property damage
of not less than $1,000,000 each occurrence with respect to any of the Contractor’s
owned, hired, and non-owned vehicles assigned to or used in performance of the
Contractor’s work or services under this Contract.
4.11.11 Errors and Omissions Insurance.
Errors and Omissions insurance and, if necessary, Commercial Umbrella insurance,
which will insure and provide coverage for errors or omissions of the Contractor, with
limits of no less than $5,000,000 for each claim.
4.11.12 Workers’ Compensation.
4.11.12.1 Workers’ Compensation insurance to cover obligations imposed by federal
and state statutes having jurisdiction of Contractor’s employees engaged in the
performance of the work or services under this Contract; and Employer’s
Liability insurance of not less than $1,000,000 for each accident, $1,000,000
disease for each employee, and $1,000,000 disease policy limit.
4.11.12.2 Contractor waives all rights against County and its agents, officers, directors
and employees for recovery of damages to the extent these damages are
covered by the Workers’ Compensation and Employer’s Liability or
commercial umbrella liability insurance obtained by Contractor pursuant to
this Contract.
4.11.13 Certificates of Insurance.
Prior to commencing work or services under this Contract, Contractor shall furnish the
County with certificates of insurance, or formal endorsements as required by the Contract
in the form provided by the County, issued by Contractor’s insurer(s), as evidence that
policies providing the required coverage, conditions and limits required by this Contract
are in full force and effect. Such certificates shall identify this contract number and title.
4.11.13.1 In the event any insurance policy (ies) required by this contract is (are) written
on a “claims made” basis, coverage shall extend for two years past completion
and acceptance of Contractor’s work or services and as evidenced by annual
Certificates of Insurance.
4.11.13.2 If a policy does expire during the life of the Contract, a renewal certificate
must be sent to County fifteen (15) days prior to the expiration date.
4.11.14 Cancellation and Expiration Notice.
Insurance required herein shall not be permitted to expire, be canceled, or materially
changed without thirty (30) days prior written notice to the County.
SERIAL 11086- RFP
4.12
BOND REQUIREMENT:
4.12.1
4.13
Concurrently with the submittal of the Contract, the Contractor shall furnish the
Contracting Agency the following bonds, which shall become binding upon the award of
the contract to the Contractor.
4.12.1.1
Performance Bond equal to the full Contract amount conditioned upon the
faithful performance of the Contract in accordance with plans, specifications
and conditions thereof. Such bond shall be solely for the protection of the
Contracting Agency awarding the Contract.
4.12.1.2
A Payment Bond equal to the full contract amount solely for the protection of
claimants supplying labor and materials to the Contractor or his
Subcontractors in the prosecution of the work provided for in such Contract.
4.12.2
Each such bond shall include a provision allowing the prevailing party in a suit on such
bond to recover as a part of his judgment such reasonable attorney’s fees as may be fixed
by a judge of the court.
4.12.3
Each bond shall be executed by a surety company or companies holding a certificate of
authority to transact surety business in the State of Arizona issued by the Director of the
Department of Insurance. The bonds shall not be executed by an individual surety or
sureties. The bonds shall be made payable and acceptable to the Contracting Agency.
The bonds shall be written or countersigned by an authorized representative of the surety
who is either a resident of the State of Arizona or whose principal office is maintained in
this state, as by law required, and the bonds shall have attached thereto a certified copy of
the Power of Attorney of the signing official. In addition, said company or companies
shall be rated “Best-A” or better as required by the Contracting Agency, as currently
listed in the most recent Best Key Rating Guide, published by the A.M. Best Company
PROCUREMENT CARD ORDERING CAPABILITY:
County may determine to use a procurement card (MasterCard), from time-to-time, to place or
make payment for orders under the Contract. Respondents without this capability may be
considered non-responsive and not eligible for award consideration.
4.14
INTERNET CAPABILITY:
County intends to use the Internet to communicate and to place orders under this Contract.
Respondents without this capability may be considered non-responsive and not eligible for award
consideration.
4.15
SUBCONTRACTING:
The Contractor may not assign a Contract or Subcontract to another party for performance of the
terms and conditions hereof without the written consent of the County. All correspondence
authorizing subcontracting must reference the Bid Serial Number and identify the job project.
4.16
SCHEDULE OF EVENTS:
Request for Proposals Issued:
August 4, 2011
Pre-Proposal Conference:
August 15, 2011
Deadline for written questions is (2) business days after Pre-Proposal Conference. Questions will
not be responded to prior to the Pre-Proposal Conference or after the (2) business day deadline has
elapsed. All questions and answers shall be posted to www.bidsync.com under the Q&A’s tab for
the solicitation and must be received by the end of business, 5:00 PM Arizona time
SERIAL 11086- RFP
Proposals Opening Date:
September 9 2, 2011
Deadline for submission of proposals is 2:00 P.M., Arizona Time. All proposals must be received
before 2:00 P.M., Arizona Time, on the above date at the Maricopa County Materials Management
Department, 320 West Lincoln Street, Phoenix, Arizona 85003.
Proposed review of Proposals and short list decision:
September 30 October 6, 2011
Proposed Respondent presentations: (if required)
October 17-28 7-21, 2011
Proposed selection and negotiation:
November 1, 2011
Proposed Best & Final (if required)
November 8 15, 2011
Proposed award of Contract:
December 14, 2011
All responses to this Request for Proposal become the property of Maricopa County and (other
than pricing) will be held confidential, to the extent permissible by law. The County will not be
held accountable if material from proposal responses is obtained without the written consent of the
Respondent by parties other than the County.
4.17
INQUIRIES AND NOTICES:
All inquiries concerning information herein shall be addressed to:
Maricopa County
Materials Management Department
ATTN: Contract Administration
320 West Lincoln Street
Phoenix, Arizona 85003-2494
Administrative telephone inquiries shall be addressed to:
Brian Walsh, Procurement Officer, 602.506.3243
(walshb@mail.maricopa.gov)
Inquiries may be submitted by telephone but must be followed up in writing.
communication is binding on Maricopa County.
4.18
No oral
INSTRUCTIONS FOR PREPARING AND SUBMITTING PROPOSALS:
Respondents shall provide their proposals in accordance with Section 4.21 as follows:
4.18.1
One (1) original hardcopy packet of all proposal documents.
4.18.2
One (1) CD providing all proposal documents in Word, Excel (Attachment A) and then
the entire proposal document in PDF format.
4.18.3
One (1) CD of Vendor Response Tool (Attachment D)
4.18.4
Eight (8) CD’s or flash drives providing the entire proposal in PDF format only.
4.18.5
Respondents shall address proposals identified with return address, serial number and
title in the following manner:
Maricopa County
Materials Management Department
SERIAL 11086- RFP
320 West Lincoln Street
Phoenix, Arizona 85003-2494
SERIAL 11086-RFP, CAD/RMS/CIVIL PROCESS and MOBILE SYSTEMS
4.18.6
4.19
4.20
Proposals shall be signed by an owner, partner or corporate official who has been
authorized to make such commitments. All prices shall be held firm for a period of one
hundred fifty (150) days after the RFP closing date.
EXCEPTIONS TO THE SOLICITATION:
4.19.1
The Respondent shall identify and list all exceptions taken to all sections of 11086-RFP
and list these exceptions referencing the section (paragraph) where the exception exists
and identify the exceptions and the proposed wording for the Respondent’s exception
under the heading, “Exception to the PROPOSAL Solicitation, SERIAL 11086-RFP.”
Exceptions that surface elsewhere and that do not also appear under the heading,
“Exceptions to the PROPOSAL Solicitation, SERIAL 11086-RFP,” shall be considered
invalid and void and of no contractual significance.
4.19.2
The County reserves the right to reject, determine the proposal non-responsive, enter into
negotiation on any of the Respondent exceptions, or accept them outright.
GENERAL CONTENT:
The Proposal should be specific and complete in every detail. It should be practical and provide a
straightforward, concise delineation of capabilities to satisfactorily perform the Contract being
sought.
4.21
FORMAT AND CONTENT:
Please provide complete responses for each section below. Proposals should not contain
extraneous promotional materials. Vendors should utilize lay person terms and common
terminology wherever possible. Proposals should cover the general topics outlined in this section.
Proposals will be evaluated on the basis of information presented by the Vendor and the
evaluation criteria listed in this RFP.
To aid in the evaluation, it is necessary for all proposals to follow the same general format. The
proposal hardcopy must be submitted in 3-ring binders and have sections tabbed as indicated
below: (Responses are limited to 200 pages, single sided, 10 point font type not including
attachments).
4.21.1
Table of Contents
4.21.2
Letter of Transmittal (Exhibit 2)
4.21.3
Executive Summary-The Vendor shall provide an Executive Summary that presents in
brief, concise terms a summary level description of the contents of the Proposal. The
vendor shall summarize understanding of the Maricopa County Sheriff’s Office’s
purpose, scope and objectives.
4.21.4
Proposal – This section should contain a statement of all of the programs and services
proposed, including conclusions and generalized recommendations. Proposals should be
all-inclusive, detailing Respondent’s best offer. Proposals should be in detail to the
requirements in section 2.0-3.0 for compliance or non-compliance including a brief
description, if necessary. Note: Failure to do so may result in the proposal being
deemed non-responsive.
4.21.5
Implementation Plan and Services- This section shall describe the respondent’s detailed
project plan for the initial implementation of the proposal
SERIAL 11086- RFP
4.21.6
Training Plan- This section shall describe the Respondent’s detailed plan for successful
training of the County personnel. Pricing must also be included in Attachment A.
4.21.7
Warranty
4.21.8
Maintenance and Support
4.21.9
Qualifications-This section shall describe the respondent’s ability and experience related
to the programs and services proposed. All project personnel, as applicable, shall be listed
including a description of assignments and responsibilities, a resume/bio of professional
experience for assigned staff to the project, an estimate of the time each would devote to
this program, and other pertinent information.
4.21.10 Proposal Exceptions
4.21.11 Subcontractors
4.21.12 Other data
4.21.13 Attachment A (Pricing)
4.21.14 Attachment B (Agreement Page)
4.21.15 Attachment C (References)
4.21.16 Attachment D (Vendor Scoring Tool)
4.22
EVALUATION OF PROPOSAL – SELECTION FACTORS:
A Proposal Evaluation Committee shall be appointed, chaired by the Procurement Officer to evaluate
each Proposal. At the County’s option, Respondents may be invited to make presentations to the
Evaluation Committee. Best and Final Offers and/or Negotiations may be conducted, as needed, with
the highest rated Respondent(s). Proposals will be evaluated on the following criteria which are listed
descending order of importance.
4.23
4.22.1
Proposed Solution
4.22.2
Vendor Response Tool (CAD/RMS Requirements)
4.22.3
Experience and Qualifications
4.22.4
Implementation Plan and Services
4.22.5
Pricing
CERTIFICATION REGARDING DEBARMENT AND SUSPENSION:
4.23.1
The undersigned (authorized official signing for the Contractor) certifies to the best of his
or her knowledge and belief, that the Contractor, defined as the primary participant in
accordance with 45 CFR Part 76, and its principals:
4.23.1.1
are not presently debarred, suspended, proposed for debarment, declared
ineligible, or voluntarily excluded from covered transactions by any Federal
Department or agency;
4.23.1.2
have not within 3-year period preceding this Contract been convicted of or
had a civil judgment rendered against them for commission of fraud or a
criminal offense in connection with obtaining, attempting to obtain, or
SERIAL 11086- RFP
performing a public (Federal, State or local) transaction or contract under a
public transaction; violation of Federal or State antitrust statues or
commission of embezzlement, theft, forgery, bribery, falsification or
destruction of records, making false statements, or receiving stolen property;
4.24
4.23.1.3
are not presently indicted or otherwise criminally or civilly charged by a
government entity (Federal, State or local) with commission of any of the
offenses enumerated in paragraph (2) of this certification; and
4.23.1.4
have not within a 3-year period preceding this Contract had one or more
public transaction (Federal, State or local) terminated for cause of default.
4.23.2
Should the Contractor not be able to provide this certification, an explanation as to why
should be attached to the Contact.
4.23.3
The Contractor agrees to include, without modification, this clause in all lower tier
covered transactions (i.e. transactions with subcontractors) and in all solicitations for
lower tier covered transactions related to this Contract.
VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES
§41-4401 AND FEDERAL IMMIGRATION LAWS AND REGULATIONS:
4.25
4.24.1
By entering into the Contract, the Contractor warrants compliance with the Immigration
and Nationality Act (INA using e-verify) and all other federal immigration laws and
regulations related to the immigration status of its employees and A.R.S. §23-214(A). The
contractor shall obtain statements from its subcontractors certifying compliance and shall
furnish the statements to the Procurement Officer upon request. These warranties shall
remain in effect through the term of the Contract. The Contractor and its subcontractors
shall also maintain Employment Eligibility Verification forms (I-9) as required by the
Immigration Reform and Control Act of 1986, as amended from time to time, for all
employees performing work under the Contract and verify employee compliance using the
E-verify system and shall keep a record of the verification for the duration of the
employee’s employment or at least three years, whichever is longer. I-9 forms are available
for download at USCIS.GOV.
4.24.2
The County retains the legal right to inspect contractor and subcontractor employee
documents performing work under this Contract to verify compliance with paragraph 4.24.1
of this Section. Contractor and subcontractor shall be given reasonable notice of the
County’s intent to inspect and shall make the documents available at the time and date
specified. Should the County suspect or find that the Contractor or any of its subcontractors
are not in compliance, the County will consider this a material breach of the contract and
may pursue any and all remedies allowed by law, including, but not limited to: suspension
of work, termination of the Contract for default, and suspension and/or debarment of the
Contractor. All costs necessary to verify compliance are the responsibility of the
Contractor.
VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES
§§35-391.06 AND 35-393.06 BUSINESS RELATIONS WITH SUDAN AND IRAN:
4.25.1
By entering into the Contract, the Contractor certifies it does not have scrutinized business
operations in Sudan or Iran. The contractor shall obtain statements from its subcontractors
certifying compliance and shall furnish the statements to the Procurement Officer upon
request. These warranties shall remain in effect through the term of the Contract.
4.25.2
The County may request verification of compliance for any contractor or subcontractor
performing work under the Contract. Should the County suspect or find that the Contractor
or any of its subcontractors are not in compliance, the County may pursue any and all
remedies allowed by law, including, but not limited to: suspension of work, termination of
SERIAL 11086- RFP
the Contract for default, and suspension and/or department of the Contractor. All costs
necessary to verify compliance are the responsibility of the Contractor.
4.26
4.27
CONTRACTOR LICENSE REQUIREMENT:
4.26.1
The Respondent shall procure all permits, insurance, licenses and pay the charges and
fees necessary and incidental to the lawful conduct of his/her business, and as necessary
complete any required certification requirements, required by any and all governmental
or non-governmental entities as mandated to maintain compliance with and in good
standing for all permits and/or licenses. The Respondent shall keep fully informed of
existing and future trade or industry requirements, Federal, State and Local laws,
ordinances, and regulations which in any manner affect the fulfillment of a Contract and
shall comply with the same. Contractor shall immediately notify both Materials
Management and the using agency of any and all changes concerning permits, insurance
or licenses.
4.26.2
Respondents furnishing finished products, materials or articles of merchandise that will
require installation or attachment as part of the Contract, shall possess any licenses
required. A Respondent is not relieved of its obligation to posses the required licenses by
subcontracting of the labor portion of the Contract. Respondents are advised to contact
the Arizona Registrar of Contractors, Chief of Licensing, at (602) 542-1525 to ascertain
licensing requirements for a particular contract. Respondents shall identify which
license(s), if any, the Registrar of Contractors requires for performance of the Contract.
VERIFICATION REGARDING RESPONDENT AFFILIATIONS:
By entering into the Contract, the Contractor, and/or subcontractor, certifies it has no
telecommunications hardware or software manufacturer or vendor affiliation within the 24 month
period preceding the solicitation submission due date.
4.28
POST AWARD MEETING:
The successful Respondents shall be required to attend a post-award meeting with the Using Agency
to discuss the terms and conditions of the Contract. This meeting will be coordinated by the
Procurement Officer of the Contract.
NOTE 1:
RESPONDENTS ARE STRONGLY ENCOURAGED TO REVIEW MARICOPA COUNTY’S
PROCUREMENT ADMINISTRATIVE INFORMATION AND SAMPLE CONTRACT
DOCUMENT PRIOR TO SUBMITTING A PROPOSAL. FOR THIS INFORMATION, GO
TO: http://www.maricopa.gov/Materials
NOTE 2:
RESPONDENTS ARE REQUIRED TO USE ATTACHED FORMS TO SUBMIT THEIR
PROPOSAL.
SERIAL 11086-RFP
ATTACHMENT A
PRICING
SEE EXCEL FILE-ATTACHMENT A PRICING
SERIAL 11086-RFP
ATTACHMENT B
AGREEMENT
Respondent hereby certifies that Respondent has read, understands and agrees that acceptance by Maricopa County of the
Respondent’s Offer will create a binding Contract. Respondent agrees to fully comply with all terms and conditions as set forth in the
Maricopa County Procurement Code, and amendments thereto, together with the specifications and other documentary forms herewith
made a part of this specific procurement
BY SIGNING THIS PAGE THE SUBMITTING RESPONDENT CERTIFIES THAT RESPONDENT HAS REVIEWED
THE ADMINISTRATIVE INFORMATION AND DRAFT RFP CONTRACT’S TERMS AND CONDITIONS LOCATED AT
http://www.maricopa.gov/materials. AND AGREE TO BE CONTRACTUALLY BOUND TO THEM.
[]
Small Business Enterprise (SBE)
RESPONDENT (FIRM) SUBMITTING PROPOSAL
FEDERAL TAX ID NUMBER
PRINTED NAME AND TITLE
AUTHORIZED SIGNATURE
ADDRESS
TELEPHONE
DUNS #
/
CITY
WEB SITE
STATE
ZIP
DATE
EMAIL ADDRESS
FAX #
SERIAL 11086-RFP
ATTACHMENT C
RESPONDENT’S REFERENCES
Please refer to section 2.6 7 for more information. The references must include sufficient detail to determine
compliance with these requirements. Note: Failure to do so may result in the proposal being deemed nonresponsive.
RESPONDENT SUBMITTING PROPOSAL:
1.
COMPANY NAME:
ADDRESS:
CONTACT PERSON:
TELEPHONE:
2.
E-MAIL ADDRESS:
COMPANY NAME:
ADDRESS:
CONTACT PERSON:
TELEPHONE:
3.
E-MAIL ADDRESS:
COMPANY NAME:
ADDRESS:
CONTACT PERSON:
TELEPHONE:
4.
E-MAIL ADDRESS:
COMPANY NAME:
ADDRESS:
CONTACT PERSON:
TELEPHONE:
5.
E-MAIL ADDRESS:
COMPANY NAME:
ADDRESS:
CONTACT PERSON:
TELEPHONE:
E-MAIL ADDRESS:
SERIAL 11086-RFP
ATTACHMENT D
VENDOR SCORING TOOL
NOTE: THE TOOL WILL BE PROVIDED AT THE PRE-PROPOSAL MEETING. THE INFORMATION BELOW IS FOR INFORMATIONAL
PURPOSES ONLY AND IS SUBJECT TO CHANGE.
Printable Requirements
1.
2.
Ref
No.
1
2
3
4
5
6
7
8
9
This version of the requirements is used for inclusion in the printed version of the RFP. A Response Key
needs to be added in the MS Word Document which identifies the appropriate response and its related
code number.
If additional formatting is required (e.g., alignment of wrapped text, bolding, etc.) this should be
completed in MS Word
Requirements Description
Response
1. RMS Functional Requirements
1.1. The general design of the system should comply with the following requirements:
1.2. The system should be designed to operate as a component of a comprehensive, seamlessly integrated, incident-based
Public Safety Information Technology environment.
1.3. The system should allow the County’s authorized users to retrieve, enter, and modify information in the RMS through the
County’s Intranet and enterprise network utilizing a browser interface.
1.4. The system should provide an Administration and Security module that will allow the System Administrator to control
security, maintenance of tables, backups, maintenance of reports, screens, etc.
1.5. MCSO often has to respond to new mandates quickly that make it necessary to add new data field to entry/retrieval masks
and store their entry content in the database. Vendors are being ask to explain in detail how they can satisfy this requirement.
1.6. The system should be capable of maintaining a minimum of 20 years of incident data online without having to retrieve
archived data.
1.7. The system should include as many labor saving routines as possible. For example, when an officer is preparing several
reports related to a single event the officer will not have to reenter his/her badge number for each item, or the location where the
event occurred. Like information should auto-populate,
1.8. The system should have the ability to receive, store, and manage data contained in selected Maricopa County Sheriffs
Department report forms.
SERIAL 11086-RFP
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
1.9. The system should be designed to share information logically, automatically, and seamlessly with other systems, such as
the proposed CAD system, while minimizing the use of point to point interfaces.
1.1. The system should include a geographically based analytical tool (mapping) component that provides analytical tools for
viewing and accessing spatial relationships among stored data. Any data that is capable of having an address or coordinates should
be capable of being represented visually on the map. This includes incidents and other events, districts, hydrants, stations,
jurisdictional boundaries, and hospitals. The offeror's GIS mapping system should interface with an ESRI GIS and the offeror should
be able to import the County's GIS data into their GIS solution. The offeror should provide means to facilitate new uploads of GIS
data into system for use with their software.
1.11. User import of data should not result in slowdowns, downtime or the breaking of any relational linkages.
1.12. The system should provide the capability for an audit trail of all transactions including records views.
1.13. When a user signs on to the proposed RMS system, the system should be capable of displaying an agency-defined user
home-page, or summary informing the user of information such as:
1.13.1. incomplete reports for which the user is responsible
1.13.2. reports that have been returned for correction or review for which the user is responsible,
1.13.3. returns from delayed inquiries to RMS, NCIC, and other resources,
1.13.4. persons or items of interest “hits”.
1.14. The proposed RMS system should provide the County with the ability to archive selected records to off-line devices and
transmit the data to off-site servers.
1.15. The system should allow authorized end-users to copy information and reports in the RMS to compact disk and other
removable media storage. Please explain how this functionality can be limited to a select number of users.
1.16. All information contained within the RMS should be available for inquires and report production.
1.17. The system should include simple methods for exporting RMS data into Access, EXCEL, and other industry standard
formats. Again, explain how this capability can be provided to only authorized staff.
1.18. The system database should have the ability to input, store and export text, sound, images, and other objects.
1.19. The system should have the ability to attach scanned images, such as pictures, diagrams, audio files, video to a case
record.
1.2. The proposed RMS system should allow access by point-and-click to all forms, images, and other database items
associated with a given case.
1.21. The system's report formats should be sufficiently configurable to avoid empty space and un-used fields on all viewed and
printed reports.
1.22. The system should have the ability to search code tables by code or by code description.
1.23. The system should capture relevant user-defined data elements and perform required edit validation for:
1.23.1. Uniformed Crime Reporting (UCR) (NIBRS) system ( edit to ensure that required fields are entered at time of entry)
1.23.2. Master Name Index (MNI)
1.23.3. Master Vehicle Index (MVI)
1.23.4. Master Property Index (MPI)
1.23.5. Master Telephone Index (MTI)
SERIAL 11086-RFP
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
1.23.6. Automated Field Reporting
1.23.7. Investigations
1.23.8. Case Management
1.23.9. Crime Analysis
1.23.10. Arrest and Booking
1.23.11. Warrant Control
1.23.12. Registrant Tracking
1.23.13. Neighborhood Services
1.23.14. Code Enforcement
1.23.15. Animal Control
1.23.16. Accreditation.
1.23.17. County Probation
1.24. Vendors are being asked to comment on their systems capability to provide a standard XML data interface (or API) that
can be used by customer as required.
1.25. The Maricopa County Attorney's Office needs to read case reports and all attachments for cases that have been
submitted for prosecution. They need to further reports back to the detectives with notations, and they need to import case
information into their internal system upon request. Since they use such a small portion of RMS functionality, can they be provided a
viewer or a form of RMS lite at a reduced cost.
2. USER INTERFACE DESIGN
2.1. The system should provide a client system for completing all RMS supported reports and queries which utilizes a browserbased client which can be used over the County's intranet.
2.2. The system should make use of Graphical User Interface (GUI) and “Windows” Technologies for both mobile and desktop
environments- The system will be designed for ease of use, taking advantage of industry standard graphical interfaces.
2.3. The design of the user interface should assist both experienced and novice users to complete individual forms and entire
reports.
2.4. The mobile client should support a day and night mode for screen display (to include day and night mode for the map
display, field based reporting, and all other applications available on the MDC).
2.5. The system should take advantage of native Windows user interface capabilities to enhance the data entry process:
2.5.1. Drop-down lists
2.5.2. Auto fill-in/auto-completion
2.5.3. Check boxes, radio buttons
2.5.4. Tool bars, pull-down menus
2.5.5. On-screen buttons, shortcuts
2.6. The system should include drop down lists for restricted entry fields but will not require the user to access the list if they
know and wish to enter a correct value directly.
2.7. The interface should utilize tabs to keep forms self-contained, as opposed to using multiple, separate windows to perform
all available functions.
SERIAL 11086-RFP
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
2.8. Tabs should group all related data.
2.9. The system should provide a clear/reset button that removes data from all fields on the current screen which employs a
mandatory second key-stroke to verify that the user desires to remove the data.
2.1. When a user is required to enter their name and ID number, the system should enter the name and ID of the user that is
logged on automatically.
2.11. The vendor should describe their approach to auto-saving data that has been entered into forms and fields including its
ability to be configured.
3. SEARCHING
3.1. The system should allow users to use forms for searching. The intent is to simplify use of the system by making data entry
and search forms user friendly.
3.2. The system should have the ability to;
3.2.1. Search for event records by such common criteria as case number, incident type, date and time,
victim/witness/suspect name, address, physical descriptors, POI, occupation, property, etc.
3.2.2. Search for data by any field (e.g., name, phone number, address, intersection. date of birth, employee badge number,
date, code, serial number, etc.), or combination of fields.
3.2.3. Search for all case reports by EIN, date and time ranges, District, Patrol Area(s), and other user defined criteria.
3.2.4. Conduct a “free-text” search of all narrative fields in the RMS.
3.2.5. Initiate searches and queries using full or partial data strings.
3.2.6. Perform searches in wildcard and partial spelling format
3.2.7. Provide Soundex or equivalent search for all “free text” narrative and data fields.
3.2.8. Display exact matches and close or near matches
3.2.9. Provide advanced and flexible query and search capabilities through user-friendly, ad-hoc reporting.
3.2.10. Search for a case number using the date the offense was reported.
3.3. The system should provide a "concept" space that can be used as a universal search field similar to Google or Yahoo.
3.4. The system should utilize a concept algorithm or "fuzzy logic" to automatically compute the strength of relationships
between each possible pair of concept descriptors identified in a search. For example, if a user is searching for all case reports
where a "boom-box" was reported stolen, the system will return a summary listing of all case reports where boom-box, boom box,
personal stereo, and portable stereo, etc. were listed as stolen. If a user is searching the RMS for all records containing the name
"Jacobson", the system should return a summary report of records listing names that are similar like “Jacobsen”, “Jaycobsin” etc.
3.5. The system should have the ability to query multiple databases, e.g., local and state name databases, through use of a
single transaction.
3.6. When a user is searching the RMS for information a single inquiry should yield results that contain all RMS records
including associated electronic files (e.g., scanned images, and all other available objects) via a summary page with hyperlinks or
other similar method.
3.7. When users enter a search parameter the system should display a summary of multiple valid records and allow the user to
select the desired record.
3.8. The system should allow users to cancel and exit a search query while it’s active.
SERIAL 11086-RFP
84
85
3.9. The system should allow individual users to save search criteria in their profile for re-use.
3.10. The system should possess extensive “drill down” capabilities. For example, if a name search returns four potential
candidates, the user should be able to view each record by selecting it in some manner. If the record displayed then had a codefendant, the user should be able to select that record and see the co-defendant records, and so on.
86
3.11. The system should have the ability to retrace the drill down steps to return to where the drill down began. The vendor
shall describe its method to accomplishing this functionality (e.g. drill down tree, etc.)
3.12. The system should allow the County to configure the types and numbers of internal and external databases searched for
both the desktop and mobile computing environment.
3.13. It is expected that District and Patrol Area boundaries will change in order to ensure appropriate staffing based on
workload demands. Therefore, when conducting historical searches, the system should:
3.14. Ensure that District and Patrol Area boundary changes are reflected in the Master Address Index so that historical data
searches return only data contained within the new boundaries and/or (user-definable) data contained within the old boundaries for
comparative analysis.
87
88
89
90
3.15. Ensure that boundary changes are reflected in every other proposed module. For example, when a pre-boundary change
case report is reviewed as part of a search return, both the new and old District and Patrol Area numerical designator will appear in
the appropriate fields.
91
92
4. INDEXES
4.1. The Master Name Index should incorporate subject records from various sources. Individuals identified in any record
(suspect, victim, witness, complainant, etc.) will be stored.
4.2. MCSO is asking the vendors to detail how they will process indexable subjects that are truly unknown (no associated
identifiers/information at all) and indexable subjects that are unknown but have some associated data (an MO for example).
MCSO's goal is to avoid cluttering its name index with useless entries, but it also does not want to lose valuable associated
information for a subject that is unknown.
93
94
95
96
97
98
99
100
4.3. Information from field interview records, case reports, warrants, and all other data sources should be indexed to this file.
4.4. The system should provide a means for name and object search (including aliases) both by exact spelling, diminutives and
phonetic search capability.
4.5. The system should notify users of possible matches (hits) immediately.
4.6. The system should include automated and semi automated routines to assist the application administrator or other
authorized user with managing the indexes. The purpose of these features will be to ensure that index associations are correct and
to prevent, as much as possible, cases from being associated with the wrong entry in an index. For example, the application should
be able to identify when a record does not have an associated master index entry, or if a master index entry has a duplicate record.
4.7. Upon the entry of data into any field which is associated with a master index the system should automatically search the
appropriate master index for similar entries.
4.8. In the event that the master index contains a similar name or item, a summary list should display showing the particulars of
the names or items that are similar to the one being entered.
4.9. The system should allow the user to associate the name or item being entered with one on the list retrieved from the
master index.
SERIAL 11086-RFP
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
4.10. When a user who is completing a case report or other form elects to associate a name or item with an existing master
index record the application shall create a conditional association.
4.11. Once a user has created a conditional association the system will cease searching the master indexes for that particular
name or item during the remainder of the report entry process.
4.12. Conditional associations should remain until the system administrator or another authorized user reviews the conditional
association.
4.13. If the two names or items refer to the same person or item, the authorized reviewer should be able to approve the
conditional association and make it permanent.
4.14. The system should clearly delineate between associations that are conditional and those that have been positively
verified through a fingerprint identification.
4.15. If the names or items have been incorrectly associated, the authorized reviewer should have the ability to remove the
conditional association and create a new master index record for the newly entered name or item.
4.16. The system should allow only authorized users to delete or transfer master index associations from one master index
record to another.
4.17. The system should allow only authorized users to join two or more master index records that erroneously appear in
multiple master index records. When joining two master index records the application shall preserve the most recently entered
information.
4.18. The system should also permit authorized users to un-link permanent associations.
4.19. The system should have the ability to automatically collect information from all reports and add them to the appropriate
master indexes.
4.20. The system should be able to create and maintain basic agency-definable Master Name Index records, including but not
limited to multiple entries for such data elements as:
4.20.1. Name (transposed middle and/or first name),
4.20.2. Address,
4.20.3. Aliases,
4.20.4. Date of Birth,
4.20.5. Nickname(s),
4.20.6. Place of Birth,
4.20.7. Sex (male, female, transgender, etc.).
4.20.8. Social security numbers,
4.20.9. Ethnicity
4.20.10. Hair (color, length, style, etc.)
4.20.11. Eyes (color, shape, size, etc.)
4.20.12. Glasses
4.20.13. Facial hair
4.20.14. Face shape
4.20.15. Complexion
SERIAL 11086-RFP
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
4.20.16.
4.20.17.
4.20.18.
4.20.19.
4.20.20.
4.20.21.
4.20.22.
4.20.23.
4.20.24.
4.20.25.
4.20.26.
4.20.27.
4.20.28.
4.20.29.
4.20.30.
4.20.31.
4.20.32.
4.20.33.
4.20.34.
4.20.35.
4.20.36.
4.20.37.
4.20.38.
4.20.39.
4.20.40.
4.20.41.
4.20.42.
4.20.43.
4.20.44.
4.20.45.
4.20.46.
4.20.47.
4.20.48.
4.20.49.
4.20.50.
4.20.51.
Teeth (gold, missing, decayed, dentures, etc.)
Height
Weight
Build
Handed
Body piercing(s),
Special Characteristics (Scars, Marks, Tattoos, including location(s), etc.),
Clothing type,
Clothing description,
Alcohol use/addiction,
Drug use/addiction,
Escape risk,
Juvenile,
Adult,
Mental risk,
Physical handicap,
Missing/deformed limbs,
Missing/deformed appendages,
Sex registrant,
Sex offender
Suicidal,
Violent offender.
Gang association/affiliation
Terrorist
Distinguishing characteristics (County-defined),
Driver License number and state (multiple),
FBI #,
Flag (sex offender registrant; domestic violence flag, etc.),
Fingerprints on file,
ID coding (e.g., Fingerprint, DNA, FBI#),
Involvement (e.g., suspect, witness, victim, person pawning, etc.),
Known associates (multiple),
Incarceration status
County booking number as assigned by the Sheriff's Office
Local assigned booking number
Online screen name,
SERIAL 11086-RFP
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
4.20.52. E-mail address,
4.20.53. Pager number,
4.20.54. Phone number,
4.20.55. Photo on file,
4.20.56. And any other related case number(s),
4.20.57. Subject's Employment
4.20.58. Employer (multiple),
4.20.59. Occupation,
4.20.60. Employer Name,
4.20.61. Employer Address,
4.20.62. Employer Telephone number (multiple),
4.20.63. Relatives (Multiple),
4.20.64. Name,
4.20.65. Address,
4.20.66. Telephone Number (Multiple),
4.20.67. Sex,
4.20.68. Relationship,
4.20.69. Employer (multiple),
4.20.70. Occupation,
4.20.71. Employer Name,
4.20.72. Employer Address,
4.20.73. Employer Telephone number (multiple),
4.20.74. Probation officer name and contact information
4.20.75. Special restrictions
4.20.76. Associates of the subject.
4.21. The system should have the ability to track agency-defined individual changes (for an individual) for all of the
aforementioned Master Name Index records such as but not limited to:
4.21.1. Physical description changes,
4.21.1. Address changes,
4.21.3. Phone number changes,
4.21.4. Driver License changes,
4.21.5. Name changes,
4.21.6. Date of birth changes.
4.22. The system should be capable of identifying duplicate records by drivers' license number, and all other user-defined
criteria.
4.23. The system should be capable of consolidating designated duplicate records.
SERIAL 11086-RFP
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
4.24. The system should be able to verify and edit names based on agency-defined data including but not limited to:
4.24.1. Full or partial name (first name or last name),
4.24.2. Address,
4.24.3. Date of birth,
4.24.4. Sex
4.24.5. Race
4.24.6. Driver License number,
4.24.7. Local arrest number,
4.25. The system should have the capability to assign agency-specified descriptions of an individual and create a Master Name
record without having a specific name (e.g., person known for a nickname, attribute).
4.26. The system should have the ability to cross reference the Master Name file with all other records associated with an
individual i.e., case reports, images, businesses, pawn information, vehicles, phone numbers, warrants, co-defendant(s), etc.
4.27. The system should have the ability to combine records of an individual if they have been entered under different names
and to automatically track those names as aliases of the individual. This would apply to a situation where the same person has two
identities.
4.28. The system should also have the ability to combine records of an individual if they have been entered under different
names and to reconcile those names if a duplicate entry exists for the same person.
4.29. The system should have the ability to attach additional/multiple identifiers (DOB, DL, user defined, etc.) to the same
name/aliases.
4.30. The system should provide a means for vehicle search by all vehicle master data. It should perform edit validation by
preventing duplicate vehicles from being entered.
4.31. The system should provide a menu for searching for vehicles by user-selected attributes including partial license plates.
4.32. The system should create and maintain basic user-definable Master Vehicle Index records, including but not limited to
multiple entries for each data field below:
4.32.1. Associates (owner, driver, passenger),
4.32.2. Name,
4.32.3. Address,
4.32.4. Date of Birth,
4.32.5. Race,
4.32.6. Sex,
4.32.7. Aliases (multiple),
4.32.8. Phone Number
4.32.9. Contact information,
4.32.10. Date
4.32.11. Time
4.32.12. Location
4.32.13. Reason for contact (summons, warrant, field contact, crash report, etc.)
SERIAL 11086-RFP
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
4.32.14. Reporting area (Patrol Area)
4.32.15. EIN of officer conducting contact
4.32.16. Vehicle (automobile, boat, motorcycle, etc.) information,
4.32.17. Make
4.32.18. Model,
4.32.19. Color,
4.32.20. Year, and range of years
4.32.21. Number of doors
4.32.22. Tag number
4.32.23. VIN number
4.32.24. Other special characteristics (bumper sticker, damage, etc.).
4.33. The system should have the ability to capture and maintain the following minimum agency-definable towing information
for a vehicle (multiple records) such as:
4.33.1. Date towed,
4.33.2. Time towed,
4.33.3. Location towed to,
4.33.4. Number of days/hours stored,
4.33.5. Name of tow company,
4.33.6. Phone number of tow company,
4.33.7. Reason towed,
4.33.8. EIN of officer requesting tow,
4.33.9. Date available for release,
4.33.10. Release date,
4.33.11. Released by,
4.33.12. Released to (with contact information).
4.34. The system should have the ability to link information related to individuals associated with a vehicle with the Master
Name Index.
4.35. The system should also maintain the additional minimum user-definable Master Indexes:
4.36. The system should have the ability to associate multiple digital mug shots with the Master Name Index and perform a
"point and click" retrieval of the associated mugs hot at the desktop and MDC level.
4.37. Users should have the ability to make a notation of their interest in the subject of a master index record. (Person or Item
of Interest such as a car, telephone number, location, etc.)
SERIAL 11086-RFP
258
259
260
4.39. When a user runs a search on a person or item of interest name (POI), the system should notify the user making the
search or updates that the record is the subject of interest to another user.
4.40. When a master index record with a POI indication is retrieved, the system should notify the user initiating the POI and any
other user who searches the RMS for the same POI.
4.41. The MCSO generally provides only case report summaries to authorized parties. The system should permit the system
administrator or other authorized users to edit report information to filter sensitive or confidential information before the report is
released to the public or for general use outside of the department. The type of information that is edited includes victim names in
certain types of cases, juvenile information, or information that is considered by the agency to be sensitive to an investigation.
261
4.42. In the case of formatted and structured data, report output programs should be able to produce a redacted version of
specific report data. In the case of narrative or otherwise unstructured information, the redaction process may requires a manual
step to produce a public version of the report.
262
4.43. The proposed RMS application should also allow the system administrator or other authorized user to determine which
fields may not be printed on copies of reports that are to be distributed to the public.
4.44. The MCSO Legal Compliance Section requires the ability to produce report copies for the General Public which they often
have to redact and copies for the County Attorney without redaction.
4.45. The system should provide the ability to manually enter old case reports into the system. The original case number and
approving supervisor information should be maintained. Process should be limited to Central Records.
4.46. The system should be capable of notifying the user initiating the POI and/or Item of Interest via:
4.46.1. The County e-mail system
4.46.2. Any e-mail address entered by the user
4.46.3. A text message to any telephone or pager number entered by the user
4.46.4. All or any combination of the above methods simultaneously.
4.47. The system should allow the user entering a POI to specify a “blind” notification when someone else conducts a search
for the same POI.
4.48. Hits on “blind” persons or items of interest should notify the person who entered the “blind” notification request but will not
notify the user conducting the search.
4.49. No one, other than the person entering the POI, the system administrator or other authorized user, will be able to see a
list of POI entries.
5. INTERNET BASED CITIZEN CRIME REPORTING
5.1. MCSO wants to make information available to citizens about crimes occurring in their neighborhoods. Inquiries would be
based upon postal codes or common neighborhood/area names. Vendors are being asked to offer any solutions that they can
provide to meet this requirement. Neighborhood watch groups need the capability to view the crimes in their designated areas.
263
264
265
266
267
268
269
270
271
272
273
274
275
6. MULTI-UNIT CRIME FREE HOUSING
SERIAL 11086-RFP
276
6.1. Apartment complexes that register with the Crime Free Housing Program need to be provided with information on calls for
service at their locations. Both the complex managers and owners are sent E-mail or postal notices that describe what has taken
place at their complexes. The system also keeps running totals of all activities and produces reports showing any actions taken by
the managers/owners and whether any repeat offenders are involved. Vendors are being asked to offer any solutions that they can
provide to meet this requirement.
277
278
279
280
7. PRINTER SERVICES
7.1. The system should offer any authorized person the ability to print:
7.2. The entire case file, including all forms, notes, activities, images, etc.
7.3. A “public" case file which includes forms defined by the system administrator or other authorized employee as being of
public record.
7.4. The system should not allow a public report to be printed before all reports are approved.
7.5. The system should provide the ability to print a single user-selected form, activity, image, or note from the case file.
7.6. The system should have the ability to direct output of any inquiry or report to:
7.6.1. a screen (workstation and MDC)
7.6.2. e-mail
7.6.3. printer
7.6.4. PDF.
7.7. The printed output should be configurable by the System Administrator.
7.8. Should the offeror's system impose a limit on the amount of text that can be inputted into a narrative field, the solution
should provide a simple option for inputting additional text into the same report and associating data from the original narrative field.
This is especially utilized when preparing lengthy investigations.
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
7.9. For example, when a Supplement Report is prepared on-line, if the narrative area exceeds the amount of space on the first
page, the narrative should continue on a subsequent page while maintaining the original header and footers of the report.
7.10. In the above instance, all information entered into the header and footer of the first page of the report should populate the
header and footer of the second and subsequent pages that may be required.
7.11. All printed reports, whether initiated by users as the result of a an ad-hoc search or prepared from the system's preformatted report library should provide a consistent, uniform, and organized appearance in format, layout, size, font, etc. whether
they are printed from the system application or printed after input to other applications (WORD, EXCEL, etc.).
7.12. The system should have the capability when printing reports to:
7.12.1. determine length of report prior to printing
7.12.2. select printer
7.12.3. specify number of copies
7.12.4. specify page ranges and multiple pages, and
7.12.5. cancel print jobs and,
7.12.6. have a user-definable default for printing.
7.13. The system should have the ability to track the following information when a report is printed:
7.13.1. user ID
SERIAL 11086-RFP
302
303
304
305
306
7.13.2. number of pages printed.
7.13.3. date and time
7.13.4. printer ID/name
8. FIELD BASED REPORTING (FBR)
8.1. The RMS should be a user-friendly system that is available to desktop computers and field officers via Mobile Data
Computers, and have the capability for the County to support officers using wireless hand-held devices. The system should enable
on-line creation/submission of field reports from the network utilizing a wireless RMS connection. It should include the ability to prepopulate needed forms with CAD information, allow for customizable workflow changes, and accommodate supervisor
receipt/review/editing/approval as well as re-routing of reports (before and after approval).
307
308
309
310
311
312
313
314
315
8.2. The offeror's FBR client should be completely integrated with the offeror's CAD and RMS.
8.3. Users should be able to initiate and complete all reports and forms from:
8.4. A desktop workstation connected to the RMS via a local or wide-area network.
8.5. A mobile data computer attached to the RMS via a wireless connection,
8.6. Any computer which supports a browser system and which has access to the County’s local or wide area network, and
8.7. The local FBR client .
8.8. The proposed FBR should:
8.8.1. Support single entry of data for all forms, reports, and other data entry tasks.
8.8.2. Support cut, copy, and paste functions between applications - Mobile and FBR/RMS, and within each individual
application.
8.8.3. Include features commonly found in word processing software such as type ahead, spell check, word wrap, bold,
underline, tab, insert tables and graphics, etc.
8.9. The vendor should describe their system's capability to copy MS WORD narratives that include different colors, fonts, and
other textual formatting, into the FBR, while maintaining the original source formatting.
8.10. Not have any artificial limit on the number of text characters that can be entered into narrative fields.
8.11. Provide users with the ability to digitally capture mug shots, pictures, audio files and other data formats and attach them
to a case record from workstations and MDCs.
8.12. The system should be able to accept data from County approved and supported software applications such as MS Office.
8.13. The system should provide the ability to present agency-defined templates of narratives and report templates for various
user-defined types of events.
8.14. Each authorized user should have the ability to create and save their own report narratives/templates to their system
profile.
8.15. The system should allow the system administrator to remotely update MDC and desktop computers with user-definable
report templates.
8.16. The system should have the ability to receive incident data from the offeror’s CAD system and use this as the default for
report entry when a case report is created.
316
317
318
319
320
321
322
323
324
SERIAL 11086-RFP
325
8.17. The system should have the ability to receive information (name, address, vehicle, etc.) from ACJIS and the RMS and
transfer that information directly into case reports, the Field Contact Card (FI), property and evidence reports, and any other system
generated reports.
326
8.18. Users should be able to begin a new case report directly in the RMS. In this case the system will obtain a case number
from the CAD system.
8.19. The numbering system should be designed to verify that all cases receive a case number, and that no case numbers are
duplicated. The case number provides a means for linking information related to a specific event.
8.20. Each RMS record should retain the case number assigned by the CAD system.
8.21. The system should have the ability to change Incident Report numbering with the cutover to an intelligent numbering
system, building in a Julian calendar date or similar to aid in searches in the future. This process should also be able to clearly
identify legacy numbers from new numbers to indicate where to find data – archive system/data warehouse or new system.
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
8.22. The system should be able to populate data fields with the current date, and address fields with the current County and
state based on an entered zip code.
8.23. The County requires that the system be initially capable of facilitating the preparation of, and producing all information
contained in the below reports at the desktop and MDC level:
8.23.1. Maricopa County Sheriffs Department's Incident Report
8.23.2. Maricopa County Sheriffs Department's Field Investigation Report
8.23.3. Maricopa County Sheriffs Department's Supplementary Interrogation Report
8.23.4. Maricopa County Sheriffs Department's Property Forms/Supplemental Property Report
8.23.5. Traffic Statement
8.23.6. Pursuit Report
8.23.7. Blood Draw Report
8.23.8. Alcohol Influence Report
8.23.9. Property Release Authorization
8.23.10. Domestic Violence Supplement
8.23.11. Juvenile Referral
8.23.12. Agency Request for Scientific Examination (non- DPS)
8.23.13. Arizona State Department of Transportation's Crash Report
8.23.14. Photographic Film Submission Form
8.23.15. Use of Force Report
8.23.16. Property Seizure Form
8.24. It is expected that additional reports will be added to the FBR in a phased implementation. The system should also
provide tools that allow the County to create, utilize, and manage electronic reports within the RMS that can be utilized by the FBR.
The goal is for the County to create additional reports without vendor assistance.
8.25. The proposed RMS system should minimally support all data fields that currently appear on County criminal offense and
investigative report forms.
SERIAL 11086-RFP
350
8.26. When the user prepares a report and assigns a classification, the system should inform the user of all related reports that
should be completed in association with the event classification. In this example, all data entered into the original form should be
available to and automatically populate any subsequent related forms that are completed.
351
352
8.27. The system should support in-vehicle printing.
8.28. The system should provide a means of storing the electronic signature of each employee so that their signature appears
on the report.
9. GENERAL REQUIREMENTS
9.1. The system should include a fully-functional RMS client designed for and capable of effective use on a mobile data
computer and hand-held device attached to the RMS via the following wireless connection types:
9.1.1. broadband
9.1.2. commercial service providers
9.2. The mobile RMS client should present the same user interface as the proposed desktop client for RMS. The need for a
client which is integrated with the RMS server application is to avoid any delay in posting information from a mobile report to the
RMS and to allow users to access and utilize information stored on the RMS server via the proposed mobile client application.
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
9.3. Offerors should provide a step-by-step description of the completion of a Departmental Report from the transfer of CAD
data to the MDC, to the entry of event details, to the submission of the report for review, to the submission of the report to the RMS.
9.4. The proposed mobile client application should utilize the Microsoft Windows operating system.
9.5. The mobile client should be designed so it is able to connect directly with the RMS application.
9.6. The mobile client application should allow the user to access and continue to process an RMS report form even when the
network connection has failed.
9.7. If the network connection is lost while a user is completing a report it should not result in the loss of any data or cause the
application to freeze.
10. USER INTERFACE
10.1. The user interface for the mobile client application should resemble the desktop application in the following minimum
ways:
10.1.1. Form design
10.1.2. Form navigation
10.1.3. Field labels
10.1.4. Command codes
10.1.5. Short-cut keys
10.1.6. Graphic command buttons
10.1.7. Logon/logoff requirements, and
10.1.8. System responses.
10.2. The system administrator should have the ability to configure the mobile client application to lock and blank the user
interface after an agency defined period of inactivity.
10.3. After the application is locked and blanked the user should be able to recover full use of the application through the entry
of the user's network password.
SERIAL 11086-RFP
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
10.4. Users should have the ability to manually lock and blank the computer screen immediately with a single keystroke and
recover full use of the application through the entry of the user's network password.
10.5. The client should support a day and night mode for screen display, to include day and night mode for the map display
(MDC only).
10.6. Additional Mobile Data Computer User Interface requirements are listed in the CAD functional requirements section,
Mobile Specific Functionality.
11. CASE REPORT PROCESSING
11.1. The system should include a configuration table which allows the application administrator or authorized user to
determine the routing of case reports to named persons, position titles, or groups, based on the:
11.2. The system should check each completed form to ensure:
11.2.1. that the user has entered a value in each mandatory field, and
11.2.2. that entries in value restricted fields match one of the acceptable values for that field. Users have requested an "OR
Wizard" concept that would prompt for required fields based upon the type of crime being reported.
11.3. If required fields have not been completed, the system should denote the missing or incorrect entries in a distinctive
manner.
11.4. The system should provide a command or function for auditing (UCR edits, etc.) the report at any time.
11.5. The system should allow a user to conditionally save a partial report or one with errors, but the system will notify the user
that required fields have not been completed or the report contains errors.
11.6. The system should be capable of being configured to ensure that a partial report or one with errors cannot be distributed.
11.7. The system should allow the report to be edited by the user and saved in “conditional” mode as is necessary.
11.8. The conditional report should be saved on the server and the local MDC/Desktop.
11.9. The reviewer should have the capability to return the conditional report to the original user with comments attached
utilizing a notepad function as described below.
11.10. The system should allow the copying or moving of data from one field to another without reentry.
11.11. The routing of reports for review and approval should occur entirely within the vendor's system and not require the use of
an external e-mail or similar system.
11.12. When all required fields on a report have been completed the system should allow the reporting officer to either route the
report to a predetermined supervisor or to a named supervisor or group mailbox for review.
11.13. In the event that supervisory review requires the reporting officer to add additional information or make changes to the
report, the reviewing official should have the ability to return the report to the originating officer.
11.14. The reviewing official should be able to utilize a notepad or other similar system to attach notes to the report that is
returned.
SERIAL 11086-RFP
398
11.15. The County is interested in reviewing alternative options for the supervisory review process that allows reviewers to
easily reference their supervisory notes and/or edits to specific sections of the report. The purpose of this functionality is to enhance
the ease of review by the both the reviewer and the reports author.
399
11.16. The system should be configurable to allow the reviewing supervisor to make corrections/changes to the report, if the
County so desires.
11.17. The originating officer should be able to view the reviewing official’s notes and the returned report on the screen
simultaneously.
11.18. The system should maintain an audit trail of all reports produced which captures all times and dates related to report
completion, report submission, and any changes that are made to the report as a result of the review and approval process.
11.19. The system should maintain a complete audit trail of all changes to database records or forms changed, including the
following information:
11.19.1. identification of the user making the change,
11.19.2. identification of the record being changed,
11.19.3. the old and new value of each field changed, and
11.19.4. the date, time and location from which the changes were made.
11.20. The system should be configurable to allow agency-definable report type(s) to be reviewed for quality control.
11.21. The system should be configurable to allow the system administrator to define which users and/or user groups can be
granted permission to review reports for quality control.
11.22. After a report is approved by a supervisor and posted to the RMS, the report and all information contained in the report
should be available to all authorized RMS users.
11.23. Unapproved reports should be prominently marked as such whether displayed on-screen or printed.
11.24. The system should allow the system administrator or other authorized user to determine which reports or forms will be
reviewed and approved by a supervisor prior to being committed to the database.
11.25. The system administrator should be able to set parameters for bypassing the Records Division approval process based
on case report event type, possible Master Index errors, and duplicate entries.
11.26. The system should allow supervisor approved reports to be available for distribution, but the reports should be flagged
as "pending" until such time as they are approved by Records Section QA Clerks.
11.27. The system administrator should be able to set parameters to delineate which portions of any report Records Section
clerks are permitted to modify.
11.28. The system should be capable of being configured to ensure that corrections by reporting officers to approved reports
are made using a Supplemental Report.
11.29. Certain report types (i.e. Use of Force, Dog Bite and Pursuit) should automatically send a notice to Internal Affairs.
12. TRAFFIC
12.1. The system should provide the capability to enter and manage all traffic-related reports and traffic citation information.
Requirements for traffic analysis include the recording and correlation of crash reports and enforcement activity. Data collected
throughout the County may affect road upgrades and thoroughfare modifications. The system will also provide standard and agencydefined traffic enforcement analysis related to moving citations, traffic arrests by location, and other similar criteria.
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
SERIAL 11086-RFP
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
12.2. The system should have the ability to:
12.3. Correlate traffic crashes with specific geographical locations (e.g. street intersections, mid-block)
12.3.1. Draw crash diagrams
12.3.2. Generate Traffic Crash Reports by:
12.3.3. Time and day of week
12.3.4. Date range
12.3.5. Location (Location includes: 1) all parts of a primary road, including intersections which may not be part of the
primary road), 2) private property, 3) parking lots, 4) service roads, 5) mid-blocks, 6) intersections, address range, hundred block,
etc.)
12.3.6. Officer
12.3.7. Generate a High Crash Locations Report, including but not limited to:
12.3.8. Mid block
12.3.9. Intersections
12.3.10. Distance from intersection
12.3.11. Patrol Area
12.3.12. District
12.3.13. Sub-Census
12.3.14. Generate user-definable monthly report of operations:
12.3.15. Total traffic crashes
12.3.16. Traffic crashes by category
12.3.17. Fatality crashes
12.3.18. Number of persons killed
12.3.19. Injury crashes
12.3.20. Number of persons injured
12.3.21. Non-injury crashes
12.3.22. Crashes w/ DWI
12.3.23. Crashes w/ bicycle
12.3.24. Fatal
12.3.25. Injury
12.3.26. Non-injury
12.3.27. Crashes w/ pedestrian
12.3.28. Fatal
12.3.29. Injury
12.3.30. Non-injury
12.3.31. By use-definable date ranges
12.3.32. By user-definable driver/passenger/pedestrian age range
12.3.33. By all other combination of user-definable data elements on the FR 300
SERIAL 11086-RFP
454
455
456
457
458
12.3.34. Total calls for service including traffic crashes
12.3.35. Citations issued by category, charge, and officer
12.3.36. Total citations issued (and by location, date and time range, etc.)
13. TRAFFIC CONTROL
13.1. Traffic enforcement duties include conducting overweight/unsafe vehicle inspections, DUI enforcement, accident
investigations, issuing traffic citations etc. These duties, especially DUI enforcement, require the completion of numerous different
forms, many of which contain duplicate information. The department wants a system that will address the duplicate entry problem
and allow them to incorporate an electronic ticketing solution.
459
13.2. If an electronic ticketing solution is proposed, citation documents being uploaded to the Court need to pass through the
RMS to populate Citation Data needed for statistical analysis and resource allocation studies.
13.3. The County is requesting a Forms Library that is centrally controlled to maintain the department's special forms templates.
Forms entered into the library would have fields that are common between forms mapped to each other so that once one form is
completed, its mapped data can auto-populate subsequent forms for the same event upon request. Documents created in the RMS
should also have common fields mapped to like fields in the Forms Library templates. The narrative free form sections of reports in
the Forms Library need to be able to utilize features commonly found in MS Word.
460
461
462
14. INVESTIGATIONS
14.1. Case Agents/Detectives need the capability to submit cases to the County Attorney when they feel that they are ready for
prosecution. See the Interfaces Section of this document for further detail. Once a case is submitted the system should track the
time it has been at the County Attorney's office, and notify the Case Agents once a user selected time period has elapsed.
463
14.2. The system should track associations between persons such that it will be possible to determine from a name search all
other persons who have been associated with that person as a co-defendant, in a vehicle during a field interrogation, as a witness
against the person or in any other documented criminal justice involvement.
464
14.3. The system should have the ability to retrieve cases with similar modus operandi to assist officers and detectives in
solving crimes. For example, similar victim types, crimes occurring in close proximity or within a given date or time range, or in which
similar kinds of property were taken, tools used, method of entry, point of entry, characteristic actions, evidence found, victim
type/location, or weapon used.
465
14.4. The system should have the capability to identify cases with a large number of matched suspect descriptors such as
glasses, teeth, speech, demeanor, facial hair, complexion, scars, marks, tattoos, hair length, hair style, hair color, ethnicity, height,
weight, or gender. The system should provide a value (e.g., high, medium, low, statistical, etc.) rating with the number of matches
listed across the descriptors.
466
14.5. The system should have the ability to display and print a list of all individuals associated with a given case sorted by their
association with the case and then alphabetically.
14.6. The above report will include the association of each individual to the case.
14.7. The system should allow a user to retrieve all records for a given associate by clicking on the name, or by some other
simple method.
467
468
SERIAL 11086-RFP
469
14.8. When an officer/detective enters a name into a case report and then tabs to the next field, the RMS should automatically
begin searching local records to determine if the subject name appears in any other case reports, in any capacity (victim, suspect,
witness, etc. including associations with addresses, phone numbers, vehicles, and other similar attributes).
470
14.9. The user should be alerted to all possible matches via an agency definable message, which contains a hyperlink to a
summary page listing all possible matches, and hyperlinks to the underlying information regarding each subject.
14.10. The system should allow authorized users to password protect case reports and supplements so that they cannot be
read by anyone without authorization to do so.
14.11. The system should allow authorized users to "compartmentalize" data contained within their case reports and
supplements. For example, the System Administrator and authorized users will be able to configure the system so that all original
and supplemental reports prepared by the Homicide Detail and some or all (user-definable) of the data contained in those reports
are not accessible to any user not assigned to the Homicide Detail.
471
472
473
474
15. Traffic Accident Investigations
15.1. The MCSO Vehicular Crimes Unit (VCU) is dispatched to an accident/whenever there is a fatality, a potential fatality, or
criminal activity is involved. The report prepared by VCU will always become the primary case report. In situations where the first
unit on the scene has already submitted a report, the initial report must become a supplement to VCU's report. A synopsis of reports
prepared by VCU need to be sent to select members of the MCSO management team automatically upon completion without
having to do any manual distribution. The synopsis document will consist of event header information along with a narrative event
summary. VCU will enter the narrative summary as the first paragraph of the DR narrative entry section, Vendors are ask to detail
how they can best satisfy VCU's requirements, and perhaps offer alternatives that will require less effort.
475
15.2. In situations where an accident occurs within a neighboring jurisdiction and MCSO has some vested interest in the
accident (i.e. a MCSO employee was involved, County property was damaged etc.) the other jurisdiction will complete and submit
the accident report' and MCSO Traffic Investigations will complete a DR. In these situations the subjects involved need to be
identified as Driver, Registered Owner, Passenger in addition to the normal descriptors of Suspect, Victim, Witness, etc. Vendors
are to describe how they can satisfy this requirement.
476
477
478
479
480
481
482
15. CASE MANAGEMENT
15.1. The proposed RMS system should provide a variety of management and analysis tools to:
15.1.1. effectively manage investigator workloads,
15.1.2. monitor performance, and
15.1.3. allocate departmental resources.
15.2. The case management module should be tightly integrated with the other portions of the RMS system.
15.3. The system should allow authorized users to display all new cases entered for a given date range so that he/she can
review the cases for assignment.
15.4. The system should respond with a summary display that shows the report number, the location of the offense, the officer
initiating the case, the offense type, the victim name, and the date on which it was initiated.
15.5. The system should allow authorized users to search and display all cases by:
15.5.1. assigned officer/detective,
15.5.2. offense type,
483
484
485
486
SERIAL 11086-RFP
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
15.5.3. date and time of offense,
15.5.4. aging (how long investigation has been ongoing),
15.5.5. shift and/or squad,
15.5.6. station
15.5.7. case status, and
15.5.8. division.
15.6. The system should respond with a user-definable summary display which shows the case number, the victim name, the
detective assigned to the case, the offense type, the status of the case (including the date when the case was last modified).
15.7. Authorized users should be able to set a threshold for case aging and be able to receive automatic notifications whenever
any active cases exceed the pre-set case inactivity threshold.
15.8. The above requirement should also include the ability for users to define case aging threshold notifications for userdefinable incident classifications, individually, and by group (e.g. The ability for a supervisor to set an alert that notifies an individual
or group of employees (e.g. supervisors) when any or all active sex offense incident reports have reached a 90 day period from date
of offense). The purpose of this requirement is to notify users when a case requires review per department policy.
15.9. Each supervisor should have the capability to set the case aging threshold for their individual squads, or for any particular
case and be able to receive automatic notifications whenever any active cases exceed the pre-set case inactivity threshold.
15.10. The system should have the ability to track and report case outcomes and crime statistics on all records that remain in
the on-line database.
15.11. The system should provide the ability for users to query by case classification (i.e. active, inactive, suspended, etc.) and
easily produce a report that provides closure rates in summary and statistical formats. The purpose of this requirement is to facilitate
the monitoring of arrest and other similar metrics.
15.12. The standard case management display should include the offense type, the case number, date and time the incident
was reported, location, type of report, case status and other user-definable fields.
15.13. It should be possible for the system administrator or other authorized user to configure the system so that cases are
automatically assigned to a specific detective/officer based on:
15.13.1. offense location, or
15.13.2. offense type, or other user-defined criteria.
15.13.3. victim
15.13.4. suspect
15.14. The system should enable an authorized user to assign a case to a specific detective or other member of the
Department.
15.15. The department currently utilizes a paper Case Solvability Factors Assignment Form (CSFA) on which solvability factors
are reviewed in order to determine if and to whom each case should be assigned for follow-up investigation. The system should
have the ability to create an electronic version of this document that can be completed by the supervisor responsible for reviewing
cases.
15.16. The user should have the ability to link the CFSA to the case that is being assigned so that the CFSA form is routed to
the assigned detective who receives the notification that they are being assigned to the case.
SERIAL 11086-RFP
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
15.17. The CFSA should become part of the case file and accessible to users as part of the case file.
15.18. Users should be able to enter identifying information about assisting detectives.
15.19. The system should enable any authorized user to transfer a case to another officer/detective/supervisor or employee for
processing.
15.20. The system should track both the reassignment of cases and changes in officer/detective/supervisor over time in order
to retain previous the data.
15.21. The system should automatically notify a detective or other member of the department at logon when a new case has
been assigned to them for follow-up.
15.22. The system should also notify the original reporting officer when a case has been assigned for follow-up and the identity
of the assigned detective.
15.23. The system should have the ability to notify the original reporting officer and/or detective whenever a supplemental
report has been filed on a case.
15.24. The system should allow authorized users to block access into selected investigations in progress.
15.25. The system should allow authorized users to view cases by all department units and sections.
15.26. The system should have the ability to identify cases without activity for a user-defined period of time.
15.27. At a minimum the system should be capable of utilizing the following agency-defined case statuses:
15.27.1. Active (open): Cases that have been assigned and are under current investigation.
15.27.2. Inactive (open): Cases not assigned due to lack of solvability factors or those that have had all viable leads
exhausted without results.
15.27.3. Unfounded (closed): The incident does not meet the elements of a criminal offense.
15.27.4. Cleared by Arrest (closed): Cases which terminate in the arrest of an individual or charges are filed.
15.27.5. Exceptionally Cleared (closed): Cleared by Exceptional Means. A case is exceptionally cleared if any of the
following can be answered in the affirmative:
15.27.6. Suicide of the Offender
15.27.7. Deathbed Confession
15.27.8. Death of Offender
15.27.9. Extradition Denied
15.27.10. Juvenile Offenses (under certain conditions)
15.28. The system should help detectives track all activity on a case including personal interviews, phone calls, etc. by
providing a means of recording the date, time and description of the activity and by providing a notes field in which the detective can
record information.
15.29. The system should allow any authorized user to view or print out a complete history of detectives assigned to a case and
activities associated with a case.
16. CRIME ANALYSIS
16.1. The system should support continual improvement of MCSO operations and administration by providing a crime analysis
module that provides graphical and statistical tools utilizing the CAD/RMS geofile for analyzing the occurrence of crime and other
reported incidents within the County.
SERIAL 11086-RFP
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
16.2. The system should provide ease of use to all users who are familiar with a Windows environment and will not require
extensive training to conduct standard crime analysis tasks.
16.3. The crime analysis functionality should permit the easy analysis of data for the purposes of identifying and eradicating a
crime series as well as the analysis of criminal offenses that are thought to share the same causal factor (usually a single offender or
group of offenders) given their descriptive, behavior, spatial, or temporal commonality.
16.4. The system should have the ability to present crime distribution statistics in graphical formats: 1) Bar graphs, 2) Pie
charts, 3) Line graphs, 4) Tabular (Matrix) form, 5) Maps.
16.5. The system should allow authorized users to graphically track and analyze crime trends on a map (such as the frequency
of drug arrests near schools or a rash of auto thefts in a particular neighborhood for a user-defined period of time).
16.6. The system should have the ability to map layers utilizing multiple data sets (offenses, calls for service, etc.).
16.7. The system should have the ability to overlay multiple GIS data layers (community pools, parks, known gang activity,
etc.).
16.8. The system should present the user with a pick list of agency-defined map layers to utilize when conducting a mapping
query.
16.9. The system should allow the user to select and utilize multiple map layers simultaneously.
16.10. The system should allow the user to select an area by drawing a polygon around a selected area to initiate a userdefined search.
16.11. When the user rolls their cursor over an icon representing an offense or call for service, a small window should appear
which contains user-defined summary information about the offense or call for service (e.g. date, time, location, offense).
16.12. When the user applies a mouse click to the icon representing an offense of call for service, the system should
immediately link to and display the case report and/or call for service information.
16.13. The system should be able to print maps produced as a result of queries.
16.14. The system should have the ability to conduct crime distribution analysis by such user-defined criteria as:
16.14.1. Offense Type(s)
16.14.2. Sub-Census, Patrol Area, District, Division,
16.14.3. Frequency of occurrence
16.14.4. Type (residential, auto, business, etc.)
16.14.5. Sub-Type i.e., if business what kind (liquor store, Peruvian restaurant, etc.)
16.14.6. Suspect M.O. (including weapons, tools, force used, etc.)
16.14.7. Suspect Descriptors (name, sex, race, age, tattoos, hair color, etc.)
16.14.8. Vehicle Descriptors (make, model, model year range, coupe/sedan, convertible, etc.)
16.14.9. Property type involved (house, boat, car, wallet, bike, printer, cash, etc.)
16.14.10. Weapon used (knife, gun, machete, pencil, lug wrench, fist, foot, etc.)
16.14.11. Current period vs. previous period
16.14.12. Current period vs. historical average
16.14.13. Percentage of total crimes for period by Patrol Area, District, Division
SERIAL 11086-RFP
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
16.14.14. Percentage change from prior periods (trend)
16.15. The system will should have the ability to generate user-definable ad-hoc reports by any combination of the above
criteria.
16.16. All crime and activity reports should be able to be filtered and sorted by user-definable criteria such as:
16.16. Patrol Division, District, Patrol Area, Sub-Census
16.16. other user defined geographic area,
16.16. date and time range of occurrence, and
16.16. crime or activity type.
16.17. The system should allow users to easily access and search the following kinds of user-definable information from crime
and other reports:
16.17.1. Date of the offense, by date range
16.17.2. Time of the offense, by time range
16.17.3. Location where the offense occurred
16.17.4. Type of premises
16.17.5. Description of weapons or tools used
16.17.6. Method and point of entry/exit
16.17.7. Victim data
16.17.8. Suspect data such as but not limited to:
16.17.9. Hair (color, length, style, etc.)
16.17.10. Eyes (color, shape, size, etc.)
16.17.11. Glasses
16.17.12. Facial hair
16.17.13. Face shape
16.17.14. Complexion
16.17.15. Teeth
16.17.16. Height
16.17.17. Build
16.17.18. Speech
16.17.19. Handed (left/right)
16.17.20. Demeanor (nervous, intoxicated, etc.)
16.17.21. Appearance (neat, dirty, etc.)
16.17.22. Scars, marks, and tattoos
16.17.23. Gang status (yes/no)
16.17.24. Gang affiliation (name of gang)
16.17.25. Reporting party data
16.17.26. Text contained in narrative fields
SERIAL 11086-RFP
593
594
595
596
597
598
599
600
601
602
16.17.27. Description of property stolen
16.17.28. Description of any evidence recovered
16.17.29. Vehicle(s) involved/stolen description(s)
16.17.30. Data from all fields in all reports.
16.17.31. The system should be able to create visual representations of:
16.17.32. Crime statistics
16.17.33. Links between persons (victim, suspects)
16.17.34. Links between property and locations
16.17.35. Links between people, places, vehicles, telephone numbers, other object types, and
16.18. The system should have the ability to retrieve cases with similar modus operandi to assist officers and detectives in
solving crimes. For example, similar victim types, crimes occurring in close proximity or within a given date or time range, or in which
similar kinds of property were taken, tools used, method of entry, point of entry, characteristic actions, evidence found, victim
type/location, weapon used, etc.
603
16.19. The system should allow authorized users to set thresholds for certain kinds of activities within a particular geographic
area. If the activity threshold is exceeded the system will notify the crime analyst. For example, if the user sets a threshold for
burglaries of five per month in a specific Patrol Area, the system will send a notice to the user if more than five burglaries are
committed in one month within that Patrol Area.
604
16.20. The system should allow authorized users to set thresholds for offenses that were committed within user-definable
dates, times, and locations based on:
16.20.1. Suspect M.O. (including weapons, tools, force used, method of entry etc.) and/or
16.20.2. Suspect Descriptors (sex, race, age, tattoos, hair color, etc.)
16.21. The system should allow for the integration of industry standard link analysis tools, i.e. i2 Analyst Notebook, CopLink,
CrimeView.
16.22. The system should be capable of being configured to send notification to the crime analyst of selected offenses that
were committed within user-definable dates, times, and location based on:
16.22.1. Suspect M.O. (including weapons, tools, force used, method of entry etc.) and/or
16.22.2. Suspect Descriptors (sex, race, age, tattoos, hair color, etc.)
16.23. The notification should include a summary listing of offenses that were reported during the user-defined time and date
range.
16.24. Authorized users should be able to point and click on any of the cases listed in the summary to open the case report
associated with the offense.
16..25. Authorized users should be able to save the notification parameters and set the notification report to run continuously or
for a user-defined time period.
16..26. For example, authorized users should be able set the system to submit a notification of all user-definable events (e.g.
Robberies, Homicides, Larcenies) that occur between any-user definable time period.
17. UNIFORM CRIME REPORTING (UCR/NIBRS)
605
606
607
608
609
610
611
612
613
614
615
SERIAL 11086-RFP
616
17.1. Uniformed Crime Reporting (UCR) system. Please note that MCSO would like to switch from UCR reporting to NIBRS
based reporting. In order to be able to account for the increase in overall crime MCSO needs to do both UCR and NIBRS based
reporting for a to be determined time period.
617
17.2. The RMS shall provide for the collection of all information as required by the Uniform Crime Reporting (UCR)/NIBRS data
elements. (http://www.fbi.gov/hq/cjisd/ucr.htm)
17.3. The system should be able to update case information that has previously been submitted.
17.4. The system should provide "wizard" type functionality that ensures all reports prepared in the vendor's field based
reporting system are audited for compliance to UCR standards during report preparation by assisting the user in properly completing
all necessary fields in the incident report.
618
619
620
17.5. MCSO's goal is to reduce much of the duplicate data entry that is currently required by this process. MCSO wants to
reduce data entry by means of an interface to the MCSO Pre-Booking System. This interface will allow arrest and booking
information that is captured in the RMS to auto-populate the County Pre-Booking Form. See the Interfaces Section of this document
for further detail.
621
622
623
17.6. The Arrest and Booking Module should:
17.6.1. Provide an arrest processing module for entering and storing information about all persons arrested. .
17.6.2. Provide the ability to capture, maintain, track, and report on numerous user-definable data fields of information on
arrested persons.
17.6.3. Provide database access to all persons arrested as well as provide all criminal, contact, and available court
information on persons processed.
17.7. Arrest information should be linked to the associated event report and CAD event information.
17.8. The MCSO Records Section receives felony warrants/warrant quashes from other County agencies/municipalities and is
responsible for entering them into the States ACJIS database. MCSO misdemeanor warrants are also entered. MCSO is entering
the warrants into a system called Justice Web Interface (JWI). JWI passes the warrants on to ACJIS, and will also need to feed
them (new warrants and quashes) to the new RMS. See the Interfaces Section of this document for further detail.
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
17.8.1. provide a means for tracking the physical location of wanted persons warrants
17.8.2. track recall (quash) information about a warrant
17.8.3. The system should have the ability to maintain, search, and report on numerous categories of agency-definable data
elements including but not limited to:
17.8.4. Warrant Information such as:
17.8.4.1. Issuance and expiration dates
17.8.4.2. Maricopa County Court, Criminal, or Traffic (Court of Issuance)
17.8.4.3. Name of issuing judge
17.8.4.4. Name of defendant
17.8.4.5. Status
17.8.4.6. Date of issuance
17.8.4.7. Date of entry by the Warrant Desk
17.8.4.8. Employee Identification Number
SERIAL 11086-RFP
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
17.8.4.9. Physical Location of the Warrant
17.8.4.10. Misdemeanor
17.8.4.11. Agency Case Number
17.8.4.12. Extradition limitations
17.8.4.13. County and/or State Offense Code
17.8.5. Service Information such as:
17.8.5.1. Date and time of service
17.8.5.2. Name of arresting/serving officer
17.8.5.3. Badge Number
17.8.5.4. EIN
17.8.5.5. Agency
17.8.5.6. Jurisdiction
17.8.5.7. Local/State
17.8.5.8. Location of arrest
17.8.5.9. Location of booking
17.8.5.10. Type of Warrant (court, officer, citizen, outside jurisdiction, etc.)
17.8.6. Person Information such as:
17.8.6.1. Name
17.8.6.2. Driver's License Information i.e., date of issuance and expiration, state, type, restrictions, etc.)
17.8.6.3. Address
17.8.6.4. Social Security Number
17.8.6.5. Date of Birth
17.8.6.6. Race
17.8.6.7. Height
17.8.6.8. Weight
17.8.6.9. Eye color
17.8.6.10. Hair color
17.8.6.11. Sex
17.8.7.
Characteristics such as armed and dangerous, mental case, suicidal, gang affiliation, etc.
17.8.7.1. Person types associated with a warrant are subject (defendant), alias, and complainant.
17.8.7.2. Photograph (hyperlink to the booking photograph)
17.8.7.3. Recall (Quash) information such as:
17.8.7.4. Name of agency requesting recall
17.8.7.5. Name of person requesting recall
17.8.7.6. Telephone number of person requesting recall
17.8.7.7. Person contacted regarding recall
SERIAL 11086-RFP
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
17.8.7.8. Agency notified of the recall
17.8.7.9. Date the agency was advised
17.8.7.10. EIN of processing clerk
17.8.7.11. Date of the recall request
17.8.7.12. Time of the recall request
17.8.7.13. Civil Process information such as:
17.8.7.13.1. Issuance and expiration dates
17.8.7.13.2. General County Court (Traffic or Criminal)
17.8.7.13.3. Juvenile and Domestic Relations
17.8.7.13.4. Other Jurisdiction
17.8.7.13.5. Town
17.8.7.13.6. County
17.8.7.13.7. Ordinances of County, County, or Town type
17.8.7.13.8. Last, First, and Middle name
17.8.7.13.9. Mailing Address
17.8.7.13.10. Residential Address
17.8.7.13.11. Physical descriptors listed under Warrant Detail Information above
17.8.7.13.12. Notation of execution
17.8.7.13.13. Notation of service pursuant to AZ Code
17.8.7.13.14. Notation of certified mailing address
17.8.7.13.15. Name of serving officer
17.8.7.13.16. Badge number
17.8.7.13.17. EIN
17.8.7.13.18. Agency
17.8.7.13.19. Jurisdiction
17.8.7.14. The system should support numerous data entry fields related to judicial activities taken on each civil service.
17.8.7.15. The system should support an agency-defined number of data fields for entering and automatically totaling
cost information regarding court-related costs and other Maricopa County information such as:
17.8.7.15.1. Case Disposition
17.8.7.15.2. Hazardous Materials
17.8.7.15.3. CDL (Commercial Driver's License)
17.8.7.15.4. Sentence
17.8.7.15.5. Fine
17.8.7.15.6. Cost
17.8.7.15.7. and agency-definable codes such as:
17.8.7.15.8. I.D.#
SERIAL 11086-RFP
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
17.8.7.15.9. Incident#
17.8.7.15.10. Arrestee#
17.8.7.15.11. Weapons at Arrest
17.8.7.15.12. Type of Criminal Activity
17.8.7.15.13. Drug Type
17.8.7.15.14. Mult. CL Indic.
17.8.7.15.15. Ethnicity
17.8.7.15.16. Residence
17.8.7.15.17. Disposition if Under 18, and
17.8.7.16. The ability to track all information related to attempts to serve Warrants, Orders. Patrol has requested that this
information be available by location.
17.8.7.17. The ability to track all information related to attempts to serve Warrants, Orders. If there is an active warrant
on someone with a Maricopa County address, a map layer should be made available that presents Icons/symbols at these locations.
If an officer clicks on a warrant location symbol, he or she should see information on the last time service was attempted at the
location. Since warrant service attempts often do not result in an IR or FI being created, this information may require a new
disposition code for "Attempted Warrant Service". If this is the method recommended by the offeror, we would also want the officer's
disposition notes included in the retrieval displays.
17.8.7.18. The ability to import and attach scanned images of Warrants, Orders, and Summons to their related records.
17.8.7.19. The ability to capture, store, audit, and track all information in all data fields contained in each type of County
document above and,
17.8.7.20. The ability to easily produce user-defined pre-formatted and ad-hoc management reports based on all data
fields in the subsystem.
17.8.7.21. The system should provide the ability to send automatic notifications to user-defined persons when a warrant
or civil process order is about to reach its court ordered expiration date.
17.8.7.22. The system should additionally provide the ability for users to define the period of time prior to an expiration
date that they desire to be notified.
17.8.7.23. When a warrant is served the officer should be able to retrieve a Warrant Supplement Sheet and autopopulate it form corresponding fields in the OR.
18. PROPERTY AND EVIDENCE TRACKING
18.1. MCSO is presently using QueTel barcode and property management/tracking systems that are meeting their current
needs. Vendors who can bid their barcode and property management modules as optional separately priced systems are being
asked to do so. MCSO wants to determine if vendors can offer property management systems with enough additional
functionality/value to warrant replacing their current systems. Vendors who can offer their property systems as optional modules,
are being asked to bid converting the legacy data in the QueTel system.
18.2. The proposed system's Property Module should provides users with a central repository for recording, tracking, and
reporting detailed information about all property that comes into the custody of the department. The desired functions of this module
include the following.
SERIAL 11086-RFP
730
18.3. Barcode Tracking: The utilization of barcodes should provide quick, key-less, and error-free retrieval and transfer
capability to the user. The system should be capable of managing property and evidence items, boxes, and storage locations using
barcodes.
731
18.4. Barcode Label Design and Printing: The system should have the capability to automatically generate a unique barcode
for each item entered into the system.
732
733
18.5. The system should provide the ability to automatically define the starting number for item barcodes to be generated.
18.6. The system should also provide the ability for property and evidence management staff to define the starting numbers for
barcodes to be generated.
18.7. The system should provide a barcode label design wizard that allows for the designing of barcode labels with text for
property and evidence items, boxes, and locations. These labels should be capable of being printed - one at a time or in batches directly from the application to any user-defined printer.
734
735
18.8. Importing: The system should have an import utility that allows records to be imported seamlessly from all reports
produced in the RMS and FBR applications
736
737
18.9. The system should also allow for the updating of current records within the application.
18.10. The importing of existing data from the RMS (FBR for example) should also provide field data type validation, duplicated
record validation, and data validation. To ensure data integrity the import utility should enforce the same data entry rules
established by the system's user interface for related functional modules.
738
18.11. Exporting: The application should have an export utility that allows users to create, save, and run any number of export
routines. Any and all data should be able to be exported from the application’s database.
739
740
18.12. The system should have the following minimum search and request capabilities:
18.13. Query-by-Example: The system should provide the ability to search from the main screen by providing an example –
including wildcards -- for a single field or for multiple fields. This functionality should include the use of such tools as date ranges,
pick lists, and free form text.
741
18.14. Query-by-Date: The system should provide the ability to perform searches including, but not limited to, by date ranges
for Date Created, Edit Date, Transfer Date, Check-out Date, Recovering Officer, Incident Report Number, etc.
18.15. Query-by-Location: The system should provide the ability to perform searches by locations. A location may be defined
as a place such as a freezer, a rifle rack, drug lab, shelf, etc. (Individuals can also be defined as locations, such as Captain Smith,
County attorney, or prosecuting attorney).
742
743
744
745
18.16. Query by Identification Number: The system should have the ability to enter, maintain, track, and query other agency
property tracking/identification numbers, or any other system administrator defined tracking numbers.
18.17. The results of all queries performed should be exportable into industry standard common formats including EXCEL,
CSV, etc.
18.18. The system should provide the ability for users to search and request items within the system. For example, this
function should identify the requestor, date requested, reason, and date required.
SERIAL 11086-RFP
746
747
748
749
750
18.19. The system should also provide the ability for evidence technicians to view, sort and print a “pending requests” report –
complete with location barcodes of the requestors -- in order to fulfill incoming requests using portable barcode scanners.
18.20. This “request” functionality should be able to be configured to automatically print in-coming requests based on identified
requestors and/or dates.
18.21. The “request" screen should also have the ability to be left open in a separate window while a user is performing other
functions within the application.
18.22. Standard Reports: The system should provide standard and configurable property and evidence management reports
including but not limited to:
18.23. Inventory Report: Lists all of the items located at each location specified in the report.
751
18.24. Query Report: Reports on the specific selection of records returned as a result of a query or a search. For example the
number of handguns taken into custody for a specified date range, etc.
752
18.25. Audit Report: Shows the audit trail for all items by location and lists every location the item has been, the user who
transferred the item, and the date & time the item was transferred.
753
18.26. Items Out Report: Lists all items checked out of the default locations (set in the workstation settings), typically the main
property room.
754
18.27. Wait List Report: Lists the items that are flagged with a pending action, e.g., all items that have an action or are on a
waiting list.
755
756
757
18.28. User Report: Shows a list of users and all of their permissions.
18.29. Retention Code: Lists all of the retention/disposition codes and the rules that are listed in the system that can be applied
to individual items.
.
18.30. Retention Review: Report based on the retention/disposition code assigned to them, lists all items within a selected date
range that are eligible for review and possible destruction.
758
18.31. The system should be capable of automatically preparing and submitting (via e-mail) user-definable reports including email notifications, to system users. This includes notifications to users informing them that action is required on their part with
respect to property that is in storage (e.g. to obtain a property release or that a stored property is about to reach its maximum
required storage time).
759
18.32. The system should provide the ability to send user-definable notifications to alert (remind) employees that property is
being held in temporary storage locations (evidence drying room, vehicle bay, etc.)
SERIAL 11086-RFP
760
761
18.33. Forms and Letters: The system should provide the ability to automate the generation and timing of Forms and Letters
that the department currently produces manually and electronically.
18.34. Box/Container Tracking: The system should utilize barcodes to track property and evidence items in and out of boxes
and/or containers, as well as, the boxes/containers themselves as they move back and forth between locations. This will allow the
department to know exactly which items are in which boxes/containers -- eliminating the need to retrieve and search through a
series of boxes/containers in order to find an item
762
18.35. Retention/Disposition: Users should to be able to apply the department's retention and disposition schedule to their
property and evidence items. A retention and disposition schedule declares the length of time items should be kept in order to
comply with state and federal regulatory requirements. The retention and disposition schedule ensures that items are maintained as
long as they are needed or as the law requires. The schedule then provides approved directives for the review and disposition of
property and evidence items at appropriate intervals. The system should provide the following retention/disposition functionality:
763
764
765
766
767
768
769
770
771
772
773
774
18.36. The ability for users to create and maintain retention/disposition codes, such as:
18.36.1. Code
18.36.2. Category
18.36.3. Description
18.36.4. Retention period definable in years, months, and days,
18.36.5. Calculation triggers using item’s creation date or another defined date, such as date case was closed
18.36.6. Ability to apply a retention/disposition code to each item logged into the system
18.36.7. System to automatically calculate a review date for an item based on its retention/disposition code
18.36.8. Ability to put a “hold” on an item scheduled for destruction, forfeiture, department use.
18.36.9. Report to list all items eligible for destruction or auction, filtered by retention/disposition code and review date range
18.36.10. Report to list all retention/disposition codes
18.37. Home Location: Each item should to have a clearly defined Home Location (a location where it should be returned after
a user is finished with it.
18.38. Audit Trail/Chain of Custody: The system should have the ability to automatically create, store, and update a complete
and unalterable audit trail for each item logged into the system. For chain of custody purposes it should keeps track of the current
location of an item, as well as every location the item has resided since it was collected. With each transfer -- initiated either with a
barcode scanner or through any other transfer process -- the system should automatically record the date and time when an item
was moved, to whom or where, and by whom. The audit trail should be unalterable in order to preserve the integrity of an item’s
chain of custody.
775
776
18.39. Field-level Auditing: The system should be able to track any and all changes made to an index field. If a change is
made to an index field, the system needs to record and store the date and time the change was made, the name of the user who
made the change, and the old value, as well as, the new value for that field. This field audit information should be unalterable in
order to preserve the integrity of an item’s chain of custody. A report to print out this audit information should also be provided.
SERIAL 11086-RFP
777
18.40. Signature Capture: The system should have the ability to capture a digital signature, on a signature pad connected to
the computer via a serial port, when performing a Check-in/Check-out of an item(s). The captured signature should be stored as
part of the audit trail for an item. The system should also be able to print out a receipt listing the items transferred and the signature
of the person receiving the items through the Check-in/Check-out process.
778
18.41. E-Mail Integration: The system should be capable of integration with the County’s Microsoft exchange server to allow for
distribution of property notices such as; Fail to Return Items Notice, Evidence Disposition Updates, and Destruction Notices.
779
18.42. Electronic Document Management: The system should have the ability to save, request view, deliver and manage
documents that are in electronic format such as scanned images, digital pictures, word processor documents, voice clips such as
911 calls and digital video. Examples of capabilities desired are the abilities to:
780
781
782
783
784
785
18.42.1. Attach, Save, Check-in/Check-out, version control and audit of digital media.
18.42.2. Attach digital photos, voice and video recordings.
18.42.3. Scan, save and attach reports to the record for quick retrieval and viewing
18.42.4. Produce forms for tracking a history of drug weights and currency value throughout the chain of custody
18.42.5. Capture an image of signed paper documents.
18.43. The system should have the ability to link case and property information. For example, to permit one officer who is
retrieving evidence from several different cases to sign-out the property, linking all case property information to the retrieving officer
for property tracking and searching.
786
18.44. Automobiles and other vehicle types that are impounded as evidence must also be managed by MCSO Property.
Vendors are asked to provide detailed information on how their systems process vehicles. How are they processed similar to an
ordinary property item, and how are they process differently.
787
788
19. REGISTRANT AND REGISTRATION TRACKING / LICENSEE AND LICENSEE TRACKING
19.1. MCSO is presently using a vendor supplied Sex Offender Tracking System that is meeting it needs. Vendors who can
offer registrant tracking systems are asked to propose solutions for registering/tracking pawn shops, adult businesses, marijuana
dispensaries, and other needs not associated with sex offenders. MCSO is required by State Statute to license and register Pawn
Shops and track their business activities.
789
790
791
792
793
19.2. MCSO's Pawnshop responsibilities are as follows:
19.2.1. The ability for users to create and maintain retention/disposition codes, such as:
19.2.1.1.
Coordinates all license suspension hearings between pawnshops and other law enforcement agencies.
19.2.1.2.
Enters pawn tickets into the Maricopa County Pawn System (system to be replaced, specifications herein).
19.2.1.3.
Checks pawned items and pawn customers through ACIC/NCIC for stolen property hits and outstanding
warrants.
19.2.1.4.
Assists Property Crimes Detectives with their cases and prepares paperwork to facilitate property being
released to its rightful owners.
19.2.1.5.
Inspects Pawn Shops for stolen property and proper documentation.
794
795
SERIAL 11086-RFP
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
19.2.1.6.
Completes administrative duties related to the recovery of stolen property recovered in Pawnshops, including
the placing of holds on such property.
19.2.1.7.
Flags stolen property in the MCSO Pawn System as having matched a pawned entry.
19.2.1.8.
Mails out license renewal letters annually.
19.2.1.9.
Tracks and responds to situations where Pawn Shops are operating without being licensed.
19.3. Vendors are being asked to respond to the MCSO's Pawn Shop administrative requirements either within this Section or
within their response to a new Pawn Subsystem below. Any response to this Section should include the following functionality:
19.3.1. The system should provide an automated process to monitor the application, approval and past history of permits
and licenses.
19.3.2. The system should provide the ability to create, maintain, and search numerous data elements of agency-definable
information on all permits and licenses issued by the MCSO..
19.3.3. Maintain complaints and inspection memoranda for all licensee locations.
19.3.4. Be able to schedule events tied to any licensee and/or licensee location and obtain event reminders.
19.3.5. Allow notices to be created and sent to other internal (MCSO) and external County agencies.
19.3.6. Automate the creation of documents that must be mailed and generate notices that can be sent vie E-Mail.
19.3.7. Allow all actions (i.e. placing a verbal hold on a piece of property) to be recorded as a memo entry and associated
with the business/licensee address. Allow all actions to be tracked and reported.
19.3.8. Allow receipts for payments to be created and recorded. The system should capture and record all funds received
and transferred to Fiscal Management.
19.3.9. The system should have the ability to maintain user-definable registrant conviction and location information by such
agency definable data as:
19.3.9.1. Conviction, jurisdiction, and case number,
19.3.9.2. Prior addresses,
19.3.9.3. Current address,
19.3.9.4. Type of registrant (sex, narcotics, arson, etc.),
19.3.9.5. Last registration date.
20. PAWN SUB-SYSTEM
20.1. The County wishes to have responding vendors to offer replacement alternatives for it current and ageing Regional Pawn
System. All vendors need to bid interfacing their RMS with the existing system whether or not a replacement system is bid. See the
Interfaces Section of this RFP for further detail.
20.2. MCSO is statutorily responsible for registering and licensing Pawn Shop establishments in the county.
20.3. MCSO is statutorily responsible for tracking and managing all Pawn Shop transactions.
20.4. MCSO has an agreement with other county LE agencies (Municipal Police Depts.) to track second hand store sales too.
These county LE agencies currently manage the registration of second hand stores (MCSO does not).
20.5. The system should include the capability to display and print a list of potential matches of stolen property against Pawn
subsystem records.
SERIAL 11086-RFP
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
20.6. The system should include the capability to display and print a list of potential matches of persons (customers) or items
(property) of interest.
20.7. MCSO seeks a Pawn Shop application that will:
20.7.1. Conform data entry edits and checking to meet data requirements of ACIC/NCIC standards.
20.7.2. Provide the ability to Add, Manage, Track, and Report Pawn Shop registration and licensing activities.
20.7.3. Provide the ability to Add, Manage, Track, and Report Second Hand Store registration.
20.7.4. Ability to differentiate between Pawn Shop Facilities and Second Hand Store Facilities (flag).
20.7.5. Provide security such that only MCSO users can Add/Maintain Pawn Shop facilities.
20.7.6. Allow for other county LE agencies to Add/Maintain Second Hand Shop facilities.
20.7.7. Provide the ability to Add, Manage, Track and Report Pawn Ticket Entries
20.7.8. Provide for Customer and Item checks during Pawn Ticket Entry
20.7.9. An internal comparison of the individual to the Pawnshop System customer filestop information.
20.7.10. An internal comparison of each identifiable item of property (i.e. each item having a serial number and/or owner
applied number) to the Pawnshop System property filestop information.
20.7.11. An external query forwarded to ACIC/NCIC, for each individual meeting the NCIC requirements. (Unless
overridden by the user.)
20.7.12. An external query forwarded to ACIC/NCIC, for each item of property meeting the NCIC requirements.
20.7.13. Provide the ability to Add, Manage, Track and Report Property related to Pawn (Second Hand Store) transaction
activities
20.7.14. Provide the ability to Add, Manage, Track and Report FileStops for both Customers and Property.
20.7.15. FileStops provide the ability to search of persons or items "of interest" within the MCSO (only) Pawn System
database. It's similar to doing a Wants/Warrants check or Stolen Items check at the State level - but only locally.
20.7.16. Customer FileStops provide the ability to register persons of interest to be checked by all subsequent Pawn Ticket
entry transactions.
20.7.17. Property FileStops provide the ability to register items of interest (by serial number, OAN, etc.) to be checked by all
Pawn Ticket and Property entry transactions.
20.7.18. The system should include the ability to prepare and maintain agency-definable Pawned Property Reports including
but not limited to:
20.7.19. A list of pawned property for a given date range sorted by category, then by brand name, with the serial number
and description for each piece listed.
20.7.20. A list of frequent pawners, sorted in descending order by the number of items pawned.
20.7.21. A list of addresses from which a user definable number of pawn activities have originated within a user definable
time period.
20.7.22. The subsystem should have the ability to display both exact and similar items. For example, if the item pawned is
the same brand, make and model but a different color or serial number it should return a notification to the designated user.
20.7.23. Provide reports and ad-hoc query ability to search/filter (Name, Item, Date, Location, ID, etc.) and report on all
aspects of the Pawn Shop system:
SERIAL 11086-RFP
846
847
848
849
850
851
852
853
854
855
856
20.7.24. Pawn Shop and Second Hand Store registration / status
20.7.25. Pawn Ticket entries
20.7.26. Customers with Wants/Warrants (ACIC/NCIC check)
20.7.27. Customers by Name or ID
20.7.28. Property entries
20.7.29. Property found on ACIC/NCIC stolen items database
20.7.30. Customer and Property FileStops
20.7.31. Property (of interest) entries that match FileStops
20.7.32. Customers (of interest) that match Customer FileStops
20.7.33. As with other RMS system activities, provide full user and transactional auditing for all activities within the Pawn
Shop application.
20.7.34. Comment on their willingness to assist a third party (i.e. Leads Online, Business Watch International, USA Software
INC) with implementing software to extract and upload stolen property data from their RMS, and would the County be charged for
this assistance. If charges would be involved, please include them in your proposal.
857
858
859
860
20.7.35. Please describe any additional Pawn Shop functionality that your system provides.
21. PERSONNEL, RECRUITING AND TRAINING ADMINISTRATION
21.1. Pre-Employment
21.1.1. County Personnel handles recruitment notices and does some up front testing to determine what applicants can be
certified eligible. Applicants considered eligible for consideration for an MCSO position are included on an Certification List that is
forwarded to MCSO Pre-Employment. Pre-Employment puts the candidates through multiple screening steps ( i.e. additional
interviews, detailed background examination, polygraph exam, psychological examination, physical agility test, drug screening etc.).
There can be delays during the multiple steps involved in the background investigation (i.e. waiting on information from a previous
employer) and tracking where a candidate is within the process is a firm requirement. This requirement is met currently by
barcoding each applicants file, and barcoding the file in and out of the processing steps using Net File. Vendors are being asked to
detail how an applicant's file can be tracked with their systems by current location and status.
861
21.1.2. All of the information, some data entered and some scanned and attached, is considered confidential and cannot be
available to anyone who is not authorized. Vendors are to detail how this requirement can be met for both keyed data entered and
scanned/attached data.
862
21.1.3. Most of the information collected during the pre-employment process will remain indefinitely, but other types of
information can only be retained for set periods of time. Vendors need to explain how this requirement is met.
21.2. Personnel Services
21.2.1. Personnel Services maintains each MCSO employee's Personnel File which consists of hire paperwork,
promotion/demotion status change paperwork, employee evaluations, signed policy forms, written reprimands, Personnel Actions
Forms, name change, address change, retirement, benefits information, MCSO awards information, commendation letters, etc.
863
864
865
866
21.2.2. Personnel Services also maintains, creates and/or provide the following:
21.2.2.1.
Weekly and monthly statistical reports regarding new hires, terminated employees, vacancies, number of
positions filled, etc.
SERIAL 11086-RFP
867
21.2.2.2.
Vital cards for both current and former employees. The vital cards list the following data types for each
employee:
868
21.2.2.3.
Name, address, phone number, serial number, city and state of birth, parent(s), spouse, children, emergency
contact, chest/flat badge issued, position action history such as position title and dates, salary advancement, assignment,
promotion/demotion/status changes, hire date, suspension, resignation/retirement/dismissal/release date, etc.
869
21.2.3. Personnel Services currently maintains a database of information (PHReD) that shares some of the same
information as the vital card, but is lacking data before year 2000. PHReD also lists employee position number information, date
that the position was created, date that the position number was abolished, military status, ethnicity, gender, academy start and end
dates, employee type such as civilian, detention, and sworn, employment status (classified, temporary, unclassified, appointed),
FLSA status, retirement date (to include DROP Program date), date that the individual is eligible for a uniform allowance (when
allowance is issued), employee hire date, date appointed to current position, initial and job probation beginning, end date and
extension date.
21.2.4. Personnel Services maintains an Access application to track the history of flat and chest badges issued to MCSO
Command, sworn, and detention staff as well as special badges that are issued to cross-certification Law Enforcement agencies.
This system lists the individuals names, serial numbers, SSNs, badge numbers (if any), and dates of issue.
870
871
21.2.5. It is vital that the new personnel management system allow immediate access to MCSO employee information as
well as allow queries and reports to be created that will allow Personnel Services to provide immediate information when requested
by Command Staff, Legal Compliance, media/public records, and MCSO Finance etc., concerning current vacancies, positions
filled, breakdown of personnel by rank/working title/ market range title (i.e. number of detention officers, Deputies, Sgt's/ Lt's/ Capt's
of each classification), a breakdown of numbers by ethnicity/gender required by DPS, FSLA status, classification status, retirement
system, etc. and in regards to recruitment.
872
21.2.6. The Employee Medical Leave/Retirement Section currently maintains paper files. We maintain files both active and
terminated for all employees relating to Medical (FMLA, ADA, Short Term, Long Term, Workers Comp, Medical Leave), Military,
CORP, PSPRS, and CDL holders. Personnel would like to scan future documents of this type and attach them to the employee
number. The documents must be secured so they cannot be accessed by anyone who is not authorized to view them.
873
21.2.7. The capability to restrict access to only those employees with a need to know must also apply to CDL and military
files.
874
875
876
877
21.2.8. Personnel needs the capability to track items such as usage of FMLA protected time, worker compensation claims,
short term and long term disability would be critical.
21.2.9. Currently all records are retained indefinitely and this practice is likely to continue. If however, retention policies were
to change a method of identifying records that qualify to be purged or stored off-line is needed.
21.2.10. Onbase is currently used to scan and store copies of all payroll timesheets and leave slips. Approximately 3300
documents every two weeks, or 85,800 records per year. If vendors are providing a robust scanning and storage option they should
also comment on their ability to convert legacy documents from ONBASE and estimate the cost to do so.
21.2.11. Presently, the Compensation Section incorporates the retention of paper documentation for the following
processes, retention of documentation is placed into the personnel files; including:
SERIAL 11086-RFP
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
21.2.11.1. Records for the entire MCSO employee population of evaluations (3 MO, 6MO, 12 MO
probationary and annual)
21.2.11.2. All documentation of employee merit increases when granted.
21.2.11.3. Retention of special work assignments and releases for the department.
21.2.12. The following Benefits Information must be entered and maintained:
21.2.12.1. Employee Qualified Status Changes
21.2.12.2. Benefit elections
21.2.13. The County is interested in assessing the capabilities of offeror provided personnel and performance management
modules that provide the above capabilities and many of capabilities listed below:
21.2.13.1. The ability to enter, maintain, manage, and analyze key information regarding personnel and the recruiting,
testing and training process by supporting numerous types of agency-definable personnel related data elements.
21.2.13.2. The ability to assist with the day-to-day management of all personnel.
21.2.13.3. A tracking capability that will monitor personnel throughout their career from recruiting to the hiring process
(interview, testing and evaluation to hiring or rejection) to their separation from the department and beyond. Such data will be
retained for a user-defined period as many applicants reapply if rejected initially.
21.2.13.4. The capability to maintain all documentation required throughout the hiring process, from initial contact,
through recruiting, interview, testing and evaluation to hiring or rejection.
21.2.13.5. The ability to maintain a “virtual” personnel file for each employee entered into the system detailing their full
employment history (from initial contact to separation) and subsequent information updates.
21.2.13.6. Employee Exit Interview information.
21.2.13.7. Outside requests for information on applicants and personnel.
21.2.13.8. The ability to provide graphical and statistical tools for analyzing personnel and training data by utilizing data
from any combination of data fields.
21.2.14. The ability to support the easy analysis of data for the purpose of:
21.2.14.1. Quantification (e.g. the number of Hispanic female officers who are on active military duty),
21.2.14.2. Trend analysis (e.g. how many recruit officers had their employment terminated during their third month of
academy training).
21.2.14.3. The ability to provide a free-text notes section for each employee history file.
21.2.15. The ability to maintain an unlimited number of agency-definable personnel data elements such as:
21.2.15.1. Suffix (Sr., Jr., I,II,III)
21.2.15.2. Last Name
21.2.15.3. First Name
21.2.15.4. Middle Name
21.2.15.5. Badge and/or Employee Identification Number (EIN)
21.2.15.6. Sworn or Civilian
21.2.15.7. Job Title
21.2.15.8. Pay Scale, Grade/Step
SERIAL 11086-RFP
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
21.2.15.9. Class
21.2.15.10. EEO Status
21.2.15.11. Race
21.2.15.12. Sex
21.2.15.13. Street Address
21.2.15.14. Apartment Number
21.2.15.15. County
21.2.15.16. State
21.2.15.17. Zip Code
21.2.15.18. Home Telephone
21.2.15.19. Work Telephone
21.2.15.20. Personal Pager Number
21.2.15.21. Personal Mobile Telephone Number
21.2.15.22. Personal E-Mail Address
21.2.15.23. County Telephone Number
21.2.15.24. County Pager Number
21.2.15.25. County E-Mail Address
21.2.15.26. Position Appointed To
21.2.15.27. SSN
21.2.15.28. Languages Spoken
21.2.15.29. Marital Status
21.2.15.30. Religion
21.2.15.31. Blood Type
21.2.15.32. Duty Status
21.2.15.33. Date of Appointment
21.2.15.34. Date of Resignation
21.2.15.35. Date Terminated
21.2.15.36. Date Retired
21.2.15.37. Date of Death
21.2.15.38. Promotion Date(s)
21.2.15.39. Rank Promoted To
21.2.15.40. Current Rank
21.2.15.41. Work Assignments
21.2.15.42. Date of Transfers
21.2.15.43. Accession Number
21.2.15.44. Academy Session Number
SERIAL 11086-RFP
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
21.2.15.45.
21.2.15.46.
21.2.15.47.
21.2.15.48.
21.2.15.49.
21.2.15.50.
21.2.15.51.
21.2.15.52.
21.2.15.53.
21.2.15.54.
21.2.15.55.
21.2.15.56.
21.2.15.57.
21.2.15.58.
21.2.15.59.
21.2.15.60.
21.2.15.61.
21.2.15.62.
21.2.15.63.
21.2.15.64.
21.2.15.65.
21.2.15.66.
21.2.15.67.
21.2.15.68.
21.2.15.69.
21.2.15.70.
21.2.15.71.
21.2.15.72.
21.2.15.73.
21.2.15.74.
21.2.15.75.
21.2.15.76.
21.2.15.77.
21.2.15.78.
21.2.15.79.
21.2.15.80.
Academy Fiscal Year
Academy Start Date
Academy End Date
Total Days In Academy
Number that Started the Academy
Number that Completed the Academy
Graduating Percentage (calculated field)
Sworn Class Title
Animal Control Class Title
Civilian Class Title
Class Number
Budgeted Positions (Sworn and Civilian)
Authorized Positions (Sworn and Civilian)
Filled Positions (Sworn and Civilian)
Vacant Positions (Sworn and Civilian)
Grant Positions (Sworn and Civilian)
Positions Overfilled
Assignment
District
Patrol Area
Special Skills (Rifle, CDL, languages spoken, etc.)
Military Reserve
Military Branch
Military Status
Military ETS
Military Phone
Military POC
Military Unit
Military Address
Deployed
Deployed Location
Deployed Date
Deployed Return Date
Activated Date
Photo
Photo Date
SERIAL 11086-RFP
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
21.2.15.81. Equipment information (multiple fields)
21.2.16. The capability of assigning agency-definable employee classification designators based on Position Title including
but not limited to:
21.2.16.1. Officials and Administrative
21.2.16.2. Professionals
21.2.16.3. Technical
21.2.16.4. Protective Services
21.2.16.5. Para-Professional
21.2.16.6. Office/Clerical
21.2.16.7. The capability to track actual and projected departmental vacancies based on:
21.2.16.8. Retirement, Resignation, Termination
21.2.16.9. Leave of Absence
21.2.16.10. Injuries
21.2.16.11. The system should calculate departmental vacancies based on:
21.2.16.12. Retirement, Resignation, Termination
21.2.16.13. Leave of Absence
21.2.16.14. Injuries
21.2.17. The system should be capable of supporting an on-line change of address form for employees.
22. TRAINING RECORDS
22.1. MCSO is interested in reviewing the capabilities of an RMS module which provides for automated maintenance and
reporting of training related files and materials as part of a comprehensive Personnel, Training, and Recruiting Administration subsystem.
22.2. The County is interested in a system which possesses capabilities such as:
22.2.1. The capability to be flexible and adapt to the County's needs, including one-time training, special training, recurring
training, firearms proficiency, etc.
22.2.2. An automated weekly, monthly and annual training calendar to prepare the training staff and participants for
upcoming training events.
22.2.3. The ability to provide prompts when a scheduled training dates are nearing, missed, or are rescheduled (utilizing a
notification in the RMS and or the County's e-mail system) that is agency configurable
22.3. The ability to maintain agency-definable training data including but not limited to:
22.3.1. Schools Attended
22.3.2. Certificates of Training
22.3.3. Courses and Seminars Attended (internal and external)
22.3.4. Dates
22.3.5. Course Name/Title
22.3.6. Course Number
SERIAL 11086-RFP
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
22.3.7. Hours Completed
22.3.8. Instructor/School
22.3.9. Special Skills
22.3.10. Firearms Qualification History
22.3.11. Issued Weapon Type
22.3.12. Off-Duty Weapon Type
22.3.13. Scores
22.3.14. Dates
22.3.15. Serial Number of Agency Issued Weapon
22.3.16. Serial Number of Personally Owned Weapon
22.3.17. State Mandated Training Completion and Dates
22.3.18. Ability to Track Course Information by All Fields
22.3.19. Ability to Set Up and Maintain a Schedule for Different Types of Training
22.3.20. Ability to Obtain Information on Personnel in Need of Training by:
22.3.21. Person
22.3.22. Training Type
22.3.23. Date
22.3.24. Special Skills (CDU, Rifle, CDL, etc.)
23. FIELD TRAINING
23.1. The system should include integrated Field Training functionality which possess automated tools designed to enhance the
employee training and evaluation process by providing the ability to document training throughout a shift and save the information
electronically in a standardized evaluation format. The intent is to improve efficiency, as the evaluation is written during the shift
while the training is taking place, rather than at the end of the shift.
1028
23.2. The system should be able to produce a consolidated virtual Field Training "folder" that contains agency-definable
employee information such as:
23.2.1. summary and detailed information concerning all hours worked (imported from CAD)
23.2.2. summary and detailed information concerning all employee activities (calls for service, field interviews, officer
initiated activities, court appearances, etc. imported from the CAD)
23.2.3. copies of all case and other reports prepared, and
23.2.4. can be produced for any employee by date range.
23.3. The folder should provide the ability to view a summary page of employee field training information that allows users to
drill down (via hyperlinks) to specific activity details and view such underlying information as case reports, unit histories, and call for
service details.
1029
1030
1031
1032
1033
1034
1035
23.4. The system should have the ability to consolidate and import all information contained in the folder to a removable media
format (such as a CD) for easy viewing of all information from the summary page.
23.5. The system should provide automated daily and weekly observation, comparison and other agency-definable reports to
assist in evaluating recruitment, hiring, and training practices.
SERIAL 11086-RFP
1036
1037
1038
1039
23.6. The system should provide tools that allow the County to create, utilize, and manage electronic "Observation" reports
within the RMS that can be utilized by authorized end-users in the desktop and mobile environment.
23.7. The reports should include radio buttons, drop-down menus, narrative fields, and data fields for entering numerical
values.
23.8. When the report is completed and saved, data fields containing numerical values should automatically calculate any
necessary sums and averages.
23.9. All "Observation" report data should be available for user-definable searching and summary report preparation. It should
be possible, for example, to prepare a summary report illustrating the number of officers, by Field Training Officer, who have
achieved a user-definable average score range in a specific user-defined competence area.
1040
1041
1042
23.9.1. The system will be fully accessible to workstation and MDC users.
24. OFFICER ACTIVITY TRACKING
24.1. Officer Activity Reports capture summary information that is typically created as a result of routine activity by Officers and
other County personnel. Statistics from calls for service, event responses, reports, field interviews, and officer initiated activities
imported from the CAD will provide summary information for management to review and analyze.
1043
24.2. The County is interested in evaluated a sub-system which can provide the ability to capture, maintain, and report on
officer activity, including but not limited to:
24.2.1. Reports filed and type,
24.2.2. Arrest types:
24.2.3. Felony
24.2.4. Misdemeanor
24.2.5. Citation
24.2.6. Traffic tickets written
24.2.7. Warning tickets written
24.2.8. Parking tickets written
24.2.9. Field interviews conducted
24.2.10. CAD Calls For Service, assigned
24.2.11. CAD Calls For Service, assisted
24.2.12. CAD Calls For Service, self initiated
24.2.13. False Alarms
24.2.14. Court time
24.2.15. Training time
24.2.16. Track actual participation time (by person) including but not limited to such activities as:
24.2.17. Foot Patrol
24.2.18. Special event time
24.2.19. Community meeting
24.2.20. Other down time
24.3. The system should provide the ability to summarize officer activity by, but not limited to, the following criteria:
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
SERIAL 11086-RFP
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
24.3.1. Individual
24.3.2. Squad
24.3.3. Division
24.3.4. Bureau
24.3.5. Date and Time range
24.3.6. Shift
24.3.7. By Officer activity and date range
24.4. The system should be able to generate statistical and graphical reports on any captured data and,
24.5. Prepare agency and user-definable activity and management reports.
24.6. The system should provide the ability to view a summary page of user-definable employee/squad statistics from which
users can drill down (via hyperlinks or other suitable method) to specific statistic details and view underlying information regarding
the statistics concerning number and types of arrests and citations, etc. by user-definable time and date ranges.
1075
1076
25. PERFORMANCE EVALUATION
25.1. The County is interested in reviewing the capabilities of an RMS module which can maintain, track, and report employee
Performance Evaluation information via an integrated Performance Evaluation Sub-System.
25.2. The system should track when performance evaluations are due, at each user-definable level of the organization, and be
capable of providing an e-mail notification to agency definable employees when evaluations are due.
26. OFF-DUTY EMPLOYMENT
26.1. The system should use basic personnel information and supplement it with agency-definable information in order to track
the off-duty employment of uniform and plain clothes officers including but not limited to:
26.1.1. An automatically generated permit number
26.1.2. Approval Date
26.1.3. Name of the Approving Commander or supervisor.
26.1.4. The system will also be capable of maintaining employer information such as:
26.1.5. Approved Employer Name
26.1.6. Approved Employer Location
26.1.7. Contact Person's Name
26.1.8. Contact Person's Phone Number
26.1.9. Approval Date
26.1.10. Is the officer working uniform or plain clothes
26.2. Work address and work schedule. The County would like to make this information available when a call comes in at or
near a location where an officer may be working. Vendor to detail how this will be met.
27. INVENTORY AND EQUIPMENT MANAGEMENT
27.1. The system should provide for the administration and maintenance of property issued to employees. Issued equipment
includes protective clothing, weapons, tools, keys, etc. Where appropriate, reports of loss or damage to issued equipment should be
linked to any associated case report.
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
SERIAL 11086-RFP
1093
27.2. The system should provide the ability to capture and maintain all County issued equipment data including, but not limited
to:
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
27.2.1. Item number
27.2.2. Description
27.2.3. Make
27.2.4. Model
27.2.5. Type
27.2.6. Cost
27.2.7. Manufacturer
27.2.8. Manufacture Date
27.2.9. Warranty period
27.2.10. Warranty start/end dates
27.2.11. Size/caliber of weapon issued
27.2.12. Serial number
27.2.13. Accessories (case, charger, battery charger, car charger, photo scale, grease pencil etc.)
27.2.14. Specialty Issue (CNT, SWAT, Mobile Field Force, Honor Guard etc.)
27.2.15. Asset/property tag number
27.2.16. Radio ID number
27.2.17. Date purchased
27.2.18. Date issued
27.2.19. Condition issued
27.2.20. Issued by
27.2.21. Date returned
27.2.22. Condition returned
27.2.23. Received by
27.2.24. Maintenance
27.2.25. Equipment type (weapons, etc.)
27.2.26. Repair dates and comments
27.2.27. Status code (lost, missing, etc.) include purchased, awarded, donated to ______, destroyed, auction p/u
date_______, Hold IA, Hold Case #_________
27.2.28. Status code (lost, missing, etc.)
27.2.29. Replacement dates
27.2.30. Keys and lockers, locker numbers and combinations
27.2.31. Other
27.3. The system should provide the ability to:
SERIAL 11086-RFP
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
27.3.1. Display and print summary of equipment by Officer in a checklist form with blocks to check off equipment as turned
in (resignation/retirement
27.3.2. List all equipment due for inspection and/or maintenance for any given time period by individual, unit or district
27.3.3. Print equipment issued and in-stock inventory listings
27.4. List equipment scheduled for inspection by:
27.4.1. Type of equipment
27.4.2. District (North or South)
27.4.3. Employee
27.4.4. Date range
27.5. The system should provide users the ability to search for and print equipment lists by all available data fields such as item
number, serial number, location, equipment type, employee, district, etc. w/multiple variables (date issued and equipment type;
make and model etc.)
27.6. The system should have the ability to retrieve and print equipment records by all available data fields such as serial
number, equipment type, location, employee assigned to, location, etc.
27.7. The system should have the ability to maintain, track, calculate and report on replacement lifecycles for specific issued
equipment including but not limited to such criteria as:
27.8. Date range, individual, District station, etc.
27.9. The system should support barcode entry, tracking and maintenance of inventoried items.
27.1. Barcode Support should include each item and each employee by employee number
27.11. The system should allow users to scan item's barcode and enter the quantity, after which the system will assign the item
to the employee, who can then print a receipt. or electronic copy for electronic signature to email to individual to sign and return for
file copy.
27.12. In the above instance, the system should also provide the ability to prepare and forward an electronic receipt via e-mail,
for the assigned employee to electronically acknowledge as a "file copy".
28. NEIGHBORHOOD WATCH
28.1. The system should have the ability to maintain a list of community members involved in neighborhood watch or other
community policing initiatives. At a minimum this list should include the following agency-definable data elements:
28.1.1. Community group name
28.1.2. Group leader
28.1.3. Street/Area
28.1.4. Contact name
28.1.5. Contact address
28.1.6. Contact home phone number
28.1.7. Contact Business phone number
28.1.8. Community group members' names
28.1.9. Community group members' phone numbers
28.1.10. Community group members' e-mail addresses
SERIAL 11086-RFP
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
28.2. The system should have the ability to print form letters and send email mailings to some or all of the persons listed in a
neighborhood watch list or other community initiative.
28.3. The Community Group and Neighborhood Watch data should be available for analysis by the system and link to the
system's mapping system and available as a user-definable mapped data layer.
29. PRINCIPAL REPORTS
29.1. GENERAL REQUIREMENTS
29.1.1. The vendor shall permit the system administrator and other authorized user(s) to determine the source (tables, etc.)
that form the basis of all available reports delivered by the vendor.
29.1.2. The system should utilize a built-in report writer for standard and/or ad-hoc report creation that can be used by a
non-technical professional to create, use, save, and print searches and reports.
29.1.3. For example, the system should provide the capability to generate a summary of warning tickets issued by vehicle
state registration.
29.1.4. The system data files should be compatible with 3rd party reporting tools such as Crystal Reports.
29.1.5. The offeror should list and describe all reports offered as part of their system. Please provide samples.
29.1.6. The system should be capable of posting to a web page, all reports (statistical, graphical, etc.) including selected
MCSO DR reports and the results of selected RMS queries
29.2. SYSTEM ADMINISTRATOR REPORTS
29.2.1. A logon Report which shows the time and location of each user logging on or off of the RMS system for a given date.
29.2.2. A workstation Logon Report which shows all users logging on or off of the system from a given workstation for a
given date.
29.2.3. An audit trail of all changes made to an incident report including the date, time, workstation, and associated
employee.
29.2.4. A report which lists all persons who have printed any or all forms associated with a given case.
29.2.5. A report which shows the system administrator or authorized user all master index entries added for a user specified
date and time range.
29.3. CRIME AND EVENT REPORTS
29.3.1. A temporally configurable (e.g. 24 hour, 8 hour, etc.) automated report, which provides a summary of reported
offenses during the previous calendar day(s) for a user-defined area. This report will include the:
29.3.1.1. Offense classification
29.3.1.2. Date
29.3.1.3. Time
29.3.1.4. Location of the offense
29.3.1.5. Complainant's Name
29.3.1.6. Reporting Officer
29.3.1.7. Summary of Offense
29.3.1.8. Suspect Description
29.3.1.9. Vehicle Description
SERIAL 11086-RFP
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
29.3.1.10. Case Status
29.3.1.11. Name, Age, Race, Sex, Residential Address of Arrestee (if closed by arrest)
29.3.1.12. Quarter Section Map
29.3.1.13. Patrol District, and
29.3.1.14. Patrol Area for each case.
29.3.2. The report should be capable of being prepared by numerous data elements including but not limited to:
29.3.2.1. Patrol District
29.3.2.2. Patrol Area, and
29.3.2.3. any user defined date and time range.
29.3.3. The report should list offenses beginning with the most serious offense or in any other user-definable order.
29.3.4. Non-criminal incidents will follow offenses.
29.3.5. The system should include a report listing offenses and calls for service by address and/or disposition by Patrol
district and Patrol area.
29.3..6. The system should include a Summary of Offenses Report which provides a summary of each offense including the
date, time, type, location of occurrence, and status for each offense for a user defined date and time range.
29.4. MANAGEMENT REPORTS
29.4.1. The County desires the management reporting capabilities:
29.4.2. Patrol: Capable of preparing user configurable Monthly and Annual reports by Patrol District, Area, and Quarter
Section Map on various user-definable statistics such as arrests, citations, case reports, crash reports, and miscellaneous
administrative activities.
29.4.3. Traffic Summary: Capable of preparing user-definable Monthly and Annual summary reports of traffic citations, crash
reports, fatalities, etc.
29.4.4. Arrests: The system should be capable of preparing user definable Monthly and Annual reports of total arrests and
by category: felony, misdemeanor, County Code, etc.
29.4.5. Investigations (CIS): Capable of preparing the following kinds of user-definable reports: Monthly case status report,
offense by UCR code, case clearance, warrants, arrests, employee, etc.
29.4.6. Juvenile: Capable of preparing user-definable reports such as monthly cases by classification, referrals, arrests,
domestic violence cases, etc.
29.4.7. Vice: Capable of preparing user-definable Monthly and Annual reports summarizing drug seizures by type. The
system should also track asset forfeitures by federal and state, search warrants, etc.
29.4.8. Demographic Profiling: Capable of providing user-definable statistical data on officer-initiated contacts, etc.
29.4.9. CAD Event Reporting: Management reports concerning agency activities will be required after the CAD data has
been transferred to the RMS. Therefore, the RMS should be capable of providing a the full range of management reporting detailed
in CAD Functional Requirements, Query and Reporting Section.
29.4.10. The system should include agency-definable statistical reports of complaints (calls for service that do not result in a
case report) and crimes including but not limited to such criteria as:
29.4.10.1. User-defined address
SERIAL 11086-RFP
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
29.4.10.2. District
29.4.10.3. Patrol Area
29.4.10.4. Any user-defined geographical area,
29.4.10.5. Day of week
29.4.10.6. Time range
29.4.10.7. Date range, or
29.4.10.8. Any combination of the above.
29.4.11. The "complaints" report will require data from the CAD.
29.4.12. The user should be able to define the radius or proximity inside which all addresses will be considered a single
address when searching for "hot spots".
29.4.13. Case Management Reporting: The ability to generate Case Assignment and Monthly Clearance Reports (offense
description, current month, total cleared, percent cleared) by officer/detective and/or squad/detective unit.
29.4.14. The Clearance report should be capable of being prepared by any user-defined period (month or number of
months, year) for any assigned officer/detective and/or squad/detective unit, and/or any Patrol District, or Patrol Area
29.4.15. The ability to generate a Case List Summary report by user-definable criteria including but not limited to:
29.4.15.1. Status
29.4.15.2. Report Date(s)
29.4.15.3. Assigned Officer/Detective
29.4.15.4. Squad/Detective Unit
29.4.15.5. Patrol Division
29.4.15.6. Patrol District
29.4.15.7. Patrol Area
30. OTHER REQUESTED FUNCTIONALITY
30.1. TRESPASS CONTROL
30.1.1. Persons found in violation of ARS 13-1502 are usually given a warning for a first violation. If the individual refuses to
leave when instructed to do so, he or she will be arrested. Patrol is requesting the capability to determine if a violator has previous
violations at or nearby a particular address/business. Business locations can report that they have advised a disruptive person or
someone who has committed a crime that they have trespassed, must leave immediately and never return. The documented
warning allows the previously warned person to be arrested if they do return. The Sheriff's Office is asking for a way to document a
trespass situation at a given location so the information is available if and when there is a repeat occurrence. The information must
be stored so that it is available by location and/or subject name. The Sheriff's Office does not want to create a DR unless an arrest
occurs. Vendors are being asked to explain in detail how they can provide this functionality.
30.2. TRESPASS CONTROL
SERIAL 11086-RFP
1229
1230
30.2.1. Gang members and their associates/affiliates now use monikers, or nicknames, so dependably that these
pseudonyms can provide a reliable source of investigative information. Gang members and their affiliates use monikers on the
streets as graffiti; tattoo them on their bodies; and write them on such personal items as school yearbooks, clothing and jewelry.
Care must be taken not to label a suspect as being a gang member unless at least two of the established gang member criteria are
met. Once two of the criteria are met, the individual is entered into Gang Net. They cannot be labeled a Gang Member in the RMS
simply because they use or display a gang moniker, or have an association with those who do. Moniker use or involvement, and/or
the fact that they satisfy one of the gang member criteria only make them a person of interest to law enforcement. The MCSO is
requesting the ability to inquire on a moniker and retrieve all persons having previously used the moniker, or have any
affiliations/associations to those using the moniker, or any event in which the moniker was displayed (i.e. graffiti, tattoos etc.). The
offeror is being asked to propose a method of providing this requested functionality.
30.2.2. Citizens can report graffiti by using a County website, a County Hotline, or by calling Communications. As a result of
a report/complaint a civilian technician responds and removes or paints over the graffiti. The technician completes a "MCSO Graffiti
Report" that contains a report number, date, time, location, moniker, suspect's name, suspect's DOB (if known), and suspect's
address and phone number (if known). Fields for a brief narrative and signatures are also provided. The form will be expanded to
capture the suspect's "Crew" association (if known). MCSO wants to capture this information and associate the suspect and/or
moniker information as described above.. A Crew inquiry should be treated similar to a Moniker inquiry and return all events, and or
associations. Although the graffiti technician is not dispatched, the graffiti occurrence should be treated similar to an event at the
location specified, and photos of the graffiti should be able to be attached. The offeror is being asked to propose a method of
providing this requested functionality.
1231
1232
30.3. Forms Control Library
Vendor Explanation
30.3.1. In several sections of this requirements document MCSO has asked to populate data from a forms template or input
screen to one or more additional forms templates. The intent of this section is to provide additional clarification on exactly what is
being requested. The County is creating one or more committees to design, approve, and manage all official forms documents.
Once forms are approved, their templates would be housed in a Forms Library that would be centrally controlled. Most forms
capture information that is redundant to information already captured to properly document an event. A DUI related arrest for
example requires the suspect's information to be captured on several different forms. The Use of Force form is another example of
having to capture numerous data fields that have already been input to the DR.. Data entry fields contained in any form template
approved and housed in the Forms Library would have commonly redundant data entry fields mapped one to the other and to
information entered into OR and FI entry screens.
1233
30.3.2. MCSO is asking for the capability to retrieve a forms template from the Forms Library, and ask that information
already entered into a report or other form be used to auto-populate the form just requested. This process will not value all fields in
the form being auto-populated, nor will the results of the transfer always be correct. Once a form template is auto-populated the
user must be able to enter missing information and edit the transferred data. When the user considers the auto-populated a form
complete and accurate, it can be stored and associated with a DR, printed, and/or routed to a destination point. The form type will
dictate how the form is further processed. In providing this explanation MCSO is not trying to specify how this functionality must be
provided. The intent is to simply specify what needs to be provided to reduce a serious problem of having to enter the same
information into multiple forms.
SERIAL 11086-RFP
1234
1235
1236
30.3.3. Vendors are also being asked to offer their solutions to this duplicate data entry problem. If an approach similar to
the one above is proposed, please specify in detail how MCSO would go about adding new forms templates to the Library and
mapping their common fields for auto-population. The intent is to be able to fully manage the process without requiring vendor
support.
30.4. CASH ACCOUNT MANAGEMENT
30.4.1. The MCSO maintains cash accounts within multiple specialty units to make cash immediately available for drug
buys, to pay confidential informants, and transact other authorized purchases. MCSO needs to acquire a Cash Management
System with the following capabilities and features:
1237
30.4.1.1. The system needs a robust security front end that limits the use of the system to only those individuals
authorized to have access and make entries. Two levels of access need to be provided. Comptroller Level would have access to all
cash accounts maintained by the MCSO. The Comptroller would have the capability to run audit reports on all accounts and would
receive monthly reconciliation reports for each cash account. Only the Comptroller can enter a reconciliation entry into the system
adjusting the system balance to the cash on hand. The Comptroller would be able to check the current status of all accounts at any
time. A Cash Account Manager Level would be assigned to select individuals within each detail that manages a cash account. Only
the designated Cash Account Managers can enter deposit, withdrawal, and transfer transactions for their detail's cash account. They
are not provided access to the accounts in other details. Access should require a user ID, a robust password (FBI CJIS compliant)
and a challenge response if equipment outside the normal work area is being used.
1238
30.4.1.2. All deposit entries must identify the person transacting the deposit, the source of the funds, the amount being
deposited, data and time, and the reason for the deposit. The reason can default to "Fund Replenishment" if the deposit is not
earmarked for a specific purpose. A return of money previously issued to an officer that is now returning all or a portion of the money
must also identify the officer returning the money, the reason for the return, and the original event for which the money was
withdrawn.
30.4.1.3. All withdrawals must identify the person transacting the withdrawal, the amount being withdrawn, the person
receiving the cash, the date and time, and the reason for the withdrawal. MCSO has developed codes for the more common
reasons for withdrawal, but a freeform text field must be available for situations that are not code identified.
1239
1240
30.4.1.4. A transfer from one cash account to another is a rare event, but the capability to do so is being requested. The
transaction would be similar to a withdrawal except that a flag would be set in the receiving account system and the Cash Account
comptroller would be notified if a deposit equal to the withdrawal is not made into the receiving account with 24 hours.
1241
30.4.1.5. At the end of each month the Cash Account Managers must reconcile the remaining balances shown by the
system with the actual cash on hand. If there is an imbalance, the Cash Account Comptroller is notified and is provided a reason for
the imbalance if one is known. The Cash Account Comptroller with debit or credit the system to clear the imbalance. The
reconciliation will appear on the monthly report sent to the MCSO Finance. If the cash on hand is equal to the balance reported by
the system, the Cash Account Managers need to make a memo entry that is date and time stamped by the system that reports that
a reconciliation was completed and the amounts are in balance.
1242
30.4.1.6. If a unit's cash account involves multiple types of cash funds (Under Cover and RICO for example) separate
cash handing and reporting is required for each type.
30.4.1.7. The capability to scan in cash receipts and other supporting expenditure documents that can be liked back to
their originating withdrawal transactions is needed.
1243
SERIAL 11086-RFP
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
30.4.1.8. The department will work with the vendor selected to build valid code tables and design report formats and
screen displays. Vendors are asked to include samples of their standard report formats and screen displays.
30.4. Electronic Ticketing
30.4.1. Vendors who have integrated mobile ticketing solutions into their CAD/RMS are asked to bid functionality to enable
officers to issue traffic citations from their mobile computers in patrol vehicles.
30.4.2. The system offered must be able to import information needed to complete an Arizona approved citation from data
returned from ACIC/NCIC, motor vehicle queries and from scanning the offender's drivers license.
30.4.3. The system offered must be able to determine the appropriate court, statute number and fine from the violation code
and location of the offense.
30.4.4. Print solutions for printing the current multi-part citation and a single offender copy using thermal paper should be
provided and priced separately. Include recommended printers of both type and pricing.
30.4.5. The capability to issue multiple citations by pulling data from the initial citation created is needed.
30.4.6. The citations need to be edited while they are being created and no citation can be finalized that contains errors or
omissions.
30.4.7. The County has a requirement to attempt to obtain the offender's signature on a criminal cite and release citation.
Vendors are asked to recommend and include pricing for wireless signature capture devices.
30.4.8. Once a citation is completed the citation data must be electronically transmitted to the RMS and Court systems.
30.4.9. Vendors are being ask to price software and hardware components separately and to provide volume purchase
discount thresholds for each
30.5. Enterprise Document Imaging
30.5.1. In several of the requirement sections of this request the need to image documents and index them to case
numbers, names, and other fields has been listed as a requirement. Because much of the information being collected is criminal
history by definition the system proposed must have security requirement equal to those applied to criminal histories in the RMS. By
this we mean that if a scanned document is indexed to one or more other RMS identifiers, it must take on the security afforded the
identifier with the highest security provisions. Document stored by the Civil Division would be in separate account from documents
stored by GIB and not shared unless authorization is provided by the account owner.
30.5.2. Documents can be entered from any authorized scanner on the network.
30.5.3. The system proposed must provide secure central storage, versioning, metadata, and security, as well as advanced
indexing and retrieval capabilities.
30.5.4. Metadata must capture the documents type, date/time the document was stored, by whom, and the capability to
describe why the document is germane to the case, person, event or other field(s) it is being indexed to.
30.5.5. County would like to see the document imaging solution tightly integrated with the CAD/RMS so that documents can
be accessed from the document management system, updated if not classed as evidence, and returned to the image repository
without leaving the CAD/RMS. It should be transparent to the user that a second system is involved.
30.5.6. Should support common integration standards such as ODMA, SOAP, LDAP, WebDAV.
30.5.7. Users should be able to retrieve documents by their index topology and by unique document identifiers when
available, and by partial search terms expected in the metadata.
SERIAL 11086-RFP
1263
1264
1265
1266
1267
1268
1269
1270
1271
30.5.8. The proposed system should include a rights manager module that allows an administrator to give access to
documents based upon type to only a certain people or details.
30.5.9. Documents identified as evidence must be marked at the time of creation to preclude alteration or unintended use.
Vendors are to explain in detail how this is to be accomplished.
30.5.10. Some documents in Civil Process for example need to be sent to someone else for review and approval within an
established period of time. The County would like to see a rules base workflow component that can route documents based upon
the rule set established.
30.5.11. The system should provide an audit trail of all changes made to a document (i.e. Date, time, changes made, and
by whom).
30.5.12. The system proposed should allow versioning, and allow users to retrieve previous versions.
30.5.13. The system must provide the capability for its designated owner to seal a document by signature or other process.
Once sealed a document can no longer be modified.
31. CIVIL PROCESS DIVISION
31.1. The Civil Division performs several distinct functions:
31.1.1. The MCSO Civil Process Division serves all Superior Court civil processes including: civil summons/subpoenas,
Orders of Protection, writs of execution, garnishment, restitution, replevin, and attachments, as well as various other in-state and
out-of-state court documents and process. Levy on real and personal property to dispose of by Sheriff’s auction or other means as
ordered by the court. Complete affidavits of service on all process showing the type of service made, actions taken, and if the
documents were not served an accurate report of the actions taken.
1272
1273
31.2. Civil Process:
31.2.1. Serves all Superior Court civil process including: civil summons subpoenas, Orders of Protection, writs of execution,
garnishment, restitution, replevin, and attachments, as well as various other In and out of court documents and processes. Levy on
real and personal property to dispose of by Sheriff's auction or other means as ordered by the court. Complete affidavits of service
on all processes showing the type of service made, actions taken, and if documents were not served an accurate report on the
actions taken.
1274
31.2.2. To automate the above functions the Civil Process Division requires a system that will capture the following
information when entering documents and deposit information, and include the following functionality:
31.2.2.1. Case numbers
31.2.2.2. State where paperwork originates
31.2.2.3. Designation if paperwork is a warrant
31.2.2.4. Identification type of attorney Proper such as driver’s license, bar number, social security
31.2.2.5. Driver license number, bar number or social security number
31.2.2.6. State where identification type originates
31.2.2.7. Plaintiff’s first, middle, & last name
31.2.2.8. Plaintiff’s company name
31.2.2.9. Attorney’s firm or Pro per’s name
31.2.2.10. 3 additional lines for attorney’s/Pro per’s address
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
SERIAL 11086-RFP
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
31.2.2.11. Phone number for attorney/Pro per
31.2.2.12. Code for common attorney’s/plaintiff’s name & addresses
31.2.2.13. Defendant’s first, middle & last name
31.2.2.14. Defendant’s company name
31.2.2.15. Person being served
31.2.2.16. 3 lines for person address being served
31.2.2.17. 3 lines for person phone number being served
31.2.2.18. number of Defendants
31.2.2.19. Designation if paperwork is a real estate sale
31.2.2.20. Designation if fees are waived
31.2.2.21. Designation if fees are deferred
31.2.2.22. Date documents received
31.2.2.23. Time documents received
31.2.2.24. Beat number of deputy serving
31.2.2.25. Zip code of place paperwork being served
31.2.2.26. Type of document(s) being served
31.2.2.27. number of originals, copies, and file copies being served
31.2.2.28. Designation if paperwork is main paper
31.2.2.29. Court date or serve by date of paperwork
31.2.2.30. Special service instructions
31.2.2.31. Deposit type
31.2.2.32. Deposit amount
31.2.2.33. Receipt number from cash register
31.2.2.34. Information about cash/check/money order/cashier’s check/credit/debit payment received
31.2.2.35. Automatic internal control number (called docket number) assigned by computer after information is entered
31.2.3. The System should print a worksheet with some of the pertinent information above for each set of paperwork entered
31.2.4. The System should capture the following pertinent information when recording disposition of paperwork being
processed after being returned from deputy:
31.2.4.1. number of attempts
31.2.4.2. Date being returned as served, not served, etc.
31.2.4.3. number of each document being returned
31.2.4.4. Deputy’s badge number
31.2.4.5. Designation if paperwork is being transferred
31.2.4.6. If paperwork being transferred, record beat paperwork is being transferred to
31.2.4.7. Code designating paperwork is served, not served, etc.
31.2.4.8. Designation if paperwork is in-state, out-of-state, or a Writ
SERIAL 11086-RFP
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
31.2.4.9. Sufficient lines to designate service or non-service information
31.2.4.10. An information screen to record any additional information received regarding this case
31.2.5. The System should have the capabilities below and capture the following pertinent information when recording the
fees for paperwork being processed after being returned from deputy:
31.2.5.1. System should be able to determine whether fees can be entered based on information inputted when
documents were received
31.2.5.2. Billing code for service, handling, mileage, etc. and the corresponding fee for each type
31.2.5.3. Statistical information regarding mileage, cash levy information, sale information, etc.
31.2.5.4. A bill or refund check should be generated based on the input of the above information
31.2.5.5. Ability to close account or keep it open in order to pay the Maricopa County Treasurer statutory fees
31.2.5.6. Ability of the system to bill each outstanding account every 30 days up to 4 months and then turn over to
collections with information provided above
31.2.6. Ability to correct the following information in screens:
31.2.6.1. Case number
31.2.6.2. Plaintiff/Pro per/Defendant/Person being served information
31.2.6.3. Document status
31.2.6.4. Ability to inquire a certain case by:
31.2.6.5. Company name
31.2.6.6. Case number
31.2.6.7. Document status
31.2.6.8. Plaintiff name
31.2.6.9. Defendant name
31.2.6.10. Person being served name
31.2.6.11. Address where being served
31.2.6.12. Comment inquiry
31.2.6.13. Ability to add charges or payments:
31.2.6.14. Cash & fees entry
31.2.6.15. Charges entry
31.2.7. Correct/Maintain Financial Information:
31.2.7.1. Financial adjustments
31.2.7.2. Billing maintenance
31.2.8. Ability to inquire financial transactions by:
31.2.8.1. Check detail record
31.2.8.2. Account information
31.2.8.3. Transaction information
31.2.8.4. Bills outstanding
SERIAL 11086-RFP
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
31.2.8.5. Daily transaction inquiry
31.2.8.6. Docket financial transaction
31.2.9. Ability to maintain supervisory functions:
31.2.9.1. Check reconciliation
31.2.9.2. Bank balancing work page
31.2.9.3. Open/Close of business day
31.2.9.4. Retire checks over 90 days old
31.2.9.5. Pay State of Arizona Department of Revenue for retired checks
31.2.9.6. Deposit reconciliation
31.2.10. Ability to inquire certain supervisory functions:
31.2.10.1. Checks to be written
31.2.10.2. Hand posted checks
31.2.10.3. Closed cases
31.2.11. Receive automatic reports after supervisory functions:
31.2.11.1. Total fees to Maricopa County Treasurer
31.2.11.2. Print checks
31.2.12. Create codes for frequently used records:
31.2.12.1. Common billing code
31.2.12.2. Account code
31.2.12.3. Document type
31.2.12.4. Officer maintenance
31.2.12.5. Beat maintenance
31.2.12.6. Documents to print
31.2.13. Ability to make inquiries regarding common billing codes
31.2.14. Ability of system to create and print affidavits, returns and envelopes in Microsoft Word using information inputted
into system (and the ability to make changes once affidavits/returns are created)
31.2.15. Ability of system to create and print daily transaction reports for audit purposes
31.2.16. Ability of system to create and print the following reports in Microsoft Office products automatically at the end of
each month/period:
31.2.16.1. number of service attempts
31.2.16.2. Monthly activity report
31.2.16.3. Order of Protection & Injunction Prohibiting Harassment served & not served report
31.2.16.4. Roster of checks written for the month
31.2.16.5. Roster of checks over 60 days old
31.2.16.6. number of miles attempted for each set of paperwork
31.2.16.7. Beat recap
SERIAL 11086-RFP
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
31.2.16.8. Zip code recap
31.2.16.9. Outstanding bills report
31.2.16.10. Bills outstanding over 90 days old
31.2.16.11. Monthly master control
31.2.17. Ability to create adhoc reports of any of the above reporting information
31.2.18. The System should be able to interact with the cash register, debit/credit machine(s)
31.3. Tax Collections
31.3.1. Collection of delinquent personal property and mobile home taxes including the seizure and sale of personal
property to satisfy the tax bill.
31.3.2. The system should provide access to the County Assessor’s records showing Account Number, Name Fields,
Address Fields, Property Information, Resolution History, Comments, Delinquent Date, Valuation Date
31.3.3. The system should provide access to the County Treasurer’s records showing Account Number, Name Fields,
Address Fields, Property Information, Payment History, Comments, Total Due – broken down by year, fees and interest.
31.3.4. The system should allow Sheriff’s Office comments to be entered for a history of the account. The Treasurer &
Assessor would also be able to view the comments entered.
31.3.5. The system should able to have fees added to the account that would also reflect on the Treasurer’s system.
31.3.6. The system should be able to generate Tax Bills, Seizure Notices, Sale Notices, Affidavits, Deputy Worksheets and
Bill of Sales. There would also need to be comments as to what notices have been sent out and a “tickler” that would bring the
account to attention when the next step in the process needs to be generated.
31.3.7. The system should be able to provide statistical information as to how many accounts have been billed, how much
as been billed, what Deputy/Clerk is doing the work, etc.
31.3.8. The system would need to show immediately when payments from the Treasurer’s system are applied.
31.3.9. The system would need to be able to be query by name, address, years delinquent, and amounts due
31.3.10. The system should be able to interact with the cash register, debit/credit, payment processing, etc. in the event that
the Tax Unit starts taking payments again.
31.4. Subpoenas
31.4.1. Service of criminal summons/subpoenas for the Superior Court. A subpoena being a process commanding a
witness to appear and give testimony in a matter before the court. A Subpoena Duces Tecum being a process by which the court
commands a witness who has in his/her possession or control some document or paper that is pertinent to the issues of a pending
controversy, to produce it at trial.
31.4.2. The System should capture the following pertinent information when inputting subpoenas:
31.4.2.1. Case number(s)
31.4.2.2. Court code
31.4.2.3. Attorney’s bar number
31.4.2.4. Attorney’s first, middle, and last name, including suffix
31.4.2.5. Title of attorney
31.4.2.6. Attorney’s phone number
SERIAL 11086-RFP
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
31.4.2.7. Attorney’s extension
31.4.2.8. 2 address lines for attorney
31.4.2.9. City
31.4.2.10. State
31.4.2.11. Zip code
31.4.2.12. Designation if county attorney or not
31.4.2.13. Defendant(s) name(s), including suffixes
31.4.2.14. Defendant(s) alias(as), including suffixes
31.4.2.15. Charges against Defendant(s)
31.4.2.16. Witness’ first, middle, last name(s), including suffixes
31.4.2.17. Serial # (if witness is law enforcement)
31.4.2.18. “In care of” box
31.4.2.19. P.O. Box #
31.4.2.20. Address #
31.4.2.21. Direction
31.4.2.22. Street Name
31.4.2.23. Suffix
31.4.2.24. Apartment #
31.4.2.25. City
31.4.2.26. State
31.4.2.27. Zip Code (which will fill in the “beat” entry below)
31.4.2.28. Beat
31.4.2.29. Home Phone
31.4.2.30. Work Phone
31.4.2.31. Work Extension
31.4.2.32. Area for warnings and special service instructions
31.4.2.33. Date subpoena received
31.4.2.34. Designate if subpoena is to be mailed, personally served, or faxed
31.4.2.35. Designate if subpoena is mental health or regular subpoena
31.4.2.36. Court date
31.4.2.37. Court time
31.4.2.38. Designate type of subpoena (criminal, juvenile, etc.)
31.4.3. The system should print deputy worksheets or postcards & envelopes for each subpoena entered (including bar
code to identify each worksheet or postcard printed)
31.4.4. The System should capture the following pertinent information when recording disposition of the subpoena being
processed after being returned from deputy or in mail:
SERIAL 11086-RFP
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
31.4.4.1. Use bar code to identify postcard or worksheet being returned
31.4.4.2. Return disposition line (served, not served, witness dead, moved, etc.)
31.4.4.3. Date and time returned
31.4.4.4. Deputy serial number
31.4.4.5. Deputy last name
31.4.4.6. Deputy first name
31.4.4.7. Mileage
31.4.4.8. Activity Comments section
31.4.5. The System should allow the ability to update, edit and print the following items:
31.4.5.1. Post cards
31.4.5.2. Envelopes
31.4.5.3. Worksheets
31.4.6. The System should allow the following items to be used as shortcuts to enter information automatically :
31.4.6.1. Activity Result
31.4.6.2. Activity Type
31.4.6.3. Attorney/Justice Courts
31.4.6.4. Class Type
31.4.6.5. Court Codes
31.4.6.6. Service Type
31.4.6.7. Beat Information
31.4.6.8. Exception Beat
31.4.6.9. Subpoena Beat
31.4.6.10. Subpoena Statistics
31.4.6.11. Beat Zip Code
31.4.7. The System should allow the following reports to be generated:
31.4.7.1. Defendant/Witness Court Date
31.4.7.2. No Results Activity Over 60 Days
31.4.7.3. Mailed Pending by Date Selection
31.4.7.4. Personal Pending by Date Selection
31.4.7.5. Witness Future Court Dates
31.4.7.6. Witness Select by Court Date
31.4.7.7. Witness Select by Last Name
31.4.7.8. Check Address For Prior’s
31.4.7.9. Run Statistics Report
31.4.7.10. Subpoena Beat Totals
31.4.7.11. Subpoena Beat List
SERIAL 11086-RFP
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
31.4.7.12. Subpoena By Address
31.4.7.13. Print Single Case
31.5. PERSONAL & REAL PROPERTY SEIZURES & SALES
31.5.1. The System should capture the following information and additional information regarding personal or real property
seizures and sales:
31.5.1.1. Plaintiff
31.5.1.2. Defendant
31.5.1.3. Defendant body from writ
31.5.1.4. Case number
31.5.1.5. Docket number
31.5.1.6. Document issued
31.5.1.7. Day document issued
31.5.1.8. Month and year document issued
31.5.1.9. Judgment day issued
31.5.1.10. Month and year judgment issued
31.5.1.11. Amount of judgment
31.5.1.12. Amount of interest
31.5.1.13. Costs
31.5.1.14. Judgment sum
31.5.1.15. Interest day started
31.5.1.16. Month and year interest started
31.5.1.17. Percent interest
31.5.1.18. Levy day
31.5.1.19. Month and year levy
31.5.1.20. Property one
31.5.1.21. Property two
31.5.1.22. Property three
31.5.1.23. Property four
31.5.1.24. Property five
31.5.1.25. Sale day
31.5.1.26. Month and year of sale
31.5.1.27. Place of sale
31.5.1.28. Day typed
31.5.1.29. Month and year typed
31.5.1.30. Deputy
31.5.1.31. cc
SERIAL 11086-RFP
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
31.5.1.32. A number
31.5.1.33. Plaintiff body from writ
31.5.1.34. Bidder’s name
31.5.1.35. Bid sum spelled
31.5.1.36. Bid amount
31.5.1.37. Day document received
31.5.1.38. Month and year document received
31.5.1.39. Number of parcels
31.5.1.40. Wholly or partially
31.5.1.41. Accrued costs
31.5.1.42. Accrued costs written
31.5.1.43. Interest
31.5.1.44. Attorney fees
31.5.1.45. Additional costs 1
31.5.1.46. IC
31.5.1.47. Balance due
31.5.1.48. Overpayment
31.5.1.49. Lien holder
31.5.1.50. Lien holder extra line
31.5.1.51. Lien holder street
31.5.1.52. Lien holder P.O. Box
31.5.1.53. Lien holder city
31.5.1.54. Lien holder state
31.5.1.55. Lien holder zip code
31.5.1.56. Lien amount
31.5.1.57. Lien date
31.5.2. The System should be able to create and print the following documents seizures and sales:
31.5.2.1. Levy
31.5.2.2. Sale notices
31.5.2.3. Various returns
31.5.2.4. Certificates of sale
31.5.2.5. Deeds
31.5.2.6. Release letters
31.5.2.7. Form letters to MVD, FAA, Game & Fish, etc.
31.5.2.8. Lien letters
31.5.2.9. Demand letters
SERIAL 11086-RFP
1554
1555
1556
1557
1558
1559
31.5.2.10. Envelopes
31.5.2.11. Sale notice posting information sheets
31.5.2.12. Sale book information
31.5.2.13. Affidavits of service
31.6. Orders of Protection/Warrants
31.6.1. Orders of Protection or injunctions against harassment may be obtained through all Justice Courts, Municipal Courts,
and the Maricopa County Superior Court. The Sheriff's Office serves orders issued by the Superior Court, while municipal police
handle orders issued by the Municipal Courts, and orders issued by Justice Courts are served by the appropriate Constable.
1560
31.6.2. Add to the information page. Check box when background completed. Add second page with template matching
existing memo showing background investigation results. Forward information to OIC.
31.6.3. Scanning to add out of state information i.e. driver’s license photo/booking photo.
31.6.4. Need the capability to log all orders served and orders pending service. This information should be able to be
retrieved by subject serverd. Subject being protected, addresses of either party etc.
31.6.5. Ability to query how many Orders of Protections processed on a monthly basis, and year to year. Same with
warrants.
31.7. Pawnshop and Second Hand Store Sub-System
31.7.1. Issuance of Pawnshop/Second Hand licenses for Maricopa County. Coordinating hearings for the suspension or
revocation of pawnshop licenses. Investigating the recovery of property reported stolen within the SO's jurisdiction that is recovered
in any pawnshop within the County, and the coordination of the subsequent release of the property. Investigating the recovery of
property reported stolen from outside of Arizona and recovered in pawnshops in the SO's jurisdiction, and coordinating the
subsequent release of that property. Investigating administrative and criminal violations regarding the operation of pawnshops and
second hand stores in the SO's jurisdiction. Vendors are being asked to include functionality for pawnshop and second hand store
requirements when completing their responses to the REGISTRANT AND REGISTRATION TRACKING / LICENSEE AND
LICENSEE TRACKING Section of this request. Vendors are further ask to bid a total replacement of the current County Pawn SubSystem in their response to the section titled Pawn Sub-System herein. Vendors who cannot offer a total replacement system are
asked to bid an interface from their RMS to the county's current Pawn Sub-System to export stolen property with proper identifying
numbers. See the Interfaces Section of this document for further detail.
31.8. ATF Class III Firearms
31.8.1. The Bureau of Alcohol Tobacco and Firearms requires that the Maricopa County Sheriffs Office, as the Chief Law
Enforcement Officer, certify that no information is available that would disqualify an ATF form 4 applicant (transferee) from receiving
or possessing the firearm described in Item 4 of the application being considered. The process leading to an approval or denial is as
follows:
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
31.8.1.1. The application packet is checked to see if it has been completed properly, contains the required two copies,
signatures are notarized, contains a photograph, contains a valid picture identification such as a Driver's License or Passport.
31.8.1.2. Photocopies are made of the valid identification documents to allow their return to the owner.
31.8.1.3. Verify current contact information and write it on the photocopy. Date and time stamp the photocopy.
31.8.1.4. The MCSO employee processing the application writes their A number on the photocopy.
31.8.1.5. If the application packet is not in proper order it is returned to the applicant for correction.
SERIAL 11086-RFP
1573
31.8.1.6. If the application packet is in order automated and manual queries are made to other municipal, county, state
and federal systems seeking information on the applicant. Queries are made to MVD (KQ), Interstate Identification Index-National
Criminal History (AHQH-III), MCSO JMS, MCSO RMS, Warrants (ACQW), State Criminal History (AHSR), MCSO Jail Visitation
(DNB1) and PACE Phoenix Police RMS (phone call to check for Warrants and recent criminal involvement), CAIS, County
Attorney's Information System, and other systems as necessary.
1574
31.8.1.7. The results of these inquiries are attached to a Face Sheet Document used to track the verification process.
Each hit must list the agency name, the charges, whether a suspect or victim, incident date and location, and disposition if available.
31.8.1.8. If a hit occurs the agency having the hit is contacted and asked to fax the supporting documentation. A record
of the contact is noted on the face sheet. If a response is not returned within one week, re-contact the agency. This process is
repeated until a response is received.
1575
1576
1577
31.8.1.9. Once the requested report is received, update the face sheet with all pertinent information, including disposition
if available, and any anomaly or peculiarity.
31.8.1.10. Once it is apparent that the application is being denied; the draft face sheet with notations is used to prepare
a final document, the packet is transferred to a red folder with the final face sheet and supporting documents placed in an
established order, and a denial letter is prepared for the Captain's signature. The applicant will be contacted and given/sent a copy
of the denial letter. A notation is made in the ATF log indicating the disposition. The packet is retained on file to be available if there
is an appeal of the denial. Otherwise it is retained until it can be legally disposed of.
1578
31.8.1.11. Once it is apparent that no disqualifying information has been found; the draft face sheet is used to prepare a
final document, the packet is transferred to a blue folder, ATF Forms are prepared for signature, a Thank You letter is prepared,
sign here postems are attached to the signature locations, and the blue folder with all documents arranged in the established order
is sent up a three step chain of command for signatures. The packet is retained along with a copy of the ATF Form 4.
1579
31.8.2. Vendor's are being asked to offer solutions for automating the above process. Third party applications will be
considered if they will be supported under one maintenance agreement with the primary vendor. Functionality should include:
31.8.2.1. Record keeping of applicants similar to pawn system. Ability to query by name, address, telephone and id
numbers.
31.8.2.2. Template matching existing memo showing background investigation results and pending information. Update
and add to the information to include new application date for repeat applicants. Be part of the applicants file as listed above.
31.8.2.3. Approved/Disapproved section with reasons/ comments
31.8.2.4. Tracking received date, signatures and completion, how many applications approved, disapproved and
pending monthly basis
31.8.2.5. Scanning ability for reports.
31.8.2.6. Payments received. Same format as Civil.
31.8.2.7. The capability to list an applicant and his/her history of weapons acquired by date ranges, overall, by address,
and by surname only to help track unusual buying patterns.
31.9. Extradition
31.9.1. Extradition is the official process whereby one nation or state surrenders a suspected or convicted criminal to
another nation or state. …
1580
1581
1582
1583
1584
1585
1586
1587
1588
SERIAL 11086-RFP
1589
31.9.2. Interstate Extradition - The term applied to the process of removing a person from one state to face charges in
another state. Federal law and the US Constitution govern interstate extradition, but the process still varies from state to state. The
process timeline begins when a person is arrested, either based upon a "fugitive of justice" warrant or when they are detained for an
infraction in another state. It is standard operating procedure for agencies to run a "wants and warrants" computer check looking for
"fugitive of justice'\" wants and warrants. The moment the requesting state is notified of the presence of their fugitive in custody a
timeline starts for the state to process their extradition request. The timeline for the request starts with the notification of detention
and will expire at the end of 90 days. If an Arizona agency is holding the detainee and he or she is not picked up within the 90 day
period the detainee must be released from custody.
1590
31.9.3. The detainee may waive the issuance and service of the warrant and all other procedures incidental to the
extradition proceedings buy prescribing in the presence of a judge of a court of record within the state a writing which stated that
he/she consents to the return to the demanding state. If consent is duly execute, the judge shall direct the officer who has custody to
deliver the detainee promptly to the accredited agent or agents of the demanding state along with a copy of the consent.
1591
31.9.4. A law enforcement agency holding a person who is alleged to have broken the terms of his/her probation, parole,
bail or other release shall immediately deliver the person to the duly authorized agent of the demanding state without the
requirement of a Governor's warrant if the detainee has signed a prior waiver of extradition as a term of his/her current probation,
bail or other release in the demanding state, and the law enforcement agency holding the person has received an authenticated
copy of the prior waiver of extradition signed by the detainee, and the demanding state submits a photograph and fingerprints
identifying the person who signed the waiver. This provision does not constitute a waiver by the detaining state of its right, power or
privilege to try the fugitive for a criminal offense committed in in the detaining sate. If a local criminal charge is pending against the
fugitive in a court in the detaining state, the fugitive's transfer of custody is subject to the discretion of the Governor. Delivery of a
fugitive to an agent of the demanding state does not constitute a waiver of the state's right, power or privilege to regain custody of
the person by extradition, detainer proceedings, or other process for the purpose of trial for any offense charged against the person
in the original detaining state.
31.9.5. If a criminal prosecution has been instituted against such person under the laws of the detaining state and is still
pending the Governor may either surrender the person on demand of the Governor of another state or may continue to hold the
person until the person has been tried and discharged or convicted and punished in the detaining state. This action would not
constitute a waiver by the demanding state of its right, power or privilege to extradite when the fugitive is released.
1592
1593
31.9.6. If the demanding state wishes to obtain custody of a person charged in the demanding state with a criminal offense
and the person was convicted or is imprisoned or held under criminal proceedings then pending in a third state, the Governors of the
detaining and demanding states may agree on the extradition before the criminal proceedings have terminated or the persons
sentence has been served. A Governors' agreement of this type is conditioned upon the return of the person to the original detaining
state at the demanding state's expense as soon as the prosecution is terminated, unless the person is sentenced to death.
1594
31.9.7. Extradition Documents - A warrant of extradition will not be issued by the detaining state unless the documents
presented by the demanding state's executive authority clearly show - except in cases that fall under ARS 13-3845, the accused was
present in the demanding state at the time of the commission of the alleged crime, and thereafter fled the state, and the accused is
now in the detaining state ( photo and fingerprints), and the accused is lawfully charged by indictment found or by information filed
by a prosecuting officer and supported by affidavit to the facts, or by affidavit made before a magistrate in that state, with having
committed a crime under the laws of that state, or has been convicted of a crime in that state and has escaped confinement or
broken parole.
SERIAL 11086-RFP
1595
31.9.8. Recovery of Expenses - On conviction of the crime that caused a person to be extradited to the demanding state,
the state or political subdivision, either jointly or severally, may recover from the convicted person the actual expenses incurred by
the extraditing agency.
1596
31.9.9. Interstate Agreement on Detainers - This agreement applies to transfers of sentenced prisoners for unrelated trials
between two States, and to transfers from the Federal Government to the States, and from States to the Federal Government. The
agreement permits a prisoner to initiate final disposition of any untried indictment, information, or complaint against him/her in
another State on the basis of which a detainer has been lodged against him/her. Upon return of the prisoner, and without good
cause continuances granted by the court in the presence of the prisoner and his/her attorney, trial shall be commenced within one
hindered and twenty five days of the arrival of the prisoner in the receiving State. If this time limitation requirement is not met the
receiving states' indictment shall be dismissed with prejudice. Article III of the Agreement also establishes that trial must commence
within 180 days of receipt by prosecuting State of prisoner's request for final disposition of charges identified in the detainer. These
two time constraints narrow the time available for physically extraditing prisoners.
1597
31.9.10. The Supreme has further complicated the extradition process by ruling that prisoners have extradition rights under
the laws of the State of incarceration. This entitles the prisoner to a hearing before he/she can be transferred from the custody of
the State of incarceration.
1598
31.9.11. The Agreement also allows a Governor only 30 days in which to disapprove a request or transfer on his/her motion
or that of the prisoner.
31.9.12. Vendors are being asked to offer solutions for automating the above processes. Third party applications will be
considered if they will be supported under one maintenance agreement with the primary vendor. The system should provide the
capability to establish an event file for each extradition activity. The type of request and the requesting agency should prompt
"action reminders" to the officer or officers assigned based upon the time constraints involved. The system should support access to
the queries required to determine if a prisoner is "extraditable". The system should also provide the capability of tracking all travel
expenses incurred per event, and reports should be supported that will aggregate costs by geographic area of the country and
distance from Phoenix by selected dates. Reports are needed that will compare expenses by year and report percentage of increase
and decline. Cash Account Management is also a requirement that vendors need to address for this section, or when responding to
the Cash Account Management Section of this document.
1599
Ref
No.
1
2
3
4
Requirements Description
Response
1. CAD Functional Requirements
1.1. The system should be designed to operate as a component of a comprehensive, seamlessly integrated, incident-based
Public Safety Information Technology environment.
1.2. The system should allow the County’s authorized users to retrieve, enter, and modify information in the RMS through the
County’s Intranet and enterprise network utilizing a browser interface.
1.3. The system should provide an Administration and Security module that will allow the System Administrator to control
security, maintenance of tables, backups, maintenance of reports, screens, etc.
SERIAL 11086-RFP
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1.4. MCSO often has to respond to new mandates quickly that make it necessary to add new data field to entry/retrieval masks
and store their entry content in the database. Vendors are being ask to explain in detail how they can satisfy this requirement.
1.5. The system should be capable of maintaining a minimum of 20 years of incident data online without having to retrieve
archived data.
1.6. The system should include as many labor saving routines as possible. For example, when an officer is preparing several
reports related to a single event the officer will not have to reenter his/her badge number for each item, or the location where the
event occurred. Like information should auto-populate,
1.7. The system should have the ability to receive, store, and manage data contained in selected Maricopa County Sheriffs
Department report forms.
1.8. The system should be designed to share information logically, automatically, and seamlessly with other systems, such as
the proposed CAD system, while minimizing the use of point-to-point interfaces.
1.9. The system should include a geographically based analytical tool (mapping) component that provides analytical tools for
viewing and accessing spatial relationships among stored data. Any data that is capable of having an address or coordinates should
be capable of being represented visually on the map. This includes incidents and other events, districts, hydrants, stations,
jurisdictional boundaries, and hospitals. The offeror's GIS mapping system should interface with an ESRI GIS and the offeror should
be able to import the County's GIS data into their GIS solution. The offeror should provide means to facilitate new uploads of GIS
data into system for use with their software.
1.10. User import of data should not result in slowdowns, downtime or the breaking of any relational linkages.
1.11. The system should provide the capability for an audit trail of all transactions including records views.
1.12. When a user signs on to the proposed RMS system, the system should be capable of displaying an agency-defined user
home-page, or summary informing the user of information such as:
1.12.1. Incomplete reports for which the user is responsible
1.12.2. Reports that have been returned for correction or review for which the user is responsible,
1.12.3. Returns from delayed inquiries to RMS, NCIC, and other resources,
1.12.4. Persons or items of interest “hits”.
1.13. The proposed RMS system should provide the County with the ability to archive selected records to off-line devices and
transmit the data to off-site servers.
1.14. The system should allow authorized end-users to copy information and reports in the RMS to compact disk and other
removable media storage. Please explain how this functionality can be limited to a select number of users.
1.15. All information contained within the RMS should be available for inquires and report production.
1.16. The system should include simple methods for exporting RMS data into Access, EXCEL, and other industry standard
formats. Again, explain how this capability can be provided to only authorized staff.
1.17. The system database should have the ability to input, store and export text, sound, images, and other objects.
1.18. The system should have the ability to attach scanned images, such as pictures, diagrams, audio files, video to a case
record.
1.19. The proposed RMS system should allow access by point-and-click to all forms, images, and other database items
associated with a given case.
SERIAL 11086-RFP
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
1.20. The system's report formats should be sufficiently configurable to avoid empty space and un-used fields on all viewed and
printed reports.
1.21. The system should have the ability to search code tables by code or by code description.
1.22. The system should capture relevant user-defined data elements and perform required edit validation for:
1.22.1. Uniformed Crime Reporting (UCR) (NIBRS) system (edit to ensure that required fields are entered at time of entry)
1.22.2. Master Name Index (MNI)
1.22.3. Master Vehicle Index (MVI)
1.22.4. Master Property Index (MPI)
1.22.5. Master Telephone Index (MTI)
1.22.6. Automated Field Reporting
1.22.7. Investigations
1.22.8. Case Management
1.22.9. Crime Analysis
1.22.10. Arrest and Booking
1.22.11. Warrant Control
1.22.12. Registrant Tracking
1.22.13. Neighborhood Services
1.22.14. Code Enforcement
1.22.15. Animal Control
1.22.16. Accreditation.
1.22.17. County Probation
1.23. Vendors are being asked to comment on their systems capability to provide a standard XML data interface (or API) that
can be used by customer as required.
1.24. The Maricopa County Attorney's Office needs to read case reports and all attachments for cases that have been
submitted for prosecution. They need to further reports back to the detectives with notations, and they need to import case
information into their internal system upon request. Since they use such a small portion of RMS functionality, can they be provided a
viewer or a form of RMS lite at a reduced cost?
1.25. The system should utilize windows standard hypertext linked help for CAD User Guides and also supports the ability to
take County supplied documents and adds them to the help system.
1.26. The system should also provide the ability to add icons to the application area with links to County supplied documents by
having an Icon and short description of the document.
1.27. This function should be capable of being updated, online by an authorized user.
1.28. This function should include an index or menu of Help topics including the acronym that identifies each topic, a short
description of the topic, and the instructions for accessing the topic.
SERIAL 11086-RFP
51
1.29. The CAD system should have an online help feature with Windows Hypertext, which includes instructions for accessing
user documentation. This function is user programmable and may be searched according to key words such as function names,
commands, or other easily recognized subjects. It should support searching by context index, or a find feature that provides a
description of the topic and a hypertext link to eliminate directions to the information
52
1.30. The offeror should also provide help files that describe system commands and procedures. Users should be able to
search for a command, or select from a command list. Double clicking or selection with the cursor displays the help information.
1.31. The offeror should provide documentation on the system’s functional aspects.
1.32. The system should permit users to data fill those fields that are pre-defined (pick lists). If the data remains invalid, a data
pick list displays, and the user can navigate through the list to the desired entry, select that entry, and the correct code is
automatically entered into the field.
53
54
55
56
1.33. The system should be capable of providing administrative/supervisory control over who can update and create pick lists.
1.34. If the user should enter an incorrect data into any pre-defined field, the system should return an error message and
automatically display the HELP drop down list for that particular field. This feature should be user configurable to prevent the lists
from appearing if so desired.
57
58
59
60
61
1.35. County would like the capability to track common data entry errors so that they can address some of them via training.
1.36. This process should provide for data integrity and consistency by trapping data errors at input time.
1.37. All pertinent documentation should be available online and the system administrator should be able to control its access.
2. EVENT AND CASE REPORT NUMBERING
2.1. The County is familiar with a process that assigns an event number to all activities entered into CAD. Some of the activities
result in departmental reports being prepared. These reports use their event numbers for identification. This process can require
additional event numbers when more than one crime is being reported on additional departmental reports. The County is interested
in hearing recommendations on how best to identify its events and reports.
62
63
64
65
66
67
2.2. The offeror should describe their event and case numbering process.
2.3. The system should be able to:
2.3.1. Allow for multiple case numbers to be associated with a single event.
2.3.2. Provide the capability of providing a "one to one" case number and event number.
2.4. These two options should be configurable by the system administrator.
2.5. Field users should have the ability to retrieve case and event information using their MDCs without involving
Communications.
2.6. Vendors should explain how supplements to original reports are identified (numbered) and how if property is being
impounded using supplements, duplicate property item numbers are avoided.
3. MESSAGING
3.1. Vendor shall explain what can be done to prevent incoming messages from over cluttering screens when messaging
volumes are high. The active units display needs to be in full view at all time.
3.2. The vendor shall explain in detail the process for accessing past messages.
3.3. The system should have the ability to support messaging from MDCs and Workstations to:
3.3.1. Workstation(s), Group(s), MDC(s), Event Number, individuals, and any combination thereof.
68
69
70
71
72
73
SERIAL 11086-RFP
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
3.3.2. All messages need to identify the workstation or MDC that sent the message and all the workstations or MDCs that
received the message.
3.4. All messages need to be time stamped.
3.5. The message should appear at the receiving terminal as it was typed in to include punctuation, returns, spacing etc.
3.6. When a message is printed the system needs to display the position requesting the print and the associated employee ID
on the printed header. Can this functionality be turned off if so desired?
3.7. The system provides the capability for users to define static and dynamic (ad-hoc) message groups for messaging.
3.8. The system can provide a simple/easy means for printing complete message information.
3.9. The system has the capability of providing Agency-defined visual and/or audible indicators that a message has been
received for both CAD workstations and MDCs.
3.10. Priority messages should produce an agency-defined audible or visual flashing indicator that is different from normal
messages.
3.11. Priority message notifications should take priority over routine messages.
3.12. Messaging can support a single user action to reply/forward to sender (similar to e-mail ) without having to type a reply
from a MDC, workstation, email, wireless device. The reply action should be configurable by Agency.
3.13. The system should support Agency definable "canned" replies in a drop-down menu.
3.14. For MDC's, the proposed message application should provide an option for a pop up window without the need for the
operator to take an affirmative action to make the message visible.
3.15. Forwarded messages should indicate the initial sender's ID in addition to the ID of the user who forwarded the message
and the time the original message was sent and forwarded.
3.16. The system should allow users, upon request, to receive acknowledgement that their sent message was read and indicate
the time the message was opened and read (agency-definable parameter).
3.17. Alerts and notifications should be delivered as a automatic pop-up window requiring action, a static display indicating that
notifications should be checked or a highlighted button that triggers a pop-up list. Each should be configurable by the system
administrator for maximum suitability to the CAD function supported.
3.18. The message system should allow Agency configurable notification and message masks.
3.19. The system should provide a minimum of three agency definable alert tones for messaging on workstations and MDCs.
3.20. Users should be able to save received messages to a notepad for future review.
3.21. The system administrator is provided unrestricted access to all messaging functionality.
3.22. The system can allow the system administrator to define individual and role based messaging capability.
3.23. The system should allow the user to send the underlying text of any message received on the MDC to a printer.
3.24. The user should have the capability to select any printer available on the network and not be confined to only the default
printer for his or her terminal device,
3.25. The system should minimally support the following classifications of user-definable messages:
3.25.1. Routine, messages that are sent, which should be archived.
3.25.2. Remote messages (from outside sources such as ACJIS, NCIC, etc., should include the message number provided
by ACJIS, NCIC, NLETS).
SERIAL 11086-RFP
99
100
101
102
3.26. The system should have the ability to generate and save user-defined groups, and
3.26.1.
store critical messages for non-logged on users for later delivery when they next log on and,
3.26.2.
store and forward any undeliverable critical messages until delivered.
3.27. The system should have the ability to send messages to users not logged on to the system. Users who receive a
message and are not logged on to the system will receive the message upon log on. If an intended recipient is not logged on the
sender should be notified.
103
3.28. The system administrator should have the ability to configure the time period and type of messages stored and forwarded
to an officer upon logon.
3.29. The system should provide the capability to easily retrieve past messages.
3.30. The system should allow all messages to be indexed and sequentially numbered to facilitate ease of search and recall.
3.31. The system should allow users to query and view a number of messages at once by specified date and time range(s).
3.32. The system should have the ability to "mine" the text of messages for key words as well as by EIN, position, dates and
times, groups, and any other user-defined parameters.
3.33. The system should provide users the ability to quickly and easily recall their most recently viewed messages.
3.34. The system should allow users to review archived messages
3.35. MDC and workstation users should be able to view more than one message at a time without deleting the previous
message.
3.36. Communications Supervisors should have the capability to view messages (real time and historical) operator to operator
and operator to MDC.
3.37. The system should provide the capability to print messages taking place between specific terminals//individuals in
chronological order.
3.38. The system should provide a simple way to associate messages to events and store them as part of the event logs.
4. EXTERNAL MESSAGING
4.1. The system should allow the County to automate notifications related to selected events (For example, on an Armed
Robbery where the victim was shot, user defined County Staff would be notified via the following options:
4.1.1. CAD message
4.1.2. The County e-mail system
4.1.3. Any e-mail address entered by the user
4.1.4. The County paging system
4.1.5. A text message to any wireless device
4.1.6. All or any combination of the above methods simultaneously.
4.2. An unlimited number of notifications should be allowed for any event type as determined by the system administrator.
4.3. The system should provide a user-definable check-box(s) on the message screen which facilitates the above alternative
notification methods.
4.4. The content of automatic external message (notifications) should be agency specific based on all available event
information.
4.5. The trigger for automatic external messaging should include any or all of the following:
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
SERIAL 11086-RFP
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
4.5.1. Unit dispatched
4.5.2. Unit dispatched to specified event types
4.5.3. Event type with specified status. Example pending, dispatched, etc.
4.5.4. Event location, by specified event type if desired
4.5.5. Event Benchmarks
4.6. Manual initiation of event notification messaging should be a capability.
4.7. The acknowledgment by a user of a notification should be placed into the event history.
5. PAGING
5.1. Users should be able to send a manual page by identifying the employee ID or designator followed by text.
5.2. The system should be configured to send a notification page based on event type or LOI or LH or any combination to a
predefined group or multiple groups.
5.3. The system should allow paging to and from workstations and MDCs.
5.4. The system should have the ability to transmit specific agency-definable information from the event to specified wireless
devices and workstations.
6. SYSTEM MEMOS
6.1. Users should be able to enter a memo into the system to display at a specific date and time
6.2. The memo can be set to occur once or for a set duration
6.3. The memo should identify who entered the information
6.4. The memo should be capable of being set to appear at a specific workstation or MDC or to a group of workstations or
MDCs or any combination of the two
6.5. A memo should be capable of being configured to remain in the system until it is manually removed, or auto- purged upon
expiration.
7. LOOKOUT FORM
7.1. The system should support the creation and maintenance of agency-definable lookout information related to people,
places, and objects (e.g., cars) for dissemination to users via a mask.
7.2. The system should provide the ability to archive and query lookout information by date, time range, and all other data fields.
7.3. The lookout information should be capable of being associated to a specific event(s) and the information should be added
to the event.
7.4. Users should have the ability to send the lookout form and information to workstations, MDCs, and groups.
7.5. When generating a lookout form with an event number, the system should auto fill agency-defined information.
8. MAPPING
SERIAL 11086-RFP
151
8.1. The mapping system should be integrated with the CAD system to allow for event creation and dispatch functions. For
example, a location should be able to be clicked on and an event should be created at the address. Even if the result is no more
than an event form with the verified location in it. The dispatcher should be able to click on a pending event on the map and receive
unit recommendations and dispatch all off the map screen. On an active event the dispatcher should be able to click on the event or
associated units and get further unit recommendations (back up units for example). The dispatcher should have the ability to CTRLclick on two events and be able to cross reference the two events together once it is determined they are related. The same feature
should exist for canceling or duplicating an event.
152
8.2. Vendor note: Maricopa County is using ESRI mapping products and is working to provide map detail down to the
apartment level. It is assumed that the new CAD will use the ESRI map to support its new CAD/RMS systems. Currently, Maricopa
County Regional 911, which is managed by the Phoenix Fire Department, is receiving map updates from member agencies and
making this County/State map data available to its member agencies. Updates are usually available quarterly. The regional map is
being used to display Power 911 caller location data. A third web hosted map that is maintained by the Maricopa County
Department of Transportation (MCDOT) is being used less frequently to determine jurisdictional boundaries.
153
8.3. All CAD Geobases should be sourced from the County's existing master address database - this will include the
incorporation of specific point addressing information (broken in native addressing components - Number, directional, street name,
street type, post directional, and unit or suite) and also the incorporation of linear attribute features coming from the GIS
transportation dataset - to include 100 block ranges, jurisdictional information (as appropriate), and street name information.
154
8.4. All CAD Geobases should have ability to store geographic values associated with any address point delivered/incorporated
from the GIS master address database. Geographic values will be representative of easting and northing values consistent with
current GIS projection.
155
8.5. All CAD Geobases should have the ability to incorporate and store appropriate geographic designators (Coverage Area,
map page, district, etc.) as defined by Maricopa County and integrated as overlay feature classes (boundary feature classes) in GIS
to the CAD/RMS geographic tables.
156
8.6. The system should have the ability to view all available GIS Feature Layers (Feature Classes) within the mapping interface.
Mapping Interface has ability to display point, line, polygon, linear reference, primary annotation (including feature linked), and
geometric network data as harvested from the County GIS. Please reference attached County GIS Data for (currently) available
feature classes.
157
8.7. The mapping interface should have the ability to display third party location based services (LBS) (AVL locations) on map,
and render appropriately to type of LBS. In particular the Positron Power ALI information plotted to the map.
8.8. Mapping interfaces must demonstrate the ability to display map layers using the following protocols:
#REF!
8.8.1. OpenGIS Web Map Service (WMS)
8.8.2. OpenGIS Web Feature Service (WFS)
8.8.3. ESRI ArcIMS
8.9. Mapping interfaces must allow local administrators to add and configure new map layers without incurring additional cost to
MCSO. Additionally, mapping interfaces must demonstrate the ability to display custom graphics for individual map points as styled
in ESRI ArcServer and other map servers.
158
159
160
161
162
163
SERIAL 11086-RFP
164
165
166
167
168
169
170
171
172
173
174
175
176
177
8.10. Mapping interfaces must be capable of displaying local base imagery provided by Maricopa County.
8.11. The mapping interface should be developed on open API for additional programming/development by County personnel.
8.12. The system should have the ability for CAD dispatchers to identify location on the mapping interface to initiate an event.
8.13. The vendor's CAD and RMS components should utilize the same mapping tables for address validation and database
incorporation.
8.14. The system should have the ability for system to "roll back" to a previous map configuration when an update to the
mapping interfaces fails due to any reason.
8.15. The mapping system should have the ability to read directly from the County GIS database for map rendering, if not,
system must be able to run timely updates from County GIS database with limited downtime.
8.16. The mapping system should have the ability to render multiple addresses for any event. In the event the caller address is
not representative of the actual event (dispatch) address, the system must have the ability to reference and render both addresses
on the map system, then reposition display as necessary to reference the event address. Appropriate data fields will then be
updated to reflect the incident history.
8.17. The system should update the appropriate data fields for caller's identification/location information in the incident history
records.
8.18. The map should be accessible on the MDC utilizing touch screen capabilities.
8.19. Users should have the ability to turn on and off any agency-defined data layers that are available for the map display.
8.20. Users should have the ability to utilize their GPS identified locations to create a new event, change an officer's location,
etc. Additionally, users should have the ability to update the event address.
8.21. The system should have the ability to display the coordinates of any position on the map identified by the user with any
user input device (touch-pad, mouse, touch-screen [MDC], etc.).
8.22. The system should have the ability to display a different symbol for unit types.
8.23. The system should have the ability to display a different symbol for events according to the activity in which they
represent. For example, it should be possible to set a different user-definable symbol for a traffic stop, a pursuit, a fight, or an offduty employment detail.
178
8.24. Existing map features will be linked to underlying attribute information stored in feature table, and available for viewing
(identifying) using the map interface. Information will be available as part of a mapping tool. (e.g. IDENTIFY button in any ESRI
map interface tool set).
179
180
8.25. The system should have the ability to display position updates from an AVL controller on the map in real-time.
8.26. The system should include the ability to zoom in and zoom out, pan in any direction, and display additional layers of the
map.
8.27. The user should be able to turn graphic layers on and off as necessary.
8.28. The system should allow the system administrator to set the following attributes for the mapping interface:
8.28.1. The default display position on the monitor,
8.28.2. The default size of the map when it is displayed,
8.28.3. The default view and zoom level, and
8.28.4. The default layers which will be displayed on the map.
181
182
183
184
185
186
SERIAL 11086-RFP
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
8.29. Rendering characteristics for any viewable layer. Rendering characteristics may be based upon the associated
underlying attribute information tied to any feature within a particular feature class. Characteristics may involve (but are not limited
to) - feature type, color, size, or angle (or any combination there of) and will render dependent upon the criteria set by the system
administrator.
8.30. The user should be able to filter the display of units and events by:
8.30.1. Event number,
8.30.2. Event type,
8.30.3. Response Area, and
8.30.4. Event priority.
8.31. The system should permit the user to filter units being displayed by:
8.31.1. Unit type,
8.31.2. Unit status,
8.31.3. Type of assigned event,
8.31.4. Priority of assigned event, and
8.31.5. any other data element in the event record.
8.32. The system should permit the user to control map functions, including but not limited to:
8.32.1. Entering a street address, intersection, commonplace, geographic coordinate or other verifiable location to zoom and
display the location on the map.
8.32.2. Entering a dispatched unit to zoom and display his/her location on the map.
8.32.3. Entering a command to zoom or pan the existing view of the map.
8.33. The system should automatically zoom to the area of a new call for service when it is received by the desktop via the 911
system.
8.34. The system should automatically zoom to the area of a new call for service when it is received by the desktop or MDC.
8.35. The system should have the ability for user to configure the system to automatically zoom to the location of an event when
it is opened.
8.36. The system should have the ability to determine and display a route of travel for a unit from one user-designated location
to another.
8.37. The user should have the choice of displaying the recommended route of travel either as textual travel directions, a
graphic map, and/or voice directions.
8.38. The system should display the location of route blocks and impediments on the map by using different symbols to
represent common categories of impediments.
8.39. The system should have the ability to center the map display using a visual indicator (icon, cross-hair, etc.) on:
8.39.1. Current vehicle location (AVL)
8.39.2. Dispatch location
8.39.3. Specified Geographic Area
8.39.4. Location of cursor when the screen or pad is touched.
SERIAL 11086-RFP
214
215
216
217
218
219
220
221
222
223
8.40. Users should have the ability to view their unit centered on the map as it changes position on the map, while the map
remains in a static north/south orientation or,
8.41. Users should have the ability to view their unit centered on the map as it moves on the map, while the map orientation
moves in the same direction as the user's unit.
8.42. The map should display a static North icon.
8.43. The system should present the user with a pick list of agency-defined map layers to utilize when conducting a mapping
query.
8.44. The system should allow the user to select and utilize multiple map layers simultaneously.
8.45. The system should allow the user to select an area by drawing a polygon around a selected area to initiate a user-defined
search.
8.46. The system should have the ability to create temporary GEO zones to identify a control area for a dispatcher (Users
should be able to draw a box or circle around a zone to take control of that area on a specific large scale event).
8.47. When the user applies a mouse click, presses the touch pad, or touches the MDC screen to the icon representing a data
point, the system should immediately link to and display the detailed information available for that location.
8.48. The system should have the capability for Location of Interest and Premise History files that meet user-definable criteria
(location where serious assaults have occurred, with user-definable time parameters) as well as addresses that are listed to unserved arrest warrants, to appear on the MDC map display as user-defined icons when their locations are within the viewable area of
the MDC.
8.49. When the user "hovers" their cursor over or touches screen the icon representing the address presenting a safety risk, a
small dialogue box should appear which displays a user-definable summary of the safety risk including date, location, and risk
information, and/or summary warrant information.
224
8.50. The system should provide the ability to draw a radius around a location (either a circle, or freehand polygon), and define
a specific user-defined radius, in feet and by tenths of a mile, to define an area for evacuation. Once an area has been defined a
printable list of all addresses within that area will be presented on the screen.
225
8.51. The system should allow users to mouse click, touch pad, or screen touch any two points on the map to produce a visual
display of the distance between the two points, by agency definable measurements (feet, miles, gradation of a mile [10th, etc.].
8.52. The system should provide an automated function that depicts on the users mobile map display any number of agencydefinable, user-selectable data elements based on their proximity to the users reported location, e.g.: hospitals.
8.53. The system should support orthophoto (aerial photographs) data layers on full function ECC CAD terminals and MDCs.
8.54. The system should be capable of geographically viewing the distribution of resources by unit type, based on AVL data.
8.55. Users should be able to perform a unit or event query from the map.
8.56. Users should be able to display the location of pending and active incidents on the map.
8.57. Users should have the ability to limit the MDC map to only display a subset of pending and active incidents (e.g., only
Animal Control, Code Enforcement or County calls).
8.58. The MDC map should be able to display the location of all “logged-in” units based on their AVL coordinates.
8.59. The user should be able to filter the display of logged-in units that appear on their map. Being able to see only the units on
Priority A calls for example
226
227
228
229
230
231
232
233
SERIAL 11086-RFP
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
8.60. The AVL map display on MDCs should be able to show:
8.60.1. The vehicle location at all times. The display should be centered on the vehicles location.
8.60.2. All units assigned to the call to which the vehicle is currently assigned.
8.60.3. The call location to which the vehicle is assigned.
8.61. An authorized user should be able to view all active County events and caller locations, via different symbols and
"renders" that the system administrator may configure for the system
8.62. The system should provide the capability to utilize the ECC map on the MDC or create an MDC specific map if desired.
9. TACTICAL INFORMATION DISPLAY
9.1. The system should include a configurable application that stores and displays location based information such as building
floor plans and tactical pre-plan information.
9.2. The display of information should be linked to GIS map display.
9.3. The display parameters should provide for multiple layers of information based on agency parameters. For example,
certain information is important for first-in field units and is grouped together while command units require additional details for
strategic planning.
9.4. The tactical information display should include graphics and text.
10. AUTOMATIC VEHICLE LOCATOR (AVL)
10.1. The County will be dispatching units for other agencies that are not MDC and/or AVL equipped. Vendors are asked to
describe the how the last known location of these units can be displayed on the map.
10.2. The AVL system should utilize GIS data to provide real-time vehicle location to the MDCs.
10.3. Offeror's shall describe the accuracy of their real-time vehicle location information, i.e., +/- at x% of the time.
10.4. The polling rate should be modified based on the priority of the call for service.
10.5. AVL coordinates should be provided to CAD by each unit's GPS receiver at an agency-specified time interval for each
logged-in mobile unit.
10.6. The system administrator for the MDCs should be able to modify the time interval and other AVL coordinate transmittal
criteria.
10.7. The AVL server should capture AVL information, organized by vehicle.
10.8. Tools should be provided in the MDC system to extract, analyze, and report this information by one or more units or by
groups of units.
10.9. Utilizing AVL, the system should create a log file of each unit's movement by street, direction, and speed of travel that can
be utilized to prepare unit history reports. The County would prefer to have the capability to disable this feature if so desired.
10.10. Authorized users should be able to view this information on a CAD/Workstation or MDC map by dynamically “playing
back” the information contained in the AVL log file.
10.11. The system should provide standard mapping functions such as pan, zoom, annotate, and print for the AVL track
display.
10.12. When an AVL equipped unit traverses through agency-defined areas (Districts, Field Areas, etc.) as identified in the
geographic system, the corresponding (system administrator defined) response area should automatically be updated in the CAD
system.
SERIAL 11086-RFP
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
10.13. Any change in a unit's field area should be transmitted to the unit's MDC to update the "Unit Status Display".
10.14. Each AVL transmission should include:
10.14.1. Mobile unit ID
10.14.2. X, Y, and Z (elevation) coordinates (please specify the level of accuracy)
10.14.3. Vehicle Travel direction
10.14.4. Vehicle Travel speed
10.15. The offeror shall describe their system's satellite fix time from a warm start, a cold start, and their reacquisition time. A fix
shall be considered when the receiver is capable of reporting a position from at least three satellites.
10.16. In any case where communication with the GPS receiver is lost for an agency defined period, the system should be
capable of providing an automatic agency defined notification to agency defined supervisor and or dispatchers console and the unit
involved.
10.17. The system administrator should be able to configure event type and unit geographical proximity algorithms.
11. CONFIGURABLE AVL SERVER REFRESH OPTIONS
11.1. The AVL system should provide for failover processing rules for AVL functions during periods of reduced bandwidth, and:
11.1.1. Dispatcher and Supervisor manual polling
11.1.2. Location information transmitted with status changes
11.1.3. Reduced auto poll parameters for degraded bandwidth
11.1.4. Each mobile unit's location information display should come from their GPS server in real time, not from the CAD
server.
11.2. The County is requesting that vendors comment on the feasibility of tracking air units (fixed wing and helicopter) and
watercraft using AVL.
12. CLOSEST UNIT DISPATCH AND RECOMMENDED ROUTING (CUDRR)
12.1. The below capabilities apply to all Full-Function CAD terminals and MDC's.
12.2. The system should have the ability to:
12.2.1. Utilize a unit's AVL-reported location when making unit recommendations, and
12.2.2. Provide recommended route of travel by the street network.
12.2.3. Determining routes based on least travel time.
12.2.4. Determining routes based on least travel distance.
12.2.5. Automatically determine and display a route of travel from a unit's AVL reported location to an event location utilizing
the street network.
12.2.6. Determine and display a route of travel for a unit from one user-designated location to another.
12.2.7. Determine and display a route of travel for a unit from its present AVL reported location to any user-designated
location.
12.2.8. Provide voice directions, distance to next turn, and street names to events. Price as optional.
12.3. The system should be capable of determining routes based on least travel time.
12.4. The system should be capable of determining routes based on least travel distance.
SERIAL 11086-RFP
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
12.5. The user should have the choice of displaying the recommended route of travel either as textual travel directions and as a
graphic map.
12.6. What types of geographical information is used to determine the closest unit recommendations?
12.7. What types of geographical information is used to determine the routing?
12.8. The unit recommendation and routing functions should consider any street closures that have been entered to ensure that
routings are based on least travel time while avoiding impediments.
12.9. The system should include the ability for a user to dynamically insert a closure or impediment on any existing street
segment, intersection, bridge, tunnel, causeway, wharf, pier, interstate highway, or highway ramp, etc.. For example, if a bridge is
closed for repairs the authorized user should be able to enter the impediment into the system.
12.10. Whenever a closure or impediment is inserted per the above requirement, the system should be capable of sending
automatic notification(s) to user-defined units and/or groups.
12.11. Whenever a closure or impediment is inserted per the above requirement, the system should be capable of sending
automatic updates to all map equipped mobile assets so that the impediment is considered when utilizing ad-hoc routing.
12.12. The system should provide a single keystroke to accept the unit recommendations.
13. QUERY AND REPORTING
13.1. MCSO Departments often have to create reports quickly that are very unique to a present situation and not addressed by
any of the pre-programmed reports that come with most systems. A good example would be a request to create a report by
geographic regions showing crimes perpetrated by ethnic classifications of the victims and suspects in descending order by number
of crimes. Vendors are being asked to describe how, and if, their systems are designed/optimized to produce reports of this type.
13.2. The CAD and Mobile systems should have the capability to interface with and inquire into:
13.2.1. RMS
13.2.2. NCIC
13.2.3. ACJIS
13.2.4. any other internal databases interfaced to the system, and
14. Intercommunication
14.1. All external communication with ACJIS will occur via WebSphere MQ. Separate queues will be provided for input and
output. Input and output will conform to AZ CJIS interface specifications.
14.2. On the MDC:
14.2.1. The tag number field will be the only field requiring entry when running a Arizona tag.
14.2.2. The drop-down states field will include all states, (including Mexico and Canadian territories), and U.S. territories.
14.3. The system should restrict queries that result in large volumes of data by:
14.3.1. Warning of the numbers of records and amount of data found
14.3.2. Prompting the user to continue or discontinue the query
14.3.3. Permit the viewing of a specified number of records and data as set by the System Administrator.
14.4. The system should have the ability to sort query results chronologically or by priority with an option for descending or
ascending order.
14.5. The system should provide pre-defined agency-configurable query forms to include:
SERIAL 11086-RFP
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
14.5.1. Log-on/log-off status
14.5.2. Vehicle queries, including boats
14.5.3. Gun queries
14.5.4. Query by license plate number
14.5.5. Query by VIN number
14.5.6. Person query (to include searching with wild cards, where allowed, e.g.. Age range),
14.5.7. Wanted check by name
14.5.8. Driver transcript query by name
14.5.9. Driver transcript query by operator's license number
14.5.10. Local Warrant files
14.5.11. Driver operator's license by name
14.5.12. Driver operator's license by operator's license number
14.5.13. Criminal History
14.5.14. All vehicles listed to an individual
14.5.15. Premise information query, and
14.5.16. All other agency-definable forms as defined by the County
14.5.17. The County is requesting the capability to create additional query forms without vendor assistance,
14.6. The system should allow queries to be grouped and run automatically based upon event type. For example, when a
traffic stop is entered the system should run the license plate as soon as it is entered, run a name check on the registered owner,
and then return either a mug photo or MVD photo of the registered owner. If the driver is not the registered owner, the system
should run a name check on the driver and the two photo inquiries (mug and MVD photo).
331
14.6.1. The system will support displaying AZ MVD information and a front-facing image driver’s license photo in the NLETS
CANDLE XML format (See Attachment XX). Driver’s license photos will be sent as a base 64-encoded string and will be rendered in
the CAD interface.
332
333
14.7. Maricopa County Mug Shots:
14.7.1. The RMS system will provide an asynchronous query and display mechanism to query Maricopa County mug shots
by the following combinations:
14.7.1.1. Name and date of birth
14.7.1.2. Maricopa County booking number
14.8. This request and the subsequent response shall be sent via WebSphere MQ and will conform to the AZ CJIS messaging
protocol.
14.9. When an inquiry is automatically initiated due to a field being entered on a call entry mask, the resulting replies should
have the capability of being forwarded to the call taker and to the units on, or responding to, the event, as configured by the County.
14.10. The system should provide the ability to display and print an event record upon command, based on a search of the file.
When an event is recalled, it appears with all event record information displayed. The County will develop report format criteria with
the offeror during application development.
334
335
336
337
338
SERIAL 11086-RFP
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
14.11. It should be possible to search and retrieve Event Records with full, partial or data in multiple fields utilizing any
combination, but not limited to, the following user-defined criteria:
14.11.1. Event Number
14.11.2. Address
14.11.3. Commonplace Name
14.11.4. Any or all Units assigned
14.11.5. EIN of responding officer
14.11.6. Name of responding officer
14.11.7. Date Range
14.11.8. Time Range
14.11.9. Address range
14.11.10. Final Disposition
14.11.11. Time of event Creation
14.11.12. Event Type
14.11.13. Event Priority
14.11.14. Event Urgency Code
14.11.15. Disposition
14.11.16. Case/Event Number
14.11.17. Any telephone number recorded in the event
14.11.18. Any license plate number recorded in the event
14.11.19. Any name recorded in the event
14.11.20. District
14.11.21. Field Area (FA)
14.11.22. EIN of entering user
14.11.23. EIN of dispatching user
14.11.24. Terminal ID for entering workstation
14.11.25. By attached ANI/ALI data
14.11.26. By key words search in remarks area
14.12. All of the above fields should be capable of being searched upon from within the CAD client by personnel as authorized
by the System Administrator.
14.13. It should be possible to query Unit History detail by all available data fields, including but not limited to:
14.13.1. Unit Number
14.13.2. Event Number
14.13.3. Date and time range
14.13.4. Location
14.13.5. Vehicle number
SERIAL 11086-RFP
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
14.13.6. Quarter Section Map (Grid)
14.13.7. District
14.13.8. Patrol Area
14.14. Through the standard report menu personnel should be able to receive a Unit History Log. This user-definable report:
14.14.1. Contains a log of activities by shift(s), officer(s), unit assignment(s), Patrol Area(s), District(s), and/or agency for a
given date span,
14.14.2. Shows all activities to which given units or personnel have responded, and
14.14.3. Is particularly useful in reviewing an employee or unit's work for a given period of time. The user defines the
parameters of the report.
14.15. The system should allow:
14.15.1. Retrieval of the history of a selected employee, including all times which can be sorted by the user.
14.15.2. Retrieval of the history of a selected unit, including all times which can be sorted by the user.
14.15.3. User defined queries of any data associated with an event, unit, or employee for any given date and/or time.
14.15.4. The preparation of an ad-hoc report that illustrates the unit and event history of any patrol shift or District by userdefined dates and times.
14.16. The system should also provide the ability to prepare Unit History Reports for ECC personnel, i.e., calltakers and
dispatchers.
14.17. When MCSO patrol personnel are not handling a dispatched assignment they utilize "In-service" discretionary time for
directed activities. The system should provide the capability for authorized users to prepare user-definable reports that illustrate in
statistical and graphical terms each period of "In-service" time that was available for any officer/unit during any user-definable date
and time period. The system should be capable of reporting this data as a sum (the total amount of "In-service" time available for any
officer/unit for a given tour of duty) and as a summary representation of the "blocks" or, "In-service" time that was available between
assignments (e.g., during any given tour of duty how many blocks of "In-service" time were available and what was their duration [for
each block and as an average of the blocks for the tour of duty].
14.18. The system should provide the capability to prepare the aforementioned report by a single unit/officer and any number of
units/officers for a user-definable time and date range.
14.19. The system should be capable of preparing user-definable agency specific standard reports for emergency calls, nonemergency calls, and both combined, including but not limited to:
14.19.1. Number of events by event type and/or time of day
14.19.2. Number of events by event type and/or day of week
14.19.3. Number of events by day of week and/or time of day
14.19.4. Number of events by event type and/or shift
14.2. Reports should be capable of being generated based on data such as but not limited to (reports may be based on
multiple fields):
14.20.1. Date
14.20.2. Time of day
14.20.3. Day of week
SERIAL 11086-RFP
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
14.20.4. Event Type
14.20.5. Priority
14.20.6. Urgency
14.20.7. Group
14.20.8. District
14.20.9. Patrol Area
14.20.10. Terminal ID for entering workstation
14.20.11. EIN of entering user
14.20.12. EIN of dispatching user
14.20.13. Talk group
14.20.14. Response time
14.20.15. Average response time
14.20.16. Disposition code applied
14.20.17. The user should have the capability to include or exclude disposition notes.
14.20.18. Urgency
14.20.19. Call time (from entry to completion (closed))
14.20.20. Average call time (from entry to completion (closed))
14.20.21. Average response time to events by reporting area by event type and time of day
14.20.22. Average response time to events by reporting area by event type and day of week
14.20.23. Average response time to events by reporting area by event type and shift (from time a call is received to dispatch,
and time of dispatch to first unit on the scene, and time of call received to arrival of first unit on the scene).
14.20.24. Average time to dispatch for all call types based on priority.
10.20.25. Average time to dispatch from the first CAD time stamp (when the call is accepted at the call taker position) by
Agency
14.20.26. Total person hours expended on events by call type (burglar alarms, disorderly conduct, etc.) by time of day, day
of week, etc., and
14.20.27. The sum of total staffing hours that were available by agency, by rank/position and all other available CAD criteria.
14.20.28. Elapsed time expended processing calls, from time the ANI/ALI appears on the call taker screen to the time:
14.20.29. The call is concluded (talk-time)
14.20.30. The call taker sends the initial event information to the dispatcher
14.20.31. The call is concluded and the time the event information is sent to the dispatcher (wrap-up time)
14.20.32. The event is opened at the designated agency dispatch position
14.20.33. The event is dispatched
14.21. The system should track and report on average times to dispatch for all event types.
14.22. The system should be able to report total staff hours expended on specific events/incident types and prepare summary
and ad-hoc reports based on user-definable parameters such as event type(s), date and time ranges, etc.
SERIAL 11086-RFP
429
430
431
14.23. This report should be configurable and sortable by event type.
14.24. This report is in addition to the capture and reporting of individual unit dispatch and arrival times.
14.25. The system administrator should be able to easily create new event codes. For example, it will be possible to create an
event code which users can apply to all events in which County are engaged in flood relief activities. In this example, authorized
users will be able to search by the event code to determine the total number of staff-hours expended on flood relief activities by a
user-definable date and time range.
432
433
434
14.26. The appearance and layout of all reports and queries should be user-definable and,
14.26.1. The user should be able to save the report format for future use
14.27. The reports should be able to be sent to a printer selected by the user performing the search/report or to a userdefinable default printer.
14.28. The reports should be able to be saved to a format that permits the archiving and e-mailing of the report as an
attachment that can be viewed by a Microsoft Office application (e.g., WORD, EXCEL, PowerPoint).
14.29. The system should be capable of posting to a web page, all reports (statistical, graphical, etc.) resulting from CAD and
RMS queries.
14.30. The system should be capable of preparing a user-definable report which illustrates (textually and graphically/spatially)
for each event, the location of each responding unit at the time they received the dispatched event. This information should be
logged as part of each event history.
435
436
437
438
14.31. The system should be capable of preparing a user-definable report which illustrates and compares 1) the travel time
expended for each responding unit from time of dispatch to time of arrival versus 2) the CUFRR estimated time of travel for each
responding unit from time of dispatch to time of arrival on the scene.
439
14.32. The system should permit the preparation of user-definable year-end/12-month CAD management reports based on any
of the aforementioned report criteria. Such report production will require a minimum of one year of CAD data.
14.33. The system should also provide a subsystem where a user can query the system for a certain type of skill set (i.e. a
person who speaks Spanish and has CPR training), the system should then display contact information (phone numbers, e-mail
address, etc.).
440
441
442
443
444
445
446
447
14.34. This ready-reference feature is an index that is accessed via a command containing items such as contacts and phone
numbers. It is typically utilized for frequently accessed phone lists.
14.35. The system should provide the full complement of NCIC, NLETS and ACJIS update and query transactions. Entry
masks should be included for the most commonly used transactions (i.e. Criminal history, Drivers License, Vehicle Want and
Registration, Firearm, Boats and messaging to and from other ORI identified agencies. Vendors shall specify what entry masks
come with their system and the cost to acquire additional masks if so desired. The capability to enter queries in a string format
(expert mode) must be made available for all transactions.
15. NLETS Transactions
15.1. System should provide a minimum of the following NLETS transactions:
15.1.1. MKE
Description
15.1.2. ACQ/AVQ
NLETS Commercial Carrier Query
15.1.3. AVQ
NLETS Commercial Vehicle Query
SERIAL 11086-RFP
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
15.1.4. CWQ
Interstate Concealed Weapons Permit Query
15.1.5. DQ
Interstate Driver’s License Query
15.1.6. IPQ/FPQ
Interpol Wanted Persons
15.1.7. ITQ/FTQ
Interpol Stolen Travel Documents
15.1.8. IVQ/FVQ
Interpol Stolen Vehicles
15.1.9. KQ
Interstate Driver’s License History
15.1.10. RQ
Interstate Vehicle Registration Query
15.1.11. VQ
Canadian Stolen Vehicle Query
15.1.12. WQ
Canadian Wanted Person Query
15.1.13. XQ
Canadian Vehicle Registration Query
16. MOBILE COMPUTER SPECIFIC
16.1. The system administrator should be able to define the series of queries and reports that will be available to MDCequipped vehicles to extract emergency event, and unit, information from the CAD system.
16.2. Vendor shall explain when their system will include the Alarm Notifications covered by CSAA-APCO ANSI 2.101.1-2008.
16.3. The system should have the ability to record remote system inquiries by MDCs and include the information as part of the
CAD unit and event (if the unit is assigned) history.
16.4. Information being displayed on the monitor should never be pushed off the monitor by newly arriving information.
17. LOCATING USERS ON THE CAD SYSTEM
17.1. The system should allow a search of all users that are either logged-on/rostered/associated with a unit using any of the
following criteria:
17.1.1. Last name of the user
17.1.2. First name of the user
17.1.3. EIN of the user (employee identification number)
17.1.4. By position (workstation ID or MDC ID)
17.1.5. By group of positions (groups will be created by the system administrator)
17.2. When a match(s) is found the system should provide full name and rank of the user and the terminal ID or Unit ID.
17.3. Searches for users logged on to workstations or MDCs should be done using the same method.
17.4. When multiple users are logged on to a single terminal or MDC the system search should include all users logged on.
17.5. Searches should return a list of all potential matches to the search criteria and clearly state if the user is logged on or not
logged on.
17.6. MCSO is requesting the capability to enter a single command that will display the locations of all units currently assigned
to a call/event. This is needed to help manage perimeter deployments If a unit has an assigned position it would be displayed
alongside its present actual location.
18. CALL RECEIPT/EVENT CREATION
18.1. A primary goal of the system is to minimize the number of operator actions required to complete a transaction.
18.2. The system should have the ability to create events from a:
SERIAL 11086-RFP
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
18.2.1.
CAD Workstation
18.2.2.
Mobile Data Computer (MDC)
18.3. When a call for service is received the system should allow the operator to press a function key, or on-screen command
button or issue a command to display a blank form for entering new events.
18.4. The system should allow the user to tab between the fields and easily return to the original field.
18.5. The ANI/ALI information should be made available through the event form.
18.6. The call entry and dispatch screen should be fully configurable by the System administrator.
18.7. The system should allow the System Administrator to assign functions/commands to the function keys. For example F2
downloads ALI info to an event mask, F5 opens a supplemental form for the last event entered at that workstation.
18.8. Once a call for service is sent to the dispatch position information can be changed/supplemented, but the system should
retain records showing the original data and tracking (time stamps and user identity) all subsequent changes.
18.9. All event entry and processing and dispatch functions should also be capable of being conducted utilizing a command
line.
18.10. The system should have the capability to add information to an event or to a unit assigned to an even/call without having
to take the time to pull up the event on the monitor. This multitasking aid is needed at both the Call taker and Dispatcher positions.
This capability is usually used for entering narrative or miscellaneous comments. Please describe any additional fields that could be
entered in this manner, if any.
19. TDD
19.1. The CAD system should import TDD information (ANI/ALI and narrative data) from the VIPER system into the event entry
form as defined by the agency.
19.2. The CAD system should assign unique numbers to each TDD communication.
19.3. If the TDD communication is related to event entry the event should reflect the unique TDD number
19.4. The user should have the ability to choose to include the text of the TDD conversation in a related event, regardless of the
TDD call being processed on the CAD system or Positron Power 911 VIPER system.
19.5. The system should provide the same functionality available through other call receipt and event entry/processing
methodologies in this document.
19.6. The system should comply with Americans with Disabilities Act (ADA) Title II, Part IV, and Paragraph 35.162.
20. EVENT FORM
20.1. The system should allow the user to save a partially filled out event form
20.2. The system should allow the following agency-configurable fields on the event entry form, to include at a minimum;
20.2.1. Location of the event (address for landline calls, X,Y coordinates for wireless)
20.2.2. Supplemental response location information (e.g. building name, in front of, along side, in the alley)
20.2.3. Building/Structure Type (commercial, garden/high rise apartment, house, school, etc.)
20.2.4. Building Number
20.2.5. Apartment or Suite Number
20.2.6. Caller name
20.2.7. Caller telephone number
SERIAL 11086-RFP
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
20.2.8. Alternate address
20.2.9. Alternate telephone number
20.2.10. Remarks section
20.2.11. Talk group assigned
20.2.12. Disposition
20.3. The system should allow the user to save a partially filled out event form
20.4. The system should allow the following agency-configurable fields on the event entry form, to include at a minimum;
20.5. Call takers want to key information in the order it is being spoken without being restrained to any set entry order.
21. LOCATION ENTRY
21.1. ADDRESS VERIFICATION AND VALIDATION
21.1.1. If the event is occurring at the ALI-reported location the call taker should not be required to manually re-enter the
location data in any other field or subsequent form(s).
21.1.2. If the event is not occurring at the ALI-reported location the system should allow the call taker to import the ANI/ALI
information into a supplemental address field.
21.1.3. The system should also allow the transfer of the ANI information from the Call ID controller with a single keystroke or
operator action if the new call is being received on a seven digit telephone line
21.1.4. The address verification process should automatically occur when the user tabs out or otherwise exits from the
address field.
21.1.5. The system should automatically verify addresses that are the result of the ANI/ALI download.
21.1.6. The system should be capable of geo-verifying addresses via the MSAG.
21.1.7. The system should be capable of geo-verifying addresses from other jurisdictions using the centerline.
21.1.8. The system should be capable of recognizing surrounding (different) municipalities.
21.1.9. Upon geo-verification, the event form should display the zip code and the jurisdiction
21.1.10. If the entered location is invalid the system should utilize a “Soundex” or phonetic, algorithm to develop and present
a list of locations that most closely match the one entered by the user.
21.1.11. The "Soundex" should be configurable by the System Administrator
21.1.12. The user should have the opportunity to choose one of the displayed records as the event location:
21.1.13. If more than one page of possible matches is displayed the system should allow the user to page forward and
backward through the pages in order to select the correct record.
21.1.14. While the event is active, any location choices offered to the user should be available for review.
21.1.15. The system should provide the ability to cross reference with number spelled out i.e. "7" or "seven".
21.1.16. The system should provide the ability to discriminate between the same street names in two different municipalities.
21.1.17. If a valid street name with an invalid address number is entered the system should present a list of all valid address
ranges for the given street.
21.1.18. If a user enters a street which has more than one record due to a directional (N, S, E, and W) or a suffix (St., Blvd.,
Rd., etc.) the system should prompt the user to select the correct entry.
SERIAL 11086-RFP
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
21.1.19. If a location match is not found on the Geofile, the user can choose to by-pass verification and force the location
into the system.
21.1.20. If a user forces a non-verified location, and the call has been closed without having been corrected, then the
entered address information should go to a verification file for review by the GIS administrator for addition or deletion from the
system and automatically generate an e-mail notification to the system administrator.
21.1.21. Upon address validation, the address zip code should become part of and be associated with the event history.
21.1.22. The system should be sufficiently scalable to include geo-file information from surrounding jurisdictions.
21.2. COMMONPLACE NAMES
21.2.1. The system should accept locations entered as commonplaces (e.g. McDonald’s, Government Center, etc.).
21.2.2. When a commonplace name is entered the system should respond by entering the verified address into the location
field along with the commonplace name.
21.2.3. When a non-unique (Safeway) commonplace name is entered the system should display all potential matches along
with their addresses.
21.2.4. The system should allow for multiple common places to be associated with a single address.
21.2.5. The system should have the ability to identify and process commonplace names that start with a number (i.e. 7-11).
21.2.6. Once an event location is validated, the system should automatically identify and display user-defined location
information, including but not limited common-place name information such as:
21.2.6.1. Street address
21.2.6.2. Low address cross street
21.2.6.3. High address cross street
21.2.6.4. Sub-division/business park name
21.2.6.5. National Grid Coordinates
21.2.6.6. X-Y-Z latitude / longitude/altitude
21.2.6.7. District
21.2.6.8. Patrol Area
21.2.7. When a partial common place name is entered a pick list should appear showing the possible common place
locations. For example, entering "Mc" should pull up all of the McDonalds.
21.2.8. When a partial common place name is entered the user should be able to utilize a "wildcard" search in association
with a street name so the system can provide a pick list showing the possible common place locations with associated addresses..
21.2.9. The vendor should describe their method for parsing lengthy street addresses and,
21.2.10. The vendor should also describe all field length limitations.
21.3. INTERSECTIONS
21.3.1. The system should accept locations entered as intersections with the street names or route numbers in any order
and the street names separated by an agency-defined character.
21.3.2. If either street name or route number is invalid the system should utilize a “Soundex” algorithm to develop and
present a list of intersections which most closely match the valid street name or route number.
21.3.3. The system should provide a method for users to display all streets that intersect with a specific street
SERIAL 11086-RFP
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
21.3.4. Once an event location is validated, the system should automatically identify and display user-defined location
information, including but not limited to the following intersection information:
21.3.4.1. For validated intersections:
21.3.4.2. Sub-division/business park name
21.3.4.3. X-Y-Z latitude / longitude/latitude
21.3.4.4. Hundred block of each street
21.3.4.5. District
21.3.4.6. Patrol Area
21.4. ALIASING
21.4.1. The system should allow multiple aliases for each official street name,
21.4.1.1. commonplace
21.4.1.2. intersection
21.4.2. The system should allow for multiple street names to be associated with a single alias.
21.5. 100 BLOCKS
21.5.1. The system should accept locations entered as street addresses (e.g. 125 North Main Street) utilizing points that
have been associated with parcels (e.g. tax map).
21.5.2. The user should have the option of entering the hundred block of each street for address verification.
21.5.3. The system should provide a hundred block range for specific street when requested by the user
21.5.4. Once an event location is validated, the system should automatically identify and display user-defined location
information, including information such as:
21.5.4.1. Low address cross street
21.5.4.2. High address cross street
21.5.4.3. Sub-division/business park name
21.5.4.4. Map grid
21.5.4.5. X-Y-Z latitude / longitude/altitude
21.5.4.6. Mile Posts
21.5.4.7. District
21.5.4.8. Patrol Area
21.5.5. The system should allow for a street name to be entered without a block range and return all possible ranges and
locations to be used to query the caller as to which is the correct choice.
21.5.6. The system should allow for route numbers to be used with exact addresses.
21.5.7. Communications needs to maintain a listing of street segments between intersections and the 100 block ranges for
each segment. This list should be searchable by the offeror's system, by street name, street name and 100 block, and intersecting
points. Partial spelling or wild card queries of a street name should return a pick list of possible matches from which to select.
21.6. WIRELESS CALLS
SERIAL 11086-RFP
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
21.6.1. Through a single key stroke the CAD system should request a retransmission of the ALI data from the phone system.
The data received should populate in the CAD system updating the X-Y coordinates in the mapping system.
21.6.2. Once an event location is validated, the system should automatically identify and display user-defined location
information, including but not limited to the following information:
21.6.2.1. Wireless 9-1-1 Phase I and II:
21.6.2.2. Street address of tower (Phase I and II)
21.6.2.3. Automatic map display with tower sector highlighted (Phase I), in which the map display is easily identifiable as
a Phase 1 call.
21.6.2.4. X-Y latitude / longitude automatic map display including radius (Phase II)
21.6.2.5. Closest street address (Phase II)
21.6.2.6. Confidence factor for location information (Phase II)
21.6.2.7. Low address cross street (Phase II)
21.6.2.8. High address cross street (Phase II)
21.6.2.9. Sub-division/business park name (Phase II)
21.6.2.10. Map grid
21.6.2.11. County District
21.6.2.12. Patrol Area
21.7. CATALOGUED ALARMS
21.7.1. The system should allow for a cataloged number to be entered into the location line of the event form (All alarm
registrations need to post to this file).
21.7.2. The user can enter the cataloged number and the system should display the address that corresponds to the
catalogued alarm number.
21.7.3. The system should automatically place the appropriate information from the cataloged alarm file into the appropriate
fields on the event form.
21.7.4. The catalogued alarm file should accept information from an external alarms interface (Cry Wolf for example) and
should accept manual entries for other alarm types. This is assuming that an external alarms interface is being recommended for
automating false alarms handling.
608
609
610
611
21.7.5. The file should also be able to contain school alarm and County alarm data.
21.7.6. The file should also be able to contain phone monitor alarm data.
22. LOCATION OF INTEREST INFORMATION
22.1. The CAD should search for all location-specific information within the CAD environment including local and externallylinked databases and alert operators of any existing location information. These searches should take place in background
processing. The type of alert should be based on the priority established for the information category.
612
22.2. All information returned for validated locations should become a part of the event record and displayed/available to
subsequent users reviewing the event record.
22.3. The location information alert should be configurable by the system administrator (e.g. message box, change of indicator
button color, etc.).
613
SERIAL 11086-RFP
614
615
22.4. The system should be able to create agency defined categories to all location-based information (internal and external)
and assign agency defined priorities to these categories.
22.5. Location information should be associated with the verified location. Information such as building number, apartment
number, commonplace, and suite number etc. is a subsidiary attribute to the address and does not effect the display of location
information returned.
616
22.6. Users should be able to conduct a radius search for locations of interest within a user defined area via the map function or
a system administrator definable radius in feet and other distance measurements. For example, the system should allow users to
draw polygon on the map which generates a system administrator defined and configurable display of all addresses containing
location of interest information, for viewing by the user. Another example is that the user should be able to search for and retrieve all
location of interest information within 1/4 mile of a user defined address. The vendor shall explain their approach to this functionality.
617
22.7. If a hazard notice is set for a location and units are being dispatched to the location, notices should be sent to the
responding units, their supervisor, and the dispatch consoles. This feature should be System Administrator configurable.
22.7.1. LOCATION HISTORY
22.7.1.1. After the address is validated but before the call is entered, the system should notify the user of all available
hazard and premise information.
22.7.1.2. Location History data should be retained for a system administrator defined period of time.
22.7.1.3. The sort order of the location history should be configurable by the system administrator (descending or
ascending)
22.7.1.4. The Location History file should record all events and the system administrator should be able to define the
data about the event that should display to the user.
22.7.1.5. The system should automatically search for prior event history at a call location and notify the user if there have
been prior events.
22.7.1.6. The system should notify the user that Location History Information is available upon entry of the event location
and be displayed via system administrator defined parameters.
22.7.1.7. All prior event activity on file for a location contained in the geo-file should be available for display upon request
(system administrator defined period of time).
22.7.1.8. A system administrator definable (text flag, button, etc.) alert should be displayed for recent prior events, which
can be sorted by the most recent date.
22.7.1.9. The system administrator should be able to define the types of Location History event data for display to the
dispatcher.
22.7.1.10. Data should include links to Operational Reports and Field Interview that were taken at the location.
22.7.1.11. The system administrator should be able to define the data fields displayed in location history display
22.7.1.12. In situations where a license plate number is tied to any of the reports at the event location, the call taker is to
be informed of the location and the identity of report(s) containing the plate number.
22.7.2. NEARBY EVENTS
22.7.2.1. Upon entry of a verified address the system should check for events occurring within an system administrator
radius of the verified address.
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
SERIAL 11086-RFP
633
634
635
636
637
22.7.2.2. The nearby events should be configurable to be agency specific or all events
22.7.2.3. The nearby event function should be the same setting as the duplicate detection process
22.7.2.4. The time frame for the nearby events should be configurable by the system administrator
22.7.3. GEO DATA
22.7.3.1. The proposed CAD system should support coordinate-based operations and should be fully integrated with the
system's Global Positioning Satellite (GPS) based Automatic Vehicle Location (AVL) and Automatic Vehicle Routing and Closest
Unit Recommendation (CUFRR) functionality.
638
22.7.3.2. System must have the ability to generate user-defined buffers using one of the following: defined coordinate
values, user defined location (mouse-click), or existing selectable feature(s). Buffers can then be utilized to identify any areas of
interest (as defined by user) contained within the perimeter of the created buffer.
639
22.7.3.3. System must allow for the GEOFILE to be managed/edited as a stand alone data table, however any changes
to the GEOFILE that were not generated via the GIS update process will require identification and notification to the GIS
Administrators to ensure appropriate modifications to the GIS Master Address table may be administered as necessary.
640
22.7.3.4. The system should have the ability to utilize County provided ESRI standards based geo-data into the CADs
geo-file.
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
22.7.3.5. The system should be sufficiently scalable to include geo-file information from surrounding jurisdictions.
22.7.3.6. The system should have the ability to import/load the map data from an ESRI ArcSDE (MS SQL) data format
as well as the ability to:
22.7.3.6.1. "Off- line” test new geofile updates for accuracy and errors, prior to updating the “live” CAD geo-file.
22.7.3.6.2. Update the “live” CAD system with the new geographic file without system downtime or degradation
22.7.3.6.3. Validate all location entries against a master geofile.
22.7.3.6.4. The Geo-File should have the ability to:
22.7.3.6.5. Validate the street name.
22.7.3.6.6. Resolve street/name ambiguities
22.7.3.7. All information returned for validated locations should become a part of the event record and
displayed/available to subsequent users reviewing the event record.
22.7.3.8. The system should permit the user to perform the location look-up immediately upon entry, or at any time
during the event entry process.
22.7.3.9. The system should provide a feature to perform location validations/geo-file look-ups exclusive of the event
creation process.
22.7.3.10. Once an event location is validated, the system should automatically identify and display any user-defined
location information, including but not limited to the following:
22.7.3.10.1. Jurisdiction
22.7.3.10.2. County Map Grid
22.7.3.10.3. Quarter Section Map (Grid)
22.7.3.10.4. Sub-census
22.7.3.10.5. X-Y-Z latitude / longitude/altitude
SERIAL 11086-RFP
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
22.7.3.10.6. Sub division / building complex/development name
22.7.3.10.7. Patrol District
22.7.3.10.8. Patrol Area
22.7.4. LOCATION OF INTEREST
22.7.4.1. The user should be alerted by a special identifier (color for example) when there is an urgent LOI at an address
at the time the address is validated.
22.7.4.2. Each LOI file entry should be able to be set to either an exact address match or a radius match.
22.7.4.3. Location of interest files should be able to be set to a specific time duration or non expiring.
22.7.4.4. When an LOI expires the system should generate a message to the LOI creator
22.7.4.5. The system should allow the user to search and report LOI, premise/hazard file information.
22.7.4.6. If a hazard notice is set for a location and units are being dispatched to the location, notices should be sent to
the responding units, their supervisor, and the dispatch consoles.
22.7.4.7. The officer responding to an onview incident and his or her dispacher should be informed of any premise alerts
at the onview location.
22.7.4.8. Hazard flags should be capable of being set to initiate notices when the hazard location is nearby (e.g. within
the same apartment building/floor, nearby house, etc.)
22.7.4.9. The system should provide the capability to match hazard location addresses to an external file (e.g. County
Water Billing File) and compare responsible party names. When a match on an address occurs the system should produce a report
of matching addresses with differing names that can be used to determine if hazard flags should be removed.
22.7.5. BUSINESS FILE
22.7.5.1. The system should be capable of maintaining a database of emergency contacts for building information
including but not limited to :
22.7.5.1.1. Business Address - Linked to existing GEOFILE (built via GIS Address Master tables)
22.7.5.1.2. Business name
22.7.5.1.3. Commonplace name (Giant, Carolinas, etc.)
22.7.5.1.4. Owner name
22.7.5.1.5. Owner contact information (24 hour telephone, pager number, and e-mail)
22.7.5.1.6. Business contact name
22.7.5.1.7. Business contact information (telephone, pager numbers, e-mail address)
22.7.5.1.8. Alarm company contact information
22.7.5.1.9. Access code(s)
22.7.5.1.10. Occupancy type.
22.7.5.1.11. Knox box location
22.7.5.2. The False Alarm Tracking database should share its content with the Business File if the vendor proposes
separate files.
23. EVENT TYPE
23.1. The system should provide for an agency-configurable event type table.
SERIAL 11086-RFP
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
23.2. The dispatcher or authorized user should be able to change the event type/priority/urgency code as required by the event.
As with all actions conducted on the proposed CAD, the activity should also be noted in the audit log.
23.2.1. SPECIAL INSTRUCTIONS AND/OR RESPONSE PLANS
23.2.1.1. The system should allow specific instructions to be associated with event types.
23.2.1.2. Once the event type are entered the special instructions should be available
23.2.1.3. The special instructions file can be text or for a drill down tree. In a tree format the responses should reflect in
the event history
23.2.1.4. The system should allow specific instructions for event addresses.
23.2.1.5. The special instructions that require a response should allow the automated inclusion of entered answers into
the event details.
23.2.2. EVENT URGENCY
23.2.2.1. The urgency code should be configurable by the system administrator. Typically the urgency codes will be I for
in progress, J for just occurred and R for Report only.
23.2.3. EVENT PRIORITY
23.2.3.1. The event priority is determined by the event type and associated urgency code and displayed as the default.
23.2.3.2. The user should be able to change the event type/priority/urgency code as required by the event. As with all
actions conducted on the proposed CAD, the activity is also noted in the audit log.
23.2.3.3. The system should ensure that any change made to the priority of an active event will result in the appropriate
changes to pending queues and status monitors and notification to the assigned dispatcher(s).
23.2.4. EVENT INFORMATION
23.2.4.1. The system should provide the capability to toggle between multiple active events with a minimum of
keystrokes.
23.2.4.2. The event entry form should contain the following minimum agency-definable fields:
23.2.4.2.1. Caller's Name
23.2.4.2.2. Caller's street address
23.2.4.2.3. Event location
23.2.4.2.4. Caller's County
23.2.4.2.5. Caller's current location (address/ intersection/commonplace/XY coordinates)
23.2.4.2.6. Caller's phone number
23.2.4.2.7. The phone field should display 4 separate sections and searchable on the database by each section or all
sections combined (3 digit area code, 3 digit exchange, 4 digit number, and up to four digit extension, preceded by an EXT)
23.2.4.2.8. Alternate Callback number
23.2.4.3. The phone field should display 4 separate sections and searchable on the database by each section or all
sections combined (3 digit area code, 3 digit exchange, 4 digit number, and up to four digit extension, preceded by an EXT)
23.2.4.3.1. Complainant contact
23.2.4.3.2. Complainant contact (yes, no or if needed)- configurable by the System Administrator
23.2.4.3.3. Call Source
SERIAL 11086-RFP
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
23.2.4.3.4. The call source (911, 7 digit, administrative line, wireless, etc.) should be configurable by the System
Administrator
23.2.4.4. Narrative:
23.2.4.4.1. The narrative field should not have any limit on the number of alphanumeric characters.
23.2.4.4.2. The narrative field should allow the use of special characters
23.2.4.4.3. Action Code field
23.2.4.5. The Sub-form of the Event mask should contain the following minimum agency-definable fields:
23.2.4.5.1.
Vehicle Description
23.2.4.5.2.
Suspect Description
23.2.4.5.3.
Article Description
23.2.4.6. The system should allow the user to perform an automatic check of local, state, and national databases upon
call taker entry of key data fields such as tag number, date of birth, name, etc.
23.2.4.7. If the event location is within a gated community the system needs to access and display the gate codes for the
dispatcher and for the officer(s) responding. Vendors are to explain in detail how they will meet this requirement.
23.2.5. DETAILS TO FOLLOW
23.2.5.1. The system should allow the user to route the event to a dispatcher with the minimum required fields and
invoke a system-definable indicator to the dispatcher that there is more information to follow. After this action is invoked, a
supplemental form should automatically appear on the screen.
23.2.5.2. The details to follow function should serve as supplemental form and allow users to continue to add narrative
information to the event. This process should only add and not change data.
23.2.6. ADVISED EVENTS
23.2.6.1. The system should provide the ability to record information from citizens about particular situations or events
that do not require the dispatching of any public safety resources. These incidents create event records that should be recorded and
retrievable from the system/event history files for later access and information analysis.
23.2.6.2. Advised events should have the capability to be routed to pre-defined workstations or groups.
23.2.6.3. An event type should be capable of being pre-determined as an advised event, with specific notification/routing
characteristics.
23.2.6.4. During event entry, the user should have the ability of designating any event as an advised event.
23.2.6.5. Advised events should be capable of creating agency definable notifications.
23.2.7. DIRECTED FIELD EVENT
23.2.7.1. Users should be able to enter an event that will not go to dispatch but will assign a unit and disposition and
close the event upon entry with the user designated disposition.
23.2.7.2. The directed field event should be included in the location history of an address
23.2.7.3. Directed patrol events should be associated with an employee ID. If the EIN is not found to be logged on upon
creation of the event the system should log the ID on and assign the paper then log the unit off. If the unit is found logged on the
event should be added to their unit history and the unit will remain logged on.
23.2.7.4. The directed patrol event identifier should be clear in the unit history to differentiate it from normal events
SERIAL 11086-RFP
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
23.2.8. CATCH UP
23.2.8.1. The system should provide the ability to continue event entry, processing, and dispatch operations as long as
power is available to the workstations. The offeror should describe their system's method for accomplishing this functionality.
23.2.8.2. In the alternative, the proposed application should allow any authorized user to add events after they have
already occurred. (Catch-up Mode)
23.2.8.3. The method for entering after-the-fact events should not vary from the normal event entry format although
additional narrative and event information should be required.
23.2.8.4. The system should enable the user to enter event and unit details on the same form.
23.2.8.5. The system should support "catch-up" entry of event data from full access CAD workstations for at least the
following situations:
23.2.8.6. An event that was active at the time the system failed
23.2.8.7. An event that was created and then closed while the system was inoperable due to a system failure
23.2.8.8. An event that was created during a system failure and is still active when the system is restored.
23.2.8.9. The event entry mask for catch-up events should minimally contain the following user-defined fields in which to
enter the following information:
23.2.8.9.1. The EIN and workstation position of the person receiving the call, and the EIN and workstation position of
the person who enters the event.
23.2.8.9.2. Units assigned
23.2.8.9.3. Status changes
23.2.8.9.4. Dispositions
23.2.8.9.5. All times associated with the event, and
23.2.8.9.6. All times associated with the units
23.2.8.9.7. Any other necessary user-defined fields.
23.2.8.10. The system should not generate unit recommendations for catch-up events.
23.2.8.11. The system should clearly indicate in the event record that the information was entered after the fact.
23.2.8.12. The system should allow the user to generate case numbers for events that may have occurred on a previous
date.
23.2.8.13. The system should have the ability to process both real-time and catch up events at the same workstation at
the same time.
23.2.8.14. The system should have the ability to enter, search for, and link multi-agency events that were entered by
different users after the system was restored.
23.2.9. SCHEDULED EVENT
23.2.9.1. The system should allow a user to schedule an event at a later time, date, by designator, EIN, etc. (Scheduled
Event).
23.2.9.2. The system should allow scheduled events to be scheduled to occur on a recurring basis.
SERIAL 11086-RFP
765
23.2.9.3. MCSO plans to use this capability to schedule individual officers to tasks like attending Court. Please explain
how this feature, if available, can be used for individual officer scheduling. If it cannot be used for this purpose, please offer an
alternative. An officer may notify Communications that they are unavailable to take calls for a period of time during their shift.
Communications needs a way making a note of this situation to avoid trying to dispatch the officer when unavailable. This capability
needs to be in addition to the unit status being set.
766
767
23.2.10. DUPLICATE CALL PROCESS
23.2.10.1. The duplicate event detection process should be configurable by the System Administrator to detect events
irrespective of agency source.
23.2.10.2. Duplicate event detection should be performed on all events entered into the system.
23.2.10.3. The system should notify the user of all possible duplicate events based on geographical proximity, event type
and/or other application configurable parameters as defined during the design of the system and system administrator configuration.
23.2.10.4. A summary line of user definable data for each possible duplicate event should be displayed on the user's
workstation.
23.2.10.5. If a duplicate event is detected, the prior event information should be displayed for review upon request,
before entering the current event.
23.2.10.6. During event entry, the user should be notified of any active or recently closed events near the one being
entered based on user-defined parameters.
23.2.10.7. At a minimum, the system should provide the user with the following details about events which have been
flagged as potential duplicate events:
23.2.10.7.1. The exact location of the event
23.2.10.7.2. The type of event
23.2.10.7.3. The status of the event
23.2.10.7.4. The time the event was initiated
23.2.10.7.5. The unit(s) assigned, if any.
23.2.10.7.6. Event number
23.2.10.8. The system should allow the user to create a new event if it is determined that the events are not duplicates,
or exit back to the event entry form.
23.2.10.9. The system should allow the user to select one of the possible duplicate events from the duplicate event
check screen.
23.2.10.10. If the user selects one of the events, the system should add all the information that was entered on the event
form (caller's name, address, phone, and comments, etc.) as supplemental comments to the selected event's audit trail.
23.2.10.11. The system should provide the user the option of continuing to enter the event as a new event, appending
the event to the earlier event as a supplement, linking the event as separate but related, designating the event as a duplicate, or
terminating the entry process.
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
23.2.10.12. When appending an existing event the system should provide the ability to automatically upgrade the event
type, priority, and/or urgency. This capability should be agency configurable.
23.2.10.13. The system should allow the user to identify two or more events as being duplicates.
SERIAL 11086-RFP
786
23.2.10.14. The system should automatically cross reference all related events and close all but the user defined active
call.
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
23.2.10.15. Once a call has been duped and closed the event should carry a disposition of "duplicate" and should have
the "active" event number in its history.
23.2.10.16. In addition to the capabilities to identify duplicate calls described above, the County wants to be able to view
a snap shot of the most recent incoming 911 calls, per workstation, at any point in time upon request.
23.2.11. EVENT ROUTING
23.2.11.1. The system should allow agency-definable routing of events to dispatchers.
23.2.11.2. Once an event has been initiated the system should be able to automatically route the event to the correct
dispatcher(s) based on the agency, location, and dispatch group.
23.2.11.3. The system should allow the user to “override” the address validation process by manually routing the call to
the correct dispatcher.
23.2.11.4. The system should log each occurrence of an address “override” and provide a means of reporting such
occurrences to System Administrator.
23.2.11.5. An agency-definable audible tone and/or visual message should notify the dispatcher that a new event has
been sent to their queue.
23.2.11.6. The system should place the event on the dispatcher's queue of events awaiting dispatch in priority order and,
within a priority, by time received.
23.2.11.7. When an event is initiated, the event information should be visually displayed to the appropriate dispatcher(s)
in the pending events queue.
23.2.11.8. Events should be capable of being assigned to a dispatcher as defined by the agency via any one of the
following:
23.2.11.8.1. Map Driven "special/temporary" geographical area/polygon
23.2.11.8.2. Event Type
23.2.11.8.3. Primary Geographical area (response area/Patrol area)
23.2.11.8.4. Pre-defined talk group (e.g., geographic location).
23.2.11.9. The hierarchy of assignment should be definable by Agency.
23.2.12. SUPPLEMENTING EVENT INFORMATION/EVENT CHANGES
23.2.12.1. The system should enable the user, when supplementing information into linked events, to designate one or
more events in which the supplemental information should appear.
23.2.12.2. The system should support ease of entry for supplemental event information and changes to event
information.
23.2.12.3. The user should be able to bring up a supplemental form either in relation to the event number or a unit
assigned to the event.
23.2.12.4. The user should be able to bring up a event change form either in relation to the event number or a unit
assigned to the event.
SERIAL 11086-RFP
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
23.2.12.5. The system should provide agency-definable visual and audible alerts to notify field units/dispatchers of event
changes and supplemental information.
23.2.12.6. The system should allow users to supplement and/or change active events, and all changes should be
tracked in the call history.
23.2.12.7. The system should allow a user to update any field except application-generated times and dates, operator
ID, ANI/ALI information, and CAD position.
23.2.12.8. All changes and supplemental information should be documented in the event history and the original
information should be retained.
23.2.12.9. The system should provide an event update/change mask.
23.2.12.10. The system should have the ability for a user to update or change a unit's most recent event by using the
unit ID of the unit or any unit that is currently assigned.
23.2.12.11. The system should require confirmation from the user when attempting to update any field in a closed event.
23.2.12.12. Whenever an active event record is updated the system, the system should by default, display a notification
of the event update at each position logged on to monitor (training mode), or control the area in which the updated event is
occurring.
23.2.12.13. The user making the update to the record should receive an agency-definable acknowledgment that the
update was processed.
23.2.12.14. Every transaction related to an event, including inquiries and responses, should be automatically stamped
with the date and time of the transaction, the responsible operator’s ID and the console ID, and becomes a permanent part of the
event history. These audit records should be added to the event history in chronological order and provide a complete historical audit
of all event activity such as comments, unit status changes, license plate information, field updates, etc. If the entry replaces existing
information in the event record, the old information, with the appropriate date, time, operator, and console stamps, is stored as a
comment in the event history. The audit information is retrievable in both summary and detailed formats when incident information is
displayed and may be printed.
23.2.12.15. A permanent audit trail should be maintained for all information recorded with an event. Once recorded,
incident history should not be modified or deleted. If corrections are necessary the records should be supplemented.
23.2.12.16. The system should allow users to supplement and or change active events and closed events; that user
should be able to update any field of a closed event without having re-open the event.
23.2.13. REOPENING A CLOSED EVENT
23.2.13.1. Users should be able to open an event that has been closed.
23.2.13.2. The event should require a comment as to why the event is being opened.
23.2.13.3. The call should go to the appropriate dispatcher as a pending or waiting event.
23.2.13.4. The re-opened event should contain the date/time, employee ID and position ID of the workstation opening
the event.
23.2.13.5. Once an event is re-opened it should act as any other active event.
23.2.13.6. Once a reopened event is dispatched to an MDC it should display a "reopened status" indicator to the user.
SERIAL 11086-RFP
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
23.2.13.7. The system should provide a command that will close an event without canceling it, when no units are
required to be assigned.
23.2.13.8. The system should provide a command for re-opening or re-activating an event that has previously been
closed.
23.2.13.9. The system should allow an authorized user to reopen an event that has been closed.
23.2.13.10. When a closed event is reopened the system should record the following minimum information:
23.2.13.10.1. User ID,
23.2.13.10.2. Workstation Number,
23.2.13.10.3. Time and Date that the event is re-opened, and
23.2.13.10.4. Provide a narrative field for the user to explain why the event was re-opened.
23.2.13.11. Any changes made to the event while reopened should appear in the event record.
23.2.13.12. Prior to closing a reopened event, the application should require an authorized user to validate or provide a
disposition if necessary.
23.2.13.13. Cancelled events should be capable of being reopened (as defined by the user) or changed.
23.2.13.14. If an event was closed by cancellation without a unit being assigned to the event and it is reopened with a
unit being assigned, the event should become part of the unit and event history.
23.2.14. CANCELLATION REQUESTS
23.2.14.1. The user should have the ability to request the cancellation of an event.
23.2.14.2. The system should provide the capability for the dispatcher to enter comments into the canceled event history.
23.2.14.3. The request notification should go to the controlling dispatcher, be displayed in the event history, and go to
any units that have been dispatched.
23.2.14.4. Only a controlling calltaker or dispatcher should have the ability to cancel an event.
23.2.14.5. If a calltaker is cancelling a call that has just been sent to a dispatcher, the dispatcher must receive a
message informing of the cancellation.
23.2.15. APPENDING EVENT INFORMATION
23.2.15.1. Users should have the ability to append information into an event, this includes messages sent from
workstations or MDC's
23.2.15.2. All appended information should be tracked in the event history and should identify the employee ID,
workstation ID and time and date stamp
23.2.15.3. The system should provide users the ability to append information into active and inactive events.
23.2.16. MEMO
23.2.16.1. The system should provide the capability of recording miscellaneous information to a unit and/or event history
on active and inactive events.
23.2.16.2. Memos to specified unit IDs should be recorded in the unit history. If the identified unit is assigned to an
event, the information should also be recorded to the event history.
23.2.16.3. Memos to a specific event should be accomplished by specifying an event number or by default to the user's
active event
SERIAL 11086-RFP
853
854
855
23.2.17. HIGH PRIORITY NOTIFICATION
23.2.17.1. The proposed system should notify the dispatcher visually that a high priority event has been initiated.
23.2.17.2. All high priority events entered into the system should have the ability to generate an agency-defined
notification to designated workstation/persons/groups as assigned by the System Administrator or supervisor (For example, on a
homicide, the County Command Staff, and PIO are notified).
856
23.2.17.3. An unlimited number of notifications should be allowed for any event type as determined by the System
Administrator.
23.2.17.4. Notifications should be capable of being triggered by Event type, LOI, Specific addresses, etc.
23.2.17.5. The individuals/groups to be notified should also receive an alert at their MDC/Workstation if they are logged
on to CAD.
23.2.17.6. The system should be capable of sending notifications to any wireless communication device (e.g. SMTP,
MAPI, SMS). etc.)
23.2.17.7. Personnel receiving notifications via CAD messaging who acknowledge the message should have the
acknowledgment memoed into the event history.
23.2.17.8. The system should have the ability to provide MDC equipped units with internally and externally initiated
Amber Alert information (including photos).
23.2.17.9. The system administrator should be able to control who has the capability to send high priority notifications.
24. DISPATCHING
24.1. The system should allow any dispatcher to take control of any event from another dispatcher.
24.2. The system should allow dispatchers to control units and events based on geographical location, e.g. talk group.
24.3. The system should provide the capability to dispatch non-County units such as other municipalities being dispatched by
the MCSO, Citizen Volunteers, Animal Control Officers, Park Rangers, and Code Compliance Officers, some of which may not be
equipped with MDCs. The displays of non-County activities should utilize labels and colors that are system administrator definable.
857
858
859
860
861
862
863
864
865
866
867
24.4. The system should provide the capability to segregate Telephone Response Unit (TRU), Animal Control Officers and any
other groups that may be dispatched now and in the future into separate screen displays. An example would be to configure
separate calls pending displays for each group.
868
869
24.4.1. DISPATCH SCREEN
24.4.1.1. The systems should be able to dynamically display unit and event data without the need to manually refresh
the display.
24.4.1.2. The patrol area should display on the header of all event displays.
24.4.1.3. The system should be able to dynamically display event and/or unit status data in a summary window.
24.4.1.4. The system should require only the minimum amount of user interaction (key strokes) to navigate pages.
24.4.1.5. The system should allow the County to create pre-defined event and/or unit status monitors to accommodate
logical groupings (e.g., by status, area, agency, jurisdiction).
24.4.1.6. The user should be able to modify the sorting of the status monitor every column within a status monitor (e.g.,
by time, by status, by location, etc.).
24.4.1.7. The system should permit the user to configure the column of the status monitor in ascending/descending
870
871
872
873
874
875
SERIAL 11086-RFP
order.
876
24.4.1.8. The system should have the user-defined ability to vertically and/or horizontally sort and/or group units and/or
events.
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
24.4.1.9. The system should be able to maintain an unlimited number of events or units within a single monitor.
24.4.1.10. The system should be able to display elapsed time in status monitors.
24.4.1.11. The unit and dispatch screen format should be fully configurable by agency.
24.4.1.12. The system should provide the ability to monitor events and unit status using user defined parameters.
24.4.1.13. The event type with the highest agency defined priority should be in the forefront and the update visually
differentiated from the other call details, e.g. highlighted.
24.4.1.14. Radio Identifiers. Agency configurable incident and command radio channels (multiple fields) should appear
on the event display, including the mobile terminal displays. Communications needs the capability to change these fields when an
event is moving to another channel (talk group).
24.4.2. DISPATCH DISPLAY
24.4.2.1. County monitors should be sortable by the user; unwanted fields should be able to be turned off at user
preference. There should also be a save feature for the individual user preference.
24.4.2.2. Monitors should have a clearly defined format to identify held events.
24.4.2.3. All monitors should have a clearly defined format to display expired timers. The capability to have visual
warnings move to the top of the calls status screen has been suggested.
24.4.2.4. All monitors should have a clearly defined format to display expired timers.
24.4.2.5. The Communications Supervisor should have the capability to set timers by call type. For example, the timer
for a domestic disturbance may be different from a check welfare call.
24.4.2.6. County dispatchers should be able to sort by dispatch group or station assignment.
24.4.2.7. The user should be able to monitor any dispatch group without taking or having control over the units or events.
24.4.2.8. All of the attributes of all masks of any display should be configurable by the System Administrator.
24.4.2.9. Resizing windows should not stop the system from processing information.
24.4.2.10. The system should provide, at a minimum, real time monitors for monitoring:
24.4.2.10.1. Active Events
24.4.2.10.2. Pending Events
24.4.2.10.3. Available Units
24.4.2.10.4. Push to talk (radio interface)
24.4.2.10.5. Active Units
24.4.2.10.6. Unit Status
24.4.2.11. The system should display in a separate window on the status monitor a chronological display of push to talk
radio IDs as they are received at that position. The system should log incoming push to talk messages to include date and time
stamp and radio ID and unit designator.
24.4.2.12. Users should have the ability to turn on or turn off monitors (the system administrator will determine if any
monitor can not be turned off)
SERIAL 11086-RFP
902
903
24.4.2.13. Held events should have a visible identifier on related monitors
24.4.2.14. The information displayed in monitors should be configurable by the system, performing logical processing of
any associated unit or event data values. Examples include: monitor designed/ configured to display all units that are not currently
available in their home quarters, i.e., any unit staffed with less than three personnel.
904
905
906
24.4.2.15. The system should provide for a method of monitoring units that have been "relocated".
24.4.3. EQUIPMENT STATUS MONITOR
24.4.3.1. The system should display the location of incidents and units in real-time without manually having to refresh the
system.
24.4.3.2. The system should provide a fully user-configurable unit status table and allow real-time updates to status, e.g.,
“on-scene”.
24.4.3.3. The proposed application should include the ability to return an assigned unit to service (user definable) and
dispatch a second unit to the event from which the first is being freed with a single command. The system should be able to
exchange two units assigned to separate events with a single command.
907
908
909
910
911
912
913
914
915
24.4.3.4. The proposed application should automatically preempt a Unit(s) when they are assigned to a different event.
This should be definable by agency, discipline, or jurisdiction.
24.4.3.5. The system should provide a quick and easy way to change a unit's status.
24.4.4. DISPATCH FUNCTIONS
24.4.4.1. The system should provide the ability for the system administrator to permit users to update/modify event
types, dispositions, addresses and other user-definable data for events that have been closed without having to re-open event.
24.4.4.2. The proposed application should provide the ability to cross reference or duplicate events and memo those
events with user defined information.
24.4.4.3. The system should provide a command for changing the location and/or status of a unit(s) assigned or
recommended to an event.
24.4.4.4. The system should provide the capability to reroute or reassign units to higher priority calls without necessarily
removing them from their current events/assignments. When rerouted/reassigned, appropriate tracking should take place to avoid
inaccurate response time reporting.
916
24.4.4.5. The system should allow officers to be removed from a call and assigned to a higher priority call without closing
the original event if any other officers remain on the call. One or more of the reassigned units may retain ownership of the original
call and return to it when time is available.
917
918
24.4.5. APPENDING EVENT INFORMATION
24.4.5.1. Users should have the ability to append information into an event, this includes messages sent from
workstations and/or MDC's.
24.4.5.2. All appended information should be tracked in the event history and should identify the employee ID,
workstation ID and time and date stamp
24.4.5.3. The system should provide users the ability to append information into active and inactive events. This
functionality should allow field units and Communications Staff to add comments to active and inactive events.
24.4.6. HOLDING EVENTS
919
920
921
SERIAL 11086-RFP
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
24.4.6.1. Holding means that events are in the pending queue and not yet assigned because they are being held for a
specific unit.
24.4.6.2. The system should allow a dispatcher to hold events to a busy unit as well as units that are in-service. If a unit
is on an assignment, when the unit(s) clears its assignment the application should notify the dispatcher and the unit(s) that held
events are waiting for the unit(s) and the unit(s) is now available. The Agency should be able to define which events can be held.
24.4.6.3. When an event is placed on hold it should notify the unit that it is being held for the unit.
24.4.6.4. The system should allow several events to be placed on hold for a single unit.
24.4.6.5. An event being placed on hold should not limit the ability of the dispatcher to send another unit on the event or
for field units self dispatching on the event.
24.4.6.6. The system should allow an event to be held for a unit that is not yet logged on
24.4.6.7. When an event is placed on hold it should be reflected in the history of the event.
24.4.6.8. Timers should be applied to all held events.
24.4.7. CROSS REFERENCING EVENTS
24.4.7.1. In the event that the dispatcher determines that one or more CAD events reference the same call for service it
should be possible to cross-reference the events.
24.4.7.2. When cross-referencing two events the system should enter the event number of each cross-referenced event
into the audit trail of the other event(s).
24.4.7.3. The system should include the ability to perform a cross-reference of events in one step.
24.4.7.4. The system should have the ability, if desired, to transfer name, call back number, remarks and any other user
defined event information along with the event ID into the event that is being retained.
24.4.8. EXCHANGING UNITS
24.4.8.1. The system should be able to exchange one unit assigned to an event with another unit with a single agency
defined command.
24.4.8.2. The system should automatically preempt a unit(s) assigned to an event when they are assigned to a different
event. This should be definable by agency.
24.4.8.3. The system should include the ability to return an assigned unit to service (agency-definable), and dispatch a
second unit to the event from which the first is being freed with a single command.
24.4.9. ASSIGNING DISPOSITION
24.4.9.1. The system should allow the user to assign a disposition to an event. The disposition types should be
determined by the System Administrator
24.4.9.2. The system should have the capability to assign multiple dispositions to a to a single event.
24.4.9.3. If multiple dispositions are assigned to an event the disposition received from the primary assigned unit should
be the final disposition.
24.4.9.4. The system should provide the ability to change or add a disposition on a closed event based upon system
administrator configurable security settings and role based privileges.
24.4.9.5. Dispositions should be highlighted/bolded or otherwise displayed in a manner that is easy for Communications
Specialists to see.
SERIAL 11086-RFP
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
24.4.9.6. The system should not allow a call to be closed if any units are still on the call.
24.4.9.7. Once the last unit has cleared an event, that event should automatically close without a disposition code if the
event type does not require a disposition.
24.4.10. PRE-EMPT
24.4.10.1. The user should have the ability to pre-empt a unit(s) from an active call, the unit(s) should be placed
available and the event should go to the pending event monitor (if no unit remains active on the call).
24.4.10.2. Users should have the ability to pre-empt a unit(s) and dispatch the unit(s) on another event. If all units are
removed from the original event it should be placed in the pending events monitor.
24.4.11. EVENT AND UNIT TIMERS
24.4.11.1. The system should be able to display elapsed timers in agency defined status monitors.
24.4.11.2. The system should have the ability to create pre-defined agency configurable elapsed timers for events and/or
unit status changes.
24.4.11.3. The system should allow users to create a custom, one-time event or unit specific elapsed timer (e.g., unit
contact timer)
24.4.11.4. The system should be able to display an agency defined warning if elapsed timer expires (visual and/or
audible alert).
24.4.11.5. The system should provide an event timer that will: activate after 'n' minutes and will initiate countdown upon
unit arrival. "n' = Administrator selected based upon Event type..
24.4.11.6. The user should have the ability to turn off or reset all timers for a single, multiple or all units related to a
single event in a single command.
24.4.11.7. The system should provide an active window to display units whose timers have expired, once the timers are
reset the units should disappear from this active window.
24.4.11.8. The dispatcher should have the ability to cancel or set all the units timers associated with an event if
necessary with a single action.
24.4.11.9. The system should record all event and unit times, including tracking times separately for primary and all
secondary units assigned to a call.
24.4.12. DISPATCHER/FIELD UPDATE NOTIFICATIONS
24.4.12.1. The dispatcher should be notified by an agency-configurable visual and/or and audible alert when a new event
has been created and is pending which is also based on event priority.
24.4.12.2. The system should provide agency-definable visual and audible alerts to notify field units/dispatchers of event
priority changes and supplemental information.
24.4.12.3. Event notifications required/preprogrammed for any event can be turned off by the dispatcher prior to
dispatching that event.
24.4.12.4. The dispatcher should have a visual indication that a call has been updated without having to rely on the
Status Monitor.
24.4.12.5. If a generic update button indicator is used to alert the user that a call has been updated the dispatcher should
be able to click on the button and be presented with the updated information.
SERIAL 11086-RFP
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
24.4.12.6. Once viewed the details should display as normal and the update indicator returned to neutral. If there are
more updates to view, the update button would continue to be lit.
24.4.12.7. The necessity to scroll or search through the record should be minimized.
24.4.12.8. When a dispatcher makes an update, supplement or change to an event they control they should not receive
notification of that change, however the dispatcher should be notified if change is made by call taker.
24.4.12.9. The dispatcher should be advised immediately whenever a field unit self dispatches or self initiates on an
event. The importance level of the notification should be configurable by the System Administrator. The system should be capable
of being set to send urgent notifications to the dispatcher for certain event types such as robberies, traffic stops etc. and to send
routine notifications for minor event types such as marking out at the station or court .When a self initiating unit has currently
assigned calls, the system needs to prompt the dispatcher to either reassign the "orphaned" calls, place them back in calls holding,
or allow them to remain with the unit for later follow-up. Some definitive action should be taken to ensure that the "orphaned" calls
are processed.
24.4.12.10. The system should not allow a unit to self initiate on a call without entering an event type and location.
24.4.12.11. Emergency activations from either radio or MDC's should create an emergency notification to the dispatcher
24.4.12.12. Any Emergency activation should require a dispatch function to acknowledge the activation
24.4.13. UNIT/RESOURCE SET-UP
24.4.13.1. The system should allow the system administrator to configure unit attributes.
24.4.13.2. The status screen(s) at the workstation should have a agency configurable display of response areas.
24.4.13.3. The system should allow for multiple unit types by agency, discipline and jurisdiction
24.4.13.4. Different discipline, agency and jurisdictions should have the ability to create common alpha numeric unit IDs.
24.4.13.5. The unit ID should be able to contain a minimum of eight (8) alpha numeric characters.
24.4.13.6. The system should maintain multiple agency-definable identifiers for each unit such as unit designator, vehicle
number, portable radio number, mobile radio number, EIN, CAD ID, home quarters, etc.
24.4.13.7. The system should be able to query a unit based on associated data such as: unit designator, vehicle
number, portable radio number, mobile radio number, EIN, CAD ID, home quarters, etc.
24.4.13.8. The user should have the ability to search the system for unit related resources. For example: special skills
such as languages, EMT and abilities, RBT tech, crash reconstruction
24.4.13.9. The system should be able to recognize that if a dual function is put on a call that it should assign a second
unit.
24.4.14. EVENT RECOMMENDATIONS
24.4.14.1. The County department currently uses patrol areas and is planning to incorporate closest unit dispatch as part
of this system migration. Event displays and recommendations need to be able to provide this type of dispatcher specific data.
24.4.14.2. All events should be assigned to a dispatcher via; a map driven "special/temporary" geographical area, the
response area, or the event type as defined by the Agency, discipline and jurisdiction. Hierarchy of assignment is in the above listed
order. E.g. a temporary dispatch area overrides all other pre-designed routing parameters.
24.4.14.3. All system recommended units should be displayed on one screen.
SERIAL 11086-RFP
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
24.4.14.4. The response order recommendations are based on AVL, or /Patrol Area assignments. The dispatcher should
be able to choose between either of the above recommendations with a user selectable function.
24.4.14.5. The system should be capable of being configured to recommend on unit type, unit capabilities, AVL position
and/or area responsibilities
24.4.14.6. The system should have a recommended unit override function. Individual unit(s) can be removed from the
recommended list via a mouse click. Multiple units should be able to be added to the dispatch via a free form line.
24.4.14.7. The system should also show all closest alternate units and be able to add individual unit(s) to the dispatch
compliment via a mouse click, command line, etc.
24.4.14.8. Any dispatcher can view a pending event and unit recommendation without any impact on the controlling
dispatcher viewing the same information and the dispatching of the event. e.g.. when someone views an event with recommended
units the units are not encumbered in any way
24.4.14.9. The system should provide the dispatcher a method to view the closest available unit (s) (least travel time) for
any location or event. The default number of unit(s) and or unit types to be automatically displayed is agency configurable.
24.4.14.10. The system should support the ability to recommend the closest (least travel time) appropriate unit(s) for an
event, based on unique capabilities; e.g. Shot-gun certified, canine, etc.
24.4.14.11. The system should provide for a mechanism to automatically recommend a "Special" response compliment
for a predefined location/event type combination.
24.4.14.12. The system should automatically generate priority, unit type requirements, back up, or non-standard routing
based on the parameters for that event as defined by the system administrator.
24.4.15. DISPATCHING EVENTS
24.4.15.1. The dispatcher should be able to process pending events in any sequence.
24.4.15.2. Users should have the ability to dispatch a single unit or multiple units with no limit to the number of units that
can be dispatched to a single event.
24.4.15.3. When selected, the event should automatically display along with unit recommendations according to the
Agency Parameters set for each event type. Dispatchers should be able to, at any time, quickly request the display and unit
recommendations for any pending event without having to perform multiple steps.
24.4.15.4. When the system recommends units for dispatch or a request is made for additional units, the dispatcher
should have the following options for completing the dispatch;
24.4.15.4.1. Press a single key to accept the recommended units and dispatch
24.4.15.4.2. Select individual units from the recommended units for dispatch, then dispatch
24.4.15.4.3. Select units not recommended by the system for dispatch , then dispatch
24.4.15.4.4. Accept recommended units and add to, then dispatch,
24.4.15.4.5. Based on geographical area, display a static response order for all units.
24.4.15.4.6. The proposed CAD should allow a dispatcher to dispatch:
24.4.15.4.7. From the command line, through the event Dispatch form, or
24.4.15.4.8. From a mouse click on the status monitor
24.4.15.4.9. From a mouse click on a unit icon on the map display
SERIAL 11086-RFP
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
24.4.15.4.10. “Hot Keys”.
24.4.15.5. The dispatcher should be able to transfer any pending event to another dispatcher. Any dispatcher should be
able to dispatch units to any event based on agency control
24.4.15.6. The user should have the ability to dispatch a unit or units to a defined location other than that of the event
location when necessary based on agency control.
24.4.15.7. Once a pending event has been displayed, the system should be configurable so that subsequent displays will
automatically generate unit recommendations based on agency control.
24.4.15.8. Once the event has been displayed, the dispatcher should be able to dispatch the event from the pending
event list without re-display based on agency control. An event should not have to be displayed in order to dispatch the event.
24.4.15.9. With the AVL feature the user should be able to click on an event then on a unit or units to assign the units to
the call regardless of control (group assignment) of that unit.
24.4.15.10. Users should be able to assign units to an event via the command line.
24.4.16. SELF-INITIATED EVENTS
24.4.16.1. The system should include a command, agency defined, for CAD (including MDC) users to create an event,
assign and arrive a unit in a single step. (Self-Initiated Event) For example, an officer comes upon an accident while on routine
patrol.
24.4.16.2. The system should automatically attempt to verify the event location for the self-initiated event.
24.4.16.3. If the self-initiated event is a high priority event the system should automatically generate necessary
notifications.
24.4.16.4. The order of the notifications sent to the dispatcher should be based on the event priority. For example a unit
marks on a parking complaint at the same time another unit marks on a traffic stop, the traffic stop should move ahead of the parking
complaint.
24.4.17. EVENT/UNIT STATUS
24.4.17.1. The system should be capable of establishing and processing the following agency-definable unit and event
statuses:
24.4.17.1.1. In-service
24.4.17.1.16. Available
SERIAL 11086-RFP
EXHIBIT 1
VENDOR REGISTRATION PROCEDURES
BidSync.com Registration is FREE and REQUIRED for all
vendors.
Register On-line at
https://www.bidsync.com/SupplierRegister?ac=register&preselect
ed_plan=free&
Upon completion of your on-line registration, you are responsible
for updating any changes to your information. Please retain your
Login ID and Password for future use.
For assistance, please contact BidSync Vendor Support
Department via phone or email, during regular business hours: 1800-990-9339 or agencysupport@BidSync.com
SERIAL 11086-RFP
EXHIBIT 2
SAMPLE TRANSMITTAL LETTER
(To be typed on the letterhead of Offeror)
Maricopa County
Materials Management Department
320 West Lincoln Street
Phoenix, Arizona 85003-2494
Re:
RFP Number – 11086-RFP
To Whom It May Concern:
(NAME OF COMPANY) (Herein referred to as the "RESPONDENT"), hereby submits its response to your Request
for Proposal dated
, and agrees to perform as proposed in their proposal, if awarded the contract. The
Respondent shall thereupon be contractually obligated to carry out its responsibilities respecting the services
proposed.
Kindly advise this in writing on or before
Very truly yours,
_______________________________
NAME (please print)
_______________________________
SIGNATURE
_______________________________
TITLE (please print)
if you should desire to accept this proposal.
SERIAL 11086-RFP
EXHIBIT 3
MATERIALS MANAGEMENT CONTRACTOR TRAVEL AND PER DIEM POLICY
1.0
All contract-related travel plans and arrangements shall be prior-approved by the County Contract
Administrator.
2.0
Lodging, per diem and incidental expenses incurred in performance of Maricopa County/Special District
(County) contracts shall be reimbursed based on current U.S. General Services Administration (GSA)
domestic per diem rates for Phoenix, Arizona. Contractors must access the following internet site to
determine rates (no exceptions): www.gsa.gov
3.0
2.1
Additional incidental expenses (i.e., telephone, fax, internet and copying charges) shall not be
reimbursed. They should be included in the contractor’s hourly rate as an overhead charge.
2.2
The County will not (under no circumstances) reimburse for Contractor guest lodging, per diem or
incidentals.
Commercial air travel shall be reimbursed as follows:
3.1
3.2
3.3
4.0
5.0
Coach airfare will be reimbursed by the County. Business class airfare may be allowed only when
preapproved in writing by the County Contract Administrator as a result of the business need of
the County when there is no lower fare available.
The lowest direct flight airfare rate from the Contractors assigned duty post (pre-defined at the
time of contract signing) will be reimbursed. Under no circumstances will the County reimburse
for airfares related to transportation to or from an alternate site.
The County will not (under no circumstances) reimburse for Contractor guest commercial air
travel.
Rental vehicles may only be used if such use would result in an overall reduction in the total cost of the
trip, not for the personal convenience of the traveler. Multiple vehicles for the same set of travelers for the
same travel period will not be permitted without prior written approval by the County Contract
Administrator.
4.1.
Purchase of comprehensive and collision liability insurance shall be at the expense of the
contractor. The County will not reimburse contractor if the contractor chooses to purchase these
coverage.
4.2.
Rental vehicles are restricted to sub-compact, compact or mid-size sedans unless a larger vehicle
is necessary for cost efficiency due to the number of travelers. (NOTE: contractors shall obtain
pre-approval in writing from the County Contract Administrator prior to rental of a larger vehicle.)
4.3.
County will reimburse for parking expenses if free, public parking is not available within a
reasonable distance of the place of County business. All opportunities must be exhausted prior to
securing parking that incurs costs for the County. Opportunities to be reviewed are the DASH;
shuttles, etc. that can transport the contractor to and from County buildings with minimal costs.
4.4.
County will reimburse for the lowest rate, long-term uncovered (e.g. covered or enclosed parking
will not be reimbursed) airport parking only if it is less expensive than shuttle service to and from
the airport.
4.5.
The County will not (under no circumstances) reimburse the Contractor for guest vehicle rental(s)
or other any transportation costs.
Contractor is responsible for all costs not directly related to the travel except those that have been preapproved by the County Contract Administrator. These costs include (but not limited to) the following: inroom movies, valet service, valet parking, laundry service, costs associated with storing luggage at a hotel,
fuel costs associated with non-County activities, tips that exceed the per diem allowance, health club fees,
SERIAL 11086-RFP
and entertainment costs.
reimbursable.
6.0
Claims for unauthorized travel expenses will not be honored and are not
Travel and per diem expenses shall be capped at 15% of project price unless otherwise specified in
individual contracts
SERIAL 11086-RFP
EXHIBIT 4
(DRAFT CONTRACT)
CONTRACT PURSUANT TO RFP
SERIAL 11086-RFP
This Contract is entered into this _____ day of ____________, 20__ by and between Maricopa County (“County”),
a political subdivision of the State of Arizona, and _______________________________, an Arizona corporation
(“Contractor”) for the purchase of ____________ services.
1.0
CONTRACT TERM:
1.1
This Contract is for a term of
and ending the day of
( ) years, beginning on the
, 20
.
day of
,
2011
1.2
The County may, at its option and with the agreement of the Contractor, renew the term
of this Contract for additional terms up to a maximum of
( ) years, (or at the
County’s sole discretion, extend the contract on a month-to-month bases for a maximum
of six (6) months after expiration). The County shall notify the Contractor in writing of its
intent to extend the Contract term at least thirty (30) calendar days prior to the expiration of the
original contract term, or any additional term thereafter.
2.0
FEE ADJUSTMENTS:
Any request for fee adjustments must be submitted sixty (60) days prior to the current Contract expiration
date. Requests for adjustment in cost of labor and/or materials must be supported by appropriate
documentation. If County agrees to the adjusted fee, County shall issue written approval of the change.
The reasonableness of the request will be determined by comparing the request with the (Consumer Price
Index) or by performing a market survey.
3.0
ACCEPTANCE TEST PROCESS:
The acceptance test process shall include three phases: the acceptance testing period, the reliability test
period, and the final acceptance. If at any time during the acceptance-testing period, the system reveals any
major defects or several minor defects, the process shall be terminated and the Vendor shall resolve the
outstanding issues. Once all of the issues have been addressed, the Vendor will recommence the
acceptance test period from the very beginning.
3.1
Acceptance Test Plan: The Vendor’s software will be delivered to the Sheriff’s Office
accompanied with written documentation of a test plan for the Sheriff’s Office to use in their
acceptance testing. The Sheriff’s Office will review the written draft of the testing plan and
schedule the installation of the software within the Sheriff’s Office test environment. The
acceptance test period will begin when the Sheriff’s Office, along with the assistance of the
Vendor, first performs all tests in accordance with the written test plan and successfully completes
SERIAL 11086-RFP
the tests defined within that plan. If major defects or numerous minor defects are found during the
acceptance testing, the tests shall be terminated and the Vendor shall resolve outstanding issues.
Once all issues have been addressed, the Vendor will recommence the acceptance test process
from the very beginning.
3.2
Reliability Test Period: After the successful completion of the cutover period, there shall be a
minimum of thirty (30) day reliability test period during which the newly installed system will be
in production and its performance monitored. During this period, the system must perform fully
without degradation of any kind in order for the acceptance test to be satisfied. If any major
defects or numerous minor defects are discovered, the reliability test period shall be terminated
and the Vendor shall resolve any and all issues. Once all issues have been addressed, the Vendor
will recommence the acceptance test process from the beginning.
3.3
Final Acceptance: At the successful completion of the reliability test period, the Sheriff’s Office
shall issue the conditional acceptance certificate. At the end of the successful completion of both
the reliability test period and the data conversion, the Sheriff’s Office shall issue the final
acceptance certificate.
The Vendor should demonstrate through an acceptance process performance (stress) test that the
system performs as required in the Sheriff’s Office’s technical environment and that the system
meets or exceeds the Sheriff’s Office’s functional requirements. The stress test should include all
LAN connected applications (i.e., CAD, RMS, etc.). The final Acceptance Test Plan (ATP)
should have use of Sheriff’s Office’s approved data and include report generation.




4.0
The final acceptance test should exercise all functionality and components successfully.
MCSO should test back-up features successfully
MCSO should test and recovery features successfully.
The failure of any specific portion of a test may require that the entire test be rerun, not
just the failed portion of the test
PAYMENTS:
4.1
As consideration for performance of the duties described herein, County shall pay Contractor the
sum(s) stated in Exhibit “A.”
4.2
Payment shall be made upon the County’s receipt of a properly completed invoice.
4.3
INVOICES:
4.3.1
The Contractor shall submit two (2) legible copies of their detailed invoice before
payment(s) can be made. At a minimum, the invoice must provide the following
information:













Company name, address and contact
County bill-to name and contact information
Contract serial number
County purchase order number
Invoice number and date
Payment terms
Date of service or delivery
Quantity
Contract Item number(s)
Description of service provided
Pricing per unit of service
Freight (if applicable)
Extended price
SERIAL 11086-RFP


5.0
6.0
7.0
Mileage w/rate (if applicable)
Total Amount Due
4.3.2
Problems regarding billing or invoicing shall be directed to the County as listed on the
Purchase Order.
4.3.3
Payment shall be made to the Contractor by Accounts Payable through the Maricopa
County Vendor Express Payment Program. This is an Electronic Funds Transfer (EFT)
process. After Award the Contractor shall fill out an EFT Enrollment form located on the
County Department of Finance Website as a fillable PDF document
(www.maricopa.gov/finance/)
4.3.4
EFT payments to the routing and account numbers designated by the Contractor will
include the details on the specific invoices that the payment covers. The Contractor is
required to discuss remittance delivery capabilities with their designated financial
institution for access to those details.
AVAILABILITY OF FUNDS:
5.1
The provisions of this Contract relating to payment for services shall become effective when funds
assigned for the purpose of compensating the Contractor as herein provided are actually available
to County for disbursement. The County shall be the sole judge and authority in determining the
availability of funds under this Contract. County shall keep the Contractor fully informed as to the
availability of funds.
5.2
If any actions are taken by any state agency, Federal department or any other agency or
instrumentality to suspend, decrease, or terminate its fiscal obligations under, or in connection
with, this Contract, County may amend, suspend, decrease, or terminate its obligations under, or in
connection with, this Contract. In the event of termination, County shall be liable for payment
only for services rendered prior to the effective date of the termination, provided that such services
are performed in accordance with the provisions of this Contract. County shall give written notice
of the effective date of any suspension, amendment, or termination under this Section, at least ten
(10) days in advance.
DUTIES:
6.1
The Contractor shall perform all duties stated in Exhibit “B”, or as otherwise directed in writing
by the Procurement Officer.
6.2
During the Contract term, County shall provide Contractor’s personnel with adequate workspace
for consultants and such other related facilities as may be required by Contractor to carry out its
contractual obligations.
TERMS and CONDITIONS:
7.1
INDEMNIFICATION:
7.1.1
To the fullest extent permitted by law, Contractor shall defend, indemnify, and hold
harmless County, its agents, representatives, officers, directors, officials, and employees
from and against all claims, damages, losses and expenses, including, but not limited to,
attorney fees, court costs, expert witness fees, and the cost of appellate proceedings,
relating to, arising out of, or alleged to have resulted from the acts, errors, omissions,
mistakes or malfeasance relating to the performance of this Contract. Contractor’s duty
to defend, indemnify and hold harmless County, its agents, representatives, officers,
directors, officials, and employees shall arise in connection with any claim, damage, loss
or expense that is caused by any negligent acts, errors, omissions or mistakes in the
performance of this Contract by the Contractor, as well as any person or entity for whose
SERIAL 11086-RFP
acts, errors, omissions, mistakes or malfeasance Contractor may be legally liable
including Contractor’s subcontractors.
7.2
7.1.2
The amount and type of insurance coverage requirements set forth herein will in no way
be construed as limiting the scope of the indemnity in this paragraph.
7.1.3
The scope of this indemnification does not extend to the sole negligence of County.
INSURANCE REQUIREMENTS:
7.2.1
Contractor, at Contactor’s own expense, shall purchase and maintain the herein stipulated
minimum insurance from a company or companies duly licensed by the State of Arizona
and possessing a current A.M. Best, Inc. rating of A-, VII or higher. In lieu of State of
Arizona licensing, the stipulated insurance may be purchased from a company or
companies, which are authorized to do business in the State of Arizona, provided that
said insurance companies meet the approval of County. The form of any insurance
policies and forms must be acceptable to County.
7.2.2
All insurance required herein shall be maintained in full force and effect until all work or
service required to be performed under the terms of the Contract is satisfactorily
completed and formally accepted. Failure to do so may, at the sole discretion of County,
constitute a material breach of this Contract.
7.2.3
Contractor’s insurance shall be primary insurance as respects County, and any insurance
or self-insurance maintained by County shall not contribute to it.
7.2.4
Any failure to comply with the claim reporting provisions of the insurance policies or any
breach of an insurance policy warranty shall not affect the County’s right to coverage
afforded under the insurance policies.
7.2.5
The insurance policies may provide coverage that contains deductibles or self-insured
retentions. Such deductible and/or self-insured retentions shall not be applicable with
respect to the coverage provided to County under such policies. Contactor shall be solely
responsible for the deductible and/or self-insured retention and County, at its option, may
require Contractor to secure payment of such deductibles or self-insured retentions by a
surety bond or an irrevocable and unconditional letter of credit.
7.2.6
County reserves the right to request and to receive, within 10 working days, certified
copies of any or all of the herein required insurance certificates. County shall not be
obligated to review policies and/or endorsements or to advise Contractor of any
deficiencies in such policies and endorsements, and such receipt shall not relieve
Contractor from, or be deemed a waiver of County’s right to insist on strict fulfillment of
Contractor’s obligations under this Contract.
7.2.7
The insurance policies required by this Contract, except Workers’ Compensation, and
Errors and Omissions, shall name County, its agents, representatives, officers, directors,
officials and employees as Additional Insureds.
7.2.8
The policies required hereunder, shall contain a waiver of transfer of rights of recovery
(subrogation) against County, its agents, representatives, officers, directors, officials and
employees for any claims arising out of Contractor’s work or service.
7.2.9
Commercial General Liability.
Commercial General Liability insurance and, if necessary, Commercial Umbrella
insurance with a limit of not less than $2,000,000 for each occurrence, $4,000,000
Products/Completed Operations Aggregate, and $4,000,000 General Aggregate Limit.
The policy shall include coverage for bodily injury, broad form property damage,
SERIAL 11086-RFP
personal injury, products and completed operations and blanket contractual coverage, and
shall not contain any provision which would serve to limit third party action over claims.
7.2.10
Automobile Liability.
Commercial/Business Automobile Liability insurance and, if necessary, Commercial
Umbrella insurance with a combined single limit for bodily injury and property damage
of not less than $1,000,000 each occurrence with respect to any of the Contractor’s
owned, hired, and non-owned vehicles assigned to or used in performance of the
Contractor’s work or services under this Contract.
7.2.11
Workers’ Compensation.
7.2.12
Workers’ Compensation insurance to cover obligations imposed by federal and state
statutes having jurisdiction of Contractor’s employees engaged in the performance of the
work or services under this Contract; and Employer’s Liability insurance of not less than
$1,000,000 for each accident, $1,000,000 disease for each employee, and $1,000,000
disease policy limit.
7.2.13
Contractor waives all rights against County and its agents, officers, directors and
employees for recovery of damages to the extent these damages are covered by the
Workers’ Compensation and Employer’s Liability or commercial umbrella liability
insurance obtained by Contractor pursuant to this Contract.
7.2.14
Errors and Omissions Insurance.
Errors and Omissions insurance and, if necessary, Commercial Umbrella insurance,
which will insure and provide coverage for errors or omissions of the Contractor, with
limits of no less than $5,000,000 for each claim.
7.2.15
Certificates of Insurance.
7.2.16
Prior to commencing work or services under this Contract, Contractor shall furnish the
County with certificates of insurance, or formal endorsements as required by the Contract
in the form provided by the County, issued by Contractor’s insurer(s), as evidence that
policies providing the required coverage, conditions and limits required by this Contract
are in full force and effect. Such certificates shall identify this contract number and title.
7.2.17
In the event any insurance policy (ies) required by this Contract is (are) written on a
“claims made” basis, coverage shall extend for two (2) years past completion and
acceptance of Contractor’s work or services and as evidenced by annual Certificates of
Insurance.
7.2.18
If a policy does expire during the life of the Contract, a renewal certificate must be sent to
County fifteen (15) days prior to the expiration date.
7.2.19
Cancellation and Expiration Notice.
Insurance required herein shall not be permitted to expire, be canceled, or materially
changed without thirty (30) days prior written notice to the County.
7.3
WARRANTY OF SERVICES:
7.3.1
The Contractor warrants that all services provided hereunder will conform to the
requirements of the Contract, including all descriptions, specifications and attachments
made a part of this Contract. County’s acceptance of services or goods provided by the
Contractor shall not relieve the Contractor from its obligations under this warranty.
SERIAL 11086-RFP
7.3.2
7.4
7.5
In addition to its other remedies, County may, at the Contractor's expense, require prompt
correction of any services failing to meet the Contractor's warranty herein. Services
corrected by the Contractor shall be subject to all the provisions of this Contract in the
manner and to the same extent as services originally furnished hereunder.
INSPECTION OF SERVICES:
7.4.1
The Contractor shall provide and maintain an inspection system acceptable to County
covering the services under this Contract. Complete records of all inspection work
performed by the Contractor shall be maintained and made available to County during
contract performance and for as long afterwards as the Contract requires.
7.4.2
County has the right to inspect and test all services called for by the Contract, to the
extent practicable at all times and places during the term of the Contract. County shall
perform inspections and tests in a manner that will not unduly delay the work.
7.4.3
If any of the services do not conform with Contract requirements, County may require the
Contractor to perform the services again in conformity with Contract requirements, at an
increase in Contract amount. When the defects in services cannot be corrected by reperformance, County may:
7.4.4
Require the Contractor to take necessary action to ensure that future performance
conforms to Contract requirements; and
7.4.5
Reduce the Contract price to reflect the reduced value of the services performed.
7.4.6
If the Contractor fails to promptly perform the services again or to take the necessary
action to ensure future performance in conformity with Contract requirements, County
may:
7.4.7
By Contract or otherwise, perform the services and charge to the Contractor any cost
incurred by County that is directly related to the performance of such service; or
7.4.8
Terminate the Contract for default.
BOND REQUIREMENT:
7.5.1
Concurrently with the submittal of the Contract, the Contractor shall furnish the
Contracting Agency the following bonds, which shall become binding upon the award of
the contract to the Contractor.

Performance Bond equal to the full Contract amount conditioned upon the faithful
performance of the Contract in accordance with plans, specifications and conditions
thereof. Such bond shall be solely for the protection of the Contracting Agency
awarding the Contract.

A Payment Bond equal to the full contract amount solely for the protection of
claimants supplying labor and materials to the Contractor or his Subcontractors in
the prosecution of the work provided for in such Contract.
7.5.2
Each such bond shall include a provision allowing the prevailing party in a suit on such
bond to recover as a part of his judgment such reasonable attorney’s fees as may be fixed
by a judge of the court.
7.5.3
Each bond shall be executed by a surety company or companies holding a certificate of
authority to transact surety business in the State of Arizona issued by the Director of the
SERIAL 11086-RFP
Department of Insurance. The bonds shall not be executed by an individual surety or
sureties. The bonds shall be made payable and acceptable to the Contracting Agency.
The bonds shall be written or countersigned by an authorized representative of the surety
who is either a resident of the State of Arizona or whose principal office is maintained in
this state, as by law required, and the bonds shall have attached thereto a certified copy of
the Power of Attorney of the signing official. In addition, said company or companies
shall be rated “Best-A” or better as required by the Contracting Agency, as currently
listed in the most recent Best Key Rating Guide, published by the A.M. Best Company .
7.6
PROCUREMENT CARD ORDERING CAPABILITY:
The County may determine to use a MasterCard Procurement Card, to place and make payment
for orders under the Contract.
7.7
INTERNET ORDERING CAPABILITY:
The County intends, at its option, to use the Internet to communicate and to place orders under this
Contract.
7.8
NOTICES:
All notices given pursuant to the terms of this Contract shall be addressed to:
For County:
Maricopa County
Department of Materials Management
Attn: Director of Purchasing
320 West Lincoln Street
Phoenix, Arizona 85003-2494
For Contractor:
7.9
7.10
REQUIREMENTS CONTRACT:
7.9.1
Contractor signifies its understanding and agreement by signing this document that this
Contract is a requirements contract. This Contract does not guarantee any purchases will
be made (minimum or maximum). Orders will only be placed when County identifies a
need and issues a purchase order or a written notice to proceed.
7.9.2
County reserves the right to cancel purchase orders or notice to proceed within a
reasonable period of time after issuance. Should a purchase order or notice to proceed be
canceled, the County agrees to reimburse the Contractor for actual and documented costs
incurred by the Contractor. The County will not reimburse the Contractor for any
avoidable costs incurred after receipt of cancellation, or for lost profits, or shipment of
product or performance of services prior to issuance of a purchase order or notice to
proceed.
7.9.3
Purchase orders will be cancelled in writing.
TERMINATION FOR CONVENIENCE:
The County reserves the right to terminate the Contract, in whole or in part at any time, when in
the best interests of the County without penalty or recourse. Upon receipt of the written notice,
SERIAL 11086-RFP
the Contractor shall immediately stop all work, as directed in the notice, notify all subcontractors
of the effective date of the termination and minimize all further costs to the County. In the event
of termination under this paragraph, all documents, data and reports prepared by the Contractor
under the Contract shall become the property of and be delivered to the County upon demand.
The Contractor shall be entitled to receive just and equitable compensation for work in progress,
work completed and materials accepted before the effective date of the termination.
7.11
7.12
TERMINATION FOR DEFAULT:
7.11.1
In addition to the rights reserved in the Contract, the County may terminate the Contract
in whole or in part due to the failure of the Contractor to comply with any term or
condition of the Contract, to acquire and maintain all required insurance policies, bonds,
licenses and permits, or to make satisfactory progress in performing the Contract. The
Procurement Officer shall provide written notice of the termination and the reasons for it
to the Contractor.
7.11.2
Upon termination under this paragraph, all goods, materials, documents, data and reports
prepared by the Contractor under the Contract shall become the property of and be
delivered to the County on demand.
7.11.3
The County may, upon termination of this Contract, procure, on terms and in the manner
that it deems appropriate, materials or services to replace those under this Contract. The
Contractor shall be liable to the County for any excess costs incurred by the County in
procuring materials or services in substitution for those due from the Contractor.
7.11.4
The Contractor shall continue to perform, in accordance with the requirements of the
Contract, up to the date of termination, as directed in the termination notice.
STATUTORY RIGHT OF CANCELLATION FOR CONFLICT OF INTEREST:
Notice is given that pursuant to A.R.S. §38-511 the County may cancel this Contract without
penalty or further obligation within three years after execution of the contract, if any person
significantly involved in initiating, negotiating, securing, drafting or creating the contract on
behalf of the County is at any time while the Contract or any extension of the Contract is in effect,
an employee or agent of any other party to the Contract in any capacity or consultant to any other
party of the Contract with respect to the subject matter of the Contract. Additionally, pursuant to
A.R.S §38-511 the County may recoup any fee or commission paid or due to any person
significantly involved in initiating, negotiating, securing, drafting or creating the contract on
behalf of the County from any other party to the contract arising as the result of the Contract.
7.13
OFFSET FOR DAMAGES;
In addition to all other remedies at law or equity, the County may offset from any money due to
the Contractor any amounts Contractor owes to the County for damages resulting from breach or
deficiencies in performance under this contract.
7.14
ADDITIONS/DELETIONS OF SERVICE:
The County reserves the right to add and/or delete products and/or services provided under this
Contract. If a requirement is deleted, payment to the Contractor will be reduced proportionately to
the amount of service reduced in accordance with the proposal price. If additional services and/or
products are required from this Contract, prices for such additions will be negotiated between the
Contractor and the County.
7.15
RELATIONSHIPS:
In the performance of the services described herein, the Contractor shall act solely as an
independent contractor, and nothing herein or implied herein shall at any time be construed as to
SERIAL 11086-RFP
create the relationship of employer and employee, partnership, principal and agent, or joint venture
between the District and the Contractor.
7.16
SUBCONTRACTING:
The Contractor may not assign this Contract or subcontract to another party for performance of the
terms and conditions hereof without the written consent of the County, which shall not be
unreasonably withheld. All correspondence authorizing subcontracting must reference the
Proposal Serial Number and identify the job project.
7.17
AMENDMENTS:
All amendments to this Contract shall be in writing and approved/signed by both parties. Maricopa
County Materials Management shall be responsible for approving all amendments for Maricopa
County.
7.18
7.19
RETENTION OF RECORDS:
7.18.1
The Contractor agrees to retain all financial books, records, and other documents relevant
to this Contract for six (6) years after final payment or until after the resolution of any
audit questions which could be more than six (6) years, whichever is longer. The County,
Federal or State auditors and any other persons duly authorized by the Department shall
have full access to, and the right to examine, copy and make use of, any and all said
materials.
7.18.2
If the Contractor’s books, records and other documents relevant to this Contract are not
sufficient to support and document that requested services were provided, the Contractor
shall reimburse Maricopa County for the services not so adequately supported and
documented.
AUDIT DISALLOWANCES:
If at any time, County determines that a cost for which payment has been made is a disallowed
cost, such as overpayment, County shall notify the Contractor in writing of the disallowance.
County shall also state the means of correction, which may be but shall not be limited to
adjustment of any future claim submitted by the Contractor by the amount of the disallowance, or
to require repayment of the disallowed amount by the Contractor.
7.20
ALTERNATIVE DISPUTE RESOLUTION:
7.20.1
After the exhaustion of the administrative remedies provided in the Maricopa County
Procurement Code, any contract dispute in this matter is subject to compulsory
arbitration. Provided the parties participate in the arbitration in good faith, such
arbitration is not binding and the parties are entitled to pursue the matter in state or
federal court sitting in Maricopa County for a de novo determination on the law and facts.
If the parties cannot agree on an arbitrator, each party will designate an arbitrator and
those two arbitrators will agree on a third arbitrator. The three arbitrators will then serve
as a panel to consider the arbitration. The parties will be equally responsible for the
compensation for the arbitrator(s). The hearing, evidence, and procedure will be in
accordance with Rule 74 of the Arizona Rules of Civil Procedure. Within ten (10) days
of the completion of the hearing the arbitrator(s) shall:
7.20.1.1
Render a decision;
7.20.1.2
Notify the parties that the exhibits are available for retrieval; and
7.20.1.3
Notify the parties of the decision in writing (a letter to the parties or their
counsel shall suffice).
SERIAL 11086-RFP
7.21
7.20.2
Within ten (10) days of the notice of decision, either party may submit to the arbitrator(s)
a proposed form of award or other final disposition, including any form of award for
attorneys’ fees and costs. Within five (5) days of receipt of the foregoing, the opposing
party may file objections. Within ten (10) days of receipt of any objections, the
arbitrator(s) shall pass upon the objections and prepare a signed award or other final
disposition and mail copies to all parties or their counsel.
7.20.3
Any party which has appeared and participated in good faith in the arbitration
proceedings may appeal from the award or other final disposition by filing an action in
the state or federal court sitting in Maricopa County within twenty (20) days after date of
the award or other final disposition. Unless such action is dismissed for failure to
prosecute, such action will make the award or other final disposition of the arbitrator(s) a
nullity.
SEVERABILITY:
The invalidity, in whole or in part, of any provision of this Contract shall not void or affect the
validity of any other provision of this Contract.
7.22
RIGHTS IN DATA:
The County shall own have the use of all data and reports resulting from this Contract without
additional cost or other restriction except as provided by law. Each party shall supply to the other
party, upon request, any available information that is relevant to this Contract and to the
performance hereunder.
7.23
INTEGRATION:
This Contract represents the entire and integrated agreement between the parties and supersedes
all prior negotiations, proposals, communications, understandings, representations, or agreements,
whether oral or written, express or implied.
7.24
VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES §414401 AND FEDERAL IMMIGRATION LAWS AND REGULATIONS:
7.24.1
By entering into the Contract, the Contractor warrants compliance with the Immigration
and Nationality Act (INA using e-verify) and all other federal immigration laws and
regulations related to the immigration status of its employees and A.R.S. §23-214(A). The
contractor shall obtain statements from its subcontractors certifying compliance and shall
furnish the statements to the Procurement Officer upon request. These warranties shall
remain in effect through the term of the Contract. The Contractor and its subcontractors
shall also maintain Employment Eligibility Verification forms (I-9) as required by the
Immigration Reform and Control Act of 1986, as amended from time to time, for all
employees performing work under the Contract and verify employee compliance using the
E-verify system and shall keep a record of the verification for the duration of the
employee’s employment or at least three years, whichever is longer. I-9 forms are available
for download at USCIS.GOV.
7.24.2
The County retains the legal right to inspect contractor and subcontractor employee
documents performing work under this Contract to verify compliance with paragraph
7.24.1 of this Section. Contractor and subcontractor shall be given reasonable notice of the
County’s intent to inspect and shall make the documents available at the time and date
specified. Should the County suspect or find that the Contractor or any of its subcontractors
are not in compliance, the County will consider this a material breach of the contract and
may pursue any and all remedies allowed by law, including, but not limited to: suspension
of work, termination of the Contract for default, and suspension and/or debarment of the
SERIAL 11086-RFP
Contractor.
Contractor.
7.25
7.26
7.27
All costs necessary to verify compliance are the responsibility of the
VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES
§§35-391.06 AND 35-393.06 BUSINESS RELATIONS WITH SUDAN AND IRAN:
7.25.1
By entering into the Contract, the Contractor certifies it does not have scrutinized business
operations in Sudan or Iran. The contractor shall obtain statements from its subcontractors
certifying compliance and shall furnish the statements to the Procurement Officer upon
request. These warranties shall remain in effect through the term of the Contract.
7.25.2
The County may request verification of compliance for any contractor or subcontractor
performing work under the Contract. Should the County suspect or find that the Contractor
or any of its subcontractors are not in compliance, the County may pursue any and all
remedies allowed by law, including, but not limited to: suspension of work, termination of
the Contract for default, and suspension and/or debarment of the Contractor. All costs
necessary to verify compliance are the responsibility of the Contractor.
CONTRACTOR LICENSE REQUIREMENT:
7.26.1
The Respondent shall procure all permits, insurance, licenses and pay the charges and
fees necessary and incidental to the lawful conduct of his/her business, and as necessary
complete any required certification requirements, required by any and all governmental
or non-governmental entities as mandated to maintain compliance with and in good
standing for all permits and/or licenses. The Respondent shall keep fully informed of
existing and future trade or industry requirements, Federal, State and Local laws,
ordinances, and regulations which in any manner affect the fulfillment of a Contract and
shall comply with the same. Contractor shall immediately notify both Materials
Management and the using agency of any and all changes concerning permits, insurance
or licenses.
7.26.2
Respondents furnishing finished products, materials or articles of merchandise that will
require installation or attachment as part of the Contract, shall possess any licenses
required. A Respondent is not relieved of its obligation to posses the required licenses by
subcontracting of the labor portion of the Contract. Respondents are advised to contact
the Arizona Registrar of Contractors, Chief of Licensing, at (602) 542-1525 to ascertain
licensing requirements for a particular contract. Respondents shall identify which
license(s), if any, the Registrar of Contractors requires for performance of the Contract.
CERTIFICATION REGARDING DEBARMENT AND SUSPENSION
7.27.1
The undersigned (authorized official signing for the Contractor) certifies to the best of his
or her knowledge and belief, that the Contractor, defined as the primary participant in
accordance with 45 CFR Part 76, and its principals:
7.27.2
are not presently debarred, suspended, proposed for debarment, declared ineligible, or
voluntarily excluded from covered transactions by any Federal Department or agency;
7.27.3
have not within 3-year period preceding this Contract been convicted of or had a civil
judgment rendered against them for commission of fraud or a criminal offense in
connection with obtaining, attempting to obtain, or performing a public (Federal, State or
local) transaction or contract under a public transaction; violation of Federal or State
antitrust statues or commission of embezzlement, theft, forgery, bribery, falsification or
destruction of records, making false statements, or receiving stolen property;
7.27.4
are not presently indicted or otherwise criminally or civilly charged by a government
entity (Federal, State or local) with commission of any of the offenses enumerated in
paragraph (2) of this certification; and
SERIAL 11086-RFP
7.28
7.27.5
have not within a 3-year period preceding this Contract had one or more public
transaction (Federal, State or local) terminated for cause of default.
7.27.6
Should the Contractor not be able to provide this certification, an explanation as to why
should be attached to the Contact.
7.27.7
The Contractor agrees to include, without modification, this clause in all lower tier
covered transactions (i.e. transactions with subcontractors) and in all solicitations for
lower tier covered transactions related to this Contract.
PRICES:
Contractor warrants that prices extended to County under this Contract are no higher than those
paid by any other customer for these or similar services.
7.29
GOVERNING LAW:
This Contract shall be governed by the laws of the state of Arizona. Venue for any actions or
lawsuits involving this Contract will be in Maricopa County Superior Court or in the United States
District Court for the District of Arizona, sitting in Phoenix, Arizona
7.30
ORDER OF PRECEDENCE:
In the event of a conflict in the provisions of this Contract and Contractor’s license agreement, if
applicable, the terms of this Contract shall prevail.
7.31
INCORPORATION OF DOCUMENTS:
The following are to be attached to and made part of this Contract:
7.31.1
Exhibit A, Pricing;
7.31.2
Exhibit B, Scope of Work;
7.31.3
Exhibit C, Materials Management Contractor Travel and Per Diem Policy.
SERIAL 11086-RFP
IN WITNESS WHEREOF, this Contract is executed on the date set forth above.
CONTRACTOR
AUTHORIZED SIGNATURE
PRINTED NAME AND TITLE
ADDRESS
DATE
MARICOPA COUNTY
CHAIRMAN, BOARD OF SUPERVISORS
DATE
ATTESTED
CLERK OF THE BOARD
DATE
APPROVED AS TO FORM
LEGAL COUNSEL
DATE
SERIAL 11086-RFP
EXHIBIT 5
SECTION 01000
DETENTION AND SHERIFF”S OFFICE FACILITIES SECURITY GUIDELINES
Effective: 08/31/2010
SEE WORD DOCUMENT 11086-EXHIBIT 5
SERIAL 11086-RFP
EXHIBIT 6
VENDOR RESPONSE TOOL USER GUIDE
SEE WORD DOCUMENT 11086-EXHIBIT 6
SERIAL 11086-RFP
EXHIBIT 7
INTERFACE DETAILS & CONTACTS
SEE WORD DOCUMENT 11086-EXHIBIT 7