MOU - Arizona 9-1-1 Program

Arizona 9-1-1 Program
Memorandum of Understanding (MOU)
Geospatial Support Services for
Next Generation 9-1-1
For Assistance:
If you have questions about this MOU, please contact:
Travis Jensen, Program Manager
travis.jensen@azdoa.gov
Eric Shreve, 9-1-1 Geospatial Manager
eric.shreve@azdoa.gov
1

Table of Contents
Section 1: Purpose
3
Section 2: Definitions
3
Section 3: Scope
6
Section 4: Obligations of the Parties
7
Section 5: Governance
7
Section 6: Policy
8
Section 7: Term; Amendments
8
Section 8: Commitment
9
Section 9: Arbitration
9
Section 10: Availability of Funds
9
Section 12: Force Majeure
10
Section 13: Confidentiality and Data Privacy
10
Section 14: Termination for Default
11
Section 15: Signatures
11
2

ARIZONA DEPARTMENT OF ADMINISTRATION
ARIZONA 9-1-1 PROGRAM
MEMORANDUM OF UNDERSTANDING FOR
GEOGRAPHICAL INFORMATION SYSTEMS (GIS) SUPPORT SERVICES
This Memorandum of Understanding (MOU) between the Arizona 9-1-1 Program (Program) managed by the
Arizona Department of Administration (ADOA) and System Administrator signatory to this MOU which manages
911 systems (Systems). This MOU outlines the roles, responsibilities, and expectations of the parties in relation
to the provision of GIS in support of Next Generation (NG) 9-1-1 in the State of Arizona.
WHEREAS, the Arizona 9-1-1 Program and 911 systems managed by System Administrators both recognize
the importance of providing GIS for communities in the State of Arizona in order to improve the efficiency and
effectiveness of emergency response; and
WHEREAS, ADOA has the authority to enter into this MOU in order to achieve this purpose pursuant to A.R.S.
18-104 A 15;
NOW THEREFORE, the Arizona 9-1-1 Program and the System Administrator (on behalf of the 911 Systems it
manages) agree to enter into this MOU in order clarify responsibilities for GIS in support of NG911 Systems for
communities in Arizona.
The parties agree to the terms and conditions contained in this MOU as follows:
Section 1: Purpose
The purpose of this MOU is to establish a relationship between the Arizona 9-1-1 Program within the Arizona
Department of Administration and the System Administrator of the 911 Systems to which this MOU applies. This
MOU is designed to clarify the GIS capabilities required by the System Administrator(and the PSAPs under this
management) and to identify GIS support that may be available for communities in the State of Arizona.
The capabilities and related support will include:
-
creating and maintaining accurate and up-to-date geospatial data layers
-
resolving ALI/TN/MSAG discrepancies
-
integrating GIS data including site structure address points, road centerlines, emergency service
boundaries, into emergency response systems
-
updating Vesta Map Local
-
submitting geospatial data to GeoComm
-
helping to maintain geospatial continuity for NG9-1-1 routing
The underlying goal of these arrangements are to improve the efficiency and effectiveness of emergency
response in Arizona communities utilizing Next Generation (NG) 911 technology.
Section 2: Definitions
Definitions used in this document are listed below. Some of the technical definitions were taken from the NENA
Knowledge Base Glossary - National Emergency Number Association in effect at the time of this MOU.
3

