Attachment_A_-_Solution_Proposed.docx

ATTACHMENT A – SOLUTION PROPOSED

Software and Interfaces Software Description and Overview of Capabilities This Attachment is presented to Vendors to solicit a detailed response that addresses the areas covered within and requires a corresponding section within Vendor’s proposal indicating it is the response to this Attachment.

CAD and Mobile Data As previously noted, the County receives approximately 500,000 emergency and non-emergency calls for service per year at the Clay County Sheriff’s Office Communications Center (CCSO). This requires a CAD and MDS system that can process incident data at very high transaction volumes, exceeding 1,350 average daily incidents and 150% higher at peak levels. Apart from the transaction volume received at CCSO, another significant element impacting system performance are the number of concurrent users accessing the server, inputting data into the database, querying the system for data and other daily activities.

The County and its partner agencies currently have CAD client licenses deployed as indicated in the below table.

The above CAD license deployment requires a very robust CAD platform that can meet performance demands twenty-four hours a day, seven days a week, three hundred sixty-five days a year (24/7/365), while providing mission critical system uptime of ninety-nine point nine hundred ninety-nine percent (99.999%) with optimum system dependability.

Vendors will provide a detailed description of their solution, beginning with the CAD system and how it meets the stringent requirements of one of the nation's largest metropolitan areas. Screenshots of CAD call-taking, dispatching, mapping, and mobile data screens should be provided to offer a descriptive overview of the solution proposed. The CAD description should include, but not be limited to, the following areas:

· The ability of the system to seamlessly ingest 911 call handling information and locate callers rapidly to initiate event creation.

· The importance of command line capabilities should not be underemphasized as seasoned call takers can rapidly input critical data quickly and efficiently via the command line.

· The ability to duplicate calls from multiple disciplines is of paramount importance in providing emergency services to the citizens of Clay County.

· Robust mapping capabilities to locate callers and emergency services personnel are of vital importance in the dispatch operation.

· The system should be capable of embedding fire resource recommendations within CAD without the need of automatic vehicle location (AVL).

· The mobile data system must be tightly integrated with CAD allowing dispatchers to share critical information to the field as it is captured.

· Pre-configured and ad-hoc event timers that notify dispatch personnel when to perform status checks on field personnel.

· Capability to easily interface with other systems and share data, such as NG911 data from 911 call handling equipment (e.g., text-to-911, images, etc.) as detailed in the interface tables.

Following the CAD system overview, the Vendor should provide a detailed synopsis of the Mobile Data System (MDS) capabilities and how the integration of both systems provides a comprehensive solution for emergency call processing and response. The MDS description should include, but not be limited to, the following areas:

· The MDS should consume real time CAD event data with access to premise alerts, hazards, and prior location history readily accessible to emergency responders in the field, with visual alerts to notify field users.

· Integrated access to FCIC/NCIC where returns are easily discernible, and officers know immediately if an NCIC hit has been received.

· Robust mapping with the same look and feel offered at dispatch consoles.

· AVL capabilities that track emergency resources of each discipline and display real-time location data.

· Car-to-car, car-to-dispatch, and dispatch-to-car messaging capabilities.

· Field access to pre-plans and/or building schematics to enhance tactical response.

· Self-initiated dispatch that captures location and time stamps unit status once activated.

CAD and Mobile Data Interfaces The below table lists the required interfaces desired in the new CAD/Mobile Data system. These interfaces are also included in the Pricing Forms that must be completed by the vendor.

CAD Required Interfaces Table

Rip and Run printers

First Watch

RMS Software As previously noted, four law enforcement agencies depend on the law enforcement RMS to collect incident data, manage cases, initiate prosecution and generate statistical data for consumption by the agencies as well as transmission to the state NIBRS system. Vendors should describe the capabilities of their RMS system, providing an overview of the modules available, it’s ability to consume information from CAD in real-time to allow officers to initiate the incident report in the field, and, primarily, how their system can serve as a multi-agency RMS for two municipal police departments and the County Sheriff.

RMS Interfaces The below table lists the required interfaces desired in the new RMS system. These interfaces are also included in the Pricing Forms that must be completed by the vendor.

