RFP_CAD-RMS-JMS_Scope-Matrix.xlsx
XLSX spreadsheet 267 KB Posted
- Attached to
- Public Safety CAD/RMS/JMS System State and local contract opportunity
- Solicitation number
- 2025-911-01
- Issued by
- Sedgwick County, Colorado
About this file
The document is a comprehensive Request for Proposal (RFP) from Summit County 911 Communications Center (SC911) in Colorado for an integrated Public Safety Software system, encompassing Computer Aided Dispatch (CAD), Mobile Data Computing (MDC), Records Management System (RMS), and Jail Management System (JMS). The solicitation seeks a vendor to provide a fully integrated solution that supports multiple public safety agencies within the county's governance structure, with the goal of enhancing emergency response and preparedness. The RFP includes an extensive matrix of detailed functional requirements across multiple modules, requiring vendors to provide specific responses indicating compliance, potential modifications, or alternative approaches for each requirement.
The procurement does not specify explicit pricing terms, total contract value, or funding sources within this document. Instead, the RFP focuses on comprehensive technical requirements, with vendors expected to demonstrate system capabilities through a detailed response matrix. The document outlines extensive technical specifications across modules including system administration, security, data management, reporting, interfaces, and specialized functionality for law enforcement, fire, and corrections operations. Vendors are instructed to use specific response codes (Compliant, Non-Compliant, Alternative, Modification, Third-Party) when addressing each requirement, with the understanding that non-compliance is not automatically disqualifying. The RFP emphasizes the need for a flexible, configurable system that can support multiple agencies' unique workflows while maintaining interoperability and adherence to state and federal standards.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| RFP_CAD-RMS-JMS_Agency-Background.pdf | ||
| RFP_CAD-RMS-JMS_2025.pdf | ||
| RFP_CAD-RMS-JMS_SCG Vendor Accessibility Checklist.docx | DOCX document |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Vendor Instructions
Response Instructions
Detailed functional requirements for the system desired are provided in this workbook. The following codes should be used where appropriate to indicate the ability of the proposed system to meet the needs as described. Codes other than "C" are not automatic disqualifiers and will be used in assessing submissions during the evaluation phase.
| Code | Response |
| C | The proposed system fully COMPLIES with requirement; indicate in the "Comments" column if this is not part of a standard/base offering. |
| N | The proposed system does NOT comply with requirement. |
| A | Proposer recommends an ALTERNATIVE, no-cost way to meet the requirement; proposer must provide an explanation in the "Comments" column. |
| M | Proposed system requires a software MODIFICATION to comply with requirement, but does not require third-party software; proposer must provide an explanation in the Comments column and list additional costs (cross-referencing the requirement) in the Cost Proposal. |
| T | Proposed system requires THIRD-PARTY software to comply with requirement; Proposer must provide an explanation in the Comments column and list additional costs (cross-referencing the requirement) in the Cost Proposal. |
Place the appropriate Response Code in the column next to each requirement. Where applicable and where requested, provide additional information that describes the way in which the proposed system fulfills the given requirement or how an alternative to the requirement will meet the Agencies' needs. Short responses may be provided in the "Comments" column, while longer answers may be provided on a separate page. Do not insert rows into any portion of the document or modify the numbering or description of the functional requirements. Please respond to each requirement. Omitted responses will be evaluated as response codes of "N" (proposed system does not comply with requirement).
Include your firm's completed MS Excel file (*.xlsx) in your proposal response. Do not reformat/submit as a .pdf file, change any formating, or embedded within an MS Word version of your proposal.
| Assumptions | |
| The term "any field" implies any available field. If the word "any" in a requirement is too inclusive, and you can provide the functionality but not to the extent that you believe the word "any" implies, please indicate the limitations. | |
| Definitions | Definitions |
| Agency | Summit County 911 Communications Center (SC911) |
| Agency-defined | Configurable by each customer independently |
| Automatically | Occurs without user intervention |
| Participating Agency | Public Safety agencies within the SC911 governance |
| System | Refers to the collective whole of all software applications |
| User | A person conducting a transaction in the system |
General Vendor Info
| Item Number | Requirement/Request | Comments |
| General Vendor Information | ||
| 1 | Describe your company’s corporate structure, e.g. public, private, governance, etc. | |
| 2 | Provide a recent history of mergers / acquisitions and any that are pending that are public knowledge. | |
| 3 | How long has your company been providing the proposed solution? | |
| 4 | How many employees in your company are: Full-time? Part-time? Contract? | |
| 5 | How many employees are dedicated to provide support and escalation services for the proposed solution? | |
| 6 | Are there any lawsuits, federal, state or local tax liens, or any potential claims or liabilities against you, your company or the officers of the company at this time or within the last three years? If so, please explain. | |
| 7 | How long has the version of the proposed solution been released (years / months)? | |
| 8 | How many customers do you have using the proposed solution? | |
| 9 | How many Colorado customers do you have using the proposed solution? | |
| 10 | Was the proposed solution created by your company or acquired through merger, acquisition, etc.? | |
| Quote Information | ||
| 1 | Is your quote based on concurrent, named user or site license? | |
| Implementation | ||
| 1 | Is there anything in the next 18 months that could affect/ delay when we could implement? | |
| 2 | How soon after contract signing does the kick off normally occur? | |
| 3 | What is the process for gathering and documenting our organization's specific workflow and needs? | |
| 4 | How will you handle data migration from our existing systems to the new software? Are there any limitations or considerations we should be aware of? | |
| 5 | What resources or support will be required from our organization during the implementation? How can we best prepare for this? | |
| 6 | What is the suggested amount of resource hours needed from SC911 staff during the project for a successful implementation? | |
| 7 | Can you provide information about your project management approach? How will you ensure effective communication and coordination throughout the implementation? | |
| 8 | What is the process for your project team to familiarize themselves with Summit County business processes? | |
| 9 | How will you handle customization or configuration of the software to suit our organization's specific needs? | |
| 10 | What testing procedures and quality assurance measures will be in place to ensure the software functions correctly? | |
| 11 | What post-implementation support services do you offer, and for how long? Are there any additional costs associated with ongoing support? | |
| 12 | What are potential risks and issues that may arise during the implementation? Do you have contingency plans in place? | |
| 13 | What is your approach to change management and user adoption? How will you ensure that our employees embrace and effectively use the new software? | |
| 14 | Describe the timing and process used for Final Acceptance testing and approval. | |
| Training | ||
| 1 | How will user training be incorporated into the implementation process? Will it occur concurrently or after the software is fully deployed? | |
| 2 | Can you provide an overview of the training curriculum and its duration? | |
| 3 | How is the training delivered? Is it conducted on-site, remotely, or through self-paced online modules? | |
| 4 | Who are the trainers and what are their qualifications and experience with the software? | |
| 5 | What resources will be provided to support the training process (e.g., documentation, user manuals, video tutorials)? | |
| 6 | Will the training be customized to suit our organization's specific needs and workflows? | |
| 7 | Will the training be provided for all user roles or specific roles within our organization? | |
| 8 | How will you ensure ongoing support and assistance after the training program is completed? | |
| 9 | Do you offer any certification programs or assessments to validate user proficiency? | |
| 10 | Are there any prerequisites or recommended knowledge/skills for trainees before starting the program? | |
| 11 | How do you handle trainees who may require additional support or have difficulty grasping the software during training? | |
| 12 | What are the training options for new employees that start after the formal implementation/ training timeframe? | |
| 13 | What feedback mechanisms are in place to evaluate the effectiveness of the training program and make necessary improvements? | |
| Support & Maintenance | ||
| 1 | After go-live, at what point are we transferred over to the support team? | |
| 2 | Are members of the support team CJIS trained and background checked to work unescorted, either in person or virtually? | |
| 3 | After go-live are we provided a a dedicated account manager or support lead to help with general non support type questions/ escalation needs? | |
| 4 | What are your support hours and time zone coverage? | |
| 5 | What is the average time it takes to resolve a support ticket assigned to a support analyst? | |
| 6 | What is the average time it takes to resolve a support ticket that is assigned to development? | |
| 7 | Can you describe your quality assurance/ testing process for updates/ releases? | |
| 8 | How long does it take for a new update/release to be implemented and used in the production/live version of the proposed solution? | |
| 9 | For hosted/ SaaS solutions, are updates applied automatically? Could we opt out/ postpone an update? | |
| 10 | Would the SC911 IT staff need to be involved with the implementation of an update/release? If yes, what would their involvement be? | |
| 11 | Are SC911 IT staff able to update without vendor support? | |
| 12 | Do you offer release notes? How are they accessed? | |
| 13 | How are we notified of upcoming releases? | |
| 14 | What type of assistance is NOT covered under your support and maintenance agreement? | |
| 15 | What are the available channels for raising support tickets or inquiries (e.g., phone, email, chat, online portal)? | |
| 16 | What is the escalation path provided to customers? | |
| 17 | What is your approach to knowledge sharing and customer training? Do you provide documentation or training materials? | |
| 18 | What is the process for customers to submit enhancement requests? How are enhancement requests selected and prioritized? | |
| 19 | Describe opportunities where your company organizes opportunities for users to get together to discuss how they use the product, and the product roadmap. |
&A
General Technical
| Item Number | Requirement/Request | Comments |
| Cloud Computing | ||
| 1 | Is the proposed solution native-cloud based, cloud hosted, hybrid cloud, or on-premise? | |
| 2 | Describe connectivity requirements to the cloud. | |
| 3 | Describe and define up-time reliability (e.g., 99.999%) | |
| 4 | Describe the geo-redundancy of your cloud components. | |
| 5 | If cloud-native/cloud/or hybrid-cloud, can your solution be deployed in a customer owned cloud tenant? | |
| 6 | Can customer administrators access/administer systems and data and cloud resources | |
| 7 | Can customer administrators access and perform ad-hoc queries against cloud host databases? | |
| 8 | Can customer administrators access real-time data via ad-hoc queries? | |
| 9 | Does your solution provide real-time CFS and Resource feeds which can be used in third-party applications and workflows? | |
| Server Environment (as applicable) | ||
| 1 | Describe the number of concurrent users supported. | |
| 2 | Describe the operating system(s) supported. | |
| 3 | Describe any supported virtualization platforms (vmware, nutanix, proxmox, citrix, hyper-v, etc.) | |
| 4 | Describe the number of processors required. | |
| 5 | Describe the number of cores required. | |
| 6 | Describe total memory required. | |
| 7 | Describe required/recommended storage. | |
| 8 | Describe specific drive configurations. | |
| 9 | Describe specific RAID requirements. | |
| 10 | Describe additional requirements. | |
| Required On-Prem Equipment (as applicable) | ||
| 1 | Describe the number of concurrent users supported. | |
| 2 | Describe any required on-prem hardware, including the operating system(s) supported, processors, cores, memory, and storage requirements. | |
| 3 | Describe any required on-prem virtual environments, including the operating system(s) supported, processors, cores, memory, and storage requirements. | |
| 4 | Describe specific drive configurations. | |
| 5 | Describe specific RAID requirements. | |
| 6 | Describe additional requirements. | |
| Network Communications | ||
| 1 | Describe your application (Client to Server) bandwidth requirement (if different from mobile to non-mobile applications then list differences). | |
| 2 | Describe your Application (Client to Server) latency requirement (if different from mobile to non-mobile applications then list differences). | |
| 3 | Describe your backup (Server to SAN) Bandwidth requirement. | |
| 4 | Describe any other network communication requirements. | |
| 5 | Describe your firewall requirements. | |
| 6 | Describe client functionality when communication to server fails. | |
| Dispatch Workstations | ||
| 1 | Describe the operating system(s) supported. | |
| 2 | Describe the hardware requirements, including the size and number of processors, memory, and storage. | |
| 3 | Describe the recommended screen size/number/resolution. | |
| 4 | Describe the requirements for network cards. | |
| 5 | Describe any additional requirements. | |
| Non-Dispatch Workstations | ||
| 1 | Describe the operating system(s) supported. | |
| 2 | Describe the hardware requirements, including the size and number of processors, memory, and storage. | |
| 3 | Describe the recommended screen size/number/resolution. | |
| 4 | Describe the requirements for network cards. | |
| 5 | Describe any additional requirements. | |
| Mobile Computer/Tablet Requirements | ||
| 1 | Describe the operating system(s) supported. | |
| 2 | Describe the hardware requirements, including the size and number of processors, memory, and storage. | |
| 3 | Describe the recommended screen size/number/resolution. | |
| 4 | Describe the requirements for network cards and/or connectivity options. | |
| 5 | Describe any additional requirements. | |
| Stationary Printer Requirements | ||
| 1 | Describe the make/model requirements/recommendations. | |
| 2 | Describe any feature sets required. | |
| 3 | Describe the recommended memory size. | |
| 4 | Describe any additional requirements. | |
| Mobile Printer Requirements | ||
| 1 | Describe the make/model requirements/recommendations. | |
| 2 | Describe any feature sets required. | |
| 3 | Describe the recommended memory size. | |
| 4 | Describe any additional requirements. | |
| Software Requirements | ||
| 1 | List all the recommended and required software necessary to operate the Application Software. Include the manufacturer, version, and any hardware specifications. Add rows below as needed. | |
| Description |
| Data Conversion | |
| 1 | Do you offer legacy data conversion? If so, for what applications: |
| 2 | CAD |
| 3 | RMS |
| 4 | JMS |
| 5 | If any data does not convert, what is the legacy data solution? |
| 6 | How are code discrepancies handled? |
| 7 | How are active cases handled in the conversion? |
| Database Application | |
| 1 | Is one centralized database used for all applications? |
| 2 | Describe the backend database used. |
| 3 | Describe the front-end program used. |
| 4 | Describe the level of system and db administrator access to the database systems. |
| Upgrades and Updates | |
| 1 | Briefly describe the upgrade process. |
| 2 | Are upgrades performed by the client or the vendor? |
| 3 | What is the expected upgrade and patch frequency? |
| 4 | Do you mandate installation of new releases? How Often? |
| 5 | Do you mandate the installation of updates? How Often? |
| 6 | Do updates need to be scheduled or automatically pushed? |
| 7 | Are users required to be local admin on PC to run updates? |
| 8 | How many versions are supported and what is end of life formula? |
| Multiple Environments | |
| 1 | Do you provide multiple environments, including: |
• Production
• Test/Development
• Training
| 2 | Describe your backup/Disaster Recovery plan. |
| 3 | Does your solution have the ability to modify the test environment and transfer modifications to the production environment? |
| 4 | Does your solution have the ability to modify the production environment and transfer modifications to the test environment? |
| 5 | Does your solution support the ability for an user to operate both a production, test and training environment simultaneously? |
| 6 | Does your solution have the ability to provide visual distinction of which environment the user is operating? |
| Backup Requirements | |
| 1 | Does your solution provide full nightly backups? |
| 2 | Does your solution support the ability to schedule full system backups? |
| 3 | Does your solution provide incremental backups multiple times daily? If so, how many times daily? |
| 4 | Does your solution allow functions be available during backups including but not limited to inquiries and updates? |
| 5 | Does your solution allow for full remote backups including immutability? |
| Disaster Recovery | |
| 1 | Does your solution include warm failover environment in the event that the primary system becomes unavailable? |
| 2 | Does your solution replicate the production data to failover system in near real time? |
| 3 | Does your solution automatically replicate or only in a failure scenario? |
| 4 | Does your solution automatically fail over to the backup environment in the event of a failure in the production environment? |
| 5 | Does your solution fails over without any manual intervention on the Servers? |
| 6 | Does your solution allow end-users to easily connect to failover environment in the event the production server is unavailable? |
| 7 | Does your solution resync production data when production environment is available, in the event that failover environment was used? |
| Upgrades and Patches | |
| 1 | Does your solution software include upgrades with an active maintenance contract? |
| 2 | Does your solution include all updates, enhancements, new versions, and upgrades of the server operating system software and database software as part of its standard software maintenance agreement? |
| 3 | Does your solution have the ability to install all software updates on the testing/training server(s) before installing them on the production servers? |
| 4 | Does your solution install all system software updates to the server which then automatically updates each client machine at next startup without any intervention from the vendor or IT? |
| 5 | Does your solution provide the ability for the client to refresh training and test environments as desired without charge? |
| 6 | How often does maintenance occur? |
| 7 | Can we expect any downtime or decreased performance during maintenance? |
| 8 | What is the average time of maintenance windows? |
| User Interface | |
| 1 | Does your solution have consistent user interface design throughout all modules? |
| 2 | Does your solution perform data validation/error checking for fields in the system? |
| 3 | Does your solution allow specific fields to be designated as required data entry? |
| 4 | Does your solution provide auto-completion for frequently entered data? |
| 5 | Does your solution provide the agency and user, customizable dashboard(s) to display summary information from modules to which the user has permissions? |
| 6 | Does your solution's user dashboard display overdue tasks and reminders? |
| 7 | Does your solution's user dashboard allow customization including adding external website links? |
| 8 | Does your solution allow the customization of field locations on all forms not just custom forms? For example moving Last name field ahead of first name field on the main Incident Initiate form. |
&A
Global Admin
| Item Number | Requirement/Request | Response | Comments |
| General | |||
| 1 | Ability to warn users of unfinished tasks when they attempt to log out. | ||
| Audit Trails | |||
| 1 | Ability to date and time stamp all system and user transactions. | ||
| 2 | Ability to differentiate between a system transaction and a user transaction. | ||
| 3 | Ability for the system administrator to configure the items that are included/excluded from the audit trail. | ||
| 4 | Ability to provide an audit trail for customer- and agency-created forms. | ||
| 5 | Ability to provide an audit trail for customer- and agency-created fields. | ||
| 6 | Ability to provide an audit trail for printed reports. | ||
| 7 | Ability to prevent the modification or deletion of audit trail records. | ||
| 8 | Ability to create a security group defining who has audit trail access permissions. | ||
| 9 | Ability to prevent the override of time stamps and record the attempt in the audit trail. | ||
| Ability to maintain an audit trail at the following levels: | |||
| 10 | User | ||
| 11 | Field | ||
| 12 | Record | ||
| 13 | Module | ||
| 14 | Application | ||
| 15 | Ability to log all actions. | ||
| 16 | Ability to create an audit record each time an attached audio or video is imported or exported from the system. | ||
| 17 | Ability to store audit trail data. | ||
| 18 | Ability to log all system actions. | ||
| 19 | Ability to review all system activity performed by a specified user during a period of time. | ||
| 20 | Ability to log all vendor access to system (e.g., record a description of all vendor activity). | ||
| 21 | Ability to maintain historical audit trail data based on an agency-defined length of time. | ||
| 22 | Ability to maintain file history so that field value changes can be viewed both before and after change occurred. | ||
| 23 | Ability to extract reports from the audit log. | ||
| 24 | Ability to set notifications on specific activity to designated email address. | ||
| 25 | Ability to comply with National Crime Information Center (NCIC) Interstate Identification Index (III) logging requirements. | ||
| 26 | Ability to print the audit log for a given time period. | ||
| 27 | Ability to provide an audit trail to all provisioning changes including who made the change and date and time. | ||
| Code Tables | |||
| 1 | Ability for Agency to maintain code tables (add/change/delete) without vendor intervention. | ||
| 2 | Ability to modify code tables without modification to software (e.g., modifying code tables does not require a custom system). | ||
| 3 | Ability to update code tables without taking the system offline. | ||
| 4 | Ability for customer to define codes for drop down menus (e.g., BN for brown, BL for blue) without vendor intervention. | ||
| 5 | Ability to delete a code table value. | ||
| 6 | Ability to create a new code and merge/link historical records to a new code. | ||
| 7 | Ability to retire a code table value. | ||
| 8 | Ability to maintain code table history when a code table is modified so that the Agency may run historical queries/searches. | ||
| 9 | Ability to re-use expired/deleted codes. | ||
| 10 | Ability to prevent display of obsolete code table values on drop down lists. | ||
| Code Table Transfer | |||
| 1 | Ability to import tables created in other applications (e.g., Excel). | ||
| 2 | Ability to export and import code tables into other applications (e.g., Excel) for the purpose of updating and editing the tables. | ||
| 3 | Ability to mass modify codes throughout the system (e.g., converting codes). | ||
| 4 | Ability for code table updates to propagate throughout the system (e.g., an update in a code table for one application component updates the same code table in other application components) where applicable. | ||
| 5 | Ability to designate code table values as obsolete and unavailable for current use, preventing further entry of that value, yet retain the value in the table to maintain data integrity for previous records. | ||
| 6 | Ability to display codes only for a given agency. | ||
| 7 | Ability to copy code tables across member agencies (e.g., eliminate need to re-enter identical data for separate agencies). | ||
| Statutes | |||
| 1 | Include federal, state and local statutes / ordinances. | ||
| 2 | Allow authorized users to create and update local statutes/ordinances. | ||
| 3 | Describe the initial import and setup of Colorado Revised Statutes and municipal statutes. | ||
| 4 | How are Colorado Revised Statutes updated to keep up with yearly code changes by state legislature. | ||
| 5 | How are NIBR codes attached to individual state statutes for accurate reporting? | ||
| Attachments | |||
| 1 | Allow the attachment of files (e.g., .PDF, .DOC , .XLS, .JPG, .WAV) to specified record types. Attached files should be able to be opened or viewed on any workstation by authorized users who have the necessary third- party applications (such as MS Word or MS Excel). | ||
| 2 | Support scanning and attaching documents directly to records in the system without the need to first save them elsewhere. | ||
| 3 | Store attached files on the vendor’s server or in the cloud within the vendor’s software (not on an open network folder) for security and ease of access. | ||
| Integration | |||
| 1 | Ensure that all modules integrate with each other (CAD, RMS, JMS, etc.), and are provided by the same vendor and are not third-party applications. | ||
| 2 | Allow all modules (CAD, RMS, JMS, etc.) to be accessible to authorized users from the same application window. | ||
| 3 | Allow for automatic transfer of critical information (e.g., CFS from CAD to RMS, Arrest and Warrant from RMS to JMS). | ||
| 4 | Integrate alerts between all modules so that they are accessible by all using any module in the system (e.g., outstanding warrants). | ||
| 5 | Ensure that all modules share the same master records for names, addresses, property and vehicles and these master records are located within a single database. | ||
| Custom Forms | |||
| 1 | Allow authorized users to create custom data collection forms to support agency specified functionality, without any intervention from the vendor. | ||
| 2 | Support printing the data from custom forms via an agency defined output template and process. | ||
| 3 | Allow authorized users to include as many fields for data collection as are necessary within custom forms, including new fields. | ||
| 4 | Support agency-defined fields for custom forms. | ||
| 5 | Allow authorized users to specify the label for each field on a custom form. | ||
| 6 | Allow authorized users to specify if each field on a custom form is required or not required. | ||
| 7 | Allow the authorized users to arrange the data items and fields in any order on the form. | ||
| Queries | |||
| Ability to conduct searches based on: | |||
| 1 | Soundex | ||
| 2 | Wild cards (includes either end of the value being queried (e.g.: $abc or abc$) | ||
| 3 | Exact match | ||
| 4 | Partial information | ||
| 5 | Boolean operators ("and," "if," "or") | ||
| 6 | Ranges (date, location, time) | ||
| 7 | Ability for searches to be non-case sensitive. | ||
| 8 | Ability to search on multiple operational data fields. | ||
| Ability for federated searches to include, at a minimum: | |||
| 9 | RMS | ||
| 10 | JMS | ||
| 11 | CAD | ||
| 12 | Law Enforcement Message Switch | ||
| 13 | Ability to provide users an option with which to select which databases to search. | ||
| 14 | Ability for search returns to indicate the information source. | ||
| 15 | Ability to select any result from a query and drill down for detailed information (e.g., hyperlink). | ||
| 16 | Ability to perform global search functions for names, addresses, phone numbers and vehicles. | ||
| 17 | Ability to search narrative fields. | ||
| 18 | Ability to search custom fields. | ||
| 19 | Ability to restrict searches that result in large volumes of data by providing a warning of the size of records found with option to continue or cancel. | ||
| 20 | Ability to clearly indicate when additional information (e.g., more search results) is available. | ||
| 21 | Ability to name and save a query. | ||
| 22 | Ability to print/export query results from within the application. | ||
| Security | |||
| 1 | Ability to meet all current CJIS Security Policy requirements (v6.0 or newer). | ||
| 2 | Ability to maintain compliance with CJIS requirements. | ||
| 3 | FIPS-140 compliance for all network communication, including wired and wireless communication. | ||
| 4 | Allow multiple agencies to share host server with the ability to limit access to sensitive information. | ||
| User Accounts/Passwords | |||
| 1 | Ability to provide Active Directory integration with support of multiple domains throughout the system. (Multiple agencies utilizing software on separate networks.) | ||
| 2 | Ability to support multi-factor authentication throughout the system. | ||
| 3 | Ability to support alternate authentication technologies (e.g., ID card, security token, biometrics, etc.). | ||
| 4 | Ability to enforce passwords per CJIS requirements throughout the system. | ||
| 5 | Centralized user management across all applications. | ||
| 6 | Ability to mask passwords when typed. | ||
| 7 | Ability to encrypt passwords when stored. | ||
| 8 | Ability to maintain a history of de-activated user IDs. | ||
| Ability to do the following if not associated with AD: | |||
| 9 | Allow authorized users to create and maintain user accounts | ||
| 10 | Allow users to change their own passwords | ||
| 11 | Ability for agency configurable password parameters. | ||
| 12 | Ability for system administrator to disable an account both temporarily or permanantly. | ||
| 13 | Ability to set a threshold for unsuccessful log-on attempts that will lock-out a user account. | ||
| Ability to capture the following information associated with each unique Login ID: | |||
| 14 | Name | ||
| 15 | Title | ||
| 16 | Badge number (not unique; can change) | ||
| 17 | Agency | ||
| 18 | Email address | ||
| 19 | Security permissions/Roles | ||
| 20 | Customer-defined criteria | ||
| 21 | Ability to change badge number associated with user as needed. | ||
| User Access | |||
| 1 | Ability to automatically logoff a user after an agency- defined predetermined period of inactivity, based on user type and location. | ||
| 2 | Ability to be logged onto multiple workstations at the same time (e.g., logged onto a mobile computer in a vehicle and a station computer simultaneously). | ||
| 3 | Ability to track user logon/logoff times and locations for time reporting purposes. | ||
| 4 | Ability to disable automatic logoff for secured workstations. | ||
| 5 | Ability to remotely log out a workstation (mobile or desktop). | ||
| 6 | Ability to provide system generated message to system administrator when an agency-defined number of unsuccessful sign-on attempts have occurred. | ||
| 7 | Ability to “lock out” a user after agency-defined number of attempted logons without regard to user ID. | ||
| 8 | Ability to automatically reset a "locked-out" user after a customer-specified period of time. | ||
| 9 | Ability to include a comment/reason when making changes to a user account. | ||
| 10 | Ability to encrypt data transmissions. | ||
| 11 | Ability to display an agency defined message at successful sign-on (e.g., CJIS security admonishment) | ||
| 12 | Ability to designate authorized users to reset passwords and/or unlock user accounts. | ||
| Ability to log the following related to user logons: | |||
| 13 | Logon attempts | ||
| 14 | Attempts to modify password | ||
| 15 | Logon date/times | ||
| 16 | Logoff date/times | ||
| 17 | Ability to grant outside users restricted access to inquiry with login (e.g., DA). | ||
| Permissions | |||
| 1 | Ability to provide clear definitions and explaniations of what permissions entail. | ||
| 2 | Ability to support group/role-based security permissions. | ||
| 3 | Ability to allow authorized users to create and maintain user groups/roles. | ||
| 4 | Ability to allow authorized users to assign users to groups/roles. | ||
| 5 | Ability to assign permissions to individual user or roles. | ||
| 6 | Ability to assign users to multiple groups/roles. | ||
| 7 | Ability to provide access levels, including view, add, edit, delete and admin for each component of the system for users and user groups. | ||
| 8 | Ability to define permissions for each group/role. | ||
| Ability to view, add, modify and make inactive user profiles based on: | |||
| 9 | User ID | ||
| 10 | User name | ||
| 11 | Any combination of the above | ||
| 12 | Ability to allow authorized user to designate user/users as a System Administrator. | ||
| Ability to provide security at the following levels: | |||
| 13 | Application | ||
| 14 | Database | ||
| 15 | Screen | ||
| 16 | Transaction | ||
| 17 | Ability to restrict logon by workstation or MDT ID. | ||
| GIS/Geo File Information | |||
| 1 | What platform/software/version does CAD mapping use? | ||
| 2 | What platform/software/version does Mobile mapping use? | ||
| 3 | How does address validation work within your solution? | ||
| 4 | How are Geo-file changes maintained? | ||
| 6 | How does your solution map wireless calls? | ||
| 5 | Ability to support shape files. | ||
| 7 | Ability to create and maintain a GIS-based geofile that meets i3 standards and functions to comply with NG911 requirements. | ||
| 8 | Ability for the system to support geospatial data, including point addresses, lines, and polygons. | ||
| 9 | Ability to create geographic boundary information in the geofile. | ||
| 10 | Ability to import geographic boundary information from another source file. | ||
| Ability to support the following location fields and map layers: | |||
| 11 | Apartment building name | ||
| 12 | Apartment number (e.g., ½, #5, 2D, D2) | ||
| 13 | Business name | ||
| 14 | City/Town | ||
| 15 | Civic associations (e.g., areas, neighborhoods, community names) | ||
| 16 | Common place name(e.g., University building number) | ||
| 17 | County | ||
| 18 | District | ||
| 19 | Address | ||
| 20 | Intersections | ||
| 21 | Public safety geographical boundaries (e.g., sectors, districts, battalions) | ||
| 22 | Mile markers | ||
| 23 | On ramps, off ramps, exit numbers (including direction) | ||
| 24 | Prefix | ||
| 25 | Reporting area | ||
| 26 | Street abbreviation | ||
| 27 | Street alias | ||
| 28 | Street name | ||
| 29 | Street type | ||
| 30 | Suffix | ||
| 31 | X/Y coordinates | ||
| Ability to associate geofile data with the following: | |||
| 32 | Address | ||
| 33 | Public safety geographical boundaries (e.g., sectors, districts, battalions) | ||
| 34 | Cross street | ||
| 35 | Entire common place or business name and aliases | ||
| 36 | Jurisdiction | ||
| 37 | Neighborhood | ||
| 38 | Reporting district | ||
| 39 | Response area | ||
| 40 | X/Y coordinates | ||
| 41 | Agency-defined polygon | ||
| 42 | Floor | ||
| 43 | Z coordinates in addition to x and y | ||
| 44 | Ability for updates to the GIS source data to update the geofile manually and automatically. | ||
| Ability to maintain the geofile by: | |||
| 43 | Uploading and/or converting a GIS-maintained set of geospatial datasets into the system’s internal geofile | ||
| 44 | Uploading and/or converting an i3-compatible geospatial dataset from the appropriate Spatial Information Function (SIF) | ||
| 45 | Ability to update the geofile while the system is live and operational. | ||
| 46 | Ability to add in a common place or address point location while system is live and without switching to a different map set. | ||
| 47 | Ability to provide interactive tools for validating the accuracy and completeness of the geofile, as well as tools to allow updates to the geofile to reflect changing conditions in the field. | ||
| GIS/Mapping Requirements | |||
| 1 | Ability to use agency maintained Esri-based GIS layers to populate and maintain the geofile. | ||
| 2 | Ability to test the GIS data to ensure proper functionality. | ||
| 3 | Ability to maintain geofile layers in a current release of Esri’s products (10.5 and above). | ||
| 4 | Ability to import geofile updates into CAD/RMS using standard Esri tools or vendor supplied models or scripts. | ||
| 5 | Ability to publish geofile layers to ArcGIS Server map services that can be used by Mobile clients. | ||
| GPS Requirements | |||
| 1 | Ability to configure GPS through ethernet or comm port. | ||
| 2 | Ability for GPS to display real time unit location of mobile client on CAD and Mobile map display. | ||
| 3 | Ability for a multi-unit display of GPS location on CAD and Mobile map display. | ||
| 4 | Ability for AVL to use real time GPS location. | ||
| 5 | Ability to use multiple GPS sources; ie Cradlepoint, MDC on board GPS, etc. | ||
| 6 | Ability to see when a unit does not have current gps location data. (an icon or similar to show that the unit has stale gps data) | ||
| 7 | Ability to use last known gps location | ||
| 8 | Ability for dispatcher to set the location for a unit manually with a geo verified location | ||
| 9 | Ability to use the unit’s home station as the default location if gps location is not known |
&A
CAD
| Item Number | Requirement/Request | Response | Comments |
| General CAD Requirements | |||
| 1 | Ability to accommodate multi-disciplinary call taking and dispatching for Law Enforcement, Fire, EMS. | ||
| 2 | Ability to support multi-jurisdictional call taking and dispatching. | ||
| 3 | Ability to comply and maintain compliance with published NENA NG911 standards. | ||
| 4 | Ability for the system to automatically generate a call for service number in any alphanumeric format and assign in sequence defined by the agency. | ||
| 5 | Ability for each member agency to have a unique identifier regarding call for service numbers. | ||
| 6 | Ability to designate roles and limit modification/data entry features (e.g., a member agency supervisor may view incidents only but not modify incidents). | ||
| 7 | Ability to start incident numbers at a custom number at go-live to maintain the sequence of current incident numbers. | ||
| Ability to perform the following via remote access: | |||
| 8 | Monitor and create calls | ||
| 9 | Run queries, monitor AVL units, Dispatch calls | ||
| 10 | Message units or personnel | ||
| 11 | Provisioning duties such as changing passwords or adding capabilities | ||
| 12 | Ability and compliance with NERIS fire reporting data framework standards. | ||
| CAD System Administration | |||
| Ability to include, at a minimum, the following data tables: | |||
| 1 | Call types | ||
| 2 | Incident Types with Modifying Circumstances | ||
| 3 | Call priorities | ||
| 4 | Commands | ||
| 5 | Dispositions | ||
| 6 | Event error logs | ||
| 7 | Patrol and command area definitions | ||
| 8 | Personnel, including emergency contact information and current assignment | ||
| 9 | Timers | ||
| 10 | Unit status types | ||
| 11 | Units | ||
| Describe how the product handles the following: | |||
| 12 | Command customization – Ability to modify common dispatch commands to fit dispatch preferences (command identifier modification and order of identifiers) | ||
| 13 | Response messages and notifications using triggers based on location and incident | ||
| 14 | Incident response configuration based on run card orders or closest unit | ||
| 15 | Custom Status monitors including colors sounds and icons | ||
| 16 | Contractor Rotations | ||
| 17 | Incident Response classes for agency, area, beat, or location | ||
| 18 | Premise Hazards | ||
| 19 | Lists and Statute Management | ||
| 20 | User Roles | ||
| 21 | Run Cards | ||
| 22 | Devices and Device Types | ||
| 23 | Address Books | ||
| 24 | Alarm Records | ||
| 25 | Authentication protocol customization | ||
| Application User Interface | |||
| Ability to support multiple form factors, including: | |||
| 1 | Tablets of all sizes | ||
| 2 | Mobile and laptop computers | ||
| 3 | Single and multi-monitor desktop computers | ||
| Ability to customize the following: (Note: if certain features are customizable at only the user or agency level, indicate as such in the "Comments" field): | |||
| 4 | Font type, size, and colors | ||
| 5 | Window background color, sizes, and locations | ||
| 6 | Day/Night mode | ||
| 7 | Required, optional, or not required fields | ||
| 8 | Field label | ||
| 9 | Ability to reset configuration to agency defined default settings. | ||
| 10 | Ability to maintain configuration settings during upgrades. | ||
| 11 | Ability to display system messages without affecting work in progress. | ||
| 12 | Ability to display one or more status windows at the same time. | ||
| 13 | Ability for user preferences to follow users to new devices. | ||
| General Data Entry | |||
| Ability to support data entry via: | |||
| 1 | Mouse (point and click) | ||
| 2 | Command line entry | ||
| 3 | Drag-and-drop | ||
| 4 | Function keys | ||
| 5 | Touch screen | ||
| 6 | Preformatted data entry screens (e.g., designated data fields) | ||
| 7 | Ability to provide type ahead capability such that the user can continue entering data while the system is processing a previous transaction. | ||
| 8 | Ability to support drop-down menus, auto completion, and select by mouse. | ||
| 9 | Ability for an administrator to customize field locations | ||
| Timers and Time Stamps | |||
| 1 | Ability to automatically time stamp all activities including the user name/workstation ID/date and time. | ||
| 2 | Ability to provide predefined timers to alert dispatchers to situations requiring their attention. | ||
| 3 | Ability to configure incident timers and alerts based upon member agency-defined parameters. | ||
| Ability to associate timers with: | |||
| 4 | Unit status updates | ||
| 5 | Incident type | ||
| 6 | Response time | ||
| 7 | Incident status | ||
| 8 | Ability to snooze, clear, or reset timers on user defined time. | ||
| 9 | Ability to alert user to the expiration of a timer via visual alert. | ||
| 10 | Ability to reset the default value when a status timer expires. | ||
| 11 | Ability to trigger timers for check-ins based on call types per agency. | ||
| 12 | Ability for customer to determine the length of timers based on incident type. | ||
| 13 | Ability to provide timers to support checks during fire operations (e.g., personnel accountability report checks, time in environment checks and patient contact time). | ||
| 14 | Ability, when querying a name, for user to be notified of an associated alert (e.g., if a person was flagged in the RMS, if a person is wanted via NCIC). | ||
| 15 | Ability to provide call history of address when creating a new call. | ||
| 16 | Ability to provide call history of calling party's phone number when creating a new call. | ||
| 17 | Ability to add a temporary flag, comment or note to a location. | ||
| 18 | Ability to include flagged information with dispatches sent to responding units. | ||
| Call Taking | |||
| 1 | Ability for call takers to create a new event and populate fields with any location, name and phone information from external functional elements. | ||
| 2 | Ability to display multiple event creation screens (to allow call takers to work multiple calls at the same time). | ||
| Ability to receive call data from (and include information on the source as part of the CAD call number): | |||
| 3 | E9-1-1 phone system | ||
| 4 | ESInet | ||
| 5 | Text-to-911 | ||
| 6 | CAD to CAD | ||
| 7 | Ability to accept and process IP-based incident data. | ||
| 8 | Ability to view location of incoming calls on CAD map. | ||
| Ability to filter CAD map to view: | |||
| 9 | Ability for a new event entry screen to open when the call taker answers the phone. | ||
| 10 | Ability for call taker to choose whether or not to accept pre-populated ANI/ALI information when creating a new event. | ||
| 11 | Ability to provide fields to capture call answer time and event creation time. | ||
| 12 | Ability to enter incident information using command lines. | ||
| 13 | Ability to enter multiple commands on one line. | ||
| 14 | Ability to open multiple command lines simultaneously. | ||
| 15 | Ability for the agency to edit, modify, and delete its own commands. | ||
| 16 | Ability to automatically populate CAD screen with information from E9-1-1 application (no manual intervention required). | ||
| 17 | Ability to populate CAD screen with information from E9-1-1 application via manual intervention (e.g., function key, mouse click). | ||
| 18 | Ability to visually identify mandatory fields on the call entry screen. | ||
| 19 | Ability to accept ANI/ALI phase 2 data and automatically or manually update the ANI/ALI data on the Incident Initiate screen | ||
| Ability for narrative fields to have the following attributes: | |||
| 20 | Unlimited number of characters | ||
| 21 | Word wrap | ||
| 22 | Full comment field display | ||
| 23 | Ability to enter standard information in defined fields for persons, vehicles, and locations. | ||
| Ability to receive and process standards-based information to include: | |||
| 24 | CCTV | ||
| 25 | Street-level cameras | ||
| 26 | IoT sensor data (e.g., seismic, weather, traffic) | ||
| 27 | Ability for dispatchers to print an event from an active call screen (without having system administration privileges). | ||
| 28 | Ability to audibly and visually alert dispatcher that the call taker has added information. | ||
| 29 | Ability for an agency-defined field to automatically query the state system and attach responses to call record. Received information must be highlighted or easily identifiable. | ||
| 30 | Ability for call taker and dispatcher to work on the same call for service simultaneously. | ||
| 31 | Ability for call taker to add comments to a call after it has been dispatched and automatically update the dispatchers screen. | ||
| 32 | Ability to relate X/Y coordinates to the closest actual address. | ||
| 33 | Ability to transform X/Y coordinates to a map for display. | ||
| 34 | Ability to capture incident location separately from caller location. | ||
| 35 | Ability for a dispatcher or mobile user to make a “priority comment” and customize the “priority comment” notification behavior for cad and mobile | ||
| Ability to parse address data into the following elements: | |||
| 36 | Street number | ||
| 37 | Apartment, lot, or suite information | ||
| 38 | Street name | ||
| 39 | Street prefix | ||
| 40 | Street suffix | ||
| 41 | Street type (Ave., Ln.) | ||
| 42 | Unit type | ||
| 43 | Unit number | ||
| 44 | City/Town | ||
| Ability to capture the following information upon receipt of a wireless Phase II 9-1-1 call: | |||
| 45 | X/Y/Z coordinates | ||
| 46 | Nearest cross street | ||
| 47 | Closest street address | ||
| 48 | Ability to geoverify the location of all entered addresses. | ||
| 49 | Ability to override the geoverified location. | ||
| Ability to validate an entry upon: | |||
| 50 | Operator request (e.g., press a button) | ||
| 51 | Entry into a location field | ||
| 52 | Ability upon address verification for system to auto-populate associated fields (e.g., zip code, town, etc.). | ||
| 53 | Ability for addresses entered by field units (e.g., on a self-dispatch) to correctly populate all address fields in the CAD record. | ||
| 54 | Ability to support Phase I wireless location validation from cellular callers. | ||
| 55 | Ability to support Phase II wireless location validation from cellular callers. | ||
| CAD Event Creation | |||
| Ability to log and time stamp transactions associated with events: | |||
| 1 | E911 Presentation | ||
| 2 | E911 answer time | ||
| 3 | Event start | ||
| 4 | Event creation | ||
| 5 | Event updates | ||
| 6 | Unit dispatches | ||
| 7 | Unit status changes | ||
| 8 | Unit comments | ||
| 9 | Event clearances | ||
| 10 | Event comments and notes | ||
| 11 | Unit or incident timeouts log and time stamp | ||
| 12 | Scheduled Incident creation | ||
| 13 | Ability for users to generate events at any time after the minimum mandatory amount of information required to create an event is entered. | ||
| Ability for system to automatically assign an event to a dispatch group based on: | |||
| 14 | Incident type code | ||
| 15 | Location | ||
| 16 | Agency | ||
| 17 | Ability to override default dispatch group. | ||
| 18 | Ability for events to appear in the queue for the appropriate dispatch area. | ||
| 19 | Ability for call takers to continue updating the event after creating the event. | ||
| 20 | Ability for call takers to create events that do not require dispatch. | ||
| Location Verification | |||
| 1 | Ability to verify locations for any address entered into the system (e.g., CAD incident address, field-entered, manual entry to research a location). | ||
| 2 | Ability to support call class of service location validation from cellular callers. | ||
| 3 | Ability to use the ALI reported location address for address verification. | ||
| 4 | Ability to use x,y coordinates or Lat/Long for address verification | ||
| 5 | Ability to click on map for address verification | ||
| Ability to display closest address matches based on: | |||
| 6 | Business name | ||
| 7 | Common place names | ||
| 8 | Landmarks | ||
| 9 | Intersections | ||
| 10 | Phonetic spelling | ||
| 11 | Street name | ||
| Ability to enter a street name and be presented with: | |||
| 12 | Aliases | ||
| 13 | Associated address ranges | ||
| 14 | List of cross streets | ||
| 15 | Ability to translate common place names into valid addresses. | ||
| 16 | Ability to translate call location to appropriate public safety geographical boundary (e.g., district, beat, sector) upon address validation. | ||
| 17 | Ability to translate alias names to actual street names or addresses. | ||
| 18 | Ability to enter a commonplace name and be presented with a list of addresses with that commonplace name (e.g., McDonald's search). | ||
| 19 | Ability to notify user through a visual and/or audible flag if multiple street addresses/street names/intersections are found in geofile. | ||
| 20 | Ability to select from lists using the keyboard and/or mouse click. | ||
| 21 | Ability to offer a list of address options if multiple similar addresses/intersections/street names are found in geofile. | ||
| 22 | Ability to manually verify an address without creating an event | ||
| Ability for CAD map to use icons, colors or shapes to distinguish between: | |||
| 23 | Available unit | ||
| 24 | Active enroute unit | ||
| 25 | Active arrived unit | ||
| 26 | Pending incident | ||
| 27 | Assigned incident | ||
| 28 | Ability to manually override an address if it cannot be verified. | ||
| 29 | Ability to accept a description of a location (e.g., "Lake Dillon Overlook"). | ||
| 30 | Ability to manually verify an address without creating an event. | ||
| 31 | Ability to search the location where a new CAD event is entered, along with neighboring locations in an agency-defined radius, to determine if previous events occurred there and whether any hazard or tactical information is available in CAD about the new event’s location. | ||
| Call Classification and Prioritization | |||
| 1 | Ability for customer to define incident type codes. | ||
| Ability to define priority and response criteria by agency, based upon: | |||
| 2 | Agency | ||
| 3 | Geographical response area | ||
| 4 | Response plans | ||
| 5 | Response classes (identify a beat needing special equipment or a special response) | ||
| Ability to enter a type code by: | |||
| 6 | Selecting from a drop down list within the incident type field | ||
| 7 | Typing the code in the appropriate field | ||
| 8 | Entering a command in the command line | ||
| 9 | Ability to retrieve a job aid (e.g., SOP) attached to an incident type code. | ||
| 10 | Ability to auto populate the incident priority field based on the incident type. | ||
| 11 | Ability for user to override associated priority. | ||
| 12 | Ability to upgrade or downgrade the incident classification during the course of managing the event. | ||
| 13 | Ability to change call type without impacting active call data. | ||
| 14 | Ability to capture original and new incident classifications and priorities and analysis and reporting. | ||
| 15 | Ability to capture multiple incident types and priorities for multidiscipline incidents. | ||
| 16 | Ability to determine the responding agency and service area from the incident type code and incident location. | ||
| 17 | Ability to zoom to location on map upon creation of a new event. | ||
| 18 | Ability to specify an incident type to see what units would be recommended at this location | ||
| 19 | Ability to specify search distance from a location and to modify what incident types show in the history of a location | ||
| 20 | Ability to zoom to location on map upon creation of a new event (and ability to modify the zoom level settings) | ||
| Incident Initiation | |||
| 1 | Ability to initiate an incident from the input of location and type code. | ||
| 2 | Ability to input all call and narrative information on one screen. | ||
| 3 | Ability to display a blank form for entering new incidents with a single keystroke, mouse click or function key upon initiation of a CAD incident. | ||
| Ability to enter incidents using: | |||
| 4 | Standard call entry form | ||
| 5 | CAD command on a command line | ||
| 6 | Ability to support multiple partially complete incidents. | ||
| 7 | Ability to initiate an incident by clicking on the map | ||
| 8 | Ability to initiate a scheduled incident | ||
| 9 | Ability to Field Initiate an incident from mobile | ||
| Duplicate Call Management | |||
| 1 | Ability to quickly view, identify, and flag potential duplicate calls based on geographic and temporal parameters. | ||
| 2 | Ability for Agency to define parameters of duplicate call identification (e.g., included call types, excluded call types, defined proximity, definition of "recently closed", etc.). | ||
| 3 | Ability to provide the user with incident details about possible duplicate incidents. | ||
| 4 | Ability to display the incident location in relation to other active incidents on the map during the incident entry process. | ||
| 5 | Ability to include pending calls in the potential duplicate call identification process. | ||
| 6 | Ability to include recently closed calls in the potential duplicate call identification process. | ||
| 7 | Ability to include field-initiated calls in the potential duplicate call identification process. | ||
| Ability for the user to do any of the following if a CAD incident is determined to be a duplicate call: | |||
| 8 | Add additional reporting parties to the original incident record with complete complainant information and additional incident comments | ||
| 9 | Close a duplicate incident and cross-reference/link it to the original CAD incident | ||
| 10 | Override and create an entirely new incident using existing address data | ||
| 11 | Ability to transfer any information entered into the new event into the original event upon cross-referencing the events. | ||
| 12 | Ability to unlink mistakenly linked calls. | ||
| 13 | Ability to relink calls to the correct original call. | ||
| 14 | Ability for call takers to add new information to a closed event record if the original event record associated with a duplicate CAD event is closed. | ||
| 15 | Ability for users to re-open a closed event, add the new information, and route the event back through the dispatch process if the new information requires a dispatch of public safety resources. | ||
| Premise Information Retrieval | |||
| 1 | Ability to alert user of the presence of hazards upon entering an address. | ||
| 2 | Ability for alerts to include audible alerts and visual flags. | ||
| 3 | Ability to indicate the number of past incidents at a location. | ||
| Multidiscipline Events | |||
| 1 | Ability to enter one type code to generate a multidiscipline event. | ||
| 2 | Ability to assign different incident types and priorities to each discipline based on entry of a single type code. | ||
| 3 | Ability to assign different priorities for the event for each discipline. | ||
| 4 | Ability to assign a different incident type when a fire unit is dispatched to an in-progress law enforcement call. |
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 .