2. Jerry Schlesinger PMP Henry Unger
EIDD Conveyance
Jerry Schlesinger PMP
Henry Unger

3. Agenda EIDD Overview EIDD Tables and Registries New EIDD Concepts
EIDD Status
EIDD Conveyance
EIDD Conveyance Rules
Push Transport (SIP)
Subscribe/Notify (SIP)
EIDD by Reference (HTTP Get)
Other Protocols
Open Discussions and Issues Resolution

4. Emergency Incident Data Document
EIDD Overview
Emergency Incident Data Document

5. Data Exchanges in NG9-1-1
i3- and ESInet-based applications use Internet Protocol (IP) to communicate with each other
i3 defines how media (voice, SMS, video, etc.) are exchanged between NG9-1-1 applications
Need a standardized method for exchanging incident related information between Functional Elements (FEs)
The EIDD was developed over the last 8+ years to provide a method for exchanging incident related information

6. EIDD and i3 (NG9-1-1) EIDD provides a standardized format for:
Exchanging emergency incident information between NG-911 FEs (Call Handling, Incident Handling, Dispatch, etc.)
Exchanging information between PSAPs, disparate manufacturers’ systems (CAD-to-CAD), and between other authorized systems
Required for call transfers – preserves call information

7. What exactly is an EIDD?
NIEM-conformant, XML-based data exchange format
Contains detailed information about emergency incidents
Contains status and location information about responding units
Organized into interrelated data groups
Each data group contains multiple data elements
Uses tables and registries to enable interoperable data exchanges

8. Information Carried by EIDDs
Common incident information (type, priority, tracking ID, incident location, status, etc.)
Notes/comments about incidents, time stamped
Dispatch information (who and what was dispatched when)
Agent and agency information (who entered what, when, dispatching agency, dispatched agency, agency contact information, etc.)
Call information (telephone numbers, call ID, cell towers, caller location, etc.)

9. EIDD Contents (cont.) Involved people and vehicles
Responder information (primary and secondary statuses, location, responder entered information)
Disposition (primary and multiple secondary dispositions)
Location of streaming media related to the incident
Alarm/sensor information
Related incidents (parent/child or simply related)
Other incident-related information (split, merge, etc.)

10. EIDD Organization

11. EIDD Contents (cont.)
Historical information – EIDDs only exchange current information about an incident
Streaming media – EIDDs contain references for retrieval, but not the content itself
May not be a complete, self-contained state of an incident
Composite views are available, but may need to be requested
EIDDs may contain either all incident information or only changed incident information (delta)
Confidential information the recipient is not authorized to access

12. Some EIDD Exchange Rules
EIDDs must be logged:
When an EIDD is sent
When an EIDD is received
EIDD users must be authorized to receive or view EIDD content
Users need to be authenticated before receiving EIDDs
EIDD contents are filtered based on recipient’s role
The transport of EIDDs must be secure (encrypted)

13. Another EIDD Exchange Rule
Logging Service
Call Handling
Incident Handling
Vendor B
Dispatch
Management Console
Mobile Data
Vendor A
EIDDs are required for information exchanges between two or more disparate manufacturers’ systems
EIDDs
EIDDs are not required within a single manufacturer’s system
CAD
CPE

14. EIDD Tables & Registries
Emergency Incident Data Document

15. Who/What Exchanges EIDDs?
Public safety systems – NG functional elements
Inside a PSAP (call/incident handling to dispatch, ANI/ALI)
Between PSAPs (automatic aid, CAD to CAD)
PSAPs to other public safety agencies
CAD to RMS
CAD to EOC
PSAP to Homeland Security (Feds)
PSAPs to other authorized agencies
Tow truck companies
Ambulance companies
News media

16. Information Exchange Issues
PSAP Examples: CAD to CAD, mutual/automatic aid, etc.
The receiving PSAP must understand and react appropriately to incidents and status updates received via EIDDs
The original PSAP will classify the incident based on its own tables and policies
Auto accident with injuries in original PSAP  ACWI
Auto accident with injuries in receiving PSAP  226
Residential structure fire in original PSAP  StFire
Residential structure fire in receiving PSAP  RStFire
How will the local PSAP know what resources to dispatch

17. EIDD Registry & Table Solution
Unrealistic that incident codes would be uniform across North America (and beyond?)
EIDD registries define global incident types that are readily understood by PSAPs receiving EIDDs
Originating PSAP translates local codes to global EIDD registry codes
Receiving PSAP translates global EIDD codes to local codes
Local PSAP applies local dispatch policies to the incident

