Tab 1.1.4- SOW Final.docx

Statement of Work

WebEOC Software and Support Services

Background The Department of Homeland Security (DHS) mission is to lead the unified national effort to secure America. DHS prevents and deters terrorist attacks and protects against and responds to threats and hazards to the nation. DHS ensures safe and secure borders, welcomes lawful immigrants and visitors, and promotes the free-flow of commerce. In support of its mission objectives, the U.S. Customs and Border Protection (CBP) has a range of operational responsibilities, from providing national Emergency Management planning and response to helping protect public health and safety and those individuals in its custody. To facilitate crisis response, emergency management, medical response and other dynamic and unique workflows, CBP requires a user-friendly highly customizable software solution, which can simplify, integrate and quickly adapt to CBPs dynamic processes while enabling it to collaborate seamlessly with interagency partners as needed. The software must provide a highly customizable commercial off-the-shelf (COTS) design that is compliant and compatible with National Incident Management System (NIMS) guidelines to include those specified for Incident Command System (ICS) purposes, software compliant with numerous Emergency Support Functions (ESFs).

The software and services must provide CBP with a simplified platform for information accessibility, enabling situational awareness, communication, and streamlining CBP response coordination. The solution shall include all the necessary features to support CBPs multi-faceted and dynamic operational mission while adhering to government standards for encryption, privacy, position-based access, audit logging, conformance with CBPs user authentication process.

Required software and services capabilities:

· Able to continue seamless development, operations and maintenance efforts are maintained on all existing WebEOC boards and capabilities with no gap in service to ensure no interruptions in mission critical operations

· Flexible and ad-hoc customization capabilities to create new boards and edit existing boards for data input and viewing, Alerts Notifications, Audit Management and Tracking Logs

· Electronic/digital entry, storage, and query of health information collected by CBP as part of current/ongoing medical support efforts

· Utilizes open API design to provide maximum flexibility and adaptability for seamless integration with most third-party systems.

· Can provide CBP user authentication from any CBP location

· Meets CBP OIT security standards and stores data behind CBP’s firewall

· Meets CBP OIT established performance standards

· Functional with PC or tablet

· Provides the following capabilities: Backup Logs, Backup Scheduling, Checkpoint tracking, Communications Management, Compliance Tracking, Corrective and Preventative Actions, Customer Management, Encryption, Field Reporting, GIS Integration, IT Incident Management, IT Incident Management, Incident Mapping, On Call Scheduling, Process/Workflow Automation,

· Capability to create and share user customized boards with internal and external stakeholders with customized user access permission applied to meet privacy and security standards

· Ability to support the following devices: Android, iPhone, iPad

· Potential for integration with ARCGIS

· Provides standard APIs that provide the right credentials to enable other applications to insert information into WebEOC or extract information out of WebEOC

· Provide COTS design that is compliant and compatible with NIMS guidelines to include those specified for ICS purposes, software compliant with numerous ESFs

· Supports Position/role-based user access permissions

· Supports integration with existing CBP user authentication

· Potential to connect via WebFusion to share data and EOC capabilities securely with FEMA and other federal mission partners with WebEOC instances as required, to reduce duplicate entry, provide a shared Common Operating Picture (COP), and enhance operational effectiveness and efficiencies

· Potential to connect via WebFusion with HHS, TSA and other federal agencies that utilize WebEOC

· Complies with CBP Privacy and Security Standards Existing CBP WebEOC boards which require ongoing development, operations, and maintenance

1) Emergency Management CBP requires the WebEOC software and development services, to include upgrades, plug-ins licensing and technical/development support, to support its multifaceted emergency response and day-to-day operational needs. CBP’s existing WebEOC data platform includes a fully functional emergency notification system API interface on the CBP domain side facing the present incident management system known as Situation Management System (SMS.) SMS is managed and maintained by the Office of Operations Support, the CBP Watch (formerly known as the Information and Incident Coordination Center), the Office of Information and Technology, and the CBP National Data Center. SMS provides lead field coordinators, local incident commanders, continuity personnel, and CBP headquarters leadership with critical, real time information to make sound decisions quickly to prepare, respond, and recover from terrorist attacks, major disasters and other emergencies. CBP requires continued WebEOC software implementation and support of its existing web-enabled crisis information management system.

2) Continuity Boards DHS mandates its Components to incorporate continuity requirements into daily operations. As such the CBP WebEOC system must include customized boards that account for the status of CBP mission essential functions, alternate operating facilities, succession, essential records tracking, continuity planning, and test, training, and exercise forms and templates. The boards are critical for streamlined multi-directional continuity reporting and information sharing. The system must be able to integrate continuity data and provide professional and aesthetically reporting and templates.

