Emergency Incident Data Document (EIDD) Transfer Protocols

1. Emergency Incident Data Document (EIDD) Transfer Protocols Jerry Schlesinger, PMP – City of Portland OR Daniel Mongrain –Bell Canada Brian Rosen – Neustar

2. Session Topics • EIDD Evolution and Current Status • EIDD Queries • EIDD Transport Mechanisms Questions and discussions are encouraged – Feel free to speak up

3. What is an EIDD? • A standardized format for exchanging Emergency Incident Information • Defines 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

4. What is an EIDD? (Cont.) • National Information Exchange Model (NIEM) conformant • XML Schema • Information Exchange Package Documentation (IEPD) • In the process of becoming an American National Standard (ANS)

5. 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 ESInet • Functional elements (FEs) within a PSAP normally communicate over LANs and WANs

6. 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

7. FEs Defined by NG-PSAP WG

8. EIDD Exchange Rules EIDDs are requiredfor information exchanges between two or more disparate manufacturer’s systems Call Handling Incident Record Handling Dispatch Management Console Login Service Mobile Data Computer EIDDs Vendor B Vendor A EIDDs are not required within a single manufacturer’s system

9. More EIDD Exchange Rules • EIDD Users must be authorized to receive or view EIDD content • Need to authenticate before receiving EIDDs • EIDD 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

10. Typical EIDD Exchanges within PSAPs • Call Handling to Incident Handling • Incident Handling to Dispatch • Dispatch to Incident Handling • Dispatch to Mobile Data • Mobile Data to Dispatch • All FEs to Logging Services (recorder) • Most interactions between FEs involve EIDD exchanges

11. 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

12. 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 yet • Responders to hospital • Suggestions?

13. 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

14. 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

15. EIDD ANS Status (Cont.) • IJIS and APCO EIDD Springboard • Test feasibility of EIDD IEPD • 13 Vendors currently participating • Will certify vendor conformance with EIDD ANS • EIDD ICE event – to be planned • EIDD ANS public review – 1st quarter of 2015* * Estimate

16. 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

17. EIDD Queries • Supported through proposed subscription filters: • Incident Tracking ID – current status of incident • Active incident within an agency – returns list of incident tracking IDs • Active incident within a geographic area – returns list of incident tracking IDs • All EIDDs for an Incident Tracking ID within a time interval – returns latest updates • Not supported: • All agencies involved in an incident • Others?

18. 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

19. 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 incidents • Filter mechanism for subscriber to control NOTIFYs it gets • Rate Controls • Content Controls (notify when certain sections change)

20. EIDD Transport – Subscribe/Notify • FE 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

21. 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

22. 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

23. 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