18. Local and Global Data Elements
EIDD registries define global data elements
Incident codes/types
Incident status
Disposition codes
EIDDs carry local data elements for these registry values
EIDDs include global data elements with local equivalents:
Incident tracking ID – local incident id
Common incident priority – local priority
Unit/resource IDs must be globally unique – local IDs
Tables must be set up to translate between internal and global values
Emergency resource type
Unit status

19. EIDD Registries Most EIDD registries are unique and stored on NRS
Some EIDD registries are defined by other standards.
Example: Incident Type EIDD Registry:

20. New Concepts Introduced
Emergency Incident Data Document

21. Globally Unique IDs and Values
Globally unique unit/emergency resource IDs
Unit 1603 
Globally unique agent IDs
John G. Jones 
Globally unique position IDs
Call taker #2 
Globally unique priority levels
Common priority levels are 0 to 10, with 10 the highest
Code blue  priority 10
Translation/conversion occurs behind the scenes

22. New Status Philosophy EIDDs separate incident status from unit status:
Incident status historically associated with unit statuses
Incidents now have their own set of statuses:
Resources assigned
Resources en route
Resources on scene
Structure cleared

23. New Unit Status Philosophy
Unit statuses – divided into primary and secondary statuses
Primary statuses – define unit’s availability for dispatch
Only one of three primary unit status values are allowed:
Available
Not Available
Conditionally Available
Multiple secondary statuses further refine the primary status
Why is a resource not available? – assigned and en route
Where is a resource available? – at headquarters
Why is a unit available? – on duty and in service

24. Secondary Unit Status Examples

25. More Examples

26. GIS Data Carried by EIDDs
All GIS data containing civic addresses embedded in an EIDD must be in PIDF-LO format (RFC 5139)
PIDF-LO is a standard, interoperable format
Consistent with i3 usage
Separates address into components (street number, directional, street name, street type, etc.)
When transferring calls, ALI must be decomposed into component parts

27. Emergency Incident Data Document
EIDD Status
Emergency Incident Data Document

28. Current EIDD Status EIDD American National Standard
Has completed ANSI’s public review period
All comments were adjudicated
Will soon be published by APCO and be available as an American National Standard
EIDD conveyance and management WGs working on next phase
Two EIDD testing events are being planned:
NENA ICE 7 – scheduled for Spring of 2017
APCO–IJIS Springboard initiative – planning stage

29. Emergency Incident Data Document
EIDD Conveyance
Emergency Incident Data Document

30. EIDD Conveyance Rules
Most interactions between FEs in a PSAP involve sending and receiving EIDDs
Almost all interactions between FEs located in disparate PSAPs involve sending and receiving EIDDs
All sent and received EIDDs must be logged as specified in NENA STA- 010
When a “Relevant Change” in incident information occurs, all subscribed FEs must be informed through the conveyance of an EIDD
Agencies receiving a call must log an EIDD containing the known information about the call
Agencies creating an emergency incident outside of a call must log an EIDD for the incident

31. EIDD Logging Requirements
Along with logging the contents of sent and received EIDDs,
Senders must log time and recipient
Recipients must log time and sender
Transmission errors must be logged
Transmission retries must be logged
If the maximum number of retries occurs, an alarm condition must be logged

32. EIDD Data Rights Management
Conveyance of EIDDs must comply with the data rights management policy of the agency that created the data
The contents of an EIDD must be filtered to comply with the data rights policies of the agency owning (creating) the data
Data right policies are stored in an agency’s policy store
Data elements are filtered based on the agency and role of the recipient
Data rights policies must conform with legal requirements (local, state, federal, etc.)

33. EIDD “Push” Conveyance
Emergency Incident Data Document

34. EIDD Conveyance via “PUSH”
Unsolicited EIDDs can show up at an agency (FE within an agency)
Agencies may control the receipt of unsolicited EIDDs by:
Specific agency designation
Agency role/type
Geographic area
Receiving agency needs to know “why” the EIDD was sent to them

35. EIDD “PUSH” – Prior Agreement
Example: Primary PSAP to Secondary PSAP
EIDD contained in the body of a SIP message
MIME type of application/emergency-incident-data- document+xml (contains a fully populated EIDD)
Standard SIP transaction semantics and error messages apply
Agency Locator and/or ECRF can be queried to find the desired agency
The History-Info header must be used to mark any redirection of the message
Vias must be preserved
Normal SIP loop detection applies

36. EIDD “PUSH” – Unsolicited
Agency needs specific assistance or resources
OASIS EDXL-RM 1.0 resource management mechanism
Uses the EDXL Distribution Element
Body of the SIP MESSAGE contains the EDXL-RM message
EDXL message explains why the EIDD was sent
SIP Header Stuff
EDXL Message
EIDD Information
SIP Message Body