3) The Office of Professional Responsibility OPR Investigative Operations Division (IOD) utilizes WebEOC as the primary tracking mechanism and reporting conduit for all field reporting, to include reporting on Critical Incidents. Many critical incidents are dynamic and require multiple updates to records to keep IOD HQ abreast of situations in the field. WebEOC provides a platform for IOD to accurately track and maintain these records for the variety of requests we receive from CBP leadership, DHS leadership, and official congressional inquiries. OPR intends to further develop integration of the Use of Force Incidents (UFIT) reporting and the ability to develop a mobile application for field agents.

4) COVID Tracking and Reporting CBP will continue to leverage WebEOC to conduct daily operations in the field and at Headquarters providing leadership with real-time visibility. CBP will continue to leverage the use of WebEOC to help manage the COVID-19 CBP EOC level as well as to connect with other EOC’s in the field for this purpose.

5) Emergency Medical Records System

a. The CBP Office of Chief Medical Officer (CMO) utilizes WebEOC boards to track, manage and share medical information as appropriate to ensure continuity of care with downstream mission partners. CBP requires the contractor to continue building out its medical workflow tracking system that contains the flexibility needed to support system integrations, internal process flows, and organizational wide process flows. This solution allows CBP to maintain organizational and intra-agency continuity in managing current and the potential for new organizational processes. The EMR will enable users to input patient intake data by creating single event records that will include the medical health interview, medical assessment, medical encounter, and patient travel clearance documents. The system will allow for follow-up and monitoring actions required for patients who need regular monitoring and administration of medication/treatments.

5.1) EMR System Requirements CBP requires the ability to continue to edit and refine its current WebEOC Electronic Medical Records (EMR) boards. This includes the need to add functionality that will support the tracking and monitoring of follow up medical actions. The CBP EMR system supports Medical Quality Management goals, timely patient (to include: U.S. Citizens, Detainees, or other members of the public) follow-up care, record storage, and inter/intra-agency collaboration with downstream partners. The EMR will address requirements of both the USBP as well as OFO. Board services shall continue to be rapidly implemented leveraging existing CBP WebEOC boards and infrastructure which is already located behind the CBP and DHS firewall and comply with DHS/CBP privacy and security standards.

