1. The Emergency Incident Data Document (EIDD)
Jerry Schlesinger, PMP
President, Intelligent Systems, Inc.

2. What 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
10/20/

3. Why Was The EIDD Developed?
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
Standard method for exchanging incident information was needed
The EIDD was developed over the last 8+ years to provide a method for exchanging emergency incident related information within NG9-1-1
10/20/

4. EIDD Supported Data Exchanges
Public safety systems – NG functional elements
Inside a PSAP (call handling to dispatch – ANI/ALI, Dispatch to responder – Mobile Data FE, etc.)
Between PSAPs (automatic aid, CAD to CAD, call transfer)
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
10/20/

5. 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.)
10/20/

6. EIDD Contents (cont.) Involved people and vehicles
Responder information (primary and secondary statuses, location, responder entered information)
Disposition (primary and multiple secondary
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/20/

7. EIDD Organization
10/20/

8. What EIDDs Do Not Contain
Historical information – EIDDs only exchange current information about an incident
Streaming media – EIDDs contain reference URIs and URLs for retrieval, but not the media 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)
10/20/

9. 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)
10/20/

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

11. Information Exchange Issues
Use case: CAD to CAD (mutual/automatic aid, etc.)
Receiving PSAP must react appropriately to information received via EIDDs
Auto accident with injuries: original PSAP  ACWI
receiving PSAP  226
Residential structure fire: original PSAP  StFire
receiving PSAP  RStFire
How will receiving PSAP know what resources to dispatch?
10/20/

12. EIDD Registry & Table Solution
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
10/20/

13. 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
Emergency resource type
Unit status
10/20/

14. Turning Local Into Global 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
10/20/

15. 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
Joint APCO/NENA EIDD conveyance and management WGs developing next phase
Two EIDD testing events are being planned:
NENA ICE 7 – scheduled for Spring of 2017
APCO–IJIS Springboard initiative – planning stage
10/20/

16. Initial Conveyance Standard
Three conveyance methods supported
Push via SIP – uses OASIS EDXL-RM messages + EIDD
Subscribe / Notify via SIP
Dereference via HTTP GET
Authentication credentials used to manage data right access
Subscribe Notify supports:
Rate – how often EIDDs are sent
Location – within geographic area
Content filters – type of incidents, etc.
Other protocols awaiting appropriate contributions
10/20/

17. Questions?
10/20/