2018_BAA_Real_Time_Electronic_Data_Sharing_SOO_I.pdf

Real-Time Electronic Data Sharing

Statement of Objectives BAA 18-02/Call 0001/SOO I

April 1, 2019 Science and Technology Directorate (S&T) Department of Homeland Security (DHS)

BAA 18-02/Call 0001/ SOO I Real-Time Electronic Data Sharing

Table of Contents

Contents

1.0 Problem Statement

2.0 Purpose and Scope

3.0 Background Environment

3.1 Current Technology Shortfalls and Threats

4.0 Potential Solution Attributes

4.1 Concept of Operations (ConOps)

4.2 Additional Capabilities

5.0 Solution Capabilities and Requirements

5.1 Must Have Requirements (Key Performance Parameters)

5.2 Desirable Capabilities or Characteristics

6.0 System Support

6.1 Contractual Requirements

6.1.1 Period and Place of Performance

6.1.2 System Affordability

6.2 Solution Support

6.2.1 Training

6.2.2 Storage and Maintenance

1.0 Problem Statement

To more effectively manage emergency response, first responders serving in a leadership capacity need a tool that 1) maps out incident scenarios, 2) provides a visual overview of the location and progress of first responder teams on the ground in response to an incident, and 3) permits digital substitution for paper-based incident command decision-making tools. Additionally, non-leadership personnel, particularly those in the field, do not have the capability to 1) quickly inform higher levels of command during a response besides relaying information by radio or in-person, or 2) passively and continuously share their location, status, or the details of their surroundings. These issues negatively affect most first responder disciplines, particularly in environments with limited visibility, intricate architectures, or complex events. The technical solution shall be applicable to firefighters, Hazardous Materials (HAZMAT) teams, disaster response teams, and certain law enforcement personnel such as special operations units during unusual and complex incidents (e.g.

riots). Simply being able to tell which floor a first responder is on in a high-rise, for example, provides invaluable geo-spatial awareness for incident command. A quicker response results in the increased likelihood of lives saved. Also, improved awareness of nearby first responders shall reduce the risk of friendly-fire. This component of the solution is expected to be the next generation precision outdoor and indoor navigation and tracking tool for first responders. However, the technical solution is also expected to provide the capability to electronically document, save, and share back to command center in real time data on incident planning, actions, and mapping.

2.0 Purpose and Scope

As an incident occurs, the ability to simultaneously work on a shared and accurate common operating picture with various points of leadership (and in-field personnel) can rid first responders of unnecessary inefficiencies including time wasted, poor coordination, and poor decision-making based on stale or incorrect information. Further, incident command is required to maintain and keep track of all pertinent documentation of decisions and certain data inputs for post-incident review.

Therefore, a supplementary need of near equal importance is the ability to record, store, and manage this information with time-stamped and categorized reference capabilities. The resulting recorded, managed, and stored information should improve transparency, consistency, and accuracy during internal after-action reviews as well as related legal proceedings.

3.0 Background Environment

3.1 Current Technology Shortfalls and Threats

The solution should accommodate disparate data inputs such as unmanned aerial vehicle video footage, data terminals, radio calls, photos, and emails from personnel in the field or leadership not present at the scene. The data inputs should be filterable by file type, inputting personnel, and date/time stamp. The general framework of the solution’s interface should be customizable. Also, the solution should assume that some (if not all) users will be at the scene and thus in need of a ruggedized, potentially portable solution.

Incident command generally develops a common operating picture by hand and on paper or whiteboard to manage resources and situation statuses. Receiving and disseminating common operating picture information must be done by sharing in-person, over radio, or by making physical copies. These efforts are time consuming and inflexible, therefore limiting decision-making efficiency. Further, physical copies of important documents must be saved for use in after-action reviews but are often lost or inadvertently thrown away. Some incident command personnel have experimented with commercially free or affordable document sharing tools as a work-around for basic document and information sharing including:

• Capturing geocoded information (ArcGIS Collector) and putting it into a map

• Sharing of pictures and documents (Moxtra/Intrepid)

• Geolocation of resources (GeoSuite)

• Real-time video sharing (Datacasting, etc…)

• Documentation and Incident Management (TRG-WebIAP, Rodium, etc…)

However, integrating these systems into a single data/visual repository that allows for synthetization of data and associated mapping through a variety of mediums does not currently exist, much less the ability to have all central documentation about the incident be in a single searchable repository. A true solution shall be highly-specialized to meet first responder needs that cannot be resolved worked around.