Finder

JMS Software The Clay County Detention Center handles nearly 500 inmates and requires a robust solution to manage the population that offers ‘keep separate” functionality, inmate property feature, signature capture, import of documents to an inmate folder, integration with GuardOne facility checkpoint system, among other critical functionality necessary to the operations of the Detention Center. Vendors should describe the capabilities of their RMS system, providing an overview of the modules available as well as its ability to integrate with other systems and transmit corrections data to the state.

JMS Interfaces The below table lists the required interfaces desired in the new JMS system. These interfaces are also included in the Pricing Forms that must be completed by the vendor.

Software Licenses The Vendor’s submission should describe what licensing model they are offering the County to accommodate the estimated number of CAD positions and mobile data clients needed by the County (NOTE: all pricing based on the proposed model is to be reflected in the Pricing Forms as a separate submission apart from the technical proposal). The proposed Solution is not required to use a “per seat or client count” licensing model, however, the proposed Solution must accommodate, at a minimum, the number of identified CAD/MDS seats or mobile data clients referenced in the RFP and the Pricing Forms. Enterprise or site license for CAD and MDS software are permissible. The Vendor is required to provide a licensing model that is predictable, understandable, and easy to manage as user adoption may increase over time. If the Vendor would like to offer an alternative licensing model that they believe is financially beneficial to the County, they are welcome to submit that model in addition to the user licensing model requested above (a second pricing form may be submitted with an alternate or optional pricing model).

The County will not purchase separate licenses for third party applications which are embedded into the solution and are required for it to function. All licenses that may be required by the solution for third party software are to be included with the proposed solution and maintained throughout the term of the contract. Licensing must include all licenses required to operate and maintain the testing, staging, training, and production environments. All such costs are to be included within the submitted Pricing Forms.

CAD/MDS Software and Related Documentation The Vendor shall provide detailed user documentation to County staff responsible for the operation and support of the system. Final software/system documentation, in electronic form, should include, but not be limited to:

· System Software Documentation

· System Administrator Documentation

· Operations and Maintenance Manuals

· Data Maintenance and System Configuration Documentation

· System Functional Specifications (CAD, Mapping, Mobile, Reporting)

· System Interface Specifications or Interface Control Documents (ICDs)

· Test Plans and Procedures

· Training Materials (Instructor guides and participant material)

· End User Manuals (CAD, Mapping, Mobile, Reporting) and Quick Reference Guides

· Final “as-built” system documentation The Vendor’s documentation should be searchable electronic copies and provide access to updated versions of this documentation via a webpage or other cloud-based document repository. The Vendor will be expected to maintain and update electronic copies of the documentation as changes are made to training, the system configuration or updates are made to the software. The Vendor will provide, in a timely manner, system documents that describe all software in sufficient technical and functional detail to enable County personnel to maintain the system and resolve identified problems.

Solution Focused Questions Overview This exhibit is presented to Vendors to solicit a detailed response that addresses the areas covered within and requires a corresponding section within Vendor’s Proposal indicating it is the response to this exhibit. The below sections present solution focused questions of functional areas where the County seeks detailed solution write-ups from Vendors. Vendors must address each issue separately with a written explanation of how their solution functions to meet the requirement.

General Solution Focused Questions Mobile Connectivity/AVL The County intends to utilize AVL capabilities as a component of this CAD/Mobile procurement. AVL data for each unit with a mobile data client shall be available systemwide so that every unit can be viewed in both CAD and in-vehicle, as controlled by system administrators. In addition to being used with the CAD system, AVL data may be shared with other applications. Additionally, the County is interested in a solution that is capable of receiving and displaying X/Y/Z coordinate data from third party sources such as body worn cameras or portable radios. Vendors shall provide details on how AVL data is depicted in its CAD and mobile mapping solutions, how this data is utilized by the CAD system to determine nearest available units, what other capabilities exist within its solution to use AVL data (e.g., routing, geofencing), and how AVL data is archived and retrieved for playback.

