EIDO & IDX FAQ (Frequently Asked Questions)

NOTE: "EIDO" refers to a JSON - formatted Emergency Incident Data Object. The EIDO specification in development is based on the NENA/APCO-INF-005.1 EIDD Information Document and other NENA documents that refer to "EIDDs" which describe XML - formatted documents.

The answers shown here are based on the point in time when they were provided, based on the then current applicable specifications. All answers are subject to change if the applicable specifications change. NENA will endeavor to keep this document in sync with any changes made in the applicable specifications that would cause these answers to be outdated. Those applicable specifications (Standards) are the normative source, and this document is informative.

EIDO Questions & Answers

What is an EIDO?

"EIDO" is an abbreviation for Emergency Incident Data Object.

Here's the draft NENA Master Glossary definition:

A JSON-based object that is used to share emergency incident information between and among authorized entities and systems.

Here are some other ways to describe an EIDO:

The EIDO 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 EIDOs?

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 EIDO specifications?

There are several documents where the specifications and requirements relating to EIDOs are published or being developed:

• The EIDO specifications are being developed from the NENA/APCO-INF-005.1 EIDD Information Document
• The requirements for PSAP functional elements for sending and receiving EIDOs are included in the NENA/APCO NG9-1-1 PSAP Requirements Document where they were described as "EIDDs".
• EIDOs used for transferred calls and other aspects of EIDOs are published in NENA-STA-010 Detailed Functional and Interface Standards for the NENA  i3 Solution

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

• EIDO Conveyance: Conveyance of Emergency Incident Data Document (EIDO) Working Group
• EIDO Management: Management of Emergency Incident Data Documents (EIDO)
• IDX Functional Element: i3 Architecture
• EIDO Specifications for NG9-1-1 PSAP Functional Elements: NG9-1-1 PSAP SYSTEMS where they were described as "EIDDs".

What kind of information is in an EIDO?

An EIDO 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. EIDOs will often include the caller's information like name, number, and location. EIDOs 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 EIDO in the NENA/APCO-INF-005.1 EIDD Information Document.

Is there a standard JSON schema for the EIDO?

The JSON EIDO schema is under development.

What is the relationship between an incident record and EIDO?

An incident record is an internal representation of the incident information and is typically proprietary to an agency’s system. An EIDO 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 EIDO” button to send EIDOs to other systems?

No – the system sends EIDOs 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 EIDOs being sent, rather than the button push.

How are EIDOs generated?

An EIDO is a data object, a JSON data object specifically. EIDOs are generated by software in response to changes in incident status. Some EIDOs 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. EIDOs will not be displayed to users directly. Some user interface may (or may not) change in response to receipt of an EIDO, but that depends on the function of the user interface and its implementation. EIDOs 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 EIDO a complete record of the call, or something less?

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

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

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

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

Yes.

Does the EIDO 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 EIDO?

