NFPA TECHNICAL COMMITTEE for Data Exchange for the Fire Service

NFPA TECHNICAL COMMITTEE FOR

Data Exchange for the Fire Service

Orlando, FL January 28 – February 1, 2019 Agenda

1. Call to order at 4pm

2. Introductions

3. Opening remarks - Chair, Ed Plaugher

4. Review and approval of minutes from previous meeting

5. NFPA Staff Liaison report - Chris Farrell

6. Presentations

a. Andrew Bailey, Data manager, National Interagency Fire Center: Data Exchange in Wildland Fire:

IRWIN and beyond

b. Cory Hohs, CEO, HAAS Alert: Fire Department Collision Avoidance and Related Data Standards

c. Matt Hinds-Aldrich, NFPA staff: Recap of data efforts at NFPA

7. Review public comments for NFPA 950

8. Review public inputs for NFPA 951

9. New business

10. Old business

11. Other items

12. Next meeting

13. Adjourn

NFPA TECHNICAL COMMITTEE FOR

Data Exchange for the Fire Service

Raleigh, NC First Draft Meeting March 21-23, 2018 May 8, 2018 and May 29, 2018 Continuation Meeting Minutes

1. Call to order at 0800

2. Introductions

TC members Andrew Bailey Christopher Carver Ron Corona Matthew Darley Jason Dolf Vern Elliott Tyler Garner Jeffrey Hartberger Vickie Hodges Kevin Kuntz Louis LaVecchia Crystal McDuffie Thomas O'Toole Roshelle Pederson Ed Plaugher Kenneth Pravetz Mike Price Paul Siebert James Smalley Chris Tubbs

Guests Gus Delgado Peter Hallenbeck Matthew Hinds-Aldrich Cory Hohs Timothy Kepler Clarence Potter Steven Roberts Dan Walton

3. Opening remarks - Chair, Ed Plaugher

4. Review and approval of minutes from previous meeting

5. NFPA Staff Liaison report - Chris Farrell

6. Created First Revisions to NFPA 950

7. New business

a. Discuss 950 and 951 going forward

8. Old business

9. Other items

10. Next meeting

a. Continuation meeting to complete work of the Committee

11. Adjourn, NLT 12:00 pm local time, Friday, March 23rd

1/10/2019 National Fire Protection Association Report

Public Comment No. 3-NFPA 950-2018 [ Global Input ]

In 6.7.1 the standard discusses CAD but makes no reference to APCO or NEMA but both of these organizations are listed in Annex B. From what I can see any ogranizational standard tied to data is listed in both the document and the annexes except for these two.

Statement of Problem and Substantiation for Public Comment

My recommendation would standardize the usage of data standardization organizations in the area of CAD. Related Item • 6.7.1 and the annexes

Submitter Information Verification

Submitter Full Name: Jeff Alberts Organization: Savannah Fire Department Street Address: City: State: Zip: Submittal Date: Wed Sep 12 09:04:31 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 1/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 6-NFPA 950-2018 [ Section No. 2.3.2 ]

2.3.2 U.S. Government Publications. U.S. Government Publishing Office, 732 North Capitol Street, NW, Washington, DC 20401-0001. National Fire Information Record Incident Reporting System (NFIRS), version 5.0, January 1999. Standard for Symbology, Homeland Security Working Group, Federal Geographic Data Committee, July 2012. Topographic Mapping Standard for Symbology, U.S. Geological Survey, U.S. Department of the Interior. United States National Grid Standard FGDC-STD-011-2001. Federal Geographic Data Committee (FGDC), United States Thoroughfare, Landmark, and Postal Address Data Standard (DRAFT), 2011.

Statement of Problem and Substantiation for Public Comment

The proposed text describes the incorrect name for NFIRS. It should be the National Fire Incident Reporting System not the National Fire Information Record System. Related Item • www.usfa.fema.gov/data/NFIRS

Submitter Information Verification

Submitter Full Name: Marion Long Organization: US Fire Administration Affiliation: Federal Government Street Address: City: State: Zip: Submittal Date: Thu Oct 04 11:37:45 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 2/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 8-NFPA 950-2018 [ Section No. 6.2 ]

6.2 Coordination and Data Sharing. The exchange of nongeospatial data shall conform to Extensible Markup Language (XML) as defined in ISO 8879 or JavaScript Object Notation (JSON) as defined in ISO/IEC 21778 for or Extensible Markup Language (XML) as defined in ISO 8879 for the transfer of nonspatial data elements. The exchange of geospatial data shall conform to requirements of Geographic Markup Language (GML) as defined in ISO 19136 or Geospatial JavaScript Object Notation (GeoJSON) as defined in RFC 7946. The primary language shall be JSON/ GeoJSON and the secondary choice of XML/GML for use with larger more robust data sets.

Statement of Problem and Substantiation for Public Comment

The purpose in this recommended changes is to establish priority to the language choices. This priority will help to maintain the most efficient and highest speed of delivery of the data sets. Larger sets of data like video, spectra and other multilayered data sets may be too large and cumbersome to use JSON/ GeoJSON, so XML/GML would be the better choice language for those. If left as an open option between the two, manufactures will make the choice and we will continue to not have a true standard to work with. By establishing this standard and the priority language will enable the most efficient potential, interoperability and creating a common operating picture for the end user.

Related Public Comments for This Document

Related Comment Relationship Public Comment No. 9-NFPA 950-2018 [New Section after A.6.1] Related Item • FR & CI

Submitter Information Verification

