Public Safety Answering Point (PSAP) Emergency Service and Provisioning

Boundaries

Best Practices Document

April 2019

i

TABLE OF CONTENTS

1. Background ............................................................................................................................... 1

2. Purpose ..................................................................................................................................... 2

3. Boundary Descriptions .............................................................................................................. 2

3.1. PSAP Boundary .............................................................................................................................2

3.2. Provisioning Boundary ..................................................................................................................2

3.3. Emergency Service Boundary ........................................................................................................3

4. Schema ..................................................................................................................................... 3

4.1. Data Layer Names..........................................................................................................................3

4.2. Data Layer Attributes ....................................................................................................................4

4.3. PSAP Boundary .............................................................................................................................4

4.4. Emergency Service Boundary ........................................................................................................5

4.5. Provisioning Boundary ..................................................................................................................5

5. Field Descriptions, Definitions and Domains ............................................................................. 6

5.1. Discrepancy Agency ID ..................................................................................................................6

5.2. Date Updated .................................................................................................................................6

5.3. Effective Date .................................................................................................................................6

5.4. Expiration Date ..............................................................................................................................7

5.5. NENA Globally Unique ID .............................................................................................................7

5.6. State ...............................................................................................................................................8

5.7. Agency ID ......................................................................................................................................8

5.8. Service URI ....................................................................................................................................8

5.9. Service URN ...................................................................................................................................9

5.10. Service Number .............................................................................................................................9

5.11. Agency vCard URI .........................................................................................................................9

5.12. Display Name .................................................................................................................................9

5.13. FCC PSAP ID .............................................................................................................................. 10

6. Boundary DEVELOPMENT ................................................................................................... 10

7. PSAP BOUNDARY Delineation .............................................................................................. 10

8. PROVISIONING BOUNDARY DELINEATION ..................................................................... 11

9. EMERGENCY SERVICE BOUNDARY DeLINEATION ......................................................... 11

10. GIS Data Elements .............................................................................................................. 11

ii

11. Use Cases ............................................................................................................................. 12

12. Terminology ......................................................................................................................... 19

13. References ........................................................................................................................... 21

1

1. BACKGROUND In a Next Generation 911 (NG911) environment, the entirety of the 911 call process is spatially enabled. The marriage between GIS and NG911 will not just replace the antiquated static location methodology of historical 911 systems with the dynamic location services necessary to find today’s transient 911 caller, GIS also will be used to route the call from the 911 caller to the proper PSAP. The National Emergency Number Association (NENA) specializes in standardizing data used in public safety systems to support emergency response, particularly as it relates to NG911. NENA’s NG911 GIS Data Model1 standard provides the foundation for this Best Practices document. PEMA anticipates completing a statewide NG911 GIS data gap analysis in 2019 that will include formalizing Pennsylvania NG911 GIS requirements. Following completion of the statewide NG911 GIS data gap analysis, this document will be revisited to include any Pennsylvania specific additions to the NENA NG911 GIS Data Model related to the boundary layers. In NG911, the static call routing and address validation tables are replaced by spatial referencing through the emergency call routing function (ECRF) to route calls to the proper PSAP and location validation function (LVF) to validate addresses within the NG911 system. The NENA GIS data model standard states that the following data elements are required for the ECRF and LVF to function, and are required for call taking and dispatch operations in a NG911 environment:

• Road Centerlines • Site/Structure Address Points • PSAP boundaries • Provisioning boundaries • Emergency service boundaries pertaining to fire/rescue, emergency medical services (EMS), and law

enforcement response areas The Pennsylvania Emergency Management Agency (PEMA) and local government partners are coordinating the development and maintenance of statewide emergency service and provisioning boundary datasets to support public safety answering point (PSAP) operations. The goal is to create a seamless georeferenced database that PSAPs across the Commonwealth can access. This document is intended to provide guidance for maintaining the PSAP, emergency service and provisioning boundary geospatial datasets that will be contained in this database. Best practices and guidance for road centerlines and Site/Structure Address Points will be provided in a subsequent document. In addition to describing these elements, this document recommends supplementary fields that will be helpful in coordinating the migration of PSAPs from the current 911 service environment to NG911.

1 NENA STA-006.1-2018

2