⎻
Automatic Location Information (ALI) is the automatic display at the PSAP of the caller’s telephone
number, the address/location of the telephone and supplementary emergency services information of the
location from which a call originates.
⎻
Computer Aided Dispatcher (CAD) is a computer-based system, which aids PSAP
Telecommunicators by automating selected dispatching and record keeping activities.
⎻
Emergency Call Routing Function (ECRF) Emergency Service Boundary is a functional element in
NGCS (Next Generation Core Services) which is a LoST (Location-to-Service Translation) 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.
⎻
Emergency Service IP Network (ESInet) is a managed IP network that is used for emergency services
communications, and which can be shared by all public safety agencies. It provides the IP transport infrastructure
upon which independent application platforms and core services can be deployed, including, but not restricted to,
those necessary for providing NG9‑1‑1 services. ESInets may be constructed from a mix of dedicated and shared
facilities. ESInets may be interconnected at local, regional, state, federal, national and international levels to form
an IP-based internetwork (network of networks). The term ESInet designates the network, not the services that
ride on the network. See NG9‑1‑1 Core Services.
⎻
Geographic Information System (GIS) is a system for capturing, storing, displaying, analyzing, and
managing data and associated attributes which are spatially referenced.
⎻
Location Validation Function (LVF) is a functional element in an NGCS (Next Generation 9-1-1
Core Services) 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.
⎻
Master Street Address Guide (MSAG) is a database of street names and house number ranges within
their associated communities defining Emergency Service Zones (ESZs) and their associated Emergency
Service Numbers (ESNs) to enable proper routing of 9‑1‑1 calls.
⎻
National Emergency Number Association (NENA) is referred to as The 9-1-1 Association, which is
fully dedicated to the continued improvement and modernization of the 9-1-1 emergency communication system.
NENA's approach includes research, standards development, training, education, certification, outreach, and
advocacy through communication with stakeholders. As an ANSI-accredited Standards Developer, NENA works
with 9-1-1 professionals, public policy leaders, emergency services and telecommunications industry partners,
like-minded public safety associations, and more. Current NENA activities center on awareness, documentation,
and implementation for Next Generation 9-1-1 (NG9-1-1) and international three-digit emergency communication

systems. NENA's worldwide members join with the emergency response community in striving to protect human
life, preserve property, and maintain the security of all communities.
⎻
Next Generation 9-1-1 (NG9-1-1) is an IP-based system comprised of hardware, software, data, and
operational policies and procedures that:
(A) provides standardized interfaces from emergency call and message services to support
emergency communications;
(B) processes all types of emergency calls, including voice, data, and multimedia information;
(C) acquires and integrates additional emergency call data useful to call routing and handling;
(D) delivers the emergency calls, messages, and data to the appropriate public safety answering
point and other appropriate emergency entities;
(E) supports data or video communications needs for coordinated incident response and
management.
⎻
Next-Generation Core Services (NGCS) is the set of services needed to process a 9-1-1 call on an
ESInet. It includes, but is not limited to, the ESRP, ECRF, LVF, BCF, Bridge, Policy Store, Logging Services, and
typical IP services such as DNS and DHCP. The term NG9-1-1 Core Services includes the services and not the
network on which they operate. See Emergency Services IP Network.
⎻
Public Safety Answering Point (PSAP) is a physical or virtual entity where 9‑1‑1 calls are delivered by
the 9-1-1 Service Provider.
⎻
RCL (Road Centerlines) is a GIS feature that represents a centerline of a roadway. Each RCL segment
has a beginning point, end point and consequently a direction of flow from beginning to end. A RCL typically has
street number range information (High and Low) attributed to each segment in order to facilitate geocoding.
⎻
Site Structure Address Points Any city-style address that includes a house number and a street name
is considered a Civic Address. Civic Addresses include a community name that may or may not be recognized
by the USPS or be MSAG valid. Civic Addresses may be used as Postal addresses if recognized by the USPS.
Civic Addresses may be used as MSAG addresses if they are an exact match to the MSAG address. A rural
route delivery address or FPO or APO address is not considered a Civic Address.
Section 3: Scope
3.0 The Systems wishing to utilize NG911 technology provided by the State of Arizona through it’s Program
must perform activities related to implementing and operating of their respective emergency telecommunication
system as follows:
3.01
Site Structure Address Point: creating and maintaining accurate and up-to-date site structure
address points for emergency response.
3.02
Road Centerline: creating and maintaining accurate and up-to-date road centerlines for use in
emergency response.

