1. Introduction

1. INTRODUCTION

Firefighters, law enforcement officers, and emergency medics have inherently dangerous jobs. Dangers in these occupations are mitigated through rigorous training, processes, and oversight. Dangers manifest themselves through a wide variety of external forces, including gunfire, building fires, and vehicle accidents. An often-overlooked danger is the physical activities emergency responders undertake to do their jobs and the associated stress and exertion those activities place on their bodies. In 2017, 87 firefighters died in the line of duty. Of those 87 deaths, 52 were the result of stress or overexertion; this includes all deaths that are cardiac or cerebrovascular in nature, such as heart attacks and strokes, as well as other events, such as extreme climatic thermal exposure.[1] Similarly, 139 law enforcement officers died in the line of duty in 2017; 16 of those officers died of a heart attack.[2] Technology in the realm of personal biometric health and wellness sensors has advanced dramatically over recent years. Many people today wear basic health monitoring devices in the form of smart watches and workout sensors. Leveraging health and wellness biometric sensors for emergency responders and combining data obtained from them with other relevant data for firefighters (e.g., air reserves, temperature, location, presence of hazardous materials and gases) and law enforcement officers (e.g., unholstering a weapon, body cameras, location) can result in fewer deaths.

1.1 Problem Statement

  • Emergency responders need a tablet- or smartphone-based dashboard showing the status of sensors worn by emergency responders or sensors connected to the equipment they use. Multiple technological solutions (sensors) exist in both the public safety and consumer markets today to monitor the health of emergency responders and to monitor their activities and equipment. However, most of these solutions are limited in their ability to serve the emergency responder needs for the following reasons:
    • Narrow focus and single-dimensional solution that solves only a subset of the many issues faced by emergency responders.
    • Use of proprietary mechanisms and data formats that do not scale and fail to integrate with emergency responder systems.
    • Data processing and presentation capabilities lacking in their support of real-time, high-intensity decision making faced by emergency responders and their supervisors.
    • Generalized solutions not specific for use by an emergency responder discipline (law enforcement, fire and EMS).

Use Cases

  • All emergency responders, regardless of discipline, encounter situations that present dangers to their health, safety, and wellness.
  • Structure Fire — During a structure fire, firefighters face environments with temperatures of hundreds of degrees while wearing and carrying more than 50 pounds of equipment, crawling through low visibility in an environment full of noxious gases, and strenuously exerting themselves. Monitoring heart rate, blood pressure (BP), temperature, and air supply allows supervisors to determine when a firefighter needs to be removed for his or her own safety. In the event of an emergency, location data would allow for efficient rescue.
  • Foot Pursuit — During a foot pursuit, supervisors and dispatchers could simultaneously monitor a law enforcement officer’s location and heart rate via a system of sensors to accurately deploy backup units or provide medical attention for the officer, if needed.
  • Hazardous Material Incident — During a hazardous materials response, emergency responders operate in immediate dangerous-to-life and -health environments while wearing chemical protective clothing that adds significant stress to the responder. Their attire limits movement and situational awareness, as well as increases heat. Access to internal and external cameras, biometrics, chemical metering devices, and nearby unmanned devices are used to address these incidents.
  • Other — Emergency responders in many other situations, including traffic stops, active shooter incidents, wild fire fighting, and day-to-day custodial responsibilities, to name a few, would benefit from remote monitoring of various on-body sensors for overall safety and awareness.

1.2 Objectives

The desired dashboard solution will address the issues listed in the problem statement and assist with monitoring and tracking the health and safety of emergency responders. A mobile application should be developed, including appropriate datasets, sensors, consolidation of data, and other UI/UX elements to demonstrate a solution relevant to the problem statements and use cases.

Note: While the desired solution would connect across the FirstNet cellular LTE or a similar network, participants should not assume availability of LTE coverage and should be prepared for sensors connected via a mesh network, Wi-Fi, or other capability.

1.3 Resources

  1. Examples of current biometric sensors and public safety sensors used today
  2. Examples of proprietary systems that exist today
  3. Example datasets that are available in the public domain for the participants to use or refer to if/as needed.

Sensors

Here is a list of known sensors that are in use or potentially in use by emergency responders today:

  • Body-worn video cameras (multiple manufacturers like Axon)
  • Scott Safety Self-Contained Breathing Apparatus (SCBA) monitors
  • PASS (Personal Alert Safety System) for Firefighters
  • Aernos sensors (detect 13 different kinds of hazardous gases) PID — gas meters and monitors; radiation monitors
  • Thermal imaging cameras (plus night vision, etc.)
  • Kestral weather stations and other temperature/weather monitors (e.g., temperature, wind speed, barometric pressure, humidity)
  • Personal Biometric devices
  • Radiation monitors (Ludlum)
  • Other gas monitors non-VOCs metered by a PID — LEL, CO, O2, H2S, CL2, NH3, etc. (e.g., MSA, Draeger)
  • Night vision cameras
  • Apparatus network or sensor feeds, such as pump pressure output and air pressure (e.g., Pierce, IDEX)
  • Access to remote data streams
  • Sensors from companies including Bullard, Drager, ESRI, FLIR, and FireHUD

Datasets

Here is a list of known sensors which are in use or potentially in use by emergency responders today:

[1]https://www.usfa.fema.gov/data/statistics/ff_fatality_reports.html

[2]https://www.odmp.org/profile/login?referral=https%3A%2F%2Fwww.odmp.org%2Fstatistics

2. Evaluation criteria

Participants must adhere to the basic application requirements listed below. Failure to do so may result in non-grading of the application.

2. EVALUATION CRITERIA

Criteria #0: Basic Requirements

Rating: Pass/Fail

  • Item 1 (Pass/Fail) — Application’s ability to display or communicate the responder’s location(s)
  • Item 2 (Pass/Fail) — Participant’s submission can be effectively deployed for use with a tablet computer or smartphone as the user’s device
  • Item 3 (Pass/Fail) — Application’s ability to display outputs from at least one sensor

Criteria #1: Sensor Identification

Rating: 20/100

  • Application’s ability to identify and display data from at least one health and wellness sensor and/or environmental data and/or hazardous material data and/or emergency responder equipment data usable by emergency responders

Criteria #2: Data Aggregation

Rating: 20/100

  • Application’s ability to appropriately identify relevant data from multiple different sensors belonging to a single emergency responder and/or attached to multiple emergency responders and determine how to aggregate relevant data to provide assessment of emergency responder health and operations

Criteria #3: User Interface (UI)

Rating: 20/100

Application’s user interface, design, and capabilities relevant to the use cases for a user to see and interact with sensor data from emergency responders on an incident

Criteria #4: Configurable Thresholds, Alerting

Rating: 20/100

  • Provide a proactive alerting functionality within the application when sensor data indicates an unhealthy situation for an emergency responder.
  • Allow application user to set trigger thresholds for incoming data via an interactive dashboard.
  • Allow for responder evacuation alerting, which means a high priority audible, haptic, and/or video alert sent to any connected device which can receive it.

Criteria #5: SDK/API

Rating: 20/100

  • Provide an SDK that integrates data from selected relevant sensors. This SDK/API would allow the data collected on a tablet computer to be sent to other applications on the device or on remote servers. These applications might be a records management system, computer-aided dispatch system, or a similar application.

3. EXPECTED DELIVERABLES FROM PARTICIPANTS

Review the How to Participate instructions in section 3 of this document to ensure that you are prepared for the in-person Regional Codeathon or Online Contest. The following deliverables will need to be included with the submission:

  1. A completed submission form through www.techtoprotectchallenge.org
  2. Mobile friendly application with the following minimum functionality:
    1. Provide the ability to configure emergency responder sensors and sensor networks if and as needed
    2. Integrate emergency responder biometric health and wellness data with data from specialized sensors and other sources (e.g., air tank supply monitors, hazardous materials sensors, weather stations, body worn cameras, thermal imaging cameras)
    3. Provide a dashboard with real-time location-based information (processed data) regarding current location and health status of the emergency responder in a given emergency event
    4. Provide configurable alarms with visuals on dashboard when sensor information determines signs of risk to emergency responder safety and health.
  3. Any available files or links to the developed solution or prototype.
  4. A 3-minute narrated PowerPoint file or 3-minute narrated video with the following sections:
    1. A summary of the submission.
    2. Basic information about the participant or participant’s team.
    3. Specific requirements of the contest that are being addressed by the participants.
    4. Two to four screenshots of the solutions or prototype.
    5. Overview of key functions included in the submission.
  5.  Documentation of the solution including:
    1. High-level roadmap to commercialization of the solution and an SDK (if applicable).
    2. Challenges to commercialization.
  6. Brief report of the contest experience of the participants.

Any additional files based on the contest description.

Tech To Protect
Rules & Guidelines