Full Featured CAD/Mobile Mapping CAD Mapping is a vital component of the dispatch environment that has seen significant progress and an increase in importance as NG911 is implemented across the country. As 911 call taking systems get better location data, the importance of visualizing this location is paramount for better service to callers. Additionally, there are increased expectations on a mapping product as the user experiences with personal products continue to develop with modern handheld devices. The CAD mapping component used with the current CAD system does not meet this performance level. Implementing a new comprehensive mapping system is a high priority of the County.

The County wants a CAD and Mobile mapping solution to provide the features and functionality of a contemporary public safety CAD and Mobile map solution including but not limited to:

· Ability to easily ingest Esri file types

· Requires the use of Dynamic layers and Geodatabase (GDB) which is the common storage and management framework for ArcGIS

· Use of the same map data for CAD, Mobile and RMS

· Utilizes a cascading geo verification process that includes Common Places, Centerline, block ranges and address points.

· Routing functionality that leverages third-party sources such as Waze and Google Maps.

· Ability to add out of jurisdiction map data for mutual aid responses and routing to include addresses outside the normal jurisdiction.

· Ability to display multiple map layers, e.g., traffic camera locations

· Ability for the CAD user to select/deselect multiple map layers

· Ability to show the location of public safety units via AVL

· Color coding for events

· Color coding for event status

· Color coding for units

· Color coding for unit status

· Display a flag to indicate hydrants with the ability to put out of service on the map

· Display a flag for floor plans with the ability to hyperlink and open them from the map

· Display a flag for all traffic cameras on the map

· Ability to calculate the distance between two points

· Turn by turn directions from a unit’s location

· Allow for an agency specific map with unique layering and routing. Example: a fire specific map that allows discipline-specific changes without authorizations from other agencies. Mapping additions could be quickly made without impacting other disciplines (e.g., speed limit adjustments, school zones, bridge height, speed bumps, bicycle lanes, etc.).

Vendors shall explain if these types of CAD / Mobile mapping features are available in the offered solution, how they function, how mapping is configured, and any other potential uses for this feature within your system.

Geo-Fencing Capability Geo-fencing is a feature that the agency would like to implement within the Vendor’s integrated mapping solution for unit response, arrival, or other parameters that could be set by the CAD system administrator or other authorized individuals. This setting could be a pre-determined radius that might be used on a long-term basis or can be a temporary radius drawn on the fly by a dispatcher or incident commander for a specific event. Additionally, the geo-fencing should provide alerts when units arrive or leave a designated area.

Vendors shall explain if this type of GIS feature is available in the offered solution, how it functions and how geo-fences are configured, and any other potential uses for this feature within your system.

Operating System Updates The County, like many other agencies, is often required to update their Operating System and other applications to stay current with Windows or Federal/State required updates. These could be version or security updates that may also require some adjustment to the Vendor’s software or interfaces.

Vendors should provide information, including billing, on their preferred approach to addressing changes and updates to the County’s operating systems and other related applications which in some way integrate, interface, or have an influence on the Vendor’s proposed solution.

Priority Call Routing The County requires that any new CAD solution have a feature that allows for a call taker or dispatcher to route a call for dispatch with minimal information. As an example, a cardiac arrest needs to be dispatched as soon as possible. In order to improve event outcomes, the County requires a solution that allows for immediate dispatch of appropriate units during the caller interrogation process without the need to complete the caller questioning. The Vendor should explain how their system works in this situation and what fields are needed for an immediate dispatch.

Fire/EMS Unit Solution Focused Questions Static Run Card Recommendations The County utilizes AVL and closest available unit as its primary means of fire resourcing; however, static run card recommendations must be available as a backup if AVL is inoperable. These static recommendations would be based on its response area and nature of the call. The response area assigned to a location allows the County to define multiple station response orders based on unit type and nature of the call. In addition, CAD will search for multiple types of units within a station before moving to the next station for a resource. The new system will need to accommodate the County’s current practices specified above and be capable of static run card responses that are unique to the agency and/or response area in the event they are needed.

Hybrid Unit Suggestion Method In alignment with the foregoing question re: static run cards, the County must understand how the system is able to incorporate both AVL and static run cards also requires that the proposed CAD system utilize a hybrid method for fire/EMS dispatching that allows for both AVL-based recommendations along with the standard unit recommendations consistent with a static station response. Specifically, the system should be able to use a standard run-card method and should allow for transitioning to AVL (Automatic Vehicle Location) location—or a mix of both. This hybrid method would utilize the standard static “in station” resource list while at the same time allowing the AVL application to replace any resource from the static station response by recommending closest-available units based on AVL data. This method of unit suggestion should also be able to incorporate penalties/costs for map features such as speed bumps and bridge height/weight restrictions.

Vendors shall explain if this type of dispatch feature is available in the offered solution, provide a description of how it functions and how dispatching/unit suggestion is configured, and any other potential uses for this feature within your system.

GIS Attribute Modifier The County seeks a solution that would allow different fire responses to the same call nature based on a hazard or building type associated with an address. This data would be an attribute in the GIS data associated with an address point. For example, a high-rise building would have a hazard attribute of S for special hazard, while a multi-family building may have a hazard attribute of H for high hazard. Vendors shall advise if their system is capable of obtaining this information from GIS and allocating a higher response based on this attribute. If so, describe how this feature is configured and implemented.

Move Ups/Transfer Assignments/Responsibility The County seeks the ability for the system to recommend apparatus or EMS move-up from one station to another in times of high call volume where one geographic area could be deficient in a specific apparatus type. Move-up recommendations should include the unit ID and location (region/district/area) being moved to. The moved unit then becomes a resource for deployment in the newly assigned location (region/district/area). Vendors should advise if their proposed solution has this functionality. If so, describe in detail the capabilities and functionality of the application.

Multi-Task Units/Concurrent Function The County seeks the ability to identify units as multi-task (i.e., a unit can fill both the advanced life support [ALS] and basic life support [BLS] functions on a medical incident, or a quint can be suggested for its ladder capability or engine capability but not both at the same time). The CAD system should recognize “multi-task” units such as engine/rescue or ladder/quint. These multi-task units should be able to be recommended in multiple CAD apparatus categories. This should be accomplished with a single CAD unit identifier, not with “ghost” units. Vendors shall explain how their system “counts” these multi-task units in deployment recommendations.

The CAD system should have the ability to adjust functionality on the fly with both the MDT and the dispatch terminal. As an example, an ALS engine paramedic rides to the hospital in an ambulance and is no longer on the engine. The unit officer or dispatcher can temporarily reclassify the engine from an ALS function while the unit remains in service as a BLS resource. This should work without taking one unit off-duty and placing another on duty. Vendors shall describe in detail how the proposed application handles this functionality and how it is configured.

Multi-Discipline incidents Currently when two (2) or more disciplines are dispatched to the same event (auto accident with injuries) the CAD system creates an event for each discipline. In turn, comments that one discipline adds to their call are not shared with the other disciplines. The County requires that calls requiring more than one (1) discipline have a shared event and all comments are also shared unless the dispatcher decides that the information should not be shared. An example of this might be CJIS data that law enforcement cannot be shared with non CJIS systems.

The County seeks:

· The ability to display law and fire/medical unit tracking on a combined (response) incident and display real-time narrative or supplemental incident entry. For example, Fire MDTs can view when police units are enroute or arrived on the call, or vice versa.

· The ability to show supplemental or narrative information among law enforcement and fire for scene safety, location changes, patient information etc.

· The ability to create law enforcement calls for each fire/medical call created based on call type. For example, an EMS mental health call would automatically create a law enforcement event and pass that event to law enforcement dispatch.

· Vendors should explain how their solution will meet the described functionality requested.

Display of High Hazard or Special Needs Facilities The County is interested in visually displaying high-hazard facilities/buildings to the dispatcher and mobile application. This would potentially include Superfund Amendments and Reauthorization Act (SARA) facilities, power/energy plants, hospitals, and nursing homes, to name a few.

Vendors shall explain how their system denotes these facilities to alert both dispatch staff and dispatched units. Vendors shall explain how their system could potentially pare down, via the map icon, to display building information or pre-plans.

Storm Alert/Busy Mode It is desirable that the CAD can switch to different response plans. For example, a feature of “storm mode” that would alter normal response and downgrade different call types during a storm or busy period. This would be a system setting that would be initiated by the floor supervisor at any time. Explain if your system has this feature and how it is initiated and displayed.

Divided Highways/Off Ramps/Mile Markers The highways in the County present many challenges for first responders. Namely, limited access, mile markers, on and off ramps at different locations, collector roads, etc. As such, responses, especially fire and EMS, utilize directional dispatching with companies responding from different directions.

Vendors shall explain how their system handles this challenge.

Incident Check/PAR Timer Prompt For firefighter safety considerations, the County requires visual prompts to the assigned incident telecommunicator to perform essential tasks. The proposed system must possess the capability to have an indicator to notify the telecommunicator controlling an incident that a task is due for a designated incident. This solution should be user-configured as to types of checks and time frequency. Examples of this are a twenty (20) minute timer to notify the Incident Commander of time on scene and a thirty (30) minute Personnel Accountability Report (PAR). Vendors should describe in detail the capabilities of their proposed solution.

Load Balancing The Fire Department has a need to balance the workload of responses between units in a station. The balancing will be configurable by call type and will also need to be by unit type and/or resource/capability. The balancing will reset at a prescribed time each day. Advise if your proposed solution has this capability. If so, describe how it is configured and how it functions.

Brower Based CAD Dashboard (Mini-CAD) Clay County Fire Rescue uses an in-house developed web-based application that they call mini-CAD. This system operates in parallel with the regular CAD system, although the mini-CAD is the preferred platform to use after the incident has been dispatched. The mini-CAD has features, such as a mapping platform that is judged superior to the related CAD product, the capability to hide units based on status and view only available units, as well as caller location/incident location. These options are an upgrade from the current CAD system. Vendors should describe in detail the capabilities of their solution to deal with this operational need.

Law Enforcement Solution Focused Questions Data Migration Migrating data from a legacy system can be a challenging undertaking and the County seeks the guidance of vendors in understanding the best proposed approach to dealing with this issue. County emergency communications and response personnel value an understanding of the history of locations, persons, and vehicles from prior events stored in CAD. Historical CAD data enhances situational awareness and responder safety in modifying response according to previous activity or known hazards. Considering the foregoing, the County is seeking the best solution to access legacy CAD data. Can the legacy data be housed in a separate database that can be queried and shared with first responders through CAD, or is a migration of the data to the new CAD solution the best option to achieve the desired results? Vendors should describe their approach with legacy CAD data when deploying their solution.

Data Dictionary and Access to CAD Reporting Database The County currently maintains a replica database of all CAD event data captured in the production database. This database serves as a reporting data warehouse where reports are created using third party analytical tools. The success of utilizing tools to mine data is predicated on the ability to understand where data resides within the database. Vendors should explain whether a comprehensive data dictionary is provided and if assistance is given in interpreting the data dictionary. County personnel believe that its CAD data is an invaluable tool for statistical analysis, operational planning, and a variety of other administrative purposes. The County seeks a detailed response as to how this issue will be addressed by your company.

Application Programming Interface Documentation and Future Interfaces The County seeks maximum flexibility in its new CAD solution during implementation and in the future as the capability to interface with other systems expands. To this end, the County desires an understanding regarding the availability of application programming interface documentation and its availability to the County to share with other vendors. Solution providers should address how the documentation is made available, if there is any cost associated with providing the API to future integration partners. Further, describe the level of effort typically required of your personnel during future interface development activities.

Alarm Monitoring and Registration The County seeks to find a solution that allows for registration and continual monitoring of alarm permits. The County Sheriff’s Office is integral to collecting and ensuring that alarms locations are registered and up to date on their fees. Vendors should describe their approach to this program.

Jail Management System Solution Focused Questions Booking It is Clay County Sheriff’s request that information (e.g., demographic, arrest) captured within the Arrest record in the LERMS, is available for import into the Jail Management System (JMS) populating demographic data to start a Booking. This will speed up the process and take less time during the Booking process.

