N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Emergency Incident Data Document (EIDD) Transfer

ProtocolsJerry Schlesinger, PMP – City of Portland OR

Daniel Mongrain –Bell Canada

Brian Rosen – Neustar

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Session Topics

EIDD Evolution and Current Status

EIDD Queries

EIDD Transport Mechanisms

Questions and discussions are encouraged – Feel free to speak up

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

What is an EIDD?

A standardized format for exchanging Emergency Incident InformationDefines the data elements that characterize

emergency incidents (incident type, location, etc.)

Groups data elements into logical data components (caller, incident, dispatch, etc.)

Establishes the relationship between data components

Developed by a joint APCO/NENA WG

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

What is an EIDD? (Cont.)

National Information Exchange Model (NIEM) conformantXML SchemaInformation Exchange Package

Documentation (IEPD)

In the process of becoming an American National Standard (ANS)

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Why Do We Need an EIDD?

NG9-1-1systems normally communicate with each other over IP-based networks Core services applications typically

communicate via SIP through the ESInetFunctional elements (FEs) within a PSAP

normally communicate over LANs and WANs

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Why Do We Need an EIDD? (Cont.)

FEs in different PSAPs need to communicate with each other through the ESInet and/or private networks

SIP and Web Services are the preferred methods for exchanging data through these networks

A standardized, non-proprietary method for exchanging incident information is needed

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

FEs Defined by NG-PSAP WG

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD Exchange Rules

DispatchManagement

Console

Mobile Data Computer

Vendor A

Login Service

Call Handling

Incident Record

Handling

Vendor B

EIDDs are required for information exchanges between two or more disparate manufacturer’s systems

EIDDs

EIDDs are not required within a single manufacturer’s system

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

More EIDD Exchange Rules

EIDD Users must be authorized to receive or view EIDD contentNeed to authenticate before receiving EIDDsEIDD contents filtered based on User’s role

EIDDs should be validated against the forthcoming EIDD ANS XML Schema

EIDDs should be validated against the business rules included in the EIDD IEPD ANS

Significant changes to an incident require an EIDD to be issued

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Typical EIDD Exchanges within PSAPs

Call Handling to Incident Handling Incident Handling to DispatchDispatch to Incident HandlingDispatch to Mobile DataMobile Data to DispatchAll FEs to Logging Services (recorder)Most interactions between FEs involve EIDD

exchanges

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Typical EIDD Exchanges between PSAPs

Call transfers – additional information collected at the original PSAP

Secondary PSAPs – Call takers to dispatchers located in a secondary PSAP

Dispatch/Incident Handling to Dispatch in different PSAP – Automatic/Mutual aid, responder status updates, etc.

Major Incidents – sharing incident information, requesting resources

Most interactions between NG9-1-1 systems involve EIDD exchanges

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Other EIDD Exchanges

PSAP to Emergency Management (filtered) PSAP to News Media (highly filtered) PSAP to Towing company

This can also be any company outside Public Safety that provide services on the scene of an Incident

CAD to RMS – follow up reports, archived information

Others we haven’t thought of yetResponders to hospitalSuggestions?

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD ANS Status

EIDD Information Document published on NENA Website (NENA-INF-005, 2/21/14)

EIDD WG moved from NENA to APCO to complete the EIDD ANS process

SEARCH developed a NIEM conformant IEPD based on the EIDD INF

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD ANS Status (Cont.)

WG reviewing/adjusting EIDD INF and IEPD

Identifying person and vehicle data elements – done

Updating IEPD and XML Schema as required – In progress

Insuring compatibility with i3 schemas

EIDD transport not currently addressed in the EIDD ANS

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD ANS Status (Cont.)

IJIS and APCO EIDD Springboard

Test feasibility of EIDD IEPD13 Vendors currently participatingWill certify vendor conformance with EIDD

ANS

EIDD ICE event – to be planned

EIDD ANS public review – 1st quarter of 2015** Estimate

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Transport Mechanism Status

STA-010.2 (08-003 V2) has EIDD transport in a SIP

transaction (as part of a call transfer) as well as a

“dereference” mechanism for EIDD-by-reference

Brian Rosen contributed a document to i3-arch

that contains a proposal for additional transport

options:

Subscribe/Notify

Asynchronous Push

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD Queries Supported through proposed subscription filters:

Incident Tracking ID – current status of incidentActive incident within an agency – returns list of

incident tracking IDsActive incident within a geographic area –

returns list of incident tracking IDsAll EIDDs for an Incident Tracking ID within a

time interval – returns latest updates

Not supported:All agencies involved in an incidentOthers?

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD Transport in 9-1-1 Calls

Required during a conference and/or transfer with another agency

EIDD is found in the Call-Info header, with a purpose of “eidd”

The INVITE includes the EIDD by value (actual data) or by reference (a link where to get the data) Reference embedded in Call’s SIP and EIDD retrieved

via dereferencing (HTTP GET) Embedded EIDD requires prior filtering Dereferencing enables filtering based on real-time

authentication

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Subscribe/Notify

FEs subscribe with each other for EIDD updates Subscribe by Incident ID to get all updates for

an Incident Subscribe for one NOTIFY per new Incident to

find out about incidentsFilter mechanism for subscriber to control

NOTIFYs it gets Rate Controls Content Controls (notify when certain sections

change)

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EIDD Transport – Subscribe/NotifyFE sends a notify to all subscribed systems

meeting filter criteria that an EIDD is available

Two protocol bases are being discussed to provide the Subscription/Notification service:SIP SUBSCRIBE/NOTIFY – EIDD included in the

body of SIP messages

<Mime header of application/emergency-incident-data-document+xml >

Web service

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Asynchronous EIDD Transport EIDDs are “pushed” to systems, requesting actions from

the receiving entities Normal “dispatch” type actions Request specific resources or actions

Receiving agencies set policies on the types of asynchronous EIDDs that they will receive, if any

Proposal uses the SIP MESSAGE method This leverages the ESRP’s Policy Routing Function to

route the request to the most appropriate agency at that time, similar to how calls are routed

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

Async EIDD Transport (Cont.)

Normal generic Dispatch request just has an EIDD

Receiving Agency Use OASIS EDXL-RM 1.0 resource management mechanism for incident in which the response is not obvious

Uses the EDXL “Distribution Element”

EDXL message included in the SIP MESSAGE body

Mime header of application/emergency-data-exchange-language+xml

Plus the EIDD

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

EDXL Message Types OASIS has specified appropriate EDXL message

types and responses Message types and responses included in EIDD

transport specifications Typical message types:

Request resource – request to receiving agency to dispatch resources to an incident

RespondToRequest – will agency provide requested resource; type and number provided

Requisition resource – can agency provide resources for incident

Wealth of other message types are available