2. PURPOSE The purpose of this document is to provide a common data model for all required boundary layers (PSAP boundary, Provisioning Boundary, and Emergency Service Boundary) and to provide guidance on minimum accuracy standards as described in Section 5 of this document that must be met before local data can be integrated into a statewide dataset. This will require substantial coordination and cooperation between 911 coordinators or designee, county GIS offices, and public safety agencies. Local 911 authorities are responsible to collaborate any efforts required for defining the PSAP, provisioning, and emergency service boundaries within their jurisdictions; this creates the foundation for 911 call routing in the NG911 environment. Internally, the alignment of these boundaries is led by the PSAP working with fire, law and EMS leaders. Seamless alignment with adjacent jurisdictional areas is critical to effective and efficient coordination and delivery of emergency services in an NG911 environment. A common data model for all boundary layers will assure that no data gaps or overlaps exist, as they could cause detrimental deficiencies in the life-safety services provided by the 911 system. Therefore, adherence to the data model and cross jurisdictional cooperation are needed in the implementation, operation, and maintenance of the NG911 system in Pennsylvania.

3. BOUNDARY DESCRIPTIONS

3.1. PSAP Boundary The primary use for the PSAP boundary is to route 911 calls in an NG911 environment. Each PSAP Boundary defines the geographic area of a PSAP that has primary responsibilities for an emergency request. This boundary layer depicts the polygon(s) and related attribute information that define the geographic area of all PSAP boundaries within a given 911 authority’s jurisdictional area. The PSAP boundary may contain data for one county, multiple counties, or partial areas of one or more counties, depending on previously established local governance arrangements that define a PSAP’s primary jurisdictional area. The PSAP boundary layer is used by the emergency call routing function (ECRF)—a Next Generation Core Services (NGCS) functional element—to perform a geographic query that determines the primary PSAP for an incoming 911 call. The geographic location information associated with the call must be provided using a civic address, geographic coordinates, or geodetic shapes as defined in NENA Detailed Functional and Interface Standards for the NENA i3 Solution.

3.2. Provisioning Boundary The provisioning boundary layer defines jurisdictional areas for local GIS data stewards who are vested in the creation and maintenance of spatial data in their respective jurisdictions. Data updates and error corrections within the defined provisioning boundary must be approved by the 911 Coordinator or designee and submitted by the GIS data steward. Each provisioning boundary only has one individual or entity operating as the provisioning authority, and there can be no gaps or overlaps between adjacent boundaries.

3

The provisioning boundary must be agreed to by all adjoining data-provisioning providers. The associated polygon layer can be used for geoprocessing by the ECRF to identify and exclude erroneous features that lie beyond the boundary; it also can be used by the Forest Guide to determine coverage for a data-provisioning authority. (The Forest Guide is an element of the Location-to-Service Translation [LoST] protocol that helps to determine the correct emergency call routing based not only on the location of the caller, but also jurisdictional factors.) The provisioning boundary is a mandatory layer in the Commonwealth’s schema structure. When provisioning data for the ECRF and location validation function (LVF) through the spatial interface (SI)—both are NCGS functional elements—the locally appointed 911 authority must submit GIS data for its geographic area of jurisdiction only, and must ensure that the data is inclusive of its geographic area of jurisdiction.

3.3. Emergency Service Boundary An emergency service boundary layer defines the primary geographic area of law enforcement, EMS, and fire responders. Each emergency service boundary layer may contain one or more polygon boundaries that define the primary emergency services for that geographic area. There must be a separate emergency service boundary layer for each type of service discipline. Each individual layer for the identified responder disciplines is used by the ECRF to perform a geographic query that determines which responding agencies are responsible for providing emergency services for the location of a 911 caller. In addition to a primary PSAP’s use of this information to identify the appropriate units for dispatch, emergency service boundary data aids the selective transfer function and Emergency Incident Data Document (EIDD) delivery for a call that must be transferred to another PSAP for dispatch.

4. SCHEMA NENA’s NG911 GIS data model standard defines the required data schema and associated fields for PSAP, provisioning, and emergency service boundaries. All fields listed in the NENA standard are included in this document. Any additional Pennsylvania-specific fields may be added to the list in future once the statewide NG911 GIS data gap analysis is completed. Populating accurate data in some of the listed fields may require coordination and assistance from the service provider implementing and maintaining the Commonwealth’s Emergency Services Internet Protocol Network (ESInet).

4.1. Data Layer Names All boundary data layers intended for submission shall be named according to the following guidelines. Data layers with different names will not be included in quality assurance tests or aggregated into statewide datasets.

• PSAP boundary layer: ESB_PSAP • Police department boundary layer: ESB_LAW • EMS department boundary layer: ESB_EMS • Fire department boundary layer: ESB_FIRE • Provisioning boundary layer: ProvisioningBoundary

4

4.2. Data Layer Attributes Each data layer is described in this document with a table listing the attributes, followed by a more detailed attribute description. The tables are formatted with the following information:

• Field Name: A recommendation for the attribute field name. This column identifies the standardized GIS data field name that MUST be used. While local entities MAY use their own field names for internal processes, utilization of GIS data within and between the NG911 system functional elements MUST conform to this standard structure.