3.03
Emergency Service Boundary: creating and maintaining accurate and up-to-date emergency service
boundaries for use in emergency response.
3.04
Resolving ALI/TN/MSAG Discrepancies: resolving any discrepancies in the Automatic Location
Information (ALI), Telecommunication Number (TN), and Master Street Address Guide (MSAG)
systems that may impact NG911 call routing.
3.05
Field Verify Address Discrepancies: verifying address discrepancies and providing mobile tools such
as Survey123 and ArcGIS Field Maps to verify civic locations.
3.06
Updating Vesta Map Local and Solacom Guardian: submitting geospatial data to GeoComm for
inclusion in the Vesta Map Local system and updating Solacom Guardian mapping as needed.
3.07
Updating unique requirements for RapidDeploy Radius Map: updating any unique requirements for
the RapidDeploy Radius Map as needed.
3.08
CAD GIS support from NG9-1-1 datasets: integrating GIS data from NG9-1-1 datasets into
Computer Aided Dispatch (CAD) Systems, as needed.
3.09
Arizona Spatial Data Infrastructure (SDI): leveraging and standing up processes/workflows on
Arizona Spatial Data Infrastructure (SDI), known as AZGeo, when a 9-1-1 system cannot stand up
GIS Enterprise Infrastructure and leverage web-based editing tools.
3.10
1Spatial: using 1Spatial’s reporting solution 1Data Gateway to show data quality, quantity, and time
when data was last submitted to the Program for synchronization into the Spatial Interface (SI) at
least quarterly. The following data layers will be shared although additional data layers may be
requested in support of the statewide initiative.
●Road Centerlines
●Site Structure Address Points
●Emergency Service Zone and/or Emergency Service Boundaries to include PSAP, Law, Fire,
and EMS
●Provisioning Boundary
●Parcels
3.11
Additional GIS or mapping support services: taking all actions to comply with GIS requirements for
geospatial call routing, which includes having accurate and up-to-date geographic data for the areas
covered by the 9-1-1 System and providing additional GIS, GIS Infrastructure, or mapping support
services as needed to assure compliance regardless of funding availability. .
Section 4: Obligations of the Parties
4.01
First, the System Administrators, either directly or through the PSAPs in their purview shall provide
the necessary resources and support to carry out the activities outlined in Section 2 and elsewhere
in this MOU. They will also provide access to relevant data and systems, collaborate with the

Program and State contracted vendors, and participate in training or technical assistance to
advance its capabilities.
4.02
Second, the Program will provide GIS support to the System Administrator as outlined in the Scope
(Section 2) of this MOU as necessary and appropriate subject to staffing and funding limitations
prioritized based on the criticality of need as determined by the Program and at their sole discretion.
4.02.01 The support will include identified specific projects or activities to improve or maintain its
GIS capabilities, based upon evidence or documentation to support the need.
4.02.02 If the 9-1-1 system cannot remediate the issues within a two-week window or is
non-communicative, the 9-1-1 program will make the necessary changes and process the
data. The updated dataset will then be provided to the 9-1-1 system to integrate into their
4.03
Third, and to the extent necessary, the System Administrator and/or the PSAP within its jurisdiction
shall engage State GIS contracted vendors under existing State contracts to close any significant
gaps in their capabilities.
4.04
The System Administrator and the State 911 Program will each designate a primary point of contact
for coordinating and communicating regarding the activities outlined in this MOU.
4.05
All statements in this MOU made by the System Administrator, bind all Public Safety Answering
Points (PSPs) within the territory that the System Administrator covers. Any exceptions must be
noted in advance in writing as an addendum to this MOU.
Section 5: Governance
5.0
A.R.S. 41-704 authorizes the Arizona Department of Administration to administer the emergency
telecommunication services revolving fund. The substantive laws and rules of Arizona (without reference to any
choice of law principles) shall govern the interpretation, validity, performance, and enforcement of this MOU.
5.01
The Program oversees the NG9-1-1 GIS system in Arizona.
5.02
The Program has the authority to develop and maintain the NG9-1-1 GIS system.
5.03
System Administrators will comply with the rules and regulations established by the Program about
the NG9-1-1 GIS system including its authorized users.
5.04
The Program will determine asset ownership for the NG9-1-1 GIS system by the rules and
regulations established by the Program
5.05
The Program will determine financial obligations for the NG9-1-1 GIS system in accordance with the
rules and regulations established by the Program.
5.06
The Program will maintain the NG9-1-1 GIS system, including networks, equipment, techniques,
and licenses.

5.07
System Administrator will cooperate with the Program to maintain the NG9-1-1 GIS system and
provide necessary resources and support in relation to its coverage area
Section 6: Policy
6.0 It is agreed and understood by the parties that:
6.01
The Program will develop practices, procedures, methods, and standards for the Program about the
NG9-1-1 GIS system.
6.02
System Administrators will follow the practices, procedures, methods, and standards established by
the Program about the NG9-1-1 GIS system.
6.03
The Program will determine the authorized use of the NG9-1-1 GIS system and network by state
law and the rules and regulations established by the Program.
6.06
The System Administrator shall comply with State Executive Orders No. 2023-01, 2009-09, and any
and all other applicable Federal and State laws, rules and regulations, including the Americans with
Disabilities Act.
Section 7: Term; Amendments
7.01
Term: This Agreement will commence on July 1, 2023 and terminate on June 30, 2024 unless
otherwise extended or renewed. This agreement expires at the end of its term unless the System
Administrator has obtained prior written Program approval for an extension or renewal.
7.02
Extension: A request for an extension must be received by the Programsixty (60) days before the
end of the term of the MOU. The Program, in its sole discretion, may approve an extension to
further the goals and objectives of the relationship and determine the length of any such extension.
7.03
Renewal: This MOU may be renewed at the beginning of each state fiscal year upon mutual
agreement of both parties in writing.
7.03
Updates: The Program and the System Administrator may initiate updates or changes to this MOU
as needed. Updates or changes to this MOU will be made in writing and must be agreed upon by
both parties.
Section 8: Commitment
This MOU is intended by the parties as a final and complete expression of their agreement. No course of prior
dealings between the parties and no usage of the trade shall supplement or explain any terms used in this MOU
and no other understanding either oral or in writing shall be binding. The provisions of this MOU are severable.
Any term or condition deemed illegal or invalid shall not affect any other term or condition of the MOU. The

System Administrator shall not assign any right nor delegate any duty under this MOU without the prior written
approval of the State. The State shall not unreasonably withhold approval.
Section 9: Arbitration
The parties to this MOU agree to resolve all disputes arising out of or relating to this MOU through arbitration,
after exhausting applicable administrative review, to the extent required by A.R.S. § 12-1518, except as may be
required by other applicable statutes (A.R.S. Title 41).
Section 10: Availability of Funds
10.01
Availability of Funds for the Next State Fiscal Year. Funds may not presently be available for
performance under this MOU beyond the current State Fiscal Year. No legal liability on the part of
the State for any payment may arise under this MOU beyond the current State Fiscal Year until
funds are made available for performance of this MOU.
10.02
Availability of Funds for the Current State Fiscal Year. Should the State Legislature enter back into
session and reduce the appropriations or for any reason and the related services are not funded,
the State may take any of the following actions:
10.02.1. Cancel the MOU; or
10.02.02. Cancel the MOU and re-acquire the services in another manner.
Section 11: Indemnification
Each party (as 'indemnitor') agrees to indemnify, defend, and hold harmless the other party (as 'indemnitee')
from and against any and all claims, losses, liability, costs, or expenses (including reasonable attorney's fees)
(hereinafter collectively referred to as 'claims') arising out of bodily injury of any person (including death) or
property damage but only to the extent that such claims which result in vicarious/derivative liability to the
indemnitee, are caused by the act, omission, negligence, misconduct, or other fault of the indemnitor, its officers,
officials, agents, employees, or volunteers.
Section 12: Force Majeure
Neither the System Administrator nor State shall be liable to the other nor deemed in default under this MOU if
and to the extent that such party’s performance of this MOU is prevented by reason of force majeure. The term
“force majeure” means an occurrence that is beyond the control of the party affected and occurs without its fault
or negligence. Without limiting the foregoing, force majeure includes: acts of God, acts of the public enemy, war,
riots, strikes, mobilization, labor disputes, civil disorders, fire, flood, lockouts, injunctions-intervention-acts,
failures or refusals to act by government authority, and other similar occurrences beyond the control of the party
declaring force majeure which such party is unable to prevent by exercising reasonable diligence.

Section 13: Confidentiality and Data Privacy
13.01
This Section 13 applies to the extent the subject of this MOU includes handling of any (1)
State’s proprietary and sensitive data or (2) confidential or access-restricted information
obtained from State or from others at State’s behest.
13.02
Data Protection and Confidentiality of Information. System Administrator warrants that it
will establish and maintain procedures and controls acceptable to State for ensuring that
State’s
proprietary
and
sensitive
data is protected from unauthorized access and
information obtained from State or others in performance of its duties is not mishandled,
misused, or inappropriately released or disclosed. For purposes of this paragraph, all data
created in any way related to this MOU, provided to System Administrator by State, or
prepared by others for State are proprietary to State, and all information by those same
avenues is State’s confidential information. To comply with the foregoing warrant:
13.02.01 System Administrator shall provide the State with a copy of its Disaster Recovery Plan
upon request. The Disaster Recovery Plan shall outline the System Administrator's
actions, with timelines, in the event of a natural disaster, cyber-attack or loss of ability to
operate and perform services under this MOU.
13.02.02 System Administrator shall: (a) notify State immediately of any unauthorized access or
inappropriate disclosures, whether stemming from an external data breach, internal data
breach, system failure, or procedural lapse within twenty-four (24) hours of a data breach,
by
sending
an
email
to
the
Arizona
Department
of
Homeland
Security
at
AZSOC@azdohs.gov, reporting the incident that occurred; (b) cooperate with State to
identify the source or cause and respond to each unauthorized access or inappropriate
disclosure; and (c) notify State promptly of any security threat that could result in
unauthorized access or inappropriate disclosures; and
13.02.03 System Administrator shall not: (a) release any such data or allow it to be released or
divulge any such information to anyone other than its employees or officers as needed for
each person’s individual performance of his or her duties under the MOU, unless State has
agreed otherwise in advance and in writing; or (b) respond to any requests it receives from
a third party for such data or information, and instead route all such requests to State’s
designated representative.
13.03
Personally
Identifiable
Information.
Without
limiting
the
generality of the above, System
Administrator warrants that it will protect any personally identifiable information (“PII”) belonging to
State’s employees or other contractors or members of the general public that it receives from State
or otherwise acquires in its performance under the MOU. For purposes of this paragraph:
13.03.01 PII has the meaning given in the Office of Management and Budget (OMB) Memorandum
M-17-12 Preparing for and Responding to a Breach of Personally Identifiable Information,
January 3, 2017; and

13.03.02 “protect” means taking measures to safeguard personally identifiable information and
prevent its data breach that are functionally equivalent to those called for in that OMB
Memorandum and elaborated on in the General Services Administration (GSA) Directive
CIO P 2180.1 GSA Rules of Behavior for Handling Personally Identifiable Information.
NOTE (1): For convenience of reference only, the OMB memorandum is available at:
https://dpcld.defense.gov/Privacy/Authorities-and-Guidance/
NOTE (2): For convenience of reference only, the GSA directive is available at:
https://www.gsa.gov/directive/gsa-rules-of-behavior-for-handling-personally-identifiable-information
-(pii)-
Section 14: Termination for Default
14.01. The State may terminate the MOU in whole or in part due to the failure of the System Administrator to
comply with any term or condition of the MOU, or to make satisfactory progress in performing the MOU. The
State shall provide written notice of the termination and the reasons for it to the System Administrator. Upon
termination under this paragraph, all documents, data, and reports prepared by the System Administrator under
the MOU shall become the property of and be delivered to the State on demand.
14.02. The State may, upon termination of this MOU, procure, on terms and in the manner that it deems
appropriate, materials or services to replace those under this MOU.
14.03 The System Administrator shall continue to perform, in accordance with the requirements of the MOU, up
to the date of termination, as directed in the termination notice.
Section 15: Signatures
All finalized attachments should be included for each party to review before signing. There should be the
corresponding number of original copies of the Agreement to sign as there are parties, for each party to have a
signed original for their official government record.
15.01
This Agreement is executed in duplicate originals.
[State of Arizona 9-1-1 Program] 
By:
Printed Name:Travis Jensen
Title:State of Arizona 9-1-1 Administrator
Date:
[9-1-1 System Administrator] 
By:
Printed Name:Chris Briggs
Title:Chief of Police
Date:
ATTEST:
_______________________________________
Julie K. Bower, City Clerk                  (SEAL)
APPROVED AS TO FORM:
_______________________________________
Michael D. Bailey, City Attorney