Exhibit_C_-_Features_&_Functionality_Technical_Requirements_Matrix.xlsx
XLSX spreadsheet 266 KB Posted
- Solicitation number
- 26-074-RFP
- Issued by
- Yolo County, California
About this file
This file is a Features & Functionality Technical Requirements Matrix for a Law Enforcement Records Management System (LERMS) and Automated Field Reporting (AFR) solicitation issued by the City of West Sacramento Police Department (BID 26-074-RFP). The matrix serves as the evaluation tool for vendor responses and outlines comprehensive functional requirements across multiple modules including jail management system (JMS), field reporting, and law records management. The City of West Sacramento, serving a population of 55,000 with 123 authorized employees, currently operates a single dispatch center serving 4 law agencies, 17 fire agencies, and processes approximately 198,580 calls annually. The RFP seeks an integrated solution to replace the existing CentralSquare CAD and RMS systems, with requirements spanning general system configuration, report writing capabilities, field interviews, workflow management, incident documentation, and advanced features such as NIBRS compliance, digital signatures, and multi-jurisdictional support. The matrix includes 132 evaluation line items across field reporting and law records management, with vendors required to indicate compliance status (Comply, Does Not Comply, Partially Comply, or Will Comply) for each requirement, along with detailed comments and dates of expected compliance where applicable.
The technical requirements matrix encompasses extensive functionality demands including web-based and mobile application capabilities, integration with external systems (NCIC, VCIN, DMV), master name index management, property tracking, court transaction processing, and reporting across multiple parameters. The City requires the solution to support digital signatures, unlimited character narratives with word processing capabilities, conditional logic in questionnaires, automatic data population from CAD and other modules, and agency-defined customization of reports and workflows. The matrix indicates specific user counts including 123 total RMS users with full access, 12 mobile/iOS Android devices, and 225 Windows workstations, with training required for all 123 personnel. The proposed solution must accommodate the City's existing GIS infrastructure maintained by a dedicated internal team and interface with the current CentralSquare CAD system. No specific pricing, funding sources, incumbent information, or contract term details are provided within this technical requirements matrix document, which functions primarily as the functional specification and evaluation criteria for vendor proposals.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Law_Enforcement_Records_Management_System_(LERMS)_and_Automated_Field_Reporting.pdf | ||
| Exhibit_E_-_Customer_References.xlsx | XLSX spreadsheet | |
| Contract_for_Services_(West_Sacramento)_-_Boilerplate_for_RFP_11.4.24.docx | DOCX document | |
| Insurance_Checklist_2023.pdf | ||
| Exhibit_D_-_Cost_Proposal.xlsx | XLSX spreadsheet | |
| Exhibit_B_Technical_Narrative.pdf | ||
| Contract_for_Services_(West_Sacramento)_-_Federal_Boilerplate_for_RFP_5.1.24.docx | DOCX document | |
| Federal_Award_Requirements_Appendix_II_to_Part_200_Contract_Provision_Language.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Matrix Submission Instructions |
| Please respond to each line item requirement by placing an X in the appropriate column to indicate your response |
| Comply: This indicates the proposed solution meets all aspects of the requirement. |
| Comments: Vendors are strongly encouraged to further explain how their solution satisfies the matrix requirement item. |
| Does Not Comply: This indicates the proposed solution does not meet the requirement. |
| Comments field: Vendors are encouraged to explain why their solution does not meet the requirement. |
| Partially Comply: This indicates the proposed solution meets part of the requirement. |
| Comments field: Vendors are encouraged to provide details indicating which part of the requirement cannot be met by the proposed solution and how the vendor partially complies (e.g., in conjunction with a third-party solution, "workaround", etc.). |
| Will Comply: This indicates that while the proposed solution does not currently meet the requirement, the vendor will comply with the requirement item. |
| Comments field: Vendors must explain how their solution will comply (e.g., if this is a future development roadmap item - including the approximate date of expected compliance (in the "Date of Expected Compliance" column), if it is an item the vendor is willing to develop and provide as a contract deliverable, or if the solution can be used in conjunction with a third-party application or "workaround" to achieve full compliance, etc.). |
| This Excel version of this matrix must be included with your proposal submission |
Agency Information
| National Public Safety Group |
| Requirements Evaluation Matrix |
| VENDOR COMPLETING THIS MATRIX: | |
| West Sacramento, CA Police Department |
| BID: 26-074-RFP | |
| Agency Logistics and Counts | |
| West Sacramento PD | |
| Agency Logistics | |
| Population served | 55,000 |
| Is there a dedicated internal GIS staff for the public safety applications or does the agency use a vendor to maintain and update maps? | The City has a dedicated GIS team that maintains the city shapefiles, etc. if required for the RMS system. |
| Total number of agency employees: | 123 (authorized) |
| Total number of administrative personnel: | ~10 who do not use RMS |
| CAD | |
| Current CAD system vendor: | CentralSquare |
| Total Number of dispatch centers: | 1 |
| Number of law agencies dispatched: | 4 |
| Number of fire agencies dispatched: | 17 |
| Number of EMS agencies dispatched: | AMR has their own dispatch, but we have CAD to CAD connection with them. |
| Total annual number of calls dispatched as Incidents in RMS: | 198,580 (this was our total calls for services for all law, fire, medical, support, and animal services in 2025). |
| Report Writing / Field Reporting | |
| Is Law Report Writing / Field Reporting built within the Mobile application, or RMS, or is it a standalone application? | Report Writing is built within the current RMS. |
| Is Law Report Writing / Field Reporting built within the Mobile application, or RMS, or is it a standalone application? | RMS is web based, so it can be accessed from any computer - it is not included in Mobile. |
| Total number of Report Writing/Field Reporting users (full system access): | 123 |
| Total number of Report Writing/Field Reporting users (partial access - view/print only): | 123 |
| Number of Report Writing/Field Reporting users that need to be trained on the new system: | 123 |
| Law RMS | |
| Current Law RMS vendor: | CentralSquare |
| Total number of Law RMS users (full system access) - this could also include Community Service Officers, Fire Department Arson Investigators, Sworn Park Rangers, Regional Auto Theft Task Force, etc.: | 123 |
| Total number of Law RMS users (partial access - view/print only): | 123 |
| Total number of Law Records personnel (clerks/staff): | 9 |
| Total number of Law RMS miscellaneous staff (District Attorney's Office, etc.): | 0 |
| Total number of concurrent Law RMS users on the system at any given time (full access, partial/limited access, administrative access, and view/print-only access): | 123 |
| Number of Law RMS users typically on a shift: | 7-50 people, depending on time of day |
| Number of MS Windows devices using the Law RMS application: | 225 |
| Number of iOS/Android app devices using the Law RMS application: | 12 |
| Number of Law RMS users that need to be trained on the new system: | 123 |
Jail
| Item Number | Module/Description of Requirement | Complies | Does not Comply | Comments |
| General Jail Requirements | ||||
| The proposed solution must have the ability to date and time stamp all application transactions. | ||||
| The proposed solution should capture all required data for Virginia LIDS (Local Inmate Data System) necessary to submit for funding. | ||||
| The proposed solution must check for errors and submit reports to the LIDS board for funding. | ||||
| The proposed solution should provide system generate wristbands, ID cards, and/or wanted/missing posters without the images being integrated to the JMS module. | ||||
| The proposed system must allow the ability to redact certain information prior to dissemination, such as juvenile information. | ||||
| The proposed solution should enable officers to revise data formats to conform to changing federal, state, or other requirements. | ||||
| The proposed solution should allow officers to have the ability to set up “tags” that define the data formats and fields that agencies want to appear on the fingerprint cards. | ||||
| The proposed system must have easily customizable reports for local data while being searchable on any field. | ||||
| The proposed system should allow for templates or officer specific permissions surrounding access and entry. | ||||
| The proposed system should restrict viewing, field entry, printing, and dissemination of information to user based permissions. | ||||
| The proposed system must automatically verify map locations for address entries (ex. Huber addresses or home addresses). | ||||
| The proposed solution should be compatible with other area agencies running the same system. | ||||
| The proposed system must easily allow for partial name searches. | ||||
| The proposed system must easily allow combining of names without automatically saving data as aliases unless desired. | ||||
| The proposed system must have the ability to document Scar, Marks, and Tattoos by type, body part, and location, along with a description; and a way to search SMTs by type, body part, location, and/or description. | ||||
| The proposed solution must have the ability to auto-populate all date and time fields with date and time stamp (e.g., booking date and time or release date and time). | ||||
| The proposed solution must have the ability for system to automatically adjust number sequencing for new calendar years. | ||||
| The proposed solution must have the ability for system to automatically account for daylight savings time and any required parameter changes to daylight savings. | ||||
| The proposed solution must have the ability to automatically calculate the day of week for any entered date. | ||||
| The proposed solution must have the ability to override action date and time stamp and also record actual entry date and time stamp, if making a retroactive entry. | ||||
| The proposed solution must have the ability to attach files to a record. | ||||
| The proposed solution must have the ability to accept digital signatures. | ||||
| The proposed solution must have the ability to accept digital fingerprints. | ||||
| The proposed solution must have the ability to provide word processing capabilities on narrative and comment fields, including, but not limited to: |
• Text wrap
• Paragraph formatting
• Use of bullets and numbering
• Spell check
• Copy and Paste
• Grammar Check
| The proposed solution must have the ability to designate mandatory fields. |
| The proposed solution must have the ability to visually distinguish mandatory fields. |
| The proposed solution must have the ability to perform data validation at time of: |
• Data Entry
• Data Submission
| The proposed solution must have the ability to validate data entry to ensure all required fields have been completed. |
| The proposed solution must have the ability for agency to modify data fields: |
• Add
• Delete
• Rename The proposed solution must have the ability for the Agency to modify data fields:
• During implementation
• Following implementation without vendor intervention
| The proposed solution must have the ability to limit the fields on the screen to only those in use. |
| The proposed solution must have the ability for agency to determine which data fields may be modified after original entry. |
| Jail Website |
| The proposed solution must have the ability to automatically update a jail website at an agency-defined time interval with the following information related to each inmate: |
• Agency Defined Field
• Name
• Booking number
• Gender
• Date of Birth
• Booking Date
• Facility
• Offense
• Address
• Release Date
• Arresting Agency
• Classification (Felony, Misdemeanor, Civil etc.)
• Charges (statute)
• Charge Description(s)
• Bond/Fine
• Court File Number
• Disposition of Charge
• Disposition Date
| The proposed solution must have the ability to search for historical information via the jail website. |
| The proposed solution must have the ability to view a roster of inmates in custody by: |
• Alphabetical Order
• Offense
• Housing location
| The proposed solution must have the ability for user to select an inmate from the roster and view detailed information |
| The proposed solution must have the ability for agency to incorporate hyperlinks on the website. |
| The proposed solution must have the ability to search inmates that are/have been: |
• Released
• In Custody The proposed solution must have the ability to search inmates by:
• Name
• DOB
• DOB Range
• Date Booked
• Date booked Range
• Jail ID
| The proposed solution must have the ability for agency to determine which inmates are eligible for display as part of the jail website (e.g., restrict "under investigation" inmates from displaying on jail website). |
| General JMS Reports |
| The proposed solution must have the ability to search on any data element in the JMS. |
| The proposed system should provide for generation of pre- formatted reports, such as: |
• dissemination log,
• individual arrest report,
• arrest summary report
• arrests by day and hour, etc.
The proposed system must provide pre-formatted reports for condensing jail information, including the following categories:
• Booking Summaries
• Inmate Population
• Jail Events by Day and Hour
• Demographic Reports
• Medical Reports and PREA
| The proposed solution should be able to generate reports for meal restrictions and keep separates. It should also keep track of future events such as work out/work in, transports, notes. |
| The proposed solution must have the ability to generate reports on any defined parameter within the system. |
| The proposed solution must have the ability to generate aggregate reports of inmates across a user defined time range identifying the following information: |
• Gender
• Race
• Location (e.g., facility)
| The proposed solution must have the ability to run comparison reports of any aggregated data (e.g., male vs. female population) |
| Federal Compliance |
| The proposed solution must have the ability to generate a report of Inmates in Custody with Non-US Citizenship for a user- defined date range. |
| The proposed solution must have the ability for jail census reports to be broken down by: |
• Total Population
• Federal Agencies
• Other Counties
• General Population The proposed solution must have the ability to generate a report of release data by date range for convicted and not convicted for the following date ranges:
• Less than 1 Day
• 1 - 2 Days
• 3 - 7 Days
• 8 - 30 Days
• 31 - 180 Days
• 180+ Days The proposed solution must have the ability to generate a report of release data by date range by any of the following parameters:
• Release hours and days
• Day of week
• Gender
| The proposed solution must have the ability for report of release data to include aggregate (total and subtotals). |
| The proposed solution must have the ability for report of release data to include average length of stay. |
| The proposed solution must have the ability to generate confidential reports specific to juveniles. |
| The proposed solution must have the ability for juvenile reports to contain any defined parameter as part of the JMS (e.g., booking information, stay information, gender information, etc.) |
| JMS Master Name Index |
| The proposed solution must have the ability to access master name information in the RMS. |
| The proposed solution must have the ability to provide a single master name index for the JMS and RMS applications, if the agency should desire. |
| The proposed solution must have the ability to distinguish between verified (e.g., positive identification via fingerprints) and unverified records (e.g., names not run through the Livescan system). |
| The proposed solution must have the ability to maintain historical information upon entry of updated information into a master record. |
| The proposed solution must have the ability to automatically update master indices upon entry of booking information. |
| The proposed solution must have the ability to notify a user entering a new master record that there is potentially an existing master record match. |
| The proposed solution must have the ability for user to decide whether to link information to an existing master name record or add a new master name record. |
| The proposed solution must have the ability for user to add a new master name record. |
| The proposed solution must have the ability to link an individual master name record to every event in which the individual is involved or associated. |
| The proposed solution must have the ability to link alias names to an individual master name record. |
| The proposed solution must have the ability to produce a synopsis of all JMS records associated with that person by querying that person's name. |
| The proposed solution must have the ability to view all related records when querying an individual MNI (Master Name Information) record. |
| The proposed solution must have the ability to provide dedicated fields to capture, at a minimum, the following information in the master name index: |
• Name (Last, First, Middle, Suffix)
• Address
• Phone Number
• Social security number
• Age
• Sex
• Race
• Gang affiliation
• Marital Status
• Mugshot
• DL or ID Number
• DL or ID State
• Citizenship
• Ethnicity
• Date of birth
• Physical characteristics
• Eye color
• Hair color
• Height
• Skin Color
• Weight
• Scar, Marks and Tattoos
• Alerts or Cautions
• Akas/Aliases
The proposed solution must have the ability to capture Identification information, including, but not limited to:
• Alien registration number
• Immigration status
• INS number
• USM Number
• DOC Number
• State ID Number
• NCIC Number
• FBI number
• Date of Death The proposed solution must have the ability to associate alias identifiers with a master name record, including, but not limited to:
• Alias names
• False names
• Monikers
• Dates of birth
• Social security number
• Driver's license or ID number
The proposed solution must have the ability to provide user entering a name with a list of potential existing master name records based on a variety of criteria, including:
• Exact spelling
• Partial name
• Sound-alike searching
• Phonetic replacement
• Date of Birth
• Social security number
• Driver's license or ID number
| The proposed solution must have the ability to merge two or more MNI records into one MNI record. |
| The proposed solution must have the ability when linking multiple MNI records to maintain historical information. |
| The proposed solution must have the ability to run a canned report identifying potential duplicate MNI records. |
| The proposed solution must have the ability to store "keep separate" information in the MNI. |
| Flags and Alerts |
| The proposed solution must have the ability for the system to automatically generate a flag for individuals in custody. |
| The proposed solution must have the ability to establish alerts: |
• Visual
• Audible
| The proposed solution must have the ability for agency to define alert types. |
| The proposed solution must have the ability for alerts to contain agency-defined special instructions and response requirements before proceeding. |
| The proposed solution must have the ability for special instructions to be associated with alert type (e.g., special diets). |
| The proposed solution must have the ability for user, when presented an alert, to be presented associated special instructions. |
| The proposed solution must have the ability to associate alerts with the unique identifier of the inmate (e.g., alert carries over to the inmate from a previous incarceration until deactivated by Agency). |
| The proposed solution must have the ability to view history of alerts associated to an inmate. |
| The proposed solution must have the ability to set alerts on an inmate at any time (e.g., booking, post-booking), including, but not limited to: |
• Escape risk
• Suicide risk
• Medical Risk
• Observation Risk
• Violent Risk
• Agency-Defined The proposed solution must have the ability to associate the following with an alert:
• Type of alert
• Person Entering Alert
• Alert Authorizer
• Reason for the alert
• Start date for the alert
• Re-Start dates (e.g., special observations during holidays)
• Alert expiration date
• Associated Special Instructions
| The proposed solution must have the ability to update alerts/flags. |
| The proposed solution must have the ability to cancel alerts/flags. |
| The proposed solution must have the ability to set an alert/requirement on persons who need to be kept separate from other persons. |
| The proposed solution must have the ability to indicate people from whom an inmate should be kept separate. |
| The proposed solution must have the ability to include alerts/requirements in any printed or electronically displayed inmate list. |
| The proposed solution must have the ability to visually distinguish type of alert (e.g.,# = combat alert, & = suicide risk) |
| The proposed solution must have the ability for agency to define the symbols for alerts. |
| The proposed solution must have the ability to include alerts in any screen reference to the inmate. |
| Inmate Booking |
| The proposed solution must have the ability to enter individual booking information. |
| The proposed solution for JMS should accommodate initial and supplemental booking, express (no-name) booking for uncooperative persons, and criminal history booking for non-custody arrests. |
| The proposed system must automatically assign a booking number |
| The proposed solution must allow the format of the booking number be segregated by member agency and/or facility |
| The proposed system should allow interruption of the booking process by allowing it to be saved once the mandatory fields are populated and allow for a continuance later. |
| The proposed system should allow the agency to define restricted entry fields during the booking process |
| The proposed system should allow for a relate a booking to be linked to a law incident by case number |
| The proposed system solution should generate an identification wristband for each inmate booked into the jail. |
| The proposed system should display any pre-existing information about the person being booked, including medical history and fingerprint classification, with any previous risk assessment performed available for review and updating. |
| During the booking process, The proposed system provide the following inmate assessments: |
• Check for Outstanding Civil
• Criminal Wants in the System
• Check for Juvenile Status
• Suicide and Medical Assessment
• Risk Evaluation/Classification
| If the system finds outstanding wants upon booking, the proposed system must allow the user to add the offense to the booking and clear the want. |
| If the system finds an outstanding civil process upon booking, The proposed system must allow the user to enter service information if the process is served at booking. |
| The proposed system must store some information from previous bookings or contacts; such as height, weight, eye color, hair color, address, and emergency contact, place of birth and education level. |
| The proposed system must allow/disallow for juvenile bookings and provide special instructions for the booking of juveniles to appear at the beginning of the booking process. |
| The proposed solution must have the ability to generate a report of all individuals being held at the facility (e.g., roster report). |
| The proposed solution must have the ability for roster report to include any agency- defined parameter selected by the user generating the report (e.g., gender, race, etc.) |
| The proposed solution must have the ability to track juvenile bookings separately from adult bookings. |
| The proposed solution must have the ability for system to automatically generate a unique MNI and/or booking number for each individual. |
| The proposed solution must have the ability for the system to automatically generate the appropriate booking number if MNI exists. |
| The proposed solution must have the ability to accept pre-booking information electronically (e.g., from a Field Reporting application). |
| The proposed solution must have the ability to populate initial booking screen with electronically received pre-booking information. |
| The proposed solution must have the ability to require different booking data entry fields based upon the type of booking (e.g., juvenile has different data fields than adult). |
| The proposed solution must have the ability to re-use previously entered booking information when entering information associated with next of kin (e.g., when entering address for next of kin, The proposed solution must have the ability to import address data from inmate). |
| The proposed solution must have the ability to provide dedicated fields to capture the following booking information including, but not limited to the following Inmate Information: |
• Name
• Date of Birth
• Sex
• Race
• Place of Birth
• Social security number
• Address
• Ethnicity
• US Citizenship
• Phone Number
• Marital Status
• Scars, marks and tattoos
• Assigned Gender
• Gender identify as
• Children
• US Veteran Status (Y/N)
• State ID Number
• FBI Number
• Literacy Information/Grade Completed
• Primary Language
• Religion
The proposed solution must have the ability to capture the following data:
• Alias
• Next of Kin Name
• Next of Kin Address
• Next of Kin Relationship
• Next of Kin Phone Number
• SSA Class
• Emergency Contact
• Occupation
• Employer
• Indigent
• Disability/SS
• Parole/Probation
• Classification The proposed solution must have the ability to capture the following Appearance Information:
• Hand Use
• Skin Color
• Physical Condition
• Scars, Marks, Tattoos
• Height
• Weight
• Hair color
• Eye color
• Is a Twin
The proposed solution must have the ability to capture the following Arresting Information:
• Arresting Agency
• Arresting Officer
• Arrest Location
• Case Number
• Date/Time of Arrest
• Charges
• FIPS Code
• LIDS code for each charge
• Warrant Number
• Offense Tracking Number
• Count
• Multiple Clearance Indicator
• Court charge if different The proposed solution must have the ability to record the following information specific to a juvenile arrest:
• School Attending
• Grade
• School of residence
• Counseling Information
• Parent/Guardian Information
• In Foster Care
| The proposed solution must have the ability to re-use information from a past booking for the same person. |
| The proposed solution must have the ability for classification to limit specific characters. |
| The proposed solution must have the ability to display any alerts/flags associated with the individual. |
| The proposed solution must have the ability to query the following from within the booking module: |
• VCIN/NCIC
• Law Enforcement RMS
• Civil
• Warrants
| The proposed solution must have the ability to provide the user with a Choice to unlink or delete arrest from booking if shared Arrest (RMS and JMS) |
| The proposed solution must have the ability to delete a booking made in error (with appropriate security level) and capture the reason for the deletion. |
| The proposed solution must have the ability to generate a report showing deleted bookings for a user-defined date and time range and includes the following fields: |
• Booking Number
• Booking Name
• User ID/Name
• Time and date stamp
• Reason for deletion
• If records was notified (shared system)
| Booking Reports |
| The proposed solution must have the ability to prepare a daily booking log listing all inmates booked during a user-defined period. |
| The proposed solution must have the ability to generate a booking report with any combination of the following information: |
• Assigned Gender
• Identifying Gender
• Race
• Residency
• Arresting Agency
• Hour of Date Booked
• Day of Week The proposed solution must have the ability to generate a report on the above mention fields plus ages as shown below:
• 0 - 21
• 22-30
• 31 - 50
• 50+ The proposed solution must have the ability to generate a report on the above mention fields plus priors as shown below:
• 0
• 1
• 2 to 5
• 6 to 9
• 10 to 19
• 20 +
| Questionnaires |
| The proposed solution must have the ability for agency to define multiple types of questionnaires (including questions and valid answers), including but not limited to: |
• Classification
• Medical
• Suicide
• PREA
• Agency-defined
| The proposed system must provide suicide, medical, and risk assessment questions that are agency- definable, with no programming involved. |
| The proposed solution must have the ability for the Agency to create and modify questionnaires: |
• During implementation
• Following implementation, without vendor intervention.
| The proposed solution must have the ability to support conditional logic in which subsequent questions are determined by previous answers. |
| The proposed solution must have the ability to maintain historical information for questionnaires if questionnaires are modified. |
| The proposed solution must have the ability for an officer to complete a questionnaire without requiring the inmate to be booked (e.g., prior to booking, a deputy completes a visual observation report) AND the proposed solution must have the ability to complete a partial booking later (e.g., uncooperative subject). |
| The proposed solution must have the ability when booking an inmate, to access and import previously completed questionnaires OR limit access. |
| The proposed solution must have the ability for questionnaires to include agency defined language upon printing. |
| The proposed solution must have the ability to document the following related to each questionnaire: |
• Inmate Name
• Person conducting questionnaire
• Date/Time •Signature of inmate The proposed solution must have the ability for questionnaire answer fields to include:
• Drop Down Menus (e.g., Yes/No/Refused)
• General Comments Field
• Comments field specific to each question
• Generate automatic jail flag/alert based on answer
| The proposed solution must have the ability to notify user during booking required questionnaires that must be completed. |
| Mugshots |
| The proposed solution must have the ability to link a Mugshot to an MNI |
| The proposed solution must have the ability to associate all images with a specified inmate's file, along with the date and time at which it was recorded. |
| The proposed solution must have the ability to keep a historical record of Mugshots (e.g., for each booking). |
| The proposed solution must have the ability to trigger print of Mugshots |
| The proposed solution must have the ability to print an Inmate Form that includes an inmate's Mugshot, name, name ID and booking number. |
| The proposed solution must have the ability for the booking sheet to include fields for manual data entry (e.g., hand written) that categorizes the following: |
• Crime
• Sentencing Term
• Assignment
• Health Restrictions
• Security Restrictions
• Assignment History
• Detainer Information
• Sick Call
• Special Watch
• Holds
• Comments
• Conduct History
| The proposed system must allow for multiple entries of body anomalies, with photos (i.e. tattoos and piercings). |
| The proposed solution should have a standalone photo capture station and/or utilize a third party solution. This photo must be connected to the current booking for easy reference/retrieval. |
| The proposed solution must have the ability for Inmate Form information fields to be populated with information previously entered into the system. |
| The proposed solution must have the ability to generate labels that identify the following inmate information: |
• Mugshot
• Booking Number
• Inmate Name
• Master Name ID
• Height
• Weight
• Eye Color
• Hair color
• Gender
• Race
| The proposed solution must have the ability to display the most recent Mugshot when a query returns an MNI record. |
| The proposed solution must have the ability to export a Mugshot with identification information. |
| The proposed solution must have the ability to export a Mugshot without identification information. |
| The proposed solution must have the ability for booking photos to be made available to the Mobile application. |
| The proposed solution must have the ability to preview an image prior to final image acceptance. |
| The proposed solution must have the ability to track history of an individual's Mugshots. |
| The proposed solution must have the ability to index photos of persons based on basic features including, but not limited to (In conjunction with FBI guidelines): |
• Name
• Age Range
• Gender
• Race
• Hair color
• Eye color
• Height
• Weight
• Height Range
• Weight Range
• Scars, marks, and tattoos
• Physical characteristics (glasses, facial hair etc.)
| The proposed solution must have the ability to separately capture scars, marks and tattoos and associate these photos with a Mugshot. |
| The proposed solution must have the ability to capture an unlimited number of scars, marks and tattoos. If limited, indicate the maximum number of permissible in the "comments" section. |
| The proposed solution must have the ability to query Mugshots by indexed features. |
| The proposed solution must have the ability to crop photographs. |
| The proposed solution must have the ability to support an unlimited number of photos associated with an individual. |
| The proposed solution must have the ability to view photos by: |
• List
• Thumbnail
| The proposed solution must have the ability to create a BOLO with mugshot and associated information for distribution. |
| Inmate Property |
| The proposed solution must have the ability to auto-populate the property record with information from the booking module, as appropriate. |
| The proposed solution must have the ability for Inmate to sign completed property report verifying accuracy. |
| The proposed solution must have the ability to generate and complete an inmate property report prior to booking completion. |
| The proposed solution must have the ability that when booking an inmate, to access and import previously completed inmate property reports. |
| The proposed solution must have the ability to maintain historical information regarding inmate property by: |
• Bin number
• Facility
• Shelf
• Room
• Inmate Name
• Book ID
• Name ID
| The proposed system should allow the entry of virtually unlimited items of personal property taken from the inmate and print a receipt that both the inmate and the jailer sign, confirming property and cash taken from the inmate. |
| The proposed system should accommodate the entry of the property storage location/locker and warn the user if the location is already being used for another inmate's property. |
| The proposed solution must have the ability to support a parent-child property tracking format (e.g., multiple bags assigned to a single bin). |
| The proposed solution must have the ability to assign property to the child container (e.g., assigning to the bags within the bin). |
| The proposed solution must have the ability to assign property to a facility/room/shelf/bin if need be |
| The proposed solution must have the ability to transfer property across facilities. |
| The proposed solution must have the ability to record individual conducting property search. |
| The proposed solution must have the ability to provide dedicated fields to capture any combination of the following: |
• Bin Number/Bag Numbers
• Property Type
• Property Description
• Color
• Quantity
• Value
| The proposed solution must have the ability for agency to assign additional Bin Numbers/Bag Numbers, rooms, shelves, bins as needed |
| The proposed solution must have the ability to support alphanumeric characters for bin/bag, room, and shelf numbers. |
| The proposed solution must have the ability to assign separate bin numbers to each facility. |
| The proposed solution must have the ability to capture electronic signature |
| The proposed solution must have the ability to inventory property by: |
• Facility
• Room
• Shelf
• Inmate Name
• Date/Time Range
• Bin/Bag
| The proposed solution must have the ability to attach files to property record. |
| The proposed solution must have the ability to print property sheet. |
| The proposed solution must have the ability to add property after initial intake. |
| The proposed solution must have the ability to track chain of custody of property. |
| The proposed solution must have the ability to support digital signatures. |
| The proposed solution must have the ability to record history of disposed property. |
| The proposed solution must have the ability to record an audit trail of all actions taken regarding property (e.g., transfer, intake, disposal, etc.) |
| The proposed solution must have the ability to generate a receipt of inmate property: |
• Intake
• Release The proposed solution must have the ability for receipt to include:
• Inmate Name
• Inmate Signature
• Date/time
• Book ID
• Property Information
• officer releasing
• Witness
| The proposed solution must have the ability to notify user of property to be released as part of inmate release. |
| The proposed solution must have the ability to record receipt of released property. |
| The proposed solution must have the ability to release property one at a time. |
| The proposed solution must have the ability to release all property at one time. |
| The proposed solution must have the ability to release "child" containers at a single time (e.g., not releasing entirety of property, but only portions of property). |
| The proposed solution must have the ability to track history of property bin use after release. |
| The proposed solution must have the ability to record inmate acceptance or refusal of property at time of release. |
| The proposed solution must have the ability to capture signature of person receiving property |
| The proposed solution must have the ability to release property to someone that is not the inmate. |
| The proposed solution must have the ability to record property release information, including: |
• Property Information
• Property Released to Information
• officer releasing property
• Person property being released to
| The proposed solution must have the ability to record all items issued to an inmate. |
| The proposed system should allow standard jail property issue (e.g. blankets, sheets, etc.) with different issues definable for male and female inmates and risk factors. |
| The proposed system should provide for recording of return of jail-issued property upon release. |
| The proposed system should enable the user to limit issue based on risk assessment. |
| The proposed solution must have the ability to generate a report of all items issued to an inmate. |
| The proposed solution must have the ability to track the following related to each item: |
• Color
• Size
• Description
• Type
• Cost
• Expiration Date
• Quantity
| The proposed solution must have the ability to generate a report notifying users of items they are using which are expiring soon |
| The proposed solution must have the ability to notify the user which items that are currently in inventory that are expiring |
| The proposed solution must have the ability to alert a user if items have expired. |
| The proposed solution must have the ability to alert a user if an item has previously been issued (e.g., inmate is only 1 item per week, they are requesting 2nd item that week). |
| The proposed solution must have the ability to assign a zero dollar cost to an item issued. |
| The proposed solution must have the ability to manage an inventory of items not yet issued. |
| The proposed solution must have the ability for agency to set thresholds of inventory. |
| The proposed solution must have the ability to alert the user if items fall below defined threshold. |
| The proposed solution must have the ability to generate inventory reports by the following parameters: |
• Date
• Time
• Associated Inmate
• Inventory Type
| Inmate Classification |
| The proposed solution must have the ability to interface with 3rd party classification system if the agency so desires. |
| The proposed solution must have the ability to provide an inmate classification system. |
| The proposed solution must have the ability to accommodate a temporary classification. |
| The proposed solution must have the ability to provide different algorithms for gender. |
| The proposed solution must have the ability to manually input a classification. |
| The proposed solution must have the ability to identify inmates that have not been classified or that need to be reclassified. |
| The proposed solution must have the ability to set parameters as to when reclassification is due |
| The proposed solution must have the ability to identify inmates that are mishoused (i.e., placed in a location that does not meet their classification). |
| The proposed solution must have the ability to capture officer name completing classification. |
| The proposed solution must have the ability to capture reason if classification is over-written or done manually |
| The proposed solution must have the ability for user to supplement responses to classification questions with narrative text entry (e.g., explanations). |
| The proposed solution must have the ability for agency to define the algorithm that generates classification code recommendations based on responses to the classification questions. |
| The proposed solution must have the ability to assign inmates to housing based on: |
• Classification
• Identifying Gender
• Keep Separate Status
| The proposed solution must have the ability to override system classification recommendation. |
| The proposed solution must have the ability to document Administrator approval of override. |
| The proposed solution must have the ability to require an explanation (free-text narrative) when system classification is overridden. |
| The proposed solution must have the ability to maintain a history of the inmate’s classification for all bookings, present and past. |
| The proposed solution must have the ability to accept an unlimited number of reclassifications. |
| The proposed solution must have the ability to set parameters as to when reclassification is due |
| The proposed solution must have the ability to establish a periodic review of classification based on agency-defined time limits. |
| The proposed solution must have the ability to record re-classification requests. |
| The proposed solution must have the ability to generate a report of inmates due for classification review. |
| The proposed solution must have the ability to maintain an audit trail of all classification and reclassification actions. |
| The proposed solution must have the ability to track a classification appeal filed by an inmate. |
| The proposed solution must have the ability to provide an alert if inmate records have any "Keep Separate" restrictions. |
| The proposed solution must have the ability to prevent any inmates that should be kept separate from being placed in the same housing unit, with a manual override if needed. |
| The proposed solution must have the ability to capture a reason as to why a "keep separate" alert was ignored if an officer does that. |
| The proposed solution must have the ability to generate a Primary Classification Report that includes any combination of the following information: |
• Inmate Name
• Booking Number
• Aliases
• Date of Birth
• Cell Location
• Booking Date
• Address
• Phone Number
• Sex/Race
• Marital Status
• Social security number
• Height/Weight
• Scars, marks and tattoos
• Next of Kin
• Occupation
• Employer
• Employer address
• Employer Phone
• Charges
• Discipline record
• Assigned Gender
• Identifying Gender
The proposed solution must have the ability to generate the following reports:
• Listing by next review date
• Listing by assessment date
• Listing by assessment type
• Listing by classification officer
• Listing by Booking date
| The proposed solution must have the ability to provide a visual indication of the inmate's classification on any screen reference to the inmate. |
| Inmate Housing |
| The proposed solution must have the ability to define housing locations as: |
• Cell Blocks/POD
• Floor
• Cell Number
• Bed
• Facility
• Medical
• Temporary Locations
• Supported Gender (e.g., female only)
• Special Watch
• Holding
| The proposed solution must have the ability to associate a narrative with a housing location (e.g., Cell Number - Available for female holding). |
| The proposed solution must have the ability to identify and display all available beds within a facility that meet the inmate’s needs (e.g., in terms of classification, gender, special handling needs, alerts, etc.). |
| The proposed solution must have the ability to recommend a housing location, based on an Agency-defined algorithm. |
| The proposed solution must have the ability to assign classification to all cells |
| The proposed solution must have the ability to define maximum number of occupants for each cell. |
| The proposed solution must have the ability for booking officer to override housing recommendations. |
| The proposed solution must have the ability to temporarily suspend the ability of a bed. |
| The proposed solution must have the ability to change assignments of facility, Pod/Block, cell, and/or cell letter, and record the reason for the change. |
| The proposed system should allow the agency to pre-define jail cells and capacities for the purpose of inmate location assignment. |
| The proposed system must accommodate multiple housing facilities in determining housing assignment. |
| The proposed system must accommodate restriction in housing by gender. |
| The proposed system must account for an inmate’s assigned housing location, as well as temporary locations in/out of the facility, allowing a user to check on an inmate's location by a name inquiry |
| The proposed solution must have the ability to maintain historical information of facility, Pod/Block, and cell. |
| The proposed solution must have the ability to maintain a history of an inmate’s housing assignment and movements for: |
• Present bookings
• Past bookings
| The proposed solution must have the ability to link housing assignments to an inmate's record. |
| The proposed solution must have the ability to generate a consolidated report of an individual inmate's housing history. |
| The proposed solution must have the ability to inquire on bed ability by: |
• Facility
• Block/POD
• Classification
• Cell Type
The proposed solution must have the ability to generate a report on all inmates that have shared housing for a user-defined date range, including but not limited to:
• Cell
• Block
• Facility
| The proposed solution must have the ability to monitor booking and releases on a single screen (e.g., housing dashboard). |
| The proposed solution must have the ability for housing dashboard to automatically refresh/update. |
| The proposed solution must have the ability to manually refresh the housing dashboard. |
| The proposed solution must have the ability to sort on any column in the booking dashboard. |
| The proposed solution must have the ability to exclude inmates from the booking dashboard if the agency should desire. |
| The proposed solution must have the ability to provide drill down capabilities from the housing dashboard screen (e.g., click on an inmate to view inmate details) |
| The proposed solution must have the ability to separate the booking dashboard by housed facility. |
| Jail Billing |
| The proposed solution must have the ability to create detailed housing invoices/billings for federal, state and local agencies based on agency-defined parameters |
| The proposed system should provide the ability to enter the responsible agency for billing purposes. |
| The proposed system should have the ability to automatically compute agency billings for housing of inmates from other agencies at a specified rate. |
| The proposed solution must have the ability to export and/or interface with a 3rd party vendor |
| The proposed solution must have the ability for housing invoices to include any combination of the following: |
• Identifying Number
• Days Billing
• Dollar Amount
• Total
• Inmate Name
• Booking Date
• Release Dates
• Agency-identified field
• Begin Date Sentencing
• End Date Sentencing
| The proposed solution must have the ability to deduct days from the invoice/billing if an inmate is out of the facility. |
| The proposed solution must have the ability to export billing information to an excel spreadsheet. |
| The proposed solution must have the ability to convert invoice to .pdf format. |
| The proposed solution must have the ability to generate outside agency Inmate invoices. |
| The proposed solution must have the ability for system to calculate billable amount due by an agency-defined reimbursement rate. |
| Key Tracking |
| The proposed solution must have the ability to track the distribution of keys. |
| The proposed solution must have the ability to Interface with 3rd party vendor if the agency so chooses |
| The proposed solution must have the ability to record the following information related to the distribution of keys: |
• Name of officer receiving key
• Rank
• Title
• Division
• Department
• Key number
• Date/Time Issued
• Date/Time Returned
| The proposed solution must have the ability to associate an unlimited number of keys with an individual. |
| Inmate Worker Management /Trustee/Huber Work Release |
| The proposed solution must have the ability to assign an inmate to work position. |
| The proposed solution must have the ability to record approval for inmate worker position. |
| The proposed solution must have the ability to generate a report of approved inmates for work positions. |
| The proposed solution must have the ability to record location of work positions. |
| The proposed solution must have the ability to generate a report that identifies a worker and the location of his/her corresponding work location. |
| The proposed solution must have the ability to generate a report of work locations and corresponding workers at that location. |
| The proposed solution must have the ability to record an inmate's request for work. |
| The proposed solution must have the ability to record approval or denial of request for work. |
| The proposed solution must have the ability to define work privileges for an inmate (e.g., location of work, type of work, etc.) |
| The proposed solution must have the ability for agency to define an algorithm that associates number of hours worked with credited days served (e.g., inmate works 24 hours total, they are granted 1 day of credit served). |
| The proposed solution must have the ability to track inmates that are serving time outside of the facility. |
| The proposed solution must have the ability to approve/deny an inmate’s request for Huber Privileges |
| The proposed solution must have the ability to document the following related to an inmate's Huber request: |
• Date and Time
• Person Approving/Denying Request
• Outcome
• Comments
| The proposed solution must have the ability to record if the inmate was approved for work, counseling, child/family/parent care, medical, school or work crew. |
| The proposed solution must have the ability to record if an inmate is serving time at Portage County facility for a sentence from another county. |
| The proposed solution must have the ability to record inmate appointments outside of agency facilities. |
| The proposed solution must have the ability to document the following related to each appointment: |
• Location
• Date
• Time
• Inmate
• Verification of Attendance
• Purpose/Reason
• Mode of Transportation
• Person Verifying Attendance
• Person Approving Request
| The proposed solution must have the ability to provide unlimited comments fields related to verification fields. If limited, indicate the maximum permissible in the "comments" field. |
| The proposed solution must have the ability to record inmates mode of transportation. |
| The proposed solution must have the ability to record driver of transportation, including: |
• Name
• Driver's License Number
• Driver's License Type (i.e., Occupational)
| The proposed solution must have the ability to alert user if driver does not have appropriate license following automated NCIC/VCIN check |
| The proposed solution must have the ability to provide electronic time keeping for workers (e.g., inmate worker card swipe). |
| The proposed solution must have the ability for time keeping system to automatically calculate hours worked for an agency-defined time period. |
| The proposed solution must have the ability for time keeping system to incorporate agency parameters (e.g., travel time) to compare against actual time worked vs. scheduled time worked. |
| The proposed solution must have the ability to provide a notification when actual time worked varies from scheduled time worked. |
| The proposed solution must have the ability to capture drug/alcohol screening results, including but not limited to: |
• Inmate Name
• Person/Agency conducting test
• Date
• Results
• Comments The proposed solution must have the ability to capture Huber violations, including but not limited to:
• Inmate
• Violation
• Date
• Comments
| The proposed solution must have the ability to record if an inmate has been revoked from Huber (including comments field). |
| The proposed solution must have the ability to record that all required Huber paperwork was signed by the inmate and the person that witnessed the inmate’s signature. |
| Daily Activity Log |
| The proposed solution must have the ability to maintain an electronic log for reporting activities and information on inmates to other staff. |
| The proposed solution must have the ability to add unlimited narrative to the electronic log (if limited, indicate the maximum permissible in the "comments" section). |
| The proposed solution must have the ability to capture the following related to the Daily Activity log: |
• Date/Time of Entry
• Person entering data
• Cell
• Inmate information (name, booking number)
• Location
• Log Type
| The proposed solution must have the ability to generate user-defined reports with any combination of data captured in the activity log. |
| Inmate Incidents |
| The proposed solution must have the ability to record jail incidents |
| The proposed solution must have the ability for incident report to include the following information: |
• Facility
• Name
• Role
• Officer
• Witness
• Inmate
• Staff
• Force
• Force description (Taser, ECD etc.)
• Chemical Agent
• Reaction Team Deployed (y/n)
• Restraint Chair Used (y/n)
• Injuries
• Injured Party
• Weapons
•…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .