CountyofPowhatan,Virginia RequestforProposals RFP‐2016‐04 ComputerAidedDispatch/Records ManagementSystem Issued: January 23, 2017 Powhatan County Administration Building Department of Finance 3834 Old Buckingham Road, Suite B Powhatan, VA 23139 RFP COVER SHEET Issue Date: January 23, 2017 RFP‐2016‐04 Title: Computer Aided Dispatch / Records Management System Commodity Code: 20800, 20830 Issuer: The County of Powhatan Virginia Office of the County Administrator 3834 Old Buckingham Road, Suite A Powhatan, VA 23139 Sealed Proposals Will Be Received Until February 24, 2017 at 2:00 PM, For Furnishing The Goods and/or Services Described Herein. All Inquiries For Information Should Be Directed To: Charla Schubert, Director of Finance Phone: (804) 598‐5610 E‐mail: [email protected] If proposals are mailed, send directly to contact address shown above. If proposals are hand delivered, deliver to: Powhatan County, Department of Finance, 3834 Old Buckingham Road, Suite B, Powhatan, VA 23139 ATTN: Charla Schubert, Director of Finance In Compliance With This Request For Proposals And To All The Conditions Imposed Therein And Hereby Incorporated by Reference, The Undersigned Offers And Agrees To Furnish The Goods/Services In Accordance With The Attached Signed Proposal Or As Mutually Agreed upon By Subsequent Negotiation. Name and Address of Firm: ______________________________________________________________ _____________________________________________________________________________________ City / State / Zip Date By: _________________________________ Name: ___________________________________________ (Signature in Ink) (Please Print) FEI/FIN No.: ____________________________ Email: _______________________________________ Phone No.: ______________________________ Facsimile: _____________________________________ This public body does not discriminate against faith‐based organizations in accordance with the Code of Virginia, § 2.2‐ 4343.1 or against a bidder or Offeror because of race, religion, color, sex, national origin, age, disability, status as a service disabled veteran, or any other basis prohibited by state law relating to discrimination in employment 1 xz Contents 1. 2. 3. PURPOSE ....................................................................................................................................................... 4 BACKGROUND .............................................................................................................................................. 4 SCOPE OF WORK ........................................................................................................................................ 6 3.4. SOLUTION OPTIONS........................................................................................................................ 7 3.5. REQUIREMENTS .............................................................................................................................. 7 4. 5. PROJECTSCHEDULE .................................................................................................................................... 8 PROPOSALPREPARATIONANDSUBMISSIONINSTRUCTIONS ................................................................ 8 5.1. GENERAL INSTRUCTIONS ................................................................................................................ 8 5.2. PROPOSAL PREPARATION............................................................................................................... 9 5.2.2. Proposal Response Format ..................................................................................................... 9 5.2.3. Cover Letter ............................................................................................................................ 9 5.2.4. Company History .................................................................................................................... 9 5.2.5. Relevant Experience ............................................................................................................. 10 5.2.6. Description of Proposed Software Solution ........................................................................ 10 5.2.10. Oral Presentation: ................................................................................................................ 12 5.2.11. Incurred Expenses: ............................................................................................................... 12 5.2.12. Addenda: ............................................................................................................................... 12 5.3. TECHNICAL PROPOSAL...................................................................... Error! Bookmark not defined. 5.3.1. Offeror’s Profile, Qualifications and Experience ................................................................. 12 5.3.2. Similar Engagements with other Government Entities ....................................................... 13 5.3.3. Specific Work Plan and Approach ........................................................................................ 13 5.4. 6. 7. 8. WARRANTY ....................................................................................... Error! Bookmark not defined. TECHNICALREQUIREMENTSANDCONFIGURATION ............................................................................ 13 EVALUATIONANDAWARDCRITERIA ..................................................................................................... 50 TERMSANDCONDITIONS ......................................................................................................................... 50 8.1. GENERAL: ...................................................................................................................................... 50 8.3. APPLICABLE LAWS AND COURTS: ................................................................................................. 51 8.4. ANTI‐DISCRIMINATION: ................................................................................................................ 51 8.5. ETHICS IN PUBLIC CONTRACTING: ................................................................................................ 52 8.6. IMMIGRATION REFORM AND CONTROL ACT OF 1986: ............................................................... 52 8.7. DEBARMENT STATUS: ................................................................................................................... 52 8.8. ANTITRUST: ................................................................................................................................... 52 8.9. PROPOSAL FORMAT: .................................................................................................................... 52 8.10. LATE PROPOSALS AND MODIFICATION OF PROPOSALS: ............................................................. 53 8.11. CLARIFICATION OF TERMS ............................................................................................................ 53 1. PURPOSE:The purpose of this Request for Proposal (RFP) is to solicit sealed proposals to establish a contract through competitive negotiation for the purchase of a fully integrated Computer Aided Dispatch (CAD) and a Records Management System (RMS) with Automated Field Reporting (AFR) for the County of Powhatan. The CAD system will be utilized by Powhatan County’s 9‐1‐1 Emergency Communications Center to facilitate the receipt of calls‐for‐service requests and subsequent dispatch via radio and on‐board mobile data computers to necessary First Responder resources consisting of Powhatan Sheriff Deputies and/or Powhatan Fire & Rescue personnel. The RMS will be utilized by the Powhatan Sheriff’s Office. The current CAD and RMS systems are at the end of their service life. 2. BACKGROUND 2.1. The County of Powhatan is a community of 28,000 residents that is located on the western edge of the Richmond Metropolitan Area, approximately 20 miles west of the City of Richmond, Virginia, the State Capitol. The County is bound by Goochland County and the James River to the north, Chesterfield County to the east, Amelia County and the Appomattox River to the south, and Cumberland County to the west. 2.2. The County has easy access to major interstates with Interstate 64, a major east‐west highway within eight (8) miles of the County. Rt. 288, the western by‐pass around Richmond connecting Interstate 64 and Interstate 95, is located along the County’s northeastern corporate limits with both State Routes 60 and 711 providing access to Powhatan from Rt. 288. Richmond International Airport is located 40 miles from the County. 2.3. Although predominately rural in character, the County has experienced significant residential growth in recent years as the Richmond area migrated westward. The County’s population increased 25% between the 2000 and 2010 Census. As one of the fastest growing communities in the Commonwealth, the County is committed to preserving its rural charm while providing first‐rate public safety protection for its residents and business partners. To support that goal, the County is looking to replace the current Public Safety CAD system and the Records Management System used by the Powhatan County Sheriff’s Office. 2.4. The current Public Safety CAD system utilizes IBR_Plus by DaPRO systems, a SQL server based CAD/RMS. The CAD/RMS system is utilized by the following users: Powhatan County Sheriff’s Department The Sheriff's Office is a multi‐faceted law enforcement agency which enforces all criminal and traffic laws and investigates more than 95% of the criminal complaints in the county. The Sheriff’s Office is also responsible for the security of court rooms, the movement of prisoners, and the enforcement of court orders. The Sheriff's Office employs 40 full‐time deputies and investigators, five part‐time deputies and 6 civilians. The Sheriff’s Office utilizes 26 mobile data terminals (MDT) for CAD and AFR. The new system will be replacing the current Law Enforcement RMS including; Master Name File, Master Vehicle File, Civil Processing, Property Management, and Image catalog. The Department does not regulate a jail or need jail management software. The office utilizes 12 PC’s for reporting and access to RMS. 4 Powhatan County Fire and Rescue Department The Fire and Rescue Department, which includes the volunteer fire/rescue companies, provide emergency medical aid and fire suppression at the scene of accidents and emergencies. The Fire and Rescue Department is staffed with a full‐time Fire and Rescue Chief, an office manager, 5 various part‐time staff, contracted daytime EMS services, and approximately 280 active volunteers. These staff and volunteers work from 9 different locations including the Fire and Rescue Administrative Office. The Department utilizes ImageTrend Elite for both Fire RMS and EMS ePCR reporting. Current Fire and Rescue MDT’s do not directly interface with the current CAD. The Department will need licenses or permission to interface with at least 53 MDT’s DT’s and 9 station terminals for access to the CAD. Station terminals can be through a web based secure application. Communications Center The County’s enhanced 911 system (Dispatch) is under the direction of the Sheriff. The 15 employees dispatch the Sheriff’s Office, other police agencies and fire/rescue units 24 hours a day. In 2014, dispatchers fielded 8,424 calls for 911 emergencies and over 40,000 non‐ emergency phone calls for police/fire/ems services. A new Dispatch center is under construction and will require 6 active CAD workstations, with possibly 4 non‐active or training terminals. Implementation of the new CAD/RMS within the current center location is not anticipated. The dispatch center utilizes: • Association of Public Safety Communications Officials (APCO) Emergency Medical Dispatch (EMD) software integrated within the IBR_Plus software, for EMD processing. • Airbus DS Communications (Cassidian) Vesta 9‐1‐1 V.4 for E911 phone processing • Revcord V.9 Digital Logging Recorder 5 Communications Center Floor Plan 3. SCOPE OF WORK 3.1. The CAD/RMS vendor will: Provide all software necessary to accomplish the end goals of this project. Provide user and administrator training for software management. Provide for the migration of data from the department’s current CAD/RMS software to the new system. Provide for the population of all database and tables (IE: statutes, ordinances, codes, etc.). Provide an interface for the importation of data from related systems as defined here 6 in. Provide an interface to the Fire and Rescue RMS and Electronic Patient Care Reporting (ePCR) Systems. Provide a detailed list of necessary hardware. 3.2. The County of Powhatan will be responsible for ensuring the County’s computer system meets the minimum standards for the software being provided by the vendor and will work with the selected vendor to ensure any specific hardware needs are met. The expectation is that the selected vendor will have an extensive CAD/RSM background and will provide a fully integrated system to replace our legacy CAD/RSM. The selected vendor will be responsible for the implementation of all selected components, project management, training, data migration, and providing a complete installation that meets the performance requirements as stated in the final contract. 3.3. The County is soliciting proposals from qualified vendors to acquire fully‐integrated comprehensive software to satisfy all the CAD and Law Enforcement RMS computing needs of the department from a single vendor. While this is not an absolute requirement, single‐vendor solutions will be given greater weight. 3.4. Additionally, the department would like to operate in a nearly paperless environment in which any form or piece of information can be easily printed when necessary, but in which paper filing is not the norm. 3.5. The components of the software to meet this need ideally will include all of the following modules/functionalities (Attachment A). Vendors who have a majority of these functionalities should respond to this RFP. Some of these functionalities are more important to the county and will be given greater weight during the evaluation. 3.6. SOLUTION OPTIONS The proposal should include one cost proposal to account for single, shared CAD and RMS hosted at a single location with the ability to limit the data through user defined security among and between the agencies, if required. 3.7. REQUIREMENTS The Attachment A: Requirements Worksheet must be completed and returned in the original Excel format (PDF is not an acceptable format). Proposals must include specific responses to each of the requirements and highly desired features. Proposal responses shall adhere to the following code guidelines: E = Existing: Requested function will be met by proposed existing software and/or hardware that is installed and operational and can be demonstrated. M = Modification: Requested function will be met by a proposed minor modifications to the existing software and/or hardware or use of software tools. All work shall be performed by the vendor. 7 C = Custom enhancement: The vendor’s base product does not contain this function or feature but it will be added to meet the requirement. Cost, if any, must be itemized in the Pricing Section. T = Third Party Solution: The requested function will be met by adding an existing third party software and/or hardware. Integration work will be performed by vendor and the third party. N = Not Available: Requested function cannot be provided. IMPORTANT NOTES: An omitted response will be assumed to be the same as “Requested function cannot be provided” (i.e. Not Available). All costs associated with “M”, “C”, or “T” responses must be included in the pricing 4. PROJECTSCHEDULE 4.1. Submittals should include a proposed schedule for the project. 4.2. The County of Powhatan will adhere to the following schedule: Event Date County Publishes Request for Proposals January 23, 2017 Deadline to Submit Questions February 14, 2017 County to Respond to Questions February 17, 2017 RFP Submission Deadline by 2:00 PM. February 24, 2017 All dates past the submission deadline are a tentative schedule of this entire RFP process. The dates are merely projections and the County of Powhatan reserves the right to modify this schedule as needed to accommodate the completion of this RFP process. 5. PROPOSAL PREPARATION AND SUBMISSION INSTRUCTIONS 5.1. GENERAL INSTRUCTIONS 5.1.1. RFP Response: In order to be considered for selection, interested parties must submit a complete response to this RFP. 5.1.2. RFP Questions: Address questions concerning this RFP to: Charla Schubert, Director of Finance 8 3834 Old Buckingham Rd. Suite B Powhatan, VA 23139 804‐598‐5610 e‐mail: [email protected] Offerors shall submit any questions in writing. Written responses, including the questions, will be posted with the RFP. Questions will not be accepted within ten (10) days of the Due Date and time of this RFP. 5.1.3. Ownership of Proposals: Ownership of all data, materials, and documentation originated and prepared for the County pursuant to the RFP shall belong exclusively to the County and be subject to public inspection in accordance with the Freedom of Information Act. Any proprietary or trade secrets material submitted must be identified as such, and must indicate the specific words, figures, or paragraphs specifically, and with a reason why such material is proprietary or a trade secret. The classification of an entire proposal document, individual pricing or total proposal prices is not acceptable and will result in rejection and return of the proposal. 5.2. PROPOSAL PREPARATION 5.2.1. Ten (10) copies of proposal submittals, including one (1) original and nine (9) copies, and one (1) electronic (PDF) copy of their proposal marked REQUEST FOR PROPOSALS – Computer Aided Dispatch / Records Management System. Proposals shall be submitted by the date and time specified on Page 1 of this RFP to the address as listed on Page 1 of this RFP, in sealed packaging properly identified. 5.2.2. Proposal Response Format The RFP response should be written and organized in the exact order of each line item in this RFP. Proposals should be as brief as possible and should not include any unnecessary promotional material. Restrict the proposal to no more than 50 pages total, including all responses, reference work, and information about the firm and individuals assigned to the project. 5.2.3. Cover Letter Include the name, address, telephone number and contact person for your company. 5.2.4. Company History Provide: A. If appropriate, the names, business address and telephone number of your company’s officers, directors and associates and the names and addresses of any parent or subsidiary of your company. Your information should describe the nature of the work and the line of authority of these individuals and/or companies as they relate to this RFP. B. Number of years in business and a historical overview of products, including how many times the company has been sold, merged, or acquired any other company to 9 integrate or interface their products. If the CAD, Mobile or RMS systems are separate modules or are acquired from another source, include the purchase history. C. How many full‐time employees the company currently has, how many of these are database developers or administrators, and whether or not your company sub‐ contracts with other companies. Include the responsibilities of any sub‐contractors your firm proposes using as part of your proposal submission. D. Statements as to whether any of the following events have occurred in the last five years with the company (as its current entity or as a predecessor entity). If yes to any of the following, provide a full explanation for each line item: a. Was the company the subject of any order, judgment or decree b. Was the company’s business the subject of any civil or criminal proceeding in which there was a final adjudication adverse to the company c. Was a petition under bankruptcy, insolvency, or receivership filed by or against the company E. Has the company: a. Supported a program where services were terminated b. Supported a program where services were temporarily discontinued directly arising from activities conducted by the company c. Supported a program that required substantial fines or refunds that directly arose from program related activities 5.2.5. Relevant Experience This section should include references and contact information from current customers, preferably agencies in Virginia or the Mid‐Atlantic Area. A brief synopsis with a list of several customers currently using the proposed system should be included. Include a description of the projects, software installed and the public safety contact name, title, and address. 5.2.6. Description of Proposed Software Solution Provide detailed technical and functional information related to the company’s product(s) and provide details on which modules are separate, interfaced or fully integrated. Describe the company’s base system as it operates today. Include a list of features and/or modules that are included in the basic system purchase. If the company’s database has interfaces with other databases, explain how the system operates. Outline the company’s basic design philosophy and briefly explain how that philosophy will fit with the Powhatan County Project (e.g., is the company’s solution centralized, modular, or does it define every component as an option that can be turned on or off). A. Core System and Modules Provide detailed information on the core system and its included components. Specify all modules by name and function: (Example: CAD, RMS, AVL, Field Reporting, MDC [Mobile], Property/Evidence, JMS, etc.) and whether they are interfaced and/or separate or fully integrated. 10 B. Versions and Life Cycles Provide the current version, release date, lifecycle and end‐of‐life date for the core system, each module, any third‐party solution and any Operating Software (OS) or database software used by the proposed system. List the programing language and version of any application server and the data base operating system. Include any other ancillary applications that are used to operate the system (e.g. workflow, dashboards, alerts, etc.) C. Technical Requirements Describe technical requirements and the technical environment for the use of the company’s software. Provide information on what Powhatan County will need to utilize the company’s proposed system. Provide the minimum hardware and software specifications for networking & security, server, database and client that are required to install and run the application. Specify any physical requirements, including space needs, Uninterrupted Power Supply Systems (UPSs), electrical power, cooling, etc. Include specifically which application requires or is recommended to run on a separate database (e.g. online reporting, Dashboards, Reporting). Include other third party licensing requirements. Include all requirements and costs clearly noted and broken down by line item, for a virtual server environment. Include all requirements for backup recommendations. The technical requirements should be included in Attachment B – Cost Spreadsheet. D. Reporting and Dashboards Include a list of all current reports built into the company’s proposed system. Include a description of how the software manages the cross checking of errors to ensure accurate reporting. Include a description of how ad‐hoc reporting or queries are handled within the company’s system for an average user. Include how crime analysis can utilize the company’s system and include if this functionality is standard or add‐ on. Include any foreseen circumstances where a third‐party reporting system may be required (e.g. Crystal Reports). Describe any features, such as Dashboards, and how the data is combined (e.g. is a separate database required to support Dashboard) and how is it presented to the users. E. Unique Features Identify any unique or distinctive features in the company’s system that differentiates the company’s product from competitors’ products. F. Training Public Safety operations is a 24/7 environment. Provide a training plan to accommodate training in a 24/7 environment, including weekends to limit any required overtime of personnel. Provide training time frame requirements for all staff assignments based on role (i.e., Patrol, Communications Staff, Detectives, Records Staff, Command Staff, Property and Evidence Staff, Jail Staff, Internal Affairs Staff). Include the number of hours each employee/work group is required to train in system administration, report‐writing, dispatch, records, jail, mobile and any other included modules. Provide a sample staff training agenda. Provide a description of the training support that will be provided on‐site when going live with the new 11 system, and how long this support will be provided. Include post go‐live training in this plan. Include cost proposals for a Train the Trainer approach and a vendor‐only led training. Recommend the best option based on the company’s previous implementations. 5.2.7. Proposals shall be signed by an authorized representative of the Offeror. All information requested should be submitted. Failure to submit all information requested may result in the County requiring prompt submission of missing information and/or giving a lowered evaluation of the proposal. Proposals, which are substantially incomplete or lack key information, may be rejected by the County. Mandatory requirements are those required by law or regulation or are such that they cannot be waived and are not subject to negotiation. 5.2.8. Proposals should be organized in the order in which the requirements are presented in the RFP. All pages of the proposal should be numbered. Each paragraph in the proposal should reference the paragraph number of the corresponding section of the RFP. It is also helpful to cite the paragraph number, subletter, and repeat the text of the requirement as it appears in the RFP. If a response covers more than one page, the paragraph number and subletter should be repeated at the top of the next page. The proposal should contain a table of contents, which cross‐references the RFP requirements. Information which the Offeror desires to present that does not fall within any of the requirements of the RFP should be inserted at an appropriate place or be attached at the end of the proposal and designated as additional material. Proposals that are not organized in this manner risk elimination from consideration if the evaluators are unable to find where the RFP requirements are specifically addressed. 5.2.9. Oral Presentation: Offerors who submit a proposal in response to this RFP may be required to give an oral presentation of their proposal to the County. This provides an opportunity for the Offeror to clarify or elaborate on the proposal. This is a fact finding and explanation session only and does not include negotiation. The County will schedule the time and location of these presentations. Oral presentations are an option of the County and may or may not be conducted. 5.2.10. Incurred Expenses: The County will not be liable for any cost incurred by Offerors in preparing and submitting proposals. Offerors may not collect proposal preparation charges from the County of Powhatan as a result of cancellation of this RFP. 5.2.11. Addenda: Return the RFP cover sheet and all addenda acknowledgments, if any, signed and filled out as required. By submitting a proposal Offerors certify that all information provided in response to this RFP is true and accurate. 5.2.12. Offeror’s Profile, Qualifications and Experience This section of the proposal should: 12 a) Provide a detailed plan for completing this system installation to include the project life cycle which must include initiation, design, development, testing, implementation, and closure upon final acceptance. b) Any supporting documents including all services, research, reports, etc. listed in this RFP. This should include graphs, charts, etc. demonstrating workflow, responsibilities, project meetings, milestones, deliverables etc. c) Provide the organization and size of the Offeror, and the location of the office from where the work on this engagement is to be performed and the number and nature of the staff to be employed in the engagement on a full‐time basis and the number and nature of staff to be employed on a part‐time basis. d) Identify the principal supervisory and management staff who would be assigned to the engagement. Provide resumes and information on the experience of each person. 5.2.13. Similar Engagements with other Government Entities This section of the proposal should: a) List and describe representative clients currently served by the Offeror’s office. b) Provide the name, address, phone number, and e‐mail address of three (3) specific local government references where one or more of the assigned staff rendered the same or similar services. The County will contact given references. c) Each reference should include the scope of services provided to each referenced client. 5.2.14. Specific Work Plan and Approach The proposal should set forth a detailed work plan indicating specific activities and timelines necessary to complete the scope of work required by this request for proposal. 5.2.15. Detailed price proposal In this section provide a detailed price proposal to include all costs associated with providing the solution proposed. 6. TECHNICALREQUIREMENTSANDCONFIGURATION 6.1.1. In order to support the Call Handling function, the CAD system: Shall import and attach/append, automatically upon user command, automatic number information (ANI) and automatic location information (ALI) to a CFS. Should import (automatically) external alarm data that conforms to the APCO/CSAA (Central Station Alarm Association) published ANS; and, should generate a CFS upon receipt of a new alarm notification. Should import (automatically) a CFS received from another CAD system. Shall import (automatically) a CFS generated on an MDC. 6.1.2. In order to support the CAD Incident / Event Types function, the CAD system: 13 Shall allow for system administrator‐defined CAD incident types or nature codes. Shall allow system users to modify the incident type and provide new/updated response plan information/suggestions based on the new incident type. Shall provide the capability to create an event, assign a unit, and close the event with a disposition without going through the dispatch process steps. Shall provide the capability to flag a CFS as an “Advised Event” separate from the incident type/nature code. 6.1.3. In order to support the Update Call for Service Event Data function, the CAD system: Shall enable the user to enter supplemental (new) information into the CFS event record of one or more user‐specified CAD events. Shall display a notification of the event update at each appropriate CAD position whenever an active event record is updated, as determined by the system’s configuration. Shall create an automatic time/date stamp for every transaction related to an event, and shall store the responsible operator’s identification (ID), the console ID, and the nature of the change. Shall add audit records to the event history or store audit records in the CAD system’s audit log file in chronological order; and, shall provide a complete historical audit of all event activity (e.g., comments, unit status changes, license plate information, field updates). Shall store old entry information, with the appropriate date, time, operator ID, and console stamps if the new entry replaces existing information in the event record. Shall enable the audit information to be retrieved and printed in both summary and detailed formats when incident information is displayed. Shall create a permanent audit trail for all information recorded related to an event, whether or not that information is later modified or deleted. Shall support ease of entry for supplemental event information and changes to existing event information. Shall allow the user to display a supplemental data entry screen by specifying either the event number or a unit assigned to the event. Shall allow the user to display a data entry screen to change information previously entered into a CAD event by specifying either the event number or a unit assigned to the event. Shall provide agency‐definable visual and audible alerts to notify field units and other appropriate CAD system users, including users of systems interfaced to CAD such as Mobile Data Computers, of event changes and supplemental information. Shall allow the user to add supplemental information and/or change active events. Shall allow the user to update any field in the CFS event record (except user‐designated fields, such as application‐generated times and date stamps, operator identification information, ANI/ALI information, and CAD position that completed a CAD transaction). Shall document all changes and supplemental information in the event history. Shall provide an event update/change data entry screen. Shall allow the user to update or change a unit’s most recent event by entering the unit’s identification or any unit that is currently assigned. Shall require confirmation from the user when attempting to update any field in a closed event. 14 Shall provide the user with acknowledgment that an update to a CAD event record was successfully completed. Shall allow the user to supplement and/or change active events. Shall allow the user to supplement and/or change any field of a closed event without having to change the state of the event. 6.1.4. In order to support the Determine Dispatch Need function, the CAD system: Shall provide the capability to close out the CFS record without assigning a resource, if it is determined that a CFS does not require the assignment of a resource(s). Shall allow the user to append a disposition code and comments to events that are not assigned any resources. 6.1.5. In order to support the Utilize Incident Disposition function, the CAD system: Shall allow the user to enter one or more dispositions, as dictated by agency policy, when a CAD event is closed. Shall close a CAD event record automatically if no resources remain assigned to the event. Shall provide the capability for a mobile unit to enter one or more dispositions when clearing from a CAD event. Shall allow the system administrator to define disposition codes. 6.1.6. In order to support the Assign Incident Classification and Priority function, the CAD system: Shall enable CAD users to select the appropriate incident/event type from a pre‐ defined list of codes based upon information received from reporting party. Shall provide, in a multiple dispatch agency or jurisdiction environment, the ability to create multiple CFS events with a single CFS event entry (e.g. a shooting incident type would create a law enforcement, EMS, and possibly a fire event). Shall provide the ability to generate a CFS event with only the location and incident type code entered. Shall allow the user to upgrade or downgrade the CFS event to fit the reported event by changing the priority for the event. Shall allow the user to utilize incident screening menus, such as a drop‐down menu, to assist in determining the appropriate incident/event type code. Shall allow the user to interrupt the CFS event creation process and save entered information, sometimes known as call stacking, to process a higher priority incoming incident. Shall provide a warning notification of the held CFS event generated at an administrator‐ configured time. Any position can review current CFS events, retrieve a partial CFS record, and complete the CFS event entry. The number of partial CFS events that can be stacked by a single position Shall be an administrator‐configurable system parameter. Shall provide the ability to override the event priority for each agency. Shall provide the ability to create and maintain incident screening menus or prompts that can be used to aid the call taker in determining the appropriate incident/event type code. Shall provide the ability to save one or more partially completed CFS events in order to enter a higher priority incident, keeping all entered data intact. 15 Shall provide a warning (visual and/or audible) that a partially completed CFS event has been held for an administrator‐defined period of time. Shall provide the ability to view a summary of all system‐wide, partially‐completed CFS events being held and awaiting completion. The summary shall include, at a minimum, the position and user ID that placed the CFS event on hold and the elapsed time that the CFS event has been on hold. Shall provide the ability to redirect assigned resources to a higher priority CFS event based on agency defined criteria. Shall store all active and partially completed CAD events in system administrator‐ configurable queues. Shall allow CAD users to be able to select a partially completed CFS event from a CAD event queue and complete the CFS entry process. 6.1.7. In order to support the Check for Duplicate Incidents function, the CAD system: Shall store all transactions resulting from the duplicate event detection process in the system’s audit log. Shall identify during the creation of a CFS event whether the event is a potential duplicate of an active CAD event or an event recently closed; and, Shall notify the call taker of the results. Shall check, as configured by the system administrator, by exact street address, street address block range, or geo‐coordinates, the location of each new CFS event to determine whether another event exists. Based on system parameters set by the administrator, either all matching events shall be presented to the user, or only those events with the same or similar nature code. Shall check, as configured by the system administrator, within a pre‐defined search radius of the location of each new CFS event, to determine whether another event exists within the search radius. Based on system parameters set by the administrator, either all matching events shall be presented to the user, or only those events with the same or similar nature code. Shall allow an authorized user to change the duplicate event search parameters (e.g. distance, exact street address match only, street address block range). Shall present the user with the following information for each potential duplicate event if potential duplicates are located: Incident ID Type of incident Location of the incident Status of the incident Shall allow the user the ability to create a new CFS event and link the event to the primary event record; or, to merge any new information contained in a duplicate event into the main event record associated with the identified duplicate CAD event. Shall allow the call taker to re‐open closed CAD events that are duplicates of a new event, add additional information to the re‐opened CAD event records, and, if necessary, re‐ route them back through the dispatch process. Shall, based on agency policy, restrict users from changing or deleting any previously entered data contained in re‐opened closed CAD events. Shall cross‐reference duplicate events to the primary event records, leave both events open, or abandon processing of the duplicate event. 16 6.1.8. In order to support the Incident Information function, the CAD system: Shall provide the ability to create a CFS with minimum required fields (e.g. location and event type). Shall provide the ability to dispatch once location and nature are obtained. Shall provide the ability to alter/augment event as further information is obtained by the call taker. Shall include an automated connection/interface to the 9‐1‐1 telephone system to use ANI/ALI data to populate the incident entry screen form. Shall provide the ability to use ANI/ALI data to assist with CFS entry. Shall provide the ability to enter defined sized narrative with text wrap‐around feature. In order to support the Determining Capture Locations function, the CAD system: Shall obtain all different versions (Standard, Standard Plus, and Extended Plus) of ANI/ALI information automatically from interfaced phone systems without requiring the user to manually re‐enter the information into a CAD event entry screen. Shall append 9‐1‐1 reported data to the record if the user has entered data into any field before accepting the 9‐1‐1 information, but not overwrite the data entered by the user. 6.1.9. In order to support the Location Verification function, the CAD system: Shall provide the ability to enter a unique building and unit number to clearly identify the location (e.g. 100 West Ave., Bldg. 2, Unit 1). Shall, depending on the permissions granted to the user, provide the ability to edit ALI 9‐ 1‐1 information in the event record if the information provided by the phone company is incorrect. Shall include the following fields for all records containing an address: street number; apartment/suite number; street; road type (Drive, Avenue, Street, Alley); direction; city, state, and/or zip code (modify list as appropriate). Shall validate entered incident addresses against the CAD geofile. Shall provide various suggestions to assist users in selecting accurate incident locations. Shall allow each address or commonplace name to have an unlimited number of alias names. Shall allow authorized users to store multiple names for businesses and tenants for a given street address. Shall organize the display of possible address matches in an ergonomic, easily understood manner that aids users in identifying valid incident locations. Shall allow authorized users to configure their tactical map display to show jurisdictional boundaries (e.g. city boundaries) and to display potential valid incident locations by jurisdiction. Shall allow the user, in case the location entered by the user is unverifiable (e.g. the location does not exist in the geofile), the capability to exit or bypass the verification process and manually route the CFS event(s) to the appropriate dispatch position(s). Shall provide the ability to enter a partial street name, with a minimum number of characters, and be presented with a list of possible matches to pick from for an exact match. Shall provide the ability to enter a misspelled street name and be presented with a list of possible matches based on SOUNDEX6 and/or other methodology. 17 Shall provide the ability to enter an incorrect street address for a correct street name and be presented with a list of valid ranges. Shall provide the ability to enter common street alias and abbreviations instead of the actual street name (e.g. MLK for Martin Luther King Blvd). Shall provide the ability to override the CAD system’s geofile by manually entering valid response area data. Shall provide the ability to enter a reason for an overridden location. Shall provide the ability to generate a report of geofile overrides. Shall provide the ability to display the incident location in relation to other active incidents on the system’s tactical map display during the CAD event entry process. Data entry fields containing an address shall follow the NENA Standard for NG9‐1‐1 GIS Data Model (71‐003), Section 3.5 (GIS Database Model Layers) and should, at a minimum, include the data elements contained in the Site/Structure Address table. 6.1.10. In order to support the Retrieve Incoming Calls function, the CAD system: Shall include an interface to the 9‐1‐1 telephone system that, upon user command, causes the automatic transfer of an emergency call’s ALI information from the telephone system to an appropriate field of the CAD event data entry screen. Shall allow call takers to initiate a CAD command/or function that will cause the CAD system to populate the CAD event data entry screen with call‐back telephone number information if it is available. Shall transfer, depending on PSAP policy, the telephone subscriber’s name to a field in the CAD event data entry screen’s reporting party’s name data field. Shall include data fields within the CAD event data entry screen for reporting party’s name, address and callback number. 6.1.11. In order to support the Involved Person Information function, the CAD system: Shall be capable of collecting the following information about each individual associated with an event: Age Date of Birth Eye Color o Hair color o Height Name Operator’s License Number Operator’s License State Race Sex Weight Additional remarks (e.g. clothing description, scars/marks/tattoos) Shall initiate an automatic query, upon entry of information about an individual associated with an event, using the following guidelines at a minimum: If the name only is known, then a name query shall be initiated to local files capable of performing a lookup based only on a name. If the minimum required fields contain enough data for state and federal queries, then the system shall initiate queries to local, state and federal databases. Shall return all responses from local, state, and federal databases to the data entry originator. 18 Shall bring positive responses (e.g. possible “hits”) that require a review by the originator to the attention of the originator through the use of audible and visual indicators. 6.1.12. In order to support the Involved Vehicle Information function, the CAD system: Shall return all responses from local, state and federal databases to the data entry originator. Shall bring positive responses (e.g. “hits”) that require a review by the originator to the attention of the originator through the use of audible and visual indicators. Shall be capable of collecting the following information about each vehicle associated with an event: o License plate o License plate state o License plate type o License plate year of expiration o Primary vehicle color o Vehicle Identification Number (VIN) o Vehicle make o Vehicle model o Vehicle year o Secondary vehicle color o Remarks o Shall initiate an automatic query to local, state and federal databases, upon entry of information about a vehicle associated with an event, using the following guidelines at a minimum: o License plate number and license plate state o VIN and vehicle make Shall initiate a cascaded query, upon receipt of a response from the DMV containing the name of the registered owner of the vehicle, to local, state and federal databases, to check the wanted status, driver’s license status, and other statuses of interest about the registered owner. 6.1.13. In order to support the Premises Hazards and Previous History function, the CAD system: Shall have the capability to retrieve information about a premises and the surrounding/adjacent area as an automatic function during the creation of a CFS. Shall have the capability to retrieve information about a premises and the surrounding/adjacent area as an ad‐hoc query. Shall display historical incident information based on a configurable date range pre‐set by the systems administrator, and according to local SOP. Shall display historical incident information based on a configurable geo‐area range pre‐ set by the systems administrator, and according to local SOP. Shall display historical incident information based on a configurable date range pre‐set AND geo‐area range pre‐set by the systems administrator, and according to local SOP. Shall be capable of storing information of interest to responders including, but not limited to: o Hazardous materials stored at the location o Firearms kept at the location 19 o Information specific to individuals at the location, including, but not limited to: o Warrants on file o Serious medical information o Impairments o Potential dangers to first responders o Information specific to the address, including, but not limited to: o Entry codes o Knox Box information Shall have additional fields available that are user definable. Shall enable all required data for direct input, to be uploaded, or to be loaded via a live interface from RMS(s). Shall be capable of integrating with a third‐party syndromic alerting/tracking application. 6.1.14. In order to support the CAD Event Creation function, the CAD system: Shall support the creation of a CFS event with a bare minimum amount of information to trigger the dispatch of resources when the matter is urgent. This includes the location of the event and the event type. It must be possible to update CFS event as additional information is gathered from the reporting party. Shall support the creation of new CFS events—in communications centers where separate call takers and radio dispatchers are employed—by either call takers or dispatchers depending on the source of the event information. Should auto‐create a CAD event for the Automated Secure Alarm Protocol (ASAP) standard if applicable. Shall spawn a copy of the CFS event—in agencies where multiple agencies and/or services are dispatched, or when an interface to another CAD system exists—for the additional agencies with a unique incident/event number for each; however, all copies of the CFS event Shall be linked to each other so CAD users can ascertain that they are a single CAD event. 6.1.15. In order to support the Determining Response Agency and Service Area function, the CAD system: Shall store all service agency and response area assignments in CFS events and the system’s audit log file. Shall validate the location of new a CAD event against the system’s geofile to verify the location is within the service area handled by the PSAP. Shall identify the new CAD event’s location and nature code, and use the system’s geofile to identify the appropriate service agencies that need to handle the event. Shall identify the appropriate service agencies to handle a CAD event, and use the system’s geofile to determine the appropriate response area(s) within each agency’s service area. Shall provide a method for CAD users to manually enter/assign the appropriate service agencies and response areas to CAD events if the CAD event’s location cannot be validated against the system’s geofile or if the validation process results in the assignment of an improper service agency or response area. Shall use the service agency and response to notify the appropriate dispatchers that they must process a CAD event. 20 6.1.16. In order to support the Alarm Processing function, the CAD system: Shall adhere to the APCO/CSAA 2.101.1‐2008 External Alarm Interface Exchange American National Standard. Shall receive alarm notifications and updates related to the alarm notification from alarm monitoring companies. Shall utilize the alarm notification data to create a CFS event without call taker involvement if the address is valid and minimum required fields have been provided. Shall spawn a copy of the CFS event to other agencies, if applicable. Shall process updates from the alarm company as an update to the CFS and shown to the telecommunicator responsible for dispatch operations with an audible and visual indication that a new update has been received. Shall send an automatic update message to the alarm company during the progression of the event—when the primary agency has been dispatched, when the primary agency has arrived on scene, and when the CFS has been closed, including any disposition information reported by the primary agency that responded. 6.1.17. In order to support the CAD Event Routing function, the CAD system: Shall examine the location, event type and response plans (when dedicated dispatch positions are in operation) to route the CFS event to one or more dispatch positions as the CFS event entry is being performed by a call taker. Should display the dispatch position’s pending event queue in priority order and in chronological order once the CFS event has been routed by the CAD system. 6.1.18. In order to support the Run Cards / Response Plans function, the CAD system: Shall allow for dynamic and fixed/static response plans. Shall allow for unlimited alarm levels. Shall allow for the use of primary and secondary capabilities. Shall allow for assignment to be by resource type, capability and equipment (e.g. thermal imager). Shall allow for the use of personnel capabilities (e.g. personnel with Spanish speaking ability). Shall allow for the use of resource groups made up of individual units [e.g. a Hazmat (hazardous material) group made up of several units and dispatched as a single “Hazmat team” (i.e. single unit)]. Shall allow for the use of premises‐based or address‐based response plans. Shall allow for the use of AVL systems for selecting units. Shall support multiple agency response plans. Shall allow for unit assignment based on time or distance to the incident. Shall allow for adjustable plans that are based on time of day or day of week. 6.1.19. In order to support the Adjustable Dispatch Levels function, the CAD system: Shall allow for adjustable dispatch levels. Shall allow for an unlimited number of dispatch levels. Shall allow for a user‐defined naming convention for the dispatch levels. 21 Shall enable adjustable dispatch levels to be individually activated (e.g. a fire response plan would change to Level 2 and an ALS response would change to a Level 3, or all plans could change to a defined level). Shall have an easily viewable method to review current dispatch levels. Shall alert the dispatcher when the required number or type of units are not dispatched (e.g. one police unit to a domestic call instead of two, or two fire engines to a commercial fire instead of four). 6.1.20. In order to support the Additional Attributes function, the CAD system: Shall provide a means to assign multiple attributes to units. Shall provide a means to assign multiple attributes to personnel. Shall provide a means to search for units or personnel attributes on the fly. Shall provide a means to assign resources to multiple units (i.e. shared crews). 6.1.21. In order to support the Mutual Aid function, the CAD system: Shall recognize the resources and capabilities of the host agency’s own units and those of neighboring agencies. Shall allow for custom mutual aid agreements, including business rules for utilization, and recognize various levels of response/mutual aid. Shall recommend the use of other agency resources based on parameters within the mutual aid agreements. Should auto‐populate incident information (e.g. address information, nature of incident, resources needed) from other CAD systems via a CAD‐to‐CAD type interface. Should support the Joint NENA/APCO Emergency Incident Data Document (EIDD) or similar CAD‐to‐CAD functionality for sharing incident information as required for mutual aid agreements. 6.1.22. In order to support the Automatic Aid function, the CAD system: Shall provide of the host agency’s own units and neighboring agency resources/units. Should provide via the capability to track the status (availability) via CAD‐to‐CAD type interface (i.e. overall view of unit resources). Shall recognize the resources and capabilities of the host agency’s own units and those of neighboring agencies. Shall allow for custom automatic aid agreements, including business rules for utilization. Shall recognize various levels of response/automatic aid. Shall recommend the use of other agency resources based on parameters within the automatic aid agreements. Should auto‐populate incident information (e.g. address information, nature of incident, resources needed) from other CAD systems via a CAD‐to‐CAD type interface. Should support the Joint NENA/APCO EIDD or similar CAD‐to‐CAD functionality for sharing resource and incident information as required for automatic aid agreements. 6.1.23. In order to support the Emergency Medical Dispatch / Incident Triage function, the CAD system: Shall include (or allow for the installation of) an EMD or incident triage program. The CAD system or EMD or incident triage program: 22 Shall allow for customization based on the needs of the agency (e.g. medical direction, operations). Shall guide or prompt the call taker through defined forms based on the information provided by the caller. Shall assist the call taker in identifying the: Type of incident (i.e. law enforcement, fire, EMS, multi‐agency) Resources needed [e.g. law enforcement, ALS/BLS, engine(s), extrication] Level of response (e.g. Alpha, Bravo, Charlie, Delta or priority) Shall provide the capability to allow a unit to be dispatched to the incident as soon as the address is confirmed and the nature of the incident is determined. Shall prompt the call taker to provide pre‐arrival instructions to the caller or responding unit(s). Shall recommend a change, based on the information obtained and entered into the program, in: Response priority (e.g. upgrade or downgrade to emergent, non‐emergent) Resources required (i.e. law enforcement, fire, EMS) 6.1.24. In order to support the Channel Designations function, the CAD system: Should have a table of radio channels/talk groups. Should allow each radio channel or talk group to be used for tactical purposes to be flagged as such in the CAD system. Should include a flag indicating a requirement for the automatic assignment of a tac channel that can be set for each incident type in the CAD system. Should assign a tactical radio channel available to units upon the dispatch to an incident requiring the automatic assignment of a tac channel. Shall allow the dispatcher to manually flag or assign one or more tactical radio channels or talk groups to an incident. 6.1.25. In order to support the Be on the Look‐Out / Attempt to Locate function, the CAD system: Should support creation and distribution of any BOLO entered into the system. Should provide a BOLO structure to include all necessary information such as the nature of the BOLO, priority, date, range of effectiveness, subject and/or vehicle information, hazard information, and contact information. Should allow narrative fields for additional information. Should provide the means for BOLO information to be easily searchable, printable, and have the ability to automatically populate on an incident sheet referencing any particular name, address, or vehicle information. Should flag the field (automatically) with configurable visual and audible alerts. Should support a workflow record for initial BOLO creation and any additional edits. 6.1.26. In order to support the Dispatch Units function, the CAD system: Shall assign an incident number to each agency responding to the incident. Should assign, for an EMS response, a patient care report (PCR) number to each patient at the incident. Shall capture every time stamp associated with each unit’s response and status change related to the incident. 23 Shall capture all status changes and their times for statistical and research purposes (e.g. out of service versus in service to calculate “lost unit hours”). 6.1.27. In order to support the Resource Alerting function, the CAD system: Shall alert via MDC. Shall generate (automatically) information appropriate for use with “rip and run” printers and/or alphanumeric pager devices when units are dispatched or on demand by a dispatcher. Shall generate (automatically) information appropriate for use with email and/or SMS sent to a mobile device when units are dispatched or on demand by a dispatcher. Should interface with tone encoder systems. Should interface with fire station, law enforcement, and EMS status and alerting systems. Should support “rip and run” printing via IP network using protocols, such as Internet Printing Protocol (IPP), Line Printer Daemon (LPD), and Hewlett‐Packard Printer Job Language (PJL), and via facsimile transmission based on operational requirements. Shall support alphanumeric paging via TAP, WCTP, SMTP, and SNPP. Shall support sending SMS messages either directly via cellular modem or using a common carrier’s SMTP interface. 6.1.28. In order to support the Move Up function, the CAD system: Should recognize resource gaps that will likely result in response performance under prescribed standards. Should recommend or automatically dispatch units to move up to address those identified gaps. Should initiate move ups based on user defined manual or automated logic processes. 6.1.29. In order to support the Staffed vs. Unstaffed Units function, the CAD system: Shall provide the ability to dynamically document that a unit is staffed or unstaffed before or after it is assigned to an incident. 6.1.30. In order to support the Cross‐Staffing function, the CAD system: Shall account for the number of qualified personnel available in a station, and determine the best possible resource allocation from that station at any given moment. Shall utilize any combination of dedicated or contingent staffing to most appropriately utilize resources. Shall account for the qualifications of personnel—such as fire apparatus driver/operator, EMS certification, and rescue certification—to establish the best possible resource allocation based on prioritized needs for the response. Shall take, based on a single shared crew assigned to multiple pieces of apparatus, the remaining piece(s) of apparatus out of service, when one piece of apparatus is assigned to an event. 6.1.31. In order to support the Additional Unit Status function, the CAD system: Should include the various statuses needed for unit readiness or during patient care. Shall add parameters to the incident that relate to the response priority (i.e. lights and siren or non‐emergency mode). Shall show if a unit is BLS or ALS. 24 Shall allow for multiple transports by the same unit on the same incident (e.g. a mass casualty incident). 6.1.32. In order to support the Rostering function, the CAD system: Should provide the capability to create rosters (i.e. assign personnel to a vehicle or position to facilitate on/off duty transactions). Should allow the dispatcher to adjust the rosters and/or assignments (i.e. on‐the‐fly, during shifts, and above normal complements). Should warn the dispatcher if a resource complement is below minimum. Should contain a 2‐way, real‐time interface to auto populate roster information in CAD. 6.1.33. In order to support the Mileage Tracking function, the CAD system: Shall capture beginning and ending mileage for individual transports. Shall provide a visual and audible error indication to the user upon failure to enter beginning or ending mileage based on transport or response type. Shall provide a method of integration with an AVL system for increased accuracy and efficiency. Shall use GIS/mapping to supplement driving directions based on shortest route beginning and ending address locations, with regard to environmental factors such as time of day, weather conditions, train schedules, and road/bridge blockages. Shall include the use of intuitive interfaces that facilitate mandatory entry based on given incident types or processes. Shall provide an interface to billing and reporting components. Shall provide the ability for an authorized user to manually override an entry by a dispatcher or supervisor. Shall record the overridden information in an audit log. 6.1.34. In order to support the Hydrant Location and Status function, the CAD system: Shall track fire hydrants, including: location, service status, recent test date, flow rate, and main size. Shall display hydrant locations and related info on the map. Shall indicate (automatically) the closest hydrants to fire calls for service. Shall record, and display, with hydrant information, alternative water sources (e.g. ponds, creeks). 6.1.35. In order to support the Exception Reason Tracking function, the CAD system: Should identify and require an exception in any case when user defined response time standards are not met. Should establish a system administrator‐defined list of exception reasons established for each CAD time interval. 6.1.36. In order to support the Geo‐fencing function and Response Boxes, the CAD system: Shall provide geo‐fence creation tools that allow the use of polygons, circles, ellipses, and rectangles. Shall display details about a resource to aid in identification, location and purpose. Shall facilitate the creation of multiple, coexisting, overlapping geo‐fences. Shall support unique geo‐fence names and each geo‐fence shall be visually distinct. 25 Shall generate an alert whenever a vehicle or resource enters and/or exits a geo‐fence. Shall include alerts that consist of: Unique visual and audible identification Resource identification Geo‐fence Identification Current resource position Timestamps of entry and exit of geo‐fence areas Ability to clear alerts and history from view while maintaining historic records as needed Shall include standard GIS functions, such as exportation of parcel Information, data fields, and historic records from geo‐fence in agency based required formats. Shall be able to alert personnel though technologies such as text messaging or email. Shall provide the ability to create, manage and record geo‐fence areas to track the entry and/or exit of GIS based resources. Shall provide informative and manageable alerts to appropriate personnel through visual and audible representation. 6.1.37. In order to support the Station Dispatch function, the CAD system: Shall provide the capability to dispatch a fire and/or EMS station to an incident regardless of the number of units or personnel that station has assigned to it or on duty. 6.1.38. In order to support the Vehicle/Unit Change function, the CAD system: Shall account for the number of personnel currently staffed on the unit. Shall allow system supervisors and other authorized users the ability to modify vehicle and resource capabilities, as required, without adversely impacting the system (i.e. without having to shut the system down). Shall allow easy modifications to unit crew capabilities to accommodate frequent changes throughout the day. Shall track units having multiple units with multiple capabilities, and attributes Shall be reflected as multiple types (e.g. a Quint, pumper, or ladder). Shall recommend resources based on the appropriate type (e.g. a “Quint” type fire apparatus may be recommended as either a pumper or a ladder truck). Shall allow the dynamic entry of personnel staffing specific units/apparatus. Shall allow the staffing module to be accessed from the field by authorized users to dynamically reflect changing assignments. Shall allow for tracking vehicle ID in addition to unit radio call sign (e.g. a given vehicle may be referred to as “Unit 1” one day and a different vehicle the next day. 6.1.39. In order to support the Automatic Driving Directions / Routing function, the CAD system: Shall present the destination address visually for validation and acceptance. Shall provide a route that considers current impedances (e.g. road closures, road construction, accidents, disable vehicles) Shall provide a route that considers speed limits, traffic lights, stop signs, and other traffic control variables, and vehicle weight limits. Shall provide a visual map that presents the entire route. Shall provide a visual map that centers the unit and presents a configurable radius around the unit (i.e. feet, miles, meters), and provides turn‐by‐turn navigation. 26 Shall provide consistent route re‐evaluation, and visually present alternate routes based on estimated drive time without interfering with current route. Shall provide a directions list from unit current location to destination. Shall present visual and audible warnings about travel impedances. Shall allow authorized field units to create and clear impedances, which may be used for directing other units. Shall account for one‐way roads, bridge weight restrictions, highway overpasses, and other considerations that impact safety. Shall store suggested route and route taken for future evaluation. Shall provide configurable forms that allow resizing, on‐off, and night/day modes. Shall provide configurable audible alerts and voices that can be enabled and disabled. Shall provide a manual entry interface for non‐CAD driven use. Shall prevent audible alerts from interfering from other system notifications that may impact unit safety. 6.1.40. In order to support the Bypassed Units function, the CAD system: Should alert (automatically) the dispatcher in the case of a unit becoming available that is closer to a CFS in which the currently assigned unit is still in route and farther away. 6.1.41. In order to support the Post‐Dispatch Response Re‐evaluation function, the CAD system: Should notify the dispatcher when a response reevaluation is appropriate based on AVL data (i.e. units that should be considered for a CFS and units that could be cancelled if those under consideration are assigned to the event). 6.1.42. In order to support the Display of Incident / Event Data function, the CAD system: Shall display CFS event data on the CAD monitor after being selected by the dispatcher. All CFS event data shall be accessible to the dispatcher. Shall enable Windows tabs to be used to allow the dispatcher to select supplemental history about the incident (e.g. premises history, past event history, hazards, and persons of interest) Shall display (automatically) updates to the CFS event for the dispatcher. Shall provide updated information that is easily discernible from the previously read data (e.g. newest information on the top, different font/color text). Shall present an audible and/or visual indication to the dispatcher when a CFS event is updated by another source such as a call taker, another dispatcher, or a field unit. Shall provide, upon receipt of an update, a method of ease, such as an ‘Update’ button, for the dispatcher to retrieve the CFS event that has been updated. Shall remove CFS events as they are closed by the dispatcher from the CFS event display, without additional interaction from the dispatcher. 6.1.43. In order to support the Update Incident Status function, the CAD system: Shall provide the capability to record supplemental information updates in the CFS event as it is received from callers, field resources and other sources. Should retain a copy of any information updated prior to the update for audit purposes. Shall provide a method to update the actual incident type versus the reported incident type. 27 6.1.44. In order to support the Dispatch Resource Decision function, the CAD system: Shall recommend resources, when the resource requirement is changed, based upon agency defined procedures, workload balancing, unit capability, and proximity of the resources. 6.1.45. In order to support the Update Assigned Resources function, the CAD system: Shall detect when a reduction in dispatched resources is required. Shall recommend readjusted resources that meet the requirements of the incident. Shall record the modifications to the CFS event when changed by the dispatcher. Shall record any changes to assigned resources as an update to the CFS event. Shall provide the capability to recommend additional resources based on response plans and/or local policies. 6.1.46. In order to support the Update Supplemental Resources Tracking function, the CAD system: Shall allow the ability to divide the response area into multiple zones, based on user‐ defined criteria, to ensure a quick response to the request. Shall make recommendations for resources to prevent any one entity from being favored. Shall allow cancellation of or by‐passing the recommendation, returning the skipped company to be placed back in the rotation either at the bottom or top of the rotation, depending on the circumstances. Shall provide the ability to skip a suggested resource, capturing the reason for the exception and placing the resource either back at the top of the queue or at the bottom, based on the reasoning. Shall provide the ability to create and maintain rotating and non‐rotating service provider information (i.e. towing companies). 6.1.47. In order to support the Assign Units function, the CAD system: Should allow the assignment of units by using drag‐and‐drop and point‐and‐click pull‐ down menus. Shall re‐queue the CFS that has had all units removed, but has not been handled. Shall recommend a unit that is unavailable only if SOP permits units to be pre‐empted for a higher priority event. Shall provide the ability to assign one or more units to an incident with a single command. Shall provide the ability to dynamically, and without user intervention, change the unit recommendation if relevant incident information changes (i.e. type, location, alarm level). Shall provide the ability to notify users that the unit recommendation has changed. Shall provide the ability to cancel a unit from an assignment: If the cancelled unit is the only unit assigned, then the CFS will be returned to the pending event queue. Shall provide the ability to assign or add multiple units to a CFS event with a single command. Shall provide the ability to assign a single unit to multiple CFS events. Shall provide the ability to hold a CFS event for a specific unit. Shall allow the dispatcher to override the system recommended units and assign other units. 28 Shall allow the dispatcher to assign any valid field unit to an incident even if that unit is not currently logged on to the system. Shall notify the dispatcher and confirm that the correct unit has been assigned if a unit assigned to an incident is not logged on the system. 6.1.48. In order to support the Update Incident Data function, the CAD system: Shall log the following information for all entries into the CFS event: date, time, user ID (or note if action was system generated), position (terminal) ID, action performed, and any notes associated with action. Shall display additional CFS event information to the dispatcher for action. Shall allow, at any time, additional incident information to be added to the CFS event, both prior to and after closing the incident. Shall allow the user to display the added comments in reverse chronological order. Shall provide the user the option of specifying the CFS event to update by entering the call sign of any assigned unit or by entering the incident number. Shall permit multiple users, including MDC‐equipped field resources, the ability to simultaneously update information to the CFS event. Should provide controls when two or more CAD users attempt to update the same field in the CFS event For example, in the event that User A is saving modifications to a field, and that field has been modified by another user since User A retrieved the CFS event, the application should notify User A that the field that is being modified has been changed since User A retrieved the record and confirm that User A wants to continue with the update. Shall provide the ability for one or more CAD users to simultaneously add incident information to an active or closed CFS event. Shall provide the ability to add supplemental information to closed incidents based on assigned user rights. Shall notify the entering party that the incident being updated has been closed. This will allow the entering party to reopen the incident for re‐queuing to dispatch if necessary. Shall provide the ability to update the CFS event by specifying the incident/event number or the call sign of assigned units. 6.1.49. In order to support the Assign Records Management System Incident / Case Number function, the CAD system: Shall facilitate an interface to an RMS to allow the transfer and tracking of incident data. Shall provide the ability to transfer the incident data to the RMS at a set time (incident closure) or at dispatcher discretion based upon the field unit’s needs. Shall coordinate the assignment of RMS incident/case numbers through a jointly used, shared list by the RMS and CAD system or through a list maintained in the CAD system. Shall provide the ability for the dispatcher to retrieve the RMS incident number at any point during the event or after the incident has been closed. 6.1.50. In order to support the Transfer Basic Incident Data to the Records Management System function, the CAD system: Shall provide the ability to automatically transfer CAD system CFS event data relating to an incident to an RMS for use by the agency. 29 Shall provide the ability to transfer data prior to the normal chronological transfer point to provide the public safety responders with an RMS incident number when needed, and if this method is required to retrieve an RMS incident number. 6.1.51. In order to support the Display Additional Incident Data function, the CAD system: Shall notify the appropriate CAD users via visual and/or audible indication when information is added or changed to a CFS event. Shall provide a separate notification for each entry made. Shall provide the ability to visually differentiate text notes in the CFS event added by different operators for the same incident (i.e. color and/or CAD user identification). Shall display additional CFS event data with the newest information displayed first. Shall display additional CFS event data with the newest information displayed in differently formatted text (e.g. color, font, formatting, such as bold, italics). Shall provide the ability to view all additional CFS event data at one time. Shall provide the ability to automatically notify users monitoring or displaying the CFS event that information has changed. Shall provide the ability to dynamically, and without user intervention, display changes to a CFS event as they occur based on assigned user rights. 6.1.52. In order to support the Reopen Incident function, the CAD system: Shall ensure all changes to the CFS event are time/date stamped. Shall notify the CAD user attempting to add information to a closed CFS event that the event is closed. Shall provide the ability to add comments to a CFS event without reopening the original CFS event. Shall provide the ability to reopen a CFS event by incident number, location, or unit ID. Shall provide the ability to reopen closed CFS events and assign units. Shall provide the ability to open a closed CFS event as a new CFS using information from the old CFS event, but with new time stamps. 6.1.53. In order to support the Add Destination Locations function, the CAD system: Shall have the ability to accurately track the destination of all units assigned to a particular incident within the CFS event, and to allow these locations and activities to change throughout the incident. 6.1.54. In order to support the Patient Tracking function, the CAD system: Should have the ability to track EMS patients from the scene to their destination or disposition. This should include the ability to capture patient identifying information. Shall meet Federal HIPAA (Health Information Portability and Accountability Act) requirements for data security where appropriate. 6.1.55. In order to support the Linking an Audio File to a CAD Event function, the CAD system: Should provide the ability to record multiple types of incoming media types and associate them with the CAD CFS event record for easy retrieval. Should provide the ability to add additional types of data to this association as they are developed. 30 Should provide the ability to associate a CAD incident with audio logging/recording. Should allow the user to open a window to support streaming multimedia feeds (i.e. video and audio). Should allow users to start, stop, pause, and rewind the multimedia feed. Should allow for adequate start/stop capabilities. 11 Standard is in development by the OASIS Emergency Management Tracking of Emergency Patients Subcommittee. Visit http://www.oasis‐open.org/committees/tc_home.php?wg_abbrev=emergency‐tep for more information. 12 See above. If the multimedia feed is stopped or paused for less than 30 seconds and then restarted, then the multimedia feed Should start where the stop or pause occurred. Stopping or pausing the data stream for up to 30 seconds Should not cause the loss of the data. There Should be at least a 30‐second cache of the multimedia data stream. Should allow multimedia data to be recorded into CFS event history; or, otherwise allow the recording of streaming media to a separate data repository with appropriate information that would allow the users to easily match multimedia files with specific incidents. Should allow authorized users to start/stop the recording process by the use of graphic command buttons or function keys. Should support the resizing of the multimedia window and the auto‐resizing of the video display portion of the window. Should interface with a separate audio recording device to include linking a CFS to the appropriate recording(s). 6.1.56. In order to support the Multiple Simultaneous Incidents to Single Unit function, the CAD system: Shall allow a dispatcher to hold or stack events to a busy unit, as well as units that are in‐ service. If a unit is on an assignment, when the unit clears its assignment, then the system shall notify the dispatcher the unit is available. Shall provide the agency a method to define what events can be held. Shall notify the unit that it is being held when an event is placed on hold. Shall allow several events to be placed on hold for a single unit. Shall allow a CFS event to be held for a unit that is not yet logged on. Shall record in the history of the CFS event when an event is placed on hold. Shall apply timers to all held CFS events and alert the dispatcher when a held event has exceeded the allowable time in a held status. Shall provide dispatchers with the ability to pre‐empt a unit and dispatch the unit to another event. If all units are removed from the original event, then it Shall be placed in the pending CFS events monitor. Shall NOT limit the ability of the dispatcher to assign another unit to the incident or for field units to self‐dispatch (assign) themselves to an event that has been placed on hold, if permitted by agency policy. 31 6.1.57. In order to support the Scheduled Events function, the CAD system: Shall provide the ability to automatically schedule the CFS event for future dispatch. Shall allow scheduled events to be created by entering a CFS or by sending a message. Shall be capable of displaying a list of all scheduled events. Shall provide the ability for authorized users to activate a scheduled event at any time. Shall send a message to the appropriate users when the scheduled activity occurs. Shall support location override for scheduled incidents. In order to support the Secondary Incident Location function, the CAD system: Shall provide the ability to note responding apparatus has arrived “in staging,” which may be a remote secondary address associated with the primary incident location. Shall provide the ability to change a unit’s location from the primary address to a secondary address without clearing the unit from the incident or CAD record. Shall log a date/time stamped record of the change in the CFS event. 6.1.58. In order to support the Single Discipline Incident to a Combined Discipline Incident function, the CAD system: Shall provide the ability to add another agency’s resources to a CFS event. Shall provide the ability to assign an agency specific incident/event number to the CFS event. Shall provide the ability to link added agency records with the initial CFS event. Shall provide the ability to share incident information across multiple linked records. Shall provide the ability to track the added resources for the duration of the incident. 6.1.59. In order to support the Timers function, the CAD system: Shall have, and allow configuration of, multiple timers based on unit status and CAD incident type, such as time on a particular call, time since last check‐in, and time at the hospital or jail. Shall have, and allow configuration of, timers for CAD system events, such as a priority 1 call overdue to be dispatched. Shall allow for operators to manually place a timer alert on a CFS or a unit. Shall minimally include “down to the second” timestamps (e.g. hhhh/mm/ss). Shall allow configurable timers (i.e. ‘hh:mm:ss’, ‘mm:ss’, or ‘ss’). 6.1.60. In order to support the User Defined Status Timers function, the CAD system: Shall be equipped with predefined timers that can be configured by the system administrator. Shall provide the ability for the system administrator to create customized definable timers. Shall record timer activity to the CFS event log. Shall produce both visual and audible alerts to the dispatcher when a timer is triggered. 6.1.61. In order to support the Request Supplemental Resource function, the CAD system: Shall be able to store, and easily retrieve, a file for standardized and ad hoc supplemental resources that may be recalled and requested as needed for services not available from the public safety agencies. 32 Shall make request and “dispatch” of said resources on the basis of the unique type of service needed, the geographic proximity to the site of the needed service, or a rotation of the unique service providers of a given type—or, a combination of methods. Shall be able to create a unique or supplemental unit designation in real time. Shall be able to record the activities of unique or supplemental units in the same manner in which agency response units are tracked and their activities recorded. Shall allow for agency‐configurable non‐agency units to be recommended, such as the closest towing company recommendation when a unit is dispatched to an accident event type. The recommendation will take into account the rotation of towing companies. 6.1.62. In order to support the Request Supplemental Resource Rotation List function, the CAD system: Shall store, and provide for easy retrieval, a list of authorized providers of unique or supplemental supplies or services. Shall provide multiple sources of contact for each authorized vendor. Shall be able to display the list of authorized service providers based upon geographical proximity to the site of need, by rotation, or by agency preference based upon contractual agreement. Shall record the transactions that occur with supplemental or unique resources. In order to support the Enter and Update Supplemental Service Record function, the CAD system: Shall provide the ability to create a record of the supplemental service request. Shall accommodate selection from the provided list either at random, by geographic proximity to the site of need, or by rotation. Shall trigger the next provider in the rotation, when selected by rotation and upon creation of the record Shall process the rotation regardless of the requested resource’s ability to respond. 6.1.63. In order to support the Determine Incident / Event Status function, the CAD system: Shall provide the ability to change the event status as the situation evolves or a resolution is achieved. The MDC interface: Shall allow the field user to enter one or more event dispositions. Shall allow the field user to update the CFS event in CAD and make that data available to the RMS. 6.1.64. In order to support the Utilize Incident Management function, the CAD system: Shall have the ability to dynamically update the CFS event with notations, updates, status changes, and notifications. Shall make the updated CFS data available for transfer to an RMS. 6.1.65. In order to support the Determine Report Functionality function, the CAD system: Shall provide the ability to automatically transfer incident/event data relevant to external RMS or reporting systems. Shall be able to determine, based upon incident type and/or disposition, whether an agency report is required. Shall accommodate either a push or pull of incident/event data from/to the RMS. 33 6.1.66. In order to support the Record Disposition function, the CAD system: Shall provide for the CFS event to contain the disposition of the incident. Shall provide for narrative to be added giving detail to the disposition. 6.1.67. In order to support the Send Data to Records Management System function, the CAD system: Shall provide the ability to exchange all CFS event information with an RMS. 6.1.68. In order to support the Assign Agency‐Specific Report Numbers function, the CAD system: Shall assign an agency‐specific report (i.e. case) number—if a report is required, and if required by agency policy—in addition to the CAD incident/event number, before the CFS event data is transferred to the RMS. Shall allow for both the CAD CFS Event Number and the Agency Report Numbers to be fully configurable (e.g. “1 to n,” “mmddyyxxxx,” “mmddyyhhmmssxxx,” “FY12xxxxxx,” “2012‐ mmdd‐xxxxx”). 6.1.69. In order to support the Geofile Maintenance function, the CAD system: shall assign (automatically) geographic boundaries (e.g. agency of jurisdiction, law enforcement zones/beats, fire box/response zones, sectors, neighborhoods, communities, precincts) to a CFS incident location. Shall validate all locations entered into or processed by the CAD system against the CAD system’s geofile. Shall provide an interactive, GUI‐based address matching tool for assisting users to determine the location of incidents that do not have an exact geofile match for their initially‐ entered location. Shall be capable of determining X, Y coordinate values that represent the location of incidents whose locations have been validated. Shall be capable of displaying coordinates anywhere on the map with mouse over. Shall support coordinate‐based operations including X, Y, Lat/Lon, and USNG. Shall make possible integration of the CAD system’s geofile with Global Positioning Satellite (GPS), AVL, and Automatic Person Location (APL) systems. Shall support X, Y coordinate‐based geographic searches for such things as nearby hazardous materials, duplicate incidents, and premises information at or near an incident’s location. Shall be capable of importing geographic boundary information (e.g. station boundaries, jurisdictional boundaries, reporting districts, response zones, neighborhoods, precincts) from GIS and other geographic data sources. Shall be capable of importing topologically‐structured street networks and other linear features (e.g. rivers, streams, utility right of ways, bus routes) from GIS and other geographic data sources. Shall be capable of importing point data (e.g. landmarks, parcel address points, business locations, retail store address points, fire hydrants) from GIS and other geographic data sources. 34 Shall be capable of importing other types of geographic data (e.g. park boundaries, rectified aerial photography, trailer parks, apartment complexes) from GIS and other geographic data sources. Shall include location databases such as hazards, general premises information, street closures, and other user‐definable GIS type data. Shall support parcel‐level GIS information and use this information for address/location validation. Shall support multiple layers of information; for example, the storage of building footprints, aerial photographs and other images (i.e. pictures of specific buildings) that are associated with specific areas and addresses. Shall maintain the CAD system’s geofile while the system is live and operational. Shall support boundary assignments (i.e. determining the response zone and jurisdiction for each incident) in real time by processing the incident’s X,Y coordinates against the RCL and/or address point file, and the appropriate boundary files. Shall support duplicate incident checks based upon the location of the incident. All incidents located within the CAD system’s duplicate incident search radius Shall be checked as potential duplicates. Shall should meet i3 standards and functions in order to comply with NG9‐1‐1 requirements. Shall include interactive tools for validating the accuracy and completeness of the geofile. Shall be able to support different search distance criteria for different types of incident situations and hazards (e.g. a search radius of 300 feet will be used for hazardous conditions, and a search radius of 1,320 feet will be used to identify potentially duplicate incidents). CAD system administrators shall be able to modify these search distance parameters. CAD users shall have the ability to select the unit of measurement necessary (feet versus meters). Shall generate an audible and/or visual alert when any potential duplicate incidents are identified. Shall include the capability for manually editing and entering any geographic data required by, or imported into, the system’s GIS (given the appropriate user permissions). 6.1.70. In order to support the Security function, the CAD system: Shall employ data security measures that are compliant with applicable state and federal security standards. Shall employ data encryption that meets CJIS security policy standards for any exchange or transmittal of CAD data between remote devices and CAD system servers. Shall provide appropriate safeguards to ensure that only authorized devices and users are allowed access to the CAD system and stored information. Shall provide a security profile to control individual user access to the various modules, applications, functions, features, and data available within the CAD system. Shall provide security to ensure that fire and EMS personnel do not have access to law incidents when CJIS data is restricted to only law enforcement user access. Shall meet CJIS Security Policy requirements. Shall validate each user’s credentials through a mandatory logon process before being granted access to any functions or data available within the CAD system. 35 Shall enable a user replacing an existing user to quickly log off the existing user and logon without the need to exit from CAD or re‐start the CAD application (i.e. when two‐factor authentication does not apply.) Shall enable system administrators to create and maintain a centralized and indexed database containing information about each system user, including their unique user ID, password, contact information, and security profile. Shall enable system administrators to define individual user access privileges and assign them to security groups. Shall provide a method for authorized users to reset a user’s password. Shall associate the user ID and workstation ID with all CAD system transactions, including data entry and report generation. Shall limit access to the centralized user security database to only specifically authorized users. Shall establish security profiles that are assigned to individual users or user groups based on personnel classifications (e.g. call taker, dispatcher, system administrator, supervisor). Shall prohibit deletion of any data entered into a CFS event. Shall provide application and module level security that enables certain users to access specific CAD system functions and application modules, while keeping other users from accessing these same functions and modules. Shall provide data entry form security that enables certain users to access specific data entry forms, while keeping other users from accessing these same data entry forms. Shall provide record type security that enables certain users to access specific CAD system record types, while keeping other users from accessing these same record types. Shall provide transaction level security that enables certain users to access specific transaction types (e.g. criminal history queries to NCIC), while keeping other users from accessing these same transaction types. Shall provide data field level security that enables certain users to access specific CAD data fields, while keeping other users from accessing these same data fields. Shall facilitate the use of unique user IDs and passwords to control CAD system access and privileges. Shall provide a “single entry” to enable logons to multiple authorized systems that are available through the system (e.g. NCIC, NLETS, and VCIN). Shall limit access to system functions and data by physical device (e.g. PCs, terminals), as well as by user ID. Shall have the capability to automatically log‐off CAD workstations based on inactivity periods set by the system administrator for specific user groups, users and workstations. Shall provide the ability to “lock out” a user after a system administrator defined number of failed attempted logons. Shall require users to change their individual password after a system administrator configurable time limit for use of the same password expires or a set time period (e.g. 90 days). Shall provide the ability for individual system users to change their passwords. Shall provide the capability for individual user name change (e.g. getting married) and shall keep a link to historical data. 6.1.71. In order to support the Logging function, the CAD system: 36 Shall include a transaction audit database that contains all system transactions and that includes the logon identification (i.e. user ID and workstation ID), date and time stamp, transaction type, contents before ID, and contents after the transaction completes. Shall enable system administrators to turn the transaction audit log function on and off by application module, transaction type, specific data entry form(s), specific tables and data fields within tables, individual users, user groups, and various combinations of these factors. Shall enable authorized system users to search the transaction audit database by date and time ranges, by application module, transaction type, specific tables and data fields within tables, specific data entry forms, individual users, user groups, workstation ID, and by various combinations of these factors. Shall enable authorized system users to create formatted reports and/or export the results of transaction audit database queries and searches. Shall enable authorized system users to generate statistical reports on transactions contained in the transaction audit database for all users, a subset of users and/or user groups, for a specified date and time range, and for various combinations of these factors. Shall prohibit any changes to the contents of the CAD transaction audit database. The CAD system’s CAD transaction audit database: Shall store all transactions completed on open/active incidents, including the transaction’s date and time stamp, the user and workstation ID performing the transaction, and the before and after results of the transaction. Shall store all system messages, including the message’s date and time stamp, the user and workstation ID sending and receiving the message, and the message contents. Shall store transaction information associated with all CAD configuration parameters and files, including any time a user views, prints, edits, ads, or deletes the configuration parameters and/or CAD system configuration file records. Shall should capture the messages and associated information (e.g. date and time stamp, user ID, workstations ID) of user and system generated queries to interfaced system and databases (e.g. NCIC, NLETS, and VCIN). Shall should capture the date, time and user ID associated with previous incident history access. Shall should capture transaction information associated with all CAD security transactions, including any time a CAD user views, prints, edits, ads, or deletes the security information within the CAD system. Shall store transaction information associated with all CAD system modifications completed by system administrators, including administrator user ID, date/time of modification, modification made, and table value prior to the completed modification. Shall store the date, time, workstation ID, and user ID associated with unsuccessful sign‐ on attempts. 6.1.72. In order to support the Configuration function, the CAD system: Shall enable authorized system administrators to configure the CAD system to meet the requirements of the agencies using the system by creating and modifying CAD configuration parameters. Shall enable authorized system administrators to modify CAD configuration parameters without the requirement for programmer or other support from the manufacturer of the CAD system. 37 CAD configuration parameters: Shall include functionality for table driven and directly modifiable functionality by authorized system administrators. Shall include functionality for interactive, menu‐driven, GUI‐based tool that allows authorized administrators to easily update and modify parameters. Shall include functionality for on‐line help that lists all of the available options for a configuration parameter, and a description of the impacts resulting from changing the parameter to each of its available options. Shall include functionality for modifications to CAD configuration parameters when the CAD system is active without having to shut the entire CAD system down or restart it. Shall include functionality for modifying agency and user specific workflows, such as when and under what circumstances a CFS event is automatically routed from a call taker to a dispatcher and which users (e.g. call takers, dispatchers, and supervisors) receive system routed CFS events. Shall include functionality for specifying the agencies that will be included in the CAD system, along with their attributes (i.e. fire department, volunteers, law enforcement agency). Shall include functionality for specifying and modifying the type of resources available in the system. Shall include functionality for specifying the incident types that will be processed by the system. Shall include functionality for entering and modifying dispatch policies that specify the type of resources that are dispatched to specific incident types. Shall include functionality for configuring different system dispatch policies for each incident type, priority and agency using the system. Shall include functionality for specifying the type of alerts and timers available in the system and their specific attributes (e.g. on/off, time interval, triggers, display features). Shall include functionality for entering and modifying the type of dispositions, priorities, and other CFS event related parameters of the CAD system. Shall include functionality for specifying the starting point and formats of case numbers created by the CAD system for each agency using the system. Shall include functionality for specifying the sort order, layout, color, font, and other appearance and operational attributes of the CAD system’s windows and menus. Shall include functionality for modifying the look and feel of CAD workstations. Shall include functionality for modifying the look and feel of the tactical map display available in the system (e.g. setting up the graphic information appearing at different zoom levels, predefined zoom levels for different incident types, icons). Shall include functionality for modifying the display and functional characteristics of CAD system queues (e.g. pending incident queue, incident queue, active incident queue, stacked incidents queue). Shall include functionality for modifying the display and functional characteristics of the CAD system’s resource recommendations. Shall include functionality for modifying the display and functional characteristics of interfaced systems and gateways (e.g. 9‐1‐1 call interfaces, paging and other responder alerting interfaces, NCIC and other criminal database interfaces, mobile computer system). 38 6.1.73. In order to support the Table Maintenance function, the CAD system: Shall include CAD tables that are maintained using entry windows. Shall include CAD table maintenance entry windows that have context‐sensitive, field‐ level help. Shall enable changes made to CAD tables to become immediately effective and shall not affect overall CAD system availability nor require any CAD system down time. Shall allow agencies to define additional data elements based on their operational requirements. Shall provide the ability for tables to be defined to support the maintenance of the following CAD objects, including, but not limited to: o Agencies o BOLOs, including location, person, and vehicle o Clearance/disposition codes o Hazards o Hydrants o Incident/event types o Fire Stations o Memos o Messages (e.g. canned, scheduled) o Notifications o Personnel o Rosters o Run cards/response plans o Service types (i.e. law enforcement, fire, EMS) o Skills (personnel) o SOPs o Units o Unit attributes (e.g. ALS, BLS, Hurst tool) o Unit statuses (i.e. dispatched, en route, arrived, cleared) o Unit Types (e.g. i.e. patrol car, motorcycle, engine, ladder, pumper) o Vehicles 6.1.74. In order to support the Communication Center / PSAP Relocation function, the CAD system: Shall meet PSAP industry best practices and CJIS requirements. Shall account for replacement or the movement of any necessary existing equipment including base computers, terminals, network, and personnel. Shall account for a data‐backup plan. Shall account for coordination of external inputs to the CAD system from third‐party vendors (e.g. telephone, data, 9‐1‐1) for a minimal loss of functionality. Shall provide for access to a copy of the production system through the backup or disaster recovery environments. 6.1.75. In order to support the CAD Catch‐Up function, the CAD system: Shall have the ability to manually open and create a CFS event sheet. Shall provide the ability to log the entering individual’s information and time of entry. 39 Shall provide the ability for all information to be entered without any restrictions, and times/dates changed to reflect the actual time that notice of the CFS event was received. Shall denote the manually‐entered CFS event so there is a record that the CFS event was not entered when it was actually received. Shall provide ability to manually designate the “starting” incident number (i.e. the last incident +1 for the starting number once the system is restarted). Shall allow for simultaneous automatic and manual entry without degradation. Shall include all the information in back entered records that a live incident/event sheet should require. 6.1.76. In order to support the Notifications function, the CAD system: Shall enable the system administrator to define the rules for automatic CFS event notifications. Shall provide the ability to create messages that are retained in the system and sent at pre‐specified times. Shall provide the ability to maintain a log of all messages processed by the system. Shall allow the user to send and store messages to other users, groups, positions, or mobile devices. Shall allow a message to be sent to multiple recipients and/or groups. Shall log all sent messages. Should provide the ability to create and maintain automatic reminders of scheduled activities (e.g. radio tests): Daily Weekly Monthly Annually User‐defined (e.g. 30 minutes, 15 minutes, first day of the month) Multiple activities or reminders per time slot 6.1.77. In order to support the Contact List function, the CAD system: Shall allow a message to be sent to multiple recipients and/or groups. Shall be able to log all sent messages. Shall provide an emergency contacts list, to include: Contact name Street address o City State Zip Telephone numbers Relationship User‐defined/configurable fields 6.1.78. In order to support the Premises Information / Hazards function, the CAD system: Shall provide the ability to enter a premises location by address, cross street or latitude/longitude. Shall provide the ability to capture, maintain or interface to specific premises information types for operators: 40 Hazardous materials Hazardous conditions Lock codes Dangerous animals Handicap Emergency contact information Unit safety Warrants Alarms Protective Orders, Sexual Offenders Fire Pre‐plans Other user‐defined premises fields/information Electronic attachments (e.g. images, files) Shall provide the ability to automatically create (i.e. upon closing of an incident) premises history based on pre‐determined criteria. Shall provide the ability to define valid date ranges for time‐limited premises information at a given location (i.e. information valid between start date and end date), and to notify supervisor of pending expiration dates. Shall provide the ability for supervisors to delete premises information for a given address or location based on expiration date and/or time of record, with prompted review prior to deletion (i.e. minimum of five years, on‐line storage). Shall provide the ability to define criteria for automatic premises information purges and activate or deactivate this feature. Shall provide the ability to verify that premises warning or hazard information has not been affected by changes to the geofile. Shall provide the ability to view premises information for a specific suite/apartment/unit, or to view all premises information for an entire building. Shall provide the ability to automatically embed premises information into the event history at the time the event is created. Shall create a permanent record of the premises information in the event history. Shall provide (or interface to) a “cautions” file to contain information pertaining to dangerous individuals possibly residing at that location or near proximity, and exceptional persons at the location, such as an emotionally disturbed person. This shall include a caution type category and free form narrative. The caution type shall be searchable. 6.1.79. In order to support the Communications Center / Public Safety Answering Point Standard Operating Procedures function, the CAD system: Shall provide the ability to store and easily retrieve SOPs for the PSAP. Shall provide a SOP tool to prompt the user to ask for additional information, perform certain tasks, or relay critical information to responding units or other responders. Shall provide a method where the retrieval of relevant SOPs are accessible from the CFS event information window and associated with the location, incident type, unit, or special skilled personnel responding. 6.1.80. In order to support the Agency‐Specific Incident / Location / Unit Standard Operating Procedures function, the CAD system: 41 Shall be able to store SOPs that are associated with incident types, properties and/or units. Shall make these SOPs available for viewing and/or transmitting when an associated incident type is encountered, the response is to a specific location with unique response/operational requirements, and/or specialized units are assigned to the incident. Shall include (optional) more sophisticated functionality (e.g. alert and check off of tasks, notifications made, or other issues capable of being tracked). 6.1.81. In order to support the Remote Access function, the CAD system: Shall support remote access by users outside of the communications center. Shall provide access that includes permission‐based views of CAD data by certain workstations and/or individuals. Shall provide remote access that includes security‐controlled, web‐based access. Shall be capable of remote access from a separate location, such as a mobile command post or a secondary location. 6.1.82. In order to support the CAD Workstation‐to‐CAD Workstation Messaging function, the CAD system: Shall provide short messaging from one CAD workstation to another. Shall include the ability to create message groups, whether they are dispatch workstations, mobile computers, groups within the PSAP, or other communications devices. Shall enable the system administrator to disable this function if desired on an agency basis. Shall log all messages. Shall provide the ability to create user definable “canned” messages for selection and distribution to other system users. 6.1.83. In order to support the Command Line / GUI function, the CAD system: Shall include the ability to be operated via a command line entry, mouse and keyboard, or both. 6.1.84. In order to support the Date / Time Stamps Function, the CAD system: Shall stamp date/time and log CAD activities, such as status changes, task accomplishments (i.e. Fire Attack Initiated, Time Fire Declared Under Control, Time at Patient), and notifications, as well as many other system transactions and the time they occur. Shall save original time stamps even if they are overridden. Shall protect time stamp overrides; and, any changes Shall be documented on the incident, including the ID of the person performing the modification and the reason for the modification. Shall maintain all time stamps to be minimally accurate to the second (e.g. hh:mm:ss). 6.1.85. In order to support the Unit Status Transitions Matrix function, the CAD system: Shall prohibit unit status transitions that do not conform to the business rules of the agency. 42 6.1.86. In order to support the Single Sign‐on for CAD and CAD Sub‐systems function, the CAD system: Shall be designed to provide a single sign‐on for CAD and its integrated sub‐systems. 6.1.87. In order to support the Dispatch Supervisor Support function, the CAD system: Shall provide the ability for a CAD supervisor, or another dispatcher with appropriate system permissions, to observe the activity of a given dispatcher including the pending events queue, active events, available units list, and map. Shall enable a supervisor, or another dispatcher with appropriate system permissions, to co‐dispatch the units under the control of another dispatcher. Shall have the ability to add additional dispatchers “on‐the‐fly” for one or more services (law enforcement, fire service, and/or EMS), either globally or for predetermined geographical areas. 6.1.88. In order to support the CAD Management Reporting function, the CAD system: Shall include standard reports that simultaneously use date, time, location, and/or incident type search parameters for report definitions. Shall include the capability of customizing standard reports and for creating user‐ defined reports. Shall provide access to all reports to the user, subject to permissions, from within the CAD system. Shall include reports in the CAD security/permissions function (i.e. individual reports can be made available/unavailable based on a user’s security profile). Shall provide all reports to users, subject to permissions, regardless of the application used to create user‐defined or custom reports (i.e. internal to the CAD system or via a third‐ party reporting or analysis tool). Shall provide an ad hoc reporting capability. Shall provide a data exporting capability. 6.1.89. In order to support the Training and Testing function, the CAD system: Shall include a training environment that accurately mirrors the live environment, including all tables and administrative configurations, and allows for call takers and dispatchers to train on specific services (i.e. law enforcement, fire service, and/or EMS) and on pre‐ configured geographic areas identical to that of the live environment. The CAD system’s training environment: Shall be clearly identifiable as the training environment (e.g. “TRAINING” prominently displayed on the screen). Shall have a separate E9‐1‐1 test connection or canned script E9‐1‐1 information and provide realistic training regarding incoming E9‐1‐1 data. Shall be able to be used, operated, started up, shut down, and updated to match the live application without affecting the live environment. Shall be able to be used to test modifications and updates to the live CAD application prior to implementing the modifications and updates in the live environment. Shall have a separate E9‐1‐1 test connection or canned script E9‐1‐1 information (i.e. wireline, cellular, no record found, and VoIP) and Shall provide realistic training regarding incoming E9‐1‐1 data. The provider(s): 43 Shall provide initial and ongoing maintenance costs for the CAD training environment (and separate test environment) in the proposed system cost section. In order to support the Snapshot / Incident Replay function, the CAD system: Should include functionality to provide a detailed, system‐wide snapshot report and/or graphic display of the system status to include all units and events, based on a user‐ specified date, and time and an incident replay, based on a user‐specified date and time, specific incidents, or other CAD events. 6.1.90. In order to support E9‐1‐1 Interfaces, the CAD system: Shall enable incoming E9‐1‐1 ANI/ALI data to be automatically mapped to corresponding address and phone data fields based on the Master Street Address Guide (MSAG) standard in the CFS event entry form. Shall support all E9‐1‐1 ANI/ALI formats including wireline, WPH1 and WPH2, VoIP, and Multi‐Line Telephone Systems (MLTS). Shall enable the capture of additional fields captured in the CFS event, including ESN, call type (landline, wireless), and ANI/ALI tracking ID (if available). Shall use GIS data, if available, to extrapolate the closest geographical attribute (address, intersection, common place). The radius used to extrapolate the closest geographical attribute shall be a configurable item within the system. If GIS data is used to create the caller location, then the offset used to determine the approximate location shall be displayed. 6.1.91. In order to support External Database Interfaces, the CAD system: Shall provide configurable query forms and response displays and be able to be custom‐ built to accommodate different federal, state and local database protocols. Shall provide authorization to perform various queries, and the ability to read responses definable by the individual agency and by role to the field level. Shall allow users to submit queries either with the query form or the command line (if applicable). Shall allow users to automatically submit queries for persons and vehicles as part of other data entry processes, such as CFS event creation. Shall enable the query request type and the database(s) to be queried to be specified from a predefined list, with automatic narrowing of pertinent databases based on user data input. Shall provide intelligent updating of the query forms based on other CAD forms that contain person or vehicle data. Shall provide a capability for entering new information into the selected external database(s) provided the external database(s) allow updating. Shall provide a method for multiple queries to be submitted through a single form or command. This is sometimes referred to as query spawning or cascading. Shall make query responses accessible either through the query response form or from the command line and shall be associated with a query response type. Shall allow users to submit new queries based on data in the query response to logical links; and, Shall also reference attachments that are associated with the response, which can be downloaded and viewed. Ideally, CAD will provide the capability to view common industry‐standard multimedia file‐types. 44 Shall provide the capability to alert dispatchers, PSAP supervisors, and street‐level supervisors of “Hot Hit” responses to queries made by officers in the field, or data run that exists elsewhere in the CAD system (i.e. in a CFS event). Shall provide optional audible and visual alerts that can be configured by the system administrator. Shall log all queries and their responses (when permitted) for audit purposes. Shall provide the ability to configure alerts for queries run by unauthorized personnel or devices, as well as the ability to monitor multiple queries of the same data or specified data. 6.1.92. In order to support the Messaging Subsystem Interfaces, the CAD system: Shall be capable of TCP/IP communication, using industry‐standard messaging protocols such as SMS and SMTP. Shall provide the capability of pre‐formatted messages, especially to paging and other handheld devices. Shall create (automatically) an alphanumeric page for selected CAD incidents. Shall allow a dispatcher to initiate an alphanumeric page for any paging group. The information sent in the page shall be configurable by the agency and shall generally contain the incident number, type of incident, and location of the incident. Shall provide an administrative mechanism to define paging groups. Shall include multiple message types, including email, BOLOs, notifications, tactical command chat rooms, and others. Shall provide a capability to format and send messages using just‐in‐time information, such as incident dispatch information, BOLOs or emergency weather alerts, and configurable triggers for these messages (e.g. incident type, assigned resources or location) for configurable recipients (i.e. send the chief a page when a specific incident type occurs at a specified location). 6.1.93. In order to support a one‐way CAD‐to‐RMS interface, the CAD system: Shall provide CAD incident and resource information to the RMS for use in reporting and case management. Shall be a data push triggered by definable incident elements, such as incident status, incident disposition or manual submission by a dispatcher and/or call taker. 6.1.94. In order to support Additional Interfaces, the CAD system: Shall provide access to MDC functions authorized to the field level within each function by system administrations down to the role level (i.e. a patrol officer may not have access to some functions that a street sergeant may have). Shall be capable (depending on agency policy) of providing silent dispatch orders to a mobile unit, in addition to providing the unit with details of the CFS event, pre‐plan information, patient information, premises history information, and other types of relevant information. Shall enable the mobile unit to, if authorized, self‐initiate incidents, self‐dispatch incidents from a queue, change its status, query CAD and RMS information, and query local and national databases, such as wanted‐person checks. Many MDCs, especially those not integrated as part of a CAD system, will require a message switch to enable the transmission of data and access to external databases. 45 Shall be able to have summary incident and resource monitoring capability. Shall provide the ability for street supervisors in multi‐agency, multi‐jurisdictional environments to choose what agencies or areas within individual agencies they wish to monitor. Shall provide the ability for CAD users to drill down into the details of summary incident and resource data, and have the ability to configure what data is displayed, as well as how it is displayed in terms of layout, font, font size, and colors. Shall provide a day/night mode for mobile users. Shall provide an integrated mobile mapping client. Shall provide incident and resource management and monitoring capabilities through the in‐car mapping solution. Shall provide the ability to view real‐time AVL data for user‐selected units from the mobile client, and the ability to interact with the units identified on the map display. This capability shall include messaging and other unit‐related functionality. Shall provide drive directions from the current location to a dispatched incident (or any selected location). Shall provide mobile search capability for resources and personnel by type of vehicle, status and location. Shall enable mobile users to search for incidents and locations. Should all interface to [insert specific application/product here] Automated License Plate Reader (ALPR) software. 6.1.95. In order to support Locational Systems Interfaces, the CAD system: Shall interface with existing ESRI ArcGIS files. Shall have a seamlessly integrated computerized map, which is a digitized map (ESRI ArcGIS database) supporting Tactical Map Display (TMD). Shall contain a map‐centric TMD, in which the GIS/map is fully integrated with the CAD system. In the case of a separate TMD application linked to the CAD system, the TMD shall support the automatic display of units as derived from an AVL system. Shall integrate with aerial imaging technologies to provide digital, oblique, aerial imaging. Shall link high‐resolution aerial photos to mapping systems; overlay shape files directly on top of both oblique and/orthogonal images; and, display vector data. Shall enable users to obtain measurements such as distance, height, elevation, and area directly from the 3D imagery, as well as insert GIS content and other data. Shall include geographic data to support, at a minimum, the following: System and boundaries registered to the street centerline in the geofile Boundary assignments (i.e. determining the response zone for each incident) completed in real time by processing the incident’s X,Y coordinates against the RCL and boundary files to determine the incident’s location and response zone Parcel‐level GIS information, in which the approximate location of the front door of all the parcels in the state are stored in the geofile Address validation and to determine an incident’s location Bulk data uploading Weekly data updates Metadata 46 FGDC standard format feed, like XML (eXtensible Markup Language) and KML (Keyhole Markup Language). 6.1.96. In order to support the geofile system, the CAD system: Should provide geo‐fencing, and add the capability to establish law enforcement on‐the‐ fly response zones, fire response areas, ambulance (EMS) response areas, street networks, and other geographical layers using typical mapping/GIS tools. Shall support valid MSAG names and multiple “aliases” for street names, intersections, commonplace names, landmarks, and street or highway route numbers. Shall stem geographically sensitive hazards, dispatch policies, and other system functions from validated locations. Shall initiate a location verification step to add the coordinates of the incident location to the event and display an incident icon on the TMD as the CFS event is created. Shall make a duplicate event check based upon the location and/or coordinates of the event, during the CFS event creation process. Shall notify the event entry position via a prompt and show a list of the potential duplicate(s) if, during event creation, a potential duplicate event in the area is found. Shall have a parameter (modifiable by the system administrator) specifying the distance in number of feet or other unit of measurement, from the location of the incident for duplicate checking. Shall define location databases such as hazards, general premises information, street closures, and other user definable databases. Shall perform a distance search to identify the existence of location information (e.g. hazards) during the event creation process. Shall support different search distance criteria for different types of locations. Shall support coordinate‐based operations; shall be capable of full integration with a GPS‐ based AVL system; and, shall be capable of accepting named standards driven GPS reporting devices, such as GPS‐enabled smartphones and portable radios. Shall allow the system administrator to be able to modify parameters. In order to support the AVL system, the CAD system: Shall seamlessly integrate with the CAD system and provide detailed, accurate, real‐ time vehicle tracking. Shall include the AVL ID (represented as an alias) for each unit user’s status. Shall include the indication that AVL is enabled for each unit on the user’s status window. AVL can also be used for reporting, messaging, response and alerting functionalities. Shall include a visual indication if units displaying on the map and in the queues are AVL equipped. The visual indication if units displaying on the map and in the queues are AVL equipped Shall be customizable by the system administrator. Shall be able to play back a unit’s AVL travel history and see the unit icon move from location to location on a map window. Shall be capable of integrating with the existing ESRI ArcGIS database. Shall have other interactive functionalities also available, such as the ability to create and view unlimited groups of vehicles. Shall provide for an automated alert function. Shall provide for an automated alert for when vehicle is out of service. Shall provide the ability to determine and modify all such alerts. 47 Shall provide the following information on any unit suffering loss of GPS signal (e.g. vehicle stopped, vehicle shut off, loss of network signal, loss of GPS data): Last known position Time of signal loss Time lapse since signal loss Shall provide minimal AVL reports that include: Complete activity detail for specific date range Vehicle last stop/end time for date range Exception reports including all events that triggered an alert Vehicle first start/begin time for date range Miles per day, stops per day, average and summaries per vehicle Shall pass unit status information to the AVL system whenever unit status is changed. Shall pass any changes in unit location information to the AVL system if unit location changes are generated within the proposed system (as opposed to the AVL navigation system). Shall display AVL updates on the map within two seconds of their receipt from the AVL controller. Shall should be able to dispatch the nearest appropriate unit based on its AVL location using an appropriate routing engine to make that determination. 6.1.97. In order to support the map and GIS analysis systems, the CAD system: Shall support either directly or, through an easily invoked (i.e. seamless) third‐party mapping tool, the creation of thematic maps; for example, a map showing the relative crime rate in each law enforcement district/zone in a given county. Shall support either directly or, through an easily invoked (i.e. seamless) third‐party mapping tool, the creation of automatic pin maps; for example, the system shall produce a map showing the location of all auto thefts that occurred in a given county during the last two months. Shall support either directly or, through an easily invoked (i.e. seamless) third‐party mapping tool, the creation of spatial data aggregation; for example, generate crime rates by district statistics by aggregating individual crimes occurring in each district of the County. Shall support either directly or, through an easily invoked (i.e. seamless) third‐party mapping tool, the creation of trend analysis/forecasting. Shall access other RMS informational files to accommodate the needs and requirements of the crime analysis function and display this information using “pin mapping” techniques. 6.1.98. In order to support map integration and functionality, the CAD system: Shall validate all incident locations, whether obtained from an E9‐1‐1 controller or entered directly by the call taker for administrative line (ten‐digit) calls, against the CAD system’s geofile to provide, at a minimum, cross streets, response areas, map page and coordinate, legal street names, and zip code. Shall allow for the manual processing of the incident location, in the event a location cannot be properly validated against the geofile, so that a CFS event can be created if the location has been confirmed or known to exist within the local jurisdiction. 48 Shall produce (automatically) a report of all incident entries that did not validate on a scheduled basis. Shall save original E9‐1‐1 ANI/ALI information as part of the CFS event if the user changes the original information (e.g. the incident is not at the caller’s location). Shall allow for processing of non‐validated locations and notify the dispatcher of the special address. Shall identify the appropriate agency (i.e. law enforcement, fire and/or EMS), district, sector, reporting area, agency of jurisdiction, and any other geographic boundaries containing an address, once it has been validated. Shall display the two nearest cross‐streets. Shall perform location validations/geofile lookups independent of the CFS event creation process. 6.1.99. In order to support Administration Interfaces, the CAD system: Shall have the ability to import and display the radio ID (and optionally the officer ID) information to the dispatcher by those keying mobile and/or portable radios. Shall have the ability to interface and synchronize all servers and CAD workstations with the master time clock. This ensures each workstation and server provides an accurate time stamp. Should provide the ability for the agency to schedule personnel, including communications center personnel and officers. This application is sometimes found in the agency’s RMS. 6.1.100. In order to support Communications Interfaces, the CAD system: Shall accept, depending on agency policy, non‐dispatchable incidents across the Internet. Incidents accepted across the Internet will be of a general nature, in which a case (report) number may be needed for insurance purposes. The case number is generated and recorded. The incident is recorded in the incidents/events history database for statistical reporting. Shall page or text (automatically) a message to pre‐defined recipients or groups of recipients based on the event type. Shall provide the capability for a CAD operator (PSAP personnel or CAD users) to page, email, or text a message to pre‐defined recipients or groups of recipients. Shall support SMS texting (text to 911) in the context as TDD. Shall be compatible with 911 Next Generation systems. 6.1.101. In order to support the Integration / Interfaces with Other Systems function, the CAD system: Shall allow the agency direct access to the underlying system information stored in the database (ODBC, FTP, web services) for future interface configuration, as well as appropriate database and system documentation to support this access. Shall provide a capability to flag a CAD call for submission as a Suspicious Activity and submit that call to the agency’s intelligence/counterterrorism unit or designated Fusion Center. This interface must conform to the standards set forth by the NSI and contained in the Functional Standard (FS) Suspicious Activity Reporting (SAR) Ver. 1.5. Shall interface to [insert specific application/product here] incident command software. Shall interface to ImageTrend Elite Fire and EPCR records management software. 49 Shall interface with alarm monitoring companies using ASAP. This interface must conform to standards contained in the APCO/CSAA ANS 2.101.2‐2014: Alarm Monitoring Company to Public Safety Answering Point (PSAP) Computer‐Aided Dispatch (CAD) External Alarm Interface Exchange. 7. EVALUATIONANDAWARDCRITERIA 7.1. Proposals shall be evaluated by the County of Powhatan based on the following criteria: 1. Ability to Meet RFP Requirements: How the proposed system meets the overall requirements of Powhatan County stated in this RFP. 35% 2. Firm’s Proposed Project Approach: Timing (does the proposal meet 25% the County’s critical milestones), Project Management, Work Plan, Quality & Thoroughness of Proposal. 3. Firm’s Experience, Quality of Service, and References: Quality 20% of experience in providing a CAD System to a locality comparable to Powhatan, and submission of required references) 4. Accessibility and Ability of the Vendor to provide timely service, 10% support and training. 5. Cost Proposal 10% 7.2. AWARD OF CONTRACT: The selection process shall be as per § 2.2‐4301 (3‐b) of the Virginia Public Procurement Act for the procurement of non‐professional services. Selection shall be made of two or more offerors deemed to be fully qualified and best suited among all the offerors on the basis of the evaluation criteria, including price. Negotiations shall then be conducted with each of the offerors so selected. Price shall be considered but need not be the sole determining factor. After negotiations have been conducted with each offeror so selected, Powhatan County shall select the offeror which in their opinion has made the best proposal, and shall award the contract to that offeror. Should Powhatan County determine in writing and in their sole discretion that only one offeror is fully qualified, or that one offeror is clearly more highly qualified than the others under consideration, a contract may be negotiated and awarded to that offeror. 8. TERMSANDCONDITIONS 8.1. GENERAL: Proposals and contracts with the County of Powhatan and its officials, departments, and employees are governed by the Virginia Public Procurement Act, Sections 2.2‐4300 – 2.2‐4343 et seq of the Code of Virginia, as amended, and the ordinances of the County of Powhatan. In the event of an inconsistency or conflict between the Provisions of this solicitation, Contract or 50 other incorporated document, or the County’s Ordinances and Policies and State Procurement Law, any inconsistencies or conflicts shall be resolved by giving precedence to the following documents in the following order: a) b) c) d) e) f) The Virginia Public Procurement Act Ordinances and Policies of the County of Powhatan Specifications of this Request The Contract Provisions of this Request Instructions to Offerors The following general information is provided to all Offerors to facilitate the preparation of suitable proposals for the goods, insurance or services identified in this Request, and the requirements set forth shall be binding upon all Offerors. The County is not at liberty to change the terms of the bargain after the opening of proposals. Where questions and discussions prior to proposal opening disclose a need for additional information or amendments, appropriate addenda to the request will be prepared and distributed so that all Offerors will be proposing based upon the same information and specifications. 8.2. The County may extend the date and time for the opening for proposals if it believes it is necessary or in the best interests of the County. In a situation where the County is closed unexpectedly on a due date, the proposals will be opened at the same time and place the next County business day. The County reserves the right to reject any and all proposals and waive any informality or technical defect if, in its sole judgment, the best interest of the County will be served as specified in Virginia code Section 2.2‐4319. 8.3. APPLICABLE LAWS AND COURTS: This solicitation and any resulting contract shall be governed in all respects by the laws of the Commonwealth of Virginia and any litigation or dispute arising out of the contract resulting from the RFP, its interpretations, or its performance shall be litigated only in the Powhatan County General District Court or the Circuit Court of the County of Powhatan, Virginia. The contractor shall comply with all applicable federal, state and local laws, codes, and regulations. 8.4. ANTI‐DISCRIMINATION: By submitting their proposals, Offerors certify to the Commonwealth that they will conform to the provisions of the Federal Civil Rights Act of 1964, as amended, as well as the Virginia Fair Employment Contracting Act of 1975, as amended, where applicable, the Virginians With Disabilities Act, the Americans With Disabilities Act and § 11‐51 of the Virginia Public Procurement Act. If the award is made to a faith based organization, the organization shall not discriminate against any recipient of goods, services, or disbursements made pursuant to the contract on the basis of the recipients religion, religious belief, refusal to participate in a religious practice, or on the basis of race, age, color, gender, or national origin and shall be subject to the same rules as other organizations that contract with public bodies to account for the use of the funds provided; however, if the faith‐based organization segregates public funds into separate accounts, only the accounts and programs funded with public funds shall be subject to audit by the public body. (Code of Virginia, § 11‐35.1E) 51 In every contract over $10,000 the provisions in 1 and 2 below apply: 1. During the performance of this contract, the contractor agrees as follows: a) The contractor will not discriminate against any employee or applicant for employment because of race, religion, color, sex, national origin, age, disability, or any other basis prohibited by state law relating to discrimination in employment, except if there is a bona fide occupational qualification reasonably necessary to the normal operation of the contractor. The contractor agrees to post in conspicuous places, available to employees and applicants for employment, notices setting forth the provisions of this nondiscrimination clause. b) The contractor, in all solicitations or advertisements for employees placed by or on behalf of the contractor, will state that such contractor is an equal opportunity employer. c) Notices, advertisements and solicitations placed in accordance with federal law, rule or regulation shall be deemed sufficient for the purpose of meeting these requirements. 2. The contractor will include the provisions of 1, above, in every subcontract or purchase order over $10,000, so that the provisions will be binding upon each subcontractor or vendor. 8.5. ETHICS IN PUBLIC CONTRACTING: By submitting their proposals, Offerors certify that their proposals are made without collusion or fraud and that they have not offered or received any kickbacks or inducements from any other Offeror, supplier, manufacturer or subcontractor in connection with their proposal, and that they have not conferred on any public employee having official responsibility for this procurement transaction any payment, loan, subscription, advance, deposit of money, services or anything of more than nominal value, present or promised, unless consideration of substantially equal or greater value was exchanged. 8.6. IMMIGRATION REFORM AND CONTROL ACT OF 1986: By submitting their proposals, Offerors certify that they do not and will not during the performance of this contract employ illegal alien workers or otherwise violate the provisions of the federal Immigration Reform and Control Act of 1986. 8.7. DEBARMENT STATUS: By submitting their proposals, Offerors certify that they are not currently debarred by the Commonwealth of Virginia from submitting bids or proposals on contracts for the type of goods and/or services covered by this solicitation, nor are they an agent of any person or entity that is currently so debarred. 8.8. ANTITRUST: By entering into a contract, the contractor conveys, sells, assigns, and transfers to the County of Powhatan all rights, title and interest in and to all causes of action it may now have or hereafter acquire under the antitrust laws of the United States and the Commonwealth of Virginia, relating to the particular goods or services purchased or acquired by the County under said contract. 8.9. PROPOSAL FORMAT: 52 Proposals shall be submitted in a sealed envelope which clearly identifies the project or solicitation, the name of the Offeror, the due date and time of the proposal, and a statement that the proposal is not to be opened until the due date and time. The Offeror assumes the risk that an envelope not properly marked will be mistakenly opened and thus rendered ineligible for consideration OR the proposal may not reach the Director of Finance prior to the due date and time. Modification of or additions to the General Terms and Conditions of the solicitation may be cause for rejection of the proposal; however, the County reserves the right to decide, on a case by case basis, in its sole discretion, whether to reject such a proposal. 8.10. LATE PROPOSALS AND MODIFICATION OF PROPOSALS: It is the sole responsibility of the Offeror to see that his proposal is in this office by the specified time and date. Proposals received by the Director of Finance after the due date and time will not be accepted and will be returned to the Offeror, if possible, unopened. There will be no exceptions. Date of postmark will not be considered. Telephone, facsimile, electronic and verbal bids will not be accepted. 8.11. CLARIFICATION OF TERMS If any prospective Offeror has questions about the specifications or other solicitation documents, the prospective Offeror should contact the Director of Finance whose name appears on the cover of the solicitation no later than ten (10) days before the due date. Any revisions to the solicitation will be made only by written addendum issued by the Director of Finance. 8.12. AUTHORITY: The County Administrator has the sole responsibility and authority placing, cancelling, or modifying this solicitation and any contract resulting thereof. No other County official or employee may obligate the Government of Powhatan County for indebtedness and any such purchase or contract made that is contrary to the provisions of this solicitation shall be of no affect and void and the County shall not be bound thereby. 8.13. PAYMENT: 1. Unless otherwise provided in the Contract, payment shall be made forty‐five (45) days after receipt of a proper invoice, or forty‐five (45) days after receipt of all goods or acceptance of work, whichever is the latter. 2. Invoices for services ordered and rendered shall be submitted by the Contractor directly to the payment address shown on the purchase order/contract. All invoices shall reference the contract number and/or purchase order number. 3. The date of payment shall be deemed the date of postmark in all cases where payment is made by mail. 4. To Subcontractors: a. A contractor awarded a contract under this solicitation is hereby obligated: (1) To pay the subcontractor(s) within seven (7) days of the contractor’s receipt of payment from the Commonwealth for the proportionate share of the payment received for work performed by the subcontractor(s) under the contract; or (2) To notify the agency and the subcontractor(s), in writing, of the contractor’s 53 intention to withhold payment and the reason. 8.14. 8.15. 8.16. 8.17. b. The contractor is obligated to pay the subcontractor(s) interest at the rate of one percent per month (unless otherwise provided under the terms of the contract) on all amounts owed by the contractor that remain unpaid seven (7) days following receipt of payment from the Commonwealth, except for amounts withheld as stated in (2) above. The date of mailing of any payment by U. S. Mail is deemed to be payment to the addressee. These provisions apply to each sub‐tier contractor performing under the primary contract. A contractor’s obligation to pay an interest charge to a subcontractor may not be construed to be an obligation of the Commonwealth. QUALIFICATIONS OF OFFERORS: The County may make such reasonable investigations as deemed proper and necessary to determine the ability of the Offeror to perform the services/furnish the goods and the Offeror shall furnish to the County all such information and data for this purpose as may be requested. The County reserves the right to inspect offer’s physical facilities prior to award to satisfy questions regarding the Offeror’s capabilities. The County further reserves the right to reject any proposal if the evidence submitted by, or investigations of, such Offeror fails to satisfy the County that such Offeror is properly qualified to carry out the obligations of the contract and to provide the services and/or furnish the goods contemplated therein. AVAILABILITY OF FUNDS: It is understood and agreed to by the parties herein that the County shall be bound hereunder only to the extent of the funds available for the purpose of this agreement. ASSIGNMENT OF CONTRACT: A contract shall not be assignable by the contractor in whole or in part without the written consent of the County. CHANGES TO THE CONTRACT: Changes can be made to the contract in any of the following ways: 1. The parties may agree in writing to modify the scope of the contract. An increase or decrease in the price of the contract resulting from such modification shall be agreed to by the parties as a part of their written agreement to modify the scope of the contract. 2. The County may order changes in the work within the general scope of the work consisting of additions, deletions or other revisions. No claim may be made by the Offeror that the scope of the project or of the Offeror's services has been changed requiring adjustments to the amount of compensation due the Offeror unless such adjustments have been made by formal written Amendment to the Contract signed by the County and the Offeror. If the Offeror believes that any particular work is not within the scope of the project or is a material change or otherwise will call for more compensation to the Offeror, the Offeror must immediately notify the Project Officer in writing of this belief. The Offeror will not be compensated for performing that particular work unless a written amendment has been signed by the County and the Offeror. If the Project Officer determines that the work is within the scope of the Contract as written, the Offeror will be ordered to continue work. 54 8.18. DEFAULT: In case of failure to deliver goods or services in accordance with the contract terms and conditions, the County, after due oral or written notice, may procure them from other sources and hold the contractor responsible for any resulting additional purchase and administrative costs. This remedy shall be in addition to any other remedies, which the County may have. 8.19. INSURANCE: The Offeror shall, at its own expense, provide and maintain during the entire performance period of this contract at least the following kinds and minimum amounts of insurance, in addition to unemployment compensation and workers compensation insurance. By signing and submitting a bid or proposal under this solicitation, the bidder or Offeror certifies that if awarded the contract, it will have the following insurance coverage’s at the time the contract is awarded. INSURANCE COVERAGES AND LIMITS REQUIRED: 1. Worker's Compensation ‐ Statutory requirements and benefits. Coverage is compulsory for employers of three or more employees, to include the employer. Contractors who fail to notify the Commonwealth of increases in the number of employees that change their workers’ compensation requirements under the Code of Virginia during the course of the contract shall be in noncompliance with the contract. 2. Employers Liability for Participants not covered by Workers Compensation Insurance in an amount not less than $100,000. 3. Comprehensive Automobile Liability, including all Owned Automobiles, Non‐Owned Automobiles and Hired Car Coverage: a. Limits: $1,000,000 per incident / $3,000,000 Total Bodily Injury (including death) b. $1,000,000 per incident / $3,000,000 Total Property Damage 4. Employer's Liability for Participants not covered by Worker’s Compensation Insurance in an amount not less than $100,000. 5. Professional Liability Insurance with limits of not less than $1,000,000 per claim and $3,000,000 in the aggregate. If Offeror’s professional liability coverage is on a “claims‐ made” basis. Offeror shall obtain extended reporting (tail) coverage (with the same liability limits) upon expiration of the Agreement for at least three years following the expiration or termination of the Agreement. No change, cancellation, or non‐renewal shall be made in any insurance coverage without a thirty (30) day written notice to the Director of Finance. Failure of the contractor to deliver a new and valid certificate will result in the suspension of all payments required of the County until the new certificate is furnished to the County. Insurance coverage required by this RFP shall be in force throughout the contract term(s). Should the contractor fail to provide acceptable evidence of insurance coverage within five (5) days of written notice at any time during the contract term(s), the County shall have the absolute right to terminate the contract without further obligation to the contractor and the contractor shall be fully liable to the County for the entire cost of procuring the uncompleted portion of the contract at the time of termination. The County shall be named as additional insured on all policies except those pertaining to Worker’s Compensation and Professional Liability. No contract shall be binding upon the County until the certificate of insurance, or policies if so requested, called for herein have been filed with the County and all have been approved as to form and sufficiency by the County Attorney. 55 8.20. DRUG‐FREE WORKPLACE: During the performance of this contract, the contractor agrees to (i) provide a drug‐free workplace for the contractor's employees; (ii) post in conspicuous places, available to employees and applicants for employment, a statement notifying employees that the unlawful manufacture, sale, distribution, dispensation, possession, or use of a controlled substance or marijuana is prohibited in the contractor's workplace and specifying the actions that will be taken against employees for violations of such prohibition; (iii) state in all solicitations or advertisements for employees placed by or on behalf of the contractor that the contractor maintains a drug‐free workplace; and (iv) include the provisions of the foregoing clauses in every subcontract or purchase order of over $10,000, so that the provisions will be binding upon each subcontractor or vendor. 8.21. For the purposes of this section, “drug‐free workplace” means a site for the performance of work done in connection with a specific contract awarded to a contractor in accordance with this chapter, the employees of whom are prohibited from engaging in the unlawful manufacture, sale, distribution, dispensation, possession or use of any controlled substance or marijuana during the performance of the contract. 8.22. NONDISCRIMINATION OF CONTRACTORS: A bidder, Offeror, or contractor shall not be discriminated against in the solicitation or award of this contract because of race, religion, color, sex, national origin, age or disability or against faith‐based organizations. If the award of this contract is made to a faith‐based organization and an individual, who applies for or receives goods, services, or disbursements provided pursuant to this contract objects to the religious character of the faith‐based organization from which the individual receives or would receive the goods, services, or disbursements, the public body shall offer the individual, within a reasonable time after the date of his objection, access to equivalent goods, services, or disbursements from an alternative provider. 8.23. AUTHORIZATION TO CONDUCT BUSINESS IN THE COMMONWEALTH: A contractor organized as a stock or nonstock corporation, limited liability company, business trust, or limited partnership or registered as a registered limited liability partnership shall be authorized to transact business in the Commonwealth as a domestic or foreign business entity if so required by Title 13.1 or Title 50 of the Code of Virginia or as otherwise required by law. Any business entity described above that enters into a contract with a public body pursuant to the Virginia Public Procurement Act shall not allow its existence to lapse or its certificate of authority or registration to transact business in the Commonwealth, if so required under Title 13.1 or Title 50, to be revoked or cancelled at any time during the term of the contract. A public body may void any contract with a business entity if the business entity fails to remain in compliance with the provisions of this section. 8.24. AUDIT: The contractor shall retain all books, records, and other documents relative to this contract for five (5) years after final payment. The County, its authorized agents, and/or state Offerors shall have full access to and the right to examine any of said materials during said period. 8.25. ADVERTISING: In the event a contract is awarded for supplies, equipment, or services resulting from this 56 bid/proposal, no indication of such sales or services to the County will be used in product literature or advertising. The contractor shall not state in any of its advertising or product literature that the County of Powhatan or its products or services unless first agreed to by the County. 8.26. BEST AND FINAL OFFER (BAFO): At the conclusion of negotiations, the Offeror(s) may be asked to submit in writing, a best and final offer (BAFO). After the BAFO is submitted, no further negotiations shall be conducted with the Offeror(s). 8.27. CANCELLATION OF CONTRACT: The County reserves the right to cancel and terminate any resulting contract, in part or in whole, without penalty, upon 30 days written notice to the contractor. Any contract cancellation notice shall not relieve the contractor of the obligation to deliver and/or perform on all outstanding orders issued prior to the effective date of cancellation. Contractor shall credit the County for the applicable decrease in service. The contractor can invoice the County for the actual cost of serviced rendered up until the effective date of cancellation. 8.28. IDENTIFICATION OF PROPOSAL ENVELOPE: The signed proposal should be returned in a separate envelope or package, sealed and identified as follows: From: _____________________________ ___________ Name of Offeror Due Date ___________________ Time _____________________________ ____________________________ Street or Box Number RFP No. _____________________________ _____________________________________ City, State, Zip Code RFP Title Name of Contact/Charla W. Schubert, Director of Finance The envelope should be addressed as directed on Page 1 of the solicitation. The Offeror takes the risk that the envelope, even if marked as described above, may be inadvertently opened and the information compromised which may cause the bid to be disqualified. Bids may be hand delivered to the designated location in the office issuing the solicitation. No other correspondence or other bids should be placed in the envelope. 8.29. OWNERSHIP OF MATERIAL AND DOCUMENTS: Except for Offeror’s work papers, which are and shall remain the property of Offeror, all information, documents, and electronic media furnished by the County to the Offeror belong 57 8.30. 8.31. 8.32. 8.33. to the County, are furnished solely for use in connection with the Offeror’s performance of services required by this Contract, and shall not be used by the Offeror on any other project or in connection with any other person or entity, unless disclosure or use thereof in connection with any matter other than services rendered to the County hereunder is specifically authorized in writing by the County in advance. All documents or electronic media prepared by or on behalf of the Offeror for the County are the sole property of the County, free of any retention rights of the Offeror. The Offeror hereby grants to the County an unconditional right to use, for any purpose whatsoever, documents or electronic media prepared by or on behalf of the Offeror pursuant to this Contract, free of any copyright claims, trade secrets, or other proprietary rights with respect to such documents. PRIME CONTRACTOR RESPONSIBILITIES: The contractor shall be responsible for completely supervising and directing the work under this contract and all subcontractors that he may utilize, using his best skill and attention. Subcontractors who perform work under this contract shall be responsible to the prime contractor. The contractor agrees that he is as fully responsible for the acts and omissions of his subcontractors and of persons employed by them as he is responsible for the acts and omissions of his own employees. SUBCONTRACTS: No portion of the work shall be subcontracted without prior written consent of the County. In the event that the contractor desires to subcontract some part of the work specified herein, the contractor shall furnish the County the names, qualifications and experience of their proposed subcontractors. The contractor shall, however, remain fully liable and responsible for the work to be done by its subcontractor(s) and shall assure compliance with all requirements of the contract. CONFIDENTIALITY (Contractor): The contractor assures that any information and data obtained as to personal facts and circumstances related to County staff or clients will be collected and held confidential, during and following the term of this agreement, and will not be divulged without the individual’s and the County’s written consent. Contractors and their employees working on this project agree to these terms. RENEWAL OF CONTRACT: This contract may be renewed by the County, at its sole discretion, for two (2) successive one year periods under the terms and conditions of the original contract except as stated in items (a) and (b) below. Price increases may be negotiated only at the time of renewal. Written notice of the County’s intention to renew shall be given approximately 90 days prior to the expiration date of each contract year. a. If the County elects to exercise the option to renew the contract for an additional one‐ year period, the contract price(s) for the additional one year shall not exceed the contract price(s) of the original contract increased/decreased by more than the percentage increase/decrease of the Other Services category of the CPI‐W section of the Consumer Price Index of the United States Bureau of Labor Statistics for the latest twelve months for which statistics are available. b. If during any subsequent renewal periods, the County elects to exercise the option to 58 renew the contract, the contract price(s) for the subsequent renewal period shall not exceed the contract price(s) of the previous renewal period increased/decreased by more than the percentage increase/decrease of the Other Services category of the CPI‐ W section of the Consumer Price Index of the United States Bureau of Labor Statistics for the latest twelve months for which statistics are available. 8.34. AUTHORIZED PARTIES: Each proposal, and any contract, must be signed by a person authorized to bind the Offeror to a valid contract with the County. The county may require that any Offeror submit appropriate documentation showing the authority of the signatory to act on the contractors behalf. 8.35. CONTRACT REPRESENTATIVE: In the event a contract is executed as a result of this solicitation, the contractor shall designate in writing his contract representative who shall be responsible for ensuring the services required by the County are complied with and delivered in accordance with the terms and conditions of the contract. 8.36. EVALUATIONS OF PROPOSALS AND AWARD: Proposals shall be evaluated on the basis of those requirements which are set forth in the Request for Proposals, the County’s policies, procedures, and ordinances, and Virginia’s Public Procurement law. This solicitation is being procured by competitive negotiation. Price will not control in the awarding of this procurement. Upon award or announcement of the decision to award a contract as a result of this solicitation, Finance will post the notice of Award or notice of the Intent to Award on the County’s webpage as well as in the state’s eVA system. The County reserves the right to award all or part of the proposal to any Offeror whose proposal is the most responsive and responsible proposal whose proposal meets the requirements and criteria set forth in the RFP with respect to the items in question, and it is in the best interests of the County. The County may award a Contract by individual items, in the aggregate, or in combination thereof, or to reject any or all proposals and to waive any informality in proposals received whenever such rejection or waiver is in the best interest of the County. The Director of Finance also reserves the right to reject the proposal of any Offeror deemed to be non‐ responsible. 8.37. ACCEPTANCE OF PROPOSAL PRICES: Offeror warrants by virtue of proposing that prices, terms, and conditions quoted will be firm for a period of ninety (90) days from the date of proposal opening, unless otherwise stated by the Offeror. There is no binding agreement, no contractual relationship, no understanding or mutual assent until a contract is signed, executed and exchanged by and between the Offeror and the County of Powhatan. 8.38. INDEMNIFICATION: To the fullest extent of the law, the contractor shall indemnify, defend, and hold harmless the County and its officers, agents, employees, community representatives or other working on behalf of the County from any and all claims, judgments, suits, losses, damages, payments, costs, fines or fees levied against the County and expenses of every nature and description, 59 including attorney’s fees, arising out of, connected or associated with or resulting from the lack of performance or the negligent performance of work as described in this contract, contract documents, or any agreements that results from this RFP. Further, if any recipient of a contract subcontracts for work, they shall enter into a contract with any such subcontractor(s) which indemnifies, defends, and holds harmless the County and its officers, agents, employees, community representatives or other working on behalf of the County from any and all claims and losses accruing or resulting from the negligent performance of work as described in any agreement that results from this RFP. 8.39. ACCEPTANCE: Work supply or performance shall be conducted in accordance with recognized and customarily accepted industry practices, and shall be considered complete when the services are approved as acceptable by the Contract Administrator. In the event of any rejection of any deliverable, the contractor shall be notified and have fourteen (14) days from date of issuance to correct the deficiencies and resubmit the deliverable. 8.40. PROTEST OF AWARD OR DECISION TO AWARD a. Any Bidder or Offeror may protest the award or decision to award a Contract by submitting a protest in writing to the Procurement Official, or an official designated by the County, no later than ten (10) days after the award or the announcement of the decision to award, whichever occurs first. Any potential Bidder or Offeror on a Contract negotiated on a sole source or emergency basis who desires to protest the award or decision to award such Contract shall submit such protest in the same manner no later than ten (10) days after posting or publication of the notice of such Contract. However, if the protest of any actual or potential Bidder or Offeror depends in whole or in part upon information contained in public records pertaining to the procurement transaction which are subject to inspection, then the time within which the protest must be submitted shall expire ten days after those records are available for inspection by such Bidder or Offeror or at such later time. No protest shall lie for a claim that the selected Bidder or Offeror is not a responsible Bidder or Offeror. The written protest shall include the basis for the protest and the relief sought. The Procurement Official shall issue a decision in writing within ten (10) days of the receipt of the protest stating the reasons for the action taken. This decision shall be final unless the Bidder or Offeror appeals within ten (10) days of receipt of the written decision by instituting legal action as provided in the Code of Virginia. b. If prior to award it is determined that the decision to award is arbitrary or capricious, then the sole relief shall be a finding to that effect. The Procurement Official shall cancel the proposed award or revise it to comply with the law. If, after an award, it is determined that an award of a Contract was arbitrary or capricious, then the sole relief shall be as hereinafter provided. Where the award has been made but performance has not begun, the performance of the Contract may be declared void by the County. Where the award has been made and performance has begun, the Procurement Official may declare the Contract void upon a finding that this action is in the best interest of the County. Where a Contract is declared void, the performing Contractor shall be compensated for the cost of performance at the rate specified in the Contract up to the time of such declaration. In no event shall the performing Contractor be entitled to lost profits. c. Pending final determination of a protest or appeal, the validity of a Contract awarded 60 and accepted in good faith in accordance with this article shall not be affected by the fact that a protest or appeal has been filed. d. An award need not be delayed for the period allowed a Bidder or Offeror to protest, but in the event of a timely protest, no further action to award the Contract will be taken unless there is a written determination that proceeding without delay is necessary to protect the public interest or unless the bid or offer would expire. 8.41. DISPUTES a. Any dispute concerning a question of fact as a result of a Contract with the County which is not disposed of by agreement shall be decided by the Procurement Official, who shall reduce his decision to writing and mail or otherwise forward a copy thereof to the Contractor within thirty (30) days. The decision of the Procurement Official shall be final and conclusive unless the Contractor appeals within six (6) months of the date of the final written decision by instituting legal action as provided in the Code of Virginia. A Contractor may not institute legal action, prior to receipt of the public body's decision on the claim, unless the public body fails to render such decision within the time specified. b. Contractual claims, whether for money or other relief, shall be submitted in writing no later than sixty (60) days after final payment; however, written notice of the Contractor's intention to file such claim shall have been given at the time of the occurrence or beginning of the work upon which the claim is based. Nothing herein shall preclude a Contract from requiring submission of an invoice for final payment within a certain time after completion and acceptance of the work or acceptance of the goods. Pendency of claims shall not delay payment of amounts agreed due in the final payment. 8.42. REMOTE ACCESS a. All hosts, including privately owned personal computers, connecting remotely to the County's network shall have up‐to‐date and properly configured anti‐virus software and current operating system service pack and patch level. Hosts may be scanned to ensure compliance with County standards, and users may be denied remote access if their host system presents an unacceptable risk to County networks. Access will be monitored and attempts to access unauthorized areas will result in denied remote access. b. Denial of remote access for cause does not relieve the Offeror of any responsibilities under the Contract. If work requires the Offeror to be in Powhatan because remote access has been denied for cause, the Offeror shall bear that cost and shall not be reimbursed by the County. 8.43. SUCCESSORS AND ASSIGNS: The County and the Offeror bind themselves and any successors and assigns to this Contract. The Offeror shall not assign, transfer, convey, sublet, or otherwise dispose of any award, or any or all of its rights, obligations, or interests under this Contract, without the prior written consent of the County. 8.44. IMMIGRATION REFORM AND CONTROL ACT OF 1986: The Offeror certifies that it shall not and will not during the performance of the Contract knowingly employ an unauthorized alien as defined in federal Immigration Reform and Control 61 Act of 1986. 8.45. NON‐WAIVER PROVISION: No waiver or breach of any of the terms, conditions, provisions or covenants contained in this Contract shall be construed as a waiver of any prior or succeeding breach of the same terms, conditions, provisions or covenants. 62
© Copyright 2026 Paperzz