HomeMy WebLinkAboutRFP - P847 COMPUTER AIDED DISPATCHREF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2 GLOBAL SYSTEM SPECIFICATIONS
2-1 CAD FULL INTEGRATION
Full integration between CAD, mobile client (MDC’s) and Mapping is seen as a high
priority. Additionally, it is also highly desired that the CAD system be integrated with the
RMS/JMS, however integration with RMS/JMS is not as important as full integration
within the CAD environment.
2-2 RMS AND JMS FULL INTEGRATION
****CRITICAL FUNCTIONALITY**** Much of the RMS/JMS functionality is listed under
General System Requirements as the RMS/JMS system is required to be a fully
integrated system that shares the identical look and feel for both RMS and JMS. It is
understood that many vendors now consider the term “Integrated” to be seamlessly
interchangeable with the term “Interfaced” because of the perception on the part of
many buyers that integrated is better than interfaced. For the purposes of this RFP the
terms are not to be interchanged. To clarify these terms the participating agencies
define an integrated system as a RMS/JMS designed and programmed to function as a
single database, fully programmed and fully supported by a single vendor, with one
client, one name file, one vehicle file, one property file, one server, one database
engine, one operating system, and so on (the participating agencies reserve the right to
further define this term). Any proposed system or module that does not fall within this
definition is to be considered an “Interfaced” system.
Ideally the preferred system would have been designed and programmed from its
inception to be both a RMS and JMS so that all levels of development were completed
on a single database. If the proposed system was originally developed as two separate
systems that were then brought together at a later date this fact must be disclosed and
the process used to bring them together fully described. If any feature described in this
section operates differently in any way in RMS as opposed to JMS or if any feature
described is present in only RMS or JMS then that difference must also be clearly
identified and described.
Full integration in RMS/JMS is seen as a critical issue to the participating agencies.
Only those systems that have achieved high levels of integration between RMS and
JMS will be considered for purchase.
2-3 SYSTEM HARDWARE AND SOFTWARE
2-3.1 DOCUMENTATION 0 0 0 0
2-3.1 (1) The vendor shall supply comprehensive documentation for the proposed
CAD/RMS/JMS and associated applications which covers at least the following
subjects:
2-3.1 (1.1) System Use,
2-3.1 (1.2) System Administration (Server and workstation),
2-3.1 (1.3) Database Set up and Maintenance,
2-3.1 (1.4) Interface Design, Use and Maintenance,
2-3.1 (1.5) Report Creation And Maintenance,
2-3.1 (1.6) Documentation of the ad-hoc reporting system,
2-3.1 (1.7) and Backup and recovery functions.
2-3.1 (2) The proposed application documentation shall be consistent with the instructions
supplied by the on-line help systems for the application.
City of Fort Collins Page 1 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-3.1 (3) The vendor shall update documentation and all on-line help systems as needed when
any software changes occur.
2-3.2 HELP FUNCTIONS 0 0 0 0
2-3.2 (1) The CAD/RMS/JMS application shall provide on-line, field or context sensitive help for
all forms and commands.
2-3.2 (2) The system administrator or authorized users shall have the ability to add, modify and
delete the on-line, field or context sensitive help files.
2-3.3 HARDWARE SPECIFICATION - PRODUCTION DATABASE 0 0 0 0
It is expected that the vendor of the CAD/RMS/JMS will fully specify and cost all
needed server hardware and peripherals required to achieve a fully functioning system
as specified in this RFP. None the less, the participating agencies reserve the right to
purchase any and all server hardware and peripherals at their discretion without
negatively impacting the remaining costs for software, installation, training, support, or
any other vendor provided good or services.
2-3.3 (1) The proposing vendor shall allow and support, at the discretion of the participating
agencies, the direct acquisition of all server hardware and peripherals by the
participating agencies from sources other than through the proposing vendor.
2-3.3 (2) The proposing vendor shall allow such acquisition server hardware and peripherals
without imposing any additional fees of any kind to the participating agencies.
2-3.3 (3) ****CRITICAL FUNCTIONALITY**** The hardware platform for the CAD/RMS/JMS
shall be either an IBM AS400 (OS400) or Sun Microsystems (Unix) server.
2-3.3 (4) Server redundancy is expected; no single production server failure shall render the
CAD/RMS/JMS non-functional.
2-3.3 (5) Expected topology for CAD is for the primary CAD functions to operate on a server
housed at the Fort Collins Police Services building, with fail over to a server running at
the Larimer County Sheriff's Office.
2-3.3 (6) Expected topology for RMS/JMS is for primary RMS/JMS functions to operate on a
server housed at the Larimer County Sheriff's Office building, with fail over to a server
running at Fort Collins Police Services.
2-3.3 (7) System servers shall be sized to ensure rapid response to standard user query and
entry (rapid response is considered an average of one second response).
2-3.3 (8) System servers shall be specified with sufficient storage to maintain a minimum of 15
years of online data for all applications, all participating agencies.
2-3.3 (9) Vendor must provide an electronic diagram of the topology of all proposed hardware
that identifies all components and clearly identifies their purpose.
2-3.4 HARDWARE SPECIFICATION - CRIME ANALYSIS DATABASE 0 0 0 0
2-3.4 (1) It is expected that an additional server intended for Crime Analysis personnel to
perform extended database queries will be specified so that the production database
performance is not degraded. This server will be specified to house a database of all of
the CAD/RMS/JMS files that are not protected by restricted user access (intelligence
files, confidential reports, etc.).
2-3.4 (2) The hardware platform for the CAD/RMS/JMS Crime Analysis database shall conform
to industry standard server architecture that utilizes Microsoft Windows® 2000 server
OS or the same operating system as the production server.
2-3.5 HARDWARE SPECIFICATION - DESK & MOBILE WORKSTATIONS 0 0 0 0
City of Fort Collins Page 2 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
The participating agencies currently own a variety of industry standard, IBM
compatible, micro computer hardware and peripherals. It should be expected that the
participating agencies will acquire any additional needed micro computer hardware and
peripherals from sources other than the proposing vendor. The intent of this
specification is to establish the minimum configuration of user hardware the vendor
would require to ensure full operational capability from all software that the vendor
would provide. Full operational capability is defined as all functions of the software
being available to the user with load and run times not to exceed 10 seconds, and
operational screen paints and forms selection to occur with no appreciable delay (within
one second). Vendor should assume their software will be running with other high end
software in a multitasking environment.
2-3.5 (1) The proposing vendor shall specifically allow and support the direct acquisition of all
IBM compatible, industry standard, micro computer hardware and peripherals by the
participating agencies from sources other than through the proposing vendor.
2-3.5 (2) The proposing vendor shall allow such acquisition of IBM compatible, industry
standard, micro computer hardware and peripherals without imposing any additional
fees of any kind to the participating agencies.
2-3.5 (3) All client services shall run with full operational capabilities on a desktop computer with
an Intel Pentium III processor (or greater) running at 400 MHz (or greater), with a 20
Gigabyte (or greater) hard drive (loaded to 40% capacity before vendor’s software is
loaded), with 112 Megabyte (or greater) of system RAM, with 8 Megabyte (or greater)
video RAM, with a 16x (or greater) CD ROM drive, with 3½" floppy drive, with a 17"
SVGA (or greater) capable monitor (CRT or LCD), with basic integrated sound (or
greater), with 101 key industry standard keyboard, with a two button mouse or pointing
device.
2-3.5 (3.1) If the vendor can’t achieve full operational capabilities with the defined desktop
hardware the vendor must provide a complete specification of the minimum required
hardware that will achieve full operational capabilities.
2-3.5 (3.2) If the vendor can’t achieve full operational capabilities with the defined desktop
hardware the vendor must detail the level of operational capability that can be achieved
with the defined desktop configuration.
2-3.5 (4) All client services shall run with full operational capabilities on a notebook computer
with an Intel Pentium III processor (or greater) running at 400 MHz (or greater), with a
20 Gigabyte (or greater) hard drive (loaded to 40% capacity before vendor’s software is
loaded), with 112 Megabyte (or greater) of system RAM, with a 16x (or greater) CD
ROM drive, with 3½" floppy drive (swap out with CD ROM drive), with a 12" LCD
display (or greater), with basic integrated sound (or greater), with built in compressed
keyboard, with a two button pointing device.
2-3.5 (4.1) If the vendor can’t achieve full operational capabilities with the defined notebook
hardware the vendor must provide a complete specification of the minimum required
hardware that will achieve full operational capabilities.
2-3.5 (4.2) If the vendor can’t achieve full operational capabilities with the defined notebook
hardware the vendor must detail the level of operational capability that can be achieved
with the defined notebook configuration.
2-3.5 (5) The system shall support the connection, setup, control and formatting of print jobs to
the following:
City of Fort Collins Page 3 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-3.5 (5.1) LaserJet printers (sheet feed) (duplex) (both black and white and color),
2-3.5 (5.2) Dot matrix printer (continuous sheet feed),
2-3.5 (5.3) Dot matrix or DeskJet printer (continuous label feed),
2-3.5 (5.4) DeskJet printer (sheet feed) (both black and white and color),
2-3.5 (5.5) Dye sublimation printer (sheet feed) (both black and white and color),
2-3.5 (5.6) Dye sublimation printer (PVC card feed) (both black and white and color),
2-3.5 (5.7) Citation printer (mobile printer in the car) (must be defined by the vendor),
2-3.5 (5.8) and DesignJet 36" plotter (continuous roll feed).
2-3.5 (6) In addition to standard input devices (keyboard, pointing device, disk drives, etc.) the
system shall accept inputs from (and provide the ability to control as needed) a variety
of input devices as follows:
2-3.5 (6.1) Flatbed scanner,
2-3.5 (6.2) Flatbed scanner with automatic feed,
2-3.5 (6.3) High-speed duplex scanner,
2-3.5 (6.4) Barcode scanner (handheld, off and online capture),
2-3.5 (6.5) Digital camera,
2-3.5 (6.6) Live video capture,
2-3.5 (6.7) Microphone audio,
2-3.5 (6.8) and Line audio.
2-3.6 NEARLINE ARCHIVE STORAGE 0 0 0 0
2-3.6 (1) The system shall have the ability to fully support nearline archival and storage of aged
data as defined and controlled by the participating agencies.
2-3.6 (2) It is anticipated that the proposed nearline storage system shall use high density optical
storage media (other media may be proposed for consideration but the media or data
must be portable for off site storage).
2-3.6 (3) The system shall automatically move data from online to nearline, build and maintain all
indexes to the nearline data, and allow for basic system searches (name, MNI, case
(report) number, booking number, incident number, location, etc.) to identify the
availability of nearline data.
2-3.6 (4) Upon user request the system shall automatically reload requested nearline data to the
online system, destroy all indexes to the nearline data, and set a new aging date for
future re-archival of that data.
2-3.6 (5) No data shall archive to the nearline system that is still being actively modified
regardless of aging date (active is defined as modified within the last six months).
2-3.6 (6) The system shall have the ability to fully purge all reference to nearline data at system
administrator request (i.e. destroy all reference to a disc that is scheduled for
destruction due to age of data).
2-3.7 BACKUP STRATEGY 0 0 0 0
2-3.7 (1) All software and data of any kind residing on any server or storage system proposed by
the vendor shall have a system and methodology to make backup copies of that
software and data.
2-3.7 (2) Backup systems must batch process all backups so that software and data is not held
at risk in a continuous write state on any server or storage device (backup media must
be freed by the system for offsite storage in a timely manner).
City of Fort Collins Page 4 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-3.7 (3) Backup process must have the ability to make multiple copies of the same data for
storage at multiple locations.
2-3.7 (4) Backup schedules must be definable and controllable by the participating agencies.
2-3.7 (5) The vendor must provide the ability to the participating agencies to restore any
software or data at the discretion of the participating agencies’ system administrators.
2-3.7 (6) The vendor must provide the ability to the participating agencies to test the backups of
any software or data at the discretion of the participating agencies’ system
administrators.
2-3.8 OPERATING SYSTEMS 0 0 0 0
2-3.8 (1) CAD/RMS/JMS production server operating system must be IBM AS400 OS or Sun
Microsystems Solaris 8 Unix (latest versions).
2-3.8 (2) Crime analysis server must use an industry standard operation system.
2-3.8 (3) Network attached workstations will use the Microsoft Windows® operating system in
versions, 98, ME, NT40 sp6, 2000 sp2, and XP Professional. All proposed workstation
software must run in these versions of windows.
2-3.8 (4) Notebook computer systems will use the Microsoft Windows® operating system in
versions, 98, 2000 sp2, and XP Professional. All proposed workstation software must
run in these versions of windows.
2-3.9 DATABASE AND SOFTWARE SPECIFICATIONS 0 0 0 0
2-3.9 (1) The proposed CAD/RMS/JMS application shall include a graphical user interface for all
client operations.
2-3.9 (2) The design of the user interface will assist both experienced and novice users to
complete individual system functions.
2-3.9 (3) ****CRITICAL FUNCTIONALITY**** CAD/RMS/JMS production database management
system must be IBM DB2 or Oracle (latest versions).
2-3.9 (4) Crime analysis database must be an industry standard database that performs in an
open system architecture, storing all data in a non-proprietary format, across several
hardware platforms, that supports all modern third party reporting and analysis tools.
2-3.9 (5) All databases specified by the vendor database shall be SQL compliant.
2-3.9 (6) All databases specified by the vendor must support ODBC industry standards.
2-3.9 (7) Vendor must provide a diagram of the database structure down to the field level.
2-3.9 (8) Vendor must have provisions in place to protect all custom features and configurations
of the system throughout an upgrade process without incurring additional cost to the
participating agencies to re-establish custom features or configurations.
2-3.9 (9) It is preferred that all application support Microsoft Windows® printing.
2-3.9 (10) The proposed CAD/RMS/JMS application shall allow the user to change the default
printer.
2-3.9 (11) Vendor must be willing to identify the programming language of all application
software.
2-3.9 (12) Vendor must be willing to (at minimum) escrow the source code for all application
programming.
2-3.9 (13) The proposed CAD/RMS/JMS application database shall have the ability to store
electronic attachments of all kinds (word documents, multimedia files, etc.).
2-3.9 (14) The proposed CAD/RMS/JMS application database shall have the ability limit the size
of electronic attachments of all kinds (word documents, multimedia files, etc.).
City of Fort Collins Page 5 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-3.9 (15) The proposed application shall employ a combination of field-level locking and record
level locking. Example; so that two users can retrieve, view, and add report narratives
at the same time, but two users cannot retrieve, view, and edit different parts of a single
form at the same time.
2-3.9 (16) The proposed CAD/RMS/JMS application shall have a simple means of exporting data
and search results in common formats such as ASCII text, .pdf, .dbf, etc.
2-3.9 (17) The proposed CAD/RMS/JMS application shall allow the participating agencies to
design and add their own data fields to the existing application (the vendor shall explain
any consequences or limitations resulting from the addition of new fields to the system).
2-3.9 (18) The proposed application shall allow the system administrator or other authorized user
to add new data elements to the database, to forms, or to report formats.
2-3.9 (19) The proposed application shall allow the system administrator or other authorized user
to modify the layout and data elements displayed on vendor supplied forms and screen
masks.
2-3.9 (20) The proposed CAD/RMS/JMS application shall allow the system administrator or other
authorized user to create macros for completing common user functions.
2-3.9 (21) The proposed application shall allow the system administrator or other authorized user
to add an internally developed report, macro, or other functions to the application
menu.
2-3.9 (22) There shall be no limits imposed on forms attached to master case records. For
example, there shall be no limits on the number of persons, items of property,
statements, arrest reports, suspect descriptions, or supplemental reports.
2-3.10 NETWORK PROTOCOL 0 0 0 0
2-3.10 (1) The only acceptable mid-layers network communications protocol is TCP/IP. All
communications hardware and software (including all interfaces) must be capable of
utilizing a modern, shared, wide area network (wired or wireless) with TCP/IP as the
only communications protocol.
2-3.11 Y2K COMPLIANCE 0 0 0 0
2-3.11 (1) The vendor must warrant that the hardware, software, firmware, or supplies delivered,
or services performed are “Year 2000 compliant.” “Year 2000 compliant” means fault-
free performance in the processing of date and date-related data (including, but not
limited to calculating, comparing, and sequencing) by all hardware, software, firmware,
and supplies, individually and in combination as a system, when used in accordance
with the product documentation provided by the vendor. Fault-free performance means
no invalid or incorrect results or abnormal termination as a result of date or date-related
data or data processing that represents or references different centuries or more than
one century; and proper calculation and handling of leap years; and except for normal
user interfaces (e.g. four digit date entry) identified in the contractor’s or vendor’s
documentation. Such date data processing shall be transparent to the user.
2-3.12 SYSTEM IMPLEMENTATION
City of Fort Collins Page 6 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
Upon contract award, the vendor will be responsible for developing an
installation/integration plan. The plan will be reviewed and must be approved by the
participating agencies’ Project Management Team. The plan must detail the tasks to be
accomplished, milestones/deliverables, the required resources (both Agencies and
Vendor), and a project schedule/timeline. Payments to the Vendor will be tied to
milestones/deliverables.
The first milestone will be a 30 day trial evaluation of the system. The Vendor will
install the hardware and software onsite and provide in-depth training for a subset of
users. A trainer will remain onsite for full-time operational oversight for the 30 days.
During the 30-day trial, acceptance testing will be conducted by the Agencies’ Project
Team.
Acceptance tests must demonstrate that all software components function in
accordance with the contract and all requirements have been successfully met.
Acceptance tests must demonstrate that all software components acquired function
separately and interact appropriately.
Items that do not pass acceptance testing will be documented and submitted to the
Vendor as soon as they are apparent to the Agencies. The Vendor will have the
opportunity to respond to the noted deficiency. The Vendor’s response must include
details on how the deficiency will be rectified, including a timeline for completion of the
modification. Failure to respond to, or rectify, a noted deficiency within 30 days of
notification will likely result in the termination of the contract.
Installation shall be considered complete only when all software acquired has been
installed and a full set of acceptance tests are successfully conducted jointly by the
vendor and the Agencies.
Costs for training and oversight during the 30 day trial must be separately itemized in
the cost proposal. Since the installation for the 30 day trial will be the final location of
the system, the Agencies do not expect to incur installation costs above and beyond
those proposed for the typical installation. If the contract is terminated during, or
immediately following, the 30 day trial, the Agencies will reimburse the Vendor only for
the actual costs of the training, oversight and installation services performed. No
hardware or software costs will be reimbursed. All estimates and actual cost
notwithstanding the participating agencies limit their liability for this 30 day acceptance
evaluation to no more than $20,000.00.
2-3.13 SYSTEM WARRANTY 0 0 0 0
2-3.13 (1) Vendor must furnish with the proposal an explanation of both contractor’s and
manufacturer’s warranties for the proposed hardware and software solution(s) and shall
indicate any cost during warranty period to the participating agencies, including
shipping costs. A minimum of one (1) year to a maximum of (5) warranty shall be
proposed with all costs identified per annum.
2-3.13 (2) Vendor must initially provide two (2) years of support with this acquisition and fix the
price for support for an additional 3 years (all costs must be identified).
2-3.13 (2.1) Support must be available on a 24 X 7 (twenty-four (24) hours a day, seven (7) days a
week) basis for both hardware and software solution(s). The maintenance period must
be in addition to the warranty period. Support and maintenance must include the
following:
2-3.13 (2.1.1) Fixed support service costs for term of agreement (5 years),
City of Fort Collins Page 7 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-3.13 (2.1.2) Include travel & per diem,
2-3.13 (2.1.3) On-site response time of forty-eight (24) hours from time of request,
2-3.13 (2.1.4) Contact response time of four (4) hours,
2-3.13 (2.1.5) An assigned engineer to the account,
2-3.13 (2.1.6) Automatic software updates and installation,
2-3.13 (2.1.7) Unlimited telephone access to support center/engineers,
2-3.13 (2.1.8) and Software problem solving and usage assistance.
2-3.14 SYSTEM TRAINING 0 0 0 0
2-3.14 (1) Training is in addition to the training provided during the 30 day system acceptance
evaluation training and must be provided just prior to full implementation (go live) of
each software module per agency.
2-3.14 (2) Vendor must provide both Technical & System Operations Training and End-User
Training.
2-3.14 (3) Vendor must provide training schedule within constraints of project schedule.
2-3.14 (4) Training must include all phases of software operation, daily maintenance, system start
-up & shut-down procedures.
2-3.14 (5) Training must provide adequate knowledge transfer for participating agencies to
provide management and support of software upon project implementation.
2-3.14 (6) Vendor must provide costs and details for each training class to include:
2-3.14 (6.1) Each level of training,
2-3.14 (6.2) For each level, experience level required for persons being trained,
2-3.14 (6.3) Number of instruction hours/days and sessions required for each level,
2-3.14 (6.4) Description of class content,
2-3.14 (6.5) Class size for hands on (max 10),
2-3.14 (6.6) Class size for classroom only (max 40 persons),
2-3.14 (6.7) Identify instructor(s) scheduled to conduct training,
2-3.14 (6.8) Provide instructor qualifications,
2-3.14 (6.9) And Include contractor travel costs and all associated costs in cost of class.
2-3.14 (7) All training participants must be supplied a copy of training materials.
2-3.14 (8) Training materials must be customized for the implemented solution (including all
custom interfaces).
2-3.14 (9) Vendor must conduct training classes on-site in Ft. Collins (Training Lab provided by
the Agencies).
2-4 SYSTEM ADMINISTRATION
2-4.1 GENERAL SYSTEM SECURITY 0 0 0 0
2-4.1 (1) The proposed system administration interface shall be a graphical application.
2-4.1 (2) All lookup tables, agency defined values, configuration settings, etc. are to be fully
controlled and maintained by the participating agencies system administrators, not by
the vendor’s personnel at a cost for each change.
2-4.1 (3) The proposed system shall include a sophisticated security module which controls the
user’s ability to:
2-4.1 (3.1) create,
2-4.1 (3.2) read,
2-4.1 (3.3) write,
City of Fort Collins Page 8 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-4.1 (3.4) modify (edit),
2-4.1 (3.5) print,
2-4.1 (3.6) delete,
2-4.1 (3.7) and file scan,
2-4.1 (3.8) or email reports.
2-4.1 (4) The above security module controls shall apply to all of the vendor supplied:
2-4.1 (4.1) applications,
2-4.1 (4.2) forms,
2-4.1 (4.3) fields,
2-4.1 (4.4) reports,
2-4.1 (4.5) interfaces, and
2-4.1 (4.6) other input or output mechanisms.
2-4.1 (5) The proposed application shall provide security for both the operating system and
database management software to prevent unauthorized persons from accessing data
by circumventing the application.
2-4.1 (6) The system shall have the ability for the system administrator to define any database
field as mandatory.
2-4.1 (7) The system shall be able to “highlight” (or otherwise indicate) any mandatory fields
when any entry form is opened.
2-4.1 (8) If data is not entered in these fields, it should automatically stand out or be flagged
during the review process.
2-4.1 (9) The proposed application shall allow these fields to be customized to users needs to
ensure certain data is being captured.
2-4.1 (10) The system shall have the ability to perform all operations, dependant on operator
security, at any client location, including simultaneous identical operations at one time.
2-4.1 (11) The system shall have the ability to limit operational capabilities by the physical location
of the client.
2-4.1 (12) It is preferred that the system have the ability to define system administrators with
varying capabilities (multi-level administration).
2-4.1 (13) The proposed CAD/RMS/JMS application must be permission based, allowing the
system administrator or other authorized user to develop security profiles for groups of
like users.
2-4.1 (14) The proposed system shall allow the system administrator or other authorized user to
assign any number of users to a given security profile.
2-4.1 (15) It is preferred that the proposed CAD/RMS/JMS application allow for drag and drop of
individuals into different security profiles if they change positions within the department.
2-4.1 (16) The proposed system shall allow the system administrator or other authorized user to
assign a user to more than one security profile.
2-4.1 (17) The proposed system shall allow the system administrator or other authorized user to
retrieve, modify and save a security profile under a new name.
2-4.1 (18) The proposed application shall allow for each participating agency jurisdiction in the
database the ability to define and allow different users, agency information and
configuration.
City of Fort Collins Page 9 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-4.1 (19) The proposed system shall require users to have a valid security profile, user name
and password on file prior to being able to logon to and use any vendor supplied
application.
2-4.1 (20) The proposed system shall allow users to change their own password at any time.
2-4.1 (21) The proposed application will maintain a complete audit trail of all user actions
including:
2-4.1 (21.1) date and time of each user login and log off,
2-4.1 (21.2) case records or forms accessed, and
2-4.1 (21.3) crime and event reports printed.
2-4.1 (21.4) The system administrator or authorized user shall have the ability to choose whether to
use this feature on a function basis.
2-4.1 (21.5) This function shall be available for export from the log file.
2-4.1 (21.6) The proposed application will maintain a complete audit trail of all changes to CAD
records, database records or forms changed, including the following information:
2-4.1 (21.7) identification of the user making the change,
2-4.1 (21.8) identification of the record being changed,
2-4.1 (21.9) the old and new value of the field changed, and
2-4.1 (21.10) the date, time and location from which the changes were made.
2-4.1 (22) The proposed application should allow the user to select what is displayed when the
audit trail is displayed. For example, only logons and logoffs.
2-4.1 (23) The proposed application shall automatically purge the audit trail information after a
period set by the system administrator.
2-4.2 CAD SPECIFIC SECURITY FUNCTIONS 0 0 0 0
2-4.2 (1) The proposed CAD application shall include a function for defining which incident types
automatically generate a case (report) number.
2-4.2 (2) At the application level the CAD system shall secure access to the following:
2-4.2 (2.1) CAD commands,
2-4.2 (2.2) function or hot keys,
2-4.2 (2.3) and individual interfaces.
2-4.3 RMS/JMS SPECIFIC SECURITY FUNCTIONS 0 0 0 0
2-4.3 (1) The proposed RMS/JMS application shall include automated and semi-automated
routines to assist the system 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 proposed application shall 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.
2-4.3 (2) The proposed RMS application shall allow the system administrator or other authorized
user to define which fields are mandatory based on:
2-4.3 (2.1) The event,
2-4.3 (2.2) Incident type, or
2-4.3 (2.3) Offense type
2-4.3 (3) The proposed JMS application shall allow the system administrator or other authorized
user to define which fields are mandatory based on booking type.
City of Fort Collins Page 10 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-4.3 (4) The proposed application shall provide the system administrator or other authorized
user with a log which lists the CAD records which were transferred to RMS and if there
were any errors in the transfers.
2-4.3 (5) The proposed RMS/JMS application shall include a table for converting state and
municipal statute codes to the appropriate IBRS code.
2-4.3 (6) The proposed RMS application shall include a configuration table that allows the
system administrator or authorized user to determine the routing of case reports to
named persons, or to position titles based on the:
2-4.3 (6.1) Offense type, or
2-4.3 (6.2) The location of the offense, or
2-4.3 (6.3) Officer ID.
2-4.3 (7) The proposed RMS application shall include a configuration table that allows the
system administrator or other authorized user to determine the copying of case reports
to named persons, or to position titles based on the:
2-4.3 (7.1) Offense type, or
2-4.3 (7.2) The location of the offense.
2-4.3 (8) The proposed RMS application shall allow for distribution to named persons or position
titles for printed reports.
2-4.3 (9) The proposed RMS application shall allow the system administrator or other authorized
user to define position titles and associate them with named individuals.
2-4.3 (10) The proposed RMS/JMS application shall allow the system administrator or other
authorized user to define the chain of command, i.e. who reports to whom, so that
reports can be routed to the correct supervisor.
2-4.3 (11) The proposed RMS/JMS application shall be able to flag offenses involving juveniles
based on age at time of occurrence versus offenses involving adults.
2-4.3 (12) The proposed RMS/JMS application shall have the ability to expunge records from the
database. When records are expunged, they shall no longer be retrievable by the
name associated with the expunged record. However, they must still be accessible for
law enforcement purposes.
2-4.3 (13) The proposed RMS application shall record the date, time, and user ID for all report
holds and releases.
2-4.3 (14) The proposed RMS application shall allow the investigator assigned to a case or
his/her supervisor to limit access to a selected investigation to named individuals.
2-4.3 (15) The proposed RMS application shall include the ability to classify cases (e.g. special,
sexual violence or narcotics).
2-4.3 (15.1) The proposed RMS application shall allow the system administrator to determine
access to for each case classification.
2-4.4 PERSONNEL MODULE SPECIFIC SECURITY FUNCTIONS 0 0 0 0
2-4.4 (1) The proposed application shall provide sufficient security to prevent employee records
from being viewed by anyone other than the employee or appropriate supervisory or
managerial employees.
2-5 SYSTEM INTERFACE SPECIFICATIONS
City of Fort Collins Page 11 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
Prices must include costs for the following interfaces. Interface prices should detail any
known expenses that you will expect the participating agencies to meet, including costs
with other vendors, communication line costs, etc. All costing must be broken out by
interface with the specific understanding that the participating agencies may accept or
reject having the vendor complete each interface on a case by case basis.
2-5.1 GENERAL REQUIREMENTS 0 0 0 0
2-5.1 (1) In the event that an interfaced system to which the CAD/RMS/JMS is connected to
becomes unavailable, the CAD/RMS/JMS shall notify the logged on users and system
administrator or other authorized user that the interfaced system is failing to respond.
2-5.1 (1.1) In the event that a user logs onto the system after the notification of failure has been
sent, and that user then attempts to use the failed interface, the system shall clearly
respond to that user with the notification of failure.
2-5.1 (1.2) Prior to transmitting any additional inquiries to the remote system the CAD/RMS/JMS
applications shall make periodic attempts to reestablish communications, and when
successful, notify the logged on users that the interface is working again.
2-5.1 (1.3) In the event that any transactions were submitted but not completed prior to the failure
of a remote system, the system shall complete the inquiries once the remote system
resumes operation.
2-5.2 COMPUTER AIDED DISPATCH
Because it is highly desired for the successful RMS/JMS vendor to also be the vendor
for a new CAD system for all participating agencies there will probably be no need for
any CAD interface. However the vendor must provide separate costing for each of two
possible scenarios:
All participating agencies will use the CAD system provided by the same vendor as
RMS/JMS.
All participating vendors will use a CAD system provided by another vendor.
In all cases the proposed RMS/JMS must be able to receive electronically transferred
call related information from the CAD system(s) used by all participating agencies to
start the case reporting or booking process within the vendors RMS/JMS.
2-5.3 E911 INTERFACE 0 0 0 0
2-5.3 (1) ****CRITICAL FUNCTIONALITY**** The proposed application shall be APCO phase II
wireless compliant.
2-5.3 (2) The proposed application shall be interfaced with Plant Equipment Vesta 911
controllers at several agencies. At a minimum the interface shall support the following
features:
2-5.3 (2.1) The CAD system shall be able to receive ANI/ALI information directly from the 911
controller, transfer it to the CAD position which is handling the voice call associated
with the ANI/ALI record, and insert the data in the appropriate fields on the new call
form.
2-5.3 (2.2) The CAD shall be able to receive and include in each call record the time that the call
taker received the 911 call.
2-5.4 ProQA INTERFACE 0 0 0 0
2-5.4 (1) ****CRITICAL FUNCTIONALITY**** The proposed application shall provide an
interface for Medical Priority Dispatch ProQA software.
2-5.4 (1.1) When a medical call is received, the dispatcher shall be able to access this software
with one key or keystroke combination.
City of Fort Collins Page 12 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-5.4 (1.2) All pertinent information including times shall be automatically transferred from the
ProQA software to the incident audit trail
2-5.4 (1.3) The transfer of this information shall be done so the information is easily decipherable
by field units utilizing mobile terminals.
2-5.4 (1.4) The application shall allow ProQA to be accessible as a stand-alone program should
the CAD application crash for any reason.
2-5.5 TDD INTERFACE 0 0 0 0
2-5.5 (1) The proposed application shall be interfaced with Plant Equipment Vesta phone system
at several agencies so as to support full TDD capabilities on the CAD client. At a
minimum the interface shall support the following features:
2-5.5 (1.1) Transfer a TDD call that was initiated on the VESTA console to the CAD client,
2-5.5 (1.2) Allow for full two way communication with the TDD caller using the keyboard that drives
the CAD client,
2-5.5 (1.3) Provide with a pop up window on the CAD client computer to display the conversation
that can be positioned and sized at the dispatcher’s discretion,
2-5.5 (1.4) and Record both incoming and outgoing text in the audit trail of the CAD system.
2-5.6 MASTER TIMING SOURCE 0 0 0 0
2-5.6 (1) The proposed system shall receive and incorporate a master timing signal from the
Spectracom Netclock II master timing device that is used by most of the participating
agencies such that the times recorded by all applications do not differ from those found
on any other system connected to the master timing source.
2-5.7 CCIC/NCIC INTERFACE 0 0 0 0
This is the interface to the state criminal computer system. The interface must provide
for a mechanism to most functions of the CCIC system through the same user client
that is used for CAD/RMS/JMS.
2-5.7 (1) The proposed system shall include an interface to the Colorado Crime Information
Center and the National Crime Information Center (CCIC/NCIC).
2-5.7 (2) The proposed application shall conform to the Colorado Bureau of Investigation’s
requirements for exchanging data between the vendor’s system and the CCIC.
2-5.7 (3) The proposed application shall communicate to the Colorado Bureau of Investigation
by utilizing the modern network infrastructure provided be the CBI to the participating
agencies using TCP/IP communication protocols.
2-5.7 (4) The proposed application shall conform to NCIC 2000 system standards.
2-5.7 (5) The proposed system shall include a message switching function such that when a
desktop or mobile user submits an inquiry to RMS/JMS which is also supported by
CCIC/NCIC, the system can (at the participating agencies discretion) automatically
initiate and transmit that inquiry to CCIC/NCIC
2-5.7 (6) The proposed system shall allow authorized users of any application or module to
initiate and complete any CCIC/NCIC supported inquiry, update or message.
2-5.7 (7) At a minimum the proposed system shall provide access to the following CCIC/NCIC
inquiries via a form for all users and additionally from the command line for CAD users:
2-5.7 (7.1) Generate Hit Confirmation,
2-5.7 (7.2) Enter/Modify/Cancel/Locate Vehicle,
2-5.7 (7.3) Enter/Modify/Cancel/Locate Missing Person,
2-5.7 (7.4) Enter/Modify/Cancel/Locate Warrant,
City of Fort Collins Page 13 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-5.7 (7.5) Enter/Modify/Cancel/Clear/Locate Sex Offender,
2-5.7 (7.6) Query Criminal History,
2-5.7 (7.7) Query Rap Sheet,
2-5.7 (7.8) Enter/Modify/Cancel/Locate Articles,
2-5.7 (7.9) Enter/Modify/Cancel/Locate Guns,
2-5.7 (7.10) TID Query,
2-5.7 (7.11) Query Driver’s History,
2-5.7 (7.12) Driver License Query,
2-5.7 (7.13) BOLO Form,
2-5.7 (7.14) Query Query,
2-5.7 (7.15) Query Driver Alpha,
2-5.7 (7.16) Query Social Security Numbers.
2-5.7 (8) The proposed system shall automatically route information entered into a CCIC/NCIC
inquiry or update form to CCIC/NCIC in a format acceptable to CCIC/NCIC.
2-5.7 (9) The CCIC/NCIC interface shall maintain a log of all inquiries, updates, and messages
sent to CCIC/NCIC via the interface.
2-5.7 (10) The CCIC/NCIC interface shall maintain a log of all response to inquiries, updates, and
messages sent to CCIC/NCIC via the interface.
2-5.7 (11) The proposed CCIC/NCIC interface shall allow a user to search previous CCIC/NCIC
inquiries records at a later date with the following search keys:
2-5.7 (11.1) vehicle license plate number,
2-5.7 (11.2) boat registration number,
2-5.7 (11.3) subject name or alias, race, gender and date of birth,
2-5.7 (11.4) subject Social Security number,
2-5.7 (11.5) gun serial number and manufacturer,
2-5.7 (11.6) article serial number and manufacturer,
2-5.7 (11.7) Vehicle Identification Numbers,
2-5.7 (11.8) and Operator License Number.
2-5.7 (12) In addition to the above it would be preferred that the proposed CCIC/NCIC interface
will allow a user to search previous CCIC/NCIC inquiries records at a later date with the
following search keys:
2-5.7 (12.1) date of inquiry,
2-5.7 (12.2) time range,
2-5.7 (12.3) initiating officer,
2-5.7 (12.4) or initiating unit number,
2-5.7 (12.5) initiating agency.
2-5.7 (13) The proposed application shall allow for no fewer than eight pre-defined response
forms. These forms are for responding to another agencies query on wants/warrants or
stolen items etc.
2-5.8 SUNPRO FIRE RECORDS MANGEMENT SYSTEM 0 0 0 0
2-5.8 (1) The vendor shall supply an interface to the existing Poudre Fire Authority SunPro RMS
which provides the following capabilities:
2-5.8 (1.1) Transfer of all CAD incident information that is required by the SunPro RMS.
2-5.9 TONING/PAGER INTERFACES 0 0 0 0
City of Fort Collins Page 14 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
The CAD/RMS/JMS system must be interfaced to a number of toning/paging systems
and services. Most notably the Zetron model 25 and 26 Fire Station toners used by the
PFA, and the Zetron model 2200 paging terminal used by Larimer County.
2-5.9 (1) The proposed system shall incorporate an interface to the Zetron model 25 and 26 Fire
Station toners used by the PFA. The interface should utilize all available features of
these systems provide.
2-5.9 (2) The proposed system shall incorporate an interface to the Zetron model 2200 paging
terminal used by Larimer County. The interface should utilize all available features of
this system provides.
2-5.9 (3) The proposed system shall incorporate an interface to commercial paging systems
such as Metrocall, AT&T, Page One, Nextel, etc.
2-5.9 (3.1) It is expected that the vendor will identify paging companies in use by the participating
agencies to ensure that all desired interfaces are accomplished (the vendor can
assume four interfaces for RFP costing).
2-5.9 (3.2) These interfaces must be fully achieved by the vendor without the participating
agencies involvement (beyond a letter of request).
2-5.9 (3.3) It is expected that the vendor will identify all resources, costs (installation and ongoing)
and necessary agreements to achieve these interfaces.
2-5.10 COLORADO IBRS AND NIBRS 0 0 0 0
2-5.10 (1) The proposed system must be able to interface to the CBI in such a way that the data
required by the state to satisfy the statistical reporting need of the Colorado IBRS
program and National Incident Based Reporting System (NIBRS) are satisfied without
ongoing intervention by the system administrators.
2-5.11 DOCUMENT IMAGING (FCPS AND LCSO) 0 0 0 0
The City of Ft. Collins standard electronic document management software (EDMS)
system is SIRE File Center and SIRE Capture from AlphaCorp (www.alphacorp.cc).
This system is planned for deployment in the Police Department on July 1, 2002.
The county has designated that the standard electronic document management
software (EDMS) to be utilized countywide is FileNET’s Content Services 5.2, eProcess
Service 3.2, and Workflo 4.2 (utilizing SQL Server 2000) with Kofax Ascent Capture 5.5
software. The implementation of the system at the Sheriff’s office will begin prior to the
implementation of the CAD/RMS/JMS.
The proposer is expected to utilize and interface with these EDMS systems for the
management of images and documents captured as part of the CAD/RMS/JMS.
2-5.11 (1) The proposed application shall use FileNET Content Services for the County Sheriff to
manage graphical images such as floor plans, aerial photographs, and diagrams.
2-5.11 (2) The proposed application shall use AlphaCorp's SIRE for the City Police Department to
manage graphical images such as floor plans, aerial photographs, and diagrams.
2-5.11 (3) The proposed application shall provide search, retrieval and display of images,
regardless of their location (FileNET or SIRE), to allow sharing of images between
organizations. Describe the proposed method for accomplishing this requirement.
2-5.11 (4) It is preferred that the proposed application not require a separate logon to access
images in either imaging system.
2-5.11 (5) The CAD/RMS/JMS shall allow the proposed application to provide the direct retrieval
of any associated images from a record that is currently viewed (e.g. incident report)
rather than performing a separate search for the image.
City of Fort Collins Page 15 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-5.11 (6) It is preferred that the interface to the graphical imaging system facilitate the use of the
graphical images by both occasional users of technology and users in high stress
environments. As such the proposed application shall be easy to use, readily
accessible, offer panning and zooming controls, and allow for a simple method of
determining whether a graphic exists for a particular address or area. Specify whether
the native FileNET and SIRE viewers will be used.
2-5.11 (6.1) It is preferred that the application interface with the GIS database to make all images
accessible from the mapping application on a per-building/structure basis.
2-5.11 (7) Specify the method of image capture. It is preferred that the organizations utilize their
current capture software (Kofax Ascent Capture at the County Sheriff and SIRE
Capture at the City Police Department).
2-5.11 (7.1) It is preferred that the capture software proposed for the County Sheriff supports Kodak
VRS (virtual rescan) technology.
2-5.11 (7.2) The proposed capture application shall populate index information in both the imaging
systems and the CAD/RMS/JMS system to eliminate redundant data entry.
2-5.11 (7.3) System must write the following imaging index values to the imaging system (FileNET
Content Services or AlphaCorp's SIRE) at a minimum:
2-5.11 (7.3.1) CAD Incident number,
2-5.11 (7.3.2) Case (report) number,
2-5.11 (7.3.3) Arrest/Booking number,
2-5.11 (7.3.4) Point coordinate information (X-Y) (requires fuzzy logic),
2-5.11 (7.3.5) MNI number,
2-5.11 (7.3.6) MLI number,
2-5.11 (7.3.7) MVI number,
2-5.11 (7.3.8) and MPI number.
2-5.11 (7.4) If vendor will use a capture system other than the image system manufacturer’s
capture software the proposed capture application must support document scanners
including flatbed, automatic feed, and high-speed duplex scanners from multiple
manufacturers.
2-5.11 (7.5) Image QC must include visual verification of each page of each document image.
Operator should be able to choose how the images are displayed (i.e., one image per
screen, or multiple thumbnails to browse through).
2-5.11 (7.6) Scanning controls must be accessible to operators through the application software for
any manual adjustments that may be necessary, such as deskew, despeckle, removal
of borders, contrast, brightness, etc.
2-5.11 (7.7) The proposed capture application must provide ability to delete, re-scan and replace
poor quality images and missing pages.
2-5.11 (7.8) The proposed capture application must provide ability to read bar codes.
2-5.11 (7.9) It is preferred that the proposed capture application provide optical and intelligent
character recognition (OCR/ICR) capabilities.
2-5.12 MUNICIPAL COURT SYSTEM INTERFACE 0 0 0 0
2-5.12 (1) The vendor shall supply an interface to the existing City of Fort Collins, Justice
Systems court records system which provides the following capabilities:
2-5.12 (1.1) Transfer citation information which has been entered into the RMS to the Full Court
System.
City of Fort Collins Page 16 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-5.12 (1.2) Accept the transfer of citation information which has been entered into the Full Court
System and store it in the appropriate fields in the proposed RMS application.
2-5.12 (1.3) Accept the transfer of case disposition information which has been entered into the
court system and store it in the appropriate fields in the proposed RMS application.
2-5.12 (1.4) Accept the transfer of warrant information which has been entered into the court
system and store it in the appropriate fields in the proposed RMS application.
2-5.13 VOICE 0 0 0 0
The Victim/Offender Information, Computer Enhancement (VOICE) system is a system
to keep victims of crime informed about their case. VOICE automatically notifies victims
by telephone and email about court dates, parole hearings, escapes, releases or other
important activity on their case. This system was implemented for the State of
Colorado by the County Sheriff’s of Colorado Inc.
This new interface is intended to support the VOICE system in whole and the Criminal
Records Information System of Colorado (CRISCO) specifically. The intent of this
interface is to automatically send the offender and victim information requested by the
CRISCO from the jail management system. The information concerning the export
requirements the CRISCO is on the web at http://asgnet2.psc.sc.edu/voice/.
In addition it is the intent of the participating agencies to define another new interface to
the VOICE system to automatically upload victim information from the victim’s response
module of the RMS. This will be a challenging interface as it has never been
accomplished before, and will require significant coordination with the VOICE
development team to create.
2-5.13 (1) The proposed RMS/JMS system shall fully support the reporting requirements of the
VOICE system as they relate to the collection and dissemination of data via an
interface to the CRISCO.
2-5.13 (2) It is desired that the proposed RMS/JMS fully support a new interface to the VOICE
system for the reporting of victim information as tracked by the VOICE system. It is
anticipated that this interface will provide victim information to VOICE from the victim’s
response information module of the RMS.
2-5.14 LIVESCAN 0 0 0 0
DBI Fingerprint System: This is the system that sends fingerprint and demographic
data to the state AFIS system. Larimer County has two DBI systems, one located in
the booking area, and one in the administration building, both of which currently receive
correctly formatted demographic data from the county mainframe via a FTP push to
each DBI system. This is a common interface in the industry and Larimer County
Sheriff’s Office requires the successful vendor to connect in a similar manner unitizing
the existing county WAN.
2-5.14 (1) The proposed system shall include an interface to the DBI Fingerprint System.
2-5.14 (2) Any DBI demographic fields that also exist in RMS/JMS must be available for transfer
via this interface.
2-5.14 (3) If more than three charges exist for an individual the RMS/JMS must send the three
most serious charges based on charge type and class of crime.
2-5.15 CERTEX 0 0 0 0
2-5.15 (1) The Certex system is a check writing system used by the detention center to issue all
inmate checks. The RMS/JMS must be able to send check data (check number, date,
name, amounts) to the Certex software.
City of Fort Collins Page 17 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-5.16 COMMISSARY 0 0 0 0
2-5.16 (1) Swanson Commissary System: This is the current provider for jail commissary. The
JMS must provide a mechanism for transferring orders electronically to this vendor.
2-5.16 (2) The current system allows for encumbrance of inmate monies at the time the order is
placed. There is a 24 hour delay from order until delivery. Due to items sometimes not
being delivered, inmate credits are created. There must be a mechanism for
electronically processing these credits.
2-6 DATABASE CONVERSION SPECIFICATIONS
Prices must include costs for the following database conversions. Conversion prices
should detail any known expenses that you will expect the participating agencies to
meet including costs with other vendors. All costing must be broken out by requested
conversion with the specific understanding that the participating agencies may accept
or reject having the vendor complete each conversion on a case by case basis.
2-6.1 CAD DATA (PECC AND LCSO)
Import of basic CAD configuration (street alias, intersection alias, common place,
incident & disposition code, etc.) and premise history/hazard files.
2-6.2 RMS DATA (FORT COLLINS POLICE SERVICES)
This data currently resides in a PRC Tri-Fox version 5.5. relational database running on
Oracle version6.4. There is approximately 8 gigabytes of data stored across multiple
files. These are relational files with the indices linking the various files created and
maintained by the application. This data must be inserted into the new database. City
of Fort Collins IMS staff will unload the database files into flat, ASCII files, delimited or
not, to the vendor upon receipt of an entity relation diagram, table layout, and data
dictionary. City of Fort Collins IMS staff will format the ASCII files to correspond to the
vendor’s database table requirements. FCPS will predetermine the data to be
converted from the existing system. City of Fort Collins IMS will work with the vendor
to resolve data migration problems, to describe current data relationships, and to
mitigate any data conversion problems.
2-6.3 RMS/JMS DATA (LARIMER COUNTY SHERIFF’S OFFICE)
This data currently resides in a Unisys DMS 1100 hierarchical database running on a
Unisys 2200/500 mainframe. There is approximately 12 gigabytes of data stored
across numerous files. These are database files with the indices linking the various
files created and maintained by the application. This data must be inserted into the
proposed database. Larimer County IMS staff will unload the database files into flat,
ASCII files, delimited or not, to the vendor upon receipt of an entity relation diagram,
table layout, and data dictionary. Larimer County IMS staff will format the ASCII files to
correspond to the vendor’s database table requirements. LCSO will predetermine the
data to be converted from the existing system. Larimer County IMS will work with the
vendor to resolve data migration problems, to describe current data relationships, and
to mitigate any data conversion problems.
2-6.4 MUGSHOT DATA
This data currently resides in a Printrak mugshot system, although all data is replicated
real time to a Microsoft SQL Server database. A common index to the master name
record exists and would be availible for the conversion process. There is
approximately 150,000 pictures in the database that is inclusive of all bookings by all
participating agencies.
City of Fort Collins Page 18 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-7 DATA SEARCH SPECIFICATIONS
2-7.1 SEARCHES AND INQUIRIES 0 0 0 0
2-7.1 (1) The following search functions must be supported by the CAD/RMS/JMS application:
2-7.1 (2) Search for string, and use of wildcards,
2-7.1 (3) Search capability for all formatted fields,
2-7.1 (4) Search capability for all text fields (including all original and supplemental narratives),
2-7.1 (5) Boolean Values Supported (separately or in combination),
2-7.1 (6) and Mobile Search Capabilities (including mugshot to the car).
2-7.1 (7) The proposed RMS/JMS application shall include a master index inquiry (MNI, MLI,
MVI, & MPI) for all applications allowing for identification and retrieval of related
records, such as incidents, case reports, citations, bookings, property, etc.
2-7.1 (8) The proposed RMS/JMS application shall include a function whereby searches default
to system wide search or to the agency logged on to the system, at each participating
agencies discretion.
2-7.1 (8.1) Regardless of search default the system shall be capable of being easily changed to
search a specific agency or all agencies.
2-7.1 (9) The proposed RMS/JMS application shall include a function for retrieving all records
associated with a user-defined name regardless of the association between the name
searched and the record in which it appears.
2-7.1 (10) The proposed RMS/JMS application shall allow authorized users to print a complete
history of all occurrences of a specific individual within the proposed RMS/JMS
application. This report will print to either the screen or paper and the records shall be
sorted by date.
2-7.1 (11) The proposed RMS/JMS application shall include a function for retrieving all records
associated with a user-defined location regardless of the association between the
location searched and the record in which it appears.
2-7.1 (12) The proposed RMS/JMS application shall include a function for retrieving all records
associated with a user-defined vehicle regardless of the association between the
vehicle searched and the record in which it appears.
2-7.1 (13) The proposed RMS/JMS application shall include a function for retrieving all records
associated with a user-defined property item regardless of the association between the
property item searched and the record in which it appears.
2-7.1 (14) The proposed RMS/JMS application shall allow users to go directly to any case report,
incident or contact (by double clicking or other simple method) found when running a
query of any person or vehicle.
2-7.1 (15) The proposed RMS/JMS application shall allow the crime analyst or other authorized
user to search by one or more vehicle descriptors.
2-7.1 (16) The proposed RMS/JMS application shall allow the crime analyst or other authorized
user to search by one or more property descriptors.
2-7.1 (17) Users shall have the ability to save query results.
2-7.1 (18) Users shall have the ability to use previously saved searches.
2-7.1 (19) The proposed RMS/JMS application shall have the ability to search the database by
any individual field or combination of fields.
City of Fort Collins Page 19 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-7.1 (20) The proposed RMS/JMS application shall provide inquiry forms that are consistent with
the data entry forms. Hence, an incident search form would look similar to an incident
entry form.
2-7.1 (21) The proposed RMS/JMS application shall include an inquiry that can show the reports
which have been completed as compared to the reports which are expected to be
completed based on incident data received from CAD (to include the status of all those
reports).
2-7.1 (22) The proposed RMS/JMS application shall include an inquiry that allows the evidence
technician to search for cases which have a court disposition and which have property
that can be returned or destroyed.
2-7.1 (23) The proposed RMS/JMS application shall provide a “Soundex” or other phonetic search
algorithm for name retrieval.
2-7.1 (24) The proposed application shall have a parameter that a user can select to search for
derivative names (i.e. William/Bill, Charles/Chuck).
2-7.1 (25) The proposed RMS/JMS application shall have the ability to search for persons or
businesses by telephone number.
2-7.1 (26) Phone numbers shall be searchable without being associated to name
2-7.1 (27) The proposed RMS/JMS application shall have the ability to search for telephone
numbers by a person’s name or alias.
2-7.1 (28) The proposed RMS/JMS application shall provide the ability to search for and display a
list of offenses and offense dates for, at a minimum:
2-7.1 (28.1) A given name,
2-7.1 (28.2) Date of birth,
2-7.1 (28.3) Gender, or
2-7.1 (28.4) Ethnicity.
2-7.1 (29) The proposed RMS/JMS application shall allow for query of locations by exact address,
by intersections, X-Y coordinates, address ranges, or by using wildcards if exact
address is unknown.
2-7.1 (30) The proposed RMS/JMS application shall allow for queries using wildcards (i.e. *, %,
etc.)
2-8 DATA ENTRY SPECIFICATIONS 0 0 0 0
The system is expected to have the capability to assist the user in performing many of
the tasks required for system operation.
2-8.1 (1) The system shall have an extensive on-line help system that accurately reflects the
state of the software in its current version.
2-8.1 (2) The system shall have an extensive context sensitive help that be access by mouse or
a single key or single keystroke combination.
2-8.1 (3) The system shall have the ability to modify or add to on-line help or context sensitive
help as an administrator function.
2-8.1 (4) The system shall use and display the same date and time formats across all
applications.
2-8.1 (5) Authorized personnel, typically records employees, enter all case narratives. They
shall be able to retrieve a report and go directly to the narrative section.
2-8.1 (6) It shall be possible for an authorized user to transfer the CAD details of an event to
RMS/JMS at any time after a case (report) number has been assigned even if the event
has not been closed in CAD.
City of Fort Collins Page 20 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-8.1 (7) Authorized personnel, typically records employees, sometimes have to update many
cases with the same information without re-entering the information. It is preferred that
the proposed system support this function (vendor must attach an explanation as to
how they would accomplish this).
2-8.1 (8) When a user is required to enter their name and ID for a process, it is preferred that the
system have the ability (at agency discretion) to automatically enter the ID of the user
that is logged on.
2-8.1 (9) The proposed RMS/JMS application shall automatically display the day of the week
when the date is entered.
2-8.1 (10) The proposed RMS/JMS application shall allow for shortcuts for date entry (i.e.
t=today’s date, y=yesterday’s date, etc.)
2-8.1 (11) The user shall be able to decrease and increase the date one day at a time by pressing
the minus or plus key.
2-8.1 (12) The proposed application shall support Windows style cut and paste functions.
2-8.1 (13) The system shall use drop down pick lists for all edited fields, but shall not require the
user to access the list if they know and wish to enter a correct value directly.
2-8.1 (14) The system shall utilize “type to complete” (typing moves through list for easy selection)
on all edited fields.
2-8.1 (15) The system shall utilize “typing to limit choice” (typing narrows possible choices) on all
edited fields.
2-8.1 (16) The system shall allow for controlling all entry functions with the exclusive use of a
mouse.
2-8.1 (17) The system shall allow for controlling all entry functions with the exclusive use of a
keyboard.
2-8.1 (18) The system shall allow for the participating agencies to define additional database
fields in all major applications.
2-8.1 (19) The system shall allow for the participating agencies to define edits for agency defined
fields.
2-9 MASTER INDEXES
2-9.1 GENERAL PROVISIONS 0 0 0 0
The RMS/JMS shall maintain at least four master indexes (shared by all agencies), the
Master Name Record (MNI), the Master Location Record (MLI), the Master Vehicle
Record (MVI) and the Master Property Record (MPI), that are used to link all
occurrences of the indexed data throughout the RMS/JMS regardless of where the
information is entered or queried.
2-9.1 (1) The system shall generate a unique global identification number (non agency specific)
for each master index record entered into the system that never changes.
2-9.1 (2) In the event that the master index contains a similar name or item, a summary list shall
display showing the particulars of the names or items that are similar to the one being
entered (defined as near hits).
2-9.1 (3) The proposed RMS/JMS application shall allow an authorized user to merge two or
more master index records into a single record that maintains all links to all areas that
were previously held by all the separate records.
2-9.1 (3.1) Upon any master index records merge the system must keep a user viewable log of the
master index numbers that were merged and the current master index number in use.
City of Fort Collins Page 21 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-9.1 (3.2) System shall allow for searching on all merged master index numbers and notify the
user of the merge and then display the current record.
2-9.1 (3.3) When merging master index records, the application shall preserve the most recently
entered information and show all other possible information as historical data.
2-9.1 (4) Users shall have the ability to set a general notification flag to indicate their interest in a
subject of a master index record (person, location, vehicle, or item of interest).
2-9.1 (5) Users shall have the ability to set a blind notification flag to indicate their interest in a
subject of a master index record (person, location, vehicle, or item of interest).
2-9.1 (6) When a user selects a record of interest (ROI) (or any of its linked appearances) for
viewing or modification, the proposed RMS/JMS application shall notify the user and
the person who set the flag that the record is the subject of interest to another user
(defined as the general notification flag).
2-9.1 (7) When a user selects a record of interest (ROI) (or any of its linked appearances) for
viewing or modification, the proposed RMS/JMS application shall notify only the person
who set the flag that the record is the subject of interest to another user (defined as the
blind notification flag).
2-9.1 (8) No one, other than the person entering the ROI, the system administrator or other
authorized user, shall be able to see a list of ROI entries.
2-9.1 (9) Users shall be able to view any images associated with a master name index record on
any workstation through a “Point & Click” or some other simple command (if not always
displayed already).
2-9.1 (10) The proposed RMS/JMS application shall make the master indexes accessible to
mobile users (if connection exists).
2-9.1 (11) The proposed RMS/JMS application shall retain all master index records indefinitely
unless a record is merged or deleted by a system administrator.
2-9.2 MASTER NAME INDEX 0 0 0 0
2-9.2 (1) The proposed RMS/JMS application shall have the ability to maintain a master name
index (MNI) that is created or updated by the entry of personal demographics in original
and supplemental reports and from any form where person query and entry is allowed.
2-9.2 (2) The MNI shall contain the minimum data as follows:
2-9.2 (2.1) last name (with provisions for hyphenated last names and suffixes),
2-9.2 (2.2) first name,
2-9.2 (2.3) middle name,
2-9.2 (2.4) gender,
2-9.2 (2.5) ethnicity,
2-9.2 (2.6) height,
2-9.2 (2.7) weight,
2-9.2 (2.8) hair color,
2-9.2 (2.9) eye color,
2-9.2 (2.10) scars, marks, and tattoos, and the location each occurs on the body,
2-9.2 (2.11) date of birth,
2-9.2 (2.12) age (manual entry if no dob exists; continual automatic calculation if dob is present),
2-9.2 (2.13) social security number,
2-9.2 (2.14) home street address (tied to MNI & MLI),
2-9.2 (2.15) home city (tied to MNI & MLI),
City of Fort Collins Page 22 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-9.2 (2.16) home state (tied to MNI & MLI),
2-9.2 (2.17) home zip code (tied to MNI & MLI),
2-9.2 (2.18) home phone (at least 20 characters) (tied to MNI & MLI) (up to 99),
2-9.2 (2.19) home phone type code (per record above),
2-9.2 (2.20) home e-mail,
2-9.2 (2.21) occupation,
2-9.2 (2.22) business name (tied to MNI & MLI),
2-9.2 (2.23) business street address (tied to MNI & MLI),
2-9.2 (2.24) business city (tied to MNI & MLI),
2-9.2 (2.25) business state (tied to MNI & MLI),
2-9.2 (2.26) business zip code (tied to MNI & MLI),
2-9.2 (2.27) business phone (at least 20 characters) (tied to MNI & MLI) (up to 99),
2-9.2 (2.28) business phone type code (per record above),
2-9.2 (2.29) business e-mail
2-9.2 (2.30) other phone number (tied to MNI) (up to 99),
2-9.2 (2.31) other phone type code (per record above),
2-9.2 (2.32) participating agencies ID number(s),
2-9.2 (2.33) state criminal ID number(s),
2-9.2 (2.34) FBI number,
2-9.2 (2.35) driver's license number(s), state(s) of issue and expiration date(s),
2-9.2 (2.36) other identifying numbers,
2-9.2 (2.37) alias last name (w/provisions for hyphenated last names and suffixes) (up to 99),
2-9.2 (2.38) alias first names (up to 99),
2-9.2 (2.39) alias middle names (up to 99),
2-9.2 (2.40) alias dates of birth (up to 99),
2-9.2 (2.41) alias social security numbers (up to 99),
2-9.2 (2.42) history of home addresses (street, city, zip) (up to 99),
2-9.2 (2.43) history of business addresses (street, city, zip) (up to 99),
2-9.2 (2.44) moniker(s) (up to 99), and
2-9.2 (2.45) multiple cautions (up to 99),
2-9.2 (2.46) mugshot images of the individual (up to 99),
2-9.2 (2.47) and a link to the addition data held in the mugshot module.
2-9.2 (2.48) For phone number fields the system shall have the ability to set a default value for area
code at the participating agencies discretion.
2-9.2 (3) The MNI shall function as a central cross reference to link all occurrences of an
individual’s personal information across all applications.
2-9.2 (4) Upon entry of a person anywhere in the RMS/JMS, the system shall provide a
mechanism to search the MNI for any pervious contacts with that person (with the
search becoming more specific as more personal information is provided) and,
2-9.2 (5) Upon entry of a person anywhere in the RMS/JMS, the system shall provide a
mechanism to search the MNI for any pervious contacts with that person by utilizing a
soundex routine on that person’s name (with the search becoming more specific as
more name information is provided).
City of Fort Collins Page 23 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-9.2 (6) The system shall display the results of the MNI search in a format that provides
sufficient information per person to eliminate near hits and allow for the selection of a
matching record with the use of a mouse or keyboard.
2-9.2 (7) The system shall allow the clearing of this search result and allow changing the data
and starting a new search.
2-9.2 (8) Upon selection of a person’s record in the search result window the system shall auto-
populate all possible fields on the entry form and create a link to the MNI for this record.
2-9.2 (9) The entry personnel shall then be able to modify any of the personal demographic
information, and by doing so, automatically update the information in the MNI.
2-9.2 (10) The system shall allow the clearing of this search result and the manual entry of all
personal demographics that will then create a new MNI record.
2-9.3 MASTER LOCATION INDEX 0 0 0 0
2-9.3 (1) The proposed RMS/JMS application shall have the ability to maintain a master location
index (MLI) that is created or updated by the entry of location information in original and
supplemental reports and from any form where location query and entry is allowed.
2-9.3 (2) The MLI shall contain the minimum data as follows:
2-9.3 (2.1) location name,
2-9.3 (2.2) location type,
2-9.3 (2.3) location street number,
2-9.3 (2.4) location sub unit type (apartment, building, etc.),
2-9.3 (2.5) location sub unit number (alpha numeric),
2-9.3 (2.6) location street name,
2-9.3 (2.7) location city,
2-9.3 (2.8) location state,
2-9.3 (2.9) location zip code,
2-9.3 (2.10) location phone number (at least 20 characters),
2-9.3 (2.11) location x coordinate (easting),
2-9.3 (2.12) location y coordinate (northing),
2-9.3 (2.13) location z coordinate (altitude),
2-9.3 (2.14) digital images of the location (up to 9).
2-9.3 (2.15) and, multiple cautions (up to 99).
2-9.3 (3) The MLI shall function as a central cross reference to link all occurrences of a location
across all applications.
2-9.3 (4) Upon entry of a location anywhere in the RMS/JMS, the system shall provide a
mechanism to search the MLI for any pervious entries of that location (with the search
becoming more specific as more location information is provided) and,
2-9.3 (5) The system shall display the results of the MLI search in a format that provides
sufficient information per location to eliminate near hits and allow for the selection of a
matching record with the use of a mouse or keyboard.
2-9.3 (6) The system shall allow the clearing of this search result and allow changing the data
and starting a new search.
2-9.3 (7) Upon selection of a location record in the search result window the system shall auto-
populate all possible fields on the entry form and create a link to the MLI for this record.
City of Fort Collins Page 24 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-9.3 (8) The entry personnel shall then be able to modify any of the location information, and by
doing so, automatically update the information in the MLI.
2-9.3 (9) The system shall allow the clearing of this search result and the manual entry of all
location information that will then create a new MLI record.
2-9.4 MASTER VEHICLE INDEX 0 0 0 0
2-9.4 (1) The proposed RMS/JMS application shall have the ability to maintain a master vehicle
index (MVI) that is created or updated by the entry of vehicles in original and
supplemental reports and from any form where vehicle query and entry is allowed.
2-9.4 (2) The MVI shall contain the minimum data as follows:
2-9.4 (2.1) vehicle type,
2-9.4 (2.2) make,
2-9.4 (2.3) model,
2-9.4 (2.4) year of manufacture,
2-9.4 (2.5) vin number,
2-9.4 (2.6) body style,
2-9.4 (2.7) color – top,
2-9.4 (2.8) color – bottom,
2-9.4 (2.9) color – interior,
2-9.4 (2.10) license plate number,
2-9.4 (2.11) license plate state,
2-9.4 (2.12) license plate expiration year,
2-9.4 (2.13) identifying marks,
2-9.4 (2.14) comments,
2-9.4 (2.15) digital images of the vehicle (up to 9),
2-9.4 (2.16) history of license plate number (up to 99),
2-9.4 (2.17) history of license plate state (up to 99),
2-9.4 (2.18) and history of license plate expiration year (up to 99).
2-9.4 (3) The MVI shall function as a central cross reference to link all occurrences of a vehicle
across all applications.
2-9.4 (4) Upon entry of a vehicle anywhere in the RMS/JMS, the system shall provide a
mechanism to search the MVI for any pervious entries of that vehicle (with the search
becoming more specific as more vehicle information is provided) and,
2-9.4 (5) The system shall display the results of the MVI search in a format that provides
sufficient information per vehicle to eliminate near hits and allow for the selection of a
matching record with the use of a mouse or keyboard.
2-9.4 (6) The system shall allow the clearing of this search result and allow changing the data
and starting a new search.
2-9.4 (7) Upon selection of a vehicle record in the search result window the system shall auto-
populate all possible fields on the entry form and create a link to the MVI for this record.
2-9.4 (8) The entry personnel shall then be able to modify any of the vehicle information, and by
doing so, automatically update the information in the MVI.
2-9.4 (9) The system shall allow the clearing of this search result and the manual entry of all
vehicle information that will then create a new MVI record.
2-9.5 MASTER PROPERTY INDEX 0 0 0 0
City of Fort Collins Page 25 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-9.5 (1) The proposed RMS/JMS application shall have the ability to maintain a master property
index (MPI) that is created or updated by the entry of property descriptions in original
and supplemental reports and from any form where property query and entry is
allowed.
2-9.5 (2) The MPI shall contain the minimum data as follows:
2-9.5 (2.1) property type (e.g. jewelry, currency, firearm, etc.),
2-9.5 (2.2) make or brand name,
2-9.5 (2.3) model,
2-9.5 (2.4) serial number
2-9.5 (2.5) other identifying number, (owner applied ID, alpha/numeric) (up to 9),
2-9.5 (2.6) dimensions,
2-9.5 (2.7) size,
2-9.5 (2.8) weight,
2-9.5 (2.9) color,
2-9.5 (2.10) caliber/gauge,
2-9.5 (2.11) narrative description,
2-9.5 (2.12) digital images of the property (up to 9).
2-9.5 (3) The MPI shall function as a central cross reference to link all occurrences of a piece of
property across all applications.
2-9.5 (4) Upon entry of a property anywhere in the RMS/JMS, the system shall provide a
mechanism to search the MPI for any pervious entries of that property (with the search
becoming more specific as more property information is provided) and,
2-9.5 (5) The system shall display the results of the MPI search in a format that provides
sufficient information per property to eliminate near hits and allow for the selection of a
matching record with the use of a mouse or keyboard.
2-9.5 (6) The system shall allow the clearing of this search result and allow changing the data
and starting a new search.
2-9.5 (7) Upon selection of a property record in the search result window the system shall auto-
populate all possible fields on the entry form and create a link to the MPI for this record.
2-9.5 (8) The entry personnel shall then be able to modify any of the property information, and
by doing so, automatically update the information in the MPI.
2-9.5 (9) The system shall allow the clearing of this search result and the manual entry of all
property information that will then create a new MPI record.
2-10 MUGSHOT MODULE 0 0 0 0
The proposed RMS/JMS application shall provide for capturing additional data on any
person listed in the MNI to support mugshot applications.
2-10.1 (1) At a minimum, the mugshot application shall include:
2-10.1 (1.1) All data captured by the MNI and;
2-10.1 (1.2) Calculated age at time of mugshot,
2-10.1 (1.3) Place of birth,
2-10.1 (1.4) Hair length,
2-10.1 (1.5) Hair style,
2-10.1 (1.6) Facial hair,
2-10.1 (1.7) Complexion,
City of Fort Collins Page 26 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-10.1 (1.8) Glasses,
2-10.1 (1.9) Eye characteristics,
2-10.1 (1.10) Speech,
2-10.1 (1.11) Teeth,
2-10.1 (1.12) Hat,
2-10.1 (1.13) Physical build,
2-10.1 (1.14) Missing limbs,
2-10.1 (1.15) Injury/ illness,
2-10.1 (1.16) Treated by,
2-10.1 (1.17) Where treated,
2-10.1 (1.18) Date and time treated
2-10.1 (1.19) Case (report) number history,
2-10.1 (1.20) Reporting officer history,
2-10.1 (1.21) Arrest history (arrest (booking) number, date and time)
2-10.1 (1.22) Arrest location history,
2-10.1 (1.23) And a clear indication that a picture is one of a juvenile.
2-10.1 (2) The proposed RMS/JMS application shall have the ability to create photo lineups, with
user defined parameters, using photos in the mugshot module.
2-10.1 (3) The proposed RMS application shall have the ability to save and/or print photo lineups
once created.
2-11 KNOWN OFFENDER MODULE 0 0 0 0
2-11.1 (1) The proposed RMS/JMS application shall include a module that will be used to register
known offenders such as sex offenders, gang members, etc.
2-11.1 (2) The Known Offender module will interface to the master indexes such that persons
entered into the Known Offender module will be found by name, location or other
master index searches.
2-11.1 (3) The Known Offender module will allow for multiple entries of offender classification (i.e.
Sex offender and gang member and parolee)
2-11.1 (4) At a minimum, the Known Offender module shall include the following fields:
2-11.1 (4.1) All the information contained in the MNI, MLI, MVI, & mugshot module for each
offender entry and;
2-11.1 (4.2) Display of the MNI number,
2-11.1 (4.3) Display of the date of last contact (derived from last entry for this person anywhere in
the RMS/JMS),
2-11.1 (4.4) Known Offender classification, (e.g. sex offender, gang member, etc.) (up to 99),
2-11.1 (4.5) Multiple date function (up to 99), defined as a one to many date capture capability with
a date type pick list (entry, first registration, next registration, end of registration
requirement, review, etc.) and a date field. All date records to be held per offender
classification, and are intended to drive system actions and notifications,
2-11.1 (4.6) Review flag by offender classification (up to 99) (sets a flag by date type that causes a
review message to be sent to specified personnel on that date).
2-11.1 (4.7) Define a one to many conditions capture capability with a agency defined pick list that
allows to append up to 99 conditions that are held unique to an offender classification,
i.e. Juvenile or Adult Conviction, Sexual Predator, Community Notification made, etc.
2-11.1 (4.8) Registering officer name , ID and role,
City of Fort Collins Page 27 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-11.1 (4.9) Gang affiliation,
2-11.1 (4.10) Gang ‘set’ affiliation
2-11.1 (4.11) Jurisdiction of conviction,
2-11.1 (4.12) Conviction type, (allow for multiples)
2-11.1 (4.13) Conviction description, (allow for multiples)
2-11.1 (4.14) Conviction NCIC Code, (allow for multiples)
2-11.1 (4.15) and Narrative.
2-11.1 (5) The Known Offender module will allow for entry/update to the CCIC/NCIC system on
record entry and modification.
2-11.1 (6) The proposed RMS/JMS application shall have the ability check CCIC/NCIC upon entry
of a registered sex offender to determine if the individual is listed as wanted in another
jurisdiction.
2-11.1 (7) The proposed RMS/JMS application shall have the ability to format and send an update
message to CCIC each time that a registered sex offender is entered in RMS.
2-11.1 (8) The proposed RMS/JMS application should include the ability to attach the CCIC/ NCIC
return to the registered sex offender.
2-12 WEB BASED FUNCTIONALITY 0 0 0 0
It is expected the system would utilize web technology to allow for many of the
functions of the CAD/RMS/JMS to be performed on any network attached workstation
with use of a web browser such as Microsoft Internet Explorer (version 5.5 or above)
alone (no vendor supplied software needed).
2-12.1 (1) Web based functionality is preferred for:
2-12.1 (1.1) mobile application (MDC),
2-12.1 (1.2) over the Internet (Secure Client),
2-12.1 (1.3) internal to the agencies,
2-12.1 (1.4) and public information dissemination over the Internet.
2-12.1 (2) Web based user capabilities are preferred for:
2-12.1 (2.1) data search and lookup,
2-12.1 (2.2) crime analysis,
2-12.1 (2.3) data entry,
2-12.1 (2.4) and system administration.
2-13 WORKFLOW PROCESS SPECIFICATIONS 0 0 0 0
The proposed RMS/JMS application must support the ability for the participating
agencies to customize the workflow processes that are inherent in all system entry
processes. This customization should be a design feature of the system that allows the
system administrators of the system to configure many different work flow processes
that will be automatically driven by the task the user wishes to accomplish.
2-13.1 (1) The proposed RMS/JMS application must support the capability for multiple, agency
configurable, workflow processes.
2-13.1 (2) Workflow processes must have the ability to automatically format and send various
types of internal messages that will prompt users to complete actions.
2-13.1 (3) Workflow processes must have the ability to automatically format and send various
types of external (to the system) e-mail messages that will prompt users to complete
actions.
City of Fort Collins Page 28 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-13.1 (4) Workflow processes must be able to be set by system administrators that will change
based on the selections that the user makes during the entry processes (different
workflow depending on selections or entries made).
2-14 REPORT GENERATION SPECIFICATIONS
2-14.1 GENERAL REQUIREMENTS 0 0 0 0
2-14.1 (1) All reporting of the proposed CAD/RMS/JMS that is run through the user client at the
user level shall have the ability to be modified, created and made available to the users
by the participating agencies system administrators.
2-14.1 (2) The proposing vendor shall train the participating agencies system administrators to
modify, create, and make available reports to the users through the CAD/RMS/JMS
client applications.
2-14.1 (3) All reporting of the proposed CAD/RMS/JMS shall be definable by agency (only the
reports for a user’s agency are viewable and usable by that user).
2-14.1 (4) The proposed CAD/RMS/JMS application shall include the ability for authorized users
to edit the appearance of printed reports.
2-14.1 (5) The proposed CAD/RMS/JMS application shall include an ad hoc report writer that can
be used by a non-technical professional to create, use and save searches and reports.
2-14.1 (6) The proposed ad hoc searching and reporting capability shall include logical operators
and other advanced methods for searching and retrieving records that meet user-
defined criteria.
2-14.1 (7) The proposed CAD/RMS/JMS application data files shall be compatible with third party
reporting tools such as IQ Objects, and Crystal Reports.
2-14.1 (8) It is desired that the proposed CAD/RMS/JMS application include a graphical or other
ad hoc report generator that does not require extensive training in SQL or other query
languages.
2-14.1 (9) The proposed CAD/RMS/JMS application shall allow authorized users to schedule
searches or reports to run at specific times and/or specific dates.
2-14.1 (10) Some reports contain empty fields. In some cases, this results in a long printed report
with information in only a few fields. It is preferred that users have the option of
choosing to print or not to print empty fields.
2-14.1 (11) The vendor shall describe any reports offered as part of their proposed CAD/RMS/JMS
application that are not required hereafter.
2-14.2 SYSTEM ADMINISTRATION REPORTS 0 0 0 0
2-14.2 (1) The proposed CAD/RMS/JMS application shall include a Logon Report that shows the
time and location of each user logging on or off the system for any given date.
2-14.2 (2) The proposed CAD/RMS/JMS application shall include a Workstation Logon Report
that shows all users logging on or off the system on a given workstation for any given
date.
2-14.2 (3) The proposed CAD/RMS/JMS application shall include a report that lists all persons
who have printed any or all forms associated with a given record.
2-14.2 (4) The proposed CAD/RMS/JMS application shall include a report that shows the system
administrator or authorized user all master index entries added for a user specified date
and time range.
2-15 LOCATION SPECIFICATIONS 0 0 0 0
2-15.1 (1) All location data-sets must contain x-y coordinate fields
City of Fort Collins Page 29 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-15.1 (2) The proposed CAD/RMS/JMS application shall verify each address entered into any
location field system wide against the system geofile.
2-15.1 (3) The proposed CAD/RMS/JMS application shall allow the user to re-verify any address
entered into any location field system wide against the system geofile.
2-15.1 (4) The proposed application shall allow a user to bypass the address verification routine if
a correct address cannot be found.
2-15.1 (5) In order to bypass address verification the user will be required to manually enter an
address or x-y (NAD 83 State Plane) coordinate.
2-15.1 (6) The system must be able to directly enter x-y coordinates (NAD 83 State Plane) on any
location entry.
2-15.1 (7) It is preferred that the user be able to select x-y coordinates with the use of a graphical
tool (point and click on a map).
2-15.1 (8) Valid location must determinable by x-y coordinate alone (all districts and agencies
assigned).
2-15.1 (9) The proposed application shall note each instance of a bypassed address so that the
system administrator or other authorized user can make the appropriate corrections to
the geofile.
2-15.1 (10) The proposed application shall allow for the transfer and display of address and x-y
coordinates from CAD into the RMS/JMS.
2-16 MAPPING
2-16.1 GENERAL REQUIREMENTS 0 0 0 0
2-16.1 (1) Mapping images shall be stored locally on each workstation and mobile to minimize
bandwidth usage.
2-16.1 (2) The proposed system shall utilize a single coordinate-based mapping file (geofile) for
CAD, RMS and all other applications (NAD 83 State Plane).
2-16.1 (3) The proposed application shall utilize a single application for creating, updating and
maintaining the shared geofile. Geofile maintenance will be shared between multiple
agencies.
2-16.1 (4) The mapping system will support the ability to locate a position on all map projections
on the fly by using latitude/longitude coordinates.
2-16.1 (5) System must have the ability to translate and display stored NAD 83 State Plane
coordinates to a display only of latitude/longitude coordinates (vendor must attach an
explanation as to how they would accomplish this).
2-16.1 (6) The proposed mapping application shall support at least 256 separate layers for
separating line and text data.
2-16.1 (7) The proposed application shall have the ability to import both database information and
graphic elements from the following mapping systems:
2-16.1 (7.1) ESRI GIS file formats,
2-16.1 (7.2) AutoCAD,
2-16.1 (7.3) and Map Info.
2-16.1 (8) The vendor shall describe how the import of data from other GIS systems is
accomplished and the steps which are required to merge that information with existing
geofile data (vendor must attach an explanation as to how they would accomplish this).
2-16.1 (9) The proposed applications shall utilize the shared geofile each time a location must be
validated by any vendor-supplied application.
2-16.1 (10) The proposed application shall utilize the shared geofile to determine:
City of Fort Collins Page 30 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-16.1 (10.1) What jurisdiction the address is in.
2-16.1 (10.2) If the address is within the city, to determine the patrol district, and
2-16.1 (10.3) the X-Y coordinates.
2-16.1 (11) The proposed applications shall use the coordinates provided by the geofile whenever
a location must be plotted on a map for display.
2-16.2 VENDOR SUPPLIED GEOFILE 0 0 0 0
In cooperation with Larimer County and surrounding municipalities, the City of Fort
Collins participated in the development of a number of countywide, GIS data sets.
These data sets include: street centerline with address ranges, city boundaries, police
jurisdictions, fire jurisdictions, ambulance jurisdictions, ZIP Code boundaries, and ESN
boundaries. These data sets are maintained by a vendor, which receives update
information from the participating agencies and produces a complete update of the data
sets on a monthly basis. These data sets are maintained in ESRI coverage and
shapefile formats in NAD83, State Plane.
The city, Larimer County, and other agencies within Larimer County also maintain a
number of other data sets within their respective agencies. These data sets would
include common-places, parks, school, railroad lines, etc. These data sets are
generally maintained in an ESRI format, but may also be AutoCAD.
2-16.2 (1) Vendors shall provide explanation of how they will supply a coordinate-based geofile,
which will meet the requirements listed below.
2-16.2 (2) The vendor shall supply a geofile, which is based upon and derived from the data sets
that are maintained by the city, Larimer County and the surrounding agencies.
2-16.2 (3) The vendor shall supply a complete and detailed explanation of additions, changes
and/or corrections that must be performed on the available data sets in order to make
them compatible with the supplied system in order to meet all functionality
requirements. This includes complete address error checking to ensure that all
addresses contained within the street centerline data set are available for call
verification within the system.
2-16.2 (4) The vendor shall ensure a final product used by the system as a geofile which includes
the name, coordinate location and an associated graphic elements for each of the
following:
2-16.2 (4.1) streets,
2-16.2 (4.2) parks,
2-16.2 (4.3) schools,
2-16.2 (4.4) fire, police and ambulance stations,
2-16.2 (4.5) common places,
2-16.2 (4.6) Interstate and state highways,
2-16.2 (4.7) boundary for each political entity/district,
2-16.2 (4.8) boundary for each of the patrol districts, including sub-jurisdictions,
2-16.2 (4.9) water features including lakes, streams and reservoirs,
2-16.2 (4.10) railroad tracks,
2-16.2 (4.11) and Boundaries for each ESN.
2-16.2 (5) The vendor shall ensure that the geofile has a positional accuracy of not less than three
meters for all database records and graphic elements. Thus graphic elements shown
on the screen are within three meters of their actual position in the world.
City of Fort Collins Page 31 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-16.3 GEOFILE MAINTENANCE TOOLS 0 0 0 0
2-16.3 (1) The City of Fort Collins and Larimer County desires to continue to use the existing
maintenance procedures that currently exist as a cooperative effort with the
surrounding agencies. The proposed maintenance application shall provide for the
complete exchange of all individual geofile data elements, such as street centerline,
city boundaries, etc.
2-16.3 (2) The vendor shall provide a detailed explanation of how the maintenance process will be
accomplished given that some, or possibly all, of the data sets will be maintained
outside of the system as a part of a separate maintenance process.
2-16.3 (3) The proposed maintenance application shall include tools for:
2-16.3 (3.1) Graphically creating, editing and maintaining a coordinate-based geofile,
2-16.3 (3.2) Graphically creating, editing and maintaining geographic boundaries such as reporting
districts, patrol districts, city boundaries, fire and ambulance boundaries and other
geographic areas and associating these with a database record,
2-16.3 (3.3) Graphically creating, editing, and maintaining geographic features such as lakes, parks,
railroad tracks or schools and associating these with a database record,
2-16.3 (3.4) Graphically selecting the database records associated with a graphic element by use of
a pointing device so that the underlying database record can be modified,
2-16.3 (3.5) Adding new streets, and other geographical elements through on-screen digitizing or
drawing,
2-16.3 (3.6) Adding new streets and other geographic elements by import from other electronic
sources,
2-16.3 (3.7) Adding new streets, and other geographical elements by receiving geographic
coordinate updates from an AVL equipped vehicle as it is moving,
2-16.3 (3.8) Creating new geographic areas by selecting many individual geographic elements (e.g.
streets and intersections) simultaneously and then making a like update to their
respective database records,
2-16.3 (3.9) and Modifying maps to include road and bridge closures, both permanent and
temporary.
2-16.3 (4) The proposed application shall provide a reporting tool that will identify conflicts in geo-
file address resolution across the geo-file. Including range overlaps, range gaps etc.
2-16.3 (5) The maintenance application shall display the map coordinate position of the pointing
device at all times (State Plane or Latitude/Longitude display).
2-16.3 (6) For clarity, the maintenance module shall have the ability to assign unique color codes
to graphic elements such as streets, parks, schools, bridges and rivers.
2-16.3 (7) The maintenance module shall have the ability to add labels to graphic attributes such
as streets and parks on the map and display the labels on the map.
2-16.3 (8) The maintenance module shall have the ability to print selected portions of the maps to
printers and plotters.
2-16.4 MAP DISPLAY 0 0 0 0
2-16.4 (1) The proposed mapping application shall allow the user to display any number or
combination of the map layers at one time.
2-16.4 (2) The proposed mapping application shall allow the user to pan and zoom the map
display either with a mouse or with keyboard controls.
2-16.4 (3) The proposed mapping application shall allow the user to retrieve a different map view
by address or common place name.
City of Fort Collins Page 32 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-16.4 (4) The proposed mapping application shall provide a single continuous map and shall not
require the user to retrieve another map “page” when the edge of one page is reached.
2-16.4 (5) The map display system shall display progressively more detail as the zoom level is
increased.
2-16.4 (6) The proposed application shall automatically size icons and objects after a zoom-in or
zoom-out so that they remain the same size relative to the map view.
2-16.4 (7) The proposed application shall allow the system administrator or other authorized user
to determine which labels display at each zoom level. For example, as the user views
a larger map they may only see labels for the major arterial as opposed to labels for
every street.
2-16.4 (8) The proposed application shall allow the system administrator or other authorized user
to determine which layers of the map will display at each zoom level. For example,
water features may only be displayed on maps of neighborhoods and not on a whole
city map.
2-16.4 (9) It is preferred that the proposed application have the ability to recommend different
resources based on a street direction. For example, northbound I-70 will receive a
different recommendation than southbound I-70 in the same location.
2-16.4 (10) It is preferred that the proposed application have the ability to recommend different
resources for events occurring on the street as opposed to at an address on that same
street. For example, some streets in the city are the responsibility of the State, while
houses located on those streets are the city’s jurisdiction (vendor must attach an
explanation as to how they would accomplish this).
2-16.4 (11) It is preferred that the proposed mapping application enable the system administrator
or other authorized user to associate names with common map views. For example, a
map view showing all streets within the city with major arterials labeled might be called
“City”. Another view might be named “neighborhood”. This view might show a ½ mile
square area with all the streets labeled, with parks, schools and railroad tracks shown.
Thus if a user is viewing a map display and chooses the “neighborhood” view the map
will automatically display the proper zoom level and features defined for that view.
2-16.4 (12) The proposed application shall allow the system administrator or other authorized user
to configure the notation accompanying each graphic symbol. For example, the option
to list the event number and status alongside an event symbol.
2-16.4 (13) The proposed application shall have the ability to display the AVL reported location of
field units on the map.
2-16.4 (14) The proposed system shall not be delayed by the redrawing of a map or by the
constant changes associated with AVL location reports.
2-17 PERSONNEL DATABASE
2-17.1 GENERAL REQUIREMENTS 0 0 0 0
2-17.1 (1) The proposed RMS/JMS application shall include a shared personnel system.
2-17.1 (2) Employee personal information in regards to all personnel system function must not be
a part of the master name index (including demographics for employees).
2-17.1 (3) Personnel file viewing must be restricted to only those persons granted permission by
the system administrator.
2-17.1 (4) The ability to make changes to the file must be further restrictable and the dates of any
changes must be recorded and who made the changes.
City of Fort Collins Page 33 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.1 (5) At a minimum, the proposed personnel system shall capture the following information
for each applicant/employee:
2-17.1 (5.1) Status (pre-hire, current employee, reserve, volunteer, ex employee, etc.)
2-17.1 (5.2) Agency
2-17.1 (5.3) Employee ID and/or badge number (alpha/numeric, minimum of 8 characters),
2-17.1 (5.4) Full name (last, first and middle), with support for hyphenated last names and name
suffixes,
2-17.1 (5.5) Date and place of birth,
2-17.1 (5.6) Current Age (continuously calculated from DOB),
2-17.1 (5.7) Social Security number,
2-17.1 (5.8) Drivers license number and expiration date,
2-17.1 (5.9) Physical description that includes; gender, race/ethnicity, height, weight, eye and hair
color,
2-17.1 (5.10) Digital photo,
2-17.1 (5.11) Blood type,
2-17.1 (5.12) Home address that includes; street number & name, po box, city, state, and zip,
2-17.1 (5.13) Applicant work name and address that includes; street number & name, po box, city,
state, and zip,
2-17.1 (5.14) At least four fields for telephone, mobile phone, and pager numbers,
2-17.1 (5.15) Email address,
2-17.1 (5.16) Marital status,
2-17.1 (5.17) Emergency contact information that includes; full name, relation, home address &
phone, work address and phone, and mobile phone,
2-17.1 (5.18) Inoculations,
2-17.1 (5.19) Allergies (free text to accommodate 3 entries)
2-17.1 (5.20) Primary care physician,
2-17.1 (5.21) Emergency medical information,
2-17.1 (5.22) Dates of physical injuries with comments,
2-17.1 (5.23) Dates of physical exams with pass/fail rating and comments,
2-17.1 (5.24) Special skills such as languages,
2-17.1 (5.25) Date of skills certification (if applicable),
2-17.1 (5.26) Level of formal education,
2-17.1 (5.27) Outside degrees, certificates and educational efforts,
2-17.1 (5.28) Date of hire,
2-17.1 (5.29) Date of status change (promotion, reassignment, etc.)
2-17.1 (5.30) Nominal probation period,
2-17.1 (5.31) Date of probation completion,
2-17.1 (5.32) Flag to indicate re-hire (forced choice)
2-17.1 (5.33) Date of termination,
2-17.1 (5.34) Reason for termination,
2-17.1 (5.35) Dates of previous employment (to accommodate 2 previous employment dates),
2-17.1 (5.36) Dates of previous termination (to accommodate 2 previous termination dates),
2-17.1 (5.37) Reasons of previous termination (to accommodate 2 previous termination dates),
2-17.1 (5.38) Current shift,
City of Fort Collins Page 34 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.1 (5.39) Current assignment to include;
Division,
Section,
Unit,
and Job title.
2-17.1 (5.40) Current supervisor.
2-17.1 (5.41) All previous assignments by date,
2-17.1 (5.42) Transfer information (no limit on number) that includes;
Date of Transfer,
and Reason for Transfer.
2-17.1 (5.43) Special Assignments (concurrent to regular assignment, no limit on number) to include
the following;
Name of assignment,
Date of assignment,
and Date of completion of assignment.
2-17.1 (5.44) Current rank,
2-17.1 (5.45) A flag to indicate status as a sworn officer,
2-17.1 (5.46) Seniority date by current assignment.
2-17.1 (5.47) Seniority date department wide.
2-17.1 (5.48) Previous ranks with dates of promotion,
2-17.1 (5.49) Commendations and dates received,
2-17.1 (5.50) Disciplinary actions taken, reasons for each and dates,
2-17.1 (5.51) and Manuals issued (forced choice w/free text).
2-17.2 EVALUATION PROCESS 0 0 0 0
2-17.2 (1) The evaluations module shall only be accessible by the designated supervisory
personnel or individuals specified by system administrator.
2-17.2 (2) Completed evaluations shall be viewable by the employee and supervisors in
employee’s chain of command or individuals specified by system administrator.
2-17.2 (3) The evaluation shall follow a review process configurable by participating agencies and
the evaluation will be able to be “locked” when designated reviews have been
completed.
2-17.2 (4) The evaluation module shall have the ability to store, for immediate retrieval by the
employee or authorized supervisor(s), the current and two previous evaluations.
2-17.2 (4.1) It is preferred that the evaluation module be configurable to store an agency defined
number of evaluations.
2-17.2 (4.2) It is preferred that the evaluation module will delete the oldest evaluation, as configured
by participating agencies, when a new evaluation is entered into the system without
specific action of rating official.
2-17.2 (5) The evaluation module shall have the ability for the system administrator to configure
the evaluation groups by agency selected fields such as, but not limited to:
2-17.2 (5.1) rank,
2-17.2 (5.2) division (assignment),
2-17.2 (5.3) type of evaluation from a pick list (monthly, interim, yearly).
2-17.1 (5.39.1)
2-17.1 (5.39.2)
2-17.1 (5.39.3)
2-17.1 (5.39.4)
2-17.1 (5.42.1)
2-17.1 (5.42.2)
2-17.1 (5.43.1)
2-17.1 (5.43.2)
2-17.1 (5.43.3)
City of Fort Collins Page 35 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.2 (6) Evaluation module shall be able to display, on screen or in print format, a list of
evaluations due within a specified date range to include at a minimum:
2-17.2 (6.1) Name,
2-17.2 (6.2) Rank,
2-17.2 (6.3) Current pay level
2-17.2 (6.4) Due date,
2-17.2 (6.5) Date of last evaluation,
2-17.2 (6.6) Supervisor,
2-17.2 (6.7) And training/education completed for specified date range.
2-17.3 INTERNAL AFFAIRS 0 0 0 0
2-17.3 (1) In addition to the standard investigative records maintained by Internal Affairs the
proposed system shall record the following information about disciplinary actions:
2-17.3 (1.1) the name, address, and phone number of the complainant,
2-17.3 (1.2) the date of the original complaint,
2-17.3 (1.3) the nature of the complaint,
2-17.3 (1.4) the officer in charge of the investigation,
2-17.3 (1.5) the disciplinary action taken, and
2-17.3 (1.6) a narrative field.
2-17.4 HIRING PROCESS 0 0 0 0
The Proposed RMS/JMS application shall contain a system specifically to track the
hiring process for all new employees.
2-17.4 (1) The hiring tracking system shall be linked to, capture, and display all personal
information captured by the personnel system.
2-17.4 (2) Upon employment the system shall not require the re-entry of any data captured and
tracked by the personnel database.
2-17.4 (3) The hiring tracking system shall allow for tracking multiple applicant processes for the
same person, both concurrently and consecutively.
2-17.4 (3.1) The system must store the results (per application) of all applications a person has
submitted.
2-17.4 (3.2) The system must clearly indicate the number of concurrent pre-hire processes a person
is involved with whenever viewing that person’s record.
2-17.4 (3.3) The system must clearly display (per application) the master status and what stage of
testing applicant is at during the pre-hire processes whenever viewing that person’s
record.
2-17.4 (4) System must capture all information relating to each application process that includes
the following:
2-17.4 (4.1) Date application received,
2-17.4 (4.2) Written exam information;
2-17.4 (4.2.1) Test date,
2-17.4 (4.2.2) Test time,
2-17.4 (4.2.3) Score,
2-17.4 (4.2.4) Military points,
2-17.4 (4.2.5) Total test score,
2-17.4 (4.2.6) Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.2.7) and Comments (free text).
City of Fort Collins Page 36 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.4 (4.3) Physical agility testing;
2-17.4 (4.3.1) Test Date,
2-17.4 (4.3.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.3.3) and Comments (free text).
2-17.4 (4.4) Background investigation;
2-17.4 (4.4.1) Investigator,
2-17.4 (4.4.2) Pass/Fail,
2-17.4 (4.4.3) and Comments (free text).
2-17.4 (4.5) Polygraph;
2-17.4 (4.5.1) Date,
2-17.4 (4.5.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.5.3) and Comments (free text).
2-17.4 (4.6) Oral Board;
2-17.4 (4.6.1) Date,
2-17.4 (4.6.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.6.3) and Comments (free text).
2-17.4 (4.7) Psychological;
2-17.4 (4.7.1) Date of exam,
2-17.4 (4.7.2) Psychologist,
2-17.4 (4.7.3) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.7.4) and Comments (free text).
2-17.4 (4.8) Physical;
2-17.4 (4.8.1) Date,
2-17.4 (4.8.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-17.4 (4.8.3) and Comments (free text).
2-17.4 (5) System must be able to export a table of pre-hire applicants as specified by personnel
staff to drive mail merge processes.
2-17.5 SCHEDULING AND ATTENDANCE 0 0 0 0
2-17.5 (1) The proposed scheduling system shall include a comprehensive work tracking system
that tracks calls for service, community service, and investigative activities carried out
by individual employees.
2-17.5 (2) The proposed scheduling system shall have the ability to create a Daily Activity Report
for a patrol officer or investigator that includes a chronological recitation of:
2-17.5 (2.1) Calls for service,
2-17.5 (2.2) Traffic stops,
2-17.5 (2.3) Pedestrian stops,
2-17.5 (2.4) Investigative activities,
2-17.5 (2.5) Community policing projects (by project code),
2-17.5 (2.6) Training, and
2-17.5 (2.7) Administrative activities.
2-17.5 (3) The proposed scheduling system shall include the ability to assign employees to a shift.
2-17.5 (4) The proposed scheduling system shall allow the system administrator or other
authorized user to define an unlimited number of rotational shifts.
City of Fort Collins Page 37 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.5 (5) The proposed scheduling system shall include the capability to define at least five
squads within each shift.
2-17.5 (6) Each squad shall have the ability to schedule different days off.
2-17.5 (7) The system administrator or other authorized user shall have the ability to assign
employees and other personnel to squads or shifts.
2-17.5 (8) The system administrator or other authorized user will have the ability to assign days
off, vacation days, holidays, and work hours by individual employee.
2-17.5 (9) The system administrator or other authorized user shall have the ability to assign days
off, holidays, and work hours to a squad and by association to the employees assigned
to that squad.
2-17.5 (10) The proposed personnel system shall allow the system administrator or other
authorized employee to determine minimum staffing levels for any shift.
2-17.5 (10.1) It is preferred that minimum staffing level function allow the system administrator or
other authorized employee to define required positions. For example, it may be that a
shift requires a minimum of two sergeants. The minimum staffing function should
monitor this and not allow a sergeant to take vacation if that will leave less than two
sergeants on duty for that shift.
2-17.5 (10.2) It is preferred that minimum staffing level function allow the system administrator or
other authorized employee to define required capabilities. For example, it may be that
a shift requires a minimum of one canine team. The minimum staffing function should
monitor this and not allow a canine officer to take vacation if that will leave the shift with
no canine teams.
2-17.5 (11) The proposed scheduling system shall allow employees to request vacation for any
date up to one year in advance, so long as minimum staffing levels have been met.
2-17.5 (12) When a vacation request is submitted, the system will deduct from the available
vacation slots.
2-17.5 (13) The proposed scheduling system shall record vacation requests and show them to the
scheduling supervisor in a distinctive manner.
2-17.5 (14) The proposed scheduling system shall allow employees to schedule sick leave for any
date up to one year in advance.
2-17.5 (15) When a sick leave request is submitted, the system will deduct from the available sick
leave slots.
2-17.5 (16) The proposed scheduling system shall record sick leave requests and show them to
the scheduling supervisor in a distinctive manner.
2-17.5 (17) At a minimum, the proposed scheduling system shall have the ability to handle the
following kinds of shifts:
2-17.5 (17.1) Eight hours, five days a week,
2-17.5 (17.2) Ten hours, four days a week,
2-17.5 (17.3) 12 hours, 2 on, 2 off, 2 on, 2 off, 2 on, 2 off, 2 on, 6 off,
2-17.5 (17.4) and 10.75 hours, 6 on (1 training day), 4 off, 5 on, 5 off, 4 on, 4 off.
2-17.5 (18) The proposed scheduling system shall allow administrators and supervisors to make up
a monthly, weekly and daily schedule for each major unit (e.g. patrol, traffic, SIU,
investigations, etc.)
2-17.5 (19) The proposed scheduling system shall include the ability to make up a shift roster that
includes the following information:
2-17.5 (19.1) First and last full name of the officer,
City of Fort Collins Page 38 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.5 (19.2) Unit to which the officer is assigned,
2-17.5 (19.3) Patrol district or location of assignment,
2-17.5 (19.4) Officer’s radio call sign,
2-17.5 (19.5) Officer's phone or pager number, and
2-17.5 (19.6) Officer’s vehicle number.
2-17.5 (20) It shall be possible for a supervisor to assign an employee from another squad, shift or
work assignment to a roster at any time.
2-17.5 (21) The proposed scheduling system shall allow dispatchers to use the electronic roster to
place units on and off duty.
2-17.5 (22) It is preferred that the proposed scheduling system enable a scheduling supervisor to
assign employees to squads, days off, holidays, and units with a "point and click"
function.
2-17.5 (23) It shall be possible to display and print the roster by shift and date.
2-17.5 (24) It shall be possible for court employees and other authorized persons to view an officer
or employee's schedule so that they will not schedule court days on regularly
scheduled days off and vacation days.
2-17.5 (25) The proposed RMS/JMS application shall have the ability to track the following
information about "Off Duty" employment:
2-17.5 (25.1) The employer's name, address and phone number,
2-17.5 (25.2) The physical location and phone number of the assignment, and
2-17.5 (25.3) The scheduled off-duty employment time.
2-17.6 CAD INTERFACE TO PERSONNEL 0 0 0 0
2-17.6 (1) The proposed personnel system shall be integrated/interfaced with the proposed CAD
such that CAD will draw from the personnel system for information such as officers with
special skills, shift assignment, etc.
2-17.6 (2) The proposed system may maintain a personnel file in the CAD for performance or
other reasons. In this case the system shall ensure that the shared personnel system
shall have primacy over the CAD personnel files and that changes to the shared
personnel system are successfully written to the CAD personnel file.
2-17.6 (3) At a minimum the system shall share the following personnel fields with the CAD
personnel file:
2-17.6 (3.1) employee name (first, middle and last),
2-17.6 (3.2) employee rank,
2-17.6 (3.3) employee ID or badge number,
2-17.6 (3.4) Social Security number,
2-17.6 (3.5) employee shift assignment,
2-17.6 (3.6) district and duty assignment, and
2-17.6 (3.7) special skills.
2-17.6 (4) The proposed system shall refer to the personnel skills, assignment and district,
entered in the personnel module when a CAD operator searches for special resources.
2-17.6 (5) The proposed system shall transfer the shift roster from the personnel system to the
CAD and shall place the oncoming units and officers on duty when the dispatcher
invokes the function.
2-17.6 (6) The dispatcher shall place each unit in service manually.
2-17.7 PERSONNEL REPORTS 0 0 0 0
City of Fort Collins Page 39 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.7 (1) The proposed RMS/JMS application shall include a Daily Activity Report for a given
officer and date that details the activity recorded for that officer by the CAD application
and the activity reporting system.
2-17.7 (2) The proposed RMS/JMS application shall include a Monthly Activity Report for a given
officer and date that details the activity recorded for that officer by the CAD application
and the activity reporting system.
2-17.7 (3) The proposed RMS/JMS application shall include, based on log on, Time and
Attendance Reports that details:
2-17.7 (3.1) The attendance of a given officer for a given date or date range period, and
2-17.7 (3.2) The attendance of the personnel assigned to a given shift for a given date or date
range.
2-17.7 (4) The proposed RMS/JMS application shall include an Assignment Report that details the
assignments of all personnel working during a user-defined shift and date.
2-17.7 (5) The proposed RMS/JMS application shall include a Daily Attendance Report which
details the total number of regular, sick, vacation, overtime and leave of absence hours
recorded for a given date.
2-17.7 (6) The proposed RMS/JMS application shall include a Work Schedule Report that shows
the assigned shift and days off by day for each section, for a user-defined period of
months.
2-17.7 (7) The proposed RMS/JMS application shall include a Seniority Report which lists staff by
rank and then by seniority in rank.
2-17.7 (8) The proposed RMS/JMS application shall include a Recall Report that lists the home
address and contact numbers for each officer and employee. As with all reports, the
system administrator or other authorized user shall have the ability to restrict printing of
the report by security profile.
2-17.7 (9) The proposed RMS/JMS application shall include a Pager List Report that lists the
pager and Department assigned cell telephone number for each officer or employee.
2-17.7 (10) Must be able to run a report to show the number of officers with POST certificates.
This report must display and be able to run by:
2-17.7 (10.1) Department,
2-17.7 (10.2) Division,
2-17.7 (10.3) Section,
2-17.7 (10.4) Unit,
2-17.7 (10.5) Rank,
2-17.7 (10.6) Shift,
2-17.7 (10.7) and Certificate.
2-17.7 (11) The report must include but not be limited to the above information and include the date
the certificate was received.
2-17.7 (12) Must be able to run a report to show the number of sworn officers by:
2-17.7 (12.1) Position,
2-17.7 (12.2) Race,
2-17.7 (12.3) and Gender.
2-17.7 (13) Must be able to run a report to show the number civilians by:
2-17.7 (13.1) Position,
2-17.7 (13.2) Race,
City of Fort Collins Page 40 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-17.7 (13.3) and Gender.
2-18 TRAINING DATABASE 0 0 0 0
2-18.1 (1) The proposed RMS/JMS application shall include a function for tracking and managing
training for all agency personnel.
2-18.1 (2) The proposed system shall maintain training records on each agency employee that
has a record in the personnel tracking system that includes:
2-18.1 (2.1) A link to the employee’s name record that displays;
2-18.1 (2.1.1) Agency,
2-18.1 (2.1.2) Employee ID or badge number,
2-18.1 (2.1.3) Last and first name,
2-18.1 (2.1.4) and Current job assignment.
2-18.1 (2.2) A record of every course the employee has attended that includes;
2-18.1 (2.2.1) Course type,
2-18.1 (2.2.2) Course title,
2-18.1 (2.2.3) Course number,
2-18.1 (2.2.4) Course date,
2-18.1 (2.2.5) Course hours,
2-18.1 (2.2.6) Course description,
2-18.1 (2.2.7) Instructor's name,
2-18.1 (2.2.8) Date of completion,
2-18.1 (2.2.9) Location of training,
In house or outside training,
Institution providing training,
Grade received,
Certificate or degree provided,
Indication if training was mandatory or optional,
Certification expiration date, and
Cost.
2-18.1 (3) It shall be possible to configure the proposed training system with required courses and
certifications so that training and certification and re-certification will not be allowed to
lapse.
2-18.1 (4) The proposed training system shall have the ability to schedule periodic tests.
2-18.1 (5) The proposed training system shall have the ability to schedule periodic training.
2-18.1 (6) The proposed RMS/JMS application shall include a notification of required re-tests for
officers and employees, including certifications and inoculations.
2-18.1 (7) The training system shall allow the training coordinator to establish minimum training
requirements for different classes of employees.
2-18.1 (8) The training system shall enable instructors to enter attendance for each employee
enrolled in a training course with some type of mass assignment tool.
2-18.1 (9) The proposed RMS/JMS application shall include a means for instructors to enter notes
about training classes or individuals.
2-18.1 (10) The training system shall maintain a database of certified trainers/instructors.
2-18.1 (11) The training system shall enable instructors to enter examination and final grade scores
for each employee enrolled in a training course.
2-18.1 (2.2.10)
2-18.1 (2.2.11)
2-18.1 (2.2.12)
2-18.1 (2.2.13)
2-18.1 (2.2.14)
2-18.1 (2.2.15)
2-18.1 (2.2.16)
City of Fort Collins Page 41 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-18.1 (12) The training system module shall allow the training coordinator to develop an annual
training schedule for in-service, recruit and other types of training.
2-18.2 TRAINING REPORTS 0 0 0 0
2-18.2 (1) The proposed RMS application shall include a Training Report that details the training
courses completed and the chronological hours expended in training for a given
officer/employee during a user-defined date range.
2-18.2 (2) The proposed RMS application shall include a Departmental Training Report that
details the total hours expended on training for all members of the Department during a
user-defined date range. This report shall subtotal training efforts by the category, e.g.
POST, in-service, personal, etc.
2-18.2 (3) The proposed RMS application shall include a Certification Expiration report that shows
all required training courses and certifications, and then lists any personnel whose
certifications will expire during the user-defined date range.
2-18.2 (4) In addition to the other training reports, the proposed application shall include a K-9
training report with the following elements:
2-18.2 (4.1) Date and time of training,
2-18.2 (4.2) Team name,
2-18.2 (4.3) Location of training,
2-18.2 (4.4) Weather conditions,
2-18.2 (4.5) Decoy type,
2-18.2 (4.6) Total hours of training,
2-18.2 (4.7) Narrative,
2-18.2 (4.8) Handler notes, and
2-18.2 (4.9) Activity.
2-18.2 (5) After all information is entered in reference to the training, a report should be generated
for all inside training which meets Colorado Police Officer Standardized Training
(POST) requirements. This report should include but not be limited to:
2-18.2 (5.1) Title of training,
2-18.2 (5.2) Number in attendance,
2-18.2 (5.3) Date of training,
2-18.2 (5.4) Social Security number,
2-18.2 (5.5) Date of birth,
2-18.2 (5.6) Name: Last, First, Middle,
2-18.2 (5.7) Signature line,
2-18.2 (6) A report will be run every 12 and 24 months which will search the training data base
and total the number of hours for inside and outside training within the date criteria.
There will be a separate total for inside and a separate total for outside. Any training of
less than one hour will not be included in the report.
2-18.2 (7) A report will be generated to list who has or has not attended certain training. This
report will be generated based on either word search or date(s). The report will include
but not be limited to:
2-18.2 (7.1) Name: First, Last, Middle,
2-18.2 (7.2) Date(s) of attendance,
2-18.2 (7.3) Number of hours,
2-18.2 (7.4) Location of training,
City of Fort Collins Page 42 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-18.2 (7.5) Division and shift,
2-18.2 (7.6) and Supervisor.
2-18.2 (8) A report will be generated using name and/or date search criteria to report the number
of training hours, over one hour, for all employees for the criteria entered. The report
will include, but not be limited to:
2-18.2 (8.1) Name: First, Last, Middle,
2-18.2 (8.2) Total number of hours,
2-18.2 (8.3) Training attended,
2-18.2 (8.4) and Date(s) of training.
2-18.2 (9) A report will be generated to report the average training hours by:
2-18.2 (9.1) Department,
2-18.2 (9.2) Division,
2-18.2 (9.3) Section,
2-18.2 (9.4) Rank,
2-18.2 (9.5) Division,
2-18.2 (9.6) and Shift.
2-18.3 ACADEMY PROCESS 0 0 0 0
Applicant Information (This database should be restricted to access by Training &
Personnel only except for searches which will display only information relevant to
criminal identification, e.g. race, sex, dob, name, address, social security number, and
drivers license number)
2-18.3 (1) The system must be able to capture all information in reference to applicants for the
academy. This should include personal information as follows:
2-18.3 (1.1) Academy Number,
2-18.3 (1.2) Academy Type (Post, Citizen, Reserve, etc.)
2-18.3 (1.3) Academy Date(s)
2-18.3 (1.4) Student agency
2-18.3 (1.5) Student ID and/or badge number (alpha/numeric, minimum of 8 characters),
2-18.3 (1.6) Student’s full name (last, first and middle), with support for hyphenated last names and
name suffixes,
2-18.3 (1.7) Date and place of birth,
2-18.3 (1.8) Current Age (continuously calculated from DOB),
2-18.3 (1.9) Social Security number,
2-18.3 (1.10) Drivers license number and expiration date,
2-18.3 (1.11) Physical description that includes; gender, race/ethnicity, height, weight, eye and hair
color,
2-18.3 (1.12) Digital photo,
2-18.3 (1.13) Student home address that includes; street number & name, po box, city, state, and
zip,
2-18.3 (1.14) Student work name and address that includes; street number & name, po box, city,
state, and zip,
2-18.3 (1.15) At least four fields for telephone, mobile phone, and pager numbers,
2-18.3 (1.16) and Email address.
City of Fort Collins Page 43 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-18.3 (2) System must also capture information relating to the academy application process that
includes the following:
2-18.3 (2.1) Date application received,
2-18.3 (2.2) Written exam information;
2-18.3 (2.2.1) Test date,
2-18.3 (2.2.2) Test time,
2-18.3 (2.2.3) Score,
2-18.3 (2.2.4) Military points,
2-18.3 (2.2.5) Total test score,
2-18.3 (2.2.6) Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.2.7) and Comments (free text).
2-18.3 (2.3) Physical agility testing;
2-18.3 (2.3.1) Test Date,
2-18.3 (2.3.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.3.3) and Comments (free text).
2-18.3 (2.4) Background investigation;
2-18.3 (2.4.1) Investigator,
2-18.3 (2.4.2) Pass/Fail,
2-18.3 (2.4.3) and Comments (free text).
2-18.3 (2.5) Polygraph;
2-18.3 (2.5.1) Date,
2-18.3 (2.5.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.5.3) and Comments (free text).
2-18.3 (2.6) Oral Board;
2-18.3 (2.6.1) Date,
2-18.3 (2.6.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.6.3) and Comments (free text).
2-18.3 (2.7) Psychological;
2-18.3 (2.7.1) Date of exam,
2-18.3 (2.7.2) Psychologist,
2-18.3 (2.7.3) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.7.4) and Comments (free text).
2-18.3 (2.8) Physical;
2-18.3 (2.8.1) Date,
2-18.3 (2.8.2) Pass/Fail/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.8.3) and Comments (free text).
2-18.3 (2.9) Academy overall;
2-18.3 (2.9.1) Date,
2-18.3 (2.9.2) Pass/Fail/Terminated/Failed to Appear (FTA)/Withdrew (WD),
2-18.3 (2.9.3) and Comments (free text).
2-18.4 ACADEMY REPORTS 0 0 0 0
City of Fort Collins Page 44 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-18.4 (1) Must be able to run a report to show totals for each stage in the academy selection
process. The report must show number and percentage change from total, and
number and percentage change from one stage to the next. Also must include race
and gender. This report must have the ability to run on any of the input fields. This
report will include but not be limited to:
2-18.4 (1.1) Initial application,
2-18.4 (1.2) Initial interview,
2-18.4 (1.3) Written test,
2-18.4 (1.4) Physical agility test,
2-18.4 (1.5) Background investigation,
2-18.4 (1.6) Polygraph examination,
2-18.4 (1.7) Oral interview,
2-18.4 (1.8) Psychological examination,
2-18.4 (1.9) Physical examination,
2-18.4 (1.10) Academy (Academic),
2-18.4 (2) Must be able to run a report to show all Failed to Appear and Withdraw for each step of
the academy process.
2-18.4 (3) Must be able to run a roster of all the recruits in an academy to include but not be
limited to:
2-18.4 (3.1) Name,
2-18.4 (3.2) Student Number,
2-18.4 (3.3) Social Security number,
2-18.4 (3.4) Drivers license number,
2-18.4 (3.5) Race,
2-18.4 (3.6) Gender,
2-18.4 (3.7) Date of birth,
2-18.4 (3.8) Age,
2-18.4 (3.9) Address (to include city, state & zip),
2-18.4 (3.10) and Phone.
2-19 SUPPLIES, EQUIPMENT AND FACILITY MANAGEMENT SYSTEM
2-19.1 SUPPLY ORDER AND TRACKING 0 0 0 0
2-19.1 (1) The proposed RMS/JMS application shall include a module that maintains an
innovatory of consumable supplies that are issues and no longer tracked. This module
would track stock, set order points, and provide accounting for the acquisition, storing,
and distribution of all consumable supplies.
2-19.1 (2) This module shall have the ability to maintain records for no less than 99,999 different
supply items.
2-19.1 (3) At a minimum the supply order and tracking module shall perform the following:
2-19.1 (3.1) Allow for separate supply tracking processes for each participating agency,
2-19.1 (3.2) Allow for separate supply tracking process for subdivisions of each participating agency
(i.e. Janitorial, Maintenance, Supply).
2-19.1 (3.3) Tracking on every stocked item that includes; product (item) type, manufacturer item
number, other (vendor) item numbers, item description, item quantity, item cost, and
reorder point,
City of Fort Collins Page 45 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-19.1 (3.4) Cost tracking for all ordered supplies (both stocked and pass through),
2-19.1 (3.5) Ability to project costs for supplies,
2-19.1 (3.6) Maintain an order history of all supplies (including the date of last order),
2-19.1 (3.7) Build orders and allow the user to attach vendors (from the vendor database) based on
product type (a list of possible vendors would display for selection based on the type of
supplies to order),
2-19.1 (3.8) Show costing on orders that includes both the unit cost ant lot cost,
2-19.1 (3.9) and Track the distribution of supplies that includes; name of person receiving supplies,
cost for supplies, work unit of recipient, and full detailed listing of supplies.
2-19.1 (4) The proposed RMS/JMS application shall have a means of tracking the use of supplies
and maintaining an accurate accounting of quantities in stock.
2-19.1 (5) The proposed RMS/JMS application shall have the ability to track a reorder quantity for
each supply and notify the supply officer when the reorder quantity has been reached.
2-19.1 (6) The proposed RMS/JMS application shall have a means for reconciling supply use with
inventory on hand.
2-19.1 (7) The proposed RMS/JMS application shall allow for the electronic routing of supply
requests to include an approval process (routing to a defined chain of command for
each requestor). Supply requests would require pertinent information based on item
requested.
2-19.1 (8) The proposed RMS/JMS application shall include a report which shows the current
supplies inventory by category of supply, location, or unit.
2-19.2 EQUIPMENT INVENTORY AND MAINTENANCE 0 0 0 0
2-19.2 (1) The proposed RMS/JMS application shall include a module that maintains an inventory,
tracks possession, and keeps a maintenance history of all types of equipment assets
used for varying purposes by all of the participating agencies. Equipment is defined as
any asset that is not considered a consumable item.
2-19.2 (2) The proposed system shall have the ability to track equipment issued to employees,
such as uniforms, badges, key cards, weapons, computers, cars, etc.
2-19.2 (3) This module shall have the ability to maintain records for no less than 99,999 different
equipment items.
2-19.2 (4) At a minimum the Equipment Inventory and Maintenance module shall perform the
following:
2-19.2 (4.1) Allow for separate equipment tracking processes for each participating agency,
2-19.2 (4.2) Allow for separate equipment tracking process for subdivisions of each participating
agency (i.e. Janitorial, Maintenance, Supply).
2-19.2 (4.3) Support a bar-coding device to capture inventory control tags,
2-19.2 (4.4) Allow for assigned inventory control numbers,
2-19.2 (4.5) Record serial or identification number,
2-19.2 (4.6) Description of the equipment,
2-19.2 (4.7) Cost of the equipment,
2-19.2 (4.8) Ability to assign the equipment to an individual, mobile unit, or location,
2-19.2 (4.9) and Allow for equipment to be tracked as peers or subservient to another piece of
equipment (equipment assigned to a vehicle, vehicle assigned to a person).
City of Fort Collins Page 46 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-19.2 (5) The system shall capture all the necessary information to fully track a vehicle
assignment (lists unit number, all equipment installed in that vehicle, and officer vehicle
is assigned to).
2-19.2 (6) The system shall capture all the necessary information to fully track officer uniform and
equipment check out (lists all uniforms and equipment checked out to each officer and
updates inventory records as additional items are checked out or returned).
2-19.2 (6.1) It is desired that this check out form should be divided into sections, listing uniforms
and related equipment (belts, leather gear) with sizes in one section, and tracked
equipment in another section (such as cameras, PBT’s etc.) with capability of entering
serial number, bar code number, model, and/or brand. Firearms would be in another
section with serial number, bar code number, brand name, caliber, and related
equipment (scope, sling, ammo carrier, etc.). Date of check out or return must also be
noted.
2-19.2 (7) Ability to search for any equipment or uniform item and run a report of every employee
who has that item issued to them, with related information (serial numbers, quantity,
etc.). For example, run a report of all employees who have a Remington 870 shotgun.
2-19.2 (8) Allow employees to view the record of the uniforms and equipment issued to them, but
limit editing to authorized personnel assigned to the Supply unit.
2-19.2 (9) Allow authorized personnel in the Supply Unit to retrieve a list of all items issued to a
particular officer, and to select from this list which items are being returned to inventory.
2-19.2 (10) The proposed RMS/JMS application shall include a report which lists all property
(uniforms, door cards, guns, etc.) assigned to each Officer or employee. The report will
include a description of each item and any identifying number.
2-19.2 (11) System should track items returned to Supply by either putting them back into
inventory, or removing them from inventory and documenting the reason for removal.
The item may have been damaged or no longer in usable condition, lost, stolen,
donated to another agency, etc.
2-19.2 (12) Ability to run a report of all items removed from inventory, specifying the reason, and
the date of removal.
2-19.2 (13) All items issued or returned should be marked in the system with the date issued or
returned.
2-19.2 (14) The proposed RMS/JMS application shall keep a maintenance history of all pieces of
equipment that requires maintenance, that includes; useful life, cost tracking,
preventive maintenance interval, repair history, and a repair threshold notification (user
defined threshold to notify about problem equipment).
2-19.2 (14.1) The proposed RMS/JMS application shall automatically send notifications that
preventive maintenance work needs to be performed as maintenance intervals expire.
2-19.2 (15) The proposed RMS/JMS application shall have the ability to keep a parts inventory per
each piece of tracked equipment, and maintain a history of parts use along with a stock
quantity of the parts.
2-19.2 (16) The proposed RMS/JMS system shall have the ability to print a list of all equipment
assigned to an employee, unit, station or other location.
2-19.3 FACILITY MANAGEMENT 0 0 0 0
2-19.3 (1) The proposed RMS/JMS system shall have a job ticket process that allows any system
user to make an electronic request to the facility maintenance staff for any of the
following;
City of Fort Collins Page 47 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-19.3 (1.1) facility maintenance need,
2-19.3 (1.2) damage or breakage repair,
2-19.3 (1.3) work order.
2-19.3 (2) The RMS/JMS must allow for separate job ticket processes for each participating
agency,
2-19.3 (3) The RMS/JMS must allow for separate job ticket processes for subdivisions of each
participating agency (i.e. Janitorial, Maintenance, etc.).
2-19.3 (4) The RMS/JMS must allow for global job ticket processes across the entire system.
2-19.3 (5) The job ticket system shall have the ability to set priority levels, both at initial request,
and upon review by maintenance staff.
2-19.3 (6) The job ticket system shall have the ability to merge multiple requests about the same
thing into one request that tracks all the requestors.
2-19.3 (7) The job ticket system shall have the ability to schedule to expected completion of the
job ticket.
2-19.3 (8) The job ticket system shall have the ability for any user of the system to look at all the
information on all job tickets, regardless of status.
2-19.3 (9) The job ticket system shall have specific fields that will be searchable by a query form
that allows for limiting the amount of responses. At minimum the job ticket should
contain the following fields;
2-19.3 (9.1) type of request (pick list),
2-19.3 (9.2) level of request (pick list),
2-19.3 (9.3) status of request (pick list)
2-19.3 (9.4) location of request (pick list),
2-19.3 (9.5) classification of request (pick list),
2-19.3 (9.6) last name of requestor,
2-19.3 (9.7) first name of requestor,
2-19.3 (9.8) requestor contact info (phone number, e-mail, etc.),
2-19.3 (9.9) link to previous request (job ticket number),
2-19.3 (9.10) chronic problem flag (check box),
2-19.3 (9.11) date of request,
2-19.3 (9.12) expected date of completion,
2-19.3 (9.13) narrative of request.
2-19.3 (10) The job ticket system shall notify designated personnel of pending job ticket requests.
2-19.3 (11) The job ticket system shall notify designated personnel of overdue job ticket requests.
2-19.3 (12) The job ticket system shall notify designated personnel of chronic problems based on
the chronic problem flag or on a threshold set by the agency of number of requests of a
specific type, in a specific area, of a specific classification, within a specified time
period.
2-19.3 (13) The job ticket system shall notify the requester(s) upon completion of the job ticket.
2-19.3 (14) The job ticket system shall have the ability to build a knowledge base of problem
resolutions that will be searchable by the fields above or by text string.
2-19.4 VENDOR DATABASE 0 0 0 0
2-19.4 (1) The proposed RMS/JMS shall have the ability to maintain lists of vendors that sell
supplies and equipment and that provide services for facility management.
2-19.4 (2) The system shall allow for separate vendor lists for each participating agency,
City of Fort Collins Page 48 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
2-19.4 (3) The system shall allow for vendor lists for subdivisions of each participating agency (i.e.
Janitorial, Maintenance, Supply).
2-19.4 (4) At a minimum the vendor database module shall record the following:
2-19.4 (4.1) Vendor Name,
2-19.4 (4.2) Vendor address,
2-19.4 (4.3) Contact Name, phone, fax, e-mail,
2-19.4 (4.4) The agency customer or account number,
2-19.4 (4.5) Comment field,
2-19.4 (4.6) List types of product types sold or services performed (multiple per vendor),
2-19.4 (4.7) and a Link to order processing.
2-20 MISCELLANEOUS FUNCTIONS
2-20.1 LOOKOUTS 0 0 0 0
2-20.1 (1) The proposed application shall offer a means for entering, storing, retrieving and
managing BOLO’s and broadcast messages.
2-20.1 (2) The proposed application shall provide a BOLO form which contains specific fields for
the following:
2-20.1 (2.1) Suspect,
2-20.1 (2.2) Vehicle/Property descriptions,
2-20.1 (2.3) Related event numbers,
2-20.1 (2.4) Event location,
2-20.1 (2.5) Date/Time of event,
2-20.1 (2.6) BOLO number (automatically populated),
2-20.1 (2.7) Purge date,
2-20.1 (2.8) Unlimited free-form text field.
2-20.1 (3) Preference will be given to solutions which allow the user to specify when creating a
BOLO for how many days and times per day the BOLO will be broadcast.
2-20.1 (4) The BOLO database shall utilize cut/copy/paste functions.
2-20.1 (5) The database shall store no less than 6 months worth of BOLO’s.
2-20.1 (6) At a minimum, the proposed application shall allow an authorized user to search for a
BOLO by:
2-20.1 (6.1) BOLO number,
2-20.1 (6.2) location,
2-20.1 (6.3) complainant,
2-20.1 (6.4) a person named in the lookout,
2-20.1 (6.5) a person described in the lookout,
2-20.1 (6.6) a vehicle described in the lookout,
2-20.1 (6.7) date and time of entry, and
2-20.1 (6.8) the name of the employee entering the lookout.
2-20.1 (7) The proposed application shall allow the user to route BOLO’s to units equipped with
mobile computers and other workstations on the network.
2-20.1 (8) The proposed application shall allow a user to cross-reference a BOLO to a CAD event
and/ or a case (report) number.
2-20.1 (9) The proposed application shall allow any user whether they are working in the RMS,
CAD, MDC or JMS application be able to initiate a BOLO.
City of Fort Collins Page 49 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
SECTION TOTALS 0 0 0 0
City of Fort Collins Page 50 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3 COMPUTER AIDED DISPATCH
3-1 SYSTEM DESIGN
3-1.1 GENERAL REQUIREMENTS 0 0 0 0
3-1.1 (1) The proposed application shall utilize an “incident/entry mask” for all call entry. This
mask will be retrievable with one keystroke combination and will contain the following
fields. The minimum number of characters per field are identified as follows:
3-1.1 (1.1) Numeric Address: 6 Characters
3-1.1 (1.2) Address directional: 2 Characters
3-1.1 (1.3) Street: 25 Characters
3-1.1 (1.4) Street Suffix: 4 Characters
3-1.1 (1.5) Intersections: 50 Characters
3-1.1 (1.6) Apt/Trailer numbers: 5
3-1.1 (1.7) Building number: 5
3-1.1 (1.8) Incident Type: 6 Characters
3-1.1 (1.9) Incident Location: 60 Characters
3-1.1 (1.10) Informant Name: 35 Characters
3-1.1 (1.11) Informant Address: 60 Characters
3-1.1 (1.12) Informant Phone Number: 10 Characters
3-1.1 (1.13) Phone extension: 5 Characters
3-1.1 (1.14) Text of Incident: 400 Characters
3-1.1 (1.15) Priority Field: 2 Characters
3-1.1 (1.16) Disposition Field: 6 Characters
3-1.1 (1.17) Police/Fire Area Field: 3 Characters
3-1.1 (2) It is preferred that all telephone number fields allow for the entry of 12 digits so that the
country code may be recorded when necessary.
3-1.1 (3) The proposed application shall allow authorized user to configure/map the keyboard as
needed.
3-1.1 (4) The participating agencies will give preference to solutions, which provide controls for
scrolling all free form text and comment fields.
3-1.1 (5) In any case where the proposed application presents multiple “pages” of information or
the information cannot be displayed within the available space there shall be a clear
indication to the user that information remains to be displayed.
3-1.1 (6) The proposed application shall allow the user to either page or scroll forward and
backward through the material by using the keyboard or a pointing device.
3-1.1 (7) When a search results in the retrieval of multiple records, the CAD application shall
allow the system administrator or authorized user to determine the sort method by
display type. For example, if an address has multiple records of previous calls for
service they might be displayed by date beginning with the most recent event.
3-2 CAD CLIENT
3-2.1 GENERAL REQUIREMENTS 0 0 0 0
3-2.1 (1) There shall be no limit on the number of workstations, which can simultaneously
access the CAD system (given proper security clearance and network connections).
City of Fort Collins Page 51 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.1 (2) The proposed application shall make efficient use of input methods (command line
short cut keys, function keys, graphic command buttons, etc.) recognizing the different
ways that operators use the proposed application.
3-2.1 (3) The proposed application shall offer a minimum of 10 work screens/windows for
dispatchers to work on. For example, handling multiple call entries or having multiple
vehicle or drivers license listings on the computer at one time and being able to work
on each without affecting the others.
3-2.1 (3.1) The screens shall be easy to “toggle” between and will not require the dispatcher to
“save” any information in any sort of memory or buffer system which would require
multiple keystrokes to retrieve later.
3-2.1 (4) The proposed system shall allow users to view different jurisdictions/agencies pending
and active calls. This will be done from screen layouts, which will be user configurable.
3-2.1 (5) The Proposed system shall allow users to view different jurisdictions/agencies unit
status information. This will be done from screen layouts, which will be user
configurable.
3-2.1 (6) In the event of a system failure (not including power outages) users signed on to CAD
at the time of the failure shall be able to view:
3-2.1 (6.1) Pending Events
3-2.1 (6.2) Stacked or Waiting Events
3-2.1 (6.3) Events in Progress
3-2.1 (6.4) Units on Duty and Last Known Location,
3-2.1 (6.5) Units Assigned and last known location, including units engaged in traffic stops,
administrative statuses, or other non-event activities.
3-2.1 (7) The proposed CAD workstations shall have the capability to support at least three
monitors.
3-2.2 LOCATION AND NUMBER OF CAD CLIENTS 0 0 0 0
3-2.2 (1) Location/Definition (all clients must be capable of full functionality)
3-2.3 USER INTERFACE 0 0 0 0
3-2.3 (1) ****CRITICAL FUNCTIONALITY**** The primary CAD interface for call takers and
dispatcher shall be a command line.
3-2.3 (2) It is preferred that the system administrator or other authorized user to enter aliases for
system supported command codes. For example, if the proposed application uses the
letters I.E. as shorthand for Initiate Event, the system administrator or authorized user
shall be able to enter the letters NE (New Event) as an alias for the system supported
I.E. command.
3-2.3 (3) It is preferred that the system administrator or other authorized users have the ability
change the default order of command parameters to allow entry of the required
information in any order. For example, if the I.E. command is followed by the location
of the call, the event type and the reporting person’s name in the vendor’s product, the
system administrator or authorized user shall be able to modify the application to
accept the event type, then location, then reporting person.
3-2.3 (4) The proposed application shall include a single key or single keystroke combination
command which will return the user to the CAD command line from any other
application, module or window.
City of Fort Collins Page 52 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.3 (5) At a minimum the proposed application shall allow the user to recall up to 50 previously
entered command line entries and reuse them as they were typed in or to modify and
re-submit them.
3-2.3 (6) The proposed application shall allow the number, size, location, orientation, content
and color-coding of status windows to be configured by the user agency.
3-2.3 (7) It is preferred that the CAD client allow the status window configuration to be tied to the
user’s log on.
3-2.3 (8) The proposed application shall allow all users to configure the windows to suit their
individual needs.
3-2.3 (9) Message and dialog boxes, which are displayed automatically by the proposed
application, rather than in response to a user request, shall not cover other windows so
as to impede the efficient processing of calls for service or other work.
3-2.3 (10) Error messages shall be displayed in a location, which will not hinder the operator’s
view of other data.
3-2.3 (10.1) Error messages shall be displayed in a consistent location.
3-2.3 (11) The proposed application shall allow an authorized user to edit any field in the incident
mask from the command line and from a form. These changes shall be accomplished
in calls that are:
3-2.3 (11.1) Pending
3-2.3 (11.2) Active
3-2.3 (11.3) Closed (without re-opening)
3-2.3 (11.4) Cancelled (without re-opening)
3-2.3 (12) The proposed application shall allow an incident to be retrieved for edits by utilizing the
following:
3-2.3 (12.1) Incident number i.e. “chg #1234…..”
3-2.3 (12.2) Unit number i.e. “chg 8K58…..”
3-2.3 (12.3) Case (report) number
3-2.3 (13) Any time a field value is changed the system shall track the previous value in the audit
trail and attach a time/date/user stamp.
3-2.3 (14) It is preferred that the software solution incorporate data validation at the field level for
CAD workstations. The object of this requirement is to enhance system use by
catching incorrect entries and incomplete forms prior to the user sending them to the
CAD application for processing.
3-2.3 (15) In the event that the data entered into a restricted field is incorrect or incomplete the
proposed application shall return the cursor to the first incorrect or incomplete field
automatically and provide an explanation of the error or the required information
somewhere on the screen.
3-2.3 (16) It is preferred that the proposed system allow on-line help at the incident field level.
3-2.3 (17) In the event that the user has made more than one mistake the proposed application
shall step through each incorrect field sequentially until all corrections have been made.
3-2.3 (18) The proposed application shall have the ability to perform logic checks on entered data
as well. For example, if the user has not entered correct incident type the system shall
flag it as an error. The following fields shall utilize this logic check:
3-2.3 (18.1) Incident Type
City of Fort Collins Page 53 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.3 (18.2) Priority Field
3-2.3 (18.3) Disposition Field
3-2.3 (18.4) Police Area Field
3-2.3 (19) If a field has restricted values the user shall only be able to choose one of the
previously defined values.
3-2.3 (20) The proposed application shall alert the user both visually and audibly that an answer
to a previously submitted query has been received.
3-2.3 (21) The alert of an arriving return shall not interrupt the user’s workflow.
3-2.3 (22) It is preferred that the system incorporate a counter into their alert so that users can
see how many returns are waiting to be viewed.
3-2.3 (23) It is preferred that the system differentiate the return by the sender (e.g. NCIC, DMV,
RMS, etc.).
3-2.3 (24) The time, position ID number, User ID number, and CAD mode (live or training) shall be
displayed discreetly in the work area at all times while a workstation is logged on.
3-2.3 (25) The proposed application shall support the following means in which a dispatcher or
call-taker may enter, query, or edit incident information:
3-2.3 (25.1) By command line functions,
3-2.3 (25.2) By pointing device (mouse functions with drop down menus),
3-2.3 (25.3) By forms,
3-2.3 (25.4) Or check box.
3-2.3 (26) The proposed application shall allow unit status changes to be completed in the
following ways:
3-2.3 (26.1) By command line functions,
3-2.3 (26.2) By pointing device (mouse functions with drop down menus),
3-2.3 (26.3) Or check box.
3-2.3 (27) The proposed application shall allow new events to be entered directly from the
command line.
3-2.4 EVENT AND UNIT STATUS MONITORS AND FUNCTIONS 0 0 0 0
3-2.4 (1) The proposed application shall allow for no less than 300 user-defined units and event
statuses per dispatcher/district.
3-2.4 (2) Each event and unit status shall have an associated user-defined timer.
3-2.4 (3) The proposed application shall use color or other visual signals as well as text to help
differentiate unit and event statuses. For example, the notation for an en route unit
might be a white “EN” on a black background. The notation for an en route unit, which
has timed out might be a red “EN” on a black background.
3-2.4 (4) The proposed application shall allow the System Administrator or authorized user to
select which colors and color combinations indicate which statuses.
3-2.4 (5) If the application uses audible alerts, the application shall allow the system
administrator or authorized user to disable these alerts on a task basis.
3-2.4 (6) It is preferred that the proposed application have the capability to activate an audible
signal when an event update includes a higher priority.
3-2.4 (7) It is preferred that each unit status have a means of defining whether a unit in the
status shall be:
3-2.4 (7.1) Recommended for an assignment,
3-2.4 (7.2) Available for an assignment even though not recommended.
City of Fort Collins Page 54 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.4 (8) The proposed application shall allow the use of “status codes”. Status codes shall be
configured as needed by the System Administrator or authorized user. (Status codes
are defined as codes used by units to log administrative time, meal breaks, and other
activity that does not require an incident to be initiated)
3-2.4 (9) The proposed application shall allow for at least two character status codes.
3-2.4 (10) The proposed application shall allow for status codes to be color coded by the System
Administrator or authorized user
3-2.4 (11) The proposed application shall allow status of all units on a single incident be changed
at once by utilizing the incident number from the command line i.e. “#1234 C4”.
3-2.4 (12) The proposed application shall allow for at least 5 unit’s status’ to be changed at one
time from the command line.
3-2.4 (13) The proposed application shall allow users to initiate status changes with the command
line and by using a pointing device (mouse) with an associated “drop down” menu that
lists all status codes.
3-2.4 (14) Each status change shall be time\date\user stamped and recorded in the audit trail.
3-2.4 (15) The proposed application shall allow the system administrator or authorized user to
define status windows.
3-2.4 (16) At a minimum the application shall allow for the following event and unit windows:
3-2.4 (16.1) Events which have not be reviewed by a dispatcher (Waiting/new)
3-2.4 (16.2) Events which have been reviewed and are waiting to be dispatched(Pending)
3-2.4 (16.3) Stacked events
3-2.4 (16.4) Active events
3-2.4 (16.5) Units on duty and available
3-2.4 (16.6) Units assigned to calls (Unit Status)
3-2.4 (17) At a minimum the waiting and pending events displays shall show the event type,
address, location, priority, patrol/fire district, time in status, and event number.
3-2.4 (18) It is preferred that the system allow for the display of the fields in any event or unit
status monitor to be reorganized and sorted by one or more criteria by the user.
3-2.4 (19) Once an event has been dispatched or referred, it shall be removed from the waiting or
pending events display.
3-2.4 (20) The Unit Status display shall minimally display the unit number, status, time in status,
current location, event address and assignment type.
3-2.4 (21) It is preferred that the system allow for the display of the fields in the Unit Status display
to be:
3-2.4 (21.1) reorganized,
3-2.4 (21.2) sorted by one or more criteria,
3-2.4 (21.3) grouped according to units assigned to the same event, and
3-2.4 (21.4) other relevant criteria by the user.
3-2.4 (22) The proposed application shall always display the last recorded location of each unit
with previous locations or changes in location retained in the audit trail with an attached
date/time/user stamp.
3-2.4 (23) Dispatchers shall be alerted to all event updates made by another user utilizing a visual
alert and an audible alert. The system administrator or authorized user shall have the
ability to easily change the sound of the alert, as well as disable the alert as needed.
City of Fort Collins Page 55 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.4 (24) The proposed application shall show the user all updates to an event in real-time if the
user has the incident displayed.
3-2.4 (24.1) It is preferred that the system visually differentiate these updates to make them easier
to see when the incident is displayed.
3-2.4 (25) At a minimum the proposed application shall have the ability to record the
date/time/user for each of the following statuses:
3-2.4 (25.1) Call Received
3-2.4 (25.2) Call reviewed
3-2.4 (25.3) Call assigned to unit’s stack
3-2.4 (25.4) Dispatched
3-2.4 (25.5) En route
3-2.4 (25.6) On-Scene
3-2.4 (25.7) Pre-empt
3-2.4 (25.8) Any status change /additional units
3-2.4 (25.9) Location change
3-2.4 (25.10) EMS/Fire call generated and cross referenced
3-2.4 (25.11) Wrecker called
3-2.4 (25.12) Cleared
3-2.4 (25.13) Event closed
3-2.4 (25.14) Reopen
3-2.4 (25.15) Case (report) number added
3-2.4 (25.16) Call updated
3-2.4 (26) The proposed application shall always date/time/user stamp any updates or changes.
3-2.4 (27) The proposed application shall allow operators to easily identify MDT/MDC equipped
vehicles by use of symbols attached to unit ID’s.
3-2.5 LOG ON/OFF COMMANDS 0 0 0 0
3-2.5 (1) The proposed application shall allow users to be signed onto multiple workstations
and/or mobile units at one time without first having to log-off of their current workstation
or mobile.
3-2.5 (2) The proposed application shall not allow a CAD user to sign off under the following
conditions:
3-2.5 (2.1) No other workstation is signed on to cover the area which the workstation signing off is
vacating.
3-2.5 (2.2) Units under the control of the workstation signing off are not being controlled by any
other workstation.
3-2.5 (3) Whenever a log on or log off attempt is rejected by the application the application shall
display an error message explaining why the action was rejected.
3-2.5 (4) The proposed application shall provide a means for an operator to log on to an active
workstation without transferring the call load or units to another workstation. This will
facilitate the rapid transfer of responsibility from one operator to another during breaks
and shift changes.
3-2.5 (5) A command shall be provided which will enable a supervisor to log off any user from
any workstation or MDC.
3-2.5 (6) There shall be no limit to the number of workstations which can sign on to a given
geographic zone simultaneously assuming that all have proper security clearance.
City of Fort Collins Page 56 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-2.5 (7) Upon log-on, all users with an OSN shall be automatically logged onto the CCIC/NCIC
system without further action by the user.
3-2.5 (8) It is preferred that the system allow the use of abbreviated, unique unit numbers by the
dispatcher or mobile user. For example: A unit is logged on as unit number “4B150”,
but if the user types only “B150”, the system shall recognize this as “4B150” and log all
activity under the logged on unit number of “4B150” for statistical purposes. This is
provided there are no two units utilizing the whole or partial unit number of “B150”.
3-3 CALL TAKING AND INITIATION
3-3.1 EVENT INITIATION PROCESSING 0 0 0 0
3-3.1 (1) Only the event type and address shall be required to initiate a new call from the
command line or from a form.
3-3.1 (2) When a call for service is received the application shall allow the user to display a blank
form for entering new events with a single key or single keystroke combination or
mouse click.
3-3.1 (3) If the new event is occurring at the ALI reported location the call taker shall not be
required to re-enter the location data in any other field.
3-3.1 (4) If the new event is not occurring at the ALI reported location the call taker shall enter
the event address in a separate location field and the proposed application shall use
this address for address verification and dispatch routing.
3-3.1 (5) The proposed application shall allow for an interface to the Plantronics VESTA system
TDD capabilities as outlined in the American’s with Disabilities Act.
3-3.1 (6) When a TDD tone is detected by the phone system, it will communicate in some way
with the CAD system, which will in turn, pop a separate window in which the dispatcher
can communicate with the reporting party.
3-3.1 (7) All text of the TDD communication shall be automatically added to the audit trail for
later review. This function shall be transparent to the dispatcher.
3-3.1 (8) If the new call is being received on any phone line which offers ANI or ALI data the
proposed application shall allow the transfer of the ANI/ALI data from the telephone
system to the appropriate fields on the event form with a single key or single keystroke
combination or operator action. The fields transferred will include, but are not limited
to:
3-3.1 (8.1) Caller address including city/community code
3-3.1 (8.2) Location/business name if applicable
3-3.1 (8.3) Caller’s phone number
3-3.1 (8.4) Caller’s name
3-3.1 (9) Once the call taker has entered the information necessary to create a new event a
single key or single keystroke combination or operator action shall be used to submit
the new event.
3-3.1 (10) The CAD system shall automatically complete the following actions with a newly
submitted event:
3-3.1 (10.1) Address verification
3-3.1 (10.2) Hazard Records Inquiry
3-3.1 (10.3) Premise Records Inquiry
3-3.1 (10.4) Determine Police District (beat)
3-3.1 (10.5) Determine the High and Low Cross Streets for the Verified Address
City of Fort Collins Page 57 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-3.1 (10.6) Determine Map Page
3-3.1 (11) After the CAD application has completed these steps the new event shall be
simultaneously routed to the correct dispatch position(s) and re-displayed at the call
takers position for immediate update without further actions or keystrokes from by the
call-taker.
3-3.1 (12) It is preferred that the call taker have the ability to determine which form the application
will display after each call is routed.
3-3.1 (13) It is preferred that the system administrator or authorized user be able to set a default
form which will appear after a new call has been completed.
3-3.1 (14) Call Takers shall be permitted to add additional information to a Call for Service record
before and subsequent to dispatch.
3-3.1 (15) Users shall be permitted to add comments to a Call for Service record after the call is
closed without reopening the event.
3-3.1 (16) Users shall be permitted to add a case (report) number to a call for service record after
the call is closed without reopening the event.
3-3.1 (17) Users shall be permitted to change information in any of the incident fields in a call for
service record after the call is closed without reopening the event.
3-3.1 (18) The proposed application shall allow new events to be scheduled for service at a future
time and date.
3-3.1 (19) It is preferred that the proposed application provide a means of scheduling reoccurring
events such as transporting a patient to a facility for regular treatments at a certain
date/time each day/week or month.
3-3.1 (20) The proposed application shall process the address verification, premise records and
other event routines for a scheduled event in the same manner as a unscheduled
event. However, the event shall not appear on the dispatcher’s pending event monitor
until a user-defined time period before the event is scheduled for dispatch.
3-3.1 (21) It is preferred that the application support the ability to immediately transfer call data to
Dispatch for a Hot-Call/Emergency, without waiting for completion of the Call Taker
screen.
3-3.1 (22) The proposed application shall utilize a separate “vehicle/subject” mask/form/tab to
assist the dispatcher in specifically identifying vehicles and subjects. All information
entered will be attached to the audit trail automatically with a date/time/user stamp.
The fields for this form are defined as follows:
3-3.1 (22.1) All vehicle descriptor fields defined as “CYMBALS”:
3-3.1 (22.2) Color
3-3.1 (22.3) Year
3-3.1 (22.4) Make
3-3.1 (22.5) Body style
3-3.1 (22.6) Additional Information
3-3.1 (22.7) License
3-3.1 (22.8) State
3-3.1 (23) All person descriptor fields shall be as follows:
3-3.1 (23.1) Race
3-3.1 (23.2) Sex
3-3.1 (23.3) Age
City of Fort Collins Page 58 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-3.1 (23.4) Height
3-3.1 (23.5) Weight
3-3.1 (23.6) Hair
3-3.1 (23.7) Eyes
3-3.1 (23.8) Clothing/Additional descriptions.
3-3.1 (24) The proposed application shall automatically query the plate, VIN, or person (if DOB
included) through the following databases:
3-3.1 (24.1) RMS/JMS
3-3.1 (24.2) CCIC
3-3.1 (24.3) NCIC
3-3.1 (24.4) DMV (as applicable)
3-3.1 (24.5) DOR (as applicable)
3-3.1 (25) The proposed application shall provide a means of creating a copy of active event.
When this function is selected, the system shall create a new event, at the same
location, with the same complainant, and a new incident number, and route the event
according to call-type and/or jurisdiction (Clone Incident).
3-3.1 (26) The proposed application shall provide a means of initiating an event and closing it
immediately without routing it to a dispatcher. This function could be used for example
to create an event and issue a case (report) number for an event which occurred earlier
(Advised Events).
3-3.1 (27) The proposed CAD application shall include the ability to automatically assign a unique
control number to each cataloged alarm.
3-3.1 (27.1) When this control number is entered during a search the system shall retrieve the
previously entered address for the call, the nature code, and any comments associated
with the call.
3-3.1 (28) It would be preferred that the proposed application also allow for an authorized user to
override the automatically assigned control number and enter a control number (from
another source) manually so long as the manually entered control number is unique to
the system.
3-3.2 ADDRESS VALIDATION 0 0 0 0
3-3.2 (1) When an event is initiated the proposed application shall verify the address against the
Geo-file to determine its exact location, responsible agency and other data required for
completing the event initiation and recommending resources.
3-3.2 (2) The proposed application shall be able to verify the address as soon as it is entered
into the address field with one keystroke combination. It will be up to the dispatcher to
verify at this point, or wait until all the information is entered into the call before
verification/entry.
3-3.2 (3) When an address or location is entered which matches a unique location record in the
geo-file, the system shall immediately accept this address as the correct address and
not require the user to confirm the address.
3-3.2 (4) If a user enters an address which does not match a unique geo-file location record the
system shall present the 10 closest possible matches to the location entered and allow
the user to select the correct location for the call.
3-3.2 (5) The proposed application shall be able to re-verify any address that has previously
gone through address verification at the operators discretion.
City of Fort Collins Page 59 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-3.3 STREET ADDRESSES 0 0 0 0
3-3.3 (1) The proposed application shall accept locations entered as street addresses (e.g. 123
Main St.).
3-3.3 (2) If the street name does not match a geo-file location record the proposed application
shall utilize a “soundex” or other phonetic algorithm to develop and present a list of
streets which most closely match the one entered by the user.
3-3.3 (3) If a correct street name but incorrect address number is entered the proposed
application shall present a list of all valid address ranges for the given street.
3-3.3 (4) If a user enters a street address without a suffix (St., Blvd., Rd) and the geo-file
contains more than one record for that street with different suffixes the proposed
application shall display all variations of the location name and prompt the user to
select the correct entry.
3-3.3 (5) If a user enters a street address without a directional (N, S, E, W, etc.) and the geo-file
contains more than one record for that street with different directional prefixes the
proposed application shall display all variations of the location name and prompt the
user to select the correct entry.
3-3.3 (6) The proposed application shall accept as little as two characters for a street or
commonplace name during the address verification routine (Partial Address).
3-3.3 (7) It is preferred that the proposed application have the ability to accept hundred block
locations. For example, a caller may report juveniles speeding in the 2400 block of S
College Ave.
3-3.3 (7.1) The proposed application shall allow call takers to distinguish between calls occurring
at the first even address in a block (e.g. 2400) and those which are being reported for
hundred block locations.
3-3.3 (8) The proposed application shall utilize municipality during the address verification
process. If the Geo-file contains the same street and address for multiple
municipalities the user shall be prompted to choose the correct address based on the
municipality.
3-3.3 (9) If a location match is not found on the Geo-file, the Call Taker will be permitted to by-
pass verification and force the location into the proposed application by defining the
fire/medical and or police area to which it belongs.
3-3.3 (10) The proposed application shall log each occurrence of an address “override” and
provide a means of reporting such occurrences to the system administrator or
authorized user.
3-3.4 INTERSECTIONS 0 0 0 0
3-3.4 (1) The proposed application shall accept locations entered as intersections with the street
names in either order and the street names separated by a slash (e.g. Main/Oak).
3-3.4 (2) If either street name is invalid the proposed application shall utilize a “soundex”
algorithm to develop and present a list of intersections which include the valid street
name and which most closely match the invalid street name.
3-3.4 (3) If both street names are invalid the proposed application shall utilize a “soundex”
algorithm to develop and present a list of intersections which most closely match the
two partial or invalid street names.
3-3.4 (4) The user shall have the option of entering a space for either of the streets at the
intersection in order to display a list of all streets intersecting with the valid street given
by the user.
City of Fort Collins Page 60 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-3.5 COMMONPLACE NAMES 0 0 0 0
3-3.5 (1) The proposed application shall accept locations entered as commonplaces (e.g.
McDonald’s, City Hall, Police Headquarters, etc.)
3-3.5 (2) The proposed application shall allow common places to be grouped into no fewer than
15 user-defined categories i.e. schools, businesses, banks, bars etc.
3-3.5 (3) The proposed application shall allow for no fewer than three commonplace aliases.
3-3.5 (4) The proposed application shall allow at least 60 characters when configuring
commonplace names.
3-3.5 (5) When a commonplace is entered the proposed application shall respond by entering
the official (or pre-programmed) address into the address field with the commonplace
name in the location field.
3-3.5 (6) When a non-unique (e.g. McDonald’s) commonplace name is entered the proposed
application shall display all potential matches along with their addresses.
3-3.6 STREET ALIASES 0 0 0 0
3-3.6 (1) The proposed application shall allow at least three aliases for each official street name
and intersection. (e.g. Main Street = State Route 119, or I-70= Interstate Route 70).
3-3.6 (2) The proposed application shall allow aliasing down to the 100 block. For example, the
100 block of N Lemay Ave is also known as Ninth St, but only in that block.
3-3.6 (3) When a street alias is used to enter an event the proposed application shall record the
official address in the event location field and the alias in the location field.
3-3.6 (4) It is preferred that the proposed application allow the user to manually search the area
of a given address for business names and commonplace records.
3-3.7 EVENT UPDATES 0 0 0 0
3-3.7 (1) The proposed application shall allow any authorized user to add new or additional
information to an event from a form and from the command line whether the incident is
active, pending, closed or cancelled.
3-3.7 (2) Whenever an event is updated all users, including mobile computers, concerned with
the event shall be notified by a visual and audible alert.
3-3.7 (2.1) Visual alerts generated by an event update shall not cover other windows so as to
impede the efficient processing of calls for service or other work.
3-3.7 (3) The proposed application shall allow a user to update any field except, system
generated times and dates, operator ID, and CAD position from a form and from the
command line.
3-3.7 (4) The proposed application shall not employ record locking whereby users are prohibited
from modifying an event record while another user has the event record open.
3-4 EVENT PROCESSING
3-4.1 GENERAL REQUIREMENTS 0 0 0 0
3-4.1 (1) The proposed application shall have a means of automatically identifying potential
duplicate calls for service.
3-4.1 (2) The proposed application shall identify potential duplicates by searching within a user-
defined distance around the new call for service.
3-4.1 (3) The proposed application shall include recently closed events in the potential duplicate
identification process.
3-4.1 (3.1) The definition of “recently closed” shall be determined through a configuration
parameter defined by the system administrator or authorized user.
City of Fort Collins Page 61 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-4.1 (4) The proposed application shall notify the call taker of possible duplicate events prior to
the new event being routed to the dispatcher.
3-4.1 (5) Events which have been flagged as potential duplicate calls:
3-4.1 (5.1) The exact address of the event,
3-4.1 (5.2) The type of event,
3-4.1 (5.3) The status of the event,
3-4.1 (5.4) The time the event was initiated,
3-4.1 (5.5) and The unit assigned, if any.
3-4.1 (6) If a new call for service is determined to be a duplicate call the proposed application
shall allow the call taker to:
3-4.1 (6.1) Add a second complainant with complete complainant contact information, and
comments about the event to the original event record,
3-4.1 (6.2) Close the event with no further action,
3-4.1 (6.3) or Create an entirely new event, using existing address data
3-4.1 (7) If the original event is updated the proposed application shall then notify the dispatcher
that additional information has been received by marking the original event as updated.
3-4.1 (8) The proposed application shall log all transactions with a date/time/user stamp into an
audit trail. The audit trail shall be easily accessible by all users.
3-4.1 (9) The audit trail shall be viewable in chronological order and laid out in a format that is
easy to read using different fonts, font sizes, colors, and/or styles to differentiate data
fields.
3-4.1 (10) The proposed application shall provide an easy method to route any searchable
information from any database attached to the CAD system, to a default printer(s).
3-4.1 (10.1) The printed format shall be easy to read using different fonts, font sizes, colors and
styles to differentiate data fields.
3-4.1 (11) The proposed application shall provide a means of recalling a unit’s last call (that has
already been closed) utilizing a single command with the unit number. I.E. “R 4B150”.
3-4.2 EVENT PRIORITIES 0 0 0 0
3-4.2 (1) The proposed application shall automatically enter a user-defined priority for each new
event.
3-4.2 (2) The application shall allow the call taker or dispatcher to upgrade or downgrade the
system assigned priority from a form and from the command line.
3-4.3 EVENT ROUTING 0 0 0 0
3-4.3 (1) Once an event is initiated, the proposed application shall automatically route the event
to correct dispatcher based on the agency, location and event type.
3-4.3 (2) It is preferred that the system have the ability to route calls to Police Service
Technicians for a telephone report based on the time of day and the event type.
3-4.3 (3) When a new call is routed to a dispatcher and no other activity is displayed in the
window used for event control, the new call shall be displayed immediately.
3-4.3 (4) If the window used for event control is busy the proposed application shall present a
visual and audible alert to notify the dispatcher of the new call.
3-4.4 RESOURCE RECOMMENDATIONS 0 0 0 0
3-4.4 (1) The proposed application shall recommend units each time a waiting, pending or active
event record is reviewed by a dispatcher.
City of Fort Collins Page 62 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-4.4 (2) It is preferred that the application recommend units based on a table which allows for
the recommendation of at least ten units of the required type for each call type. For
example, a cold Burglary call would result in the recommendation of one patrol unit. A
burglary in progress would result in the recommendation of two patrol units and a K9.
3-4.4 (3) It is preferred that the proposed application offer a means of recommending units
based on capabilities required to handle a particular call type. For example, a traffic
accident with injuries would result in the recommendation of a traffic unit rather than a
patrol unit.
3-4.4 (3.1) If this capability is included the proposed application shall allow the system
administrator or authorized user to designate capabilities for each unit and the
capabilities required for each event type.
3-4.4 (3.2) If this capability is included, the proposed system shall allow the system administrator
or authorized user to have the ability to activate and deactivate the capabilities-based
recommendation feature as needed.
3-4.4 (4) Regardless of the recommendation algorithm being used, the proposed application
shall search for the nearest responsible unit of the type or with the capabilities required
to handle the new event.
3-4.4 (5) As an option, the proposed application shall have the ability to utilize AVL reported
location to recommend the nearest available resource with the proper capabilities.
3-4.4 (6) It is preferred that the proposed application have the ability to recommend different
resources based on a street direction. For example, northbound I-70 will receive a
different recommendation than southbound I-70 in the same location.
3-4.4 (7) It is preferred that the proposed application have the ability to recommend different
resources for events occurring on the street as opposed to at an address on that same
street. For example, some streets in the city are the responsibility of the State, while
houses located on those streets are the city’s jurisdiction (vendor must attach an
explanation as to how they would accomplish this).
3-4.4 (8) The proposed application shall provide a means of recommending special resources.
Special resources shall include either special employee skills (languages, etc.), or
resources which are not normally controlled by CAD (mobile command post, etc.)
3-4.4 (9) The proposed application shall allow the dispatcher to select and assign recommended
units using the following methods:
3-4.4 (9.1) command line entry,
3-4.4 (9.2) function key,
3-4.4 (9.3) check box,
3-4.4 (9.4) pointing device,
3-4.4 (9.5) or from a form.
3-4.4 (10) The proposed application shall assume that the first unit assigned to a call is the
primary unit.
3-4.4 (11) The proposed application shall allow any user to change the primary unit designation
for a given event at any time.
3-4.5 HAZARD AND PREMISE FILES 0 0 0 0
3-4.5 (1) The proposed CAD application shall allow all users to create hazard records for any
physical location.
City of Fort Collins Page 63 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-4.5 (2) The CAD system shall allow hazard records to be associated with a specific address
(including apartment number or trailer lot number), block range, radius or
commonplace.
3-4.5 (3) The proposed application shall allow the user to categorize each hazard record prior to
accepting the record. For example, hazard records could be categorized as gun
permits, dangerous persons, etc.
3-4.5 (4) The proposed application shall add a date/time/user stamp to the audit trail once the
dispatcher has accessed the hazard/premise details.
3-4.5 (5) The proposed application shall allow at least 1000 characters worth of data to be
entered in the text field of the hazard/premise form.
3-4.5 (6) The proposed application shall allow the system administrator or authorized user to
create and name hazard record categories as needed. Examples include:
3-4.5 (6.1) Firearms Stored on Site,
3-4.5 (6.2) Premise Owner and Contact Information,
3-4.5 (6.3) Access to floor plans,
3-4.5 (6.4) Special Permits (Gun, hazmat, Alarm, etc.),
3-4.5 (6.5) Dangerous Situations (Combative Persons, Guard Dogs, Explosives, etc.)
3-4.5 (6.6) Persons with medical conditions
3-4.5 (6.7) Knox box, alarm panel, and standpipe locations
3-4.5 (7) The CAD application shall sort hazard records according to their categorization when
they are displayed as a result of an address verification.
3-4.5 (8) The proposed application shall push all hazard/premise information out to all MDC’s so
responding units can read the details of the entry before arrival.
3-4.5 (9) The proposed application shall display both visual and audible alerts at both the
dispatch terminal and MDC’s notifying user of premise/hazard at that location.
3-4.5 (10) Hazard/Premise details shall not be displayed until user elects to see it.
3-4.5 (11) Details shall be retrievable utilizing only one keystroke combination.
3-4.5 (12) Hazard and premise hits shall be displayed separately
3-4.5 (13) All users shall have the ability to disable the audible alert.
3-4.5 (14) The CAD application shall include an expiration date field for each hazard record.
3-4.5 (15) It shall be possible to enter a hazard record which does not expire.
3-4.5 (16) The proposed CAD application shall automatically create premise records each time a
call for service is received from a physical location.
3-4.5 (17) At a minimum a premise record shall contain the incident number, date, time, the
nature and disposition of each call and the unit(s) that handled the call.
3-4.5 (18) The CAD application shall allow the operator to easily select and view the original call
record from the premise record summary.
3-4.5 (19) The proposed CAD application shall visually alert the user to the existence of hazard or
premise records for a given address immediately upon address verification.
3-4.5 (20) The proposed CAD application shall allow a user to search for hazard or premise
records for a given address.
3-4.5 (21) The premise file shall retain not less than the 20 previous events for a given address.
3-4.5 (22) Beyond the twenty required records no premise history records shall display to the
operator when processing a call for service.
City of Fort Collins Page 64 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-4.5 (23) The system administrator or authorized user shall be able to define which agency
premise information is viewable by which users. I.E. Fire department users are only
able to view fire department premise information etc.
3-4.5 (24) At a minimum the proposed application shall display a summary of premise records
found and then allow the user to drill-down into the detail of the record as needed.
3-4.5 (25) The proposed application shall also conduct a check for hazard records in a user
defined area around the new event and for exact addresses.
3-4.5 (25.1) If this function is provided the range of the area to be checked for premise records shall
be user definable for each category of hazard records (e.g. gun permit, dangerous
person, etc.).
3-4.5 (26) The proposed application shall not search for hazard and premise records each time
the location of a unit assigned to a call is changed.
3-4.5 (27) The proposed application shall offer a simple method for the system administrator or
authorized user to modify or delete hazard and premise records.
3-4.5 (28) In the event that hazard records are located during a search the proposed application
shall:
3-4.5 (28.1) Indicate in a non-intrusive fashion the type(s) of record(s) (Gun, Dangerous Person,
etc.) that were found,
3-4.5 (28.2) and Differentiate between records which relate to the exact address of the new event
and those which fall within the user-defined search area.
3-4.6 EVENT AND CASE (REPORT) NUMBERING 0 0 0 0
3-4.6 (1) Whenever a call for service or officer-initiated event is entered into the CAD system a
new incident number shall be assigned.
3-4.6 (2) The proposed application shall allow the manual addition of case (report) numbers as
needed. Case (report) numbers shall only be issued when an incident number is
present.
3-4.6 (2.1) Case (report) numbers shall be linked to incident numbers at all times.
3-4.6 (3) The proposed application shall allow the addition of case (report) numbers to incidents
whether that incident is pending, active or closed without having to re-open that
incident.
3-4.6 (4) If the proposed application allows the issuance of multiple case (report) numbers per
incident, it must also allow the agency to lock this feature out so multiple case (report)
numbers are not allowed.
3-4.6 (5) The proposed application shall allow the user to configure the system to assign case
(report) numbers automatically on a per-agency/jurisdiction basis.
3-4.6 (6) CAD Incident numbers shall conform to the following format (AA)(YY)(NNNNNN),
where (AA) is a two letter code for the agency of jurisdiction, where (YY) is the last two
digits of the current year, and (NNNNNN) is a six digit sequential number unique to
each agency that starts over each year.
3-4.6 (7) Case (report) numbers shall conform to the following format (YY)(AA)(NNNNNN) where
(YY) is the last two digits of the current year, (AA) is a two letter code for the reporting
agency, and (NNNNNN) is a six digit sequential number unique to each agency that
starts over each year.
3-4.6 (8) The proposed application shall allow the use of abbreviated incident numbers (no more
than 5 total characters) to lessen the number of keystrokes necessary to recall, modify,
cancel or close an incident.
City of Fort Collins Page 65 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5 DISPATCH FUNCTIONS
3-5.1 GENERAL REQUIREMENTS 0 0 0 0
3-5.1 (1) Dispatchers shall have access to all call taker functions plus the following specific
features and functions.
3-5.1 (2) At a minimum the proposed application shall allow dispatchers to choose which patrol
or fire districts they are controlling when they sign on.
3-5.1 (3) The proposed system shall also allow the use of a default set of patrol or fire districts to
simplify log-on’s at specific consoles. The default shall be determined and easily
changed by the system administrator or authorized user.
3-5.1 (4) It is preferred that the system allow dispatchers to specify whether they are controlling
a district for which they are signed on, or merely monitoring the district.
3-5.1 (5) The proposed application shall have the ability to transfer alternate Districts and
Beats/Response areas from the test system to the live system.
3-5.1 (6) It is preferred that the system allow the user to specify which other units they wish to
control or monitor when they sign on.
3-5.1 (7) The proposed application shall allow the user agency to facilitate changes in resource
deployment and CAD control through the creation, retrieval and manipulation of
resource deployment plans.
3-5.1 (8) The proposed application shall include a command for retrieving and loading a new
deployment plan.
3-5.1 (9) The loading of a new deployment plan shall not require the proposed application to be
stopped or made quiet.
3-5.1 (10) The proposed application shall include status timers for each event and unit status.
3-5.1 (11) The proposed application shall offer user-defined status timers for events and unit
statuses based upon incident type.
3-5.1 (12) When a status timer expires the operator shall be notified by means of a distinctive
change in the status display
3-5.1 (13) When a status timer expires users shall have two options for resetting the timer.
3-5.1 (13.1) The dispatcher may reset the status timer to the default value.
3-5.1 (13.2) The dispatcher may reset the timer with a new time value. The manual timer value field
shall support at least three digits.
3-5.1 (14) The proposed application shall provide a means for one workstation to transfer its
entire workload to another signed on workstation.
3-5.1 (15) The proposed application shall provide an easy means for the transferring workstation
to recover its workload at a later time without signing off.
3-5.1 (16) Upon dispatch, the application shall automatically assign the recommended or
requested units, remove the event from the pending queue, update the status display,
send the event to the assigned units’ MDC’s, start the status timers, and update the
audit trail.
3-5.1 (17) After initial dispatch, the system shall allow the addition of units to an incident from the
command line, from a pointing device (drag n drop dispatching) and from a form.
3-5.1 (18) It is preferred that the proposed application have the capability to place all units in a
previously defined roster on or off duty with a single command.
3-5.1 (18.1) It is preferred that the proposed application allow for single unit exceptions when
placing a roster on or off duty.
City of Fort Collins Page 66 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.1 (19) Units in a roster that is placed “on-duty” shall not be available or recommended for calls
until they notify the dispatcher that they are in service.
3-5.1 (20) The proposed system shall maintain a log for tracking impounded and towed vehicles.
This functionality may exist as a part of the CAD application or as a module of the
RMS/JMS, so long as it is accessible to all CAD/RMS/JMS users.
3-5.1 (20.1) The tow/impound record shall include the CCIC RTY field, vehicle license plate number,
state of registration, year of expiration, vehicle make and body style, color, year, VIN
Number, location which the vehicle was towed from, time and date, tow company name
and phone number.
3-5.1 (20.2) The tow/impound entry form shall conform to CCIC/NCIC standards and upon entry,
the system shall automatically run the vehicle for wants/warrants.
3-5.1 (20.3) Upon entry of a towed/impounded vehicle into the CAD system, the application shall
give the user the option of automatically entering the vehicle as
towed/impounded/stolen etc into CCIC/NCIC. All CIC and NIC numbers shall be
automatically added to the audit trail.
3-5.1 (20.4) The proposed application shall allow for searches from all fields in the tow/impound
entry.
3-5.1 (20.5) All modifications or cancels of a tow/impound entry shall automatically update or cancel
the CCIC/NCIC entry if applicable.
3-5.1 (20.6) The proposed application shall check the towed and repossessed vehicles file for
potential matches when a stolen auto event is entered.
3-5.1 (20.7) The proposed application shall offer a means of adding comments to an existing event
record from the command line without retrieving the event.
3-5.1 (20.8) The proposed application shall offer a means of adding comments to a unit’s history
from the command line.
3-5.1 (20.9) The proposed application shall allow the user to enter comments continuously to any
event or unit record, date/time/unit stamping each comment as it is entered and not
exiting the function until another command is invoked.
3-5.1 (20.10) The application shall allow at least 1000 characters be entered per comment.
3-5.1 (21) It is preferred that the proposed application offer a car chase function whereby:
3-5.1 (21.1) the user can quickly enter the unit number and location and the system will put that unit
in pursuit status,
3-5.1 (21.2) Following the use of this command the user will be able to add comments continuously
to the record without entering another command or retrieving the event,
3-5.1 (21.3) and A means of date/time/unit stamping each comment shall be provided and shall be
recorded into the incident audit trail.
3-5.2 EVENT CONTROL FUNCTIONS 0 0 0 0
3-5.2 (1) When a dispatcher reviews a pending event and returns it to the pending queue without
action the call status shall change. For example, once a new call is reviewed it will
change from “waiting/new” to “pending”.
3-5.2 (2) The proposed application shall provide a single key or single keystroke combination
command for retrieving the highest priority, oldest event from the pending events queue
for review and dispatch.
3-5.2 (3) The proposed application shall also provide a command or function key for reviewing
each pending event sequentially.
City of Fort Collins Page 67 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.2 (4) The proposed application shall allow the dispatcher to interrupt one transaction to
handle another of higher priority without losing information entered on the first.
3-5.2 (5) When the proposed application recommends units for dispatch the dispatcher shall
have the following options for completing the dispatch:
3-5.2 (5.1) press a single key to accept the proposed application recommended units,
3-5.2 (5.2) select individual units from the recommended units for dispatch, then dispatch,
3-5.2 (5.3) or select units not recommended by the proposed application for dispatch, then
dispatch.
3-5.2 (6) Dispatchers and mobile units shall be able to create self-initiated events. When
invoked the dispatcher shall provide the unit number, location and event type. The
proposed application shall respond by creating a new event at that location and placing
the specified unit in an “arrived” status.
3-5.2 (7) The proposed application shall have the ability to distinguish between self-initiated
events, and calls taken via phone or walk-in so as to be able to report on self-initiated
activity (“source of origin”)
3-5.2 (8) The proposed application shall allow all call-types to be utilized as field initiated
contacts.
3-5.2 (9) If the field initiated contact contains a license plate, the application shall automatically
check the following without further input from the dispatcher or officer if initiated from an
MDC:
3-5.2 (9.1) Check license plate for wants/warrants,
3-5.2 (9.2) List DMV information on plate,
3-5.2 (9.3) Search for the registered owner of the vehicle,
3-5.2 (9.4) Check the RO for wants/warrants,
3-5.2 (9.5) List the Registered Owner’s driver’s license information,
3-5.2 (9.6) and Query RMS for any past contacts with that plate.
3-5.2 (10) The proposed application shall have the ability to bypass address verification on a per
incident basis on all field initiated contacts.
3-5.2 (11) The system administrator or authorized user shall have the ability to configure the
proposed application to require address verification on self-initiated events before that
event is closed.
3-5.2 (12) It is preferred that the proposed application shall allow dispatchers to transfer selected
events to another dispatcher when necessary.
3-5.2 (13) It is preferred that the application also allow the dispatcher to specify which event the
dispatcher will retain, and the application will transfer all other events to a designated
user.
3-5.2 (14) Dispatchers shall have the ability to send a copy of an event to a workstation other than
the proposed application determined destination. For example, if an event occurs on
the boundary between two police zones/jurisdiction the dispatcher shall be able to send
a “copy” of the event to the neighboring zone.
3-5.2 (15) The proposed application shall have a means of assigning one case (report) number to
multiple event numbers and logically linking those events together.
3-5.2 (16) The dispatcher shall be able to assign more than one event to a given unit or resource
(Call Stacking) from the command line.
3-5.2 (17) The dispatcher shall be able to “un-stack” a call stacked against an officer from the
command line.
City of Fort Collins Page 68 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.2 (18) The system administrator or authorized user shall have the ability to set queue limits for
both numbers of events allowed to be stacked in a given queue and the time an event
remains in queue for each priority level.
3-5.2 (19) If the timer for an event in queue expires the proposed application shall notify the
dispatcher.
3-5.2 (20) The proposed application shall provide a command which allows a dispatcher to cancel
an event.
3-5.2 (20.1) The command shall require the user to enter a reason for cancellation prior to
executing.
3-5.2 (20.2) Upon execution the command will automatically remove the event from the pending or
active events queue and add a cancellation disposition automatically to the event
comments.
3-5.2 (21) If an event has been dispatched all units must be cleared from the incident prior to
invoking the cancel command.
3-5.2 (22) The proposed application shall provide a command for re-opening or re-activating an
event which has previously been closed using a simple code and incident or case
(report) number from the command line.
3-5.2 (22.1) If an event is re-opened the proposed application shall record the re-opening command
in the original event audit trail and continue recording actions to the original audit trail.
3-5.2 (22.2) The proposed application shall sum all time spent on any given incident no matter how
many times it was re-opened to accurately track time spent on incidents.
3-5.2 (23) The proposed application shall allow a workstation (no MDC’s) to select an event for
continuous monitoring. Such events will appear in a separate window, in real time and
all event or unit activity, regardless of their point of entry, will be displayed in this
window as they are recorded to the CAD database.
3-5.2 (24) If the proposed application allows for officers to dispatch themselves onto incidents, the
system administrator or authorized user must be able to disable this function.
3-5.2 (25) The proposed application shall include an option to display the dispatch screen with
unit recommendations immediately after a call has been entered. This would allow for
dispatchers to take a call and move immediately to the dispatch function.
3-5.2 (26) The proposed application shall include a function which allows two or more events to
be cross-referenced. The result of a cross-reference command will be to indicate that
the event is cross-referenced to another event whenever either of the events are
displayed.
3-5.2 (27) Incidents from any jurisdiction/community shall be able to be cross-referenced to one
another.
3-5.3 UNIT CONTROL FUNCTIONS 0 0 0 0
3-5.3 (1) It is preferred that the proposed application shall provide a means for placing units
either on or off-duty either individually or as a group to facilitate shift changes.
3-5.3 (2) The proposed application shall show units placed on duty as available and they shall
be available for calls.
3-5.3 (3) The proposed application shall have no limitations on the number of units which can be
assigned to a given event, and the times for each unit will be tracked separately.
City of Fort Collins Page 69 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.3 (4) It is preferred that the proposed application provide support for the assignment of a call
for service to one or more units, or the assignment of one or more units to an event by
“dragging and dropping” one on top of the other.
3-5.3 (5) If the system provides for drag and drop dispatching, the system shall highlight the
incident in question when the cursor/unit is hovering above it. This is to ensure the
correct unit is dispatched onto the correct call while the screen is dynamically
refreshing.
3-5.3 (6) The proposed application shall have the ability to associate personnel with a patrol or
other mobile unit.
3-5.3 (7) The proposed application shall provide a method for adding an officer to or removing
an officer from a unit at any time.
3-5.3 (8) The proposed application shall have the ability to track the activity of each officer
associated with a mobile unit.
3-5.3 (9) The proposed application shall allow the dispatcher to assign primary zone
responsibility for patrol/fire units.
3-5.3 (10) The proposed application shall allow the dispatcher or unit to change primary zone of
responsibility easily from the command line.
3-5.3 (11) The proposed application shall support the capability to dispatch resources other then
patrol units, e.g. crime scene technicians, investigators, etc without first having to log
the unit on-duty. “Temporary units”.
3-5.3 (12) The recorded event address shall not be affected by a change in the unit location.
3-5.3 (13) The proposed application shall display both incident address and officer location on the
status monitor.
3-5.3 (14) The proposed application shall permit the user to quickly determine the last known
location for a given unit.
3-5.3 (15) The proposed application shall provide a command which will allow the dispatcher to
preempt one assignment with another assignment.
3-5.3 (15.1) The proposed application shall also provide for automatic pre-empting of units from an
incident if a new assignment, including field initiated contacts, are assigned without
using the above defined command.
3-5.3 (15.2) The original call that the unit was assigned shall automatically be “stacked” for that unit
and shall be automatically re-assigned to the same unit once the officer clears the other
call for service.
3-5.3 (16) The proposed application shall have a command which will allow a single unit to be
cleared from an event without a disposition code if other units are still working an
incident. At a minimum, this shall be done from the command line.
3-5.3 (17) The proposed system shall allow for a disposition code to be entered for each officer on
a call.
3-5.3 (18) The proposed system shall only require one disposition code for an incident to be
placed into “closed” status.
3-5.3 (19) If a unit is the only unit currently assigned to the an event the proposed application
shall require a disposition before clearing the unit or closing the event. Once the
disposition has been entered the proposed application shall close the event.
3-5.3 (20) If the user clears less than all the units the application shall not require a disposition or
close the event.
City of Fort Collins Page 70 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.3 (21) If a disposition for the event has already been entered the system shall not require it to
be entered again as assigned units clear.
3-5.3 (22) The proposed application shall support a swap feature. This feature will allow two units
to exchange currently assigned activities. For example, if one unit is assigned to 123
Main St. and another unit is assigned to 456 Oak Street and they wish to switch
assignments the proposed application will allow the assignments to be swapped with a
single command.
3-5.3 (23) The proposed application shall also support a unit exchange command which allows
the dispatcher to remove an assigned unit from a call and assign a another unassigned
unit to the first unit’s call.
3-5.3 (23.1) The proposed application shall place the first unit back in service.
3-5.3 (24) The proposed application shall allow the dispatcher to dispatch a call for service to a
unit which is not on duty. The system shall immediately log the unit on as a temporary
unit and shall be distinguished visually as not being “logged” onto their MDC.
3-5.3 (24.1) Once the unit clears the assignment the system shall place them off-duty again.
3-5.3 (24.2) The utilization of a “temporary” unit shall not require the user to first log a unit on duty.
3-5.3 (25) The proposed application shall not require an additional number keystrokes when
assigning temporary units to a call than would be required to place an on-duty unit on a
call.
3-5.3 (26) The proposed application shall allow the dispatcher to define the temporary unit
number using that person’s pre-assigned unit number.
3-5.3 (27) The proposed application shall have the ability to track off-duty detail information for
officers.
3-5.3 (28) The proposed application shall provide a function for changing the location of a unit at
any time while still assigned to an event.
3-5.3 (29) When a unit is placed in a traffic stop status, the proposed application shall allow the
user (MDC client) to record the location of the stop, the vehicle license plate number,
state of registration, and comments from the command line.
3-5.3 (30) The proposed application shall process a traffic stop by initiating, at a minimum, an
inquiry to the following resources:
3-5.3 (30.1) CCIC,
3-5.3 (30.2) CAD (prior involvement by license plate number),
3-5.3 (30.3) RMS/JMS,
3-5.3 (30.4) NCIC,
3-5.3 (30.5) DOR,
3-5.3 (30.6) and DMV.
3-5.4 SYSTEM ACTIONS 0 0 0 0
3-5.4 (1) Each time an event record is retrieved for review or dispatch, if related premise records
are found the proposed application shall display a visual warning which is noticeable
but which does not interrupt the processing of the event.
3-5.4 (2) It is preferred that the Premise records warning note the categories of the records
which have been found.
3-5.4 (3) The proposed application shall allow for “special instruction messages” to be entered
for specific addresses, address ranges, and geographical areas.
City of Fort Collins Page 71 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.4 (3.1) These messages shall be defined by authorized users and be able to contain free form
text information to aid dispatchers. Example: notification information when dispatching
into a mutual aid response area.
3-5.4 (3.2) These messages shall be displayed when a call is selected for dispatch. The
messages will be visible enough to draw the dispatcher’s attention to them without
covering other pertinent information.
3-5.4 (4) It is preferred that the proposed application shall have the ability to dynamically alter
Districts and Beats/Response areas based upon time of day or need.
3-5.4 (5) When reviewing a call record for dispatch, at a minimum the call record displayed shall
include the following information:
3-5.4 (5.1) Incident and Case (report) number,
3-5.4 (5.2) Event Type,
3-5.4 (5.3) Time of Event Initiation,
3-5.4 (5.4) Call taker receiving the call and Position ID,
3-5.4 (5.5) Event Location,
3-5.4 (5.6) Event Number,
3-5.4 (5.7) Event Priority,
3-5.4 (5.8) Complainant Name,
3-5.4 (5.9) Complainant Address,
3-5.4 (5.10) Complainant Phone Number,
3-5.4 (5.11) Method of Alarm (911, 7 Digit, walk-in, etc.),
3-5.4 (5.12) Units Assigned (if units have been assigned),
3-5.4 (5.13) Patrol/Fire District,
3-5.4 (5.14) Map Grid (x-y),
3-5.4 (5.15) Reporting Area, District or Zone,
3-5.4 (5.16) Nearest High and Low Cross Street,
3-5.4 (5.17) Indication of Premise or Hazard Records,
3-5.4 (5.18) Comments or Notes,
3-5.4 (5.19) and Notifications related to events or locations as described above.
3-5.4 (6) In the event that the CAD system is unavailable for a time, a function shall be provided
which will allow events to be added retroactively with the actual date(s) and time(s)
rather than the current date(s) and time(s).
3-5.4 (6.1) The proposed application shall process retroactive events and assign case (report)
numbers in the same manner as new events.
3-5.4 (6.2) The proposed application shall clearly note in the audit trail that an event was entered
“retroactively”.
3-5.5 TOW REQUEST ROTATION 0 0 0 0
3-5.5 (1) The proposed application shall offer a tow request rotation services module.
3-5.5 (2) The tow request rotation service module will allow a system administrator or authorized
user to enter multiple contractors with different kinds of capabilities, similar to the way
patrol units are entered into the system as described above.
3-5.5 (3) The information supplied to the dispatcher after this command has been initiated shall
include the name of the tow company, their phone number, free form text (described
below), the officer the tow was requested for, and the location of the incident for which
the tow was called.
City of Fort Collins Page 72 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.5 (4) When the module is invoked it shall present the next contractor with the required
capabilities in sequential order.
3-5.5 (5) If a contractor is contacted to respond, then it’s determined while tow is en route that
the tow is no longer needed, there shall be a simple cancel command utilized from the
command line to put that contractor back at the top of the rotation.
3-5.5 (6) If a contractor cannot be reached for a call, the proposed application shall place that
contractor at the bottom of the rotation list.
3-5.5 (7) The system shall allow tow requests to be generated for all locations including un-
verified/forced addresses.
3-5.5 (8) The tow rotation shall be accessible via the command line by entering an incident
number or unit number, a command to generate the next tow, and free form text that
identifies the vehicle being towed.
3-5.5 (8.1) The free form text field shall be at least 70 characters in length.
3-5.6 FIRE/AMBULANCE DISPATCHING 0 0 0 0
3-5.6 (1) The proposed application shall allow system administrator or authorized users to define
alarm levels.
3-5.6 (2) Alarm levels shall allow the addition of equipment and/or apparatus to any call-type.
3-5.6 (3) Alarm levels shall be able to be upgraded by the dispatcher with no more than one
command.
3-5.6 (4) The proposed application shall include an ambulance transfer feature. This feature
shall perform the following functions:
3-5.6 (4.1) Alert the dispatcher of all pre-scheduled event conflicts and recommend a solution,
3-5.6 (4.2) Take into account emergent calls for service that are being handled by the ambulance
that is supposed to be taking a scheduled transfer and recommend a solution,
3-5.6 (4.3) and Automatically select and display a pre-scheduled transfer for dispatch at the pre-
determined time.
3-5.6 (5) Authorized users shall have the ability to define variables (business rules) to adhere to
current protocols.
3-5.6 (6) The system administrator or authorized user shall have the ability to add “canned”
alpha paging messages to be automatically sent to specific groups of responders as
the new alarm levels are toned. I.E.…when a 2nd alarm is toned at the fire stations,
certain groups of off-duty firefighters are also alpha paged and notified of the situation.
3-5.6 (7) The system shall not limit the number of pagers attached to any one pager group.
3-5.6 (8) The proposed application shall allow station toning from the command line, without
generating a call for service. This is to provide a means of testing the toning system.
3-5.6 (9) The proposed application shall incorporate an alpha paging system (ability to page
utilizing the CAD software). The paging system shall be accessible from both
workstations and from MDC’s to send pages via a paging interface to both the county
paging system and commercial paging systems.
3-5.6 (10) The proposed application shall have the ability to work with a Zetron model 25 and 26
Fire Station toners via a paging interface, utilizing all available features of these
systems provide.
3-5.6 (11) The proposed application shall have the ability to work with a Zetron model 2200
paging system via a paging interface, utilizing all available features of these systems
provide.
City of Fort Collins Page 73 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.6 (12) The application shall be able to be configured by an authorized user, to automatically
send call information to responding units’ alpha pagers as the call is dispatched, with
no other action taken by the dispatcher. The alpha page shall be able to be configured
with the following information:
3-5.6 (12.1) Address,
3-5.6 (12.2) Location,
3-5.6 (12.3) High and low cross streets,
3-5.6 (12.4) Map page,
3-5.6 (12.5) and Call text information to a total of 220 characters in length.
3-5.6 (13) It is preferred that the application have the ability for authorized users to enter pre-
scripted messages to expedite paging groups such as SWAT paramedics. Pre-scripted
messages must be able to have spaces left for call specific information the dispatcher
will enter before sending.
3-5.6 (14) The paging application shall have the ability to be “minimized” in some fashion as to not
interrupt other dispatching functions as modems are being dialed and pages sent.
3-5.6 (15) The application shall provide a visual alert to the sending console to notify the user that
the page has been successfully sent or failed and needs to be resent.
3-5.6 (16) The application shall recommend units for each call type and automatically populate
those units into a form for dispatch.
3-5.6 (17) The recommended units shall be determined by run orders already in place
geographically.
3-5.6 (18) The application shall allow/facilitate the importing of run cards information from the
participating agencies currently using a CAD system to avoid rebuilding that database
from scratch.
3-5.6 (19) If AVL is utilized, the system shall recognize as units move through their jurisdiction and
adjust recommendations of units accordingly.
3-5.6 (20) The proposed application shall allow the dispatcher to dispatch a call with a single key
or single keystroke combination, provided the system is able to recommend units for
response and automatically populate a form or command line with those units.
3-5.6 (21) Upon striking the single key or single keystroke combination to dispatch units, the
application shall perform the following functions:
3-5.6 (21.1) Tone all applicable firehouses/ambulance stations,
3-5.6 (21.2) and Send the information to all applicable personnel’s alpha pagers as described
above.
3-5.6 (22) The proposed application shall allow the system administrator or authorized user to
configure the system to allow fire/ambulance calls to be closed without the use of
disposition codes.
3-5.6 (23) The proposed application shall allow additional units be added to a call that is active
and assigned from the command line, mouse, form and/or check box.
3-5.6 (23.1) The application shall give the dispatcher the choice of sending tones and/or alpha
pages when assisting other units in this manner.
3-5.6 (24) The proposed application shall allow the system administrator or authorized user to
define what units are to be recommended for each of the following:
3-5.6 (24.1) Call type,
3-5.6 (24.2) Call type AND geography,
City of Fort Collins Page 74 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.6 (24.3) Call type AND address,
3-5.6 (24.4) or Call type AND address range.
3-5.6 (25) The proposed application shall allow all logged on units to show available for calls on
the dispatch screen.
3-5.6 (26) The proposed application shall allow the movement of fire/ambulance (manually) units
into different station assignments. This function shall be available from workstations
and MDC’s.
3-5.6 (27) The proposed application shall suggest coverage of firehouses that are vacant due to
units being assigned to large-scale incidents (move-ups).
3-5.6 (27.1) The system shall alert the dispatcher to the station vacancies
3-5.6 (27.2) The system shall offer coverage solutions due to station vacancies.
3-5.6 (27.3) The system shall automatically populate a form with units to be toned if the dispatcher
accepts the recommendations.
3-5.6 (27.4) All variables shall be user-definable to assure adherence to current protocol.
3-5.7 AUTOMATED ON-LINE SSM CONTROL FEATURES 0 0 0 0
Automated System Status Management (SSM) controls exist primarily to aid
Dispatchers in maintaining the best possible coverage at every point in time given the
remaining ambulance resources then available in the system, and to aid in assigning
units to calls in the most prudent manner possible. This specification category includes
features enabling input of various SSM protocols and controls by time-of-day and day-
of-week, and the on-line application of those protocols and controls.
3-5.7 (1) The proposed application shall be capable of easily creating and storing sufficient
System Status Plans (SSPs) for hour-of-day, day-of-week and for special situations
such severe weather, major sporting events, and holidays.
3-5.7 (1.1) Plans shall be easily modified, copied, or duplicated.
3-5.7 (1.2) SSP Table Example: XX designates equal / alternate posts: (See Table)
3-5.7 (2) The proposed application shall provide an easily understood and convenient format for
entering SSP information re-post priorities for each SSP, at each status level.
3-5.7 (3) The system shall be capable of handling (i.e. storing, displaying, and controlling) not
less than 10 separate post locations, with status levels up to 20 units.
3-5.7 (4) With the SSP entered, the application shall provide visual warning when the system is
not in compliance with SSP, and clear indication of what must be done to restore
compliance.
3-5.7 (5) The visual warning shall be displayed in such a manner as to not hinder any other work
being completed at the time.
3-5.7 (6) SSM features shall include the “equal/alternate post control feature, designated within
the SSP, by assigning the same post priority to two or more posts at the same status
level.
3-5.7 (7) So long as an available unit is located at any equal/alternate post, the system shall be
deemed in compliance with the SSP. If the system is non-compliant, and a unit must
be moved to a post for which there is an equal/alternate, both posts shall be displayed
as alternative options for restoring compliance.
3-5.7 (8) The proposed application shall provide the ability for assignment of multiple units to a
given post, with a method to assign a “dispatch priority” to each unit.
City of Fort Collins Page 75 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.7 (9) The proposed application shall incorporate a method for “special unit activation.” The
purpose of this feature is to provide for planned activation of a “supervisor’s unit” or
other “special unit” not otherwise available in the system.
3-5.7 (9.1) The activation notification shall appear on the dispatch screen, subject to conditions
specified in the SSP.
3-5.7 (9.2) User-specified optional conditions shall include: status level and type of call.
3-5.7 (10) The proposed application shall incorporate a table driven “non emergency cutoff”
protocol linked to each SSP. The purpose of this feature is to notify the dispatcher
when a pre-determined ambulance level is reached.
3-5.7 (10.1) The “cutoff” notification shall appear on the dispatch screen, but shall not prevent the
dispatcher from taking an action or dispatching a call.
3-5.7 (11) The proposed application shall include an “Emergency Only” Unit Restriction. This
refers to a unit which is not available for posting or for dispatch to routine calls, but is
available for dispatch to emergency calls, and can transport.
3-5.7 (12) The proposed application shall include a “Non-Transport” Status Unit Restriction:
(manual/automatic). This unit is available for dispatch to emergency calls but cannot
transport and is not dispatched to routine calls.
3-5.7 (12.1) An automatic prompt shall request the dispatch of an additional unit to the same
incident to transport.
3-5.7 (13) The proposed application shall allow for a “home post” feature. This feature allows a
unit to be given a “home post” designation at the time of unit setup. When active, the
home post protocol will call for relocation of “home post” units to their designated home
posts.
3-5.7 (14) The application shall provide an Emergency dispatch unit recommendation. This
feature shall provide for automatic recommendation of the three nearest available units
or units en route to lower-priority calls (by MPD protocol), listed nearest unit first.
3-5.7 (14.1) “Nearest” shall be determined by AVL (if available) using street attributes or last known
location.
3-5.7 (15) The proposed application shall provide an automatic recommendation for multiple
ambulance response based on MPD priority code or “code 5 status” (If single unit listed
is a “status 5” unit, display will indicate “non-transport unit”). (“Additional unit”
command creates duplicate “run card” for assignment of other units to same incident.)
3-5.7 (16) The proposed application shall provide a pre-scheduled transfer unit recommendation.
This feature shall provide for automatic recommendation of units from a table driven list
or the nearest available unit if no listed units are available.
3-5.7 (17) The proposed application shall notify the dispatcher when ambulance resources reach
certain levels and suggest a solution i.e. which agency to contact for other resources.
3-5.7 (18) The application shall notify the dispatcher when an ambulance is dispatched out of a
pre-determined geographical area and off-duty crews or other agency ambulances are
necessary for coverage.
3-5.7 (19) If the dispatcher selects the system recommendation, the system shall automatically
page the on-call ambulance crew with a “canned” alpha page.
3-5.7 (20) The proposed application shall allow the user to configure the system to recognize
which ambulance unit is first or last call in reference to time of day and/or day of the
week.
City of Fort Collins Page 76 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.7 (21) The proposed application shall automatically recognize a pre-determined geographical
area, call type, and time of day and alert the dispatcher to contact an air ambulance for
immediate response
3-5.7 (22) The proposed application shall contain a separate database where burn permits will be
entered and maintained.
3-5.7 (23) When a citizen calls to report they will be conducting a prescribed or recreational burn
the system shall do the following:
3-5.7 (23.1) Show a visual reference on the dispatcher’s screen. The visual reference shall be as
unobtrusive as possible and shall include burn permit number, address or location
where the burn is, callback number.
3-5.7 (23.2) The system shall recognize these calls and alert the dispatcher to the possibility of a
duplicate call should another call be entered at the same location or general area.
3-5.7 (24) The proposed application shall create one incident only for calls requiring both fire
apparatus and ambulance.
3-5.7 (24.1) It is preferred the proposed application shall create, however, two separate incident
numbers—one for the fire jurisdiction and one for the ambulance jurisdiction under the
one incident created.
3-5.7 (24.2) The proposed application shall also automatically assign two agency specific (one fire,
one EMS) case (report) numbers to each incident number upon dispatch.
3-5.7 (25) The proposed application shall have the ability to create “combined” calls for police and
fire/ambulance at the same time. This function shall allow resources to be sent to the
same location on the same call, but with their respective call-types.
3-5.7 (26) “Combined” calls shall be automatically “cross-referenced” with each other by incident
number upon creation.
3-5.7 (27) The proposed application shall allow the user to configure certain call-types to be
combined, and automatically give the dispatcher the option to create both, one, or
neither.
3-5.7 (27.1) The application shall allow the dispatcher to change call types for the combined calls if
necessary before the call is entered.
3-5.7 (28) The proposed application shall include a “split crew” function. This function shall be
driven by minimum numbers of personnel, defined by the user agencies, that are to
respond on primary and secondary pieces of apparatus assigned to a single fire
station. I.E. When the primary unit is dispatched on a call or moved out of its station
area, the secondary unit shall automatically become unavailable if there are not enough
personnel remaining to respond on that piece of apparatus.
3-5.7 (28.1) If the secondary piece of apparatus is dispatched to a call or moved out of it’s area, the
primary unit shall remain available for calls (assuming there are enough personnel
remaining).
3-5.7 (28.2) The dispatcher shall have the ability to override these functions as necessary.
3-5.7 (29) The proposed application shall allow the system administrator or authorized user to
create volunteer station boundaries within the paid stations boundaries.
3-5.7 (29.1) When a call is created in an area that is part of the volunteer boundary, the volunteer
units shall be added to the normal full assignment of paid equipment.
3-5.7 (29.2) The volunteer units shall be able to move into a paid station area and become part of
the normal run assignment for that station.
City of Fort Collins Page 77 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-5.7 (30) The proposed application shall allow other fire agencies units to be included in the run
cards and be automatically recommended for dispatch if a call for service is within a
given boundary (Auto-Aid areas where multiple fire agencies respond to the same
address). Clarification: The other agency fire units will not be dispatched by this
agency—this feature is to make the dispatcher aware that a call for service is occurring
in an area where they need to contact another agency for response.
3-5.7 (30.1) It is preferred that the proposed application be capable of notifying other agencies
dispatch centers automatically of a call for service via data streams, or paging systems.
3-5.7 (31) The proposed application shall allow for Bureau (investigations) units to be attached to
the ladder companies, but be maintained as a separate unit. Clarification: The Bureau
is actually a 4th firefighter assigned to a ladder company, but responds in their own
vehicle and has other duties separate of the ladder company at times.
3-5.7 (31.1) When the ladder companies are dispatched, the bureau unit shall be automatically
recommended and dispatched with the ladder unit it supports. I.E. bureau1 shall
respond with ladder1 and bureau5 shall respond with ladder5 etc.
3-5.7 (31.2) The Bureau unit shall not be recommended for dispatch with a ladder company it is not
attached to, even though the run card will show incomplete for dispatch.
3-5.7 (31.3) Bureau units shall be able to be dispatched to calls without the accompanying ladder
unit. This is to facilitate the use of the Bureau units for code violations etc.
3-5.7 (32) The proposed application shall allow the use of ladder-tenders. Ladder-tenders shall
be attached to a primary ladder unit just as the Bureau unit is attached to the ladder
unit.
3-5.7 (32.1) Ladder-tenders shall be dispatched in conjunction with the ladder unit in which it is
attached.
3-5.7 (32.2) Ladder-tenders shall be able to be dispatched to calls without the accompanying ladder
unit. This is to facilitate the use of the ladder-tenders for use in wild-land fire situations
in rural areas.
3-5.7 (33) The proposed application shall recognize dry areas in the system (areas without fire
hydrants).
3-5.7 (33.1) The proposed system shall automatically add tenders to the structure fire run cards in
these areas.
3-5.7 (34) The proposed application shall allow an “insert” function in the run card system.
3-5.7 (34.1) The insert function shall allow for future additions of equipment or fire stations without
the need to retype the whole run card.
3-6 MOBILE DATA COMPUTER 0 0 0 0
3-6.1 (1) It is preferred that the CAD mobile application be fully developed and supported by the
same vendor for the CAD system rather than a third party vendor.
3-6.1 (2) All described functions for the mobile system shall be completed by each of the
following:
3-6.1 (2.1) Command line,
3-6.1 (2.2) Masks/forms,
3-6.1 (2.3) and Hot keys.
3-6.1 (2.4) All commands not possible by the aforementioned functions shall be defined by the
vendor.
3-6.1 (3) The look and feel of the CAD client shall be fully configurable by agency specific to the
functions of that agency (Police, Fire and EMS applications).
City of Fort Collins Page 78 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-6.1 (4) The proposed system shall allow the system administrator or authorized user to map
the MDC keyboard as necessary.
3-6.1 (5) The proposed mobile data application shall receive and process logon requests from
MDC equipped units. When a logon request is received the CAD shall:
3-6.1 (5.1) log the unit on with full CAD functionality including all other database functions, but not
place them in an available-for-duty status until the MDC user issues another command,
3-6.1 (5.2) and Record the officer(s) assigned to the unit.
3-6.1 (6) The proposed mobile data interface shall receive and process logoff requests from
MDC equipped units.
3-6.1 (6.1) Units shall also have the ability to remove themselves from on-duty status, to off-duty
status without fully logging off of the system.
3-6.1 (6.2) After being placed into the off-duty status, but remaining logged on, the user shall have
full access to the CAD system and all other databases associated.
3-6.1 (6.3) After being placed into the off-duty status, but remaining logged on, the unit shall no
longer show up on the dispatcher’s screen.
3-6.1 (7) The proposed mobile data interface shall receive and process all CAD commands from
an MDC.
3-6.1 (7.1) All commands available on the CAD system shall be available to mobile users.
3-6.1 (7.1.1) CAD commands not available on the MDC, but available on the CAD system shall be
detailed by the vendor.
3-6.1 (8) The proposed mobile data interface shall automatically send a copy of each call for
service to the assigned units. This message shall include the following information:
3-6.1 (8.1) the event nature code,
3-6.1 (8.2) the event priority,
3-6.1 (8.3) event number,
3-6.1 (8.4) the case (report) number (when assigned),
3-6.1 (8.5) the location of the incident,
3-6.1 (8.6) the name, address and phone number of the complainant,
3-6.1 (8.7) premise and hazard alerts for the assigned location,
3-6.1 (8.8) the time the call was received,
3-6.1 (8.9) the time the call was dispatched,
3-6.1 (8.10) the units assigned to the call,
3-6.1 (8.11) and the comments field.
3-6.1 (9) When a call or message is sent to a MDC equipped unit the system shall provide a
positive acknowledgement to the sender that the call or message was received by the
MDC.
3-6.1 (10) On demand, messages to or from a MDC equipped unit shall be logged to the incident
or unit audit trail.
3-6.1 (11) If the proposed application has a feature that automatically logs every message to or
from an MDC equipped unit into an incident or unit audit trail, that feature shall be
easily disabled by the system administrator or authorized user.
3-6.1 (12) The proposed application shall allow MDC users to import response information from
other applications such as CCIC/NCIC or limited RMS information (as defined by the
system administrator) into the body of a call.
City of Fort Collins Page 79 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-6.1 (13) The proposed application shall provide a visual and audible alert to MDC users when
any information pertaining to an incident that user is assigned to, has been updated in
any way.
3-6.1 (13.1) The system shall not display the updated information until requested by a single key or
single keystroke combination by the MDC user.
3-6.1 (13.2) When the user recalls the incident to review the new information, the entire incident
shall be displayed.
3-6.1 (14) The user shall be able to easily scroll or page forwards and backwards through an
incident without use of a pointing device.
3-6.1 (15) The proposed mobile data interface shall allow MDC equipped units to initiate traffic
stops from their MDC’s without dispatcher intervention.
3-6.1 (15.1) When MDC equipped units initiate a traffic stop the CAD shall process the message as
if it had been entered by a dispatcher.
3-6.1 (15.2) In the event that a MDC initiated inquiry receives a hit from CCIC/NCIC or another
source, the vendor’s proposed interface to the message switch shall ensure that an
alert message is routed to the dispatcher responsible for that unit as well as the MDC
user.
3-6.1 (15.3) The dispatcher alert shall be displayed in an obvious, but not obtrusive manner.
3-6.1 (16) The proposed mobile data interface shall allow MDC equipped units to initiate an
incident.
3-6.1 (16.1) The CAD application shall change the unit’s status to assigned at the location given in
the MDC message.
3-6.1 (17) The proposed mobile data interface shall allow an officer to add comments to any
active or closed CAD event.
3-6.1 (17.1) The CAD system shall log the comments to the audit trail identifying the user entering
the comments, and the time and date the comments were added.
3-6.1 (18) The proposed mobile data interface shall allow MDC equipped units to clear a call to
which they are assigned.
3-6.1 (18.1) When this message is received the CAD shall change the call type, if included in the
message.
3-6.1 (18.2) When this message is received the CAD shall receive and record the event disposition,
if included in the message.
3-6.1 (18.3) When this message is received the CAD shall place the units assigned to the call back
in service.
3-6.1 (19) The proposed application shall provide MDC users the ability to close calls utilizing a
mask.
3-6.1 (19.1) The mask shall be accessible by one key or keystroke combination.
3-6.1 (19.2) The mask shall include fields to change call type, address of the call, add comments to
the call, and add a disposition to the call.
3-6.1 (20) The proposed application shall allow users to return to an “in-service” status with one
key or keystroke combination if that officer is not primary and, therefore, is not required
to disposition the call.
3-6.1 (21) The proposed mobile data interface shall allow MDC equipped units to enter a
disposition for a call to which they are assigned without clearing the event.
3-6.1 (22) The proposed application shall allow officers to assist themselves onto another officer’s
call without assistance from the dispatcher.
City of Fort Collins Page 80 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-6.1 (22.1) This function shall be done from the command line.
3-6.1 (23) The proposed mobile data interface shall allow MDC equipped units to retrieve the
details of a single incident.
3-6.1 (23.1) Can be retrieved by either incident number, case (report) number or officer assigned (if
any).
3-6.1 (23.2) Incident can be either open or closed.
3-6.1 (23.3) If the incident is retrieved by incident number or case (report) number, a maximum of
six characters shall be required to recall the incident.
3-6.1 (23.4) The system administrator or authorized user shall be able to define a default agency
I.D., that is no more than two characters in length for all workstations and MDC’s. This
shall facilitate users minimizing keystrokes necessary when recalling an incident.
3-6.1 (24) The proposed mobile data interface shall allow MDC equipped units to view all CAD
incidents for a user-defined date range.
3-6.1 (25) The proposed system shall allow units equipped with mobile data computers to view
the current status of all units under the control of the CAD system.
3-6.1 (25.1) This function shall be accomplished with one key or keystroke combination.
3-6.1 (25.2) The unit status display shall include the following:
3-6.1 (25.2.1) Patrol/Fire area,
3-6.1 (25.2.2) Unit(s) assigned to the call,
3-6.1 (25.2.3) Current location of units,
3-6.1 (25.2.4) Call Type,
3-6.1 (25.2.5) Incident Number,
3-6.1 (25.2.6) Unit Status (On scene, en route etc),
3-6.1 (25.2.7) Time elapsed in current status,
3-6.1 (25.2.8) and Units assigned to the same call shall be grouped together for easy viewing by
mobile users.
3-6.1 (26) The proposed application shall allow units equipped with mobile data computers to
view pending incidents under the control of the CAD system.
3-6.1 (26.1) This shall be accomplished with one key or keystroke combination.
3-6.1 (26.2) The pending incident status shall include the following information:
3-6.1 (26.2.1) Incident number,
3-6.1 (26.2.2) Patrol/Fire District,
3-6.1 (26.2.3) Call type,
3-6.1 (26.2.4) Address/location,
3-6.1 (26.2.5) Time elapsed in pending status,
3-6.1 (26.2.6) Unit the call is stacked against (if applicable),
3-6.1 (26.2.7) and Incidents shall be grouped by patrol/fire area of assignment.
3-6.1 (27) MDC equipped units shall have the ability to draw the next logical case (report) number
for an existing event without dispatcher intervention.
3-6.1 (28) MDC equipped units shall have the ability to search for and display premise and hazard
records for a given address without initiating a call.
3-6.1 (29) If a premise or hazard entry is associated with an incident address, the proposed
application shall alert the MDC user by a visual and audible alert.
3-6.1 (29.1) The alert shall be obvious but not obtrusive and shall not impede any work already in
progress.
City of Fort Collins Page 81 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-6.1 (29.2) The alert shall distinguish between a premise or hazard entry.
3-6.1 (29.3) The alert shall distinguish between and exact match and a proximity match with the
incident address.
3-6.1 (30) The proposed application shall allow the MDC user to pull up the full text of the hazard
and/or premise entry with one keystroke combination if there is just one entry
associated with the address.
3-6.1 (30.1) If the address is associated with more than one premise and/or hazard entry, the
proposed application shall instead produce a list of entries.
3-6.1 (30.2) The premise and/or hazard entries shall be listed by priority defined by the system
administrator or authorized user.
3-6.1 (30.3) The MDC user shall be able to page or scroll through the list of premise and/or hazard
entries without the use of a pointing device.
3-6.1 (31) The proposed application shall allow premise and/or hazard entries from the MDC.
3-6.1 (31.1) The MDC user shall have the same functionality as a dispatcher.
3-6.1 (32) The proposed application shall allow the system administrator or authorized user to
restrict the number of premise hits that populate the MDC screen. This is to minimize
information the MDC user has to review.
3-6.1 (33) Premise and hazard details available to the MDC user shall match that of what a
dispatcher or call-taker sees.
3-6.1 (34) The proposed mobile data interface shall route messages from the MDC equipped
units to the following:
3-6.1 (34.1) Another MDC (terminal name),
3-6.1 (34.2) Another workstation (terminal name),
3-6.1 (34.3) A specific user (via personnel number),
3-6.1 (34.4) A user defined group of individuals I.E. all dispatchers,
3-6.1 (34.5) To a patrol/fire area,
3-6.1 (34.6) To all officers on an incident (via incident number),
3-6.1 (34.7) or To a system printer.
3-6.1 (35) The proposed application shall include a method of replying to a message sent by any
of the above listed groups/units
3-6.1 (35.1) The user shall have the option of including the original message in the reply.
3-6.1 (36) The proposed application shall include a method of forwarding messages to the above
listed groups/units
3-6.1 (37) The proposed application shall provide an audible and visual alert to notify the user of
an incoming message.
3-6.1 (37.1) The visual alert shall be obvious, but not obtrusive to the user and shall not impede any
other work being done by the user upon receipt.
3-6.1 (37.2) The visual and audible alerts shall be configurable by the user.
3-6.1 (38) The CAD application shall provide a positive response to the MDC user to all
messages and commands received from an MDC user. I.E. confirmation that a
command such as “en route” has been accepted by the system.
3-6.1 (39) The proposed application shall allow officers to reset unit contact timers.
3-6.1 (39.1) This function shall be preformed from the command line.
3-7 MAPPING AND GEOFILE FUNCTIONS
3-7.1 GENERAL REQUIREMENTS 0 0 0 0
City of Fort Collins Page 82 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-7.1 (1) The proposed application shall utilize a geographic information system which meets the
requirements listed in Section 2.
3-7.1 (2) The proposed application shall also use the coordinate-based geofile to determine if:
3-7.1 (2.1) There are duplicate calls within a user-defined radius of the new call,
3-7.1 (2.2) and There are premise or hazard records within a user-defined radius of the new call.
3-7.1 (3) The proposed application shall have the ability to receive and accept geographic
coordinates from a cellular telephone carrier and display the location of a cellular caller
on a map (phase 2 wireless).
3-7.2 MAP DISPLAY 0 0 0 0
3-7.2 (1) The proposed map application shall allow the user to turn layers of the map on and off
as needed.
3-7.2 (2) The map display shall have the ability to run as a window on the same monitor as the
status display or on a third monitor.
3-7.2 (3) The proposed map display application shall be capable of redrawing quickly enough
such that neither the user or the CAD application has an appreciable wait while the
map redraws (appreciable wait is defined as 5 seconds or more).
3-7.2 (4) The proposed application shall include a mapping display application which shows the
location of an incoming 911 call based on the ALI information supplied by the telephone
company.
3-7.2 (5) The mapping system shall generally provide a graphical representation of the unit and
event status monitors overlaid on any maps displayed.
3-7.2 (6) The proposed application shall be capable of displaying a map which shows:
3-7.2 (6.1) The location of active calls for service,
3-7.2 (6.2) The last recorded location of all units,
3-7.2 (6.3) The location of AVL equipped units,
3-7.2 (6.4) and The location of pending calls for service.
3-7.2 (7) The mapping system shall display symbols on the map for each unit controlled by the
CAD system regardless of jurisdiction.
3-7.2 (8) Each user shall be able to identify which units the user views up to all units controlled
by the CAD system.
3-7.2 (9) The mapping system shall display symbols on the map for each active or pending
event.
3-7.2 (10) Each user shall be able to identify which incidents the user views up to all incidents for
all jurisdictions controlled by the CAD system.
3-7.2 (11) The map symbols shall utilize colors which are consistent with those utilized by the
status displays; e.g., pending or active for events, on-scene or en route for units, etc.
3-7.2 (12) The participating agencies will give preference to solutions which during the event entry
process zoom the map to a user-defined level and display a symbol on the map
showing the location of the address of the calling party as reported by the 9-1-1 or
Caller ID system.
3-7.2 (13) The map display shall zoom to a user-defined level each time an event record is
selected for review, centering on the event location.
3-7.2 (14) It is preferred that the map display shall allow for different levels of zooms based upon
incident type; e.g., broader map area for chase.
City of Fort Collins Page 83 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-7.2 (15) The operator shall have the ability to enter an address and have the map zoom in to
show that address. This will be accomplished either from the CAD command line or
from the mapping system itself.
3-7.2 (16) It is preferred that the proposed application allow for map manipulation through as
many methods as possible; i.e. function key, pointing device, command, or graphic
command button.
3-7.2 (17) The proposed application shall allow the user to configure the default map views for
each workstation. These views shall be attached to user log-on’s.
3-7.2 (18) The map shall return to the default view after a user-defined period of time subsequent
to a zoom induced by an event record review, location verification or user directed
zoom.
3-7.2 (19) The proposed application shall provide a feature that allows the mapping display
system to have the ability to calculate the following between any two user selected
locations or system selected points (AVL/cell call data etc.) on the map both upon call
entry and on demand:
3-7.2 (19.1) Route with the shortest distance.
3-7.2 (19.2) Route with the shortest travel time.
3-7.2 (20) The geofile shall have the ability to capture all necessary street attributes to accomplish
the calculation of shortest travel time.
3-8 SYSTEM ADMINISTRATION FUNCTIONS
3-8.1 DEFAULT AND RESTRICTED VALUES 0 0 0 0
3-8.1 (1) The CAD system shall allow the system administrator or authorized user to enter
“default” values in each of the following fields:
3-8.1 (1.1) The State field on any form,
3-8.1 (1.2) The City field on any form,
3-8.1 (1.3) The Date field on any form (current date),
3-8.1 (1.4) The Time field on any form (current time),
3-8.1 (1.5) The User ID field on any form (logged on user),
3-8.1 (1.6) or The Workstation ID field on any form (workstation initiating transaction).
3-8.1 (2) The proposed application shall allow the system administrator or authorized user to
define the acceptable values for any field.
3-8.1 (3) The proposed application shall allow the system administrator or authorized user to set
a default time period for scheduled events such that the scheduled event will appear in
the pending event queue for the appropriate dispatcher (xxx) minutes prior to the
original time that the event was scheduled.
3-8.1 (3.1) The default time field shall be at least three digits and shall be measured in minutes.
3-8.1 (4) The system administrator or authorized user shall have the ability to retrieve premise
records based on their expiration date so that they can be renewed or purged as
appropriate. This shall be an automatic report generated by the system based on
expiration dates.
3-8.1 (5) The proposed application shall support an auto-purge function for hazard records when
they reach their expiration date.
3-8.1 (5.1) The application shall then send, via e-mail message, a form to the user that entered the
record, that it has been purged, giving the user the chance to re-enter if the record is
still valid.
City of Fort Collins Page 84 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-8.1 (6) The proposed application shall support user-defined event dispositions of, at minimum,
6 alphanumeric characters.
3-8.1 (7) The system administrator or authorized user shall be able to determine which events
require a disposition before they can be closed.
3-8.1 (8) The system administrator or authorized user should have the ability to construct query
masks for outside interfaces including but not limited to CCIC/NCIC/DOR/DMV
databases.
3-8.2 GENERAL INQUIRY REQUIREMENTS 0 0 0 0
3-8.2 (1) The proposed application shall offer a single form for entering the following inquiries to
CCIC and other systems for registration, wanted, stolen or other information. The form
shall include all fields for the following queries:
3-8.2 (1.1) Drivers License Query,
3-8.2 (1.2) Vehicle Registration Query by license plate number or VIN,
3-8.2 (1.3) and Stolen Article Query.
3-8.2 (2) The proposed application shall allow the user to add the entire text of any inquiry return
or message from CCIC to a CAD event record by the use of a simple command or
action.
3-8.2 (3) When sufficient information is entered on a vehicle or person stop proposed application
shall automatically query to the following systems for registration, stolen or wanted
information:
3-8.2 (3.1) CCIC/NLETS/NCIC,
3-8.2 (3.2) DOR/DMV,
3-8.2 (3.3) and Local (System) RMS/JMS,
3-8.2 (4) When a vehicle, boat, person, article or gun inquiry is initiated the proposed application
shall also check the CAD database for previous involvement. For example, names
shall be checked for past involvement as a complainant or suspect; license plates shall
be checked for previous involvement as suspect, stolen or towed vehicles.
3-8.2 (5) The proposed application shall automatically format and send inquiries to the
appropriate database(s) under the following circumstances:
3-8.2 (5.1) Upon the entry of a vehicle contact which includes a license plate number and state of
issue (default value),
3-8.2 (5.2) Upon the entry of a subject stop which includes name, and DOB information,
3-8.2 (5.3) and Upon the entry of a towed/impounded vehicle, boat, trailer or other licensed object.
3-9 REPORTS AND SEARCH FUNCTIONS
The CAD system must provide a variety of management information reports. A
standardized set of management reports shall be provided, which will be used to
analyze the occurrence of events by unit ID, area of assignment, shift, type, geographic
area, time of day and day of week, call source and to examine the average response
times. Although most reports will be routine, the proposed application must also
provide an ad-hoc report writer that will enable non-technical authorized users to easily
define, save, and share custom reports created from any database included in the
proposed application.
3-9.1 GENERAL REQUIREMENTS AND REPORTS 0 0 0 0
3-9.1 (1) The proposed application shall allow a user to search, with the use of wildcards, on any
field or combination of fields including but not limited to:
City of Fort Collins Page 85 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-9.1 (1.1) Incident number,
3-9.1 (1.2) Case (report) number,
3-9.1 (1.3) Date/time ranges,
3-9.1 (1.4) Jurisdiction,
3-9.1 (1.5) Call-type,
3-9.1 (1.6) Map page,
3-9.1 (1.7) Police, fire and/or ambulance beat/area/reporting district,
3-9.1 (1.8) Primary unit,
3-9.1 (1.9) Unit/dispatcher that entered the incident,
3-9.1 (1.10) Disposition,
3-9.1 (1.11) Address (shall utilize address verification),
3-9.1 (1.12) Location,
3-9.1 (1.13) or Commonplace.
3-9.1 (2) Searches shall retrieve information pertinent to the field type from all forms in the CAD
application. For example if the user queries the name Robert Smith and Mr. Smith
appears as a reporting person on one incident and a suspect on another incident the
application shall return both instances.
3-9.1 (3) At a minimum all standard reports will contain the following fields:
3-9.1 (3.1) Report header with department name,
3-9.1 (3.2) Date report was printed,
3-9.1 (3.3) Date and time range for the contents of the report,
3-9.1 (3.4) Page number,
3-9.1 (3.5) Specified search parameters (e.g. district, unit ID, etc.),
3-9.1 (3.6) and Report requestor’s name.
3-9.1 (4) The proposed application should have the ability to schedule named reports for
printing:
3-9.1 (4.1) On a specific time and date,
3-9.1 (4.2) or on a periodic basis.
3-9.1 (5) The proposed application shall include a premise records report which allows the user
to view premise records which are due to expire during user-defined date range.
3-9.1 (6) The proposed application must be able to print a report on command of the current unit
and event statuses.
3-9.2 EVENT RELATED REPORTS 0 0 0 0
3-9.2 (1) The proposed CAD system should include the following event reports:
3-9.2 (1.1) Events by type for a specific date or date range,
3-9.2 (1.2) Events by type and day of week for a given date range,
3-9.2 (1.3) Events by type, and day of week, sorted by district, location or other geo-file supported
zone, for a given date range,
3-9.2 (1.4) Events for a given date range subtotaled by event type,
3-9.2 (1.5) Events for a given date range subtotaled by call source,
3-9.2 (1.6) All events by address, district, location or geo-file supported geographic area during a
user defined date and time range,
3-9.2 (1.7) All events by police, fire and/or ambulance district during a user defined date and time
range,
City of Fort Collins Page 86 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-9.2 (1.8) Total event activity occurring in a given police, fire and/or ambulance district zone
during a user defined time and date range,
3-9.2 (1.9) Average event processing time sorted and totaled by event priority,
3-9.2 (1.10) Average event processing time sorted and totaled by event type,
3-9.2 (1.11) Average event processing time for a specific communications employee by event
priority,
3-9.2 (1.12) Average event processing time for a group of communications employees by event
priority,
3-9.2 (1.13) Event audit report which shall show every transaction recorded to a specific event in
chronological order,
3-9.2 (1.14) Event summary report which shall include the date, time of receipt and dispatch,
location, event type and priority, call taker and dispatcher id, primary and backup units,
disposition, and event close time for a given event number,
3-9.2 (1.15) Disposition reports which detail the disposition for all events in a given patrol, fire
and/or ambulance district for a given date range,
3-9.2 (1.16) A report showing all events for which the event type was changed at least once. This
report shall include the original classification and any subsequent classifications.
Events shall be identified by event number and location,
3-9.2 (1.17) and A “hot spot” report, which details all event locations which exceed a user-defined
number of events for a user-defined date and time interval.
3-9.2 (2) Response Time Compliance: user-defined “emergency” or “non-emergency” and
“district” or “zone” display will be available for call up or printout and will show response
time compliance for a date range. Cumulative fractal distribution response time (see
example):
3-9.2 (2.1) Problem/solution maps: Graphical display of user-defined call types input of priority
dispatch codes (emergency / non-emergency), date range, and response time
parameters): a geographic display showing the locations of problem calls by hour-of-
day, day-of-week.
3-9.2 (2.2) Demand analysis: peak demand by date range, hour-of-day, and day-of-week-graphic,
numeric, and chart
3-9.2 (2.3) Statistics by date range: number of calls, call types by number and % of total.
3-9.2 (2.4) Records finder: List of ambulance incidents and run numbers by date range; listing call
type, dispatch time, incident location, patient name, destination, crew names, unit ID
numbers.
3-9.3 UNIT AND EMPLOYEE RELATED REPORTS 0 0 0 0
3-9.3 (1) Single unit activity, including calls for service and other non-event related activities, for
a user-defined time period, shift, or assigned area.
3-9.3 (2) Single employee activity, including calls for service and other non-event related
activities, for a user-defined time period or shift.
3-9.3 (3) Single employee activity or events by type and user-defined date/time range.
3-9.3 (4) Single employee activity by location or grid during a user defined date and time range.
3-9.3 (5) Address overrides by user-defined employee during a user-defined date and time
range.
3-9.3 (6) Roster report which includes all personnel, units and districts to which they are
assigned for a given date and shift.
City of Fort Collins Page 87 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-9.3 (7) If the roster report is not for the current shift it shall include the on-duty and off-duty
time for each employee and unit assignment changes during the shift, if any.
3-9.3 (8) A report shall detail the on-duty, off-duty times, elapsed time and assignment for a
given employee during a given date and time range.
3-9.3 (9) A report shall provide a statistical summary of the hours worked by all employees
during a given time and date range, sorted and sub-totaled by shift or organizational
element.
3-9.3 (10) It is preferred that the system be capable of creating a report which shows the recorded
location and status of all units and events at particular date and time.
3-9.4 SEARCH FUNCTIONS 0 0 0 0
3-9.4 (1) The proposed application shall allow access to a CAD name index and offer a form or
other device which will allow a user to search the CAD name index for prior CAD
involvement.
3-9.4 (2) The proposed application shall provide search results that include at a minimum:
3-9.4 (2.1) Returns from CAD,
3-9.4 (2.2) and Returns from the RMS/JMS MNI.
3-9.4 (3) The proposed application shall provide a means for searching for BOLO’s.
3-9.4 (4) The proposed application shall allow the following fields be available as search
parameters for bolo’s:
3-9.4 (4.1) Date or date range/times,
3-9.4 (4.2) Summary or title,
3-9.4 (4.3) Offense nature or event type code,
3-9.4 (4.4) Persons named on bolo,
3-9.4 (4.5) Physical descriptions,
3-9.4 (4.6) License plate numbers involved,
3-9.4 (4.7) Vehicle descriptions,
3-9.4 (4.8) Police District,
3-9.4 (4.9) Other geographic area supported by the geofile,
3-9.4 (4.10) Free form text search,
3-9.4 (4.11) or Reporting party name.
3-9.4 (4.12) It is preferred that the following search criteria be available:
3-9.4 (4.12.1) Date or date range,
3-9.4 (4.12.2) Shift,
3-9.4 (4.12.3) Day of week,
3-9.4 (4.12.4) Vehicle or unit number,
3-9.4 (4.12.5) and Police, fire and/or ambulance district.
3-10 SECURITY FEATURES
3-10.1 AUDIT LOG 0 0 0 0
3-10.1 (1) The proposed application must create and maintain an audit trail for each event.
3-10.1 (1.1) The system will archive these audit logs for a minimum of 12 months time.
3-10.1 (1.2) All audit logs shall be easily accessible from CAD workstations and MDC’s.
3-10.1 (2) The proposed application shall create and maintain an audit trail for each unit.
3-10.1 (2.1) The system will maintain a history of these audit logs for at least 12 months time.
3-10.1 (2.2) All audit logs shall be easily accessible from CAD workstations and MDC’s.
City of Fort Collins Page 88 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-10.1 (2.3) The audit log shall record every transaction for an event or field unit.
3-10.1 (3) The proposed application shall provide a command for displaying the audit trail for any
event or unit.
3-10.1 (4) In every case where a CAD database record, including non-event or unit records, is
created or changed the proposed application shall record:
3-10.1 (4.1) The time and date of the change,
3-10.1 (4.2) The user making the change,
3-10.1 (4.3) The workstation from which the change was made,
3-10.1 (4.4) The original value of the field which was changed,
3-10.1 (4.5) and The new value of the field.
3-10.2 CAD MANAGEMENT INFORMATION SYSTEM
3-10.2 (1) The proposed application shall offer a Management Information System module for
CAD.
3-10.2 (2) The CAD MIS shall allow the system administrator or authorized user to manage:
3-10.2 (2.1) CAD configuration files,
3-10.2 (2.2) Passwords and security tables,
3-10.2 (2.3) and Interfaces.
3-10.2 (3) The CAD MIS shall minimally offer the following standard reports concerning
Communications Operations:
3-10.2 (3.1) A workload statistics summary report which summarizes the number of calls for service
handled during a given date range, subtotaled by shift which shows the average
processing time for all calls and by call priority,
3-10.2 (3.2) A workload statistics detail report which shows the total calls for service handled by
each employee during a given time period, subtotaled by event priority and showing
average processing time by priority,
3-10.2 (3.3) and An individual workload report which shows for a given employee and time period,
the total time signed on to CAD, the total number of calls for service handled by calls
entered, calls dispatched, and calls changed or supplemented.
3-10.3 PERSONNEL MODULE INTERFACE 0 0 0 0
3-10.3 (1) The proposed application shall include/interface with the shared personnel module
described in Section 2 for tracking information related to employees who either interact
with the CAD system or are resources tracked by it.
3-10.3 (2) The shared personnel module shall have primacy over the CAD personnel database.
Thus, CAD shall first draw personnel information from the shared system and allow the
user to enter additional information as required.
3-10.3 (3) The proposed CAD application shall obtain special skills information from the shared
personnel system.
3-10.3 (4) The proposed CAD application shall draw on-duty personnel information from the roster
function of the shared personnel system.
3-10.3 (5) The proposed application shall provide a simple means for a dispatcher or other
authorized employee to record the on and off duty time for a particular employee.
Normally the shift roster will be used to record such times. This function will be used to
record the times for employees who are not assigned to a particular shift, or who arrive
later or leave earlier than the rest of their shift.
3-11 OTHER CAD REQUIREMENTS
City of Fort Collins Page 89 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-11.1 COMPUTER ASSISTED CAD TRAINING 0 0 0 0
3-11.1 (1) The CAD system shall include a training system which allows users to access the live
CAD databases including the Geo-file, unit table, event table, hazard and warning files.
3-11.1 (2) Users logged on to the training system shall be able to simulate the actions of all
system interfaces.
3-11.1 (3) Users logged on to the training system shall utilize the same commands, forms and
system features as users logged on to the live CAD system.
3-11.1 (4) No data entered or command invoked while logged to the training system shall corrupt
the live system or noticeably impede the performance of the live system.
3-11.1 (5) It is preferred that the proposed application provide an audit trail of all actions taken
while in the training system for post-training review.
3-11.1 (6) Accessing the training system shall be tied to user log-in. It shall require no other input
from user or system administrator to begin using the training mode.
3-11.2 SCRATCH PAD
3-11.2 (1) It would be preferred that the proposed application offer a “scratchpad” or other means
of storing and retrieving notes.
3-11.2 (2) It is preferred that each user be able to store and retrieve their scratchpad notes
individually.
3-11.3 ELECTRONIC MAIL AND MESSAGING FUNCTIONS 0 0 0 0
3-11.3 (1) The proposed application shall allow for separate CAD e-mail and messaging
functions.
3-11.3 (2) The CAD system shall incorporate an electronic mail system which allows users to
send and receive mail messages to another CAD user, networked connected
workstation, or mobile computer.
3-11.3 (3) E-mail shall allow for system administrator defined e-mail groups. For example: 1
group for dispatchers only, 1 group for patrol only etc.
3-11.3 (4) The CAD system shall allow E-mail messages to be attached to the CAD record on
demand.
3-11.3 (5) If a user is not logged on to the system when the mail message is sent the application
will hold the message until the next time they log on.
3-11.3 (6) Users shall be able to send a message to:
3-11.3 (6.1) one or more officers or employees ID numbers, in which case the application will
determine where the addressees are logged on and route the message to the
appropriate workstations or MDC’s,
3-11.3 (6.2) to a pre-defined group,
3-11.3 (6.3) to a workstation,
3-11.3 (6.4) a CAD position,
3-11.3 (6.5) a mobile data computer,
3-11.3 (6.6) to an incident number,
3-11.3 (6.7) or to a printer.
3-11.3 (7) The proposed application shall allow each user to have a mailbox.
3-11.3 (8) The system administrator or authorized user will have the ability to set a maximum
mailbox size for each user. Once the mailbox limit has been reached the mailbox will
no longer accept messages.
City of Fort Collins Page 90 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
3-11.3 (9) The mailbox will hold new messages, sent messages and messages which have been
read but which have not been deleted.
3-11.3 (10) The system administrator or authorized user shall have the capability to set a time limit
for the retention of messages. When a message is older than the time limit it will be
automatically purged.
3-11.3 (11) The system administrator or authorized user shall have the ability to log all messages
sent in the CAD system.
3-11.4 MEMOS/REMINDERS 0 0 0 0
3-11.4 (1) The proposed application shall provide a memo feature to allow all users to input free-
form reminder messages to pop up at a selected date/time.
3-11.4 (2) This feature shall allow users to enter a single memo to appear one time, or be
scheduled to appear on a regular basis—daily, weekly, or monthly—for an indefinite
period of time.
3-11.4 (3) The free-text field should be no less than 200 characters in length.
3-11.5 INFORMATION FILES 0 0 0 0
3-11.5 (1) The proposed application shall incorporate a separate database that holds
miscellaneous information including but not limited to phone numbers, door
combinations, specific procedures, on-call lists, and any other conceivable bits of
information deemed necessary.
3-11.5 (2) This database shall be accessible by all users for entry and query.
3-11.5 (3) This database shall be searchable by key-words and shall allow searching by “wild-
cards” all from the command line.
SECTION TOTALS 0 0 0 0
City of Fort Collins Page 91 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4 RECORDS MANAGEMENT
4-1 SYSTEM DESIGN
4-1.1 GENERAL REQUIREMENTS AND DESIGN FEATURES 0 0 0 0
The Records Management Database shall be designed to operate as a component of a
comprehensive, fully integrated, multi-user, incident-based Public Safety System
4-1.1 (1) Records The proposed Management RMS/JMS System application (RMS) shall and be Jail designed Management to share System information (JMS). logically
and automatically with other applications, such as CAD, Full Court Justice Systems,
4-1.1 (2) etc. When a user signs on to the system the proposed records application shall display (at
participating agencies discretion) a summary or otherwise inform the user of:
4-1.1 (2.1) Incomplete Reports for which the user is responsible,
4-1.1 (2.2) Reports which have been returned for corrections or review for which the user is
responsible,
4-1.1 (2.3) Scheduled reports which have run since the user’s last logon,
4-1.1 (2.4) Returns from delayed inquiries to RMS/JMS, CBI, NCIC, NLETS, and other resources,
4-1.1 (2.5) Newly assigned cases for investigations follow up,
4-1.1 (2.6) Records of interest (ROI) “hits”,
4-1.1 (2.7) And waiting messages.
4-1.1 (3) The proposed RMS/JMS application shall include extensive “drill down” search
capabilities. For example, if a name search returns four potential candidates the user
shall be able to view each record by selecting it in some manner. If the record
displayed then had a co-defendant, the user would be able to select that record, see
the co-defendant records, if the co-defendant had a vehicle, the user would be able to
select that record and sell all persons and locations associated with that vehicle, and so
on.
4-1.1 (4) The proposed application shall have the ability to retrace the drill down steps (step by
step) to return to any point of the drill down and then branch in a different direction.
4-1.1 (5) All narrative fields shall have the ability to accept no less than 32,000 characters of
text.
4-1.1 (6) The proposed RMS/JMS application shall be sized to store up to fifteen years of data
on-line without adding disk or other storage devices, memory, or additional processors.
4-1.1 (7) The proposed RMS/JMS application shall support single point of entry of data for all
forms, reports, and other data entry tasks.
4-1.1 (8) The proposed application shall allow a user to retrieve a previously submitted report,
change one or more fields and save it as a new report.
4-1.1 (8.1) The proposed application shall provide a means of modifying this cloned report by
automatically inserting the CAD data for the new case (report) number.
4-1.1 (9) The proposed application shall provide basic word processing capabilities (without
spawning a separate word processor) for entering narratives and supplemental reports
that specifically includes spell check and the creation of templates (all text must be
searchable on RMS/JMS user query).
4-1.1 (10) It is desired that the proposed records application track the time required to complete
each report in order to facilitate management reporting and to identify persons who
may require additional training.
City of Fort Collins Page 92 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-1.1 (11) The proposed application shall allow for the user to request translation of any code that
has an associated entry in the code table by allowing the user to select the code in
some manner and to then have a full text description appear in some way.
4-1.1 (12) The system shall have the ability to assign sequential case (report) numbers (numbers
unique to each event and each agency) in the format described below;
4-1.1 (12.1) alpha/numeric,
4-1.1 (12.2) 10 characters,
4-1.1 (12.3) in the format (YY)(AA)(NNNNNN) where (YY) is the last two digits of the current year,
(AA) is a two letter code for the reporting agency, and (NNNNNN) is a six digit
sequential number unique to each agency that starts over each year.
4-1.1 (13) The numbering system shall be designed to ensure that all cases (reports) receive a
number, that no numbers are omitted, and that no numbers are duplicated (anywhere in
the system).
4-1.1 (14) Each RMS record shall record and retain the incident number assigned by CAD.
4-1.1 (15) It is desired that the proposed application include as many labor saving routines as
possible. For example, when multiple pieces of property are being entered into a report
by one officer the officer shall not have to reenter his/her badge number for each item,
or the location where the property was found or seized.
4-1.1 (16) The proposed application shall have a defined field to record the fact that one or more
of the officers involved in this event had to use physical or deadly force in the course of
the event.
4-1.2 LOCATION AND NUMBER OF RMS/JMS CLIENTS 0 0 0 0
4-1.2 (1) Location/Definition (all clients must be capable of full functionality) (SEE TABLE)
4-1.3 RMS PRINTING SERVICES 0 0 0 0
4-1.3 (1) The proposed RMS application shall have a "public" report option for each incident or
other public report such that the system administrator or other authorized user can
choose to blank out (redact) certain fields.
4-1.3 (1.1) The proposed RMS application shall have a "public" report option for each incident or
other public report such that the system administrator or other authorized user can
choose to blank out (redact) narrative with an on screen tool
4-1.3 (1.2) The proposed RMS application shall have a "public" report option for each incident or
other public report such that the system administrator or other authorized user can
choose to blank out (redact) repeating narrative with an (find and replace) on screen
tool.
4-1.3 (2) The proposed RMS application shall offer any officer, investigator or authorized person
the ability to print:
4-1.3 (2.1) A single user-selected form, activity, image, or note from the case (report) file.
4-1.3 (2.2) The entire case (report) file, including all forms, notes, activities, images, etc.
4-1.3 (2.3) A broad scope printout that could include multiple case reports for which the system
administrator or other authorized user will be able to define the types of forms, notes,
images and activities to be included.
4-1.3 (2.4) A broad scope printout that could include multiple case reports, which includes forms,
defined by the system administrator or other authorized employee as being of public
record.
City of Fort Collins Page 93 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-1.3 (3) The proposed RMS application shall provide a means of storing the electronic
signature of each employee so that when a report is printed his or her signature will
appear on the report.
4-1.3 (4) The proposed RMS application shall provide a means of printing an electronic indicator
such as “approved by <officer name>” to indicate that the report has been processed
and approved.
4-1.3 (5) The proposed RMS system shall have a clear on screen indicator of the approval
status of a report.
4-1.3 (6) The proposed RMS application shall provide a means of capturing and storing citizens
electronic signatures for receipt of documents and/or property.
4-1.3 (7) The proposed RMS application shall not allow a public jacket or public report to be
printed before all reports are approved.
4-1.3 (8) The proposed RMS application shall have the ability to place overlay “watermarks” on
any output when agency defined conditions exist (juveniles, sex assault, not approved,
restricted use, etc.)
4-1.3 (9) The proposed RMS application shall allow a dissemination log of all reports printed or
emailed. At a minimum, the log shall capture require who printed, faxed, or emailed the
report, who received the report (name, address and phone), and the reason a report
was printed, faxed, or emailed.
4-1.3 (10) The proposed RMS application shall print the participating agencies logo, address, and
telephone number on all reports printed (as defined by the agency).
4-1.3 (11) The proposed RMS application shall print motor vehicle accident reports to look like the
State of Colorado accident report forms.
4-1.3 (12) The proposed RMS application shall have the ability to direct output of any inquiry or
report to:
4-1.3 (12.1) Screen (workstation),
4-1.3 (12.2) A network connected fax modem,
4-1.3 (12.3) Email as an attached .PDF file,
4-1.3 (12.4) ASCII text file format, or
4-1.3 (12.5) Printer.
4-2 CASE REPORT ENTRY AND PROCESSING
4-2.1 GENERAL REQUIREMENTS 0 0 0 0
4-2.1 (1) The proposed RMS/JMS application shall provide an clear indication of cases involving
juvenile victims and suspects.
4-2.1 (2) The proposed RMS application shall allow the system administrator or other authorized
user to exclude specified some users from seeing juvenile records on MNI inquiries.
4-2.1 (3) The proposed RMS application shall allow a user to begin the entry of a report with any
form. For example, it shall be possible for an officer to complete a Field Interrogation
(FI) form first, and then upon determining that the subject is wanted, use the
information on the FI form to complete the arrest and other necessary reports.
4-2.1 (4) The proposed RMS application shall include the ability for the system administrator or
other authorized user to define special enforcement zones such as schools.
4-2.1 (5) It is preferred that the proposed RMS/JMS application have the ability for the geo file to
auto track and auto populate a special enforcement zone field in the RMS/JMS.
City of Fort Collins Page 94 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-2.1 (6) If a crime is reported within a special enforcement zone the application shall notify the
user in a distinctive fashion.
4-2.1 (7) The proposed RMS application shall allow copying or moving of data from one field to
another (with cut & paste function) without reentry.
4-2.2 CASE REPORT AND DATA ENTRY 0 0 0 0
The proposed RMS application shall allow an officer or other employee to complete the
remainder of a report initiated in CAD through the RMS module. To accomplish this,
the proposed RMS application shall have the ability to receive and display the following
initial incident data from the Computer Aided Dispatch (CAD) System:
4-2.2 (1.1) Final call type
4-2.2 (1.2) Date/Time received
4-2.2 (1.3) Location by full street address
4-2.2 (1.4) Location by X-Y coordinates
4-2.2 (1.5) Location by reporting district
4-2.2 (1.6) Location by patrol area
4-2.2 (1.7) Listing of all officers assigned
4-2.2 (1.8) Listing of all related disposition codes by officer
4-2.2 (2) It is preferred that the proposed RMS application permit an employee to begin a new
case report directly in the RMS. Under these circumstances RMS would complete the
following actions:
4-2.2 (2.1) Create a CAD incident containing the basic case details including the date, time,
verified location, and nature of the incident, and primary officer's identification, and
4-2.2 (2.2) Draw the next logical case (report) number from the CAD system.
4-2.2 (3) The proposed RMS application shall assign a unique sequential number subservient to
(under) the original case (report) number for each supplemental investigative report.
4-2.2 (4) The proposed RMS application shall have the ability to receive, store and manage data
contained in the report forms included in the Appendix.
4-2.2 (5) Users shall be able to initiate and complete all reports and forms from:
4-2.2 (5.1) A desktop workstation connected to the RMS via a local or wide-area network,
4-2.2 (5.2) A mobile computer terminal attached to the RMS via a wireless connection,
4-2.2 (5.3) A mobile computer terminal running stand alone (off-line) with only occasional
connectivity to the RMS
4-2.2 (5.3.1) When processing reports entered in an off-line mode, the application shall check the
validity of all fields and complete other processing tasks as if the report was entered
from an on-line client.
4-2.2 (5.4) Any computer which supports a browser application and which has access to the
Department's local or wide area network.
4-2.2 (6) The proposed RMS application shall log all new reports, including supplemental
reports, as "Unapproved" until such time as they are approved by the reporting officer's
supervisor.
4-2.2 (6.1) Unapproved and/or incomplete reports shall be prominently marked as such whether
displayed on-screen or printed (such as a watermark).
4-2.2 (7) When all required fields on a report have been completed the system shall provide the
user with a dialog box or other means to route the report electronically to the next
person in an agency defined workflow process for review.
City of Fort Collins Page 95 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-2.2 (8) The proposed RMS application shall provide a means of routing a report to any other
person in the RMS such as a supervisor or another user prior to completion of the
report.
4-2.2 (9) The proposed RMS application shall provide users with the ability to capture mug shots
and store them as a part of the MNI.
4-2.2 (10) The proposed RMS application shall provide users with the ability to capture or upload
pictures, scanned images; such as pictures, diagrams and witness statements, or
electronic files of various types and store them with any RMS case record.
4-2.2 (10.1) The system shall have the ability to limit the size of attachments.
4-2.2 (11) The proposed RMS application shall include a report format for collecting information
on field stops and interrogations (Contact or Field Interview Cards).
4-2.2 (12) At a minimum, the contact card form shall capture the information contained in the MNI,
MLI, MVI, mugshot module, & offender module for each person contacted and;
4-2.2 (12.1) Clothing description,
4-2.2 (12.2) Narrative for comments and probable cause,
4-2.3 CASE REPORT PROCESSING 0 0 0 0
4-2.3 (1) The proposed RMS application shall check each completed field to ensure:
4-2.3 (1.1) That the user has entered a value in each mandatory field, and
4-2.3 (1.2) That entries in value restricted fields match one of the acceptable values for that field.
4-2.3 (2) If mandatory fields have not been completed, the application will denote the missing or
incorrect entries in a noticeable manner.
4-2.3 (3) The proposed RMS application shall allow a user to save a report prior to completing all
fields or when errors are present, but the application will notify the user that required
fields have not been completed or the report contains errors.
4-2.3 (4) The proposed RMS application shall include a table that shall allow the system
administrator or other authorized user to determine which reports or forms must be
reviewed and approved by a supervisor before being committed to the database.
4-2.3 (5) The proposed RMS application shall notify a supervisor each time a report requiring
review is received from a user under their command.
4-2.3 (6) The proposed RMS application shall provide a command for supervisors to display the
reports which are awaiting their review.
4-2.3 (7) The proposed RMS application shall:
4-2.3 (7.1) Automatically route completed reports to the supervisor designated for the officer or
employee who completes the report.
4-2.3 (7.2) Automatically route reviewed reports requiring corrections back to the initiating officer
or staff member.
4-2.3 (7.3) Return corrected reports to the Supervisor for review.
4-2.3 (7.4) Monitor the number of times a report is submitted and reviewed for each officer in order
to identify officers or staff members who may require additional training.
4-2.3 (7.5) The proposed RMS application shall include a notes field where supervisors can enter
comments that would be automatically deleted upon final approval.
4-2.3 (7.6) The proposed RMS application shall allow a supervisor to flag fields or text that must
be corrected before the report will be accepted.
4-2.3 (8) The proposed RMS application shall provide a command for supervisors to see the
reports which they have returned for corrections and which have not been resubmitted.
City of Fort Collins Page 96 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-2.3 (9) The proposed RMS application shall notify the responsible supervisor and the
commander of the unit to which the supervisor is assigned when required reports have
not been completed after a Department definable time.
4-2.3 (10) The proposed RMS application shall notify the responsible supervisor and the
commander of the unit to which the supervisor is assigned when required reports have
not been submitted for review after a Department definable time period.
4-2.3 (11) The proposed RMS application shall allow authorized users to restrict the distribution of
a report so that it cannot be viewed or printed by other users (Report Hold). (look at all
of this area)
4-2.3 (11.1) The proposed RMS application shall have the ability to classify certain reports as
confidential and restrict distribution to a list defined by the user who is defining the
report as Restricted.
4-2.3 (11.2) The proposed RMS application shall allow the system administrator or other authorized
user to determine which users will have the authority to classify a report as Restricted.
4-2.3 (11.3) The proposed RMS application shall have the ability to classify certain reports as
confidential and restrict distribution to a list defined by the user who is defining the
report as password protected.
4-2.3 (11.4) The proposed RMS application shall allow the system administrator or other authorized
user to determine which users will have the authority to classify a report as password
protected.
4-2.3 (11.5) The proposed RMS application shall have levels of security to ensure certain cases
may be protected (flagged) (i.e. confidential, adult-at-risk, etc.)
4-2.3 (11.6) The proposed RMS application shall allow having more than one (global) password (i.e.
different password for different reasons – drug task force, etc.)
4-2.3 (12) The proposed RMS application shall allow the generation of a hard copy listing of
archived records.
4-2.3 (13) The proposed RMS application shall allow the archive capabilities according to a pre-
defined records retention schedule.
4-2.3 (14) The proposed RMS application shall retain master index entries for archived records in
the on-line master index with a notation that the record has been archived and the
location of the archived information.
4-2.3 (15) When a search return includes an archived record, the operator shall be able to easily
determine the location of the archived information.
4-2.3 (16) The proposed RMS application shall have the ability to access at least 15 years of on-
line RMS data.
4-2.3 (17) In addition to the elements shown on the forms attached in the Appendix, the proposed
RMS application shall have the ability to track the following information about persons:
4-2.3 (17.1) All information contained in the master name record as it was originally entered in this
report (data can not change when the MNI is updated with new information).
4-2.3 (17.2) Relationship to report (e.g. Suspect, witness, parent, complainant, etc.); multiple roles
allowed.
4-2.3 (17.3) Modus operandi (mo) fields that are configurable by system administration
4-2.3 (17.4) Clothing description,
4-2.3 (17.5) Blood alcohol level,
City of Fort Collins Page 97 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-2.3 (18) In addition to the elements shown on the forms attached in the appendix, the proposed
RMS application shall have the ability to track the following information about vehicles:
4-2.3 (18.1) All information contained in the master vehicle record as it was originally entered in this
report (data can not change when the MVI is updated with new information).
4-2.3 (18.2) Stolen vehicle information:
4-2.3 (18.2.1) value of the vehicle,
4-2.3 (18.2.2) date/time recovered,
4-2.3 (18.2.3) value of the vehicle when recovered,
4-2.3 (18.2.4) location of recovery by full street address (tied to MLI),
4-2.3 (18.2.5) location of recovery by x-y coordinates (tied to MLI),
4-2.3 (18.2.6) location of recovery by reporting district,
4-2.3 (18.2.7) location of recovery by patrol area,
4-2.3 (18.2.8) and insurance carrier and policy number.
4-2.3 (19) The proposed RMS application shall have the ability to receive, store, and manage all
data elements required for Colorado (IBRS) and FBI (NIBRS) reporting.
4-2.3 (20) The proposed RMS application shall allow authorized users to update case reports with
clearance information, and automatically generate an update to the IBRS record that
was sent to the State.
4-2.3 (21) Outside of (and subservient to) the NIBRS/IBRS reporting of exceptional clearance of
incident reports, the proposed RMS application shall allow additional clearances per
case record to show the individual status of each offender.
4-2.3 (22) The proposed RMS application shall have the ability to receive, store and manage
court dispositions for each charge in the case record.
4-2.3 (23) The proposed RMS application shall allow standard IBRS/NIBRS reports to be printed
locally, and/or saved to some type of magnetic media; and/or forwarded electronically
as a batch download, to CBI monthly.
4-2.3 (24) Reports shall include, at minimum, all information captured by IBRS/NIBRS elements in
the format(s) prescribed by CBI for the following information:
4-2.3 (24.1) Monthly Return of Offenses,
4-2.3 (24.2) Property Stolen by Classification,
4-2.3 (24.3) Property Recovered Tally,
4-2.3 (24.4) Larceny - Theft Tally,
4-2.3 (24.5) Motor Vehicle Theft Tally,
4-2.3 (24.6) Supplement to Return A - Evaluation of Stolen Property,
4-2.3 (24.7) Monthly Return of Arson Offenses,
4-2.3 (24.8) Age, Sex and Race of Person Arrested - 18 & Over,
4-2.3 (24.9) Age, Sex and Race of Person Arrested - Under 18,
4-2.3 (24.10) Law Enforcement Officers Killed or Assaulted (LEOKA) Report,
4-2.3 (24.11) Homicide Summary Report.
4-3 TRAFFIC ENFORCEMENT 0 0 0 0
4-3.1 (1) The proposed RMS application shall include an integrated module for reporting and
tracking citations, warnings and accidents.
4-3.1 (2) The proposed RMS application shall allow for cross-referencing to other incidents,
accidents, arrests, etc.
City of Fort Collins Page 98 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-3.1 (3) The proposed RMS application shall allow for a narrative report to be attached to the
accident details.
4-3.1 (4) The proposed RMS application shall have the ability to capture and store the data
elements required for the State of Colorado accident, commercial vehicle and fatality
report forms, included in the Appendix.
4-3.1 (5) The proposed RMS application shall have the ability to print out completed accident
reports including accident diagrams as a replica of the State of Colorado accident
report form.
4-3.1 (6) Information obtained through the traffic system shall be included in the master name,
and vehicle indexes.
4-3.1 (7) It is preferred that the proposed RMS application has the ability to receive parking and
traffic complaints from citizens. These complaints would then be used to plan traffic
enforcement assignments.
4-3.1 (8) It is preferred that the proposed RMS application have the ability to receive simple
traffic accident report forms via HTML so that citizens can report minor accidents
through the agency(ies) web site(s).
4-3.1 (9) The proposed RMS application shall be able to import an ASCII text file from a traffic
accident field reporting application. Imported records shall be processed for field logic
once they are displayed on the proposed RMS client application.
4-3.1 (10) The proposed RMS application shall allow for the transfer of accident information that
has been entered into the RMS in the form of a delimited ASCII text file.
4-3.1 (11) The proposed RMS application shall have the ability to track the issuance of citation
books with the beginning and ending citation number.
4-3.1 (12) At a minimum, the proposed RMS application shall capture and report the following
citation and warning information:
4-3.1 (12.1) Capture the information contained in the MNI, MLI, & MVI for each person contacted
and;
4-3.1 (12.2) Citation or warning number,
4-3.1 (12.3) Location of offense,
4-3.1 (12.4) County where offense occurred,
4-3.1 (12.5) Offense date,
4-3.1 (12.6) Offense time,
4-3.1 (12.7) Issuing officer,
4-3.1 (12.8) Violation code
4-3.1 (12.9) Violation description,
4-3.1 (12.10) Speed/posted speed,
4-3.1 (12.11) and Fine assessed.
4-3.1 (13) System needs to be able to figure due date of fine payment from date citation issued
(early payment/point reduction)
4-3.1 (14) Need to be able to generate reports of fines due, fines paid, citations overdue, and
citations sent to court.
4-3.1 (15) When a citation is issued in conjunction with an accident, the proposed RMS
application shall copy the offender name and other relevant information to the citation
record so that the user will not have to re-enter the information.
City of Fort Collins Page 99 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-3.1 (16) It is preferred that the proposed RMS application allow officers to issue citations on a
mobile or portable data terminal and then upload those citations to the server either via
wireless or some other means.
4-3.1 (17) The vendor shall supply specifications and pricing for driver’s license barcode or
magnetic stripe readers.
4-4 FIELD REPORTING
4-4.1 GENERAL REQUIREMENTS 0 0 0 0
4-4.1 (1) The proposed RMS application shall provide a mobile field reporting application.
4-4.1 (2) The proposed mobile field reporting application shall have the same look and feel as
the RMS client.
4-4.1 (3) It is preferred that the field reporting application be fully developed and supported by
the same vendor for RMS/JMS rather than a third party vendor.
4-4.1 (4) The user agency forms should be resident on the mobile data computer.
4-4.1 (5) The proposed mobile field reporting application shall use pull-down fields with auto
defaults and auto fill capabilities.
4-4.1 (6) The proposed mobile field reporting application shall use look up tables for pick and
validation purposes.
4-4.1 (7) The proposed mobile field reporting application shall require data be entered only once
and use that data in all other needed forms and reports.
4-4.1 (8) The proposed mobile field reporting application shall allow data entry by bar code
reader.
4-4.1 (9) The proposed mobile field reporting application shall have the ability to prompt for
needed information.
4-4.1 (10) The proposed mobile field reporting application shall allow shortcut keys for entering
information.
4-4.1 (11) At a minimum, the proposed mobile field reporting application shall have the ability to
electronically complete the following forms and reports:
4-4.1 (11.1) Case Reports,
4-4.1 (11.2) Arrest,
4-4.1 (11.3) Booking,
4-4.1 (11.4) Traffic Accident,
4-4.1 (11.5) Field Interviews (Contact Cards),
4-4.1 (11.6) Warnings,
4-4.1 (11.7) Traffic Citations,
4-4.1 (11.8) Property/Evidence Reports,
4-4.1 (11.9) Property Inventory (for search warrants),
4-4.1 (11.10) Domestic Violence Reports,
4-4.1 (11.11) Subpoenas and Warrant Service,
4-4.1 (11.12) Civil Process
4-4.1 (11.13) and Affidavit of Warrantless Arrest
4-4.1 (12) The proposed mobile field reporting application shall have the ability to complete all
operations as described in this module without full time wireless connectivity.
4-4.1 (13) The proposed mobile field reporting application shall have “store and forward”
capabilities (all work is transmitted in both directions and system updates are
downloaded as a connection becomes available, either wireless or hard wire).
City of Fort Collins Page 100 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-4.1 (14) The proposed mobile field reporting application shall have the ability to print the above-
listed forms and reports.
4-4.1 (15) The proposed mobile field reporting application shall have the ability to submit reports
electronically to RMS upon command.
4-4.1 (16) The proposed mobile field reporting application shall have the ability to access and
update submitted reports from the field before report approval.
4-4.1 (17) The proposed mobile field reporting application shall have the ability to access
approved reports from the field.
4-4.1 (18) The proposed mobile field reporting application shall have the ability to write reports
simultaneously with other functions (e.g. electronic dispatch, messaging, inquiries, etc.)
4-4.1 (19) The proposed mobile field reporting application shall have the ability to automatically
populate field reporting with information gathered from an inquiry.
4-5 ARREST PROCESSING 0 0 0 0
4-5.1 (1) The proposed RMS/JMS application shall provide an arrest-processing module for
entering and storing information about persons arrested.
4-5.1 (2) The proposed RMS/JMS application shall have the ability to capture all of the fields
shown on the arrest report included in the Appendix of this RFP.
4-5.1 (3) The proposed RMS/JMS shall have the ability to auto-populate all arrest module
information from a booking at the jail.
4-5.1 (4) The system shall have the ability to assign sequential arrest (booking) numbers
(numbers unique to this individual and this arrest or booking) in the format described
below;
4-5.1 (4.1) alpha/numeric,
4-5.1 (4.2) 12 characters,
4-5.1 (4.3) in the format (YY)(AA)(F)(C)(NNNNNN) where (YY) is the last two digits of the current
year, (AA) is a two letter code for the arresting agency, (F) is a one letter code for
facility (derived by physical location of the entry terminal), (C) is a one letter code
indicating to highest level charge for this arrest, and (NNNNNN) is a six digit sequential
number shared by all agencies that starts over each year.
4-5.1 (5) The arrest number shall be generated by the same routine that provides booking
numbers to the jail (arrest number is the same as booking number and must be unique
across the entire system).
4-5.1 (6) The proposed RMS application shall allow the user to record the following information
about arrested persons:
4-5.1 (6.1) All information contained in the master name record as it was originally entered in this
report (data can not change when the MNI is updated with new information).
4-5.1 (6.2) All information contained in the mugshot module as it was originally entered in this
report.
4-5.1 (6.3) Case (report) number,
4-5.1 (6.4) Booking/arrest number,
4-5.1 (6.5) Arresting officer(s),
4-5.1 (6.6) Reporting officer,
4-5.1 (6.7) Arrest date,
4-5.1 (6.8) Arrest location,
4-5.1 (6.9) Blood alcohol level,
City of Fort Collins Page 101 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-5.1 (6.10) DUI test type given,
4-5.1 (6.11) Injuries or illness,
4-5.1 (6.12) Treated by,
4-5.1 (6.13) Where treated,
4-5.1 (6.14) Treated date and time,
4-5.1 (6.15) Offense location,
4-5.1 (6.16) Offense date and time.
4-5.1 (7) If the arrestee is a juvenile, the RMS shall record the following additional information:
4-5.1 (7.1) Person notified of arrest,
4-5.1 (7.2) How notified,
4-5.1 (7.3) Relationship,
4-5.1 (7.4) Date and time notified
4-5.1 (7.5) Arrestee released to,
4-5.1 (7.6) Relationship,
4-5.1 (7.7) Date and time released.
4-5.1 (8) Dispositions associated with juvenile arrests (i.e. turned over to other agency, felony
filing, etc.)
4-5.1 (9) The proposed RMS system shall allow a minimum of 99 charges records per person
with the following information for each charge:
4-5.1 (9.1) Sequential number for each charge,
4-5.1 (9.2) The charge (ability to select from an agency maintained pick list, charges, by full or
partial charge code or charge description) or;
4-5.1 (9.3) Ability for free text entry of a charge code (override).
4-5.1 (9.3.1) The system shall send an notification to a system administrator that a manual charge
code entry was made.
4-5.1 (9.4) Ability for free text entry of a charge description,
4-5.1 (9.5) A pick list field (per charge) specifically for class of crime (e.g. Felony 1,2,3,4,5,6,
Misdemeanor 1,2,3, Petty Offense 1,2, Etc.),
4-5.1 (9.6) A pick list field (per charge/sentence) specifically for type of charge/sentence (e.g. state
charge, municipal charge, warrant, etc.)
4-5.1 (10) A field (per charge) specifically for the entry of the State of Colorado standardized court
docket/warrant number (for CICJIS linking),
4-5.1 (10.1) The system shall ensure correct entry of state standardized court docket/warrant
number by checking for adherence to correct formatting as defined by the State of
Colorado.
4-5.1 (10.2) Summons number,
4-5.1 (10.3) A pick list field (per charge/sentence) specifically for arresting agency.
4-5.1 (10.4) A field (per charge/sentence) specifically for charging officer.
4-5.1 (11) The system shall store (per charge/sentence) all charge information (code and
description) as displayed (as opposed to only storing a pointer to a table).
4-5.1 (11.1) Number of counts,
4-5.1 (11.2) The IBRS code.
4-5.1 (12) The proposed RMS application shall have the ability to record the use of force by an
officer concerning any arrested person.
City of Fort Collins Page 102 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-5.1 (13) The user shall have the ability to record the type of weapon used during the use-of-
force encounter.
4-5.1 (14) The proposed RMS application shall allow for notification to user-defined individual(s)
when use of force entry is made
4-5.1 (15) If the arrested person does not have a MNI, the proposed RMS application shall
generate a new number.
4-5.1 (16) If the arrestee has a previous record, the system shall auto-populate all empty fields on
the new arrest report upon the user’s command.
4-6 CRIMINAL INVESTIGATION & ANALYSIS
4-6.1 INVESTIGATIONS 0 0 0 0
4-6.1 (1) The proposed RMS application shall support all data fields that currently appear on the
agency’s criminal offense and investigative report forms.
4-6.1 (2) The proposed RMS application shall utilize the shared mapping system described in
Section 2 and Section 3 so as to enable agency personnel to plot and display incidents
and offenses by various parameters on a computerized map.
4-6.1 (2.1) The proposed application shall have the ability to plot incidents and offenses on a map
for any jurisdiction for which the system has a coordinate based geofile.
4-6.1 (2.2) It is preferred that this analysis module include a data animation feature. This feature
would allow the user to find patterns of activity in large data sets by animating or
stepping through activity on successive dates, weeks, months or days of the week. For
example, the analyst might retrieve all robberies for a one year period and then with a
simple command animate the data set so that robberies will display one month at a
time in succession. This would allow the analyst to see how robberies are moving
around and to see if there are any discernable patterns.
4-6.1 (3) The proposed RMS application shall allow the user to select a geographic search area
by drawing a polygon or circle (on a map) with a pointing device.
4-6.1 (3.1) The proposed RMS application shall assist any authorized user with the identification of
crime patterns by:
4-6.1 (3.2) A report which shows rates of offense increase/decrease by patrol district or other area,
4-6.1 (3.3) A report which shows rates of offense increase/decrease by day of week and time of
day,
4-6.1 (3.4) A mapping function that will use colored or shaded maps to show rates of offense
increase/decrease by patrol district or other area graphically on a map.
4-6.1 (4) The proposed RMS application shall have the ability to retrieve cases with similar
modus operandi to assist 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.
4-6.1 (4.1) It is preferred that this function not require advanced training in query languages or
techniques.
4-6.1 (5) The proposed RMS application shall automatically identify cases with similar suspect
descriptions, such as glasses, teeth, speech, demeanor, facial hair, complexion, scars,
marks, tattoos, hair length, hair style, hair color, ethnicity, height, weight, or gender by
searching the mugshot module.
4-6.1 (6) The proposed RMS application shall include the ability to search narrative fields for a
user-defined “string” of text.
City of Fort Collins Page 103 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-6.1 (7) The proposed RMS application shall have the ability to display or print a list of all
individuals associated with a given case sorted by their association with the case and
then alphabetically.
4-6.1 (8) It is desired that the proposed RMS application include a graphical representation of
the association between each listed individual.
4-6.1 (8.1) It is preferred that the proposed RMS application allow a user to retrieve all records for
a given associate by double-clicking on the name, or by some other simple method.
4-6.2 CRIME ANALYSIS 0 0 0 0
4-6.2 (1) The proposed RMS/JMS application shall include a crime analysis module that
provides graphical and statistical tools for analyzing the occurrence of crime and other
reported incidents within Larimer County.
4-6.2 (2) The proposed RMS/JMS application shall provide for the ability to extensively query the
RMS/JMS database without significantly slowing any other function of the system.
4-6.2 (3) The proposed RMS/JMS application shall allow the crime analysts to easily access the
following kinds of information from crime and other reports.
4-6.2 (3.1) Date of the offense, by date range,
4-6.2 (3.2) Time of the offense, by time range,
4-6.2 (3.3) Location where the offense occurred,
4-6.2 (3.4) Type of premises,
4-6.2 (3.5) Description of weapons or tools used,
4-6.2 (3.6) Method and point of entry/exit,
4-6.2 (3.7) Victim data,
4-6.2 (3.8) Suspect data,
4-6.2 (3.9) Reporting party data,
4-6.2 (3.10) Text contained in narrative fields,
4-6.2 (3.11) Clearance type,
4-6.2 (3.12) Description of property stolen,
4-6.2 (3.13) Vehicle(s) involved/stolen description(s),
4-6.2 (3.14) Suspect(s) description(s),
4-6.2 (3.15) or Incident name.
4-6.2 (4) The proposed RMS/JMS application shall allow the crime analyst to set thresholds for
certain kinds of activities (incident types). If the activity threshold is exceeded the
system shall notify the crime analyst. For example, if the crime analyst sets a threshold
for burglaries of five per month the system will send a notice to the analyst if more than
five burglaries are committed in one month.
4-6.2 (5) It is desired that the proposed RMS/JMS application include the ability to provide a
suspect or MO profile for a given offense based on past offenses of the same type. For
example, if the analyst runs a profile report on armed robberies the profile might show
that past robberies have occurred primarily at convenience stores between the hours of
2100 and 0200.
4-6.2 (6) The proposed RMS/JMS application shall allow the crime analyst or other authorized
user to search by one or more physical descriptors, with the results displaying (either
on screen or in printed form) in alphabetical order (defined elsewhere - descriptors to
be range searchable).
City of Fort Collins Page 104 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-7 CASE MANAGEMENT 0 0 0 0
4-7.1 (1) The proposed RMS/JMS application shall provide a variety of management and
analysis tools to:
4-7.1 (1.1) Better manage investigator workloads,
4-7.1 (1.2) And monitor performance.
4-7.1 (2) The proposed case management module shall be tightly integrated with the other
portions of the RMS application. For example, if an investigator updates a case status
in the case management module or changes an offense classification it shall be
reflected in every other proposed module.
4-7.1 (3) The proposed RMS application shall include fields for determining case solvability.
4-7.1 (4) The proposed RMS application shall automatically calculate the solvability of a case by
calculating the solvability factors.
4-7.1 (5) The proposed RMS application shall allow an authorized user to manually override the
automatically determined solvability factor, or assign an overriding priority.
4-7.1 (6) The proposed RMS application shall provide a means of notifying or displaying for
authorized users all cases with a total solvability factor greater than x, where x is a
configuration parameter or is chosen by the user at the time the display command is
invoked.
4-7.1 (7) The proposed RMS application shall allow the Detective Commander or other
authorized user to display all new cases entered for a given date range so that the
commander can review the cases for assignment.
4-7.1 (8) The proposed RMS application shall respond with a summary display which shows the
case (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.
4-7.1 (9) The proposed RMS application shall allow the Detective Commander or other
authorized user to display all active cases by:
4-7.1 (9.1) Assigned investigator,
4-7.1 (9.2) Offense type,
4-7.1 (9.3) Date and time of offense,
4-7.1 (9.4) Aging (how long investigation has been ongoing),
4-7.1 (9.5) Shift,
4-7.1 (9.6) And patrol district,
4-7.1 (9.7) Date of last modification (activity or lack thereof).
4-7.1 (10) The proposed RMS application shall respond with a summary display which shows the
case (report) number, the victim name, the investigator assigned to the case, the
offense type, the status of the case (including the date when the case was last
modified).
4-7.1 (11) The proposed RMS application shall have the ability to track and report case outcomes
and crime statistics on all records which remain in the on-line database.
4-7.1 (12) It shall be possible for the system administrator or other authorized user to configure
the proposed RMS application so that cases are automatically assigned to a specific
investigator based on:
4-7.1 (12.1) Offense location,
4-7.1 (12.2) Or offense type.
City of Fort Collins Page 105 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-7.1 (13) The standard case management display shall include the offense type, the case
(report) number, date and time the incident was reported, location, type of report, and
the solvability rating for each active case.
4-7.1 (14) The proposed RMS application shall enable an authorized supervisor or other
authorized employee to assign a case to a specific investigator or other member of the
Department.
4-7.1 (15) The proposed RMS application shall allow for the assigning of a primary officer on all
cases.
4-7.1 (15.1) If no officer is assigned, the case will automatically be assigned to the primary officer
identified in the CAD record.
4-7.1 (16) The proposed RMS application shall allow a supervisor or other authorized employee
to reassign cases at any time, even after the cases have been closed in CAD.
4-7.1 (17) The proposed RMS application shall enable a supervisor or other authorized employee
to transfer a case to another investigative supervisor or employee for processing.
4-7.1 (18) The proposed RMS application shall enable a supervisor or other authorized employee
to enter a case disposition without first assigning the case to an investigator.
4-7.1 (19) The proposed RMS application shall automatically notify an investigator or other
member of the Department at logon when a new case has been assigned to them for
follow-up.
4-7.1 (20) The proposed RMS application shall allow an investigator to forward a case to the
investigative supervisor for review once the investigator has determined that the case
should be closed.
4-7.1 (21) The proposed RMS application shall allow a case to be closed for the purposes of
IBRS reporting, but remain active for investigation.
4-7.1 (22) The proposed RMS application shall have the ability to allow multiple investigators to
be assigned to and update a single case.
4-7.1 (23) The proposed application shall allow an investigative supervisor or other authorized
user to reassign cases or primary investigator designation at any time.
4-7.1 (24) The proposed RMS application shall allow access by point and click to all forms,
images, and other database items associated with a given case.
4-7.1 (25) The proposed RMS application shall allow an authorized user to add or remove
investigators from a case at any time
4-7.1 (25.1) The system shall maintain an easily displayed history of all assigned investigators.
4-7.1 (26) The proposed RMS application shall allow authorized users to block access into
selected investigations in process.
4-7.1 (27) The proposed RMS application clearly identify juvenile criminal history information.
4-7.1 (28) The proposed RMS application shall automatically classify cases as juvenile cases
when the defendant, on the date that the crime occurred, was a juvenile and process
the cases accordingly.
4-7.1 (29) The proposed RMS application shall have the ability to include juvenile records in all
searches.
4-7.1 (30) The proposed RMS application shall have the ability to identify cases without activity for
a user defined period of time.
4-7.1 (31) At a minimum, the proposed application shall include the following case statuses:
4-7.1 (31.1) Active Case,
City of Fort Collins Page 106 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-7.1 (31.2) Assigned for investigation,
4-7.1 (31.3) Lack of investigative leads (inactive),
4-7.1 (31.4) Suspense,
4-7.1 (31.5) User closure - pending for additional suspect/information,
4-7.1 (31.6) Case being handled by another agency,
4-7.1 (31.7) Unfounded,
4-7.1 (31.8) And civil matter.
4-7.1 (32) It is preferred that the system administrator or other authorized user have the ability to
define new case statuses and closures as needed.
4-7.1 (33) The proposed RMS application shall include the following case dispositions:
4-7.1 (33.1) Adult arrest,
4-7.1 (33.2) Juvenile arrest,
4-7.1 (33.3) Warrant issued,
4-7.1 (33.4) Unfounded,
4-7.1 (33.5) Exceptional clearance,
4-7.1 (33.6) Extradition declined,
4-7.1 (33.7) Death of offender,
4-7.1 (33.8) Victim/witness refused to cooperate,
4-7.1 (33.9) And prosecution declined.
4-7.1 (34) The proposed RMS application shall allow a user to generate a form letter to the
complainants and victims of an offense after the case has been closed.
4-7.1 (35) The proposed RMS application shall have the ability to generate a form letter to a
victim or witness requesting them to call the investigating detective.
4-7.1 (36) The proposed RMS application shall have the ability to cross-reference two or more
cases.
4-7.1 (37) The proposed RMS application shall help investigators to track all activity on a case
including personal interviews, phone calls, letters written and so on by providing a
means of recording the date, time, description and duration of the activity and by
providing a notes field in which the investigator can record information.
4-7.1 (38) It is preferred that the proposed RMS application allow investigators, community and
school resource officers, and others to capture case activities on a Palm or other hand-
held computer and transfer these to the RMS application.
4-7.1 (39) It is preferred that the Palm activity tracking application should include:
4-7.1 (39.1) A field for entering the case (report) number the activity is related to,
4-7.1 (39.2) A field for entering the incident number the activity is related to,
4-7.1 (39.3) A field for the officer or employee making the activity,
4-7.1 (39.4) A field for the address where the activity is being performed,
4-7.1 (39.5) A field to record the name of the person the investigator is interviewing,
4-7.1 (39.6) A field to record the start time and date,
4-7.1 (39.7) A field to record the end time and date,
4-7.1 (39.8) An activity classification list,
4-7.1 (39.9) A project code field so that different activities related to the same project can be
captured,
4-7.1 (39.10) A comment field.
City of Fort Collins Page 107 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-7.1 (40) The proposed investigative system shall allow the investigator to record case notes
without adding these notes to a case via an official departmental report.
4-7.1 (41) The proposed RMS application shall have the ability to list the activities on a case and
provide a total of the time expended.
4-7.1 (42) The proposed RMS application shall allow investigators or other users to add
reminders to each case. These reminders will include a text field and a means to
schedule the reminder date and time.
4-7.1 (42.1) The proposed RMS application shall allow users to track the completion of activities by
including a means of indicating that the reminder was completed or rescheduling it for
another time.
4-7.1 (42.2) It is preferred that the reminder function allow the user to schedule reoccurring notices
and include a user-definable lead time.
4-7.1 (43) The proposed RMS application shall allow any authorized user to view or print out a
complete history of investigators assigned to a case and activities associated with that
case.
4-8 WARRANTS TRACKING 0 0 0 0
4-8.1 (1) The proposed RMS application shall include the ability to enter and track wanted
individuals.
4-8.1 (2) At a minimum, the RMS application will capture the following data elements for a
wanted persons record:
4-8.1 (2.1) All the information contained in the MNI, MLI, & MVI for each wanted person and;
4-8.1 (2.2) Charge,
4-8.1 (2.3) Misdemeanor or felony,
4-8.1 (2.4) Bond type and amount,
4-8.1 (2.5) Fingerprint classification,
4-8.1 (2.6) Vehicle information,
4-8.1 (2.7) State of Colorado standardized warrant number (for CICJIS linking),
4-8.1 (2.7.1) The system shall ensure correct entry of state standardized warrant number by
checking for adherence to correct formatting as defined by the State of Colorado.
4-8.1 (2.8) Warrant status,
4-8.1 (2.9) Issue date,
4-8.1 (2.10) Court,
4-8.1 (2.11) Agency,
4-8.1 (2.12) Case (report) number,
4-8.1 (2.13) Other identifying numbers,
4-8.1 (2.14) Cautions,
4-8.1 (2.15) Miscellaneous field,
4-8.1 (2.16) and Cancellation date.
4-8.1 (3) The proposed RMS application shall include an automatic add/update to CCIC for each
new warrant added to the wanted persons file.
4-8.1 (4) The proposed RMS application shall include an automatic cancel to CCIC for each
warrant canceled in the wanted persons file.
4-8.1 (5) It is preferred that the system be able to import CICJIS warrant data directly into the
system. All CICJIS messaging would be handled electronically as internal messaging
(data would be parsed and drive a system entry/exit process).
City of Fort Collins Page 108 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-8.1 (5.1) System should have a field that indicates CICJIS possession of a warrant (court or
packing agency).
4-8.1 (5.2) It is preferred that the participating agencies would be able to use the RMS to take
possession of a CICJIS warrant.
4-8.1 (5.3) It is preferred that the RMS have some method to track and notify of incomplete CICJIS
warrants.
4-8.1 (6) It is preferred that the system track all warrant locates and then generate and format an
arresting agency response message as well initiate the disposition process.
4-8.1 (7) It is preferred that the system have the ability to do a Department of Revenue
registered owner vehicle query and then to automatically pack the warrant with the
4-9 response. CIVIL SERVICE PROCESS 0 0 0 0
The proposed system must have the capability to track the service, and attempts to
service, civil process papers and court orders processed by the Sheriff's Office. At
minimum the proposed system shall provide the following functionality:
4-9.1 (1) The system must record the agency name, full address, phone and contact person that
any papers are received from for service (tied to location and name master indexes.
4-9.1 (2) The system must record the last possible date and time the papers can be served by
the Sheriff’s Office.
4-9.1 (3) The system must track the officer assigned the papers or order for service.
4-9.1 (4) The system must notify the assigned officer and the civil process personnel as defined
by the agency of any papers or processes that are nearing the last possible date and
4-9.1 (5) time The system (lead time must for record the notification the date and to be time set any by the papers agency)were . received by the Sheriff's
Office.
4-9.1 (6) The system must record the class of service (pick list).
4-9.1 (7) The system must record the type of document (pick list).
4-9.1 (8) The system must record the court of issuance.
4-9.1 (9) The system must record the date the papers were issued by the court.
4-9.1 (10) The system must record the county in which the court of issuance resides.
4-9.1 (11) The system must record the court of issuance case (report) number.
4-9.1 (12) The system must record the person(s) to be served personal demographics (tied to
master name index and specified as to role).
4-9.1 (13) The system must record the person(s) to be served full employment information
including company name, full address and phone number (tied to master name index).
4-9.1 (14) The system must record the best possible location(s) for service including phone
numbers.
4-9.1 (15) The system must record defendant’s personal demographics (tied to master name
index and specified as to role).
4-9.1 (16) The system must record defendant doing business as (specific information on
defendant’s company name).
4-9.1 (17) The system must record plaintiff’s personal demographics (tied to master name index
and specified as to role).
4-9.1 (18) The system must record plaintiff’s relationship to defendant.
4-9.1 (19) The system must allow for multiple defendants for a single plaintiff.
4-9.1 (20) The system must allow for multiple plaintiffs for a single defendant.
City of Fort Collins Page 109 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-9.1 (21) The system must allow for multiple plaintiffs for multiple defendants.
4-9.1 (22) The system must track all attempts for service to include;
4-9.1 (22.1) Date and time of each attempt,
4-9.1 (22.2) Full location information of each attempt (tied to location master index),
4-9.1 (22.3) Time elapsed for each attempt,
4-9.1 (22.4) Mileage driven for each attempt,
4-9.1 (22.5) Officer performing the attempt (tied to master name index),
4-9.1 (22.6) Indicator of last attempt and failure to complete service,
4-9.1 (22.7) Date and time the un-served papers were returned.
4-9.1 (22.8) Person the papers were returned to (tied to master name index and specified as to
role).
4-9.1 (22.9) And the free text comments for each attempt.
4-9.1 (23) The system must track all successful services to include:
4-9.1 (23.1) Indication of service to the defendant, or,
4-9.1 (23.2) Actual person served demographics (tied to master name index and specified as to
role),
4-9.1 (23.3) Actual person served relationship to defendant,
4-9.1 (23.4) Date and time of service,
4-9.1 (23.5) Full service location information (tied to master location index),
4-9.1 (23.6) Time elapsed for service,
4-9.1 (23.7) Mileage driven for service,
4-9.1 (23.8) Officer performing the service (tied to master name index and specified as to role),
4-9.1 (23.9) Free text comments for the service,
4-9.1 (23.10) And the indication of a successful service.
4-9.1 (24) The system must track all funds processing to the agency/person requesting civil
service process to include:
4-9.1 (24.1) Type of transaction (payment or refund),
4-9.1 (24.2) Date and time of any transaction,
4-9.1 (24.3) Amount of payment or refund,
4-9.1 (24.4) Form of payment (cash, check),
4-9.1 (24.5) Check number (issued or received),
4-9.1 (24.6) Person making a payment or receiving a refund (tied to master name index and
specified as to role),
4-9.1 (24.7) Employee completing transaction (viewable as part of the form),
4-9.1 (24.8) Automatic calculation of mileage charges,
4-9.1 (24.9) Tracking of various fees applicable to civil process (eviction fee, service fee, notary fee,
other fees as defined by the agency),
4-9.1 (24.10) Provision for a free text field per fee or charge assessed.
4-9.1 (24.11) Tracking of all unpaid fees and indication of final payment,
4-9.1 (24.12) Automatic notification to the system operator of any unsatisfied debt upon entry of a
new request for service by the same agency or person,
4-9.1 (24.13) And the generation of a detailed invoice and/or receipt.
4-10 PROPERTY AND EVIDENCE MANAGEMENT SYSTEM
4-10.1 GENERAL REQUIREMENTS 0 0 0 0
City of Fort Collins Page 110 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-10.1 (1) The proposed RMS application shall include a comprehensive property and evidence
management system.
4-10.1 (2) At a minimum, the proposed system shall have the ability to track the following kinds of
property:
4-10.1 (2.1) Evidence,
4-10.1 (2.2) Stolen property,
4-10.1 (2.3) Recovered stolen property,
4-10.1 (2.4) Safekeeping,
4-10.1 (2.5) Found property,
4-10.1 (2.6) Seized property, and
4-10.1 (2.7) For Destruction.
4-10.1 (3) In addition to the other fields listed in the user agency forms included in the Appendix,
the proposed system shall include the following information for each property item:
4-10.1 (3.1) Make or brand name,
4-10.1 (3.2) Model,
4-10.1 (3.3) Property type (e.g. Jewelry, currency, firearm, etc.),
4-10.1 (3.4) Size,
4-10.1 (3.5) Weight,
4-10.1 (3.6) Color,
4-10.1 (3.7) Serial number,
4-10.1 (3.8) other identifying number, (owner applied ID, alpha/numeric)
4-10.1 (3.9) License plate number,
4-10.1 (3.10) Caliber,
4-10.1 (3.11) Narrative description,
4-10.1 (3.12) Digital photo or scanned image of property item,
4-10.1 (3.13) Specific location the property was found, recovered or seized from,
4-10.1 (3.14) Name, address and phone number of the person finding the property,
4-10.1 (3.15) Date and time recovered,
4-10.1 (3.16) Individual the evidence was confiscated from, including name, address, telephone
number, and criminal case information (defendants, charges),
4-10.1 (3.17) Name and ID number of the officer(s) receiving, recovering or seizing the property,
4-10.1 (3.18) Name, address, and phone number of the property owner,
4-10.1 (3.19) Case (report) number,
4-10.1 (3.20) Evidence tag number (number and barcode),
4-10.1 (3.21) Date and time entered,
4-10.1 (3.22) Retention review dates,
4-10.1 (3.23) Which court (i.e. County, Municipal or District), and
4-10.1 (3.24) Temporary storage location.
4-10.1 (4) It is preferred that the proposed RMS application include a vehicle diagram for
automobile records or the ability to attach a digital photo so that existing damage to the
property can be recorded.
4-10.1 (5) The proposed system shall support a cash receipts journal.
4-10.2 EVIDENCE ENTRY AND PROCESSING 0 0 0 0
City of Fort Collins Page 111 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-10.2 (1) When a new property record is entered, the proposed RMS application shall
automatically check by serial number and/or property type to see if the items have been
entered into the system previously (e.g. it has been reported stolen).
4-10.2 (2) The proposed RMS application shall assign a unique case-related property ID number
to each item of property entered into the system.
4-10.2 (3) The proposed RMS application shall allow officers and employees to enter property
records either from a desktop workstation or from the field.
4-10.2 (4) The proposed RMS application shall allow the evidence technician/custodian to reject
improperly packaged property or inappropriate property logged in by officers.
4-10.2 (4.1) If the property is rejected, the system shall allow for notification to the officer that the
property has been rejected.
4-10.2 (5) The proposed RMS application shall offer a method so that when a user is required to
enter multiple property items, the user shall not be required to enter repetitive the same
information more than one time.
4-10.2 (6) The proposed RMS application shall upon user request format and send an inquiry to
the pawn system and to CCIC for each new property record and name that is entered
into the system.
4-10.2 (7) The proposed RMS application shall include the ability to print a label that includes at a
minimum:
4-10.2 (7.1) Case (report) number,
4-10.2 (7.2) Name and number of officer recovering the property,
4-10.2 (7.3) Item number,
4-10.2 (7.4) Date and time collected,
4-10.2 (7.5) Owner’s name, and
4-10.2 (7.6) Bar code for every item of property.
4-10.2 (8) When printing a label for a package containing drugs, the label shall include at a
minimum:
4-10.2 (8.1) The property description,
4-10.2 (8.2) and Weight of contents.
4-10.2 (9) The proposed RMS application shall allow evidence technicians or other authorized
user to print specified property labels in a batch mode once they have finished entering
property either in the field or at the station.
4-10.2 (10) The proposed RMS application shall have the ability to read the bar code on a property
label and retrieve the property record without additional information.
4-10.2 (11) The proposed RMS application shall include the ability to record a court disposition for
each property item.
4-10.2 (12) Once a court disposition has been recorded for a case, the system shall generate a
final disposition request and electronically send that request to the investigating officer
and evidence technician.
4-10.2 (13) The proposed RMS application shall allow an authorized user to generate/print a form
letter to the listed owner of the property for cases that have a final disposition status.
4-10.2 (14) The proposed RMS application shall include the ability to record the following
information for non-departmental personnel who are claiming property:
4-10.2 (14.1) All information contained in the master name record,
4-10.2 (14.2) Form of identification,
City of Fort Collins Page 112 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-10.2 (14.3) Digital signature,
4-10.2 (14.4) and Digital photograph.
4-10.2 (15) The proposed RMS application shall allow the evidence technician or other authorized
users to retrieve property items that are unclaimed for an agency defined period and
generate/print a form letter to the listed owner of the property.
4-10.2 (16) The proposed RMS application shall include a report that lists case (report) numbers of
property items which are releasable but which have not been picked up within user-
defined number of days of the listed owner’s notification.
4-10.2 (17) The proposed RMS application shall allow the system administrator or other authorized
user to limit property record editing to authorized employees assigned to the evidence
vault.
4-10.3 PROPERTY ADMINISTRATION 0 0 0 0
4-10.3 (1) At a minimum, the proposed application shall include the following agency defined
property status classifications per item:
4-10.3 (1.1) Destruction,
4-10.3 (1.2) Auction,
4-10.3 (1.3) Conversion,
4-10.3 (1.4) Evidence,
4-10.3 (1.5) Evidence hold,
4-10.3 (1.6) Evidence release,
4-10.3 (1.7) Stolen property,
4-10.3 (1.8) Recovered stolen property,
4-10.3 (1.9) Safekeeping,
4-10.3 (1.10) Found property,
4-10.3 (1.11) Damaged,
4-10.3 (1.12) Seized property, and
4-10.3 (1.13) Lab hold.
4-10.3 (2) The system shall be able to automatically calculate the retention review dates by
offense type or allow for manual adjustment/entry at the user’s discretion on a per item
basis.
4-10.3 (3) The proposed RMS application shall allow for the evidence technician or other
authorized user to print reports based on the retention review dates.
4-10.3 (4) Once the retention date has been reached, the case officer and evidence technician
shall be notified via an internal system message or auto-generated report/email.
4-10.3 (4.1) Case officer notification shall become a part of a workflow process that mandates a
response from the officer to the evidence technician.
4-10.3 (5) The proposed RMS application shall maintain a “chain of custody” record for every
piece of property under departmental control such that the date, time, releasing and
receiving members’ identification shall be recorded every time the custody of a property
item is changed.
4-10.3 (6) The proposed RMS application shall allow the users to track when property is checked
out by a law enforcement or authorized representative of another jurisdiction.
4-10.3 (7) The proposed system shall offer the user an easy way to retrieve a property record and
transfer custody of the article to another member of the department or a citizen.
City of Fort Collins Page 113 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-10.3 (8) In order to facilitate the transfer of custody, the system shall allow the evidence
technician or other authorized user to retrieve and assemble a list of property items and
then transfer custody of all items on the list at one time.
4-10.3 (9) In order to facilitate the return of property to the evidence vault, the system shall allow
the evidence technician or other authorized user to retrieve all items in the custody of a
particular officer and select from this list which items are being returned to the evidence
vault.
4-10.3 (9.1) The system shall then mark all these items as returned at the same date and time.
4-10.3 (10) The proposed system shall allow the evidence technician or other authorized user to
designate another employee as the authority for releasing property as required.
4-10.3 (11) The proposed system shall have the ability to track the physical location of property
items while they are stored in the evidence vault or at satellite facilities. At a minimum,
the location record shall include:
4-10.3 (11.1) A facility name or number (i.e. FCPS, LCSO, CBI, FBI, Etc.) (both pre-defined pick list
and free text),
4-10.3 (11.2) A room name or number (i.e. evidence room, lab, clandestine lab storage) (both pre-
defined pick list and free text),
4-10.3 (11.3) A sub locator (i.e. rack, drug box, refrigerator, safe, etc.) (pre-defined pick list to be
limited by room selection),
4-10.3 (11.4) and A sub/sub locator (i.e. bin, space, shelf, drawer) (pre-defined pick list to be limited
by sub locator selection).
4-10.3 (12) The proposed RMS application shall have the ability to support a final disposition
record for all property items that includes the date, time, and disposition.
4-10.3 (12.1) It is preferred that the proposed RMS application have the ability to process final
disposition with some type of batch process.
4-10.3 (13) The proposed RMS application shall allow the officers responsible for the evidence to
mark it for release to the owner, destruction, auction, or conversion on the computer on
a per item basis.
4-10.4 LABORATORY EXAMINATION 0 0 0 0
4-10.4 (1) The system shall have the ability to track and report laboratory examination processes
by capturing the minimum of the following information for each item processed by the
lab:
4-10.4 (1.1) Case (report) number,
4-10.4 (1.2) Item number,
4-10.4 (1.3) Item condition before,
4-10.4 (1.4) Item condition after,
4-10.4 (1.5) Process type (up to 99 per item),
4-10.4 (1.6) Process start date and time (per process type),
4-10.4 (1.7) Process end date and time (per process type),
4-10.4 (1.8) Task type (up to 99 per process type),
4-10.4 (1.9) and Narrative per task.
4-10.4 (2) Lab results as tracked in this module shall have the ability to be routed electronically to
the reporting officer, collecting officer, and any other designated person.
4-10.4 (3) Reports shall include:
4-10.4 (3.1) Case (report) number,
City of Fort Collins Page 114 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-10.4 (3.2) Item number,
4-10.4 (3.3) Item condition after,
4-10.4 (3.4) Processes performed (all for each item),
4-10.4 (3.5) Tasks performed (all for each process),
4-10.4 (3.6) and All narratives (for each task).
4-10.4 (3.7) Lab results as tracked in this module shall have the ability to be grouped by case
(report) number and routed en-mass electronically to the reporting officer, collecting
officer, and any other designated person.
4-11 VICTIM’S RESPONSE MODULE 0 0 0 0
4-11.1 (1) The proposed system must have a Victim’s Response module that fully supports the
tracking of all victims of crime that includes the ability to interface to the state VOICE
system and at minimum collects all data required by all facets of that system.
4-12 COMMUNITY POLICING SUPPORT SYSTEM 0 0 0 0
4-12.1 (1) The proposed RMS application shall include functions designed to support community-
policing efforts.
4-12.1 (2) The proposed RMS application shall allow an authorized user to assign a project code
to any community policing or other special project.
4-12.1 (3) The proposed RMS application shall allow the user agency to track all activity and
efforts associated with a community policing project by allowing officers to add the
project code to incident reports, follow-up investigations, arrests, and all other
associated activities.
4-12.1 (4) The proposed RMS application shall include a log for recording community policing
efforts by the user agency. This log shall be similar to the investigator’s activity log in
that it will record activities that are not captured by the CAD system.
4-12.1 (5) At a minimum, the activity log will record the following information:
4-12.1 (5.1) The activity code,
4-12.1 (5.2) The project code,
4-12.1 (5.3) The date and time of the activity,
4-12.1 (5.4) The duration of the activity,
4-12.1 (5.5) The location of the activity,
4-12.1 (5.6) The name of the user conducting the activity,
4-12.1 (5.7) The classification of the activity,
4-12.1 (5.8) A notes field for recording additional information about the activity.
4-12.1 (6) At a minimum, the proposed RMS application shall have the ability to maintain a log of
community policing efforts by category and location.
4-12.1 (7) The proposed RMS application shall have the ability to maintain a list of community
members involved in neighborhood watch or other community policing initiatives. At a
minimum, this list shall include the following data elements:
4-12.1 (7.1) Community member’s full name,
4-12.1 (7.2) Up to four telephone numbers,
4-12.1 (7.3) Up to two email addresses, and
4-12.1 (7.4) Up to four user-defined fields for defining the community member’s subjects of interest.
4-12.1 (8) The proposed RMS application shall have the ability to send form letter or email
mailings to some or all of the persons listed in the neighborhood watch list.
City of Fort Collins Page 115 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-12.1 (9) It is preferred that the proposed RMS application include the ability to receive tips on
crime, quality of life problems and disorder from an HTML form.
4-12.1 (10) It is preferred that the proposed RMS application allow the user to capture emails and
messages for crime prevention and school resource officers submitted through the user
agency web site.
4-12.1 (10.1) The receiver should be able to add a project code to any message received in this
manner.
4-13 CRIME REPORTING REQUIREMENTS 0 0 0 0
4-13.1 (1) The proposed RMS application shall have the ability to satisfy the State of Colorado
requirements for the Colorado Incident Based Reporting System (IBRS) and the
National Incident Based Reporting System (NIBRS).
4-13.1 (2) The proposed RMS application shall edit records for IBRS/NIBRS validity and
consistency as prescribed by the Colorado Bureau of Investigation (CBI).
4-13.1 (3) The proposed RMS application shall have the ability to transmit IBRS/NIBRS reports to
CBI electronically or via magnetic media.
4-13.1 (4) The proposed RMS application shall be able to maintain, at a minimum, fifteen years of
incident based reporting (IBRS/NIBRS) data on the user agency system for analytical
and statistical reporting purposes.
4-13.1 (5) The proposed RMS application shall allow authorized users to reclassify prior incidents.
4-13.1 (6) The proposed RMS application shall report the correct statistical counts for crimes and
events even when a case is changed. For example, assume the user agency had one
homicide last quarter and none this quarter. Then assume that the classification for the
homicide last quarter is changed to accidental death. The homicide count for this
quarter and last quarter should both show zero.
4-13.1 (7) The proposed RMS application shall include a statistical report of IBRS/NIBRS
offenses by offense type for hard copy.
4-13.1 (8) The proposed RMS application shall include the capability to display or print individual
records.
4-13.1 (9) The proposed RMS application shall have the ability to print IBRS/NIBRS reports in the
same format as all of the reports distributed by the CBI for comparison purposes.
4-13.1 (10) The proposed RMS application shall include the following internal reports:
4-13.1 (10.1) Arson Report,
4-13.1 (10.2) Homicide Report,
4-13.1 (10.3) Use of Force,
4-13.1 (10.4) Arrest & Citation Log,
4-13.1 (10.5) Arrested Persons (adult and juvenile) by Age, Gender, Ethnicity and Charge,
4-13.1 (10.6) Hate Crimes,
4-13.1 (10.7) Domestic Violence,
4-13.1 (10.8) Property stolen, by classification and type,
4-13.1 (10.9) Law Enforcement Officers Killed and Assaulted,
4-13.1 (10.10) and Property recovered tally – theft tally, motor vehicle theft tally.
4-13.1 (11) The proposed RMS application shall include the capability to display or print any of the
above-listed reports.
4-14 MISCELLANEOUS APPLICATIONS
4-14.1 PAWN MODULE 0 0 0 0
City of Fort Collins Page 116 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-14.1 (1) The proposed RMS application shall include the ability to capture all CBI-required fields
and formats for pawn tickets.
4-14.1 (2) Each time a new pawn record is entered, the Pawn module shall automatically
compare the pawned item against the RMS files to determine if the item has been
previously reported stolen.
4-14.1 (3) The proposed RMS application shall be able to enter and track a pawn ticket number
assigned by individual pawnbrokers.
4-14.1 (4) The proposed RMS application shall be able to enter and track the pawn shop and
pawnbroker where item is pawned.
4-14.1 (5) The proposed RMS application shall be able to enter and track police holds by:
4-14.1 (5.1) Case (report) number
4-14.1 (5.2) Date of hold
4-14.1 (5.3) Officer placing hold
4-14.1 (5.4) Pawnbroker notified of hold
4-14.1 (5.5) Hold expiration date to be configurable by System Admin
4-14.1 (6) It is desired that the proposed RMS application 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.
4-14.1 (7) The proposed RMS application shall have the ability to automatically transmit pawn
records (property and name information) via the interface to CBI to check for stolen.
4-14.1 (8) The proposed RMS application shall have the ability to automatically record an
acknowledgement for each record from CBI.
4-14.1 (9) It is desired that the proposed RMS application have the ability to enter Pawn
information into the article file in CCIC when entered into the RMS system.
4-14.1 (10) It is desired that the proposed RMS application have the ability to accept pawn tickets
from pawnshops electronically.
4-14.1 (11) The proposed RMS application shall include the capability to print or display a list of
potential matches of stolen property against Pawn module records.
4-14.1 (12) The proposed RMS application shall include the following Pawned Property Reports:
4-14.1 (12.1) A one-line 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.
4-14.1 (12.2) A list of frequent (threshold of frequency user definable) pawners, sorted in descending
order by the number of items pawned.
4-14.1 (13) It is desired that the proposed RMS application reject or make some type of notification
that the person pawning the property is under the age of 18 on the date of pawn.
4-14.1 (14) It is desired that the proposed RMS application identify individuals who use a
pawnshop more than once a day or any pawnshop more than four times per week.
4-14.1 (14.1) Time parameters (thresholds) for alerts shall be user configurable
4-14.1 (14.2) Once the identification is made, it is desired that the proposed RMS application shall
make some type of notification to a user-defined individual(s).
4-14.1 (15) The proposed RMS application shall have the ability to generate report listing all out of
area pawners.
4-14.1 (16) The proposed RMS application shall track all pawn forfeiture reports.
4-14.1 (17) The proposed RMS application shall have the ability to track pawners prohibited by
court order or city ordinance.
City of Fort Collins Page 117 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-14.2 TOWING AND IMPOUNDMENT RECORDS 0 0 0 0
4-14.2 (1) The proposed RMS application shall maintain a file of all vehicles that have been towed
or impounded by the user agency or local tow companies.
4-14.2 (2) The proposed RMS application shall allow an officer to complete the tow report directly
from a mobile computer, when connection available, and send it to a tow company via a
fax modem accessible from the RMS server.
4-14.2 (3) At a minimum the tow record shall include the:
4-14.2 (3.1) All the information contained in the MNI, MLI, & MVI for each towed vehicle and;
4-14.2 (3.2) Case (report) number,
4-14.2 (3.3) Notes, e.g. Previous damage to the vehicle,
4-14.2 (3.4) Location where vehicle was towed from,
4-14.2 (3.5) List of property in vehicle,
4-14.2 (3.6) Reason for towing,
4-14.2 (3.7) Civil seizure (yes or no),
4-14.2 (3.8) Police hold (yes or no),
4-14.2 (3.9) Name of employee authorizing release of vehicle,
4-14.2 (3.10) Release date and time,
4-14.2 (3.11) Person to which vehicle was released,
4-14.2 (3.12) Name of towing company,
4-14.2 (3.13) Storage location,
4-14.2 (3.14) Date and time tow occurred,
4-14.2 (3.15) and Officer ordering tow or receiving notification of tow.
4-14.2 (4) In the event that a vehicle is towed in conjunction with a case, the tow record shall be
linked to the case record and shall be retrievable by a case (report) number search.
4-14.2 (5) The proposed RMS application shall allow the entry person to request a check of
CCIC/NCIC to determine if the towed vehicle has been reported stolen in another
jurisdiction.
4-14.2 (6) The proposed RMS application shall have the ability to format and send an update
message to CCIC each time a new vehicle is entered as towed or impounded.
4-14.2 (7) The proposed RMS application should include the ability to attach the CCIC/NCIC
return to the tow record.
4-14.3 FIELD INTERVIEW 0 0 0 0
4-14.3 (1) The proposed RMS application shall include a module that will be used to enter field
interview information.
4-14.3 (2) The Field Interview module will interface with the master indexes such that persons
entered into the Field Interview module will be found by name, location or other master
index searches.
4-14.3 (3) At a minimum, the Field Interview module shall include the following data fields:
4-14.3 (3.1) Unique system-generated number or case (report) number,
4-14.3 (3.2) All the information contained in the MNI, MLI, MVI, mugshot module, and offender
module for each person contacted and;
4-14.3 (3.3) Officer name, ID and role
4-14.3 (3.4) Reason individual was contacted,
4-14.3 (3.5) Location where individual was contacted,
City of Fort Collins Page 118 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-14.3 (3.6) Date and time individual was contacted,
4-14.3 (3.7) and Narrative.
4-14.3 (4) FI form shall be configurable to retain data entry in fields when form is submitted to the
system when several individuals are contacted (i.e., same date, time, location, etc.)
4-14.4 LICENSES 0 0 0 0
4-14.4 (1) The proposed RMS application shall include a license module that can be used to track
bicycles, guns, concealed weapons permits, and other items.
4-14.4 (2) The proposed RMS application shall assign a unique license number by license type
for each new record that is entered.
4-14.4 (3) At a minimum, the license record shall include the following data fields:
4-14.4 (3.1) All the information contained in the MNI, MLI, & MPI, for each license issued and;
4-14.4 (3.2) License type, (e.g. Gun, Liquor, CCW, etc.)
4-14.4 (3.3) Associated property records,
4-14.4 (3.4) Registration date,
4-14.4 (3.5) and Expiration date.
4-14.4 (4) The proposed RMS application shall have the ability to check CCIC/NCIC upon entry of
an item being licensed (bike, gun, etc.) to determine if the item is listed as stolen in
another jurisdiction.
4-14.5 BICYCLE REGISTRATION 0 0 0 0
Bicycle registrations and licensing are entered and maintained through this module.
4-14.5 (1) The proposed RMS application shall include the ability to capture all designated fields
for bicycle registrations to include the following:
4-14.5 (1.1) All the information contained in the MNI, MLI, & MPI for each bicycle registered and;
4-14.5 (1.2) A person role as owner,
4-14.5 (1.3) Date of Registration,
4-14.5 (1.4) Registration duration (time to expire),
4-14.5 (1.5) Registration Number,
4-14.5 (1.6) Associated property record,
4-14.5 (1.7) Bicycle Frame Style,
4-14.5 (1.8) Bicycle Frame Size,
4-14.5 (1.9) and A Narrative Field for a more complete description and to list distinguishing features.
4-14.5 (2) In addition, it is desired the system include the ability to attach images (i.e. digital
photos) corresponding to each registration.
4-14.5 (3) When the bicycle serial number is entered, the bicycle registration module shall
automatically compare the bicycle against the MPI to determine if the bicycle has
previously been entered into the system and then to notify the entry person of the types
of involvement.
4-14.5 (4) When a bicycle serial number is entered, it is desired that system would be able to
check the serial number through NCIC/CCIC files for stolen entries.
4-14.5 (5) The system must also be able to perform serial number searches for registration
checks of suspected stolen bicycles.
4-14.5 (6) The bicycle information shall become part of the MPI.
4-14.5 (7) Participating agencies using this module shall be able to determine their own beginning
registration number.
City of Fort Collins Page 119 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-14.5 (8) The proposed RMS application shall provide a single query that will return a list of all
expired bicycle registrations.
4-14.5 (9) It is desired that written warnings for bicycle traffic violations be capable of being
entered in a similar manner as vehicular traffic warnings.
4-14.5 (10) It is desired that the system have the ability to be changed over to a bar coding system
if the registering agency so desires. This system should include:
4-14.5 (10.1) Ability to print individual labels (licenses) including the registration number and a bar
code matching the registration number.
4-14.5 (10.2) Ability to read a barcode from a driver's license or student registration card for owner
information which will automatically be downloaded into the registration record.
4-14.5 (11) The system shall have the ability to provide a bicycle registration list by name, serial
number, license number, frame number, and date range (either registration date or
expiration date).
4-14.6 ALARM TRACKING 0 0 0 0
4-14.6 (1) The proposed RMS application shall include an alarm registration and false alarm
tracking module.
4-14.6 (2) At a minimum, the alarm registration record shall include the following data fields:
4-14.6 (2.1) The location where the alarm is installed.
4-14.6 (2.2) The name, address and phone number for the owner(s) of the premises,
4-14.6 (2.3) The name, address and telephone number for the person(s) or firm(s) responsible for
responding when an alarm sounds
4-14.6 (2.4) The name, address and telephone number for the person(s) or firm(s) responsible for
maintaining the alarm,
4-14.6 (2.5) The registration expiration date,
4-14.6 (2.6) The type of alarm (silent, audible, etc.),
4-14.6 (2.7) and A unique alarm registration number for each record.
4-14.6 (3) The proposed RMS application shall have the ability to receive alarm activation reports
from the CAD application.
4-14.6 (4) The proposed RMS application shall have the ability to retrieve alarm activations by:
4-14.6 (4.1) Alarm location,
4-14.6 (4.2) Business name
4-14.6 (4.3) Building owner name(s),
4-14.6 (4.4) Name of person(s) responsible for maintaining the alarm, and
4-14.6 (4.5) Number of activations for a given date range
4-14.6 (5) The proposed RMS application shall include the ability to record the collection of alarm
registration fees.
4-14.6 (6) The proposed RMS application shall include the ability to print and send violation
notices to the owners’ of buildings whose properties have had more than a user-
defined number of false alarms in a user-defined date range.
4-14.6 (7) The proposed RMS application shall include basic case management procedures for
false alarm violations. (It is acceptable to use the standard case management module.
If this is proposed, explain how it will work.)
4-14.6 (8) The proposed RMS application shall allow for incident transfer from CAD of dispatched
incidents identified as false alarms.
4-15 RMS REPORTS
City of Fort Collins Page 120 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-15.1 CRIME AND EVENT REPORTS 0 0 0 0
4-15.1 (1.1) The proposed RMS application shall allow for printing of all records associated with a
user-defined name. At a minimum, the following information should print:
4-15.1 (1.2) Name,
4-15.1 (1.3) Date of birth,
4-15.1 (1.4) Current address,
4-15.1 (1.5) Current telephone number,
4-15.1 (1.6) Physical description,
4-15.1 (1.7) Alias or AKA,
4-15.1 (1.8) All contacts associated with individual,
4-15.1 (2) The proposed RMS application shall allow for the following to print on all reports printed
(i.e. case reports, master name searches, master vehicle searches, etc.):
4-15.1 (2.1) Agency name,
4-15.1 (2.2) Agency address,
4-15.1 (2.3) Agency telephone number,
4-15.1 (2.4) Date,
4-15.1 (2.5) Time, and
4-15.1 (2.6) Name of user logged on to system at time of print.
4-15.1 (3) The proposed RMS application shall include the ability to print a copy of any crime or
event (e.g. traffic accident) report.
4-15.1 (4) Crime and event reports shall be conspicuously marked “Unapproved” in the event that
the responsible supervisor has not approved the report at the time it is printed.
4-15.1 (5) The proposed RMS application shall include a Juvenile Offense Summary report which
provides a summary of offenses involving juveniles but which does not identify juvenile
defendants.
4-15.1 (6) The proposed RMS application shall include a report listing offenses and calls for
service by address or by user-defined map location.
4-15.1 (7) The proposed RMS application shall include an incident log that shall print a list of
complaints with the time, nature, and case (report) number, if any, for a user-defined
date.
4-15.1 (8) The proposed RMS application shall include a Summary of Offenses Report that
provides a summary of each offense including the date, time, type, location of
occurrence, and status of each offense for a user- defined date range.
4-15.2 INVESTIGATIVE & CRIME ANALYSIS REPORTS 0 0 0 0
4-15.2 (1) The proposed RMS application shall include the ability to provide periodic and
comparative crime statistics by offense type.
4-15.2 (2) The proposed RMS application shall include statistical reports of incidents and crimes
by:
4-15.2 (2.1) User-defined address,
4-15.2 (2.2) Patrol district,
4-15.2 (2.3) Any geographic area defined in the mapping system,
4-15.2 (2.4) Any user-defined geographic area,
4-15.2 (2.5) Day of week,
4-15.2 (2.6) Time range,
4-15.2 (2.7) Date range, or
City of Fort Collins Page 121 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-15.2 (2.8) Any combination of the above.
4-15.2 (3) The proposed RMS application shall include a report that lists all calls for service or
crimes occurring during a user-defined date range sorted by patrol area.
4-15.2 (4) The proposed RMS application shall include an Offense Comparison Report which lists
crimes by state statute or IBRS code, by month with comparisons with prior month and
same month prior year, and year to date totals.
4-15.2 (5) The proposed RMS application shall include a report that shows locations that are
experiencing the calls for service or crimes that exceed a user-defined threshold for a
user-defined date range (Hot Spot/Exception Report).
4-15.2 (6) The user shall be able to define the radius or proximity inside which all addresses will
be considered a single address when searching for hot spots. For example, 123 Main
Street might be within two blocks of 1st and Main and therefore they should be
considered the same address for hot spot reporting purposes.
4-15.2 (7) The proposed RMS application shall have the ability to plot the results of any search on
a map so long as the result of the search includes addresses that are in the geofile.
4-15.2 (8) The proposed RMS application shall include the ability to add a graph or chart to any
report that contains statistical data.
4-15.3 CASE MANAGEMENT REPORTS 0 0 0 0
4-15.3 (1) The proposed RMS application shall include a report showing all active cases sorted by
assigned investigator or officer with offense type and case (report) number included
(Cases by Investigator).
4-15.3 (2) The proposed RMS application shall include a report showing all active cases sorted by
offense type with the assigned officer, and case (report) number included (Cases by
Type).
4-15.3 (3) The proposed RMS application shall include a report that shows the cases closed for a
given date range sorted and subtotaled by investigator (Case Closure Report).
4-15.3 (4) The proposed RMS application shall include a report that shows the cases closed for a
given date range sorted and subtotaled by organizational unit (Case Closure Report -
Unit)
4-15.3 (5) The proposed RMS application shall include a report that shows a statistical
comparison of closures for all investigators during a user-defined date range
(Clearance Report).
4-15.3 (6) The proposed RMS application shall include a report which lists the assigned
investigator and case (report) number for each active case which is 30, 60, or 90+ days
old or other user-defined parameter (Case Aging Report).
4-15.3 (7) The proposed RMS application shall include a report that provides a summary of all
investigative actions taken on each active case during a user-defined period. This
report shall be for one or more officers at the users discretion (Case Status Report).
4-15.3 (8) The proposed RMS application shall include a report which details, by investigator or
other employee and date range, a count of assigned and closed reports and the ratio of
closed to assigned cases (Case Management Report).
4-15.3 (9) The proposed RMS application shall include a report that lists the property associated
with a case. This report shall include a summary description of the property and a
status (stolen, recovered, evidence, etc.) for each item.
4-15.3 (10) The proposed RMS application shall include a report that lists all pending or
unapproved reports for a given officer or unit, and date range (Pending Reports).
City of Fort Collins Page 122 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-15.3 (11) The proposed RMS application shall have the ability to print an audit trail report
showing all actions concerned with a case from beginning to end, including preliminary
investigative efforts made by patrol.
4-15.3 (12) The proposed RMS application shall provide an easy means to close a case in the
event that a suspect is arrested by another jurisdiction.
4-15.3 (13) The proposed RMS application shall include a report that details each investigative
action completed for a given case with the total time expended on the report.
4-15.3 (14) The proposed RMS application shall include a report that details the investigative time
allocated to a given case subtotaled by officer or investigator.
4-15.3 (15) The proposed RMS application shall include a report that shows the total investigative
time expended for a user-defined officer and date range, subtotaled by case (report)
number.
4-15.3 (16) The proposed application shall include the ability for investigators to print all notes
associated with a case at one time.
4-15.3 (17) The proposed application shall include a report that allows an individual user to print
any reminders associated with a case to which they are assigned. At a minimum, the
report shall include:
The case (report) number,
Defendant or complainant’s name,
The reminder date,
The reminder text, and
Status.
4-15.4 ARREST REPORTS 0 0 0 0
4-15.4 (1) The proposed RMS application shall include a report that provides a statistical
breakdown of adult arrests by crime category with month-to-date and year-to-date
comparisons.
4-15.4 (2) The proposed RMS application shall include a report that provides a statistical
breakdown of juvenile arrests by crime category with month-to-date and year-to-date
comparisons.
4-15.4 (3) This report shall include case disposition, case (report) number, and court disposition.
4-15.5 PROPERTY AND EVIDENCE REPORTS 0 0 0 0
4-15.5 (1) The proposed RMS application shall include a listing of all property in the database by
storage location.
4-15.5 (2) The proposed RMS application shall include a listing of all property by seizing or
recovering officer.
4-15.5 (3) This report shall include the case (report) number and disposition if available.
4-15.6 TRAFFIC REPORTS 0 0 0 0
4-15.6 (1) The proposed system shall include a summary report of citations issued by:
4-15.6 (1.1) User specified officer for a given date and time range,
4-15.6 (1.2) User specified squad, for a given date and time range,
4-15.6 (1.3) User specified district for a given date and time range,
4-15.6 (1.4) User specified shift for a given date and time range,
4-15.6 (1.5) For all officers for a given date and time range,
4-15.6 (1.6) Offense location for a given date and time range, or
4-15.6 (1.7) Offense type for a given date and time range.
4-15.3 (17.1.1)
4-15.3 (17.1.2)
4-15.3 (17.1.3)
4-15.3 (17.1.4)
4-15.3 (17.1.5)
City of Fort Collins Page 123 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-15.6 (2) The proposed system shall provide a statistical summary of citation activity by:
4-15.6 (2.1) User specified officer for a given date and time range,
4-15.6 (2.2) User specified squad, for a given date and time range,
4-15.6 (2.3) User specified district for a given date and time range,
4-15.6 (2.4) User specified shift for a given date and time range,
4-15.6 (2.5) For all officers for a given date and time range,
4-15.6 (2.6) Offense location for a given date and time range, or
4-15.6 (2.7) Offense types for a given date and time range.
4-15.6 (3) The proposed system shall include a summary report of accidents by:
4-15.6 (3.1) Location,
4-15.6 (3.2) District, or
4-15.6 (3.3) Other geofile supported polygon.
4-15.6 (3.4) Other geofile user-defined parameter
4-15.6 (4) The proposed system shall include, but not be limited to, reports showing the:
4-15.6 (4.1) Total number of accidents for a user-defined date and time range,
4-15.6 (4.2) Total number of personal injuries as a result of accidents, and
4-15.6 (4.3) Total number of accidents per location within any jurisdiction based upon a user-
defined date and time range.
4-15.6 (5) The proposed RMS application shall include a summary and a detail report of all Fatal
Accidents occurring in a user-defined area or location, during a user-defined date
4-15.6 (6) range. The proposed RMS application shall include a report listing accidents by cause in a
user-defined area and during a user-defined date and time range.
4-15.6 (7) The proposed RMS application shall include a report that shows all locations in which
accidents exceed a user-defined number for a user-defined date and time range.
4-15.7 POLICE MANAGEMENT REPORTS 0 0 0 0
4-15.7 (1) The proposed RMS application shall support continual improvement of police
operations and administration by providing periodic reports of division and
departmental performance, providing both current statistical and historical data in
tabular and graphic formats.
4-15.7 (2) The proposed RMS application should include the following monthly and year-to-date
frequency counts for patrol:
4-15.7 (2.1) Citations,
4-15.7 (2.2) Warnings,
4-15.7 (2.3) Arrests by type,
4-15.7 (2.4) Juvenile arrests,
4-15.7 (2.5) Adult arrests,
4-15.7 (2.6) Field interrogations,
4-15.7 (2.7) Reported felonies,
4-15.7 (2.8) Reported misdemeanors, and
4-15.7 (2.9) Seized items and value.
4-15.7 (3) The proposed RMS application shall include the following performance reports for
4-15.7 (3.1) patrol: Average en route time to calls for service by shift,
4-15.7 (3.2) Average en route time to calls for service by district,
City of Fort Collins Page 124 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
4-15.7 (3.3) Average en route time to calls for service by priority,
4-15.7 (3.4) Average en route time by officer,
4-15.7 (3.5) Average on scene time by shift,
4-15.7 (3.6) Average on scene time by district,
4-15.7 (3.7) Average on scene time by officer,
4-15.7 (4) Report parameters in 13.9.3 shall be reportable by any or all parameters
4-15.7 (5) The proposed RMS application shall include the following reports for investigations:
4-15.7 (5.1) Average crime clearances by shift, and
4-15.7 (5.2) Average crime clearances by officer or investigator.
4-15.7 (5.3) Average crime clearances by unit (investigations, SIU, etc)
4-15.7 (6) The proposed RMS application shall have the ability to create a daily activity report
showing the calls for service, investigative activities and other system recorded actions
taken by an officer for a given shift.
4-15.7 (7) The proposed RMS application shall include a report showing a summary of the report
submission and review process for a specific report including the following events:
4-15.7 (7.1) The date and time the report was first assigned,
4-15.7 (7.2) The date and time it was modified by records,
4-15.7 (7.3) The date and time it was submitted review,
4-15.7 (7.4) Each date and time it was returned for corrections, and
4-15.7 (7.5) Each time it was resubmitted.
4-15.7 (8) The proposed RMS application shall include the following case report management
reports:
4-15.7 (9) For an individual officer the percent and number of offense, accident, property and
other reports which were completed and not returned for corrections (1st Time
Completion Report).
4-15.7 (9.1) A 1st Time Completion Report for a group of officers.
4-15.7 (9.2) A 1st Time Completion Report which details the percent and number of reports that
were completed and not returned for corrections by report type.
4-15.7 (10) The proposed RMS application shall include a Calls for Service Summary/ Comparison
Report which lists calls for service by call type for a user-defined month with
comparisons to the prior month and the same month in the prior year.
SECTION TOTALS 0 0 0 0
City of Fort Collins Page 125 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5 JAIL MANAGEMENT
5-1 GENERAL REQUIREMENTS
The Jail Management Database shall be designed to operate as a component of a
comprehensive, fully integrated, multi-user, incident-based Public Safety System
Records Management System (RMS) and Jail Management System (JMS).
5-1.1 WORKFLOW PROCESS 0 0 0 0
5-1.1 (1) The system shall have the ability to set an agency defined workflow process that is
then followed automatically from screen to screen during booking and release.
5-1.1 (2) The system shall have the ability to complete the work flow process out of order at user
discretion
5-1.1 (3) The system shall have the ability to have more than one workflow process defined that
would then change based on type of booking or release.
5-1.1 (4) The system shall have the ability to manage simultaneous workflow processes on one
station at one time.
5-1.2 SCHEDULING 0 0 0 0
System shall have a schedule keeping system that is used globally by all jail
management functions, allowing system wide visibility of all events scheduled per
inmate.
5-1.2 (1) System shall schedule at minimum the following events for an individual (indicate the
type of scheduling capabilities below);
5-1.2 (1.1) court appearances,
5-1.2 (1.2) prisoner transport,
5-1.2 (1.3) writ of habeas corpus
5-1.2 (1.4) extradition,
5-1.2 (1.5) furlough,
5-1.2 (1.6) appointments,
5-1.2 (1.7) programs,
5-1.2 (1.8) education,
5-1.2 (1.9) visitation,
5-1.2 (1.10) other events.
5-1.2 (2) The system shall allow for scheduling inmates in groups as defined by the operator.
5-1.2 (3) System shall be able to schedule any person who has a core record in the RMS/JMS
regardless of booking status.
5-1.2 (4) System shall be able to schedule physical locations pre-defined in the system.
5-1.2 (5) System shall warn of violations of restrictions (keep separates, medical restrictions,
etc.)
5-1.2 (6) System shall allow / disallow schedule conflicts based on administrative settings
5-1.2 (7) System shall notify the originator(s) of the other scheduled events of a new scheduled
events that conflicts with previously scheduled events (all that conflict).
5-1.2 (8) System shall have the ability to send unsolicited notification of pending participation in
an event to any number of pre determined recipients based on user defined
parameters.
City of Fort Collins Page 126 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-1.2 (9) The system must be capable of choosing the scheduled event from a pick list: medical
appointments and their locations, court dates, visitor appointments (personal and
professional), transporting inmates to other facilities, and special program
appointments (GED classes, etc.).
5-1.2 (10) The system must be able to view or print all scheduled appointments or a particular
type of appointment (e.g. court appointments).
5-1.2 (11) The system should have the ability to cancel or reschedule events.
5-1.2 (12) The system must provide the ability to generate a summary sheet of all appointments
sequenced by housing assignment and by inmate in chronological order.
5-1.2 (13) The system must provide the ability for the user to display all scheduled events for an
inmate or housing area for a particular date and event type.
5-1.2 (14) The system must allow entry of special inmate events (e.g. delivery of court clothes,
delivery of personal items, special visitation rights).
5-1.3 PROCESS NOTIFICATION 0 0 0 0
5-1.3 (1) The system shall initiate internal messages based on agency defined criteria that will
notify system operators of pending processes (indicate the type of notifications below).
Note - This is not the same as a user requesting a report, the system drives this
process, not the user;
5-1.3 (1.1) mitimus booking due (from pre-booking),
5-1.3 (1.2) temp release fail to return,
5-1.3 (1.3) release due,
5-1.3 (1.4) suicide watch due,
5-1.3 (1.5) meal watch due,
5-1.3 (1.6) sleep watch due,
5-1.3 (1.7) emotional instability watch due,
5-1.3 (1.8) restraint check due,
5-1.3 (1.9) court date due,
5-1.3 (1.10) transport pending,
5-1.3 (1.11) visitation due,
5-1.3 (1.12) program attendance,
5-1.3 (1.13) medical appointments due,
5-1.3 (1.14) counseling appointments due,
5-1.3 (1.15) status and/or classification review due,
5-1.3 (1.16) disciplinary hearing board attendance,
5-1.3 (1.17) disciplinary process incomplete,
5-1.3 (1.18) work release fail to return,
5-1.3 (1.19) weekend or midweek program fail to report,
5-1.3 (1.20) useful public service fail to report,
5-1.3 (1.21) inmate work program scheduled,
5-1.3 (1.22) other processes.
5-1.3 (2) The system shall send these same messages external to the system via an interface to
an e-mail system.
5-1.4 OTHER GENERAL REQUIREMENTS 0 0 0 0
City of Fort Collins Page 127 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-1.4 (1) The system shall display a master status screen that will contain brief information
(including status, charges, assigned housing, and current location) of every active
inmate in the system.
5-1.4 (2) The system shall maintain a dynamic electronic copy of this master status in an
industry standard formatted file on the hard drive (in a location specified by the
agency), of any computer defined by the agency to receive this file, that has a currently
logged on client of the RMS/JMS. This file must remain and be available for viewing in
the event of a RMS/JMS failure.
5-1.4 (3) The system shall have the ability for patrol officers to initiate the booking process by
providing basic needed information electronically via an uploaded computer file created
in the field and transferred by air, wire, or removable media.
5-2 BOOKING AND RELEASE PROCESS
5-2.1 BOOKING - PERSON ENTRY 0 0 0 0
5-2.1 (1) The system shall have the ability to pre-book an individual to start serving a sentence
on a specific day in the future.
5-2.1 (2) The system shall have a mechanism to lookup a person after the entry of a name (full
or partial), and/or race, and/or sex, and/or DOB, and by utilizing soundex procedures,
provide the entry person with a list of possible matches of individuals with any prior
involvement in any part of the RMS/JMS and, upon selection, to pre-populate all
personal demographic fields (person and address) from the latest information held in
that individual’s core record.
5-2.1 (3) The system shall be able to display a photograph as a part of the lookup process (not a
separate process) prior to selecting the record and pre-populating all personal
demographic fields.
5-2.1 (4) The system shall allow the use of a bar code reader to gather entry information to pre-
populate entry fields from a Colorado driver’s license.
5-2.1 (5) The system shall have the ability to assign sequential booking (arrest) numbers
(numbers unique to this individual and this booking or arrest) in the format described
below;
5-2.1 (5.1) alpha/numeric,
5-2.1 (5.2) 12 characters,
5-2.1 (5.3) in the format (YY)(AA)(F)(C)(NNNNNN) where (YY) is the last two digits of the current
year, (AA) is a two letter code for the arresting agency, (F) is a one letter code for
facility (derived by physical location of the entry terminal), (C) is a one letter code
indicating to highest level charge for this arrest, and (NNNNNN) is a six digit sequential
number shared by all agencies that starts over each year.
5-2.1 (6) The booking number shall be generated by the same routine that provides arrest
numbers to the RMS application (booking number is the same as arrest number and
must be unique across the entire system).
5-2.1 (7) The system shall automatically calculate and display an inmate age from the date of
birth to flag juvenile inmates.
5-2.1 (8) The system shall maintain the calculated age as historical information (always show the
age the person was at the time, not the age they are now).
5-2.1 (9) The system shall have an agency defined pick list field for country of birth.
5-2.1 (10) The system shall track the level education.
City of Fort Collins Page 128 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-2.1 (11) The system shall automatically notify staff at the time of booking of any significant
alerts on file in the RMS/JMS (indicate the type of notifications below);
5-2.1 (11.1) pending warrants,
5-2.1 (11.2) pending civil process,
5-2.1 (11.3) registered sex offender,
5-2.1 (11.4) officer hazards,
5-2.1 (11.5) gang affiliations,
5-2.1 (11.6) keep separates,
5-2.1 (11.7) victim notifications,
5-2.1 (11.8) past suicidal behavior,
5-2.1 (11.9) past combative behavior,
5-2.1 (11.10) escapee,
5-2.1 (11.11) escape risk,
5-2.1 (11.12) medical cautions,
5-2.1 (11.13) dietary cautions,
5-2.1 (11.14) other cautions.
5-2.1 (12) The system shall display any and all of these alerts anytime the inmates record is
viewed.
5-2.1 (13) The system shall have the ability to maintain a person of interest tag specific to the
booking process (only notify when someone is brought into the facility).
5-2.1 (14) The system shall automatically query state and local databases for wants and warrants
every time someone is booked.
5-2.1 (15) The system shall have the ability to format and send CCIC/NCIC messages at the user
interface.
5-2.1 (16) The system shall provide authorized users only with the ability to de-attach (separate)
specific booking records from a specific inmate and assign it to another person.
5-2.1 (17) The system shall have a provision for authorized users only to combine multiple inmate
records to a specific inmate.
5-2.1 (18) The system shall allow entry of information associated with scars, marks and tattoos
including their location and description.
5-2.1 (19) The system shall have a pick list field specific to the booking that will indicate the
agency that brought the person in for booking.
5-2.1 (20) The system shall have field specific to the booking that will indicate the primary officer
of custody (officer who brought the inmate to jail) of the agency that brought the person
in for booking.
5-2.1 (21) The system shall have a field for booking agency case (report) number (used for linking
purposes).
5-2.1 (22) The system shall have a pick list field specific to the booking that will indicate the
agency that will be the agency of record for the arrest.
5-2.1 (23) The system shall have field specific to the booking that will indicate the primary
arresting officer (officer who will be filing the charges) of the arresting agency.
5-2.1 (24) The system shall have a field for arresting agency case (report) number (used for
linking purposes).
5-2.1 (25) The system shall have a field specific to the booking for comments.
City of Fort Collins Page 129 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-2.1 (26) The system shall have a tool for assessing possible suicide risk using a question and
answer form that is definable by the agency.
5-2.1 (27) The system shall maintain suicide risk information historically of any inmate classified
as a suicide risk.
5-2.1 (28) The system shall have the system have the ability to capture and save partial booking
information until it can be modified and completed at a later time.
5-2.1 (29) The system shall allow for location changes for inmates prior to completion of the
booking process.
5-2.1 (30) The system shall allow for different types of bookings (e.g. citation, warrant, detainer,
courtesy hold, court pickup).
5-2.1 (31) The system shall generate board tag inserts for a magnetic master status board
currently in place and maintained by booking staff.
5-2.1 (32) The system shall generate tamper resistant barcode bracelets with inmate picture and
identifying text as specified by Larimer County.
5-2.1 (33) The system shall generate picture output in sizes and quantities as needed by booking
personnel.
5-2.1 (34) The system must be able to track full demographics, name, address, phone, etc. (tied
to the master name record) of all victims of the person being booked.
5-2.1 (35) The system must be able to track up to 99 “victim condition” codes per victim that are
pre-defined by the agency and made available through the use of drop down selection.
5-2.1 (36) The system shall have the ability to capture the affidavit of warrantless arrest on any
booking (essentially an attached narrative to the booking).
5-2.1 (37) The system shall have the ability to limit the affidavit of warrantless arrest to one per
booking.
5-2.1 (38) The system shall have the ability to limit the number of characters contained in an
affidavit of warrantless arrest to an agency defined and maintained number.
5-2.1 (39) The system must have the ability to flag the booking record to indicate that the person
being booked needs to go to a pre-trial interview.
5-2.1 (40) The system must have the ability to export basic booking information (person, charges,
affidavit of warrantless, bond information, CCIC/NCIC responses, etc.) to an ASCII file
to be saved at a location chosen by the user (used to import data to pre-trial).
5-2.1 (40.1) The information contained in this file and how it is delimited shall be controlled by the
system administrator.
5-2.2 BOOKING - CHARGE ENTRY AND TRACKING 0 0 0 0
5-2.2 (1) The system shall allow for a minimum of 99 charge records for any inmate.
5-2.2 (2) The system shall have a sequential number for each charge.
5-2.2 (3) The system shall have the ability to select from an agency maintained pick list,
charges, by full or partial charge code or charge description.
5-2.2 (4) The system shall allow for free text entry of a charge code (override).
5-2.2 (5) The system shall send a notification to a system administrator that a manual charge
code entry was made.
5-2.2 (6) The system shall allow for free text entry of a charge description.
5-2.2 (7) The system shall store (per charge/sentence) all charge information (code and
description) as displayed (as opposed to only storing a pointer to a table).
City of Fort Collins Page 130 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-2.2 (8) The system shall have a field (per charge/sentence) specifically for the entry of the
State of Colorado standardized court docket/warrant number (for CICJIS linking).
5-2.2 (9) The system shall ensure correct entry of state standardized court docket/warrant
number by checking for adherence to correct formatting as defined by the State of
5-2.2 (10) Colorado. The system shall have a pick list field (per charge/sentence) specifically for type of
charge/sentence (e.g. state charge, municipal charge, warrant, sentence (ST, WR, WE,
HD, UPS, etc.)).
5-2.2 (11) The system shall have designator (per charge/sentence) specifically to indicate that this
charge is restricted release of information (can be used to suppress printing of a
charge).
5-2.2 (12) The system shall have a pick list field (per charge/sentence) specifically for class of
crime (e.g. Felony 1,2,3,4,5,6, Misdemeanor 1,2,3, Petty Offense 1,2, Etc.).
5-2.2 (13) The system shall have the ability to record a bond type and amount per charge.
5-2.2 (14) The system shall have the ability to record a bond processing fee per charge and to
debit that amount to the inmate’s account.
5-2.2 (15) The system shall have a field (per charge/sentence) specifically for NCIC code (4 digit
code) as required by the Colorado Bureau of Investigations.
5-2.2 (16) The system shall automatically populate NCIC code when charge is selected from a
pick list.
5-2.2 (17) The system shall allow a NCIC code to be manually entered if the charge is manually
entered.
5-2.2 (18) The system shall have a pick list field (per charge/sentence) specifically for arresting
agency.
5-2.2 (19) The system shall have a field (per charge/sentence) specifically for charging officer.
5-2.2 (20) The system shall have a field (per charge/sentence) for arresting agency case (report)
number (used for linking purposes).
5-2.2 (21) The system shall have a field (per charge/sentence) specifically for bond amount.
5-2.2 (22) The system shall have a field (per charge/sentence) specifically for court of record
5-2.2 (23) The system shall have a field (per charge/sentence) specifically for comments.
5-2.3 BOOKING - PROPERTY ENTRY AND TRACKING
5-2.3 (1) The system shall fully track vehicles involved in the arrest (make, model, style, plates,
VIN, description, involvement, disposition, etc.).
5-2.3 (2) The system shall attach vehicle involvement in the arrest to that vehicle’s master record
(if it exists) and the involvement in the arrest must be displayed on future operator
queries on that vehicle from anywhere in the system.
5-2.3 (3) The system shall have a property screen that uses both free text entry, and agency
defined pick lists, to record all property removed from, and stored for an inmate.
5-2.3 (4) The system shall have the ability to track disposition of any entered property.
5-2.3 (5) The system shall have the ability to log and track property before the arrestee has gone
through the entire booking process.
5-2.3 (6) The system shall assign property bins based on the next available of a series of pre-
defined bins (requires that the system track bins in use).
5-2.3 (7) The system shall have an entry point on the property screen for all cash deposited to
the inmate’s individual account.
City of Fort Collins Page 131 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-2.3 (8) The system shall print a combined property and money receipt for inmate and officer
signature at time of booking.
5-2.3 (9) The system shall have some method of capturing a signature for process verification.
5-2.4 PROPERTY ISSUED 0 0 0 0
5-2.4 (1) The system shall have full tracking of property issued to an a inmate, including the
ability to show a complete list of allowed property based on classification and of that
property what was issued.
5-2.4 (2) The system shall track the date/time of all dress in and dress out processes and the
office that completes each.
5-2.5 SENTENCE CALCULATION 0 0 0 0
Sentence calculation is a process that is used to determine when a sentenced
individual is due to be released from jail. At the Larimer County jail it must not only
handle standard good time but also provide a mechanism for inmates to earn and lose
additional time from their sentence based on activities within the jail. The proposed
system must have a sentence calculation system.
5-2.5 (1) The system shall have the ability to calculate (per charge/sentence) the release date as
defined by applied formulas.
5-2.5 (2) The system shall automatically give credit for statutory good time based on agency
defined parameters.
5-2.5 (3) The system shall allow for deductions in any earned time.
5-2.5 (4) The system shall have a provision for sentence calculations based on served
consecutively and/or served concurrently provisions.
5-2.5 (5) The system shall allow for a minimum of 99 sentence records for any inmate.
5-2.5 (6) The system shall have a provision for a comment field for any sentence entry.
5-2.5 (7) The system shall automatically calculate a release date for inmates in alternative
sentencing programs such as work release, weekend or mid-week programs, home
detention, or useful public service.
5-2.5 (8) The system shall provide a mechanism to convert a sentence from an alternative
sentence program to straight time in the jail.
5-2.5 (9) The system shall provide a mechanism to convert a sentence from straight time in the
jail to an alternative sentence program.
5-2.5 (10) The system shall provide a mechanism to report how system arrived at calculated
release date, how date was derived, and who did calculation.
5-2.5 (11) System must allow for an override on calculated release date with mandatory
5-2.5 (12) System must provide for sentence adjustment with mandatory comment.
5-2.5 (13) The system shall have a mechanism to void current sentence calculations.
5-2.5 (14) The system shall have a mechanism for inmates to gain additional credits based on
status in any number of jail programs with every jail program having different earning
ratios.
5-2.5 (15) The system shall have a provision for inmates to lose credits earned based on
disciplinary actions.
5-2.5 (16) The system shall have a provision for logging activity of all actions that contributed to
final calculated release date.
5-2.5 (17) The system shall show relationships between each sentence record (which is
consecutive to which, which is concurrent to which).
City of Fort Collins Page 132 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-2.5 (18) The system shall be able to display a percentage of calculated sentence served.
5-2.5 (19) The system shall have a mechanism to allocate credit for time served.
5-2.5 (20) The system shall have a provision that allows credit for time earned prior to actual
sentence date.
5-2.6 RELEASE PROCESS 0 0 0 0
5-2.6 (1) The system shall allow for temporarily releasing an inmate to another agency without
the need to fully satisfy the formal release process (booking remains active).
5-2.6 (2) The system shall track the reason for the temporary release.
5-2.6 (3) The system shall clearly indicate those inmates with an active booking that are out of
the facility on temporary release.
5-2.6 (4) The system shall allow the operator to set a date for the anticipated return of a
temporarily released inmate, and by so doing cause the system to initiate action if the
inmate is not returned by that date.
5-2.6 (5) The system shall have the ability to maintain holds that must be satisfied by an
operator specifically clearing the hold before the system will allow the release of an
inmate from the system.
5-2.6 (6) The system shall have a free text hold disposition field (per hold) that must be
completed before a hold can be released.
5-2.6 (7) The system shall automatically query state and local databases for wants and warrants
every time someone is being released from the system.
5-2.6 (8) On release of pre-defined warrants holds, the system shall automatically generate an
agency response message to the warrant agency that can be reviewed and corrected
before message is sent by the releasing officer.
5-3 INMATE HOUSING AND MOVEMENT
5-3.1 CLASSIFICATION 0 0 0 0
5-3.1 (1) The system must have an automatic classification process.
5-3.1 (2) The system must have a classification process that fully adheres to NIC guidelines.
5-3.1 (3) The system must have a classification process that is acceptable and certifiable by
ACA.
5-3.1 (4) The system must classify inmates by utilizing a flow chart methodology that branches in
different directions based on yes/no answers (a point classification system is not
acceptable).
5-3.1 (5) The classification system must be integrated with the RMS/JMS and automatically
utilize information entered at other points in the system to assist in the classification
process.
5-3.1 (6) The system must allow for an agency maintained categorization of individual housing
areas as to type of inmate that will be housed (e.g. minimum, medium, maximum).
5-3.1 (7) The system must allow the agency to change a housing area's designation as housing
needs change.
5-3.1 (8) The system shall maintain housing categorization information historically.
5-3.1 (9) The system must have an alert noting if an inmate has been mis-housed.
5-3.1 (10) The system must allow the classifying officer to override the housing recommendation
as necessary, but the system must log the event and allow for entry of explanation.
5-3.1 (11) The system must have an automatic means of sending a message to pre-defined
person(s) that the classification recommendation was overridden.
City of Fort Collins Page 133 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-3.1 (12) The system must have an automatic means of sending a classification review needed
message or alert. Examples of events that should re-send the classification needed
message or alert are: new charges/warrants, a security move, a specified number of
incidents, or a time interval between reviews.
5-3.2 HOUSING 0 0 0 0
5-3.2 (1) The system must have agency maintained system tables that control codes for facility,
housing area and cell.
5-3.2 (2) The system must provide information on available beds in each housing area.
5-3.2 (3) The system must allow assignment of inmates by classification personnel to a
particular housing area.
5-3.2 (4) The system must provide means for tracking persons who must be kept separate from
a specific inmate within the facility. An alert should be generated when assigning
housing locations if an inmate is being assigned housing with a keep separate.
5-3.2 (5) The system must provide entry of routine inmate counts and the ability to view them in
both online and printed formats.
5-3.2 (6) The system must provide inmate rosters in both online and printed formats. The
system must allow individual housing areas to be viewed or printed and must also be
able to view and print all housing area roster information.
5-3.2 (7) The system must have the ability to flag an inmate being housed for another agency.
5-3.2 (8) The system must be able create both an online and printed alphabetic list of all active
inmates, including either the housing assignment or the actual location.
5-3.2 (9) The system must historically keep housing area rosters for any given date and time.
5-3.2 (10) The system must track and historically maintain all housing location changes for an
inmate.
5-3.3 HOUSING LOGS 0 0 0 0
5-3.3 (1) The system shall maintain pass-on files (type of entry code and free text comment),
keyed to locations, that can be later recalled by an officer based on type of entry and
location, such as all inmates sanctioned in a housing area (pass-on for a housing area
for example).
5-3.3 (2) System shall make a notation in a pass-on file that a person housed in that area has
had a behavioral report filed in the system.
5-3.3 (3) System shall display pass-on files by selecting predefined time periods (i.e. clicking on
a button).
5-3.3 (4) System shall display pass-on files by allowing the user to specify area and time period.
5-3.4 MOVEMENT 0 0 0 0
5-3.4 (1) The system must create online 'move' lists from the assignment of inmates to a
particular housing area. The system must be able to display these 'move' lists online
as needed or in a printed report format.
5-3.4 (2) The system must be able to track all inmate movement within the facility and keep a
history log of the movement.
5-3.4 (3) The system must provide the ability to alert targeted jail staff by inmate's name and ID
with details of the special alert(s) (e.g. security and transport status, medical alert, gang
affiliations, special diets, security moves, unscheduled court appearance).
5-3.4 (4) The system should allow alerts to require acknowledgements with or without comment.
City of Fort Collins Page 134 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-3.4 (5) The system shall notify supervisors of unacknowledged alerts after a certain time.
5-3.4 (6) The system shall allow for inmate movement to be processed by the use of portable
bar code readers.
5-3.4 (7) The system shall allow for moving inmates in groups by barcode as defined by the
operator.
5-3.4 (8) The system must have the ability to generate online and printed internal and external
movement lists.
5-3.4 (9) The system must allow the addition of names to movement lists.
5-3.4 (10) The system must be able to record inmate movement separate from inmate housing
assignments.
5-3.5 TRANSPORTATION 0 0 0 0
5-3.5 (1) The system shall provide for full tracking and management of the court transportation
process.
5-3.5 (2) The system shall provide for full tracking and management of the extradition process,
including tracking all costs, preparing billing, other agency holds, current status and
history maintenance.
5-3.5 (3) The system shall have the ability to maintain a transportation needed listing. These
names may be inmates from booked into the facility or may be inmates from other
agencies.
5-3.5 (4) The system must be able to generate a printed court action sheet. The system will
print a court action sheet, listing inmates scheduled for a court appearance for a
particular date with selects by Courtroom or Housing Area.
5-3.5 (5) The system must have the ability to enter the disposition of each court appointment and
then allow scheduling of the next court date.
5-3.5 (6) The list of inmates scheduled for transport must include the appropriate warnings (e.g.
escape risk, prone to violence, high bond, medical precautions).
5-4 PROGRAMS AND SERVICES
5-4.1 INMATE ACCOUNTING 0 0 0 0
5-4.1 (1) The system shall have a funds accounting system that tracks funds of all inmates
individually (credits and debits).
5-4.1 (2) The system shall allow for the tracking of an individual’s account from booking to
booking to include all negative balances.
5-4.1 (3) The system shall have a process that tracks an individual’s account by transaction
type.
5-4.1 (4) The system must be able to provide real-time inmate account balance information.
5-4.1 (5) The system must be able to report in an online and in printed format inmates who have
been released and still have account balances.
5-4.1 (6) The system must have the ability to handle and report unclaimed funds and return the
balance to zero based on length of time left unclaimed.
5-4.1 (7) The system must have the ability to apply inmate account funds towards bond or fines
and costs. All appropriate financial records must be updated as necessary.
5-4.1 (8) The system must have the ability to print each inmate's account activity.
5-4.1 (9) The system shall have the ability to automatically have repetitive fees debited for every
pre-defined period that passes while an inmate is (or has) served time in the facility.
City of Fort Collins Page 135 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-4.1 (10) The system shall have the ability to send automatic notification to a predefined
person(s) anytime an inmate’s account shows a negative balance (each time it goes
from positive to negative).
5-4.1 (11) The system shall have the ability to hold encumbrances to a negative balance that can
be settled either automatically of manually (defined by type of encumbrance).
5-4.1 (12) The system shall have the ability to automatically notify the accounting technician of all
deposits to a negative balance.
5-4.1 (13) The system shall hold all monies deposited up to the total amount of encumbrances to
a negative balance from the release process (only that money above the negative
balance is releasable).
5-4.1 (14) The system shall have the ability to track all inmate money deposits and releases by
individual bringing or receiving money.
5-4.1 (15) The system shall have the ability to allow or deny money deposit or release to an
individual based on previous status as a recent inmate of Larimer County.
5-4.1 (16) The system shall have the ability to electronically capture signatures for receipt
process.
5-4.1 (17) The system shall have the ability to print receipts to include captured signature.
5-4.1 (18) The system shall have the ability to print checks at multiple locations.
5-4.1 (19) The system shall have the ability to track and bill costs associated with booking
inmates for other agencies and entities.
5-4.1 (20) The system shall have the ability to track and bill costs associated with holding inmates
for other agencies and entities. This should include a standard rate per day and allow
entry of any special fees or charges.
5-4.1 (21) The system must be able to handle various billing rates for inmates from different
agencies.
5-4.1 (22) The system must be able to accommodate different billing cycles for different agencies.
5-4.1 (23) The system must automatically calculate the billing amount for inmates housed from
another agency.
5-4.1 (24) The system must be able to report on inmates housed for another agency (e.g. days
incarcerated, last date billed, billable amount, special fees or charges, billing agency
information).
5-4.1 (25) The system must be able to create detailed bills for each agency that have inmates in
our facility.
5-4.1 (26) The system shall have the ability to record and maintain multiple master inmate fund
accounts set for varying purposes (indigent, commissary, bond fee, medical fee, etc.) to
include transactional tracking of sufficient detail to allow complete reconstruction of any
fund movement process for auditing purposes.
5-4.1 (27) The system shall have the ability to fully reconcile the master accounts at the beginning
of each fiscal period (balance or zero as desired).
5-4.2 PROGRAMS 0 0 0 0
5-4.2 (1) The system shall maintain a listing of qualified instructors/volunteers for various
programs by agency defined and maintained instruction type codes.
5-4.2 (2) Each instructor shall be definable by up to 99 instruction/function type codes.
5-4.2 (3) The system shall search for and display qualified instructors/volunteers by
instruction/function type code.
City of Fort Collins Page 136 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-4.2 (4) The system shall indicate current status of instructors/volunteers (i.e. active or inactive)
5-4.2 (5) The system shall maintain a listing of activities and courses that could be offered.
5-4.2 (6) The system shall track all programs activities (who taught, who went, what was taught,
when, pass/fail/score by person if applicable).
5-4.2 (7) The system shall allow for the scheduling of programs resources (availability of facilities
and equipment).
5-4.2 (8) The system shall have the ability to provide basic library tracking functionality
(inventory and checkout).
5-4.3 VISITATION PROCESSING 0 0 0 0
5-4.3 (1) The system shall have the ability to pre-schedule and track all inmate visitation,
including indicating whether or not the visitor was previously incarcerated, a record of
all inmates visited by day and date, and any past problems with the visitor.
5-4.3 (2) The system shall allow for the scheduling of visitation resources (availability of visitation
spaces).
5-4.3 (3) The system shall the system display a listing of all scheduled visits for an operator
requested date and time span.
5-4.3 (4) The system shall alert visitation personnel of pending issues and cautions in regards to
potential visitors (indicate the type of notification below);
5-4.3 (4.1) pending warrants,
5-4.3 (4.2) pending civil process,
5-4.3 (4.3) officer hazards,
5-4.3 (4.4) gang affiliations,
5-4.3 (4.5) keep separates,
5-4.3 (4.6) victim of offense (visitor or inmate),
5-4.3 (4.7) restraining order violations,
5-4.3 (4.8) property (or money) to be released,
5-4.3 (4.9) special offender (sex offender, parolee, probation, etc,),
5-4.3 (4.10) other notifications
5-4.4 COMMISSARY 0 0 0 0
In addition to providing an interface to a commissary vendor as specified in global
system specifications, the system must also provide the following commissary
functions;
5-4.4 (1) The system must have the ability to track and issue commissary that includes full
barcode enabled inventory and order control, automatic funds debiting, and the ability
to disallow participation based on current disciplinary or classification status.
5-4.4 (2) The system must maintain a table of available commissary products and prices. This
table must allow for adding, modifying and deleting products and making price
adjustments. This table must be maintainable by direct import from a commissary
vendor.
5-4.4 (3) The system must have the ability to limit selection of commissary products by inmate,
sex, housing location, and special diet.
5-4.4 (4) The system must allow a maximum dollar amount for each inmate order.
5-4.4 (5) The system must provide for immediate calculation of inmate available funds as the
order is entered.
City of Fort Collins Page 137 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-4.4 (6) The system must provide immediate notification if the order exceeds available inmate
funds.
5-4.4 (7) The system must be able to track the issuance of indigent packages to inmates.
5-4.4 (8) Selection of the inmate for order entry must be available by name search (active
inmates only) or by entering the inmate Identification number or booking number.
5-4.4 (9) The system must allow for an inmate flag that prevents commissary access for a
specific time period.
5-4.4 (10) The system must have the ability to produce order reports and product usage reports.
5-4.4 (11) The system must have the ability to produce commissary product lists.
5-4.4 (12) The system must have the ability to produce inmate commissary history reports.
5-4.4 (13) The system must have the ability to produce order payment reports.
5-4.4 (14) The system must historically keep all orders for a specified period of time. Financial
records must be permanently maintained.
5-4.4 (15) The system must create, upon request, an ASCII file of commissary orders for a given
time period for selected housing areas to be transmitted to the commissary vendor.
5-4.4 (16) The system must create, upon request, an ASCII file of available funds per inmate for a
given time period for selected housing areas to be transmitted to the commissary
vendor.
5-4.5 FOOD SERVICES 0 0 0 0
5-4.5 (1) The system must track and notify system operators of any special dietary needs or
cautions per inmate.
5-4.5 (2) The system must be able to print an alphabetical listing of all inmates who have special
dietary needs or cautions by housing area.
5-4.6 MEDICAL 0 0 0 0
5-4.6 (1) The system must have the ability for medical personnel to set a person of interest flag
that would notify pre-determined personnel any time that person is booked into the
facility.
5-4.6 (2) The system must have an initial medical assessment process that allows for initial
medical screening by booking personnel without granting any additional security to
view any other medical records.
5-4.6 (3) The system must log the need for and the completion of the initial medical assessment.
5-4.6 (4) The system shall provide for recording the fact of initial medical assessment completion
that is globally viewable, but the actual assessment shall become protected and
viewable by medical personnel only upon completion.
5-4.6 (5) The system shall allow for the agency system administrator to define (and redefine) all
medical screening questions and actions for those questions.
5-4.6 (6) The system shall allow for multiple medical questionnaires.
5-4.6 (7) The system shall have a provision to indicate a need for a medical watch to be
performed that can be restricted for viewing by medical personnel only.
5-4.6 (8) The system shall have a provision to indicate a need for a medical watch to be
performed that can be global to the system.
5-4.6 (9) The system shall have the ability to set and track more than one watch per inmate.
5-4.6 (10) The system shall indicate the type of watch to be performed (i.e. alcohol withdrawal,
drug withdrawal, head injury, sleep watch, meal watch, activity watch, etc.).
City of Fort Collins Page 138 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-4.6 (11) The system shall indicate the interval of the watch to be performed (i.e. random,
mealtimes, every 15 minutes, etc.).
5-4.6 (12) The system shall record the completion of the watch by time, date, person performing
the watch, and comments.
5-4.6 (13) The system shall allow for medical restrictions to be set that would then flag the inmate
record and notify any person attempting to schedule or locate the inmate for an activity
or in an area that is restricted (i.e. strenuous physical exertion, handicap, lower bunk
required, cot required, lower tier only, etc.).
5-4.6 (14) The system shall have the ability to set a flag on the inmate record of any medical
cautions that may be of concern for officer safety.
5-4.6 (15) All medical, dental, and psychological information gathered on an inmate must become
a part of the inmate's medical records.
5-4.6 (16) The system must be able to maintain the confidentiality of all medical, and dental, and
psychological inmate information.
5-4.6 (17) The system must have the ability to record inmate medical histories.
5-4.6 (18) The system must have the ability to chronologically record doctor and nurse notes for
each inmate.
5-4.6 (19) The system must have the ability to chronologically record doctor orders for each
inmate.
5-4.6 (20) The system must have the ability to record inmate medical visits, both internal and
external; nurse, physician's assistant, and doctor.
5-4.6 (21) The system shall have the ability if visits are canceled and re-scheduled to allow for
entry of a coded reason, a note and who authorized the rescheduling.
5-4.6 (22) The system must have the ability to track inmate special needs (e.g. glasses, diabetic).
5-4.6 (23) The system must have the ability to track medications dispensed to inmates. Examples
of information needed include prescription and non-prescription medications, dosages,
how dispensed, time to be dispensed, period of time to be taken, inmate refusal of
medication, etc.
5-4.6 (24) The system must have the ability to flag an inmate who requires isolation precautions.
5-4.6 (25) The system must have the ability to list in detail the type of isolation precautions that
must be observed.
5-4.6 (26) The system must have the ability to track and display more than one isolation
precaution per inmate.
5-4.6 (27) The system must flag an inmate scheduled for release who is under current medical
care (e.g. taking a prescription drug) and print instructions for the inmate.
5-4.6 (28) The system must have the ability to maintain an inventory of prescription and non-
prescription medications, as well as medical supplies.
5-4.6 (29) The system must allow minimum inventory limits to be set.
5-4.6 (30) When an inventory item reaches its minimum limit, the system must flag the item as
needing to be reordered.
5-4.6 (31) The system must create an online and printed report of items needing to be ordered.
5-4.6 (32) The system must be able to report on inmate medication usage, especially controlled
substances.
5-4.6 (33) The system must be able to track treatments ordered for inmates and flag those
treatments not administered.
City of Fort Collins Page 139 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-4.6 (34) The system shall have the ability to globally indicate on an inmate record approval or
denial for the inmate to participate in any number of agency definable and maintainable
programs or activities.
5-4.6 (35) The system shall have the ability to track more than one type of medical approval per
inmate.
5-4.6 (36) The system shall record medical approval with the use of an agency maintained pick
list.
5-4.6 (37) The system shall have the ability for medical personnel to place and release medical
holds that would prevent inmate release until the hold is satisfied.
5-4.6 (38) The system must have the ability to bill inmate accounts for medical costs and services.
5-4.7 MENTAL HEALTH 0 0 0 0
5-4.7 (1) The system must have the ability to classify an inmate as a suicide risk and maintain
this information historically.
5-4.7 (2) The system must have the ability for mental health personnel to set a person of interest
flag that would notify pre-determined personnel any time that person is booked into the
facility.
5-4.7 (3) The system must be able to track and chronologically record detailed inmate
psychological information.
5-4.7 (4) The system shall allow for mental health restrictions to be set that would then flag the
inmate record and notify any person attempting to schedule or locate the inmate for an
activity or in an area that is restricted (i.e. library only, staff run only, all programs, etc.).
5-4.7 (5) The system shall have a provision to indicate a need for a psychological watch to be
performed that can be restricted for viewing by mental health personnel only.
5-4.7 (6) The system shall have a provision to indicate a need for a mental health watch to be
performed that can be global to the system.
5-4.7 (7) The system shall have the ability to set and track more than one watch per inmate.
5-4.7 (8) The system shall indicate the type of watch to be performed (i.e. suicide risk, emotional
instability, medication required, sleep watch, meal watch, activity watch, etc.).
5-4.7 (9) The system shall indicate the interval of the watch to be performed (i.e. random,
mealtimes, every 15 minutes, etc.).
5-4.7 (10) The system shall record the completion of the watch by time, date, person performing
the watch, and comments.
5-4.7 (11) The system shall have the ability to set a flag on the inmate record of any psychological
cautions that may be of concern for officer safety.
5-4.7 (12) All medical, dental, and psychological information gathered on an inmate must become
a part of the inmate's medical records.
5-4.7 (13) The system must be able to maintain the confidentiality of all medical, dental, and
psychological inmate information.
5-4.7 (14) The system shall have the ability for mental health personnel to place and release
mental health holds that would prevent inmate release until the hold is satisfied.
5-5 ADMINISTRATIVE FUNCTIONALITY
5-5.1 JMS INCIDENT AND DISCIPLINARY REPORTING (JMSIDR) 0 0 0 0
City of Fort Collins Page 140 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
The jail management system, incident and disciplinary reporting (JMSIDR) module
manages inmate misconduct. This misconduct can include major and minor rules
violations that can lead to changes in inmate status. These changes may include, but
are not limited to, loss of time earned towards sentence length reduction, verbal or
written warning, lock down, reclassification, and loss of privileges. The proposed
system must include a jail incident and disciplinary reporting system that is separate
from the RMS incident reporting system.
5-5.1 (1) The JMSIDR shall have a mechanism to enter unlimited narrative with spell check
capabilities.
5-5.1 (2) The JMSIDR shall have a mechanism to enter involved people (It must allow the ability
to include or exclude any people on query and hard copy reports).
5-5.1 (3) The JMSIDR shall have a mechanism to route reports to appropriate management
personnel.
5-5.1 (4) The JMSIDR shall have a provision for supervisory review and acceptance.
5-5.1 (5) The JMSIDR shall have a provision for assigning reports to certain personnel and show
who the report has been assigned to.
5-5.1 (6) The JMSIDR shall have a mechanism to produce hard copies of incident reports.
5-5.1 (7) The JMSIDR shall be able to reference any associated RMS incident reports and/or
arrests.
5-5.1 (8) The JMSIDR shall have a mechanism to import the report into the RMS standard
incident report system.
5-5.1 (9) The JMSIDR shall have a mechanism to time-stamp report.
5-5.1 (10) The JMSIDR shall have a mechanism for displaying/printing pending incident reports.
5-5.1 (11) The JMSIDR shall have a mechanism for providing disposition and stating who made
the incident determination.
5-5.1 (12) The JMSIDR shall have a provision for an appeal process including management by
time.
5-5.1 (13) The JMSIDR shall have a provision for an agency maintained table of type codes for
the type of incident report.
5-5.1 (14) The JMSIDR shall have a mechanism to provide informational reports.
5-5.1 (15) The JMSIDR shall have a mechanism to provide medical based incident reports.
5-5.1 (16) The JMSIDR shall have a dissemination level flag.
5-5.1 (17) The JMSIDR shall provide all previous incident history for any inmate based on security
level of user.
5-5.1 (18) The JMSIDR shall allow for the ability to classify incident (similar to a JMS incident
name).
5-5.1 (19) The JMSIDR shall allow for the entry of up to 99 JMSIDR incident names per report.
5-5.1 (20) The JMSIDR shall allow for the ability to set a level of incident (severity of incident) that
could drive the post process of the investigation.
5-5.1 (21) The JMSIDR shall provide the ability to move to dropped sanctions to a separate area
of the database and to remove links to the sanctioned inmate(s) core record while still
allowing for a search (based on something other than inmate name) to display the
incident itself (searching on the inmate name must not display the record).
5-5.1 (22) The JMSIDR shall have the ability to attach scanned documents to the incident report.
City of Fort Collins Page 141 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-5.1 (23) The JMSIDR must provide the ability to track "use of force" incidents and investigation
results.
5-5.1 (24) The JMSIDR should have the ability to link all inmates involved in a particular incident
or all incidents involving a particular inmate.
5-5.1 (25) The JMSIDR must provide the ability to view and or print dates and times of violations,
location(s) of violations, the type of housing areas and the type of violation and
disposition sequenced by date, time, housing area and facility for user specified
selection criteria, (e.g. housing area, violation, disposition, inmate, officer involved,
date, time, day of the week).
5-5.1 (26) The JMSIDR shall have the ability to mark the incident or disciplinary event as
confidential restricting access to certain user groups by the originating supervisor.
5-5.2 ACA VALIDATION AND CERTIFICATION 0 0 0 0
5-5.2 (1) The system shall provide functionality specific to the tracking and management of ACA
accreditation.
5-5.3 SOCIAL SECURITY ADMINISTRATION 0 0 0 0
5-5.3 (1) The system shall provide for tracking and notification to the Social Security
Administration of inmates that are incarcerated for extended periods of time so that
benefits for that individual can be suspended.
5-6 ALTERNATIVE SENTENCING PROGRAMS 0 0 0 0
The Larimer County Sheriff’s Office has an extensive Alternative Sentencing Unit (ASU)
that administers a number of different programs to allow serving sentences for the
commission of crimes in ways that are more beneficial to the community than having an
inmate serve straight time in the jail. It is expected that the RMS/JMS that will be
purchased by the participating agencies will be capable of managing these inmates as
well as those in the jail. The ASU has four primary programs it administers;
Work Release (WR) - Inmates hold regular jobs, but spend all their off time for the
duration of their sentence at a facility operated by the Sheriff’s Office. The system will
have to track their status as an inmate, manage the assignment and reservation of
available beds (hotel function), and track the inmate’s location and the failure to be at a
certain location at a certain time.
Workender (WE) - Inmates report to the Sheriff's Office two days a week for the
duration of their sentence (could be any two days of the week) for assignment to a work
crew. Time served is counted for each day they are participating on a work crew.
Inmates stay overnight for one night of the two days. The system will have to track
their status as an inmate, manage the assignment and reservation of work slots, and
track the inmate’s time served over many months of two day check ins.
City of Fort Collins Page 142 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
Useful Public Service (UPS) - Inmates are sentenced to perform a certain number of
hours performing some task that benefits the community. The time spent performing
these tasks is not directly supervised by the staff at ASU, but is instead tracked and
reported by a reliable third party such as an employer or program manager. Reports
are generally submitted on a weekly basis and are then entered into a computer
program as a credit to their sentence. Sentence is complete when all the hours of the
sentence have been accounted for. Some inmates are sentenced to perform a certain
number of hours per year for the rest of their lives and will never complete their
sentence until their death. The system will have to track their status as an inmate and
the actual time they have worked over many entries.
Home Detention (HD) - Inmates can hold regular jobs, but spend all their off time at
their residence for the duration of their sentence. Their location is tracked through the
wearing of an ankle transmitter that is monitored by a third party monitoring service.
The system will have to track their status as an inmate, and track the inmate’s location
and the failure to be at a certain location at a certain time.
It seems that calculation or completion of a sentence in ASU needs to be driven by
some type of applied formula system (calculated on time in for WR, HD, WE, or by
number of hours by date(s) for UPS) (i.e. 100hrs per year for 100 years). - See 5-2.5
“Sentence Calculation”
5-6.1 (1) System must allow for concurrent participation in more than one ASU program (i.e. in
work release and fulfilling community service hours at the same time).
5-6.1 (2) System shall notify ASU personnel of any contact with an ASU inmate recorded
anywhere else in the system.
5-6.1 (3) System must be able to track billing and payment for ASU programs, by program, and
by court case within program.
5-6.1 (4) System shall have the ability to record and track the payment for any mandated testing
(alcohol, drug testing etc.) required of all inmates of the ASU programs.
5-6.2 WORK RELEASE 0 0 0 0
5-6.2 (1) System shall have the ability to record and track the payment for a one time program
fee for Work Release.
5-6.2 (2) Sign in for Work Release needs to be rapid and electronic - System shall have the
ability to print an expected attendance roster that lists full name, DOB, expected time,
barcode, and a signature capture blank.
5-6.2 (3) System shall have a mass check in / check out routine that can check in and check out
groups of people using that bar code attendance sheet.
5-6.2 (4) System shall notify a predetermined group of people whenever a Work Release inmate
is out of the facility for more than a operator selected time period in a 24 hour period
(24 hour period to be defined by person) (usually more than 12 hours).
5-6.2 (5) System must maintain schedules on work release inmates that includes automatic
calculation of total time spent, notification sent to a specified individual when return
times are missed.
5-6.2 (6) System must maintain a history of work release violations and adherence to the
sanctions imposed.
5-6.2 (7) System must look for, and warn of, potential inmate conflicts (based on past
incarceration records) when reserving space.
5-6.3 WORKENDER 0 0 0 0
City of Fort Collins Page 143 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
Workender programs are defined as any two days of the week.
5-6.3 (1) System shall have the ability to record and track the payment for a one time program
fee for Workender.
5-6.3 (2) System must have a sentence calculation routine that calculates and records both days
served and nights served (2-1 ratio at this time).
5-6.3 (3) Sign in for Workender needs to be rapid and electronic - System shall have the ability
to print an expected attendance roster that lists full name, DOB, expected time,
barcode, and a signature capture blank.
5-6.3 (4) System shall have a mass check in / check out routine that can check in and check out
groups of people using that bar code attendance sheet.
5-6.3 (5) System must allow for exception check in (all expected inmates are automatically
assumed to be present unless otherwise indicated).
5-6.3 (6) System must record a reason for failure to appear.
5-6.3 (7) System must look for, and warn of, potential inmate conflicts when reserving space.
5-6.4 USEFUL PUBLIC SERVICE 0 0 0 0
5-6.4 (1) System shall have the ability to track the expected participation in the UPS program
based on entry of a court order and record at minimum;
5-6.4 (1.1) Full name (tied to master name index),
5-6.4 (1.2) Court case number (16 character),
5-6.4 (1.3) Convicted charge,
5-6.4 (1.4) Number of community service hours to serve,
5-6.4 (1.5) Number of days to complete the hours,
5-6.4 (1.6) Judge’s name,
5-6.4 (1.7) Sentencing date,
5-6.4 (1.8) Probation officer’s name,
5-6.4 (1.9) The deadline for the community service,
5-6.4 (1.10) And a comment area.
5-6.4 (2) Based on the sentencing date the system shall notify ASU personnel if the person
expected to perform community service does not report to ASU after a pre-determined
time has past.
5-6.4 (3) System shall have the ability to record and track the payment for a one time program
fee for UPS.
5-6.4 (4) System Shall notify a designated person(s) if the deadline for the community service
passes and the sentence has not been fully satisfied.
5-6.4 (5) System must track and maintain schedules on inmates sentenced to useful public
service that includes automatic calculation of total time spent, notification sent to a
specified individual when conditions are not met as scheduled.
5-6.4 (6) System must maintain a history of useful public service and adherence to the sanctions
imposed.
5-6.5 HOME DETENTION 0 0 0 0
5-6.5 (1) System shall have the ability to record and track the payment for a one time program
fee for Home Detention.
5-6.5 (2) System shall have the ability to automatically assess, record and track the payment for
a daily fee for the Home Detention ankle bracelet.
City of Fort Collins Page 144 of 145 Proposal P-847
REF. SPECIFICATIONS YES NO ALT MOD COMMENTS
5-6.5 (3) System must track and maintain schedules on inmates sentenced to home detention
that includes automatic calculation of total time spent, notification sent to a specified
individual when conditions are not met as scheduled.
5-6.5 (4) System must maintain a history of home detention violations and adherence to the
sanctions imposed.
SECTION TOTALS 0 0 0 0
City of Fort Collins Page 145 of 145 Proposal P-847