4.0 Potential Solution Attributes

4.1 Concept of Operations (ConOps)

The solution shall work as a web-based software operating in either a virtual cloud (e.g. Amazon Web Services (AWS)) or on agency servers and shall be configurable to a variety of input mediums.

Input mediums could be current electronic device standards such as audio, photo, and video formats as well as various email platforms. However, the capability to link various enterprise solutions such as Environmental Systems Research Institute (ESRI)/ArcGIS and unmanned aerial vehicle outputs shall be configurable in the settings to allow for integration without licensing compromises.

Users shall have access to the web-based software through smartboard or computer-based platforms. Users shall have the capability to access, run reports, share information, and link information to a real-time common operating map. The common operating map can also link to other enterprise mapping solutions to ensure two-way communications and ensure information is not siloed into the software. The software, regardless of device being used, records all the information and uploads it to the cloud or other web area. The users in the field have real-time access to the smartboard through a mobile application on their standard smart phone or tablet. The mobile application may allow field personnel to enter and update information on the smartboard, but must provide flexibility for agencies to determine input/output restrictions.

Through a user control management interface, response personnel could be preconfigured into the system. Real-time user profile management will link the various capacities of their devices or computers into the web platform for real-time information sharing. For users that have not been vetted, a basic “universal” profile allows them to submit data but not view the data until the profile is validated.

During an incident, responders operating in the application (linked to a web platform) will have real-time information sharing capabilities and viewing capacity through a simple, easy to use user interface. The application will also activate the users Global Positioning System (GPS) function in their device and allow for real-time tracking of the resource and geocoding of information for easy recall and data logging.

4.2 Additional Capabilities

Users operating on the smartboard or computer-based platforms will have an enhanced capability to access, run reports, share information, and link information to a real-time common operating map.

The common operating map shall also link to other enterprise mapping solutions to ensure two-way communication and ensure information is accessible. The software will record all the information and upload it to the cloud (or other web area). The users in the field have real-time access to the smartboard through a mobile application on their standard smart phone or tablet. The mobile application may allow field personnel to enter and update information on the smartboard but must provide flexibility for agencies to determine input/output restrictions.

5.0 Solution Capabilities and Requirements

5.1 Must Have Requirements (Key Performance Parameters)

The proposed solution must:

• Life expectancy of the solution’s technology o Cradle to grave software solution Predicated on continuous updates and modifications.

o Applications Continuous updates and modifications.

• Physical characteristics o Smartboard device – About the size of current command boards and able to fit in a command car.

• Durability o If only software-based, then durability is dependent on type of device being used to house software.

o If smartboard-like device is to be included in solution, then ruggedness is required as the device will be in and out of vehicles and potentially exposed to poor weather conditions.

• Power Supply o Smartboard-like device must be direct current battery-powered.

5.2 Desirable Capabilities or Characteristics

• Certification Requirements for Product Conformity.

o Desktop and mobile application programming software needs to be Department of

Homeland Security (DHS) Standard coding protocol o Desktop software – easy-to-use interface o Mobile Application – easy-to-use interface, minimization of buttons and steps to share information o Full push/pull API is needed to integrate solution with existing capabilities and enterprise

(username/password) solutions.

6.0 System Support

6.1 Contractual Requirements

6.1.1 Period and Place of Performance

The length of time of the contract shall be between 12-18 months and shall not exceed 18 months.

All developmental activities will be performed at the contractor-designated site(s). DHS may require the contractor to perform critical design reviews and/or product presentations at DHS-specified locations.

6.1.2 System Affordability

First responder agency budgets are limited and should be taken into consideration when developing and determining a price per unit cost model.

6.2 Solution Support

6.2.1 Training

Training information as required shall be provided on any specialized equipment, and shall include how to properly store, clean, deploy, and maintain the basic ensemble/unit. Any specialty requirements of personnel conducting maintenance, storage, extraction, or delivery will be identified including certification requirements. Training material shall be available initially in hard-copy, and subsequently in soft-copy format.

6.2.2 Storage and Maintenance

The contractor shall identify all necessary storage and maintenance requirements for the proposed solution including: the required maintenance schedule, identification of the specific components of the ensemble that requires maintenance, the type of maintenance required, and whether the maintenance can be performed in the field by operational personnel or if it will be required to be returned to the manufacturer for the required maintenance.

If the proposed solution is virtual, describe any storage or maintenance requirements, including archival activities, and the personnel performance needs associated with the solution.