Submitter Full Name: Peter Jensen Organization: Ventura County Fire Department Affiliation: IAFC Hazardous Materials Response Committee Street Address: City: State: Zip: Submittal Date: Fri Oct 26 14:58:03 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 3/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 14-NFPA 950-2018 [ Section No. 6.4.5.3 ]

6.4.5.3 Attributes shall exist that support the labeling of point features by latitude and longitude. 6.4.5.3.1 The latitude and longitude label attribute shall be depicted as absolute (unprojected) coordinates referenced to the North American Datum of 1983 (NAD83). 6.4.5.3.2* The latitude and longitude label attribute shall be depicted as decimal degrees. in the appropriate format (Decimal Degrees, Degrees Minutes, or Degrees Minutes Seconds) as determined by the AHJ. 6.4.5.3.3 A negative sign, or appropriate alphanumeric designator: W or S, shall be used for west longitude and south latitude, as determined by the AHJ . The absence of a negative sign, or appropriate alphanumeric designator: E or N, shall be used for east longitude and north latitude, as determined by the AHJ 6.4.5.3.4 The latitude and longitude label attribute shall be expressed to a precision and accuracy no greater than that at which the data were collected, acquired, or calculated.

Statement of Problem and Substantiation for Public Comment

Comments: This standard change moves from the realm of data exchange to the realm of user interface design and is out of character with our previous committee work. Additionally, Wildland fire, particularly in applications dealing with aviation resources, are bound by the standards of map use for aviation. Aviation maps and location references commonly use Degrees Decimal Minutes, expressed as DD MM.MMM N/W (example 34 23.543 N, 112 34.546 W). Other systems, such as the NOTAM (Notice To Airmen), require locations in Degrees, Minutes, Seconds. We should not, as a standards body focused on interoperability, recommend a display/UI change to decimal degrees without buy-in from all parts of our business, and in researching, have not found decimal degrees to be an industry best practice for display. It would work as a data exchange standard, but this section specifically refers to label attributes. The labeling format must be audience-specific. Related Item • Related to Latitude/Longitude labeling formats

Submitter Information Verification

Submitter Full Andrew Bailey Name: Organization: US Department of Interior National Wildfire Coordinating Group, Data Management Affiliation: Committee Street Address: City: State: Zip: Submittal Date: Thu Nov 15 12:02:41 EST 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 4/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 10-NFPA 950-2018 [ Section No. 6.4.5.3.2 ]

6.4.5.3.2* The latitude and longitude label attribute shall be depicted as degrees, minutes, decimal minutes (DDD-MM.mm) to conform with DHS endorsed national standards. If required, use up to 2 digits to the right of the decimal. If required, allow 3 digits in the degrees field for longitude (i .e., DDD-MM.mm). Do not use leading zeros to the left of the decimal for degrees or minutes that require fewer than the maximum number of possible digits to express their value. The minimum number of digits is always one, even if it is a zero. (Example: Recommended: 9-0.3N 4-2.45W; Not recommended: 09-00.300N 004-02.45W).

Statement of Problem and Substantiation for Public Comment

Wording as offered has been endorsed by seven federal departments and agencies through the National Search and Rescue Committee as a way to eliminate confusion about the multiple forms of latitude and longitude. See page 165 of http://www.mngeo.state.mn.us/committee/emprep/download/USNG/2011_1118_Published_Land_SAR_Addendum_1.0.pdf as an example. Without setting a conforming standard for latitude longitude in this document, data systems and field use will continue to develop in irregular fashion and be detrimental to the overall health of the fire service and those it protects. Related Item • PI per NFPA 950

Submitter Information Verification

Submitter Full Name: Stephen Swazee Organization: SharedGeo Affiliation: SharedGeo Street Address: City: State: Zip: Submittal Date: Thu Nov 01 12:03:01 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 5/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 15-NFPA 950-2018 [ Section No. 7.3.2 ]

7.3.2 Time shall be referenced in local UTC time.

Additional Proposed Changes

File Name Description Approved Integration_Specification_-_Incident_API_V5_Final20180416.pdf

Statement of Problem and Substantiation for Public Comment

Storing time in local time is inconsistent with best practices we have discovered while doing data integration within wildland fire. With the IRWIN project, we have found that using UTC time for data exchange facilitates both human and machine interpretation of the data far more effectively than storing and exchanging local times with UTC offset. Interpreting time zone offsets, particularly with regards to daylight savings time, is extremely difficult for human users. Recommend establishing UTC as your standard reference point, and having sending/consuming systems translate as appropriate based on location. Related Item • For public comments on storage and exchange of time values.

Submitter Information Verification

Submitter Full Andrew Bailey Name: Organization: US Department of Interior National Wildfire Coordinating Group - Data Management Affiliation: Committee Street Address: City: State: Zip: Submittal Date: Thu Nov 15 12:20:25 EST 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 6/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 5-NFPA 950-2018 [ New Section after 8.2.2 ]

8.2.3 Software shall provide an API or other standardized means capable of sending and receiving data in order to connect discrete software systems.

Statement of Problem and Substantiation for Public Comment

I believe that a section calling out the API requirements should be added to section 8.2 for general requirements instead of being repeated for each discrete set of software. Related Item • None

Submitter Information Verification

Submitter Full Name: Dan Curran Organization: City of Rochester Fire Department Street Address: City: State: Zip: Submittal Date: Wed Sep 12 14:53:46 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 7/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 16-NFPA 950-2018 [ Section No. 8.6 ]