• Descriptive Name: Basic description of the data field name. It is provided to clarify the intent of the information contained in the field name.

• Type: The required attribute type, per NENA standards. o P – Printable ASCII characters (decimal codes 32 to 126). Case is not important, except in legacy fields which require upper case as per NENA 02-010, NENA Standard for Data Formats for 911 Data Exchange & GIS Mapping [8] Example: Text fields in Esri feature classes and shapefiles. o U – A Uniform Resource Identifier (URI) as described in Section 11, Terminology, and defined in RFC 3986 [9], and also conforming to any rules specific to the scheme (e.g. sip:, https:, etc.) of the chosen URI. Depending on the provider of relational database this data type may vary. o D – Date and time: This field is used for storing date and time data. Example: Date fields in Esri

geodatabase feature classes and shapefiles. Note: NENA requires the ISO 8601 date/time format with time zone information. Many GIS applications cannot easily produce this particular format. Local data stewards could store date attributes in the more common format, and the attributes will be converted in the Commonwealth dataset.N – Non-negative Integer: This field consists of whole numbers only. Example: In Esri geodatabase feature classes and shapefiles, these shall be short-integer or long-integer fields.

• Field Width: The maximum field width, in number of characters. • M/C/O: This field is used to indicate whether populating the attribute is mandatory, conditional or

optional. Full attribute descriptions are listed after the table. The descriptions include an explanation of the field along with any required domain of valid values. o Mandatory – An attribute value must be provided for the data field for each record. Mandatory

data field must not be blank. o Conditional – If an attribute value exists, it must be provided. If no value exists for the attribute,

the data field is left blank. o Optional – An attribute value may or may not be provided in the data field.

4.3. PSAP Boundary

Descriptive Name Field Name M/C/O Type Field Width

Discrepancy Agency ID DiscrpAgID

M P 75

Date Updated DateUpdate M D 20 Effective Date Effective O D 20

5

Expiration Date Expire O D 20 Emergency Service Boundary NENA Globally Unique ID

ES_NGUID

M P 254

State State M P 2 Agency ID Agency_ID M P 100 Service URI2 ServiceURI M U 254 Service URN3 ServiceURN M P 50 Service Number ServiceNum O P 15 Agency vCard URI AVcard_URI M U 254 Display Name DsplayName M P 60 FCC PSAP ID FCCID_PSAP M N 4

4.4. Emergency Service Boundary

Descriptive Name Field Name M/C/O Type Field Width

Discrepancy Agency ID DiscrpAgID M P 75 Date Updated DateUpdate M D 20 Effective Date Effective O D 20 Expiration Date Expire O D 20 Emergency Service Boundary NENA Globally Unique ID

ES_NGUID M P 254

State State M P 2 Agency ID Agency_ID M P 100 Service URI ServiceURI M U 254 Service URN ServiceURN M P 50 Service Number ServiceNum O P 15 Agency vCard URI AVcard_URI M U 254 Display Name DsplayName M P 60

4.5. Provisioning Boundary

Descriptive Name Field Name M/C/O Type Field Width

Discrepancy Agency ID DiscrpAgID M P 75 Date Updated DateUpdate M D 20

2 Uniform resource identifier. 3 Uniform resource name.

6

Effective Date Effective O D 20 Expiration Date Expire O D 20 Provisioning Boundary NENA Globally Unique ID

PB_NGUID M P 254

5. FIELD DESCRIPTIONS, DEFINITIONS AND DOMAINS This section provides a description, attribute data domain, and an example for each field. An attribute data domain defines the set of all valid values that are allowed in the attribute data field. If the domain defines no values, then any value that matches the data type and description may be used for the attribute field. Those with given data domain values must use only one of those values for the attribute field.

5.1. Discrepancy Agency ID Description: The agency that is responsible for receiving a discrepancy report (DR), should a discrepancy be discovered, and sufficiently resolving the discrepancy. The identified discrepancy agency must be represented by a domain name that is compliant with the agency identifier definition contained in the NENA Master Glossary.4 This may be the same agency as the locally appointed 911 authority. Domain: None Example: luzerne911.pa.us.gov; LCWC911.pa.us

5.2. Date Updated Description: The date and time that the record was created or last modified. This value MUST be populated when modifications are completed to attributes, geometry, or both. Domain: Date and time may be stored in the local database’s date/time format with the condition that the local time zone MUST be recorded; also, time MUST be recorded to a precision of at least 1 second, but MAY be recorded to a precision of 0.1 second. If the local database’s date/time format does not meet these specifications, the database SHOULD record both the local date/time format and a string conforming to the W3C dateTime format as described in XML Schema Part 2: Datatypes Second Edition. Example: A W3C dateTime with optional precision of 0.1 second:

• 2017-12-21T17:58.03.1-05:00 (representing a record updated on December 21, 2017, at 5:58 and 3.1 seconds p.m., U.S. Eastern Standard Time)

• 2017-07-11T08:31:15.2-04:00 (representing a record updated on July 11, 2017, at 8:31 and 15.2 seconds a.m., U.S. Eastern Daylight Time)

5.3. Effective Date Description: The date and time that the record is scheduled to take effect.

4 NENA Master Glossary

7

Domain: Date and time may be stored in the local database’s date/time format with the condition that the local time zone MUST be recorded; also, time MUST be recorded to a precision of at least 1 second but MAY be recorded to a precision of 0.1 second. If the local database’s date/time format does not meet these specifications, the database SHOULD record both the local date/time format and a string conforming to the W3C dateTime format as described in XML Schema Part 2: Datatypes Second Edition. Example: A W3C dateTime with optional precision of 0.1 second:

• 2019-02-18T02:30:00.1-05:00 (representing a record that will become active on February 18, 2019, at 2:30 and 0.1 seconds a.m., U.S. Eastern Standard Time)

• 2019-10-09T13:01:35.2-04:00 (representing a record that will become active on October 9, 2019, at 1:01 and 35.2 seconds p.m., U.S. Eastern Daylight Time)

Note: This field is used when time and date of a change is known, e.g., the time and date an annexation takes effect.

5.4. Expiration Date Description: The date and time when the information in the record is no longer considered valid. Domain: Date and time may be stored in the local database’s date/time format with the condition that the local time zone MUST be recorded; also, time MUST be recorded to a precision of at least 1 second but MAY be recorded to a precision of 0.1 second. If the local database’s date/time format does not meet these specifications, the database SHOULD record both the local date/time format and a string conforming to the W3C dateTime format as described in XML Schema Part 2: Datatypes Second Edition. Example: A W3C dateTime with optional precision of 0.1 second

• 2022-02-18T02:30:00.1-05:00 (representing a record that will expire on February 18, 2022, at 2:30 and 0.1 seconds a.m., U.S. Eastern Standard Time)

• 2022-10-09T13:01:35.2-04:00 (representing a record that will expire on October 9, 2022 at 1:01 and 35.2 seconds p.m., U.S. Eastern Daylight Time)

Note: This field is used when the time and date of a change is known, e.g., the time and date an annexation takes effect and the previous boundary is retired.

5.5. NENA Globally Unique ID Description: The NENA Globally Unique ID (NGUID) pertains to each PSAP, provisioning and emergency service boundary. Each record in these boundary layers MUST have a globally unique ID. When coalescing data from other local 911 authorities into the ECRF and LVF, this unique ID MUST continue to have only one occurrence. One way to accomplish this is to append the 911 authority’s domain to the end of the “locally unique ID.” Note that emergency service boundary data is unique in that the data fields and their attributes are only a template to be reused for each emergency service boundary; separate datasets for law enforcement, EMS, and fire—as well as other emergency services such as Poison Control, Forest Service, and U.S. Coast Guard—also MAY exist. Domain: None Example: It is suggested that the emergency service boundary NGUID start with the type of emergency service (e.g., EMS, LAW, FIRE, PSAP).

8

• Feature ID 243 in the EMS emergency service boundary layer would be represented as EMS243@911Authority_domain.state.us

• Feature ID 44 in the law enforcement emergency service boundary layer would be represented as LAW44@911Authority_domain.state.us

• Feature ID 18 in the fire emergency service boundary layer would be represented as FIRE18@911Authority_domain.state.us

• Feature ID 7 in the PSAP boundary layer would be represented as PSAP7@911Authority_domain.state.us

Note: When an emergency service boundary crosses into one or more states, the emergency service boundary SHOULD be split at the state boundary or state equivalent, with the state and the emergency service boundary NGUID being the only difference in the attributes.

5.6. State Description: A state name, or state equivalent, represented by the two-letter abbreviation identified in USPS Publication 28 [14], Appendix B. A state is a primary governmental division of the United States. Domain: ISO 3166-2 contains the same abbreviations as USPS Publication 28 [14], Appendix B, plus additional abbreviations for the nine minor outlying islands owned by the U.S. These abbreviations also are available through the U.S. Census Bureau. Example: PA, NM, OR