Standardized data sets will be used, where possible or as determined by the government point of contact, to help maintain data integrity. Comment text fields will be utilized where determined by the government point of contact as being appropriate to ensure detailed medical data and input is captured where needed. Unique patient identifiers shall be defined based upon Alien number (A#) if available or an algorithmic combination of other fields (such as record ID, Event number, gender, birthdate, etc.)

The medical data screens will be organized around patient profiles. These profiles group all patient interactions and incident boards to associate them with the individual being assessed/treated. This association is made through the creation of unique patient identifiers.

6.0 SCOPE OF WORK

The Contractor shall provide the following:

1.1 Provide a commercial-off-the-shelf (COTS) software product that is compatible with CBP’s existing incident event crisis management system (SMS).

1.2 Renew licenses, software, interfaces.

1.3 Software updates such as security, correction, compatibility, and enhancement releases of licensed products.

1.4 Access to client technical support representatives via email and telephone.

1.4.1 Routine support Monday through Friday between 8:30 AM EST and 7:00 PM EST.

1.4.2 Emergency support 24x7x365

1.5 Technical support services include application support for licensed products (user and administrator); assistance with identification and resolution of errors or defects; assistance with application and use of new releases; general support for Board Builder and boards built by client or contractor and access to WebEOC best practices, community-use status boards, “help” resources and other content made available through contractor

1.6 Access to the online WebEOC community through a Contractor-hosted web portal.

1.7 Deliver the latest releases of the following products to the CBP production environment at the National Data Center:

-WebEOC Air and Cruise Care Plan -WebEOC Maps Add-On Module Care Plan -WebEOC Disaster Recovery (i.e., redundant server) maintenance and support -WebEOC Resource Request and Deployment Module Care Plan -WebEOC ArcGIS Extension Module Care Plan -WebEOC Enterprise (includes Fusion, Board Data Manager Module, and sub-admins) maintenance and support -WebEOC Single Sign-On Module Care Plan -WebEOC® Tech Services

- WebEOC Significant Incident Module -WebEOC Tutorial Plugin

1.8 Technical Implementation Analyst (TIA) (WebEOC Management)

· Provide a centralized and unified incident reporting structure for CBP. Ensure that reporting functions fully merge in a single system improving enterprise-wide awareness

· Generate a streamlined reporting and system implementation through computers, tablets, and mobile device data entry resulting in real-time updates across CBP.

· Fully integrate reporting as the CBP Watch and mission offices’ reporting functions fully merge into a Common Operating Picture to improve enterprise-wide awareness.

· Increase data accessibility as multiple system data feeds are integrated into WebEOC for a more informed operational picture.

- WebEOC Boards as identified by Program Manager/COR that includes key features as part of a template aesthetic. To match this, all boards will include:

· CBP’s stylesheets to match the look-and-feel

· CBP’s banner header

· PDF export capabilities on all display views

· Excel export capabilities on all list display views

· What’s New modal feature to track board-level code changes (present only on primary list view)

· Management list view to view and/or recover deleted records

· View links (clickable links to allow users to edit or see detail information) will be tucked inside an Actions dropdown on list views

1.9 Solution Implementation Analyst (SIA) (WebEOC Management) The Contractor personnel shall provide the following tasks to support all WebEOC Boards:

1.9.1 Develop and maintain plans and procedures for emergency planning, response operations, and WebEOC Boards.

1.9.2 Develop training and exercises in support of emergency management objectives as well as for all WebEOC training strategic communications efforts.

1.9.3 Support Emergency Operations Center activation and deployment activities.

1.9.4 Maintain crisis action team rosters and distribution lists for personnel deployment tracking.

1.9.5 Document lessons learned to include tracking progress, completion timelines, and establishing contractual level of efforts.

1.9.6 Support CBP’s involvement in Component, Department, and Interagency working groups.

1.9.7 The Contractor shall provide support services for consolidating knowledge based past AAR, Improvement Plans and Corrective Action Plans, Draft system design, implementation, and change management plans, and perform data analytics on system data and processes pertaining to WebEOC.

1.9.8 The Contractor shall maintain the project schedule and other project related documentation as well as the administrative, contractual, and financial aspect of the project.

1.9.9 Ensure that the deliverables are developed according to the DHS/CBP specifications and delivered on time.

1.9.10 Review and deliver any work summary/progress reports, manage and assigns all staff associated with the project and handle any question associated with invoices.

1.9.11 Respond to Taskings and develop correspondence.

1.9.12 Coordinate and collaborate with internal CBP components.

1.9.13 Maintain and update Standard Operations Procedures (SOP, program documentation, and training materials for all WebEOC efforts.

1.9.14 Create and maintain WebEOC user accounts and access levels.

1.9.15 Maintain technical requirement documents and process optimization plans for IICC processes and data connections.

1.9.16 The Contractor shall maintain the project schedule and other project related documentation as well as the administrative, contractual, and financial aspect of the project.

1.9.17 Ensure that the deliverables are developed according to the DHS/CBP specifications and delivered on time.

1.9.18 The contractor shall provide developers to assist with the merging of the SITROOM Module with WebEOC and general support in the WebEOC.

1.10 - WebEOC Development for Medical

All new records will include the ability to geo-locate using device location services, allowing records to be displayed on a map for enhanced situational awareness. The solution will leverage the WebEOC mobile application currently in development, and will further support the user in leveraging displays and system capabilities (i.e. automated reminders for follow-up and medical treatments).

CBP has a current board set that includes key features as part of a template aesthetic which has been approved by the government point of contact. To match this, the Medical Intake Board will include:

· CBP’s stylesheets to mirror the look-and-feel

· CBP’s banner header

· PDF export capabilities on all display views

· Excel export capabilities on all list display views

· Information icon in the top right on some of the boards will be used to house a description of the board and an accompanying informational paper for new users

· Management list view to view and/or recover deleted records

· View links (clickable links to allow users to edit or see detail information) will be tucked inside an Actions dropdown on list views

1.10.1 EMR System Development Life Cycle

Contractor shall utilize customized application components in support of the CBP EMR System (Boards) using a collaborative, agile software development methodology. Contractor shall provide the following services and deliverables:

· Host Sprint Planning meetings with Stakeholders and Product owners to discuss technical and developmental requirements ahead of each Sprint Development Cycle.

· Deliver system updates in two-week sprints, as directed by the EMR Program Manager (acting as Product Owner) in Sprint Authorization Memo’s generated after each Sprint Planning meeting.

· Facilitate a Sprint Demo and Sprint Retrospective at the end of each Sprint Development Cycle.

· At the end of each two-week sprint deliver updates in the CBP SAT and Training environment for Government Assessment Testing.

· Upon Government Approval a Release Memo will be generated by the Government.

· For each Release Memo the vendor will provide a Version Description Document providing a Narrative of changes, a set of Release Notes, and Updated User Guide and/or Training Materials to cover the included system changes. Upon completion of this release package Vendor will deploy the changes to the CBP Production environment.

1.10.2 - Additional Scope Requirements

The contractor shall add the below functionality and features to enhance the current solution:

· Support of barcode scanning in conjunction with Bluetooth or USB scanners to capture and utilize identifying information contained on patient wristbands.

· Medication/Follow-up Care Reminders and Diagnostic Plan:

· Functionality to build additional medical monitor and medication boards which will be associated with the encounter records to support providers in tracking those patients who need periodic monitoring and medication

· This functionality may use or trigger color coding for visually conveying patient statuses for those patients described above.

· A checkbox or other filtering mechanism (for example) will be visible from the homepage to filter and highlight those patients that require medication and monitoring

· This board will include sections to reflect diagnostic plan of associated encounter and medication required (if required for patient) as well as other necessary fields depending on the diagnosis.

· Medication order/administration will be tracked as well as any other monitoring checks required for the patient.

· Fields shall also be created for tracking medication using standardized values that would derive from the standardized formulary approved for use.

· Additional fields may be needed to capture and track dosage/concentration/route, and other information associated with administration of medication.

· Exit Health Interview – Additional fields shall be created to store information related to “fit for travel” requirements and for transfer to downstream facilities as appropriate.

· Public Health/Infectious Disease support – Additional fields may be necessary, as determined by each of the WebEOC Board Owners, to support enhanced protocols needed to address and track public health/infectious disease requirements as needed.

· Printing Functionality – A patient summary shall be available to print a patient profile to include all biographic, intake, assessment, encounter and medication/follow-data as defined.

· Document and Image file Attachment capability – Contractor shall create functionality to enable the upload of documents and images that could be appended to patient records (ex. Hospital records) at various points in the workflow process.

· Systems Integration and Data Integrity- The contractor shall work with WebEOC Medical Boards IPT and CBP OIT in support of the following goals:

· Data integrity: A medical record within WebEOC must be appropriately linked to the overall actions that occur for each subject within CBP custody.

· APIs: As requested by the WebEOC project manager, the WebEOC team will provide the CBP OIT team with the appropriate APIs for system integration that comply with OIT technical architecture requirements and CBP and DHS Security.

· Information Sharing Dashboards

· Based upon WebEOC IPT input, the contractor shall create information dashboards that would enable situational awareness of mission essential patient tracking related information for use among CBP program management, as well as government and contract supervisory medical physicians, quality control management, and patient safety risk managers.

· Web-EOC Map Based view Contractor shall ensure successful configuration of WebEOC Mapping functionality to provide users with the ability to geo-plot data from the Medical Boards and access sets of default layers through the ESRI ArcGIS Online service. All street, satellite and topography imagery will be visible as mapping layers.

Geocoded patient data will also be available to be downloaded from WebEOC for upload into another map-based application or program to support map based queries or visuals.

Other CBP Medical Board Features The contractor shall configure the following features based upon feedback and specifications from the WebEOC IPT:

· Data storage/syncing – System shall allow for data input via mobile device when out of network range and automatic sync up and data upload when returning to range

· Reporting Functionality – Contractor shall configure canned/standard reports based upon user specifications as well as support and/or configure ad-hoc reporting tools and functionality

· Free Text Search - System shall include the ability to quickly and easily search data based on “key words” related to the patient profile data and medical data, within specified date and location criteria.

1.10.3 - Board Refinements The contractor shall refine CBP Medical boards based on user input throughout all phases of the testing process and beyond the go-live/implementation phase into steady state operations as the CBP customer’s business rules and workflow may change.

As refinements are made, business process models may be generated to include the use of flow charts or activity diagrams.

A Requirements Traceability Matrix (RTM) and other relevant workflow documents shall also be created and updated by the contractor as required. The RTM shall clearly link the new and/or changed requirements to where and how they have been implemented in the system. The RTM shall provide backwards and forward traceability, meaning the RTM documents each requirement from its source through definition, analysis design, testing, acceptance, and deployment.

1.10.4 - User Defined Groups and Access Roles

WebEOC contractor shall work with the CBP medical boards team to ensure boards and processes implemented are consistent with agency requirements. This includes ensuring final access privileges are assigned to Status Boards, plug-ins, links and menus and process permissions are assigned to Organization Groups. WebEOC will also assist to review the processes with the CBP team.

CBP will provide input to the contractor regarding the appropriate user access validation structure needed for (1) defining Users, (2) assigning Users to Positions, (3) assigning Positions to Groups and (4) assigning permissions (privileges) to Groups. Each user account must be assigned to a position and each position must be assigned to a group. The group assignment defines the permission that the user will have to the various Boards and application features.

The contractor will work with the WebEOC Program Manager to set up representative accounts. In concert with this effort, the contractor will provide best practices for naming conventions and introduce techniques to deal with implementations where the system may be sharing information with other WebEOC installations/agencies.

The contractor shall create administrative super user roles as appropriate to enable "super users" at the component level to configure and edit certain data fields or dropdown values without going to a contractor – these would only be defined as recommended by the contractor and WebEOC IPT.

1.10.5 Phased Implementation

· The implementation of the CBP Medical Boards will continue to take place in a phased fashion as defined by the CBP Medical IPT.

· The various “Go-Live” iterative phases will occur as releases when the functional board has no visible issues based on the requirements and expectations of outcome.

· The contractor shall continue to provide refinements based upon issues encountered during the phased implementation in coordination with the PMO.

1.10.6 - Process User Validation and Onsite targeted user training

Once a baseline process is developed and installed, targeted training can be conducted. The contractor shall participate in the initial training and advise on the development of training materials to help ensure the training is tailored to CBP’s unique implementation. This initial training would be administered to selected Users representing key positions. Upon completion of training, the same individuals participate in a mini exercise. The purpose of the exercise is to test user knowledge gained during initial training. It will also be used to validate the WebEOC implementation as directed by the Customer and highlights areas needing improvement.

Upon completion of onsite training and the exercise, contractor shall work with the PMO to address any issues identified and implement any needed changes.

1.10.7 - Steady-State Support for Changes to Boards and Corrective Maintenance

Contractor shall remain available following the implementation and live release of the CBP medical boards to make minor changes to the board data fields and other aspects of the application based on changing requirements, structural data needs and changes to CBP policy/medical service requirements.

Examples of issues that require corrective maintenance include the following:

· Data screens that omit a required entry or store an entry in the improper location

· Improper logic in business rules

· Aborted programs

· Error messages Interfaces that are not functioning as designed

· Application configuration issues in which the contractor shall ensure software contractors and other technical staff follow project plans established in each Work Request when conducting Steady-State corrective maintenance.

2.0 TESTING AND REPORTING

The technical support and development work assigned shall be determined complete after CBP accepts the work. CBP will conduct a functional test of the API which must be successful, and ENS within the Situation Management System must be internal facing.

If the API does not function in accordance with CBP’s design request, the COR and Contractor shall be notified within five (5) days, and the Contractor must take immediate corrective action.

Testing for Medical boards. The Contractor shall work with the WebEOC IPT to conduct a series of tests to include: functional, unit, system/integration, regression, load/performance and/or stability tests, as applicable. Each applicable test shall be identified as a milestone in project plan. The amount and type of testing shall be commensurate with the size, scope, and risk of the specific release as deemed necessary by the Government WebEOC Project Manager.

2.1 Functional and Technical Testing

The initial prototype of the CBP medical boards has already been developed by the CBP Medical Boards IPT. This prototype has undergone initial testing with the team, but functionality tests of the web boards must be performed to further tailor the board configurations from a functional standpoint. In this round of beta testing, the provider testing user groups will ensure boards and processes implemented are consistent with their medical and agency requirements.

Testing user groups, which will consist primarily of medical providers and some CBP Project Managers that use the system for different needs, will provide their input to the IPT.

Contractor shall work with the CBP Medical IPT to provide input into the numbers of testers needed and functions that should be tested at different stages of development. Contractor shall provide input into the functional and technical testing plan documents to help ensure that the necessary aspects of the application are tested sufficiently.

Contractor shall make any refinements needed to better adapt the WebEOC medical boards to support their workflow box processes. To the extent possible, contractor shall participate in functional testing to receive real-time feedback on functionality and discuss workflow issues and areas for improvement. Participants will include the CBP IPT, as well as contract medical personnel and project managers or his/her designee.

Technical Testing must also be performed to validate performance and identify and correct issues.

The contractor shall be available on site or remotely to interact with CBP personnel and its medical contractors as they perform as many scenarios as possible, hitting select all, entering data on all forms and ensuring that they can view the data with the “Details Views” and printing the records.

The contractor shall support and guide the CBP IPT in testing the following functions:

· Browser functionality with the site computers and mobile tablets/laptops. Functionality will be tested in Internet Explorer 11, Microsoft Edge, and Google Chrome, if applicable, or any updated programs.

· Contractor shall perform fixes as needed to ensure compatibility with applicable browsers

· Test WebEOC Positions created by the CBP WebEOC Team

· Performance testing with heavy user load and activity

· Test to validate performance in an integrated testing environment

· Tests will be conducted to identify and correct system/technical errors encountered by the user test group and has no visible issues based on the requirements and expectations of outcome

· The contractor shall provide automatic testing scripts

Technical issues encountered during testing will be well documented by CBP and forwarded to the contractors to account for any possible scenarios that could present user issues. Contractors shall perform refinements and fixes to the medical boards based upon this feedback. Functionality will be tested until application works as intended.

2.2 User Acceptance Testing

User Acceptance Testing (UAT) is the critical step for identifying whether the medical boards are ready to be deployed.

System performance load and stress testing will begin as early as feasible in the Execution of Solution phase and shall be conducted at appropriate intervals prior to the submission of the request for the system release to ensure acceptable performance in production.

The Contractor shall help to prepare or update a User Acceptance Test (UAT) Plan and test scenarios/scripts for users to follow during the initial structured portion of the UAT (following structured testing the users are encouraged to conduct their own free-form testing). The Contractor shall assist the Government during the preparation and execution of the acceptance test by establishing test data and maintaining the test environment.

The Contractor shall correct any errors identified by the User Acceptance Test team. The Contractor shall document the results of the testing in the Test Report. Upon receipt of the report, the Government will examine the test results and make a determination as to the readiness of the new or modified code and/or system changes/additions to be released into the production environment.

3.0 PROGRESS REPORTS

The Project Manager shall provide a monthly progress report to the Contracting Officer and COR via electronic mail. This report shall include a summary of all Contractor work performed, including an assessment of technical progress, schedule status and any Contractor concerns or recommendations for the reported period. All Medical records reporting should be separated out as this is paid for with a separate funding string and must be tracked accordingly.

4.0 Travel

Travel will be part of the overall operation and maintenance of this contract. All required travel must be preapproved and authorized, by the CO or the COR. All travel will be reimbursed to the Contractor in accordance with the Federal Travel Regulations and not to exceed $15,000 per year. The Contractor shall be responsible for obtaining COR approval (e-mail is acceptable) for all reimbursable travel in advance of each travel event. The Contractor exceeds the NTE at its own cost and risk.

5.0 Invoicing

The Contractor shall submit an invoice in accordance with FAR 32.905 Payment Documentation and Process into the Invoice Processing Platform (IPP) system for processing.

1.0 A proper invoice shall include the following:

1. Name and address of the contractor

1. Invoice date and invoice number

1. Contract number or other authorization for supplies delivered or services performed

1. Description, quantity, unit of measure, unit price, and extended price of supplies delivered or services performed.

1. Shipping and payment terms (e.g., shipment number and date of shipment, discount for prompt payment terms). Bill of lading number and weight of shipment will be shown for shipments on Government bills of lading.

1. Name and address of contractor official to whom payment is to be sent (must be the same as that in the contract or in a proper notice of assignment).

1. Name (where practicable), title, phone number, and mailing address of person to notify in the event of a defective invoice.

1. Taxpayer Identification Number (TIN). The contractor must include its TIN on the invoice only if required by agency procedures.

1. Electronic funds transfer (EFT) banking information.

The contractor shall submit invoices via IPP once monthly.

6.0 DELIVERABLES

Final Review/Acceptance of Work Products Although the Contractor shall be responsible for generating work products, recommendations, etc., the Contractor is advised that final determination for all work products, recommendations, etc. is reserved for Government officials. Any documents, briefings, or oral recommendations provided to Government staff are only recommendations, and the decision to accept, reject, or modify them is the responsibility and authority of the cognizant Government Official.

The Contractor shall submit all deliverables on the respective due dates which are considered significant in the performance of this contract in accordance with the following.

7.0 GOVERNMENT FURNISHED EQUIPMENT

7.1 Upon completion of a CBP background investigation, a computer workstation for the Government site will be provided to contractors working on-site as deemed necessary to support OS. Upon termination of contract or separation of service, contractor must immediately return all government furnished equipment to the COR or other designee. On a case-by-case basis, additional items such as laptop and cell phone may be issued. The Government will also provide access to copiers, fax machines, printers and scanners. All Government issued equipment shall be used in accordance with CBP Office of Information Technology (OIT) policies and guidelines.

8.0 SECURITY

8.1 All contractor employees must have CBP Background Investigation before working on site. The contractor shall comply with CBP administrative, physical and technical security controls to ensure that the Government's security requirements are met. Contractor must submit names of employees within five business days of contract award.

8.2 Physical Security: The contractor shall be responsible for safeguarding all Government equipment, information and property provided for contractor use. At the close of each work period, Government facilities, equipment, and materials shall be secured per CBP policy.

8.3 Identification of Contractor Employees: All contractor employees shall be required to wear identification badges when working in government facilities. “Identification of Contractor Employees in the Federal Workplace (Aug 2008):

1. The contractor shall provide each of its employees who will be involved in the performance of the work located on a Government facility with an identification (ID) badge. The ID badge shall clearly display the contractor’s name, the employee’s name and color photograph of the employee. The Contracting Officer or his/her designee shall approve the ID badge before the commencement of work performance. It is the contractor’s responsibility to ensure that all contractor personnel wear the ID badge at all times when performing work under this task order at a Government facility. Unless otherwise specified, contractor employees shall wear the ID badge in a conspicuous place on the front of his or her clothing and above their waist, except when safety or health reasons prohibit such placement. This requirement is in addition to any Government facility security provisions that require that a Government-issued security badge also be worn.

1. The contractor personnel shall clearly identify themselves to all attendees as a contractor employee when placing, answering or participating in telephone/VTC conversations with Government or other contractor personnel.

1. When contractor personnel send e-mail messages from or to a Government owned computer when conducting Government business, they shall include a signature block that includes their employer’s name and the employee’s full name and e-mail address.

1. Each of the requirements set forth in paragraphs a-c above, must be included in all subcontracts at any tier.

9.0 Section 508 Requirements

Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) (codified at 29 U.S.C. § 794d) requires that when Federal agencies develop, procure, maintain, or use information and communications technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public with disabilities must be afforded access to and use of information and data comparable to that of Federal employees and members of the public without disabilities.

All products, platforms and services delivered as part of this work statement that, by definition, are deemed ICT shall conform to the revised regulatory implementation of Section 508 Standards, which are located at 36 C.F.R. § 1194.1 & Appendix A, C & D, and available at https://www.gpo.gov/fdsys/pkg/CFR-2017-title36-vol3/pdf/CFR-2017-title36-vol3-part1194.pdf. In the revised regulation, ICT replaced the term electronic and information technology (EIT) used in the original 508 standards. ICT includes IT and other equipment.

Exceptions for this work statement have been determined by DHS and only the exceptions described herein may be applied. Any request for additional exceptions shall be sent to the Contracting Officer and a determination will be made according to DHS Directive 139-05, Office of Accessible Systems and Technology, dated November 12, 2018 and DHS Instruction 139-05-001, Managing the Accessible Systems and Technology Program, dated November 20, 2018, or any successor publication.

10.0 Section 508 Requirements for Technology WebEOC Board Development

Section 508 applicability to Information and Communications Technology (ICT): software

Applicable Exception: N/A Authorization #: N/A

Applicable Functional Performance Criteria: All functional performance criteria in Chapter 3 apply to when using an alternative design or technology that results substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4 and 5 of the Revised 508 Standards, or when Chapters 4 or 5 do not address one or more functions of ICT.

Applicable 508 requirements for electronic content features and components (including but not limited to Internet or Intranet website; Electronic documents; Electronic forms; Electronic document templates; Electronic emergency notifications; Electronic surveys; Electronic reports; Electronic training materials; Multimedia (video/audio); Interactive maps; Other): All requirements in E205 apply, including all WCAG 2.0 Level A and AA Success Criteria apply as specified in E205

Applicable 508 requirements for software features and components (including but not limited to Web, desktop, server, mobile client applications; Electronic content and software authoring tools and platforms; Software infrastructure): All requirements in Chapter 5 apply, including all WCAG 2.0 Level A and AA Success Criteria, 502 Interoperability with Assistive Technology, 503 Application, 504 Authoring Tools

Applicable 508 requirements for hardware features and components: Does not apply

Applicable 508 requirements for support services and documentation: All requirements in Chapter 6 apply

10.1 Section 508 Requirements for Technology Services

1. When providing installation, configuration or integration services for ICT, the Contractor shall not reduce the original ICT item's level of Section 508 conformance prior to the services being performed.

2. When providing maintenance upgrades, substitutions, and replacements to ICT, the contractor shall not reduce the original ICT’s level of Section 508 conformance prior to upgrade, substitution or replacement. The agency reserves the right to request an Accessibility Conformance Report (ACR) for proposed upgrades, substitutions and replacements prior to acceptance. The ACR should be created using the on the Voluntary Product Accessibility Template Version 2.2 508 (or successor versions). The template can be located at https://www.itic.org/policy/accessibility/vpat

3. When providing Platform as a Service (PaaS) or Software as a Service (SaaS), the contractor shall ensure services conform to the applicable Section 508 standards (including the requirements in Chapter 5 for software and WCAG Level A and AA Level 2.0 success criteria for web and software. When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall ensure conformance to the Functional Performance Criteria specified in Chapter 3.) The agency reserves the right to request an Accessibility Conformance Report (ACR) for PaaS and SaaS offerings. The ACR should be created using the Voluntary Product Accessibility Template Version 2.2 508 (or later). The template can be located at https://www.itic.org/policy/accessibility/vpat

4. When providing cloud hosting services (Infrastructure as a Service, Platform as a Service, Software as a Service, etc.) the Contractor shall ensure user administrative screens, dashboards and portals used to configure, and monitor cloud services conform to the Section 508 standards.

5. The Contractor shall ensure cloud hosting services shall not reduce the level of Section 508 conformance for ICT migrated by DHS to the cloud hosting environment.

6. When developing or modifying ICT, the Contractor is required to validate ICT deliverables for conformance to the applicable Section 508 requirements. Validation shall occur on a frequency that ensures Section 508 requirements is evaluated within each iteration and release that contains user interface functionality.

7. When modifying, installing, configuring or integrating commercially available or government-owned ICT, the Contractor shall not reduce the original ICT Item’s level of Section 508 conformance.

8.When developing or modifying web based and electronic content components, except for electronic documents and non-fillable forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria) by conducting testing using the DHS Trusted Tester for Web Methodology Version 5.0 or successor versions, and shall ensure testing is conducted by individuals who are certified by DHS on version 5.0 or successor versions (e.g. “DHS Certified Trusted Testers”). The Contractor shall provide the Trusted Tester Certification IDs to DHS upon request. Information on the DHS Trusted Tester for Web Methodology Version 5.0, related test tools, test reporting, training, and tester certification requirements is published at https://www.dhs.gov/trusted-tester.

