Jerry Schlesinger PMP Henry Unger EIDD Conveyance Jerry Schlesinger PMP Henry Unger

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

Emergency Incident Data Document EIDD Overview Emergency Incident Data Document

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

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

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

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

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

EIDD Organization

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

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)

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

EIDD Tables & Registries Emergency Incident Data Document

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

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

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

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

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

New Concepts Introduced Emergency Incident Data Document

Globally Unique IDs and 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

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

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

Secondary Unit Status Examples

More Examples

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

Emergency Incident Data Document EIDD Status Emergency Incident Data Document

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

Emergency Incident Data Document EIDD Conveyance Emergency Incident Data Document

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

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

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

EIDD “Push” Conveyance Emergency Incident Data Document

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

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

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

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

EIDD Conveyance via Subscribe/Notify Emergency Incident Data Document

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

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

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

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

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

EIDD Conveyance via Dereference Emergency Incident Data Document

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

Should Other Protocols be Supported? Emergency Incident Data Document

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

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

Emergency Incident Data Document Questions? Discussion? Emergency Incident Data Document