37. OASIS EDXL-RM Messages
EIDD “PUSH” supports all EDXL-RM message types including:
RequestResource
ResponseToRequestResource
RequisitionResource
CommitResource
RequestInformation
ResponseToRequestInformation
OfferUnsolicitedResource
RequestResourceDeploymentStatus
ReleaseResource
EIDD Conveyance ANS identifies EDXL-RM message format constraints for sending EIDDs; receipt supports standard format
RequestReturn
ResponseToRequestReturn
RequestQuote
ResponseToRequestQuote
ReportResourceDeploymentStatus
RequestDeploymentExtendedDuration
ResponseToRequestDeploymentExtended Duration

38. EIDD Conveyance via Subscribe/Notify
Emergency Incident Data Document

39. Subscribing for EIDDs
An FE can subscribe to one or more other FEs for EIDDs
Subscription specifies the conditions under which EIDDs will be sent including:
Specific incident (Incident Tracking ID)
All new incidents handled by the FE for which an EIDD is sent
Subset of new incidents handled by the FE (within a geographic area, specific incident types, etc.)
SIP SUBSCRIBE/NOTIFY mechanism is used similar to how it is described in NENA STA-010

40. SIP Subscribe/Notify Mechanism
Event Package Name: nena-EIDD
Event Package Parameters:
IncidentId: all updates related to an Incident Tracking ID
Blank/Null: all new incidents for which an EIDD is generated
SUBSCRIBE Bodies:
Standard RFC4661 protocol
Extension filter specifications may be included and must at least support:
Rate
Location
Content filters

41. Subscription Duration & Format
Default is one hour
1 minute to 24 hours is acceptable
Subscription terminates when:
Specified duration ends
Processing by the notifier of the Incident Tracking ID ends
Notify Body:
Parameter
Condition
Description
EIDD
Mandatory
Emergency Incident Data Document

42. Subscribe/Notify Processing
SUBSCRIBE request processing:
Notifier consults policy to determine if subscriber is authorized to subscribe
Notifier returns appropriate response (603 or 202)
Notification processing:
Notifier sends all new EIDDs that meet subscription to subscribers
Notifier first filters EIDD based on data rights policies
Only one EIDD is sent to subscribed FEs that have not subscribed to the specific Incident Tracking ID
If the subscriber wants updates it must subscribe with the notifier for the specific Incident Tracking ID

43. Subscribe/Notify Processing (cont.)
Subscriber processing of notifications
Specific action is not required
Normal SIP loop detection applies
Forked request handling – not used in this application
Notification Rate
Notifier may not send updates more often than requested
Notifier may send updates less frequently than requested
Notifier may refuse rate if policy dictates
State Agents
No special processing is required
EIDDnoteUpdateFilter may be used to specify when to send notes (every character, every 80 characters, etc.)

44. EIDD Conveyance via Dereference
Emergency Incident Data Document

45. EIDD Dereference Processing
Agency places EIDD on a webserver
URI for the EIDD is exchanged with entities wishing to dereference it
An HTTP GET can be used with the URI to retrieve the EIDD
Separate URIs are required depending on the data rights privileges of the agency/user dereferencing the EIDD
Dereference using an incident tracking ID
Agencies may support an EIDD URL source that can be used to dereference EIDDs for specified Incident Tracking IDs
An HTTP GET with a single parameter of “incidentId” returns a URI for the Incident
An HTTP GET with that URI will return the EIDD
Separate URIs may need to be generated based on the data rights privileges of the entity requesting the information

46. Should Other Protocols be Supported?
Emergency Incident Data Document

47. Exchanges Without SIP
Use cases where systems agree to exchange emergency incident information with each other:
Dispatch FE to Records Management System
EIDD transferred upon dispatch, 1st unit on scene, incident closure
Enables responders to write follow-up reports
CAD to tow truck company – whenever a tow is requested, an EIDD is used to send the relevant incident information to the tow truck company
Dispatch and News Media data warehouse
Filtered incident information made available to the news media in a timely manner
Enables PSAP personal to concentrate on their priority tasks without interacting with journalists
Public can keep track of what is happening in their neighborhoods

48. Simple Web Services Solution
Involved agencies codify agreements (contracts) that enable the systems to share EIDDs via web services
Whenever a system generates an EIDD, Web Service WSDL is used to transfer the information to the other system
Authentication is not required as the participating systems are well known to each other
Filtering can be employed as required by the applications
Data owners explicitly identify the information that will be shared
Simple, cost-effective way to share incident information
Including it in the standard enables agencies to request the capability in their RFPs

49. Emergency Incident Data Document
Questions? Discussion?
Emergency Incident Data Document