9.When developing or modifying electronic documents and forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable to the applicable Section 508 standards (including WCAG Level A and AA Level 2.0 Success Criteria) by conducting testing using the test methods published under “Accessibility Tests for Documents” at https://www.dhs.gov/compliance-test-processes.

10.When developing or modifying ICT deliverables that contain the ability to automatically generate electronic documents and forms in Microsoft Office and Adobe formats, or when the capability is provided to enable end users to design and author web based electronic content (i.e. surveys, dashboards, charts, data visualizations, etc.), the Contractor shall demonstrate the ability to ensure these outputs conform to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria). The Contractor shall demonstrate conformance by conducting testing and reporting test results based on representative sample outputs. For outputs produced as Microsoft Office and Adobe PDF file formats, the Contractor shall use the test methods published under “Accessibility Tests for Documents”, which are published at https://www.dhs.gov/compliance-test-processes. For outputs produced as web based electronic content, the Contractor shall use the DHS Trusted Tester for Web Methodology Version 5.0, or successor versions. This methodology is published at https://www.dhs.gov/trusted-tester

11. When developing or modifying software functions of ICT, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the requirements in Chapter 5 and WCAG 2.0 Level A and AA Success Criteria). When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall demonstrate conformance to the Functional Performance Criteria specified in Chapter 3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for software functionality delivered pursuant to this contract. The Contractor may utilize the DHS Trusted Tester Methodology for Web and Software Version 4.0 as a component of the overall test process used. This version of the test process provides partial test coverage of the Section 508 standards that apply to software. If the Contractor uses this test process, the Contractor shall address the test coverage gaps through additional test procedures. Information on the DHS Trusted Tester Methodology for Web and Software Version 4.0, including coverage against the applicable Section 508 standards for software as well as gaps that need to be addressed through other test methods, related test tools, and training is published at https://www.dhs.gov/trusted-tester.