8.6 Incident Command and Situational Awareness Software Applications. 8.6.1 Software intended for the management of fire and emergency service incident command and situational awareness data shall also meet the requirements of Section 8.2. 8.6.2 Incident Command Software Applications. 8.6.2.1 Software intended for the management of incident command data shall provide a graphic user interface that allows users to manipulate the location of units, assign tasks, and task personnel, as specified by the AHJ. 8.6.2.2 Incident command software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect to discrete software systems. 8.6.3 Responder Notification/Alerting Software Applications. 8.6.3.1 Software intended for the management of responder notification data shall be capable of sending an emergency alert within a time threshold agreed by the AHJ. 8.6.3.2 Responder notification software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect discrete software systems. 8.6.4 Pre-Incident Planning Software Applications. 8.6.4.1 Software intended for the management of fire and emergency service pre-incident planning data shall be provided with a map-based graphical user interface capability for the documentation of the location of means of ingress and egress, fire protection systems, life safety systems, utilities, stairwells, hazardous materials storage, known life safety hazards, and other features as specified by the AHJ. 8.6.4.2 Pre-incident planning software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect discrete software systems.

Statement of Problem and Substantiation for Public Comment

The section is overly broad and the intent seems out of line with the rest of the standard - this reads like material better suited for the guide than the standards. Data excahnge and development may be improved with the sections that include language regarding data exchange (interfacing with APIs) where the exchange mechanism is well documented. Language that specifies user interface items, as these are no longer dealing with data exchange in the fire service, but specify features that should be considered in the acquisition of software rather than mandated by a standard. See 8.6.2.1 as an example, but there are others. Related Item • Related to the entirety of section 8.6

Submitter Information Verification

Submitter Full Andrew Bailey Name: Organization: US Department of Interior Affiliation: National Wildfire Coordinating Group - Data Management https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 8/21 1/10/2019 National Fire Protection Association Report

Committee Street Address: City: State: Zip: Submittal Date: Thu Nov 15 13:45:04 EST 2018 Committee: DAT-AAA

Public Comment No. 11-NFPA 950-2018 [ Section No. 8.8.2.3 ]

8.8.2.3 Software intended for the management of inspection records data shall identify, flag and flag transfer violations that are due for reinspection to the AHJ to ensure the violations have been corrected.

Statement of Problem and Substantiation for Public Comment

The revision to this section would require action on the part of the software to transfer the data to the AHJ for enforcement. Related Item • First Draft Report

Submitter Information Verification

Submitter Full Name: Jeffrey Hugo Organization: National Fire Sprinkler Associ Affiliation: NFSA Street Address: City: State: Zip: Submittal Date: Wed Nov 14 13:10:44 EST 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 9/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 12-NFPA 950-2018 [ New Section after 8.8.4.2 ]

8.8.4.2.1 Fire protection and life safety systems permit information shall be interconnected with the inspection records management system. 8.8.8.2.1 Fire protection and life safety systems permit information shall be interconnected with the inspection records management system.

Statement of Problem and Substantiation for Public Comment

This comment is attempting to tie the permit information to the inspection records management system. For example, the plan review identifies or verifies the information on the permit, such as type of system, number of systems, number of sprinklers in the building, hazard, etc. This information should be transferred or correlated to the ITM side to provide consistency of ITM annual reporting and enforcement. This allows the new work permit side (typically the building dept) to communicate the information to the fire prevention side (fire department) and gives the ability to track missed reports, changes in systems, and verify permitted versus work done without permits. Related Item • First Draft Report

Submitter Information Verification

Submitter Full Name: Jeffrey Hugo Organization: National Fire Sprinkler Associ Affiliation: NFSA Street Address: City: State: Zip: Submittal Date: Wed Nov 14 13:37:29 EST 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 10/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 4-NFPA 950-2018 [ Section No. 8.8.7.4 ]