The EIDO Conveyance working group is writing standards that define how EIDOs are sent ("conveyed”). Current draft text provides several mechanisms including a “push” mechanism where the FE that creates the EIDO 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 EIDO to, for example, a Dispatch FE, to request dispatch. The sender includes in the EIDO 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 EIDOs 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 EIDO is only a snapshot in time, where are the EIDO transactions logged?

EIDOs must be logged when they are sent. To get history, you query the logger of the sender. EIDOs 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 EIDO have a complete history of the incident at the time it is first generated and then only updates after that?

An EIDO represents the state of an incident as known by the sender at the time the EIDO was sent. The EIDO 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 EIDO and send it. That updates the incident at the recipient. At present, the draft conveyance text expects each EIDO 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 EIDO was sent, they get it from the logger. If they need to know the state after an EIDO was sent, they subscribe to the incident at the sender, and they will get new EIDOs when state changes.

Other i3 data items can be sent “by value” or “by reference”. What does EIDO 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 EIDO (value). Similarly, an FE can create a URI which is used with the subscription service to receive EIDOs. The subscription URI is another form of EIDO 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 “EIDO 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 EIDO by reference.

How do I control what EIDO information is made available?

As with all i3 services, the content of the EIDO, 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 EIDO owner determines who can use these services and what data they can obtain from these services.

When an EIDO 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 EIDO. If the GET is repeated later, a new EIDO with current state is returned.

When does an EIDO 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 EIDO would change is sufficient to generate a new EIDO. However, with the subscription service, the recipient can specify content, rate and/or location filter criteria that affects when it receives EIDOs. All filters can reduce the number of EIDOs sent, but the rate filter also has a minimum rate specification, which if used can cause an EIDO to be sent even when no value changes.

Does the EIDO calltaker note data component, or any other data component that contains multi-line text get generated after a single character is typed, and after every character is typed, or only when the creator ‘saves’ or otherwise causes the entry to be captured into an EIDO?

The current proposed transport draft uses Subscribe/Notify to send updated EIDOs. The mechanism includes filters that allow the recipient to control the rate of transmission. The sender can decide how often to send updates, which could be as often as every character, or as little as complete notes. The recipient can limit how often it receives EIDOs using the rate filters.

The NENA-APCO EIDD INF document says that an EIDD does not provide historical data. What does that mean?

The EIDO specification that is being developed from the NENA/APCO-INF-005.1 EIDD Information Document indicates that the EIDO only includes the entire (not delta) CURRENT ‘state’ of the incident, as known by the sender. Historical data is stored in, and retrieved from the logging service.

How do I determine that something has changed during the course of an incident?

At least one field will be different from the previous EIDO received for this incident, but see below*. The EIDO itself doesn’t indicate that something changed. The UI determines what the agent/user becomes aware of, and how they are notified.

* The conveyance document describes the use of “rate” filters, one of which is a minimum rate. An EIDO may be sent to achieve the minimum rate, which may not have any fields different from the prior EIDO.

Where do EIDO data files get stored?

They don’t get stored. There is no such thing as a “EIDO data file”. EIDOs sent are logged, so there is a copy in the logging service of the sender. Received EIDOs may be logged, so there may be a copy in the logging service of the recipient. Anything else is implementation dependent. Systems that exchange EIDOs probably store the information in their own incident record. Neither the EIDO standard nor STA-010 define how the data in EIDO messages must be physically stored in FEs that exchange EIDO messages.

Is there a way to show the recipient that current data within the EIDO is not the original data (e.g., location data was updated/changed – is there indication of this to the PSAP)?

No, but the history is in the logging service.

When is a new EIDO sent?

An EIDO is sent when a significant change in incident state changes. At minimum, at least one data component in the EIDO has to change from the prior EIDO sent for this incident. Also see EIDO FAQ# 1.20, and EIDO FAQ# 1.23.

Policy in the sender may restrict sending an EIDO when there are what it considers minor values that ARE visible in a data component. The usual example is location of a responding unit.

Is it going to create a trail for us follow?

The “trail” is in the logger.

Does it create a map?

EIDOs don’t create a map. Information in the EIDO can be used by the User Interface to create or update a display that may include a map.

Will actions such as rebid create another EIDO?

“Rebid” would create a new EIDO if and only if the response changes by some policy determined value AND the filter for the recipient requests it.

What is the difference between an EIDO vs Incident Record

“Incident Record” is not standardized, EIDO is. An implementation may have more data (non-standardized) in its local incident record than in an EIDO.

(Also see EIDO FAQ# 1.6)

What notes are updated?

There is a data component in an EIDO that is called a note, and there are references to notes in several other data components. You can “update” any note, just like you can “update” any other data component. You send an EIDO that has a change in that data component.

Which PSAP workflows will generate an EIDO?

EIDOs are sent when a new incident is generated (either receipt of call or a self-declared incident), and whenever state changes. State changes are determined by the EIDO data components: when any of those data components has at least one element that changes, the agency that determines the changes sends EIDOs. Events that might cause an EIDO to be sent include (not limited to):

• Call Handling (call received, answered, transferred, terminated)
• Dispatch operations (request another agency dispatch, or select a unit to dispatch)
• Incident classification
• Responder unit reports (arrived on scene, determination of victim/perpetrator/witnesses,
• Clearing operations

How is access to the information in an EIDO controlled?

Standard NG9-1-1 Data Rights Management mechanisms apply to EIDOs. There are restrictions on what data may be passed to an agency that the sender received from another agency.

Data rights management for data received from another agency requires additional development work. In the meantime, a way to control access to 3rd parties is to give a link to the data, rather than the data itself (by ref versus by value).

How are new values for the ‘Reason for Issue’ field in the EIDO generated?

Reason for Issue values are defined in a Registry managed by the NENA Registry System. Creating a new value requires a specification document and expert review.

An EIDO contains Current State. What does Current State always include?

Current state, as known by the entity sending the data at the time the EIDO was sent, will include the data components that the sender is aware of, which may differ at any point in time. However, several elements are always included in an EIDO. Those are listed as ‘mandatory’ elements in the EIDO header.

IDX Questions and Answers

What is the purpose of an IDX?

An Incident Data Exchange (IDX) is a functional element that aggregates EIDO information from multiple FEs within an agency and creates a composite EIDO that represents the entire state of an incident as known by the agency at the time the aggregated EIDO was sent by the IDX. To accomplish this task, the IDX receives EIDOs from all the constituent FEs within the agency and combines them using an algorithm to create a single composite EIDO. FEs or agencies inside or outside the agency can then obtain the composite EIDO from the IDX. There is a second type of IDX that coalesces information from more than one IDX for a multi-agency incident. It is called the Inter-agency IDX. The Inter-agency IDX obtains EIDOs from all the agencies involved in an incident and creates a composite view of the incident from the constituent EIDOs. Any (authorized) agency can then get a unified view of the incident by obtaining an EIDO from the Inter-agency IDX.

Where are the specifications for the IDX?

They will be in V4 of STA-010, but work has not yet begun on the IDX section.

From an operational perspective how does the IDX get EIDOs

The IDX subscribes to all the FEs within an agency and obtains updates for every incident from every FE within the agency.

Can the IDX send EIDOs by reference?

The IDX may deliver coalesced EIDOs by reference. If it does so, then it does the dereferencing for those references.

Is the IDX capable of receiving a constituent EIDO ‘by reference’?

No. The IDX always subscribes to the FEs that supply it constituent EIDOs, therefore the EIDOs are sent by the FEs, to the IDX ‘by value’.

If an EIDO is received by an IDX containing data ‘by reference’, what is in the coalesced EIDO it sends?

If the data was received ‘by reference’, it is sent ‘by reference’.

If the data was received ‘by value’, it is sent ‘by value’.

When an outside organization wants to obtain an EIDO, does it do it through the IDX?

In most cases yes. Policy can determine if an FE in an outside organization is permitted to obtain EIDOs from FEs other than the IDX.

How does an FE locate the IDX?

The agency locator (defined in STA-010) will contain the address (URI) of the IDX that needs to be interrogated about incident information for an agency.

Does the IDX always “mediate” requests for an EIDO? Where mediate means that all requests for EIDOs go through an IDX.

Within an agency, one FE may send/receive EIDOs to other FEs directly.

For FEs outside the agency, see FAQ# 2.8

While it is not mandatory that FEs within an agency use the IDX, there are situations and functions that benefit from having the IDX do mediation. In particular, the coalescing algorithm used by the IDX is complex, and should not be duplicated in other FEs.

Can EIDOs be exchanged without an IDX?

Yes. An FE can exchange EIDOs directly with other FEs. This might be implementation specific. In addition STA-010 specifies how to include an EIDO in a transferred call.

Does the IDX act as a hub (similar to a location server) as opposed to a logger (after call time)?

The IDX is a live FE that acts as an aggregator and only keeps a current picture of an incident. It is not a store of historical information (e.g., if the address has changed three times then only the last change will be in the IDX).

EIDOs may have sensitive information, how is that information protected?

Security for EIDO exchanges is no different than any other exchange in i3. Credentials will be used for all EIDO exchanges (e.g., incident updates or requests for service setup). Requestor will identify and authenticate itself and the server will authenticate back to the requestor. Authorization and authentication is handled at the beginning of the exchange and credentials are used to filter based on policy. The Data Rights Management policy of the sender of the EIDO is the policy that is determinant as to what information is allowed to be exchanged.

How does an FE that receives an EIDO send information it receives in an EIDO that it sends?

In general, FEs may not send information they receive from another entity. However, if an FE receives a reference to an EIDO (or a component of an FE) it may pass the reference on. Authentication of the requester is accomplished by the element providing the dereferenced value. If you dereference an EIDO or component to obtain a value, one should never forward the value, but only the reference URI. Dereferencing is always done at the host designated by the URI.

Is dereferencing always done at the IDX?

The URI leads to some entity that will do the dereferencing, that may or may not be the IDX.

What credentials are used by an FE (including an IDX)?

Any entity sending or receiving an EIDO must have credentials (i.e. public/private key pair issued within the Public Key Infrastructure (PKI) defined in STA-010)

Does the IDX maintain a listing of EIDO related transactions?

No. The Logging Service performs this function.

IDX vs. Logging Service: which element knows about every EIDO generated or distributed in/out of its domain?

The logging Service. The IDX keeps just a current picture of the incident to pass on to a subscriber.

Is the incident record stored in IDX

An IDX may store current data for active incidents but does not store history.

What about an Incident that spans more than one Agency?

When an Incident involves two or more Agencies, each Agency maintains their current view of the Incident which can be obtained from their IDX. Each agency has an IDX and a Logging Service. There is a way to discover all the Agencies involved in an incident and where the Logging Service and IDX for each of those agencies can be reached. There may be an Inter-Agency IDX, which is part of an NGCS, which coalesces information about a multi-Agency Incident from each of the constituent Agency involved and produces a single EIDO representing the aggregated current state of the Incident of all Agencies.

How do you present full incident history to the call taker?

You get current incident state from the individual Functional Elements and/or the IDX (which aggregates incident data from multiple FEs). You get history from the Logging Service.

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

In the Logging Service.

If A transfers to B, would B then request the dereference function back through the IDX at A? If so, when B transfers to C, does C request the dereference function back through B or A?

An IDX may or may not be used. If an IDX is used, B gets an EIDO as part of the transfer. It could be by value or reference. If sent by reference, the URL you get tells you who can dereference it. It could be the IDX (that is implementation specific).

For example, when A sends an EIDO ‘by reference’ to B, B goes back to A to dereference it.

When B transfers the incident to C, if B send the EIDO by reference, then C goes back to B to dereference it. C will know that A is involved, and if C wants to find current state and to get updates, it will request those from A.

When B transfers the incident to C, if B send the EIDO ‘by value’, then C doesn’t need to dereference, but may still opt to request current state and updates from A.

Relevant NENA Documents
Note: To find and download the document, copy the document number (like NENA-STA-010) from below and search the NENA Standards and Documents page.

---

• NENA-STA-010, Detailed Functional and Interface Standards for the NENA i3 Solution