What Is an EIDO, and Why Does It Matter for Data Sharing Between Agencies?

An EIDO, or Emergency Incident Data Object, is a standardized JSON package that

carries everything one system currently knows about a single emergency incident, and hands it

to another system in a format both sides understand. NENA's own glossary defines it as "a JSON- based object that is used to share emergency incident information between and among

authorized entities and systems." In plain operational terms, the EIDO replaces the old serial

cable between call handling equipment and dispatch, and gives agencies a common CAD-to-CAD interface at the same time.

That second half is the part worth slowing down on. For decades, the reason a neighboring center could not simply see your incident was not policy or bad intentions; it was format. Two

systems built by two different manufacturers had no agreed way to describe a caller, a location,

a unit, or an incident type. The EIDO is the agreement. 

This blog from NGA explains what is inside an EIDO, how it travels between agencies, which standards govern it, and what your center should be asking about it right now.

What an EIDO Actually Is

An EIDO is data, not a document and not a screen. It is generated by software, exchanged

between systems, and never displayed to a telecommunicator as a raw object. NENA's EIDO and IDX knowledge base FAQ is direct about this: EIDOs "are computer to computer notifications of incident state, as known by the sender, at the time it was sent." Nobody presses a send EIDO button. When the state of an incident changes, whether a call taker saved a note or an AVL feed moved a unit, the system emits a new EIDO on its own

The standard's own framing explains why the industry needed this. The NENA Standard for

Emergency Incident Data Object opens by noting that as agencies move toward NG911 and IP

based systems, "it is critical that they adhere to a standardized, industry-neutral format for

exchanging emergency Incident information between disparate manufacturer's systems located

within one or more public safety agencies, and with other Incident stakeholders." Industry

neutral is the operative phrase. The format belongs to the standard, not to any one product.

Worth knowing: EIDO is the JSON successor to the older, XML-era concept of the EIDD, the

Emergency Incident Data Document. If you see EIDD in a document from a few years ago, it

is describing the same idea in the format that came before. Current material, including the

NENA glossary entry for EIDO, uses EIDO

What Information an EIDO Carries

An EIDO describes one incident, and it is built from modular data components. Each component

carries a unique identifier, a last update timestamp, and a reference to the agency, and where applicable the agent, that changed it last. That bookkeeping is what lets a receiving system

merge an update without guessing whose version is newer.

The components defined in the standard include:

• Incident information: type, status, and the general details gathered by agents, responders,reporting parties, and devices.
• Call information: one component per call, keyed to the globally unique Call Identifier that the first ESRP in the first ESInet assigns. More than one call can attach to a single incident.
• Person components for callers, suspects, victims, witnesses, and others. A person component with the role set to "caller" must be created alongside the call component at the start of an emergency call, and the caller's details survive in the EIDO even after the call component is gone.
• Location components, which may be the caller's location, the incident location, or another type. Location in NG911 is expressed as PIDF-LO wherever possible, with separate objects used to describe an intersection or a cross street.
• Vehicle components for suspect vehicles, crash-involved vehicles, and others. Telematics data does not live here; it arrives as additional data associated with a call.
• Dispatch and Emergency Resource components, which identify assigned units in the form resource@agency, for example engine52@riversideFD.riverside.ca, and carry status updates from the field.
• Agency and Agent components. Every EIDO includes at least one agency component

identifying its creator, and that agency must have a record in the Service and Agency Locator defined in NENA-STA-010.

• Notes, Disposition codes, Additional Data blocks per RFC 7852, Link components for related incidents, and Split/Merge components for incidents that combine or divide. 

Two details in that list tend to surprise people. First, agency is construed broadly in the

standard, explicitly including organizations such as poison control centers, hospitals, utility

companies, and tow operators. Second, disposition codes are not invented per vendor; the initial registry values are adopted from APCO ANS 1.111.2-2018, Common Disposition Codes for Data Exchange, one of several places where NENA and APCO standards interlock. 

Value lists like incident type, incident status, and person role live in IANA registries, and the person and vehicle structures reuse NIEM types so that non-911 justice and emergency systems can consume them.

What an EIDO Is Not, and Why That Matters

This is the section that prevents most bad assumptions in a procurement conversation.

• An EIDO is not a history. The standard states that an EIDO "SHALL represent the state of the Incident, as known by the sender, at the time it was sent. Only known current state of the Incident is included." It is a snapshot, deliberately.
• An EIDO is not the audit trail. Every EIDO is logged when it is sent or received, and the record of the incident over time lives in the Logging Service. If you want to know what changed and when, you query the logger, not the last EIDO.
• An EIDO is not your incident record. An incident record is internal and typically proprietary to an agency's system, and it may hold more data than the standard covers. The EIDO is the external, standardized representation of it.
• An EIDO is not a complete record of a call. It represents an incident, which may have zero, one, or many calls attached.
• An EIDO does not draw a map. Information in an EIDO can update a mapped display, but the object itself is data.

Get those five straight and you avoid the two most common misreadings: expecting an EIDO to

answer historical questions, and expecting it to be a full replacement for the incident record in

your own system.

How EIDOs Move Between Systems

Conveyance is its own standard. In February 2025, NENA published the ANSI-approved Standard for the Conveyance of Emergency Incident Data Objects between NG911 systems and applications, NENA-STA-024.1.1-2025, which added methods for resource discovery and push notifications covering requests for service, requests for awareness, and the responses to them.

Two movement patterns matter operationally:

1. Push. The system that creates the EIDO sends it to another system with no prior action by the recipient. This is the classic dispatch request: call handling pushes an EIDO to dispatch, the sender includes what it knows, and the recipient does what it considers appropriate.
2. Subscribe, sometimes called pull. The receiver asks in advance, using a subscription with a filter, to be sent EIDOs that match specified criteria. This is how a system tracks an incident as it evolves, or learns that a neighboring agency has opened something relevant.

There is a second axis that matters just as much: by value versus by reference. An EIDO can carry the actual data, or it can carry a URI pointing at the data, which the recipient dereferences from the host named in the URI. By reference is how sensitive information gets shared with third

parties without handing over the contents outright, since authentication happens at the point of

dereference. The rule in the FAQ is worth memorizing: if you dereference a value, you never

forward the value onward, only the reference.

Access is governed by NG911 Data Rights Management policy, and the sender's policy is the

determinant of what may be exchanged. Any entity sending or receiving an EIDO holds

credentials issued under the PKI defined in NENA-STA-010, and there are explicit restrictions on passing along data that your agency originally received from someone else.

The IDX: One Incident, One Composite View

If every functional element inside an agency emits its own EIDOs, an outside agency asking

"what is happening at this incident" would have to stitch several partial views together. The

Incident Data Exchange, or IDX, exists to prevent that. It is a functional element that subscribes

to the elements within an agency, receives their EIDOs, and coalesces them into a single

composite EIDO representing the whole incident as that agency currently knows it.

There is also an inter-agency IDX, which coalesces across agencies so that any authorized agency can retrieve one unified view of a multi-agency incident. The address of an agency's IDX is published as a URI in the agency locator defined in NENA-STA-010, which is how a system finds it in the first place.

Three constraints on the IDX are easy to miss. It keeps only the current picture, not history, so if

an address changed three times the IDX holds the last one. It is not the logger. And it is not

mandatory for internal exchanges, since elements inside an agency may send EIDOs to each

other directly, though NENA notes the coalescing algorithm is complex enough that it should not

be duplicated in every element. The IDX specifications are expected in version 4 of STA-010.

One honest caveat about sources: NENA's knowledge base FAQ is explicitly informative

rather than normative, and parts of it still describe the JSON schema as under development.

The published standards are the authority. NENA-STA-021.1b, dated 2022 and ANSI-

approved, carries the schema, and NENA-STA-024.1.1-2025 carries conveyance. When the

FAQ and a standard disagree, follow the standard.

The Standards that Define It

• NENA-STA-021.1b, EIDO JSON. The data standard itself, with the component definitions, required and conditional elements, and IANA registry actions. NENA publishes it alongside the schema and example instances in the public EIDO JSON repository, which includes a sample call transfer EIDO you can read line by line.
• NENA-STA-024.1.1-2025, EIDO Conveyance. How EIDOs are requested, subscribed to, pushed, and discovered between systems.
• NENA-STA-010, the i3 standard. The architecture underneath all of it: agency and agent identifier formats, the Service and Agency Locator, PIDF-LO, the Logging Service, PKI credentials, and EIDOs carried with transferred calls. If i3 is unfamiliar territory, start with our explainer on what i3 compliance is and why it matters.
• IETF RFC 7852 for additional data associated with a call, and NIEM types for person and vehicle structures.

Two useful non-NENA references sit at the federal level. The National 911 Program's CAD

interoperability report observed that after NENA published the EIDO specification, it "has

become the de facto standard for emergency incident data exchange," while also noting bluntly

that "there is no national body or 911 authority to enforce national standards." The program's

911 data and information sharing strategic plan sets the wider context for why standardized

incident data matters beyond a single console.

That combination, a de facto standard with no national enforcement mechanism, is exactly why

conformance language in your own contracts carries so much weight.

