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

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/2016 - 2

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/2016 - 3

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/2016 - 4

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/2016 - 5

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/2016 - 6

EIDD Organization 10/20/2016 - 7

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/2016 - 8

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/2016 - 9

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/2016 - 10

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/2016 - 11

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/2016 - 12

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/2016 - 13

Turning Local Into Global Values Globally unique unit/emergency resource IDs Unit 1603  1603@police.portland.or.us Globally unique agent IDs John G. Jones  johngjones@boec.psap.or.us Globally unique position IDs Call taker #2  2@boec.psap.or.us 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/2016 - 14

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/2016 - 15

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/2016 - 16

Questions? 10/20/2016 - 17