5.7. Agency ID Description: A Domain Name System (DNS) domain name that is used to uniquely identify an agency. An agency is represented by a domain name as defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 1034 (available at https://tools.ietf.org/html/rfc1034). Each agency MUST use one domain name consistently to correlate actions across a wide range of calls and incidents. Any domain name in the public DNS is acceptable if each distinct agency uses a unique domain name. This ensures that each agency ID is globally unique. Domain: MUST be a registered DNS domain name. Example: psap.harriscounty.tx.us; police.allegheny.pa.us Note: The Agency ID is a field in the PSAP and emergency service boundary layers that identifies the agency that the boundary defines. It also is used in the EIDD, the Service/Agency Locator, and may be used in constructing NGUIDs.

5.8. Service URI Description: The uniform resource identifier (URI) used for call routing. This attribute is contained in the emergency service boundary layer and defines the URI of the specific service. The URI is usually a Session Initiation Protocol (SIP or SIPS) URI but MAY be a telephone number URI that defines the route to reach the service. Domain: Registered domain name; RFC 1035 (available at https://www.ietf.org/rfc/rfc1035.txt ) defines the process for registering a domain name.

9

Example: sips:sos.psap@eoc.houston.tx.us; tel:+12025551212

5.9. Service URN Description: The uniform resource name (URN) used to select the service for which a route is desired. The ECRF is queried with a location and a service URN, and then returns the service URI. Domain: ITEF RFC 5031 defines the service URN, while NENA-STA-010.2-2016 defines the domain of allowable values. PSAP boundaries only SHOULD contain features with service URN values of "urn:nena:service:sos.psap." Values to be used for emergency service boundaries for other responding agencies are found in the NENA Registry System. Example: urn:nena:service:sos.psap; urn:nena:service:responder.police; urn:nena:service:responder.fire; urn:nena:service:responder.ems Note: A boundary with a service URN of urn:service:sos MUST be provisioned in the ECRF. 911 authorities responsible for the ECRF or their designees/vendors will need to generate such a boundary from the boundaries in all GIS systems provisioned to that ECRF. If provisioning a boundary to the ECRF, it MUST conform to the service boundary definition contained in NENA-STA-010 [1], Appendix B.

5.10. Service Number Description: The numbers that would be dialed on a 12-digit keypad to reach the emergency service appropriate for the location. This is not the same as an emergency service number (ESN) in legacy E911 systems. This field is used for all emergency service boundaries including PSAP, law enforcement, fire EMS, and others such as poison control. Within the U.S., the service number for most emergency services is 911; however, there may be emergency service boundaries, e.g., poison control, that have a different number. Additionally, in areas outside the U.S., different numbers may be used for law enforcement, fire, and EMS—this field would be used to denote those numbers. Domain: A dialable number or dial string. Example: 911; 18002221212

5.11. Agency vCard URI Description: A vCard (virtual card) is a file format standard for electronic business cards. The agency vCard URI is the internet address of an eXtensible Markup Language (XML) data structure that contains contact information (e.g., agency name, contact phone numbers) in the form of a vCard (IETF RFC 6350). vCard files may be exported from most email programs or created with a text editor. The vCard URI is used in the service boundary layers to provide contact information for each agency. The Service/Agency Locator (see NENA STA-010.2-2016) will provide these URIs for agencies listed within it. Domain: None Example: https://vcard.psap.allegheny.pa.us; https://vcard.houstontx.gov/fire

5.12. Display Name

10

Description: A name or description of the entity offering emergency services within a PSAP boundary or emergency service boundary. This value MUST be suitable for display. Domain: None Example: New York Police Department; Med-Life Ambulance Services

5.13. FCC PSAP ID Description: The Federal Communications Commission (FCC) maintains a registry of PSAPs within the U.S. and its territories, and assigns a unique 4-digit key to each. This field value should be the primary PSAP identifier from the FCC Master PSAP Registry assigned to the PSAP to which the ESN would default route. Domain: The FCC Master PSAP Registry can be downloaded from https://www.fcc.gov/general/911-master-psap-registry. If you do not find your PSAP, or if a change has taken place, please advise the FCC using the contact information in the link provided and register. Example: 5879 (Cumberland), 5906 (Lycoming), 5856 (Blair), 5887 (Erie)

6. BOUNDARY DEVELOPMENT PEMA is requesting that county 911 coordinators or designee and county GIS data stewards actively map Pennsylvania’s PSAP, emergency service and provisioning boundary layers. To assist with these efforts, GIS data development related to 911 services is eligible for 911 funding. In addition, PEMA, in consultation with the 911 Advisory Board, has made GIS data development a top priority for funding in the 2018 Statewide Interconnectivity Grant Program and anticipates that GIS data development will again be a top priority in 2019. PEMA and the County GIS Professionals Association (County GISPros) have developed a PSAP boundary template using data submitted by each county. Sixteen counties submitted PSAP boundaries as part of that data collection effort. The PSAP boundary template was assembled from the 16 county-submitted PSAP boundaries, with the remaining 46 PSAPs represented as Pennsylvania Department of Transportation (PennDOT) county boundaries. PEMA decided to start with PennDOT county boundaries because the data already topologically clean, with no gaps or overlaps. This data also will be easy to compare with finalized versions of the PSAP boundary layer to see where PSAP boundaries differ from county boundaries to facilitate discussions between counties for setting PSAP boundaries. Best practices for developing the PSAP boundary, provisioning boundary, and emergency service boundary are provided in subsequent sections of this document.

7. PSAP BOUNDARY DELINEATION The statewide PSAP layer consists of 62 PSAP polygons. County GIS data stewards must work with the appointed county 911 coordinators in their jurisdiction first and then with the neighboring jurisdictions to define the boundary. The entire PSAP boundary should be seamless without gaps or overlaps. The draft dataset described earlier in this document will be used to facilitate discussion between neighboring PSAPs to determine the proper depiction of their shared PSAP boundaries. In some cases, this may require coordination with a neighboring PSAP in an adjacent state. With 911 coordinator or designee approvals, GIS data stewards must take initiatives to collaborate with neighboring PSAPs to submit identical boundaries.

11

It is strongly recommended that PEMA, PSAPs and GIS offices make every effort to coordinate all GIS boundary layers (i.e., PSAP boundaries, emergency service boundaries, and provisioning boundaries)

8. PROVISIONING BOUNDARY DELINEATION The provisioning boundary layer is important in the reporting of discrepancies back to the source for remediation. GIS data is expected to be provided from a variety of sources for coalescing into the overall statewide layers. The provisioning boundary is intended to represent the boundary extent (city, county, and region) for which the GIS data is provided. For example, if a city is providing its data directly, the provisioning boundary is a single polygon for that city boundary. However, if that city provides its data to the county, and thus the county is the provisioning source of data into the statewide layers, then the county boundary becomes the single polygon for the county as the authoritative source. The same holds true if multiple counties supply data to a regional entity. Thus, each authoritative source provides a single polygon boundary, and those boundaries become coalesced at the state level, where no overlaps or gaps are allowed.

9. EMERGENCY SERVICE BOUNDARY DELINEATION The set of emergency service boundaries must include, at a minimum, the following:

• Law enforcement • Fire • Emergency medical services

Other emergency service boundaries may include at a minimum:

• Poison control • Forest service • U.S. Coast Guard • Animal control

The list above is not comprehensive. Other emergency service providers may have boundaries created for them, based on the unique needs within a geographical area. The local 911 authority MAY maintain the emergency service boundary layer as a combined or single layer for each emergency service. However, when exchanging emergency service boundary information in an NG911 environment, emergency service boundaries MUST be exchanged as individual layers for each emergency service type, e.g., one for law enforcement, one for fire, and one for EMS.

10. GIS DATA ELEMENTS While PennDOT boundaries were used to compile the template, PSAP boundaries are not identical to the established geopolitical county boundaries. An approximation of the extent of the PSAP coverage area is contained in tabular fashion in the Master Street Address Guide (MSAG). The ESN values contained in the dataset can be correlated to an individual PSAP and are helpful in creating a PSAP boundary dataset.

12

Emergency service zones (ESZs) should be compared with PSAP boundaries because the extent of an ESZ may reveal a corresponding PSAP boundary configuration. Geocoding the 911 authority’s MSAG will generate a point layer of addresses assigned to that PSAP. Physical features, such as mountains and rivers, may have been used to establish the current ESZs or PSAP boundaries, or may encourage local 911 authorities to consider adjustments to these layers for future efficiencies in emergency notification and response. Most localities have emergency service boundary datasets depicting fire, EMS and law enforcement response areas. These boundaries typically are used by computer-aided dispatch (CAD) systems within the PSAP. The statewide boundary dataset can make use of these existing local response agency service boundaries.

11. USE CASES The public safety answering point (PSAP) boundary file maintained by the GIS data stewards will be used in place of the master street address guide (MSAG) to route 911 calls to the appropriate PSAP in the NG911 system and must serve as an accurate representation of a PSAP’s response area. This critical first step in providing life safety services must be completed to resolve inaccurate, unvetted or incomplete GIS data. It is imperative that the county 911 coordinator and county GIS data steward develop the PSAP boundary in coordination with neighboring county 911 coordinators and county GIS data stewards to ensure complete coverage without overlaps or gaps. While a PSAP boundary file already may exist in the PSAP GIS, PEMA strongly recommends creating a fresh PSAP boundary over attempting to edit existing PSAP boundary data unless the latter has been developed in coordination with neighboring PSAPs. The PennDOT County boundary should be used as a starting point as it is topologically clean Once a PSAP has a boundary file created, the next step is for the county 911 coordinators and GIS data stewards to further refine these boundaries to ensure there are no gaps or overlaps. Further adjustments to the boundary should be done in order to accommodate the ground truth of emergency response taking in account the terrain and other physical features and existing mutual aid and first due agreements. Spatial routing can accommodate mobile callers and route calls placed from anywhere; the middle of a lake, swamps, or woods for example. This capability necessitates a PSAP boundary with no gaps or overlaps to quickly route the call to the correct PSAP. Regional taskforces are encouraged to facilitate regional workshops involving all the counties. Collectively they can work to identify boundary issues and research the solutions for any discrepancies. Below are two use cases where GIS offices of neighboring PSAPs coordinated the development of the PSAP boundary. Use Case 1: Cumberland County and Franklin County

13

Figure 1 - Final PSAP Boundary: Franklin and Cumberland Counties

Cumberland and Franklin County have gone through a PSAP boundary delineation process with their GIS staff and 911 directors. The PSAP boundary decisions they made will be documented below.

Figure 2 - Gunters Valley

Gunters Valley runs along the border of Franklin, Cumberland, and Perry Counties. Gunters Valley is long and narrow with 1000 ft ridges. The only road accessing Gunters Valley is in Franklin County. Because no direct access exists from Cumberland County, the section of Gunter Valley in Cumberland County is assigned to the Franklin PSAP.

14

Figure 3 - Coverage Issues

Great care is needed to ensure that GIS data used for NG911 meets public safety grade standards. PSAP Boundaries are required to be topologically clean with no gaps or overlaps.

Figure 4 - Conflicting Coverage Issues

County boundaries form the foundation of PSAP boundaries. Middle Spring Creek forms a portion of the boundary between Franklin and Cumberland County. The lower section of Figure 4 shows Franklin and Cumberland Counties’ PSAP Boundaries aligned with the 2018 PennDOT County Boundary. Between 2016, when this PSAP boundary was created and 2018, PennDOT changed this boundary to better reflect Middle Springs Creek geometry. The upper section of Figure 4 shows a section of Franklin and Cumberland Counties’ PSAP Boundaries that requires alignment.

15

Figure 5- Parcel Splits by County Boundary

A thorough review of properties and their corresponding GIS data along county boundaries is necessary. Legacy 911 and the tabular MSAG and ALI records used the assigned addresses to route calls to the appropriate PSAP. Figure 5 shows a housing development that is bisected by the PennDOT county boundary. Cumberland County has first due responsibilities for fire and rescue services to this neighborhood. As such, the PSAP boundary was adjusted to route all 911 calls placed from within that neighborhood to Cumberland County’s PSAP.

Figure 6 - Jurisdiction Splits by County Boundary

Shippensburg Borough is split by the county boundary between Cumberland and Franklin Counties. Many years ago, the Cumberland County PSAP accepted responsibility for receiving 911 calls from the entirety of Shippensburg Borough. As shown in Figure 6, the Cumberland County PSAP boundary has been adjusted to cover all of Shippensburg Borough including the portion in Franklin County. Also shown in the left section of Figure 6 is the Volvo plant that straddles Shippensburg Borough and Southampton Township. Since Shippensburg Borough is first due to the whole facility, the Cumberland County PSAP boundary was adjusted to cover the Volvo plant.

16

Use Case 2: Tioga, Lycoming and Sullivan County Tioga County GIS, along with Lycoming County GIS, took an initiative with the intent to establish and create logistically correct PSAP boundaries that will meet the topology rules necessary to function in the NG911 data model. In order to efficiently work out the discrepancies noticed between the two PSAP boundaries, Lycoming County and Tioga County staff focused on the primary objective, which is to route 911 calls to the proper PSAP. The first step in this process was to review the existing selective routing in order to establish the correct geographic area of the PSAP.

Figure 7 Tioga and Lycoming/Sullivan PSAP geographic area

A great deal of collaboration between GIS data stewards and 911 authorities and PSAP staff was required in the process. For example, the Tioga county PSAP is especially complicated because it is an answering point for not only all of Tioga and Potter County, but also for portions of McKean, Lycoming, and Bradford Counties.

17

Figure 8 ESZ boundaries for Lycoming/Sullivan and Tioga

They noticed a significant amount of overlap with PSAP layer and the ESZ (Emergency Service Zones) layers and realized that the ESZ layer could be a major component in refining the PSAP boundary.

Figure 9 ESZ boundaries intersecting the PSAP boundary

Both counties agreed to a perpetual data sharing cooperative for the sake of NextGen911 feature compilation and QC. This sharing of datasets allowed for the GIS personnel of both organizations to overlay the data in ArcMap, which clearly revealed the discrepancies.

18

Figure 10 Boundaries overlap issues

Data from both counties showed discrepancies like overlapping ESZ boundaries. All the discrepancies that would affect the PSAP boundaries were identified and documented. These discrepancies were discussed between the two counties involving all the stakeholders.

Figure 11 Example of changing PSAP boundary for access reasons

19

In order to determine the correct course of action, the supporting data layers utilized in the 911 dispatch systems from both counties were overlaid in ArcMap. The most critical layers utilized were road centerlines, structure address points, ESZ/ESN boundaries, and municipal boundaries. With proper symbolization in ArcMap, the combined GIS datasets revealed discrepancies that managers from both organizations could easily identify. These uniformly displayed datasets allowed for consistent communication to occur back and forth between the organizations until solutions were decided upon. Final changes were then applied to the master datasets of both organizations. Figure 11, shows why it was decided that Flooks Run Rd should be included in Tioga’s PSAP as the properties on this road in Lycoming County cannot be accessed from Lycoming County. To summarize, by sharing the entire datasets of these jurisdictions and then displaying it via a properly symbolized ArcMap document for all managers to utilize, complicated problems became much simpler to solve. All solutions to the discrepancies were then communicated to all stakeholders for approval and applied to the master datasets. Other recommended GIS layers for use in this process include: Hydro (water) Box Locations Phone Lines Data for Cellular (tower, coverage area, etc.) 12. TERMINOLOGY The following terms are a subset of terms defined in NENA Master Glossary of 911 Terminology document NENA-ADM-000.22-2018 Term or Abbreviation Definition / Description ECRF (Emergency Call Routing Function) A functional element in an ESInet which is a LoST protocol

server where location information (either civic address or geo-coordinates) and a Service URN serve as input to a mapping function that returns a URI used to route an emergency call toward the appropriate PSAP for the caller’s location or towards a responder agency.

LVF (Location Validation Function) A functional element in an NGCS that is a LoST protocol server where civic location information is validated against the authoritative GIS database information. A civic address is considered valid if it can be located within the database uniquely, is suitable to provide an accurate route for an emergency call and adequate and specific enough to direct responders to the right location.

SI (Spatial Interface) A standardized data replication interface used to publish GIS data to the functional elements that consume GIS data, such as the ECRF, LVF, Map Database Services, etc.

20

NGCS (Next Generation 911 (NG911) Core Services)

The base set of services needed to process a 911 call on an ESInet. Includes the ESRP, ECRF, LVF, BCF, Bridge, Policy Store, Logging Services and typical IP services such as DNS and DHCP. The term NG911 Core Services includes the services and not the network on which they operate. See Emergency Services IP Network.

LoST (Location-to-Service Translation) Protocol

A protocol that takes location information and a Service URN and returns a URI. Used generally for location-based call routing. In NG911, used as the protocol for the ECRF and LVF.

Forest Guide A special instance of a LoST server. It is part of the Location to Service Translation (LoST) protocol query process and allows client functional elements to discover call routing information outside of its domain (typically their ESInet or state level ECRF/LVF).

EIDD (Emergency Incident Data Document) A National Information Exchange Model (NIEM) conformant, object that is used to share emergency incident information between and among authorized entities and systems.

GIS Data Steward Data stewards are GIS professionals who are vested in the creation and maintenance of spatial data in their respective Jurisdictions, and as such are the logical source for authoritative foundational data for NG911 from all jurisdictions in the Commonwealth.

NENA i3 NENA i3 introduces the concept of an Emergency Services IP network (ESInet), which is designed as an IP-based inter-network (network of networks) shared by all agencies which may be involved in any emergency.

21

13. REFERENCES

1. NENA Standard for NG911 GIS Data Model (NENA-STA-006.1-201X) https://dev.nena.org/higherlogic/ws/public/download/13408/NENA-STA-006%20NG911%20GIS%20Data%20Model_SFN.pdf

2. NENA Standards for the Provisioning and Maintenance of GIS data to ECRF and LVFs (NENA-STA-005.1.1- 2017) https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-005.1.1-2017_ECRF-L.pdf

3. NENA GIS Data Collection and Maintenance Standards (02-014) https://cdn.ymaws.com/www.nena.org/resource/resmgr/Standards/NENA_02-014.1_GIS_Data_Colle.pdf

4. NENA Detailed Functional and Interface Standards for the NENA i3 Solution https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.2_i3_Architectu.pdf

5. NENA Master Glossary of 911 Terminology (ADM-000.22-2018) https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-ADM-000.22-2018_FINAL_2.pdf

6. 911 Master PSAP Registry https://www.fcc.gov/general/911-master-psap-registry

7. XML Schema Part 2: Datatypes Second Edition https://www.w3.org/TR/xmlschema-2/

8. Publication 28 - Postal Addressing Standards https://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf