NENA Knowledge Base

EIDO & IDX FAQ (Frequently Asked Questions)

Revision as of 17:27, 13 August 2018 by MikeVislocky (talk | contribs) (Updated to more closely match FAQ published on nena.org)

Test Page Note. The same content is shown in a table format here: EIDD Frequently Asked Questions (test page for table format). Before deciding a preference for either the table or non-table format, please view the pages on as many devices as possible, including desktop, tablet, and smart phone.

If you have questions about EIDDs that are not answered here, put them in the Discussion page. You can also use the Discussion page to submit comments, suggestions, or improvements on the answers you see here.

EIDD Basics

What is an EIDD?

"EIDD" is an abbreviation for Emergency Incident Data Document.

Here's the official NENA Master Glossary definition:

A National Information Exchange Model (NIEM) conformant object that is used to share emergency incident information between and among authorized entities and systems.

Here are some other ways to describe an EIDD:

The EIDD and its conveyance mechanisms replace the serial port data connection between CPE and CAD, as well as providing a standardized CAD to CAD interface. It standardizes incident status update mechanism, between responders and agencies, between agencies working multi-agency incidents, and also provides a standardized way to send incident data to EOCs, tow truck operators, utilities and even news organizations.

Why do we need EIDDs?

We need a way for one system that has information about an incident to send that information to another system using a standard format. That way, both systems can understand the information, even if the systems are from different vendors or operated by different agencies. In NENA documentation, these systems are often also called functional elements (FE).

Where are the EIDD specifications?

There are several documents where the specifications and requirements relating to EIDDs are published:

NENA Working Groups are currently developing additional documentation for EIDDs and their use:

What kind of information is in an EIDD?

An EIDD contains information about a single incident including: the calls related to that incident, the responders assigned to the incident, the participants and vehicles involved in the incident, etc. EIDDs will often include the caller's information like name, number, and location. EIDDs can also include agents' notes, information about responder equipment, agencies involved in the incident, and lots of other incident information. You can find details on all of the kinds of information that can be transferred in an EIDD in the NENA/APCO Emergency Incident Data Document (EIDD). There is also a handy Excel spreadsheet guide to all of the kinds of XML elements that there can be in an EIDD in the EIDD Mapping Spreadsheet.

Is there a standard XML schema for the EIDD?

Yes. The NIEM-Conformant IEPD (Information Exchange Package Document) is available here: NIEM IEPD (Schemas & other documents)

What is the relationship between an incident record and EIDD?

An incident record is an internal representation of the incident information and is typically proprietary to an agency’s system. An EIDD is an external representation of the current state of an incident as known by the sending FE.

Does the user have to push a “send EIDD” button to send EIDDs to other systems?

No – the system sends EIDDs to other systems when the Incident state changes, whether because a user entered something, or because the system received automated data like the location of an assigned unit. For user-entered information, there may be a “save” or “commit change” button, but it’s really the fact that the Incident state has changed that triggers EIDDs being sent, rather than the button push.

How are EIDDs generated?

An EIDD is a data object, an XML data object specifically. EIDDs are generated by software in response to changes in incident status. Some EIDDs may be generated as a result of human action like choosing a responder in a dispatch (“CAD”) system. Some may be generated automatically, like a change in a responding vehicle’s location determined by an AVL system. EIDDs will not be displayed to users directly. Some user interface may (or may not) change in response to receipt of an EIDD, but that depends on the function of the user interface and its implementation. EIDDs are computer to computer notifications of incident state, as known by the sender, at the time it was sent. They are standardized to allow call (“CPE”) to dispatch (“CAD”), CAD to CAD, CAD-to-responder (e.g MDT), PSAP to EOC, or any other systems from multiple vendors to interoperate where incident state is exchanged.

Is an EIDD a complete record of the call, or something less?

No, an EIDD represents the state of an Incident, which may have zero or more Calls associated with it. An EIDD also represents the state of an incident at the time it was sent, as known by the system or agency that sent it. (See EIDD FAQ# 10)

If an EIDD is not a complete record of the call, how does that look?

An EIDD only includes INCIDENT (not just “call”) information as known by the FE that is generating the EIDD at the time it was sent. If there is a change in the state of an incident, that change is included in a new EIDD. The EIDD has no incident history.

Is an EIDD only a snapshot in time that carries data from one point to another?

Yes.

Does the EIDD accumulate the entire data exchange record?

No. The accumulation of the entire data exchange record for an Agency is located in the Agency’s logger(s).

How does an FE or Agency get an EIDD?

The EIDD Conveyance working group is writing standards that define how EIDDs are sent ("conveyed”). Current draft text provides several mechanisms including a “push” mechanism where the FE that creates the EIDD sends it to some other FE without any prior action by the recipient. This is used in, for example, a typical dispatch operation, where the sending FE (for example, the Call Handling FE) sends an EIDD to, for example, a Dispatch FE, to request dispatch. The sender includes in the EIDD what it knows about the incident and the recipient does whatever it believes is appropriate for that incident.

There is also a proposed “pull” operation where the receiver asks (in advance) with a subscription mechanism to receive EIDDs based on a “filter” specification. The subscription mechanism is typically used to get periodic updates of incident state as an incident progresses. It can also be used to inform an agency of new incidents opened by the sender that match a set of criteria specified in the subscription.

If an EIDD is only a snapshot in time, where are the EIDD transactions logged?

EIDDs must be logged when they are sent. To get history, you query the logger of the sender. EIDDs may be logged by the recipient. If they are, you can get history from the recipient’s logger, but the sender’s logger is “authoritative”.

Does an EIDD have a complete history of the incident at the time it is first generated and then only updates after that?

An EIDD represents the state of an incident as known by the sender at the time the EIDD was sent. The EIDD is a snapshot in time, not a complete history. If the recipient uses the subscription mechanism, then whenever the state changes sufficiently, the sender will create a new EIDD and send it. That updates the incident at the recipient. At present, the draft conveyance text expects each EIDD to contain the entire state of the incident as known by the sender, and not changes to the state. If the recipient needs to know what happened before an EIDD was sent, they get it from the logger. If they need to know the state after an EIDD was sent, they subscribe to the incident at the sender, and they will get new EIDDs when state changes.

Other i3 data items can be sent “by value” or “by reference”. What does EIDD transmission use?

The current draft conveyance offers both in some circumstances. Most transmission is “by value”, but an FE can create a URI which, when dereferenced, would return the current EIDD (value). Similarly, an FE can create a URI which is used with the subscription service to receive EIDDs. The subscription URI is another form of EIDD by reference.

How is a Reference obtained?

A reference may be obtained from a transferred call in the SIP signaling. The “Service and Agency Locator” can return a URL for an agency ’s “EIDD reference factory” service, which, when queried with an incident ID, returns a URL that can be used with the dereference service. As above, the FE can also create a subscription URI which also is a form of EIDD by reference.

How do I control what EIDD information is made available?

As with all i3 services, the content of the EIDD, the subscription service, the dereference service and the reference factory service responses are all subject to the agency’s Data Rights Management policy, and thus the EIDD owner determines who can use these services and what data they can obtain from these services.

When an EIDD payload is done by-reference, how does that look?

An FE can generate a URI and distribute the URI. An FE in possession of the URI “dereferences” it by using an HTTP Get operation, which access’s a dereference service, which returns the then-current value of the EIDD. If the GET is repeated later, a new EIDD with current state is returned.

When does an EIDD get generated from triggered events (e.g., note-taking?

In general, any event which would change the state of an incident sufficiently such that at least one field of the EIDD would change is sufficient to generate a new EIDD. However, with the subscription service, the recipient can specify content, rate and/or location filter criteria that affects when it receives EIDDs. All filters can reduce the number of EIDDs sent, but the rate filter also has a minimum rate specification, which if used can cause an EIDD to be sent even when no value changes.

Sending EIDDs

What functional elements can send or receive EIDDs?

The functional elements in NG9-1-1 that can send or receive EIDDs are shown here: FE (Functional Element)

When does a functional element send an EIDD?

A functional element sends an EIDD when it detects a change in the status of an incident. Want some examples? They're next.

What are some examples of when an EIDD would be sent?

  • A call-handling FE would send an EIDD to the incident-handling FE when a call arrives. The EIDD would include the caller information that came with the call's signalling data.
  • The same call-handling FE would send another EIDD to the incident-handling FE when the call is answered. That EIDD would add the identity of the agent that answered the call and other information.
  • If the call-taker types notes, an EIDD with the notes, agent's identification, etc. would be sent from the incident-handling FE to the dispatch FE.
  • If a dos[atcher dispatches a firetruck, an EIDD with the details would be sent to incident handling, and maybe call-handling so the call-taker would know.

EIDD Contents

What information does a functional element put in an EIDD when it sends one?

An FE puts information about the current state of the incident that it "knows". Depending on which FE generates an EIDD, it might include the caller's information like name, number, and location. EIDDs can also include agents' notes, information about responder equipment and lots of other incident information.

You can find details on all of the kinds of information that can be transferred in an EIDD in the NENA/APCO Emergency Incident Data Document (EIDD).

There is also a handy Excel spreadsheet guide to all of the kinds of XML elements that can be in an EIDD in the EIDD Mapping Spreadsheet.

Does an EIDD include voice or other media?

No, but it may contain links where various forms of media can be accessed.

EIDD Transport

What protocol is used to send EIDDs from one element to another?

There is a SIP-based transport specification in development and an HTTP-based specification suggested.

IDX (Incident Data eXchange)

What is the IDX?

The IDX (Incident Data eXchange) is a functional element that receives EIDDs from other elements in a PSAP and aggregates the information in order to send a consolidated view of an incident upon to subscribers.

Who subscribes to an IDX

Subscribers can be elements both within and outside of the PSAP. They may be regional or state agencies inside an ESInet and they may be outside agencies or services.

What are examples of outside agencies or services.

Outside recipients of EIDDs might include power and gas utilities, ambulance services, hospitals, U.S. government agencies like the DHS (Department of Homeland Security), towing services, etc.

Retrieved from "https://kb.nena.org/wiki/EIDO_%26_IDX_FAQ_(Frequently_Asked_Questions)?oldid=3588"