8.8.7.4 Public education and outreach software shall be provided with an ( API or other standardized means capable of sending and receiving data in order to connect discrete software systems.

Statement of Problem and Substantiation for Public Comment

Typographical error. Related Item • First Draft Report

Submitter Information Verification

Submitter Full Name: Dan Curran Organization: City of Rochester Fire Department Street Address: City: State: Zip: Submittal Date: Wed Sep 12 14:47:51 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 11/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 13-NFPA 950-2018 [ Section No. 8.11.3 ]

8.11.3 Inspection, Testing, and Maintenance Notification Software Applications. 8.11.3.1 Software intended for the management of inspection, testing, and maintenance (ITM) data shall identify properties with unresolved deficiencies, violations, and errors within a timeframe specified by the AHJ. 8.11.3.2 ITM notification software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect discrete software systems.

Statement of Problem and Substantiation for Public Comment

Recommend removing entire 8.11.3 section as including it would require current third party reporting solutions to meet all other chapters of this standard increasing costs to AHJ's, Building Owners, constituents and fire protection service providers. Multiple association committees (e.g. NFSA/AFAA, SFPE) are currently meeting and discussing possibility of new standard specifically for third party ITM services seperate to NFPA 950. Related Item • FR 28

Submitter Information Verification

Submitter Full Name: Dwight Wills Organization: BuildingReports Street Address: City: State: Zip: Submittal Date: Wed Nov 14 16:13:23 EST 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 12/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 1-NFPA 950-2018 [ Section No. 8.12 ]

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 13/21 1/10/2019 National Fire Protection Association Report

8.12 Digital Alert Warning Systems. 8.12.1 Data specification shall at minimum include the following open data parameters for any Digital Alert Warning System 8.12.1.1 The DAWS shall be capable of sending out the data shown in Table (8.12.1.8) below at least once per every two (2) seconds while the master optical warning switch is on. 8.12.1.2 The DAWS must transfer data over a cloud, edge, or short-range direct service. 8.12.1.3 The DAWS data shall be encrypted at rest and in transit. 8.12.1.4 The service shall be capable of alerting motorists as well as other emergency vehicles with no longer than a five (5) second delay from receipt of DAWS data. 8.12.1.5 The DAWS service shall be capable of alerting motorists as well as other emergency vehicles within a minimum of (1) mile of the DAWS location. 8.12.1.6 The DAWS shall have the ability to be deactivated by personnel. 8.12.1.7 The DAWS data can be an after-market product or a byproduct of existing apparatus technology. 8.12.1.8 Table (Y) Data: ID* – unique identifier of the apparatus Timestamp* - Conforms to ISO 8601 extended format ([YYYY]-[MM]-[DD]T[hh]:[mm]:[ss.ff][TZD]) Latitude* – Conforms to ISO 6709 ±DDD.D format Longitude* – Conforms to ISO 6709 ±DDD.D format Altitude – in meters above (>0) or below (<0) sea level Accuracy – xx meters Speed* - xx meters / sec Heading* – degrees, where 0/360 = North, 90 = East, 180 = South, and 270 = West Run ID* – unique identifier associating 2 or more DAWS data points with each other Master optical warning device switch* – Boolean “true” / “false”, where “true” = on * = required 8.12.2 Responder-to-Vehicle Citizen Motorist Alerts. 8.12. 1.1 Software 2.1 Software intended for the management of responder-to-vehicle citizen motorist alerts shall utilize universal parameters for sharing and meet the requirements of Section 8.2 . 8.12. 1.2 Responder 3.2 Responder -to-vehicle citizen motorist alerts software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect discrete software systems. 8.12. 2 Responder 3 Responder -to-Responder Apparatus Alerts. 8.12. 2.1 Software 3.1 Software intended for the management of responder-to-responder apparatus alerts shall utilize universal parameters for sharing and meet the requirements of Section 8.2 . 8.12. 2 3 . 2 2 Responder-to-responder apparatus alerts software shall be provided with an API or other standardized means capable of sending and receiving data in order to connect discrete software https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 14/21 1/10/2019 National Fire Protection Association Report

systems.

Statement of Problem and Substantiation for Public Comment

Reasons for Open Standard for all Providers of Digital Alert Warning Systems: The industry is already seeing proprietary solutions creep into the market which will not allow R2R and R2V technologies to work together – this means for mixed fleets and R2R across Police/Fire/EMS/and other rapid response vehicles – they will not be able to communicate. This becomes challenging for first responders and cities across the board as they look to provide R2V and R2R solutions for safer driving in their fleets. The proprietary technical solutions should not be in the communication of the vehicles and the dataset, but in the product that is developed that utilizes that communication.

The death and injury rate for collisions is only rising. With this technology available now to any fleet in any industry with multiple solution providers, it is distracting for fire departments and municipalities looking to pick a product that can have hidden proprietary data formats in which the fire department is unable to utilize a DAWS system with other vehicles in their fleet and with neighboring fleets.

The data format is common industry practice and mimics the VDR standards which are already common place in every vehicle. For the 950 committee, it’s important to lead on making the basic parameters required and not optional as if data formats are optional, it only hurts the departments when a DAWS solution is implemented.

For background on R2R and R2V, please see below for additional reading:

Background and Problem: Emergency service vehicle incidents (ESVIs), including crashes and first responders being struck by vehicles, are the second leading cause of US firefighter fatalities, accounting for over 400 deaths since 1994 (Fahy et al., 2017). The highest death and injury rate for First Responders combined is traffic collisions. Nineteen firefighters died in ESVIs in 2016 alone, comprising 28% of on-duty firefighter fatalities (USFA, 2017). Furthermore, a large proportion of ESVIs involve civilian vehicles and in these cases civilians are at significantly greater risk for fatality than firefighters (Donoughe et al., 2012; Fahy, 2008). Between 2011 and 2015, the National Highway Traffic Safety Administration (NHTSA) reported that civilians accounted for over 73% of the fatalities in ESVIs (NHTSA, 2017a). Responder-to-responder (R2R) ESVIs, although less frequent, are especially dangerous given the speeds and sizes of the vehicles involved. Working on roadside incidents also remains a major safety concern for first responders. From 1996 to 2010, over a fifth (22%) of first responder ESVI fatalities were caused by road-side struck-by incidents (USFA, 2012).

This problem isn’t new, FAMA has supported previous safe driving studies through the Arizona Safety FEMA work as first responders have always been at risk traveling to a scene. Often times those scenes are also in the midst of hazardous roadways. Distracted and negligent drivers create persistent danger.

As if navigating the chaos of cities, congestion and traffic to arrive safely and quickly on-scene weren't enough, responders are then expected to perform and assist each other to the highest degree. Strict protocols even dictate strategic placement of vehicles and personnel when operating in dangerous roadway conditions. Responders should not have to fear other motorists colliding with them, whether en route or stationary on-scene in equally dangerous situations also known as “secondary incidents” or the “wake effect.” Drivers are becoming increasingly more distracted by technology and the proliferation of vehicle in-dash or infotainment systems. 75% of all vehicles will be connected by 2020, autonomous vehicles are already being deployed in cities around the U.S. and elsewhere, and auto makers are actually trying to make car cabins sound-insulated to provide a “nicer” ride for the driver. All of these issues contribute to more danger for our first responders who serve and protect.

When looking at technology available on fire apparatus, there are only 2 ways to notify motorists: lights and sirens. There is a gap in the availability of an alert mechanism to “digitally alert” drivers in the roadway – this has been a long standing issue in the emergency response industry. The key to the technology is in knowing not just where first responders are in real-time, but more importantly, when they are actually in "code 3" or "emergency" mode with emergency lights turned on in real-time. By proposing a standard, this proposed solution will offset the gap in “on-apparatus” technology so that the responders when dispatched are capable of (1) generating the needed alert from the apparatus when the emergency lights are activated (2) making sure that the digital alert reaches a motorist in time to notify them (3) making sure a digital alert reaches another first responder vehicle (for Responder-to-Responder communication). https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 15/21 1/10/2019 National Fire Protection Association Report

As this technology is available already today and being added to the apparatus, what is not being proposed is how to implement, what technology to use, and where the alerts are sent to. Keeping these topics out of the discussion leaves room for multiple solutions with varying technologies and the ability to send the alerts through whichever alert software provider one chooses.

FAMA has supported other Connected Vehicle FEMA work opportunities that support this safety along with others in the industry.

Quick Facts on DAWS: Average install time per apparatus for any provider's solution? 20 minutes Average apparatus additional cost for any provider's solution? $100 Average size of any provider's solution? Roughly a cellular phone or similar

Additional Comments: To keep it short, I only provided the basic information. Would be happy to come and present more details on a DAWS requirement along with industry experts in this area.

Sources: Fahy, R. F., LeBlanc, P. R., & Molis, J. L. (2017). Firefighter Fatalites in the United States-2016. Retrieved from Quincy, MA: United States Fire Administration. (2017). Firefighter Fatalities in the United States in 2016. Retrieved from https://www.usfa.fema.gov/downloads/pdf/publications /ff_fat16.pdf Donoughe, K., Whitestone, J., & Gabler, H. C. (2012). Analysis of firetruck crashes and associated firefighter injuries in the United States. Annals of advances in automotive medicine / Annual Scientific Conference ... Association for the Advancement of Automotive Medicine. Association for the Advancement of Automotive Medicine. Scientific Conference, 56, 69-76. National Highway Traffic Safety Administration (NHTSA) (2017a). Traffic Safety Facts 2015 (DOT HS# 812384). Retrieved from https://crashstats.nhtsa.dot.gov/Api/Public/Publication/812384: United States Fire Administration. (2012). Traffic Incident Management Systems. Retrieved from https://www.usfa.fema.gov/downloads/pdf/publications/fa_330.pdf Related Item • In NFPA951 there is an additional public comment submitted with this addition

Submitter Information Verification

Submitter Full Name: Cory Hohs Organization: HAAS Alert Street Address: City: State: Zip: Submittal Date: Thu Sep 06 12:05:44 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 16/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 7-NFPA 950-2018 [ Section No. A.4.4.2 ]

A.4.4.2 Examples of applications and systems requiring the exchange of data include records management systems interfacing with National Fire Information Incident Reporting Systems System and the National Emergency Medical Services Information System. These should support the requirements established herein or as also modified locally.

Statement of Problem and Substantiation for Public Comment

Submitter Information Verification

Submitter Full Name: Marion Long Organization: US Fire Administration Affiliation: Federal Government Street Address: City: State: Zip: Submittal Date: Thu Oct 04 11:42:49 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 17/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 9-NFPA 950-2018 [ New Section after A.6.1 ]

A.6.2 The choice of JSON/ GeoJSON as the primary language is to ensure that the data is being transfered and received in the most efficient and standardized format. The XML/ GML language format is a more cumbersome and robust language wich would enable the transfer of larger packets of data. An example is to consider that data trasfered using JSON/ GeoJSON would be like using e-mail, very fast and the potential to send continuous and semi-continuous data streams. If a larger package of data like a video or spectra needs to be sent then it would be sent using a "snail" mail or package delivery service i.e XML/GML. A JSON/GeoJSON message would be sent to tell the receiver to go to the post office/ location to pick up the package. There is a need for both languages but direction needs to be given to keep the important small packets of data transfering at the highest possible speed and not bogged down by packaging them in larger packets.

Additional Proposed Changes

File Name Description Approved 2018-08- IAFC White Paper on Data Standardization for 16_Hazmat_Data_Standards_White_Paper- Hazardous Materials Responses _V4_-_FINAL.docx

Statement of Problem and Substantiation for Public Comment

This gives a more detailed explanation on why JSON/GeoJSON was chosen as the primary language. The example is an attempt to put the explanation into laymen's terms for better understanding and clarity.

Related Public Comments for This Document

Related Comment Relationship Public Comment No. 8-NFPA 950-2018 [Section No. 6.2] Supporting explanation Related Item • FR & CI

Submitter Information Verification

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 18/21 International Association of Fire Chiefs

White Paper on Data Standardization for Hazardous Materials Response

Executive Summary

Over the past several years, the landscape of the “smart emergency responder” has been defined and priorities have been identified1 in support of a common operating picture (COP). A common theme across the broad studies has been the need for standardization in the data formats driving both system compatibility and interoperability. The goal of this strategy is to define a road map of how the International Association of Fire Chiefs (IAFC) and its partners will implement a standardized approach to data transmission from multiple types of sensors capturing both discrete and continuous data streams in a hazardous materials environment. The standardization of data transmission will allow for the advancement of data ingest products capable of digesting the large amounts of data and displaying it in operationally relevant context.

Hazardous materials teams utilize a variety of sensors ranging from weather “Knowledge is power data to physiological data to cameras to chemical sensor systems and and harvesting the data others. The sensors are based upon both discrete and continuous measures. important to fire This data, when combined, paints a picture of the operational environment fighters is empowering which is vital to incident analysis and critical decision-making efforts. the smart fire fighter of Currently, data is generally displayed on a proprietary display inherent to the future.”1 the device. Many products also incorporate wireless systems within their product lines but often include a proprietary display software to make the data usable. The current trend for most manufacturers is the display of the data on the instrument screen but also allowing for an output jack or data broadcast in an independent format. This approach challenges the development of software data interpretation tools and displays to assist the command element in making informed decisions based on the data The data could be displayed, mapped, input into forms, tracked, and analyzed.

The need for wireless receiving and processing of data is growing rapidly. It is not practical nor operationally suitable for a hazardous materials team to have separate computer-based receiver and display points for each manufacturer or sensor product. In addition, the “Give responders the procurement of separate “translator” hardware and software is an right information at the inefficient use of funds. right time to make the hard decisions to keep The proposed establishment of JavaScript Object Notation (JSON) as the our communities safe, standard output language for all sensors intended for use in the hazardous while not interrupting materials community will allow the end user to access data output from all their mission wireless-enabled detectors operating at an incident. This will allow for the response.”2 development of data analysis tools unfettered by data format incompatibilities to assist in the interpretation and visualization of the data thereby increasing the operational utility of the instrumentation and the safety of the community and the first responders by making operationally relevant data available to command staff quickly and efficiently.

Key Findings

The International Association of Fire Chief’s (IAFC) Hazardous Materials Committees hosted a discussion open to all vendors and manufacturers of hazardous materials related instrumentation equipment, broadcast infrastructure, and receiving/processing software. Meetings were held between March and June of 2018 in San Diego (CA), College Station (TX), and Baltimore (MD). The goal of the meetings was to agree upon a standard data output language to be used industry-wide. The consensus of the participants was to move forward with JavaScript Object Notation (JSON) as the standard output language. JSON is a lightweight, compressible data-interchange format.

“Responders are overburdened with data and devices, so throwing more technologies at the problem does more harm than good. Instead, responders need smarter, seamless technologies that increase their ability to focus on the mission, rather than distract from it.”2

JSON and Extensible Markup Language (XML) are the two most common formats for data interchange used today. The Open Geospatial Consortium (OGC) has a best practices document on JSON Encoding Rules that are available for simple conversions between XML and JSON representations. JSON is a text syntax that facilitates structured data interchange between all programming languages. XML is more suited towards the inclusion of metadata-heavy information. JSON uses less resources and is much faster than XML. As sensors and sensing systems become smaller and more mobile, and therefore have less on- board computing power, JSON will be preferable.

Recommendation

The IAFC recommends this data standard for the efficient acquisition, management, and dissemination of sensor data for use in a hazardous materials response environment. Specific recommendations include:

1. JSON will be the approved language for sensor data transmission. 2. All sensors shall have the ability to transfer data using the JSON format. 3. Data that is actionable shall be accepted by telemetry.

For advanced analytical instrument where spectral information or imagery is captured, a simple data set may be transmitted via JSON format with full spectral or imagery information available for direct analysis later. These larger data sets should be linked and available for transmission and processing in an efficient, non-proprietary format (i.e., XML, cloud transfer, others).

Implementation Strategy

The IAFC Hazardous Materials Committee will work with hazardous materials teams, instrument manufacturers, software developers, and others to develop an implementation strategy that is scalable and accessible to all.

Timeline Department Manufacturer/ Standards Implementation Developer Coordination Expectations Goal 1: 18 months Request JSON language JSON available as an Provide public input Pilot be available on new option on devices. to NFPA 950, and devices as an objective specifically section Refine requirement. 5.3.3 Data Exchange recommending JSON language. Goal 2: 36 months Require JSON language JSON required as Implementation of Scale be available on new standard data JSON into NFPA 950 as Up devices as a threshold exchange language on a recommended best requirement. devices. practice. Goal 3: 48 months Full implementation of the JSON language standard across the board from Review sensor to processing software to data analytics and COP displays. and Refine

As with any technical solution, it is critical that the standards are evaluated periodically to ensure that the standard is not surpassed by new technologies. It is recommended that a meeting is held every five (5) years amongst practitioners, developers, and vendors to ensure that the strategy is working. This meeting should precede the next NFPA 950 standards cycle to allow for timely input to that document as technological changes occur.

Future expansion and use of the data produced from these sensors and devices will need continued guidance from the hazmat community and the fire service leadership to create usable platforms and displays of the data. It is further recommended that working groups be established representing the hazmat response community to give input to the development of software and hardware to best serve the response community with the imagination and forethought into the future and potential needs. The establishment of a standardized output language is only the first step to allow for and enable the future development of a truly common operating platform for hazardous materials incident management. The IAFC’s Hazmat and Technology committees are primed to provide leadership and contributions to these discussions and to influence the appropriate end-user requirements for this type of platform and interface.

References

1Grant, Hamins, Bryner, Jones, and Koepke. Research Roadmap for Smart Fire Fighting. National Institute of Standards and Technology Special Publication 1191, May 2015.

2Next Generation First Responder Integration Handbook, Part 1: Introduction, Version 2.0, February 2018. Department of Homeland Security.

1/10/2019 National Fire Protection Association Report

Public Comment No. 17-NFPA 950-2018 [ Section No. B.2 ]

B.2 APCO ANS 1.116, Public Safety Communications Common Status Codes for Data Exchange, 2014 2015 . This standard provides a standardized list of status codes that can be used by emergency communications and public safety stakeholders when sharing incident-related information. Creating a common status code does not mean that an agency must change the codes they use internally. The intent is to have each agency map their internal codes to the standardized list.

Statement of Problem and Substantiation for Public Comment

Date of standard is incorrect Related Item • B.2 APCO ANS 1.116

Submitter Information Verification

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 19/21 1/10/2019 National Fire Protection Association Report

Public Comment No. 18-NFPA 950-2018 [ Section No. B.5 ]

B.5 APCO/CSAA ANS 2.101, Alarm Monitoring Company to Public Safety Answering Point to Computer Aided Dispatch Automated Secure Alarm Protocol, 2012 2014 . The purpose of the APCO/CSAA ANS 2.101.2-2014, also known as ASAP 3.3, documentation is to provide a standard data exchange for transmitting information using automation between an Alarm Monitoring Company and a PSAP. There are three primary uses for this information exchange package documentation (IEPD): (1) Initial notification of an alarm event by an alarm monitoring company to a PSAP (2) Update of status by the PSAP’s computer-aided dispatch CAD system to the alarm monitoring company as follows:

(3) Alarm Notification Accepted, call-for-service created (4) Alarm Notification Rejected due to invalid alarm location address, invalid event type, alarm notification too old, or other reason(s)

(5) Bidirectional update of other events between an alarm monitoring company and a PSAP, such as the following:

(6) Requests for cancellation by the alarm monitoring company (7) Updates concerning key-holder information by the alarm monitoring company (8) Notice by the PSAP that the primary response agency has been dispatched (9) Notice by the PSAP that the primary response agency has arrived on scene (10) Notice by the PSAP that the event has been closed (with a disposition if applicable) (11) Updates from the PSAP telecommunicator or field resource requesting additional information, such as an estimated time of arrival for the key-holder

Statement of Problem and Substantiation for Public Comment

Date incorrect for standard referenced. Related Item • B5. ASAP

Submitter Information Verification

Submitter Full Andrew Bailey Name: Organization: US Department of Interior National Wildfire Coordination Group - Data Management Affiliation: Committee Street Address: City: State: Zip: Submittal Date: Thu Nov 15 13:54:24 EST 2018 Committee: DAT-AAA https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 20/21 1/10/2019 National Fire Protection Association Report

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 21/21 1/10/2019 National Fire Protection Association Report

Public Input No. 1-NFPA 951-2017 [ Global Input ]

There are already numerous standards in existence or in development governing CAD, RMS, GIS, and Next Generation data systems. Duplicating this information will generate confusion for the industry and public safety in general. Additionally, reference should be made to APCO, NENA, and ATIS existing standards with regard to data exchange for public safety.

Additional Proposed Changes

File Name Description Approved PC_No._5_Hold_for_PI_F2020.pdf 951_PC_No.5

Statement of Problem and Substantiation for Public Input

NOTE: This Public Input appeared as "Reject but Hold" in Public Comment No. 5 of the F2015 Second Draft Report for NFPA 951 and per the Regs. At 4.4.8.3.1.

Substantiation: Ensuring that all applicable standards are referenced will assist agencies with compliance.

Submitter Information Verification

Submitter Full Name: TC On DAT-AAA Organization: NFPA Street Address: City: State: Zip: Submittal Date: Wed May 24 11:36:23 EDT 2017 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 1/6 1/10/2019 National Fire Protection Association Report

Public Input No. 2-NFPA 951-2018 [ Chapter 6 ]

Chapter 6 Data Sharing and Exchange 6.1 Introduction. This chapter sets forth the technical specifications and business rules all fire and emergency service organizations should follow in creating an interoperable data sharing and exchange environment. The technical specifications for acquisition, display, and management are set forth in the previous chapters. This chapter includes a description of the fundamental data components that need to be exchangeable and specifies the format for each of those data components. This in no way limits the AHJ from creating local policies with additional requirements, but for data exchange to be compliant, all components must, at a minimum, be in the formats specified within NFPA 950. 6.2 Addresses. This guide follows the protocols established by the Federal Geographic Data Committee (FGDC) and maintained by the U.S. Census Bureau. This format is most often and easily recognized by geocoding engines. It is readily accepted and recognized by responders and the general public. Addressing in many jurisdictions has traditionally evolved from non-standards- based conventions that do not follow these standards. This often creates challenges for agencies attempting to comply with nationally recognized standards such as NFPA 950. Several approaches exist to resolve these discrepancies. The jurisdiction should adopt a strategy that best fits the data and resource environment within which they operate. The most direct and short-term method for becoming compliant with NFPA 950 is to supplement the street address with a geographic coordinate (in accordance with NFPA 950, USNG, or latitude and longitude). While this will not make an address data NFPA-compliant, it will allow the agency or department to deliver services on time in the right place without a significant change to the jurisdiction’s naming conventions. 6.3 Date and Time. NFPA 950 follows the most commonly recognized protocol currently in use in the United States. The committee recognizes that other date schemas are available and preferred by some agencies. This format is widely recognized by civilian and governmental agencies. 6.3.1 Time Stamp. It is recommended that the time stamp be recorded based on the incipient incident record time reference. 6.3.2 Decimal Time. Decimal time is a universal standard format that allows for numeric computations. 6.3.3 Time Reference. Time is referenced to the local time zone and UTC. The committee acknowledges that storing the date twice is redundant but recognizes the inconsistency of time zone applications across regional boundaries. 6.3.4 Time Calibration. Time calibration is a critical component of all incident record keeping because of the legal implications associated with incident response. As such, calibration provides a legal framework for incident records. 6.4 Incident Typing Information.

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 2/6 1/10/2019 National Fire Protection Association Report

6.4.1 NFPA 950 recognizes the National Fire Incident Reporting System (NFIRS) and the National EMS Information System (NEMSIS) as the standard incident reporting systems currently required by most U.S. states and territories. This framework establishes a transferrable data set and as such meets the intent of NFPA 950. This guide does not imply the use of any particular software for recording incident data. This component of the standards refers only to the typing standards within these frameworks. 6.4.2 The “plus 1” append provides the local jurisdiction with an opportunity to amend data for local use. This gives jurisdictions the ability to review subsets of data for incident analysis. 6.5 Text. ASCII is a universally accepted text standard. Compliance with this protocol will enable ready transfer of text data using all of the standard data exchange methods specified herein. 6.6* CAD, RMS, CAD/CAD, CAD/RMS, and RMS/RMS Exchange. 6.6.1 Design and Construction. Design and construction of CAD/CAD, CAD/RMS, and RMS/RMS interfaces and applications should comply with all technical elements set forth in Chapters 4, 5, and 6 of NFPA 950. The integration of all department systems, including, but not limited to, CAD and RMS, must be considered at the design level. This guidance is intended to be device and software agnostic. Specific to incident response, this establishes the data framework required to support this essential mission element. 6.6.2 Intent. The intent of this language is to emphasize the importance of a seamless flow of data. This will enable appropriate utilization of data assets throughout the organization and into the entire public safety ecosystem. This environment will enhance data accuracy and drive the ability to leverage data resources for data driven decisions, comprehensive situational awareness, and essential communications to all stakeholders in the community. In short, unlocking data assets from proprietary systems and structures will provide the data environment that can support effective management. 6.6.3 Dynamic Technology. NFPA 950 specifically calls out CAD and RMS systems because these are the dominant nomenclature for computer applications currently in use to perform these functions at the time of this writing. NFPA 950 is written with the full understanding of a rapidly changing landscape. The implicit intention of the committee in the writing of NFPA 950 was to set forth a standard that applies any information system designed to aid in the analysis, visualization, and distribution of data intended to support the fire and emergency service organization mission. 6.6.4 Spatial Data Influence. When an emergency occurs, spatial data becomes an important backdrop to the entire sequence of events. From the moment a 911 call is received, an accurate incident location is the one attribute that ties together and sifts through all the other information available to support a successful outcome. When that location is stored in a modern, standards-based, NFPA 950– compliant information system, it provides the foundation to everything else that follows: (1) Call takers can confirm the accurate location of the incident. (2) Station personnel can quickly reference the location. (3) Digital route maps with standard symbology can augment the driver’s situational awareness. (4) Accurate hazard and hydrant locations support the scene size-up. (5) Preplan layouts in scalable formats provide lifesaving detail for search operations and attack strategies. (6) Incident Command assist data.

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 3/6 1/10/2019 National Fire Protection Association Report

6.6.5 Accuracy. Call location, initial incident description, routes, locations of responding vehicles, water sources, exposures, hazards, access, and egress are all crucial, all about geography, and all need to be right. 6.6.6 All location data needs to be accurate, consistent with its intended use. 6.7 Digital Alert Warning Systems. 6.7.1 Data specification shall at minimum include the following open data parameters for any Digital Alert Warning Systems for Responder-to-Vehicle Citizen Motorist Alerts as well as Responder-to-Responder Apparatus Alerts. 6.7.1.1 The DAWS shall be capable of sending out the data shown in Table (6.7.1.8) below at least once per every two (2) seconds while the master optical warning switch is on. 6.7.1.2 The DAWS must transfer data over a cloud, edge, or short-range direct service. 6.7.1.3 The DAWS data shall be encrypted at rest and in transit. 6.7.1.4 The service shall be capable of alerting motorists as well as other emergency vehicles with no longer than a five (5) second delay from receipt of DAWS data. 6.7.1.5 The DAWS service shall be capable of alerting motorists as well as other emergency vehicles within a minimum of (1) mile of the DAWS location. 6.7.1.6 The DAWS shall have the ability to be deactivated by personnel. 6.7.1.7 The DAWS data can be an after-market product or a byproduct of existing apparatus technology. 6.7.1.8 Table (Y) Data: ID* – unique identifier of the apparatus Timestamp* - Conforms to ISO 8601 extended format ([YYYY]-[MM]-[DD]T[hh]:[mm]:[ss.ff] [TZD]) Latitude* – Conforms to ISO 6709 ±DDD.D format Longitude* – Conforms to ISO 6709 ±DDD.D format Altitude – in meters above (>0) or below (<0) sea level Accuracy – xx meters Speed* - xx meters / sec Heading* – degrees, where 0/360 = North, 90 = East, 180 = South, and 270 = West Run ID* – unique identifier associating 2 or more DAWS data points with each other Master optical warning device switch* – Boolean “true” / “false”, where “true” = on * = required

Statement of Problem and Substantiation for Public Input

when a DAWS solution is implemented.

For background on R2R and R2V, please see below for additional reading:

FAMA has supported other Connected Vehicle FEMA work opportunities that support this safety along with others in the industry.

Additional Comments: To keep it short, I only provided the basic information. Would be happy to come and present more https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 5/6 1/10/2019 National Fire Protection Association Report

details on a DAWS requirement along with industry experts in this area.

Submitter Information Verification

Submitter Full Name: Cory Hohs Organization: HAAS Alert Street Address: City: State: Zip: Submittal Date: Thu Sep 06 12:28:29 EDT 2018 Committee: DAT-AAA

https://submittals.nfpa.org/TerraViewWeb/ViewerPage.jsp 6/6