Please describe how the solution handles Arrests from FBR and the workflow of how the data is transferred and leveraged to start the Booking record in JMS.

Fingerprint Interface The County Sheriff’s Office uses Data Works software/hardware to process/fingerprint arrestees at the central booking location. Currently the arresting officer must complete a paper booking form, and demographic information is manually entered into the Data Works system. The County Sheriff’s office is looking for a solution where demographic information contained in the Master Name Index (MNI) can be auto populated into the Data Works system via a bi-directional interface. Additionally, mug shots and updated demographic information collected in the Data Works system during the booking process can be imported into the MNI, as well as identify confirmation messages.

Juvenile Bookings Please describe how records are handled in the solution if a juvenile is originally booked as an adult and it is then discovered they are a juvenile.

Mug Shots The County desires the JMS solution to include mug shot functionality. The County wants to have mug shot photo functionality that centers on the subject’s eyes, in the mug shot photo, and then crops it automatically to conform to FBI standards. The Respondent shall explain if this functionality is offered in their mug shot solution and how it functions.

Medical Records The County currently utilizes a third-party software system to maintain prisoner medical records, however, the agency would like the ability to capture all medical information in the new JMS system including mental health data without using a third-party system.

Electronic Signature Capture During prisoner intake or release, inmate property is often exchanged, and a signature captured validating that the property was received or released. The Respondent shall describe its solution’s capability to capture signatures using an electronic signature capture pad. Electronic signatures should be captured throughout the entire process to eliminate paper.

Driver’s License Reader (DLR) and Barcode Scanner The County would like the ability to scan driver’s licenses or identification cards of inmates being booked and visitors to the jail. This should fill in the data on the Booking screen in JMS and could record the names of individuals as well as the date/time of the visits.

The Respondent shall describe its solution’s capability to interface with a Driver’s License Reader (DLR), read the information contained on the card, and incorporate it into the appropriate module within its software including in the field from Mobile.

Barcode scanning needs to be available to inventory property, do cell checks and check inmates in and out of different areas of the facility. Describe any other ways this can be utilized in the JMS system.

Provide a list of scanners that are supported by the respondent.

Commissary The County is looking for a solution that tightly integrates with Lockdown Commissary software. The solution will have the capability of checking the commissary system to see if an inmate being released has any pending commissary orders. The respondent should explain how their solution functions upon inmate release to identify any pending financial transactions for the inmate.

If an inmate has a pending Commissary order and it is then discovered they are being released, the solution will cancel all pending orders.

Commissary receipts must be electronically kept for three (3) years and the County desires the capability to batch upload electronic payments into the system. The County is willing to consider an integrated commissary system provided by the Respondent, if available.

Respondents shall explain if this type of feature is available in the offered solution, provide a description of how it functions, how it is configured, and any other potential uses for this feature within your solution.

Integration As referenced in the JMS Interface tables, integration with third-party systems in the corrections environment is critical to the daily operations of the County Sheriff’s Office. The County understands that the Respondent will work with the County to develop interfaces but, more importantly, the County is interested in the experience each Respondent has in interfacing with court systems, third-party medical, commissary, inmate phone systems, etc., to enable data sharing and efficiency of operations. The Respondent shall describe their experience in interfacing its JMS solution with third-party systems and how easily new interfaces can be developed.

The Respondent shall also provide information to determine if it is a tool made available to clients where interfaces can be developed in-house or whether that is a function that must be performed by the Respondent.

System Infrastructure Server Hardware and Network Throughput Specifications The County may procure the system hardware through the selected Vendor or elect to purchase it independently. As a result, the County is requesting that the Vendor provide a quote for Optional Hardware as indicated in the Pricing Forms. The Vendors should specify all hardware to operate the system at optimal performance levels at both the primary site and the disaster recovery site. The County will be providing the network infrastructure to host the primary data center and the disaster recovery center. Vendors are required to provide detailed specifications for each hardware component, a comprehensive system diagram that includes primary and disaster recovery sites, as well as data throughput requirements for the system. The Vendor is required to provide a system architecture and network design as Section 2A of the proposal (as an appendix to your Section 2 response). Whether hardware is procured by the County or purchased from the Vendor, it is the County’s expectation that the Vendor will certify the final as-built system infrastructure as meeting its requirements for optimal system performance.