12. When developing or modifying hardware components of ICT, including closed systems (for example – kiosks), the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the Chapter 4 hardware requirements). Where the requirements in Chapters 4 do not address one or more functions of ICT, the Contractor shall demonstrate conformance to the Functional Performance Criteria specified in Chapter 3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for hardware functionality delivered pursuant to this contract.

13. Contractor personnel shall possess the knowledge, skills and abilities necessary to address the accessibility requirements in this work statement.

10.2 Section 508 Deliverables

1. Section 508 Test Plans: When developing or modifying ICT pursuant to this contract, the Contractor shall provide a detailed Section 508 Conformance Test Plan. The Test Plan shall describe the scope of components that will be tested, an explanation of the test process that will be used, when testing will be conducted during the project development life cycle, who will conduct the testing, how test results will be reported, and any key assumptions.

2. Section 508 Test Results: When developing or modifying ICT pursuant to this contract, the Contractor shall provide test results in accordance with the Section 508 Requirements for Technology Services provided in this solicitation.

3.Section 508 Accessibility Conformance Reports: For each ICT item offered through this contract (including commercially available products, and solutions consisting of ICT that are developed or modified pursuant to this contract), the Offeror shall provide an Accessibility Conformance Report (ACR) to document conformance claims against the applicable Section 508 standards. The ACR shall be based on the Voluntary Product Accessibility Template Version 2.0 508 (or successor versions). The template can be found at https://www.itic.org/policy/accessibility/vpat. Each ACR shall be completed by following all of the instructions provided in the template, including an explanation of the validation method used as a basis for the conformance claims in the report.

4. Other Section 508 Documentation: The following documentation shall be provided upon…