What Changes on The Floor

Telecommunicators will never see an EIDO. What they should notice is the disappearance of

several familiar frustrations.

Transfers carry their context. STA-010 specifies how an EIDO travels with a transferred call,

so the receiving center does not restart the interview from zero. Compare that with the

situation our interoperability post describes, where the accompanying data stops at the

agency boundary.

Mutual aid stops depending on a phone call. When a neighboring agency's system can

subscribe to an incident, the update happens because state changed, not because someone

remembered to relay it.

Status updates become structured. Unit assignment, arrival, and clearing arrive as data

elements instead of a voice report someone retypes.

Dispositions become comparable. Shared registry values mean two agencies can count the

same thing the same way, which is what makes cross-agency reporting and analytics honest.

Location arrives in a form your map can use. PIDF-LO based location, including intersections and cross streets, plugs into the GIS foundation described in our post on GIS in NG911.

It is also worth being realistic about the gap. The same federal report found that most CAD

systems were built as an agency's system of record rather than as interoperable participants,

and that translating incident nature codes and addresses between them is genuinely hard. A

standard removes the format problem. It does not automatically resolve the fact that two

agencies classify the same call differently.

Who Else can Receive Incident Data

The most underappreciated part of the EIDO model is how far outside the PSAP it reaches.

Because agency is defined broadly and access is governed by policy rather than by cable,

standardized incident data can flow to emergency operations centers during a large event, to

hospitals preparing for arrivals, to utilities responding to a line down, to tow operators, and,

with appropriate policy, even to news organizations.

For centers thinking through large-scale response, this is the mechanism that turns the

coordination described in our disaster management post and our continuity of operations post

from a conference call into a data flow. It is also the reason data rights management is not an

afterthought in the standard. The moment external stakeholders can subscribe, deciding what

each of them may see becomes an operational policy question, not a technical one.

Where NGA Fits

NGA's platform is built on i3 architecture, which is the foundation EIDO exchange depends on.

NEXiSCore handles standards-based call and incident processing, NEXiSEdge extends it to the

agencies and positions that sit outside the primary center, and NEXiSAnalytics is where

structured incident data becomes reporting your director and your funding authority can use. If

you want the wider picture of how the pieces fit, our ESInet introduction and the full NG911

solution set are the places to start, and our NG911 terminology guide is useful to keep open

beside any standards document.

If you are mid-transition and trying to work out which of these questions apply to your center

specifically, reach out to our NGA team. It is a short conversation and it usually saves a long

procurement detour.

Frequently Asked Questions

Is an EIDO the same thing as an EIDD?

Effectively yes, one generation apart. EIDD referred to the earlier XML-formatted Emergency

Incident Data Document, and EIDO is the current JSON-based Emergency Incident Data Object. Older NENA and APCO documents use EIDD language for what is now specified as EIDO.

Does an EIDO contain the caller's personal information?

It can. NENA notes that EIDOs will often include the caller's name, number, and location, along

with agents' notes and details about people and vehicles involved. That is precisely why access is controlled by NG911 Data Rights Management policy, why every participating system holds PKI credentials, and why sensitive content is often shared by reference rather than by value.

How often is an EIDO sent during an incident?

Whenever incident state changes meaningfully. At minimum, at least one data component must

differ from the previous EIDO sent for that incident. Sender policy can suppress low-value

changes, and a responding unit's location is the usual example.

Do we need an IDX to exchange EIDOs?

No. Functional elements can exchange EIDOs directly, and STA-010 specifies how an EIDO

accompanies a transferred call. An IDX becomes valuable when you want one composite view of an incident for requesters outside your agency, and the inter-agency IDX serves the same

purpose across agencies.

If an EIDO only carries current state, how do we reconstruct what happened?

From the Logging Service. Every EIDO is logged when sent or received, so the history of an

incident, including what a value was before it changed, is reconstructed from the logger rather

than from any single EIDO

Conclusion

The EIDO is not a feature and it is not a product. It is an agreement about format, which is why it quietly solves a problem that better intentions never could. One system knows something about an incident, another system needs it, and for the first time both describe it the same way.

For a center evaluating systems, that reframes the question. The useful thing to ask is not

whether a platform supports data sharing, but which standard versions it implements, which

conveyance patterns it supports, who controls the sharing policy, and whether your agency is

discoverable to everyone who might need to reach you. Those answers decide whether your

incident data actually crosses the boundary when it matters.

For the standards themselves, NENA's knowledge base and the National 911 Program's resource library are both worth bookmarking, and the National 911 Program site tracks the federal side of the transition. For a broader orientation, see our 2026 NG911 resource guide or browse the NGA resource library.