· System overview, description of hardware and detailed hardware specifications, operating system, database and virtualization software and network configuration of the solution proposed.

· Hardware and system software documentation

· Operations and maintenance manuals

· System administrator documentation

· Data maintenance and system configuration documentation

· System functional specifications (CAD, mapping, mobile, reporting)

· System interface specifications or interface control documents (ICDs)

· Test plans and procedures

· Training materials (instructor guides and participant material)

· End user manuals (CAD, mapping, mobile, reporting) and quick reference guides Virtualization Information regarding Virtualization will be provided to registered Vendors, subject to completion of a non-disclosure agreement (NDA) to be provided by County. The information will be provided via secure access and is deemed Confidential Information of the County.

Multiple Environments It is the County’s preference that the proposed solution be designed to accommodate the following virtualized environments – testing, training, and production. The Vendor shall develop a system design that will allow users to access all system applications, interfaces, associated databases, and the geo-file/mapping system from any of the three environments. The testing and training environments shall be capable of replicating the production environment while not impeding the performance of the production environment.

The testing and training environments:

· Shall have a separate NG9-1-1 test connection or canned script ANI/ALI information and provide realistic training regarding incoming NG9-1-1 data.

· Shall have a separate telephony test connection or canned script caller information (i.e., wireline, cellular, no record found, and VoIP) and shall provide realistic training regarding incoming ten-digit data.

· Shall be able to be used, operated, started, shut down, and updated to match the production application without affecting the production environment.

· Shall be able to be used to test modifications and updates to the production CAD application prior to implementing the modifications and updates in the production environment.

· The Vendor shall ensure ongoing maintenance costs for the CAD include these environments in the proposed system cost section.

· Licensing must include all licenses required to operate and maintain the testing and training environments. All costs are to be included within the proposal response.

System Availability and Access The public safety mission of the County requires consistent operations. The proposed solution is expected to maintain a solution availability of ninety-nine-point nine hundred ninety-nine percent (99.999%) uptime annually. Routine maintenance or administrative procedures should not require system down time or a re-start to take effect.

There should be no single point of failure for any portion of the system at the primary site or the disaster recovery site.

The systems must be fault tolerant so if there is CAD system connection failure, it will continue to operate with the remaining connected systems. The solution must also be capable of automatically recovering when connectivity is restored.

The system must be fault tolerant so:

· If any server node of the distributed database cluster goes offline, the system will failover to a replicated database and continue to operate without system disruption or any data loss.

· If any single application server fails, the system will continue to operate in a reduced mode without system disruption or any loss of data.

Disaster Recovery Operations The County requires the proposed solution to have appropriate fully automated backup capabilities for the purpose of disaster recovery. This should include all database and application data. Backup media shall be in a format suitable for convenient off-site storage. The proposed solution shall provide differential backup schedules for various solution components configurable by the system administrator. Incremental and full back-up capabilities shall be provided. All backup and recovery processes shall be subject to auditing and reporting. Solution backups shall be accomplished without taking the application out of service and without degradation of performance or disruption to operations.

The system must provide a disaster recovery environment for maintaining a replica of the entire system that can be brought online in the event of a catastrophe that disables the primary operational environment. The database and software should be as near real-time as possible. System pricing must provide options for site licensing for inclusion of the disaster recovery site without requiring a separate system license. Further, the County’s expectation is that backup workstations with CAD client licenses are typically in a dormant state and pricing for these licenses should be calculated accordingly.

SYSTEM PERFORMANCE METRICS

Mission Critical System Availability The CAD system, as a mission critical operations platform, will be expected to meet very high-performance levels during peak operations and deliver exceptional system uptime that will be documented in the final contract. The following specifications describe the expected minimum performance requirements for the system following the County's formal acceptance of the system and throughout the life of the contract between the County and the vendor. These service levels (SLA) represent the County's expectations with regard to system availability, performance, restoral times, as well as potential credits to the County if the vendor fails to meet the contractually agreed SLAs. During contract negotiations, the County will negotiate remediation procedures and maintenance credits for failure to meet the SLAs as described.

For any consecutive thirty (30) day period during the life of the contracts and/or warranties, the software components of the System shall remain fully operational and available at ninety-nine point nine hundred ninety-nine percent (99.999%) availability (five point twenty-six (5.26) minutes of downtime/year). Thirty (30) day performance periods are incremental from system acceptance. If a problem occurs, a new thirty (30) day period will begin once the problem has been corrected. The County will decide and notify the vendor when issues have been satisfactorily resolved.

In the event that the system fails to meet any requirement of the contract after final acceptance and during the initial warranty period, the vendor shall take appropriate steps to resolve the problem and bring the system back into compliance with the performance and reliability requirements, at no cost to the County. In the event that the system fails to meet any requirement during the maintenance period, the vendor shall take appropriate steps to resolve the problem and bring the system back into compliance with the reliability requirements.

The vendor shall warrant that software supplied under this contract will be operational and meet availability SLAs during the warranty period, the warranty period will be extended on a day-for-day basis for each day the system performance falls below this level. Additionally, the County shall receive compensation in the form of maintenance credits for subsequent year's maintenance fees for failure to meet SLAs during the maintenance period.

Availability is defined as:

· Installed hardware/software components have power applied and are operating correctly.

· All functions and interfaces are installed and all the functional features necessary for the receipt (processing) and dispatching of calls for service and emergency resources are operating correctly.

· System availability will be expressed as a percentage of the maximum expected availability over a given period. The system shall be available twenty-four hours, seven days a week, three hundred sixty-five days a year (24/7/365). Scheduled down time, as defined by the successful vendor and accepted by the County, will not be construed as hours when the system is unavailable.

Loading Assumptions The proposed system design should provide for a minimum of 35 active CAD users and a minimum of 250 active mobile computers during the peak busy hour and the system shall provide the performance defined. Vendors will not be responsible for the processing time of external systems (e.g., FCIC) when such systems are involved in a transaction.

Response Time Requirements Transaction Maximum Response Time for CAD and Mapping All commands associated with routine event workflow from CAD event initiation to final disposition (any command that enables dispatching and call taking functionality) should take no longer than one (1) second (sub-second), ninety-nine percent (99%) of the time. This includes, but is not limited to the following transactions:

· Display of blank event entry screen

· Assigning multiple unit(s) to an event

· Changing unit(s) status

· Clearing unit(s) from an event

· Transfer of event from call taker to dispatcher terminal must occur

· Population of map with caller location after latitude/longitude (x/y coordinates) entered into event

· Display of FCIC/NCIC returns Note: any occurrence where response times are over one (1) second that lasts longer than five (5) seconds in duration could result in an operational transition to manual mode. As a result, this performance degradation will be considered a Severity 1 issue.

Response times of less than two (2) seconds ninety-nine percent (99%) of the time for the following transactions:

· Verification of a unique address

· Return of a list of possible address matches when an address cannot be uniquely verified with the information entered

· Display unit recommendation based on uniquely verified address Transaction Maximum Response Time for CAD and Mobile Data System The System shall provide response times of less than two (2) seconds ninety-nine percent (99%) of the time for the following transactions:

· Mobile-to-Mobile e-mail message, eighty (80) characters

· CAD-Mobile dispatch message

· Query premises/hazard file data

· Display a list of events queried by unit ID for a single shift Other performance requirements:

· All inquiry and file maintenance functions shall be performed without adversely affecting system performance and system operations.

· System shall perform backups or other system administration tasks without impact on system operations.

· System shall perform report and search functions without impact on system operations. Impact includes any slowdowns of the system.

The initial system hardware design should be scalable to allow for enhancements to the hardware configuration so that increases in transaction volume, up to one hundred fifty percent (150%) of current volume can be accommodated and maintain the specified system performance requirements. The expanded system must continue to meet the functional, reliability and performance requirements as expressed in this specification throughout the life of the system.